Shared CloudFormation stacks

Apps do not write their own infrastructure from scratch. They pick an archetype — the deployment policy envelope defined in aws-bootstrap that bounds what the deployer may provision in the account — and compose fragments, the published templates in Switchboard's fragment library, shipping artifacts into their shape. Archetype and fragment are different axes and are never used for each other.

Conventions your stack must follow:

• Tags are the interface, and every key has a reader. The deploy writes the stack set — swb:stack-set / swb:tenant / swb:app / swb:env — at stack level, and CloudFormation propagates it onto every taggable resource, exec roles included; your stack writes none of it. A workload's scopes are its record's, keyed on the role ARN, not read from a tag. Public surfaces carry swb:endpoint, which your template does write because only it knows what a resource exposes — see endpoints. A tag a system outside Switchboard reads off your resources — Datadog's service / env / version, the AWS console's awsApplication grouping — is yours to declare in your app's manifest under cfn.tags, with the deploy's own placeholders; the platform writes none of them.
• Outputs are read back. Component versions (landedPins) and anything a custom resource produces surface as stack outputs; the deploy read-back records them on the install.
• Custom resources carry the odd jobs. Anything the old deploy workflows did that is not CloudFormation belongs in a custom resource — the Zuplo gateway and dev portal deploy through Custom::ZuploProject in the app's own CDK.

Templates and their locations are catalogued per repo in the console's Repositories page; the construction-phase plugin will carry the per-archetype how-to.