Key tested-image cache by sealed release identity

[alexeygrigorev]

Problem\nThe container job caches release-image.tar under only the source SHA. Schema-2 release identities also include a run-time version and constructed_at. A later manual promotion of the same SHA can restore an image labeled with an earlier identity and fail provenance, even though the image was valid for the original run.\n\nObserved on 2026-08-24 for SHA 522c47d: push run 32680937557 passed container verification with version 20260824-014815-522c47d; manual run 32682462766 restored that cache entry but expected 20260824-021544-522c47d and failed before publish/deploy.\n\n## Scope\n- Include the sealed schema-2 identity in the tested-image cache key so a cache hit can only restore an image built with the same release labels.\n- Add or adjust workflow contract tests for the cache key.\n- No Dockerfile, application runtime, deployment, or AWS changes.\n\n## Acceptance\n- A cache hit is valid only for the exact sealed source SHA, version, and constructed_at identity.\n- Existing automatic rerun reuse remains possible for the same sealed identity.\n- Manual reuse_existing_image=false builds a fresh image when its identity differs.\n- Focused CI tests and the normal CI quality gates pass.

[alexeygrigorev]

PM grooming — READY FOR ENGINEERING\n\nThe issue is narrowed to the CI tested-image cache invariant. The allowed implementation paths are exactly:\n\n- \n- \n\nThe engineer must key the cache from the sealed schema-2 identity produced by , including the fields that determine the image labels (, , and ). Automatic reruns must still restore the first attempt's exact identity; a manual run with must not restore an image from a different identity for the same SHA. No application, Dockerfile, deployment, or AWS changes are in scope.\n\nTester must verify the exact two-file allowlist, reproduce the prior same-SHA/different-identity cache mismatch, and prove that same-identity rerun reuse remains valid.

[alexeygrigorev]

PM grooming — READY FOR ENGINEERING (corrected)\n\nThe issue is narrowed to the CI tested-image cache invariant. The allowed implementation paths are exactly:\n\n- .github/workflows/ci.yml\n- ci/tests/test_workflows.py\n\nThe engineer must key the cache from the sealed schema-2 identity produced by resolve-release, including the fields that determine the image labels: source_sha, version, and constructed_at. Automatic reruns must still restore the first attempt's exact identity; a manual run with reuse_existing_image=false must not restore an image from a different identity for the same SHA. No application, Dockerfile, deployment, or AWS changes are in scope.\n\nTester must verify the exact two-file allowlist, reproduce the prior same-SHA/different-identity cache mismatch, and prove that same-identity rerun reuse remains valid.\n\nThe immediately preceding comment was malformed by shell quoting; this comment supersedes it.

[alexeygrigorev]

PM technical acceptance — ACCEPTED\n\nThe independent tester verified the frozen #222 candidate in a separate worktree.\n\n- Exact two-file allowlist: .github/workflows/ci.yml and ci/tests/test_workflows.py.\n- The previous same-source-SHA/different-version collision was reproduced and now yields different cache keys.\n- Exact sealed identities yield the same key, preserving automatic rerun reuse.\n- No run_id or run_attempt is in the key.\n- make test-ci: 572 passed.\n- Workflow tests: 16 passed; lint and typecheck passed; actionlint passed with only the pre-existing SC2129 warning outside the diff.\n- Container verification: 13 assertions passed.\n- The repo-wide format check still reports two unchanged out-of-scope podcast files; the candidate’s changed-file format check passed.\n- Playwright and screenshots are not applicable to this CI-only workflow contract change.\n\nThe candidate is technically accepted. The engineer may commit exactly the frozen two-file diff with Refs #222. This acceptance does not claim deployment success or issue closure.

[alexeygrigorev]

PM scope amendment — #222 follow-up\n\nThe first post-merge CI envelope found one stale assertion in core/tests/test_deployment_workflow.py:330. It still expected the retired SHA-only tested-image cache key, so the Django gate correctly rejected the candidate after the workflow implementation changed.\n\nThis is an in-scope contract update required by the same #222 invariant. The amended exact allowlist is:\n- .github/workflows/ci.yml\n- ci/tests/test_workflows.py\n- core/tests/test_deployment_workflow.py\n\nThe follow-up may update only the stale assertion and add narrowly necessary regression coverage. No application runtime, Dockerfile, deployment, AWS, or unrelated test changes are authorized. Tester must rerun the exact allowlist and official CI-oriented checks; PM acceptance of the first candidate is superseded for the follow-up.

[alexeygrigorev]

PM technical acceptance — AMENDED FOLLOW-UP ACCEPTED\n\nThe amended #222 candidate has passed an independent tester envelope after the first post-merge stale assertion was found.\n\n- Exact three-file allowlist: .github/workflows/ci.yml, ci/tests/test_workflows.py, core/tests/test_deployment_workflow.py.\n- Workflow contracts: 17 passed.\n- Deployment workflow contracts: 125 passed, 305 subtests passed.\n- make test-ci: 603 passed.\n- Ruff check and format check: passed for both changed test files.\n- Mypy: passed for both changed test files.\n- YAML validation and same-SHA/different-identity collision simulation: passed.\n- Exact sealed identities reuse the same cache key; different identities do not; run_id/run_attempt are absent.\n- The engineer worktree remained untouched by the tester; no Playwright run was required for this CI contract-only follow-up. Actionlint was unavailable in the tester environment; PyYAML and workflow contract tests supplied YAML validation.\n\nThe amended candidate is accepted. The engineer may commit exactly the three-file follow-up with Refs #222. This acceptance does not claim deployment success or issue closure.

[alexeygrigorev]

PM scope amendment — #222 follow-up 2\n\nThe post-merge quality and Django gates exposed the generated frozen terminology policy entry for core/tests/test_deployment_workflow.py. Updating that test requires refreshing only its recorded whole-file SHA-256; its expected legacy-term count remains 28.\n\nThe amended exact allowlist is now:\n- .github/workflows/ci.yml\n- ci/tests/test_workflows.py\n- core/tests/test_deployment_workflow.py\n- _docs/compatibility/development-terminology-allowlist.json\n\nThe fourth file may change only the matching core test entry’s sha256 field to the digest of the accepted test file. No other policy entries, application code, deployment logic, or AWS changes are authorized. Tester must verify the exact four-file diff and rerun the quality/CI contract envelope.

[alexeygrigorev]

PM technical acceptance — AMENDED FOLLOW-UP 2 ACCEPTED\n\nThe independent tester verified the four-file candidate from clean f5883b6.\n\n- Exact allowlist: .github/workflows/ci.yml, ci/tests/test_workflows.py, core/tests/test_deployment_workflow.py, and _docs/compatibility/development-terminology-allowlist.json.\n- The policy changes only the core deployment test whole-file SHA; expected_count remains 28 and all other entries are unchanged.\n- make terminology-check: passed.\n- Workflow contracts: 17 passed.\n- Deployment workflow contracts: 125 passed, 305 subtests passed.\n- make test-ci: 603 passed.\n- Ruff lint/format and mypy: passed.\n- The tester reproduced the cache identity invariant and confirmed no run_id/run_attempt key components.\n- No Playwright, commit, push, or engineer-worktree mutation occurred during testing.\n\nThe amended candidate is accepted. The engineer may commit exactly the policy-only change with Refs #222. This acceptance does not claim deployment success or issue closure.

[alexeygrigorev]

P0 release-lane audit — 2026-08-24

Issues #219, #220, #221, and #222 have their intended code merged and tester/PM technical gates recorded; no additional engineering is indicated. Their remaining gates are human/on-call deployment, populated-database migration, readiness, smoke, and exact live identity evidence.

The strongest current evidence is push run 32689634458 for origin/main ef24863: all CI verification gates passed, but auto-capture-prior stopped before mutation with service_pending_nonzero for web. Publish and deploy were skipped. The non-mutating OIDC/ECS probe 32690654995 passed, but it is not deployment evidence. Live still serves 20260821-062421-11b2bd1 and health/ready is 503 with database unavailable.

Next lifecycle action: resolve or explicitly authorize the bounded development recovery for the static DATABASE_URL/RDS readiness boundary tracked by #191, then rerun the normal exact-main release controller and collect the remaining human gates. Do not bypass capture or revive merged engineering candidates. No repository or AWS state was changed by this audit.