Merge 4f5a5040e3 into 86b4859589

requireImdsv2:true makes CDK auto-create a launch template named from the
construct id ('Instance' -> 'InstanceLaunchTemplate') with no env qualifier,
so OpenSweDevStack and OpenSweProdStack both render
LaunchTemplateName: InstanceLaunchTemplate. dev created it first (the live
dev box runs on it); the prod first-deploy then failed with
InvalidLaunchTemplateName.AlreadyExistsException and the whole stack rolled
back.

Force a per-env LT name (open-swe-<env>-lt) via an aspect (the LT is created
at synth time by the requireImdsv2 handling, not in the constructor), and
rename the instance's launch-template REFERENCE in lockstep so CFN still
resolves it. synth-verified: dev=open-swe-dev-lt, prod=open-swe-prod-lt on
both the LT resource and the instance reference; version GetAtt preserved.

NOTE: deploying this renames dev's LT -> one-time dev box replacement
(stateless; boots from the baked AMI + pulls releases/latest). prod then
creates open-swe-prod-lt cleanly.

.github/scripts/check-dev-green.sh

@@ -26,6 +26,11 @@
 set -euo pipefail
 
 EXCLUDE_RUN_ID="${EXCLUDE_RUN_ID:-}"
+# Name of the promotion workflow's own check-run (its job id). STALE check-runs from
+# prior FAILED promote runs on the same dev HEAD are dropped in the loop so they don't
+# self-poison the "every present check must be green" rule. Configurable so a job
+# rename doesn't silently break the exclusion.
+PROMOTE_CHECK_NAME="${PROMOTE_CHECK_NAME:-promote}"
 # Mandatory checks (one per line). Defaults to the CI suite, which runs on
 # every push to dev (see ci.yml). Keep in sync with those job names; if a name
 # drifts the gate blocks (fails safe) until the list is updated.
@@ -41,7 +46,18 @@ while IFS=$'\037' read -r name status conclusion details_url; do
   [ -n "${name:-}" ] || continue
   # drop the promotion run's own check-run by run id (never by name).
   if [ -n "${EXCLUDE_RUN_ID}" ] && \
-     [ "${details_url}" != "${details_url#*/runs/${EXCLUDE_RUN_ID}/}" ]; then
+     [ "${details_url}" != "${details_url#*/runs/"${EXCLUDE_RUN_ID}"/}" ]; then
+    continue
+  fi
+  # Also drop ANY check-run from the promotion workflow itself — not just THIS run
+  # (above) but STALE ones left by prior FAILED promote runs on the same dev HEAD,
+  # which would otherwise self-poison this gate forever (the failure check-run is
+  # immutable on the commit). Scoped to name==PROMOTE_CHECK_NAME AND a GitHub Actions
+  # run URL (details_url under /actions/runs/) so an EXTERNAL app cannot hide a real
+  # failing check by naming it "promote". The positive REQUIRED_CHECKS allow-list
+  # below is the authoritative signal regardless — "promote" is never a required check.
+  if [ "${name}" = "${PROMOTE_CHECK_NAME}" ] && \
+     [ "${details_url}" != "${details_url#*/actions/runs/}" ]; then
     continue
   fi
   seen=$((seen + 1))

.github/workflows/promote-dev-to-prod.yml

@@ -19,15 +19,32 @@ jobs:
       contents: write
       checks: read
     steps:
+      # Mint a GitHub App installation token for the protected-branch push below.
+      # A plain ref push by github-actions[bot] is REJECTED by the `main` ruleset
+      # (PRs required + a required status check; the default token is not a bypass
+      # actor). The App behind these secrets MUST be added to the `main` ruleset's
+      # bypass actors; the push is then accepted and attributed to the App (not a
+      # human PAT). The promoted commit already passed every check on dev (gated
+      # below), so re-gating it via a PR on main would be redundant.
+      - name: Mint app token for the protected-branch push
+        id: app-token
+        uses: actions/create-github-app-token@bcd2ba49218906704ab6c1aa796996da409d3eb1 # v3.2.0
+        with:
+          app-id: ${{ secrets.PROMOTE_APP_ID }}
+          private-key: ${{ secrets.PROMOTE_APP_PRIVATE_KEY }}
       - uses: actions/checkout@v7
         with:
           ref: dev
           fetch-depth: 0
+          # Persist the App token as the git credential so the fast-forward push uses
+          # the bypass-actor identity (not the default github-actions[bot]).
+          token: ${{ steps.app-token.outputs.token }}
       - name: Require dev HEAD fully green
         # Hard precondition: every check-run on the dev HEAD commit must be
         # completed + passing before we let it become prod. A red OR still-pending
-        # check blocks the promotion. The promote job's own in-progress check-run
-        # is excluded by name so the gate can't deadlock on itself.
+        # check blocks the promotion. The promotion workflow's OWN check-runs are
+        # excluded by the gate (this run by id, plus any STALE prior promote runs by
+        # name + Actions URL) so the gate can't deadlock on itself.
         env:
           GH_TOKEN: ${{ github.token }}
           # exclude THIS run's own check-run by its run id (not by name).
@@ -39,7 +56,13 @@ jobs:
             -q '.check_runs[] | [.name, .status, (.conclusion // ""), (.details_url // "")] | join("\u001f")' \
             | bash .github/scripts/check-dev-green.sh
       - name: Fast-forward main (PROD) to dev
-        # main is the production branch; a plain ref push is fast-forward-only
-        # (branch protection rejects non-FF), so a diverged main fails loudly.
+        # main is the production branch. A direct ref push is normally rejected by the
+        # `main` ruleset (PRs required), so this succeeds only because the App minted
+        # above is a bypass actor. The push is fast-forward-only, so a diverged main
+        # fails loudly rather than force-updating.
+        #
+        # SECURITY: this is the LAST step on purpose. The App token persists as the
+        # git credential after checkout — do not add steps after this push that run
+        # untrusted code or could echo the credential.
         run: |
           git push origin HEAD:refs/heads/main

infra/lib/constructs/app-service.ts

@@ -8,7 +8,7 @@ import * as logs from "aws-cdk-lib/aws-logs";
 import * as route53 from "aws-cdk-lib/aws-route53";
 import * as iam from "aws-cdk-lib/aws-iam";
 import * as ssm from "aws-cdk-lib/aws-ssm";
-import { Construct } from "constructs";
+import { Construct, IConstruct } from "constructs";
 import { EnvName, prefix } from "../config";
 import { bakedOpenSweArm64 } from "./ami-cache";
 
@@ -230,6 +230,27 @@ export class AppService extends Construct {
       ],
     });
 
+    // `requireImdsv2: true` makes CDK auto-create a launch template, and it names
+    // that LT from the construct id ("Instance" -> "InstanceLaunchTemplate") with NO
+    // env qualifier — so OpenSweDevStack and OpenSweProdStack both want the identical
+    // LT name and the second env to deploy fails with
+    // InvalidLaunchTemplateName.AlreadyExistsException (prod rollback, 2026-06-29).
+    // Force a per-env LT name. Done via an aspect because the LT is created at synth
+    // time by the requireImdsv2 handling, not in this constructor.
+    cdk.Aspects.of(this.instance).add({
+      visit(node: IConstruct) {
+        if (node instanceof ec2.CfnLaunchTemplate) {
+          node.launchTemplateName = `${p}-lt`;
+        }
+        // The instance references the LT BY NAME, so the reference must be renamed in
+        // lockstep (preserve the GetAtt version) or CFN can't find the template.
+        if (node instanceof ec2.CfnInstance && node.launchTemplate) {
+          const spec = node.launchTemplate as ec2.CfnInstance.LaunchTemplateSpecificationProperty;
+          node.launchTemplate = { ...spec, launchTemplateName: `${p}-lt` };
+        }
+      },
+    });
+
     // SSM deploy document (open-swe-<env>-deploy): runs the baked
     // /opt/open-swe/bin/deploy.sh to pull the latest release + restart. CI fires it
     // (tag-scoped to project=open-swe,env=<env>) after uploading a release, so the

infra/lib/constructs/instance-role.ts

@@ -64,28 +64,35 @@ export class InstanceRole extends Construct {
     // random 6-char suffix, hence the trailing `*`. This is the statement that
     // actually gates which secret VALUES the box can read: prefix-scoped, so the
     // dev box can never read prod secret values (and vice versa). GetSecretValue is
-    // checked per-secret even when the value is returned via BatchGetSecretValue.
-    //
-    // BatchGetSecretValue is included here (prefix-scoped, NOT `*`) because
-    // fetch-config.sh now fetches by EXPLICIT `--secret-id-list` rather than a name
-    // `--filters` scan (OSWE-IAC-SECRETS-LIST-01). An id-list batch call authorizes
-    // against each referenced secret's ARN, so the prefix ARN satisfies it — and we
-    // no longer need the account-wide `secretsmanager:ListSecrets` grant that a
-    // filtered collection scan unavoidably forced (ListSecrets has no resource-level
-    // scoping). Net effect: the box can read open-swe-<env>/* secret values and
-    // nothing else — it can no longer enumerate secret names account-wide.
+    // checked per-secret even when the value is returned via the batch call below.
     this.role.addToPolicy(
       new iam.PolicyStatement({
         sid: "ReadSecretValues",
-        actions: [
-          "secretsmanager:GetSecretValue",
-          "secretsmanager:BatchGetSecretValue",
-          "secretsmanager:DescribeSecret",
-        ],
+        actions: ["secretsmanager:GetSecretValue", "secretsmanager:DescribeSecret"],
         resources: [`arn:aws:secretsmanager:${REGION}:${ACCOUNT}:secret:${p}/*`],
       }),
     );
 
+    // BatchGetSecretValue MUST be granted on `*` — it is a collection action that
+    // AWS authorizes against the account, NOT the per-secret ARN, REGARDLESS of
+    // whether the caller uses `--filters` or `--secret-id-list`. A prefix-scoped
+    // BatchGetSecretValue AccessDenies the whole call ("no identity-based policy
+    // allows the secretsmanager:BatchGetSecretValue action") — VERIFIED on the live
+    // dev box 2026-06-29 (the OSWE-IAC-SECRETS-LIST-01 attempt to prefix-scope it
+    // crash-looped the box once the prior broad grant's eventual-consistency lapsed).
+    // This `*` does NOT widen VALUE access: a secret value is only returned when the
+    // prefix-scoped GetSecretValue above also allows it, so cross-env value isolation
+    // holds. The win that DID survive: fetch-config uses `--secret-id-list` (explicit
+    // names, no name filter), so `secretsmanager:ListSecrets` is NOT needed and is
+    // intentionally omitted — the box cannot enumerate secret names account-wide.
+    this.role.addToPolicy(
+      new iam.PolicyStatement({
+        sid: "BatchGetSecretValues",
+        actions: ["secretsmanager:BatchGetSecretValue"],
+        resources: ["*"],
+      }),
+    );
+
     // NOTE (T11): SSM SecureString + Secrets Manager here are assumed to use the
     // AWS-managed keys (alias/aws/ssm, alias/aws/secretsmanager) for which the
     // service grants Decrypt implicitly — so NO kms:Decrypt is granted. If T11