Repository navigation
Make release recovery verify the existing App writer capability #787
Description
🤖 Generated by the Agentic Engineer
Problem and evidence
The first real Platform recovery dispatch passed its read-only incident admission and obtained the existing repository-scoped publication token, then the released publisher stopped before publication with writer credential has no proven push access to the repository. Run 40655034468 used the reviewed consumer and immutable v13.4.0 engine. A fresh release-by-tag read still returns 404, and the current latest release is unchanged. No blind retry or alternate writer was used.
The engine requires a literal permissions.push=true on the repository metadata response. That is not an independently established capability contract for the installation token used by its own consumer. The workflow's scoped token-creation request succeeded; its existing App and grants should be retained.
GitHub documents that installation-token access depends on App permissions, and that the release-notes preview endpoint requires Contents write permission while saving no generated content. Evaluate a supported positive capability proof instead of treating missing or user-oriented metadata as authorization. A successful read alone must never authorize publication or establish complete draft visibility.
Acceptance criteria
- Reproduce the installation-shaped metadata refusal with the real publisher and a stateful API fixture; preserve the real dispatch failure as adoption evidence.
- Prove effective authority for the exact repository before accepting a complete release/draft inventory or sending a release-creation request. Add positive and negative controls for the supported proof, denied permission, unavailable/malformed responses, wrong identity and no publication on refusal.
- Preserve read-before-writer admission, complete independent inventories, exact existing tag/source/producer checks, deterministic recovery receipt, unchanged latest release, one bounded publication request, unknown-outcome reconciliation and idempotency. Do not expand App grants, add another App, move tags, use an alternate credential or silently accept unknown authorization.
- Pass complete local and native checks, substantive exact-head review and protected merge; verify the released fix and update the consumer to its immutable source through its own protected change.
- Re-run the real controls and both captured recoveries with the existing scoped App, verify independent publication and no-op readback, and record any remaining historical root-cause uncertainty separately.
High priority, Medium effort, Risk reduction. This is a focused recovery blocker for Platform #4839 and the rollout in #603. Original incident acceptance criteria remain unchanged.
Primary sources: GitHub App permissions, release-notes preview.
Shared-engine stage verified: v14.0.2; evidence: #787 (comment)
Verified delivery — 29 October 2026
Both captured releases are published and independently verified; both explicit reruns skip the writer and publication step. Native control and exact source receipts are recorded in the completion comment. Historical root-cause uncertainty and temporary flag lifecycle remain separately tracked.
Activity
chore: agent-claim #787 nonce=0fc3a208cf6a4d224d35fa582b4db7fa
fix: prove release recovery writer capability through GitHub (#788)
devantler commentedon Oct 28, 2026
The shared-engine stage is delivered in PR #788, signed merge
0b137510d139bbf62e479d9610b0db17c972bc2b, and v14.0.2. The version tag points directly to that merge, and all five exact-source default-branch workflows, including native CI and publication, completed successfully.The before/after stateful HTTP regressions, complete inspector/publisher suites, race tests, vet and native review passed. CodeRabbit reviewed the exact delivered head without findings. No App grant or existing recovery safeguard changed.
The Platform consumer is now being updated to this released source, with a native read-only permission refusal control before requesting the writer. The last two acceptance criteria remain open: the protected consumer update, real App-backed controls, both recoveries and no-op readback. Historical Git-ref cause uncertainty remains separate. This issue is not complete or counted as a resolution.
chore: agent-claim #787 nonce=44c52d9c54ecc3442256687aaddd77d8
chore: agent-claim #787 nonce=2f1c87e5d7b0814a08b34bffbc3ce661
chore: agent-claim #787 nonce=006c4ecf6e3059ed9ab1151f00c6d657
devantler commentedon Oct 29, 2026
Completed native consumer verification after protected Platform #5523 merged at signed
af57d1b87fa50972265c66fce7cb9fa3b42f5ee2, adopting immutable .github v14.0.5 (8e2dfbd3f9249b76b58234189ccbbae98d11b32b). The earlier shared implementation, release and review evidence is retained above.Both real publications passed the existing read-only permission-refusal control before obtaining the approved writer, and the publisher independently verified the release, tag/source and complete inventory. Both reruns skipped the writer credential and publication step. Independent authenticated reads matched each deterministic recovery receipt and the unchanged original tag/source.
The second publisher reports exactly one publication request and identical latest-release IDs before/after recovery. Normal delivery subsequently published v1.281.4 after the recovery step completed; that later advancement is recorded separately. No App, grant, alternate credential or tag changed. Original generated notes were not reconstructed, and the historical Git-ref rejection cause remains UNKNOWN under Platform #4839. Temporary flag lifecycle stays open under #603. All five criteria of this focused capability defect are now satisfied.