The self-CI gate ran `./actionlint -shellcheck=`, and the empty value
silently disabled the shell-linting half of the check — so every `run:`
body in the reusable workflows this repo publishes was unlinted, on the
exact path that deploys to AWS.
Measured against the pinned actionlint 1.7.12 and the shellcheck the
ubuntu-latest runner ships (0.9.0-1), the real backlog was 5 findings,
not the 4 the old comment claimed. Three were genuine and are fixed in
the shell:
- cd-cdk.yaml "Publish .NET project" (SC2046): the project path was
interpolated inline and `$(dirname ...)` was unquoted, so a path
containing whitespace split into several arguments. Now passed via
env indirection and quoted, which also removes the last inline
expression interpolation from that step.
- cd-cdk.yaml / ci-python-sam.yaml "Install Python dependencies"
(SC2044 x2): `for req in $(find ...)` word-split and globbed every
path found. Replaced with a NUL-delimited `while read` loop.
Two are deliberate and are suppressed per-line, with the reasoning in a
comment directly above:
- cd-sam.yaml `sam deploy ... $PARAMS` and cd-cdk.yaml
`cdk deploy $STACKS` (SC2086 x2) rely on word-splitting so multiple
parameter overrides / stack selectors reach the CLI as separate argv
entries. Quoting them would collapse each into a single argument and
break every parameterised or multi-stack deploy, so they keep the
unquoted expansion and carry a scoped `# shellcheck disable=SC2086`.
The gate now runs plain `./actionlint` (shellcheck defaults to the
binary on PATH) and prints `shellcheck --version` first, so the check
fails loudly if a future runner image drops it instead of quietly
linting less.
Three pieces of tooling for retired flows were still carried in this
repo, and the README documented them as if they were current.
- `.github/workflows/compliance-audit.yaml`: deprecated 2026-06-10.
Its schedule was already stripped, and its live state in the Actions
API is `disabled_manually`, so it was workflow_dispatch-only and
inert. It was also the last consumer of the `CLAUDE_CI_APP_ID` and
`CLAUDE_CI_APP_PRIVATE_KEY` org secrets.
- `scripts/rollout-review-workflow.sh`: a one-shot script that pushed a
per-repo wrapper calling `claude-code-review.yaml`. That reusable
workflow was deleted on 2026-05-13 and no longer exists in this repo
or any of the 31 org repos, so the script could only ever open PRs
for a workflow that resolves to nothing.
- README `PR Reviews`, `Scripts`, and the `claude-code-ci` GitHub App
setup steps, which described the same retired flows.
The `ANTHROPIC_API_KEY` org secret is deliberately kept in the setup
table: it is still read by the active `reviewer-eval.yml` workflow in
`open-swe`. The `CLAUDE_CI_APP_*` secrets are now unreferenced across
the org, but this change only removes their documentation. Neither the
secrets nor the App itself are touched.
Setup steps are renumbered 1-3 with no gap, and the `see §5` reference
in the IAM section is repointed to §3. actionlint 1.7.12 (the version
pinned in ci.yaml) passes clean over the remaining workflows.
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.
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.
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.
INFRA-69: README documented the deleted claude-code-review.yaml workflow and
its rollout as the live PR-review setup. PR reviews are handled by the official
Claude Code App (since 2026-05-13); corrected the workflow list, added a PR
Reviews note, marked the legacy rollout script, and replaced the obsolete
rollout step. Preserved the claude-code-ci App + secrets (compliance-audit
still uses them).
INFRA-68: add SECURITY.md (private vuln reporting via GitHub advisory / email)
and SUPPORT.md (Jira INFRA, handbook, security pointer).
The bootstrap IAM stack (oidc-deploy-roles.yaml) had no README coverage:
how to deploy it manually (no CD pipeline; >51KB needs --s3-bucket), the
scoped github-cfn-execution-role contract, and the
seahaven-lambda-execution-boundary ceiling for SAM Lambda roles.
Documents the INFRA-97 / INFRA-103 work.
Parameterized workflows that each repo calls via a thin 3-5 line
caller. All lint, test, and validate steps are toggleable so repos
can adopt incrementally. Covers Python SAM, Python CDK, TypeScript
CDK, and Node.js SAM stacks.
- Reusable PR review workflow (repos call via thin wrapper)
- Weekly compliance audit across all org repos
- Rollout script to push wrapper workflow to all repos
- Uses GitHub App tokens for cross-repo auth (no PAT rotation needed)
