Development record
A self-attested result is labelled as such, and only the person switches it on, by an act abcd's own verbs refuse to its agents
Context
A private repository pays hosted CI by the minute, and abcd's agents land work often, so re-running in hosted CI the gates the person's machine has just run is the largest avoidable cost a solo maintainer meets (itd-2611011325403127 measures it). The cheap alternative, posting the local result to the forge, is exactly what the forge cannot check: any person or integration with write access can set any commit status (GitHub's protected-branch documentation), artifact attestations are produced only inside GitHub Actions (and need Enterprise Cloud for a private repository), and SLSA v1.2 places a build run on the developer's own machine at Build L0, its provenance at L1 "trivial to bypass or forge". The agents run as the person's own account: the interactive guard does not protect the person's machine configuration from an agent's writes, and the agents' forge login holds admin rights (iss-2610170725144804). One ruling stands and one is proposed: no receipt minted in the cloud is trusted (adr-2610120937435856, accepted), and the person alone grants autonomy (adr-2610240850193281, proposed).
Decision
We will let a repository's local gates be reported to the forge only as a self-attestation, labelled as such, and only when the person has switched it on by an act abcd's own verbs refuse to its agents; it stands in for a hosted run only once it is posted by an identity the agents cannot use, which is open until the planning interview rules on it. The posted result carries a name of its own that says it is self-attested (never the name an independent check reports under) and a description saying it ran on the person's machine and was not independently verified. The switch is set with the person present, by a touch of a security key or a fingerprint on a key the agents' processes cannot use without it, and is recorded on the person's machine; no verb abcd offers an agent turns it on; but agents run as the person's own account, so an agent with write access to abcd's own code or to the recorded grant could defeat the switch itself, and the switch therefore bounds abcd's own landing, not such an agent. It is offered only where the conditions hold: a private repository, one maintainer, a person as technical facilitator, and changes by the person or their agents; a change from anyone else always gets the full independent check. Wherever abcd reports a landing, a self-attested one is shown as such.
Alternatives Considered
- Labelled self-attestation behind a switch only the person can set, by an act abcd's own verbs refuse to its agents (chosen). Honest because the label says what the result is, and safe enough because the switch needs the person present. Its residual, stated plainly: posted from the person's token, the status can be posted by any agent holding that token without touching the switch at all, so the switch bounds abcd's own landing, not the forge; the label stays truthful about what kind of result it is, but it asserts that the local gates passed, which a forged post makes false. Until an identity the agents cannot use posts it (open question 1 of itd-2611011325428560), it is a label beside the hosted run, never a required check that replaces it.
- A plain commit status from the person's token (gh-signoff's pattern). The cheapest, but the agents hold the same token, so the status is the agent's word, and it would reopen the required-check pinning of iss-2610290913450522. Rejected.
- Cryptographic attestation the forge verifies. GitHub verifies no locally produced test evidence; artifact attestations need Actions. Not available, so not an option today.
- No self-attestation at all; always run hosted CI. Honest and simple, and stays the default; rejected as the only choice because its cost makes abcd unaffordable for a solo private repository.
Consequences
- A solo maintainer of a private repository can land with no hosted run, knowingly, once the self-attested result is posted by an identity the agents cannot use; until then it is a label beside the hosted run.
- abcd must guard the switch as far as an account it shares with its agents allows: the grant needs the person's touch, and since an agent with write access to the grant record or to abcd's code could still defeat it, the record says so wherever it shows a self-attested landing.
- Every landing report distinguishes self-attested landings from independently checked ones, so the product thinker can see what no independent check examined.
- The independent checker of itd-2611011325430933 is the upgrade path: the same person can move from self-attestation to a check no agent can fake without changing how they land.
Frontmatter
| id | adr-2611011327164895 |
|---|---|
| type | adr |
| status | proposed |
| date | 2026-11-01 |
.abcd/development/decisions/adrs/2611011327164895-a-self-attested-result-is-labelled-as.md
open on GitHub ↗ · commit history ↗
References4
- adr-2610120937435856A cloud session's unchecked work goes only to a declared work-in-progress prefix that never reaches the default branchrelated
- adr-2610240850193281A human-set autonomy grant permits, separately from the agent-written waiting-on badgerelated
- itd-2610261025516272Private repos land checked work without renting CIrelated
- itd-2611011325428560A solo private repo can self-attest its gates, labelled sorelated
mentions4
- iss-2610170725144804The live-reservation cap is fixed at ten per person (claim.MaxLive in internal/core/claim/crowd.go), counted by username across every session, laptop and cloud copy. A project with one maintainer running many parallel sessions under one GitHub identity hits it with no one else to protect: on 2026-10-17 all ten were held by the maintainer's own sessions, mostly finished work waiting to merge, and a new reserve was refused. The cap is right for abcd once several people share a project, but the maintainer cannot raise or lift it today.
- iss-2610290913450522The settings baseline requires each status check from any source. GitHub lets any person or integration with write access set the state of any status check, and the statuses API lets a push-access token post any context, so a required check left on any source can be set to passing by someone other than the workflow that runs it. Choosing the app as the source refuses a status set by anyone else. Assessed against the abcd-fixes-what-it-adds principle: the route exists without abcd (it is GitHub's default for any required check), and abcd's apply adds no weaker state, since without it the repository requires no check at all; pinning is a tightening of a setting abcd itself writes, applied only on the person's yes, and changes nothing else about how the repository works. No released abcd has ever applied a required check: the apply that writes one ships for the first time in the change itd-2610290746077716 delivers, so abcd has put no managed repository in this state.
- itd-2611011325403127Every landing shows what it cost and the next run's estimate
- itd-2611011325430933A machine the person owns checks agents' work independently