ADR-030: The current holder of an in-flight intent is cycle state, not history
| Status | Accepted |
| Date | 2026-08-02 |
| Author | bodurkalukasz |
Context
ADR-010 put work history in the tracker and kept it out of the repo, and the reasoning holds: a repo that also maintains state transitions, timestamps and assignment logs becomes a bad tracker competing with a good one. cycle-open states the consequence plainly - do not assign people; the row's owner is a role.
Two things have since made that line, as written, unworkable.
The adoption intake offers in-repo tracking. A team that answers "we track work here" has no tracker, so "it lives in the tracker" names a place that does not exist for them. The rule silently assumed an answer the intake explicitly allows them not to give.
A cycle without a holder is not a commitment. owner is a role - dev, product, architect. A cycle whose rows all say dev records that developers will do some development, which is not information. The question a person actually asks of an open cycle - who has this one - has no answer anywhere in the repo, and answering it in a meeting is the state cycles were meant to replace.
Options considered
- A - Hold the line; assignment only in a tracker. Consistent with ADR-010 as written. Rejected: it fails outright for in-repo teams, and it leaves the most-asked question about an open cycle unanswerable in the repo that claims to describe the work.
- B - Full per-item execution state in the repo - assignment, transitions, timestamps, time spent. Rejected, and this is the thing ADR-010 was right about: it rebuilds a tracker badly, and the repo starts losing to the tool teams already have.
- C - The current holder only, on cycle rows, archived with the cycle. Chosen. One field, present tense, bounded lifetime.
Decision
assignee names the person currently holding an in-flight intent, on cycle rows only.
The boundary against ADR-010 is tense, and it is what keeps this from being option B:
- The pool has no assignee - an item nobody has picked up is not yet anyone's, and a pool that assigns work has become a queue of orders.
- A cycle row carries exactly one current holder. Not a list of who touched it, not when it changed hands, not how long each held it. Reassignment overwrites; the previous holder is not recorded, because that is history and history is ADR-010's.
- When the cycle closes, the file is archived as written. It is a record of what that cycle looked like, not a queryable log - nothing reads assignees across cycles, and no skill aggregates them.
ADR-010 is narrowed, not superseded: work history still lives in the tracker. What moves into the repo is one field of present state, with no accumulation.
Consequences
- An open cycle answers "who has this" without a meeting or a second tool.
- In-repo teams get a coherent story instead of a pointer to a tracker they chose not to have.
- The cost, and it is deliberate: who used to hold an item is unrecoverable from the repo. A team that needs that needs a tracker, and this standard will keep saying so.
- A second cost: an assignee left stale after someone changes teams looks authoritative and is wrong. Nothing detects this - see below.
- Per-person throughput is not derivable and is not meant to be. A field that could be aggregated into individual velocity would be, and that is a measurement this standard declines to make (see ADR-029 for the same reasoning applied to sizes).
Confirmation
Review, not a script, and the gap is worth stating. cycle-guard checks that an intent lives in exactly one place and that blocks point at something real; it does not and cannot check that an assignee is a real person, is still on the team, or is current. A guard that tried would need a roster the standard does not have and would go stale faster than the field it was checking.
What is mechanical: cycle-close reports rows whose status did not change during the cycle, which surfaces an abandoned item - the usual symptom of a stale assignee - without claiming to detect the cause.
Revisit when
A team reports that they wanted the previous holders after all - which would mean the archived-as-written rule is too thin and the boundary has been drawn in the wrong place. That is the observation that reopens this; a general preference for more tracking is not.