Development record
The attribution gate should let a dependabot dependency bump through without a human re-authoring it. The product thinker asked for this on 2026-09-22 after PR 655 sat blocked with auto-merge armed and every other check green. Two things must be said precisely, because the request names the trailer and the trailer is not what fails. The gate refuses a bot on IDENTITY: check_ident reads dependabot[bot] as a machine in the author role on two independent signals, the forge's [bot] name suffix and the bot mailbox, and it deliberately stays silent about the missing Assisted-by trailer so the remedy is not misread, its own comment saying that adding a trailer is not the fix for a dependency bump and landing it as a human is. No review clears an identity refusal, which is why an armed auto-merge looks like it is waiting for a reviewer when it is waiting for something no reviewer can give. The rule is deliberate and stated in AGENTS.md: the contributor graph is built from the author and committer fields, a machine there asserts an authorship it does not hold, and a squash merge re-appends a mis-identified branch author as a co-author, so the consequence, that a dependabot pull request is not mergeable as authored, is written down as intended. Wanted: a way for a dependency bump to land without a person re-authoring it every time, without letting a machine into the contributor graph on any other change. Candidate shapes for the decision to weigh: the gate exempts a commit whose diff touches only go.mod and go.sum on a branch the forge marks as dependabot's, with the exemption named in the refusal it would otherwise raise; or the repository takes dependabot's bumps through a workflow that re-authors them as the human owner before the gate runs, so nothing about the gate changes; or dependabot is turned off for this repository and bumps are made by hand on a schedule. This reverses a stated rule, so it is an ADR plus a brief invariant before any code moves, not a quiet edit to the script.
The attribution gate should let a dependabot dependency bump through without a human re-authoring it. The product thinker asked for this on 2026-09-22 after PR 655 sat blocked with auto-merge armed and every other check green. Two things must be said precisely, because the request names the trailer and the trailer is not what fails. The gate refuses a bot on IDENTITY: check_ident reads dependabot[bot] as a machine in the author role on two independent signals, the forge's [bot] name suffix and the bot mailbox, and it deliberately stays silent about the missing Assisted-by trailer so the remedy is not misread, its own comment saying that adding a trailer is not the fix for a dependency bump and landing it as a human is. No review clears an identity refusal, which is why an armed auto-merge looks like it is waiting for a reviewer when it is waiting for something no reviewer can give. The rule is deliberate and stated in AGENTS.md: the contributor graph is built from the author and committer fields, a machine there asserts an authorship it does not hold, and a squash merge re-appends a mis-identified branch author as a co-author, so the consequence, that a dependabot pull request is not mergeable as authored, is written down as intended. Wanted: a way for a dependency bump to land without a person re-authoring it every time, without letting a machine into the contributor graph on any other change. Candidate shapes for the decision to weigh: the gate exempts a commit whose diff touches only go.mod and go.sum on a branch the forge marks as dependabot's, with the exemption named in the refusal it would otherwise raise; or the repository takes dependabot's bumps through a workflow that re-authors them as the human owner before the gate runs, so nothing about the gate changes; or dependabot is turned off for this repository and bumps are made by hand on a schedule. This reverses a stated rule, so it is an ADR plus a brief invariant before any code moves, not a quiet edit to the script.
Ruling
- 2026-09-22, the product thinker: route 2 of the three shapes above. A workflow re-authors a bot-opened bump as the repository owner BEFORE the gate runs; the gate itself does not change. The bound is the diff's shape (an ecosystem's manifest and its lock file, on a branch the forge marks as that bot's) and it covers every ecosystem dependabot opens, not Go alone. The re-authored message names the bot and the workflow and carries
Assisted-by: None. It is scaffolded into a managed repository by the same verb that writes its release workflows, opt-in per repository. Named rather than assumed: a workflow asserts the owner's authorship with no person in the loop, which the owner accepts once in the configuration under that bound. Planned as itd-2609221842494980.
Frontmatter
| id | iss-2609221820487644 |
|---|---|
| type | issue |
| lifecycle | open |
| severity | minor |
.abcd/work/issues/open/iss-2609221820487644-the-attribution-gate-should-let-a.md
open on GitHub ↗ · commit history ↗
Referenced by1
- itd-2609221842494980A dependency bump lands without a person re-authoring it, and no machine enters the contributor graphrelated
mentions3
- adr-2609292116133348A dependency bump inside the bound is re-authored as the owner and only pushed by an App
- iss-2609292030070275The dependency-bump re-authoring (itd-2609221842494980, spc-2609221843355061) has never run against the live forge, so its first acceptance criterion is proven only offline, against a stand-in App API and a local remote. The person's steps are owed: create a GitHub App with Contents read and write, install it on this repository, store its id and private key as the Dependabot secrets DEPENDENCY_REAUTHOR_APP_ID and DEPENDENCY_REAUTHOR_APP_KEY, and set owner_name and owner_email in .abcd/config/dependency-reauthor.conf. Until then every in-bound bump is refused by name and stays a person's to land. Done when one real dependabot go_modules or pip bump is watched re-authored as the owner, re-checked green by the attribution gate and merged; then the spec closes and the intent ships (Refs: iss-2609221820487644).
- iss-2610241550026188record_schema resolves a cross-reference field's target in any record family (internal/core/lint/schema.go:764 checks only that the handle is in the corpus), so itd-2609221842494980 carries related_adrs: [iss-2609221820487644], an issue, and passes record-lint, although the ADR README documents related_adrs as adr-N only; because the link sits in the wrong field, the promote join between that shipped intent and its still-open originating issue is invisible to intent audit --issue-drift.