feat(binjovi): seed ex-mcp management grant and authority readback #680
Loading…
Reference in a new issue
No description provided.
Delete branch "feat/ex-mcp-authority"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Why
Two grants the bindings change missed. Both surfaced by watching the live bootstrap fail, not by reading the tree — neither is visible from the binding lists.
The management grant
binjovi-operator-botis a non-admin Forgejo user, andCollaboratorClient.repository_access/2refuses any repository whosepermissions.adminis not true. So it cannot grant itself the access it needs.Every
ex-mcpservice operation sat atdenied, attempt 5, while the identical operations onbyteysucceeded — because bytey already carries both bots:management-grants-repositories.txtis the mechanism. Its JobPUTsbinjovi-operator-botonto each listed repository with the admin token, and its guard states the rule: "every cold-rebuild seed needs its management grant before Binjovi can adopt it." 40 → 41 entries.Flux may not make that grant instead.
tests/binjovi-collaborator-handoff.shforbids aForgejoCollaboratorCR forbinjovi-botorbinjovi-operator-botinforgejo-usersorgitmirrors. I wrote those CRs first; the guard rejected them and was right to.The authority readback
binjovi-provider-authorityinexecution-platform.yamlgainsex-mcp-main,ex-mcp-trunk,ex-mcp-tags.It is a different Role from
binjovi-service-legacy— the pre-release authority check, not the absence check — and both bind the same ServiceAccount. That is exactly why granting one looked sufficient and was not. Worth knowing for the next onboarding.Known blocker — not introduced here
The grant Job cannot run today, so this change does not by itself grant
ex-mcpanything.Its image
registry.sean.farm/someara/pipeline-tools:v8is pinned by digest, which pins a single architecture rather than a manifest list — and all six nodes are nowarm64. ThebinfmtDaemonSet that would emulate it isnodeSelector: kubernetes.io/arch=amd64with 0 desired, because no amd64 node remains.buildkit-fleet-retirein nsargocddies on the same image the same way. This is a live fault affecting more than this work and it is not mine to fix.Two consequences worth stating plainly:
-v2suffix must move once the image works.Verification
Full
tests/check.shgreen. The bootstrap guard moves 40 → 41 and now assertsex-mcpby name.https://claude.ai/code/session_01XdBRc9CHgFhAxCyHbdVtt6