You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Add the default-off release-recovery publication workflow #717
Once the publisher command exists, operators still need a reviewed, default-off way to run it in the affected repository without rerunning release plugins or widening credentials (#602).
Smallest useful change
Add a default-off reusable recovery workflow that calls the publisher command:
It runs only in the affected public repository on its default branch, sharing the normal release concurrency group.
It builds the publisher from immutable catalogue code before any credential is issued.
It admits the incident with a one-repository read token. It stops as a verified no-op when the publication already exists, before any writer token is minted.
Only then does it mint a token with Contents(write) and Actions(read) for that one repository.
It keeps a permanent, explicit operator confirmation separate from the temporary rollout flag. Production publication is manual-dispatch only.
Acceptance criteria
Default-off and explicit enabled/offline CI calls run without production credentials. Every reusable caller is covered by the required aggregate.
Workflow-authority guards cover scoped permissions, immutable source and the order of read token before writer token, with negative controls.
Operator documentation is written, reviewed, merged and released.
A point to settle in this slice, carried over from the publisher's review (#718).
The publisher proves write access by reading permissions.push from the repository response with its own credential, and it refuses when that field is absent. The offline controls cannot answer two questions:
Does the scoped App installation token's repository read include that field? If it does not, every run is refused.
Is the field the token's capability, or only the owner's role? For a user-owned fine-grained token, push reflects the user's role, not the token's scope. That is why only the scoped App token should ever be passed.
The workflow's acceptance should include one native observation of the field under the minted Contents(write) and Actions(read) token. The observation reads only; it publishes nothing.
Activity
devantler commentedon Oct 22, 2026
A point to settle in this slice, carried over from the publisher's review (#718).
The publisher proves write access by reading
permissions.pushfrom the repository response with its own credential, and it refuses when that field is absent. The offline controls cannot answer two questions:pushreflects the user's role, not the token's scope. That is why only the scoped App token should ever be passed.The workflow's acceptance should include one native observation of the field under the minted Contents(write) and Actions(read) token. The observation reads only; it publishes nothing.
feat(release): add the default-off release-recovery workflow (#720)