The workflow-templates catalog offered starter workflows for only 7 of
the 12 reusable workflows in .github/workflows, so ci-python-app,
ci-typescript-frontend, ci-static, ci-dotnet and cd-mobile-ios were
invisible in the org's Actions > New workflow UI and had to be wired by
hand. Add a template + properties.json pair for each.
Each caller CI job is keyed `ci` so the check context resolves to the
`ci / ci` required by the org ruleset, and every reusable ref is pinned
to the same 40-char SHA the existing templates use. node-version: "24"
is passed on the three reusables that declare the input
(ci-typescript-frontend, ci-static, cd-mobile-ios); ci-python-app and
ci-dotnet do not declare it, so it is omitted there.
Phase A moved the CFN execution role's boundary-gated IAM statements into
the attached seahaven-cfn-exec-iam-management managed policy, with the
escalation fixed and three Deny backstops, while deliberately leaving the
old inline iam-role-management-boundary-gated policy in place so that
deploy removed nothing. That is now redundant and this removes it.
Effective permissions are unchanged, proven statically before deploying:
of the 6 Allow statements being removed, 5 are byte-identical to the
managed policy's. The only difference is Sid IAMPutPermissionsBoundary,
where the inline copy also listed iam:DeleteRolePermissionsBoundary --
the action DenyBoundaryTampering explicitly denies, so that Allow was
already inert.
Frees the scarce budget: inline usage drops from 10,006 to 8,261 of IAM's
10,240-byte per-role limit, leaving 1,979 bytes of headroom on a role that
previously had 234.
The shared CloudFormation execution role could remove the permissions
boundary from the very roles that boundary was gating. Its
iam-role-management-boundary-gated policy allows
iam:DeleteRolePermissionsBoundary on role/* under a StringEquals
condition on iam:PermissionsBoundary -- and for a delete that condition
key reflects the boundary CURRENTLY attached to the target role, so it
matches exactly the roles the gate protects. Create a boundary-gated
role with an inline *:* policy, strip its boundary, PassRole it to
Lambda, and the result is unbounded admin in the management account.
Confirmed live with simulate-principal-policy, not inferred.
Phase A adds an attached managed policy, seahaven-cfn-exec-iam-management,
carrying the corrected statement set: the boundary-gated Allows without
iam:DeleteRolePermissionsBoundary, plus three Deny backstops --
DenyBoundaryTampering (boundary removal), DenyBoundaryPolicyEdit
(rewriting a seahaven-* policy document) and DenySelfMutation.
DenySelfMutation exists because the first draft of this fix was not
durable: the role holds iam:DetachRolePolicy, iam:DeleteRolePolicy and
iam:DeleteRole on Resource "*" with no condition, so it could detach the
Deny-carrying policy from itself in one call and reinstate the
escalation. It now cannot modify its own role, any githubdeploy-* role,
or any seahaven-* policy. Nothing legitimate needs that: the deploy
substrate's own principals are owned by this stack, which is deployed
manually with administrator credentials rather than through this role.
The change is additive. The old inline policy stays in place, so
CloudFormation removes nothing and there is no window in which the role
lacks its IAM permissions -- an explicit Deny beats an Allow anywhere in
the policy set, so the corrected version governs from the moment this
lands. Phase B removes the redundant inline copy. The split is also
required by size: inline sits at 10,006 of IAM's 10,240-byte per-role
limit, and the Deny statements do not fit there.
Also reconciles drift. The deployed role carries three logs:*MetricFilter
actions added out-of-band on 2026-06-29 and never back-ported.
afterhours-shift-manager creates an AWS::Logs::MetricFilter through this
role, so they are load-bearing; the template now matches the live policy
exactly, which keeps inline at 10,006 and stops a future write-back from
silently stripping them.
Removes the SeahavenSlackBotDeployRole resource block. Step 1 recorded
DeletionPolicy/UpdateReplacePolicy Retain in the deployed template, so
CloudFormation stops managing the resource without issuing DeleteRole
against a role that no longer exists -- confirmed from the change set,
which reports PolicyAction: Retain on a single Remove entry.
seahaven-slack-bot was decommissioned in favour of sh-mcp and the role
was deleted directly in IAM on 2026-07-23. The stack is now consistent
with reality again, and stack updates no longer fail on it.
seahaven-slack-bot was retired in favour of sh-mcp and its deploy role was
deleted directly in IAM on 2026-07-23, leaving the stack holding a
resource that no longer exists. The Outputs section resolved
!GetAtt SeahavenSlackBotDeployRole.Arn as a LIVE IAM read at the end of
every update, so the role's absence failed the whole thing:
Unable to retrieve Arn attribute for AWS::IAM::Role, with error message
The role with name githubdeploy-seahaven-slack-bot cannot be found. (404)
This is latent and invisible: the resource definition is unchanged, so it
produces no change-set entry, and change sets do not preview Outputs
resolution. A clean change set was not evidence the update would succeed.
It surfaced when the Phase A boundary-Deny change failed on it.
Step 1 of two. Removes the Output so updates stop resolving the ghost, and
records DeletionPolicy/UpdateReplacePolicy Retain so that step 2 can drop
the resource without CloudFormation issuing DeleteRole against a role that
is not there. Verified from the change set that this step touches only
DeletionPolicy and UpdateReplacePolicy -- metadata, requiresRecreation
Never -- so no IAM call is made against the missing role.
Nothing imported the Output: it had no ExportName, and no stack imports
any export from this stack.
Step 2 deletes the resource block itself.
Publishes a .NET project, packages the output as a bundle, uploads it,
creates an Elastic Beanstalk application version, and updates an
existing environment using OIDC credentials. It deploys to an
environment; it never creates one.
Two deliberate departures from the existing cd-* reusables:
- A concurrency group keyed on application+environment, with
cancel-in-progress false, so two pushes cannot deploy over each other
and an in-flight deploy is never aborted midway. The existing cd-*
workflows have no concurrency group at all.
- No input or secret is interpolated into a run: body; everything goes
through env-var indirection. The repo's actionlint runs with
shellcheck disabled, so this is a hand-maintained property.
The post-deploy check polls rather than using the CLI waiter
"elasticbeanstalk wait environment-updated": that waiter is hardcoded to
20 attempts x 20s and the CLI cannot extend it, so a slower rolling
deploy would fail the job while the deployment was still healthy. The
timeout is an input instead. The check asserts status, health and the
running version label -- Elastic Beanstalk reports a rolled-back deploy
as a healthy Ready environment running the previous version, so without
the version assertion the job would go green over a failed deploy.
Replaces the malformed cd-dotnet-eb.yaml.yml stub (doubled extension,
empty on:/jobs:). Adds the matching starter template and README entries.
The sam-deploy starter template pointed every new repo's cfn-role-arn at
the management account's execution role, silently landing new workloads
in an account frozen for workloads. The ARN is now a REPLACE-ME
placeholder with guidance to use the github-cfn-execution-role in the
repo's target account.
Per the updated handbook convention (engineering-handbook PR #18),
reusable-workflow references use full commit SHA pins with a '# main'
comment instead of the mutable @main branch ref. Templates now ship
pinned so new repos start convention-compliant; Dependabot advances
the pin after instantiation. Commented usage examples in ci-static and
ci-typescript-frontend use the <full-commit-sha> placeholder form.
Callers with an adjudicated accepted-risk advisory (suppressed with
justification in their repo-local .security-review/suppressions.json)
had no way to keep the dependency-review check green when a lockfile
diff touches a package still inside the vulnerable range. Passes the
input straight to actions/dependency-review-action. Default '' is
byte-identical to an unset action input, so existing callers are
unaffected.
First consumer: seahaven-site, allowing GHSA-mh99-v99m-4gvg
(brace-expansion, no in-range fix until @11ty/recursive-copy bumps
minimatch).
Unpinned pip install ruff let ruff 0.16.0 pick up expanded
default lint rules, breaking every caller repo without its
own ruff config. Pinning prevents implicit rule-set changes
on new ruff releases.
Refs: #87
Co-authored-by: amoussa1229 <166072409+amoussa1229@users.noreply.github.com>
payments-dashboard's BoaRawBucket (first bucket in the org with an
explicit BucketEncryption block) failed CREATE: the CFN execution
role lacked s3:PutEncryptionConfiguration. Adds the Get/Put pair to
the shared s3-management statement (bucket-level, existing * scope).
Escalation review: the role holds no kms:* actions anywhere, so the
PutEncryptionConfiguration + PutBucketPolicy combination cannot pivot
to a role-controlled KMS key; SCPs permit the action (the original
denial was identity-policy). GPT-4.1 cross-family review: FIX-level
only, dispositioned above. Stack deployed before merge per README.
Refs: payments-dashboard#76
Post-rename deploy verified green from seahaven-org-baseline (run
29355616637, both account jobs). The freed repo name must not stay
trusted (namespace-reuse window, security review IAC-02).
* Add stacks input to cd-cdk for multi-account apps
cdk deploy was hardcoded to --all, which breaks when one CDK app defines
stacks for two AWS accounts: whichever role the job assumed fails on the
other account's stacks. Callers can now pass per-job stack selectors;
default stays --all so existing callers are unaffected.
* Trust seahaven-org-baseline sub on account-baseline deploy role
Transition pair for the repo rename: OIDC sub claims carry the repo full
name, so the renamed repo cannot assume the role until its sub is
trusted. Old sub is removed after a post-rename deploy verifies green.
* Pass stacks selector via env var, not expression interpolation
Defense-in-depth from the security review: expression interpolation
into run: is pre-shell text substitution, so metacharacters in the
input would execute as script. Env-var expansion never re-parses shell
syntax; word-splitting for multiple selectors is preserved.
Add job-level concurrency (cancel-in-progress) to all four ci-python-app
jobs, matching the ci-python-sam idiom. Per-job group keys include
github.job so the parallel jobs in a single run do not share a group.
Replace sam-deploy starter-template stack-name: $default-branch (which
GitHub substitutes to the literal branch name main) with a
REPLACE-ME-stack-name placeholder, and point cfn-role-arn at the real
shared github-cfn-execution-role.
actions/checkout v7.0.0 (2026-06-18) is internally an ESM rebuild plus
one behavioral change: it blocks checking out a fork PR head ref under
pull_request_target / workflow_run (PR #2454). No Sea Haven workflow uses
those triggers, so there is no reachable behavior change. The Node 24
runtime requirement already landed at v6, so v6 -> v7 carries no new
runner requirement. All runners here are GitHub-hosted (ubuntu, macos).
Covers all 16 checkout pins across 12 reusable/standalone workflows plus
the dependency-review workflow-template scaffold. Consumers on @main pick
this up automatically on merge.
Adds ci-typescript-frontend.yaml, a workflow_call reusable CI for bundled
TypeScript SPAs (Vite / React / Vue with vitest + Playwright). Existing
reusable CIs do not fit this shape: ci-static is for plain HTML sites and
ci-typescript-cdk targets CDK infra repos.
The workflow runs as a single `ci` job so callers emit the `ci / ci` status
context the org branch-protection rulesets require. Steps: a Sea Haven
standards gate (required npm scripts present, plus a changed-line guard for
AI-tool footers, hook bypasses, and hardcoded secrets), then format:check,
lint, build, unit tests, and an optional Playwright browser smoke. Every step
past the standards gate is individually toggleable, and string inputs are
passed through env to avoid expression injection.
Documents the workflow in the README reusable-workflows list.
The central label rules assumed a root-level project layout
(lib/**, bin/**, cdk/**, src/**), so monorepos that nest components
under top-level dirs (infra/, web/, mobile/, shared/) matched nothing
for those areas. PRs touching only infra/lib/** or web/** ran the
labeler green but received no label.
Label coverage:
- infra: + 'infra/**' (covers infra/lib, infra/bin, infra/cdk.json)
- app: + 'web/**', 'mobile/**', 'shared/**'
Additions are appended to the existing root paths, so single-project
repos are unaffected; deliberately avoided blanket '**/lib/**' globs
that would mislabel web/src/lib/** as infra.
Hardening rolled in while here:
- Pin actions/labeler to a commit SHA (was the floating @v6 tag)
- Add a per-PR concurrency group with a run_id fallback for non-PR
callers, so rapid pushes cancel superseded label runs
- Broaden 'ci' (.github/actions/**), 'dependencies'
(Directory.Packages.props, yarn.lock, pnpm-lock.yaml, Podfile/.lock)
and 'tests' (JS/TS .test/.spec, pytest test_*.py/conftest,
.NET *Tests.cs, Java *Test.java, Go, Ruby) globs
Caller repos must already have any label a rule can emit; actions/labeler
does not create missing labels. The org 'infra' label was backfilled
across repos separately.
Reusable CI for plain Python apps / locally-run tooling that don't deploy via
SAM or CDK. Beyond ruff lint/format + the conventions audit, it adds a
collect-only import check for a root suite whose live run needs secrets, and an
isolated full pytest run for a self-contained subproject dir (whose tests/
package would collide with the root tests/ under one rootdir).
Emits the org-required `ci / ci` via an aggregator job keyed `ci` that gates on
every other job. actionlint-clean.
Add a thin caller so the .github repo invokes its own reusable
callable-labeler.yaml on pull_request, like every consumer repo does. Without a
caller the workflow_call-only labeler never runs on .github's own PRs (this is
why #61 wasn't auto-labeled). Grants the three permissions the reusable requires
(contents:read, pull-requests:write, issues:write).
