chore(bootstrap): pin a7cb962f8920 and re-record digests - #86
Merged
Conversation
By hand, because the `pin` job could not do it. Its brokered App token minted
and passed the `pull_requests: write` assertion, then 403'd one step later on
the push:
remote: Permission to bounded-systems/.github.git denied to
bounded-systems-front-desk[bot]
fatal: ... The requested URL returned error: 403
So the App installation is missing `contents: write` on this repo. The job
asserts the scope it needs to OPEN the PR but not the one it needs to PUSH the
branch, which is why this surfaced as a raw 403 rather than the named error the
step was written to produce. Filed separately; this commit just gets main green.
Also corrects a comment in the canonical bootstrap text that #84 disproved: the
setup script's `register-mcp.mjs` call is no longer the only one that can work,
so "this must happen here, not in the dispatcher" is wrong. It is still the one
ordered before launch, which is the reason to keep it — so the comment now says
that instead.
This was referenced Aug 3, 2026
bdelanghe
added a commit
that referenced
this pull request
Aug 3, 2026
Two changes, one cause (#87). 1. Point at `front-desk-pin`, not `front-desk`. The fan-in entry carries no `contents`, so it could never push the bump branch, and it cannot be given any: it is deliberately unpinned and `contents` is privileged, so the broker would refuse the entry outright and take every other consumer with it. The separate pinned entry is bounded-systems/infra#172. 2. Do not use the token when the mint step FAILED. `require: contents, pull_requests` (#93) worked exactly as designed on the merge of #97 — it reported `contents(granted: absent)` and named both places the gap could live. Then `continue-on-error: true` swallowed the verdict, the job used the token anyway, and died on the very push the assertion had just said would fail. An assertion whose verdict nothing consumes is decoration. The fallback is not a downgrade: github.token holds contents:write here and pushed this branch fine before the broker was wired in (#79). So on a scope gap the branch now LANDS with the correct pin and only opening the PR is lost — a click, versus the full hand-regenerate it costs today (#79, #86, #89, #98). A third annotation separates "broker reachable, scopes insufficient" from "broker unreachable", since the two are fixed in different systems.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The bump #84 needs, done by hand because the
pinjob could not do it.mainis currently red onschema:bootstrap-pin.test.mjsassertsFRESHNESSon push, and the pin still namese7126e4c274d, which predates #84's changes tosession-start-dispatch.mjsandregister-mcp.mjs. Any session without.githubattached is being served the pre-#84 files from the fallback path. This is the designed hand-off —PINcannot name a merge commit before that commit exists — it just did not complete.Why the automation did not do it
The
pinjob minted its brokered App token and passed thepull_requests: writeassertion, then failed one step later on the push:The installation is missing
contents: writeon this repo. Note the job asserts the scope it needs to open the PR but not the one it needs to push the branch — so this surfaced as a bare 403 at exit 128, and none of the named::errorannotations below it ran. That is the same argument the assertion step's own comment makes aboutgh pr create, one step earlier in the sequence. Filed as a follow-up; this PR does not touch the workflow.Contents
PIN→a7cb962f8920(the merge commit of session-start: register MCP servers from the dispatcher when the setup script did not #84), withSUM_session_start_dispatch_mjsandSUM_register_mcp_mjsre-recorded.SUM_stop_hook_git_check_shis unchanged, as expected — session-start: register MCP servers from the dispatcher when the setup script did not #84 did not touch that file.node .claude/gen-bootstrap-pin.mjs a7cb962f89203920f94d8d8ffad697830f1324e2, not hand-edited.Verification
107 tests pass with
GITHUB_EVENT_NAME=push, which is the setting that assertsFRESHNESS— i.e. checked under the condition that is currently failing on main, not just the PR-mode one.Generated by Claude Code