Close V28 gate 13 promotion readiness#18
Conversation
Add the Gate 13 product-closure readiness check, wire it into gate and promotion workflows, and expand the V28 promotion dry-run command plan. Align the full protocol demonstration proof suite with the current proof catalog and active-canon posture, including the deposit-to-read-fit enum and superseded V26 readiness assertions. Harden staging-testnet readback validation with bounded DB audits, Data API evidence, updated QA/spec notes, and verifier coverage for the single-client DB path.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 5c6108fb8e
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| --runInBand | ||
|
|
||
| - name: Test pipeline readback verifier | ||
| run: pnpm test:qa:v28:pipeline-readback |
There was a problem hiding this comment.
Remove duplicate readback verifier run in gate-quality
This step reruns pnpm test:qa:v28:pipeline-readback even though Validate draft canon posture already calls promote-bitcode-canon --dry-run, and the V28 dry-run plan now includes the same command (scripts/promote-bitcode-canon.mjs, V28 command plan). On V27 draft branches this duplicates a network-sensitive check in one workflow run, increasing CI time and flake exposure enough to block gate closures.
Useful? React with 👍 / 👎.
| echo "Unexpected BITCODE_SPEC.txt pointer: $POINTER" >&2 | ||
| exit 1 | ||
| fi | ||
| pnpm test:qa:v28:pipeline-readback |
There was a problem hiding this comment.
Avoid duplicate readback verifier in promotion workflow
When BITCODE_SPEC.txt is V27, this job already executes node scripts/promote-bitcode-canon.mjs --version V28 --commit HEAD --dry-run, and the updated V28 dry-run plan includes pnpm test:qa:v28:pipeline-readback; running it again here duplicates the same external-readiness check in a single PR validation pass. This adds avoidable runtime and flakiness risk on the main promotion path (version/v28 -> main).
Useful? React with 👍 / 👎.
Summary
Validation