Repository navigation
Prepare v7.16.2 publisher acceptance before the caller update #5092
Description
🤖 Generated by the Agentic Engineer
Objective
Prepare and deploy acceptance of the v7.16.2 manifest publisher before the caller update merges, so configuration releases remain verifiable.
Details
The caller currently uses e1681322e671f8e277c5e230a57fe66cdf1a612d and proposes 8d2203af130a8c27b8b98b3d7146f76b5ade7a98. The current fixed approval and configuration-source matcher accept only the former canonical revision. The documented two-revision transition requires the new fixed approval, regenerated matcher and production authorization record to deploy first.
Independent source review found the publisher workflow byte-identical (SHA-256 2858f387b7b7587d871940af0ac26ff88e6a73c6242e39e38f8e9919b601ca1e). The complete comparison lists no change to its immutable publication/recovery helpers. This preserves the existing immutable caller, signing, claim verification and promotion controls; matching source bytes alone does not preserve certificate identity.
Checklist
- Add exactly the proposed immutable revision alongside the current canonical approval for this consumer; preserve all other consumers and legacy compatibility evidence.
- Regenerate the matcher through its writer and record the reviewed production authorization change.
- Prove the old and new exact identities match while unrelated revisions, repositories and issuers fail; pass affected regressions and required CI/review.
- Merge through the normal queue and independently verify deployed acceptance of both identities before the caller update merges.
- Retain the old approval until the first real publication under the new identity verifies and reconciles; track its later removal separately.
Dependencies
This is the missing prerequisite of devantler-tech/.github#649, identified by its current-head P1 review. It is a mechanical dependency migration, not a new product feature. Historical platform#4894 concerns a different, older publisher target.
Notes
Small implementation; deployment and publication acceptance determine completion. Keep this issue open if only source preparation has landed.
Delivered on: 2026-10-19
Blocker: publisher-acceptance-readback | outcome | last-verified 2026-10-19: The reviewed transition merged and passed protected production delivery, but independent current-generation acceptance readback is pending. Resume when the verification environment satisfies its safety preflight, or the delivered interactive read-only exception is approved. Verify both exact identities before .github#649 merges; retain this issue through the first real replacement publication.
Metadata
Metadata
Assignees
Type
Fields
Priority
Projects
- Status
Activity
chore: agent-claim #5092 nonce=e92d41ae8178c0d3652d01e0d201efba
chore: agent-claim #5092 nonce=a2255ae268be52ec9e0794d4e1783f1f
chore: agent-claim #5092 nonce=76edf425bc73c7df6f85719f238075ba
chore: agent-claim #5092 nonce=a8ab7a0321bea1e65d8c9c47942c07d3
chore: agent-claim #5092 nonce=b2eaf7535c9e50df85a75346e86a0557
chore: agent-claim #5092 nonce=9cdc723a729bdc08bffa289fcc34fdaf
devantler commentedon Oct 19, 2026
Platform #5093 merged at 2026-10-19 14:49:56 UTC. Reviewed source
9237f6b59d2c7e9bd005aeb2f28b8714918666fflanded as5ed390fa8f3a5296b74d8c254d3ff669fea46890through the normal protected queue.The exact landed-head CI completed all 22 native jobs: selected checks, production deployment, required aggregate and queue receipt succeeded; PR-only paths were intentionally skipped. Required feedback was 28m19, including 16m16 deployment; summed job occupancy was 53m49, not billed cost. All observed post-merge main checks also completed successfully. Platform v1.235.1 resolves to that landed commit.
This completes source preparation, regeneration, exact-identity regressions, review and protected delivery. It does not independently prove the live verifier now accepts both signing identities, nor a first publication by the replacement caller. The remaining check cannot run in this session's current verification environment; the narrowly scoped read-only exception has been asked interactively and is awaiting a reply.
Returning this merged continuation to Ready with its resume condition rather than parking it in Verifying. Next: independently read the deployed verification specification and current-generation Ready result; then clear the current-head P1 on .github #649, obtain its qualifying review and drive it to merge. Do not wait for this issue to close before reviewing that caller: the final publication criterion necessarily follows the caller update. Keep the old signer until the first genuine replacement publication verifies and reconciles; do not manufacture a release solely to tick this checkbox.
devantler commentedon Oct 19, 2026
Live acceptance readback — 2026-10-19 15:30 UTC
I read the deployed configuration source in production directly (read-only).
mainafter #5093. For this consumer it accepts exactly two publisher revisions: the currente1681322e671f8e277c5e230a57fe66cdf1a612dand the replacement8d2203af130a8c27b8b98b3d7146f76b5ade7a98. The issuer is still pinned to GitHub Actions only, and nothing wider was added.Ready,SourceVerifiedandArtifactInStorageas true, serving the signed release7.17.0.mainholds both revisions for.github'spublish-manifests, and only those two.What this does not prove: that a real publication signed by the replacement revision verifies. That can only happen after the caller update (.github#649) merges and a release goes out. The last checklist item stays open for that, and the old approval stays until then.
So the condition the caller update was waiting for, a deployed acceptance of both exact identities, now holds. I am resuming .github#649.
devantler commentedon Oct 19, 2026
The caller update .github#649 merged at 15:28 UTC at the reviewed head
3868e643b9b9ab131ca17801b528bdd1b07351f9(merge commit576414b858b958890e31e7617c42987688017c46). From now on, configuration releases from.githubare signed by the replacement publisher revision8d2203af….Remaining: the last checklist item. The next real
.githubconfiguration release must verify and reconcile in production under the new identity. After that, removing the old approval gets its own tracked change. No release will be cut just to tick this box. The next run that sees a newgithub-configrelease reads backSourceVerifiedand the served revision.