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
Org-level project board fed by this label and milestone taxonomy #97
Build an org-level GitHub Project fed by the label and milestone taxonomy this plan installs. Needs org admin access, which this tool does not have and should not be given.
Half of this shipped. The org board exists as project 9 and tools/apply_governance.py board reconciles Status from the label taxonomy, which landed in #104. The part still open is the "fed by" half, and it is worth naming precisely because it is not a missing feature so much as a token boundary.
apply_governance.py says it out loud:
it runs under a maintainer's own gh credentials rather than a token stored in the repository, because the board is organization-owned and a workflow's GITHUB_TOKEN cannot write to it.
That holds. None of the eleven workflows in .github/workflows/ contains an add-to-project action or a projectsV2 mutation, so nothing in CI touches the board. The board's own built-in workflows add an item, close it, and merge it, and cannot set a Status from a label, which is the gap the reconciler exists to fill.
The practical consequence showed up today. Eleven issues were filed in one batch (#142 through #149, #152, #153, #155). Every one carries status:needs-triage and every one maps to the Needs triage column under desired_board_status. None of them appears there, because nothing has run the reconciler since. A batch of issues is invisible on the primary view until a maintainer with the right local credentials remembers to run a script, and the people most likely to file a batch are the least likely to be watching for that.
Two things follow.
The credential requirement is also a friction point for the humans. Running the board step needs read:project and project on the maintainer's own token. A default gh auth login does not grant either, so the command fails with INSUFFICIENT_SCOPES for anyone who has not specifically refreshed for it. Worth putting in CONTRIBUTING.md next to the command rather than leaving each maintainer to discover it.
The original objection deserves a narrower answer than it got. This issue says the automation "needs org admin access, which this tool does not have and should not be given," and that is right about org admin. It is not the only option. A GitHub App installed on the org with organization_projects: write and nothing else can set a Status field without being able to touch repositories, members, settings, or anything else org admin implies. That is a much smaller grant than a classic PAT with project scope sitting in repository secrets, which is the option that genuinely should not be taken.
So the question is whether a scoped App is worth standing up, or whether running the reconciler stays a documented manual step on the weekly triage call. Either is defensible. What is not defensible is the current state, where it is a manual step that is not documented as one and that nobody is assigned.
Related: #144 covers three workstream leads whose write invitations are unaccepted, so they cannot apply the labels this board reconciles from. #145 covers the absence of a first-triage response target. All three are the same shape, which is governance that depends on a person remembering.
Correcting a sentence in my comment above, because it states the mechanism backwards and someone will read it.
I wrote that the board's built-in workflows "add an item, close it, and merge it, and cannot set a Status from a label." The reverse is true. Project 9 has six built-in workflows, and Item added to project is enabled, which is why all 58 items carried a Status and not one was blank. What the project does not have is any auto-add for this repository. The only add workflow present is Auto-add sub-issues to project, which fires on sub-issues.
The board sets Status correctly and never adds anything.
That is also the sharper version of the drift. The highest item on the board was #104, "Reconcile the project board from labels," merged 2026-09-10. Nothing created after it had ever been added: 40 open issues and pull requests, including every external conformance report and the whole accepted 0.1.3 set. A dry run of the reconciler put the split at 40 adds against 1 Status change, so adds were 97.5% of the problem and the Status machinery was working the whole time.
The reconciler has been run. The board is at 98 items, all statused.
Two things follow, and the first is free.
Enabling Auto-add to project on project 9, filtered to this repository, fixes the real-time path with no credential at all. Combined with the already-enabled Item added to project, every new issue and pull request lands in Needs triage the moment it opens. It cannot be done from code, since the GraphQL API exposes only deleteProjectV2Workflow and no mutation that creates or enables one, so it is a UI toggle somebody has to flip. It would have prevented 40 of the 41 drift events on its own.
The nightly safety net is #157. That covers what auto-add misses and corrects Status when labels move, and it uses the GitHub App that #104 named as the right long-term answer rather than the PAT that commit correctly refused. The grant, the environment restriction, and the residual risk are all written out there.
So the answer to this issue's original objection, that the automation "needs org admin access, which this tool does not have and should not be given," is that org admin was never the only option and the cheapest fix needs no token whatsoever.
Status, so this issue says what is left rather than what happened.
The board itself exists and is current: 98 items, every one with a Status, reconciler reporting zero pending actions. The nightly safety net merged as #157, and #158 fixes an ordering defect in it that only showed up under test.
Three things remain, none of which can be done from code.
Enable Auto-add to project on project 9, filtered to this repository. This is the one that actually prevents drift, it needs no credential, and it would have caught 40 of the 41 events this week on its own. The GraphQL API exposes only deleteProjectV2Workflow and nothing that creates or enables one, so it is a UI toggle.
Create the GitHub App on the organization with organization_projects: write plus read on this repository's issues and pull requests, installed on this repository only.
Create the board-automation environment with BOARD_APP_ID as a variable and BOARD_APP_PRIVATE_KEY as a secret, deployment branch rule limited to the default branch.
Until the second and third are done, the nightly workflow fails at the token step rather than doing anything quietly wrong. That is deliberate. An inert automation that reports failure is recoverable, and one that reports success while doing nothing is how this issue happened in the first place.
The first item is worth doing on its own even if the other two are declined.
Activity
rocklambros commentedon Sep 17, 2026
Half of this shipped. The org board exists as project 9 and
tools/apply_governance.py boardreconciles Status from the label taxonomy, which landed in #104. The part still open is the "fed by" half, and it is worth naming precisely because it is not a missing feature so much as a token boundary.apply_governance.pysays it out loud:That holds. None of the eleven workflows in
.github/workflows/contains anadd-to-projectaction or aprojectsV2mutation, so nothing in CI touches the board. The board's own built-in workflows add an item, close it, and merge it, and cannot set a Status from a label, which is the gap the reconciler exists to fill.The practical consequence showed up today. Eleven issues were filed in one batch (#142 through #149, #152, #153, #155). Every one carries
status:needs-triageand every one maps to the Needs triage column underdesired_board_status. None of them appears there, because nothing has run the reconciler since. A batch of issues is invisible on the primary view until a maintainer with the right local credentials remembers to run a script, and the people most likely to file a batch are the least likely to be watching for that.Two things follow.
The credential requirement is also a friction point for the humans. Running the board step needs
read:projectandprojecton the maintainer's own token. A defaultgh auth logindoes not grant either, so the command fails withINSUFFICIENT_SCOPESfor anyone who has not specifically refreshed for it. Worth putting inCONTRIBUTING.mdnext to the command rather than leaving each maintainer to discover it.The original objection deserves a narrower answer than it got. This issue says the automation "needs org admin access, which this tool does not have and should not be given," and that is right about org admin. It is not the only option. A GitHub App installed on the org with
organization_projects: writeand nothing else can set a Status field without being able to touch repositories, members, settings, or anything else org admin implies. That is a much smaller grant than a classic PAT withprojectscope sitting in repository secrets, which is the option that genuinely should not be taken.So the question is whether a scoped App is worth standing up, or whether running the reconciler stays a documented manual step on the weekly triage call. Either is defensible. What is not defensible is the current state, where it is a manual step that is not documented as one and that nobody is assigned.
Related: #144 covers three workstream leads whose write invitations are unaccepted, so they cannot apply the labels this board reconciles from. #145 covers the absence of a first-triage response target. All three are the same shape, which is governance that depends on a person remembering.
rocklambros commentedon Sep 17, 2026
Correcting a sentence in my comment above, because it states the mechanism backwards and someone will read it.
I wrote that the board's built-in workflows "add an item, close it, and merge it, and cannot set a Status from a label." The reverse is true. Project 9 has six built-in workflows, and
Item added to projectis enabled, which is why all 58 items carried a Status and not one was blank. What the project does not have is any auto-add for this repository. The only add workflow present isAuto-add sub-issues to project, which fires on sub-issues.The board sets Status correctly and never adds anything.
That is also the sharper version of the drift. The highest item on the board was #104, "Reconcile the project board from labels," merged 2026-09-10. Nothing created after it had ever been added: 40 open issues and pull requests, including every external conformance report and the whole accepted 0.1.3 set. A dry run of the reconciler put the split at 40 adds against 1 Status change, so adds were 97.5% of the problem and the Status machinery was working the whole time.
The reconciler has been run. The board is at 98 items, all statused.
Two things follow, and the first is free.
Enabling
Auto-add to projecton project 9, filtered to this repository, fixes the real-time path with no credential at all. Combined with the already-enabledItem added to project, every new issue and pull request lands in Needs triage the moment it opens. It cannot be done from code, since the GraphQL API exposes onlydeleteProjectV2Workflowand no mutation that creates or enables one, so it is a UI toggle somebody has to flip. It would have prevented 40 of the 41 drift events on its own.The nightly safety net is #157. That covers what auto-add misses and corrects Status when labels move, and it uses the GitHub App that #104 named as the right long-term answer rather than the PAT that commit correctly refused. The grant, the environment restriction, and the residual risk are all written out there.
So the answer to this issue's original objection, that the automation "needs org admin access, which this tool does not have and should not be given," is that org admin was never the only option and the cheapest fix needs no token whatsoever.
Reconcile the project board on a schedule, under a GitHub App (#157)
rocklambros commentedon Sep 17, 2026
Status, so this issue says what is left rather than what happened.
The board itself exists and is current: 98 items, every one with a Status, reconciler reporting zero pending actions. The nightly safety net merged as #157, and #158 fixes an ordering defect in it that only showed up under test.
Three things remain, none of which can be done from code.
Auto-add to projecton project 9, filtered to this repository. This is the one that actually prevents drift, it needs no credential, and it would have caught 40 of the 41 events this week on its own. The GraphQL API exposes onlydeleteProjectV2Workflowand nothing that creates or enables one, so it is a UI toggle.organization_projects: writeplus read on this repository's issues and pull requests, installed on this repository only.board-automationenvironment withBOARD_APP_IDas a variable andBOARD_APP_PRIVATE_KEYas a secret, deployment branch rule limited to the default branch.Until the second and third are done, the nightly workflow fails at the token step rather than doing anything quietly wrong. That is deliberate. An inert automation that reports failure is recoverable, and one that reports success while doing nothing is how this issue happened in the first place.
The first item is worth doing on its own even if the other two are declined.