This is the record of an abcd-managed repository

abcdBetav0.16.2 · 2026-11-06

Development record

Now, Next and Later list an intent in a lane under Now only; phases stay retired

adracceptedadr-2609292012006845

Context

adr-2609212115255771 (2026-09-21) retired phases, milestones and the word roadmap, and its decision 2 defined the rendered Now / Next / Later block: "Next is every planned intent the gate reports READY; Later is the rest of planned and the drafts". The block shipped as itd-2609212103568351, and an intent the build had in a lane then appeared twice: under Now with its lane state, and again under Next (or Later) where the gate placed it.

On 2026-09-29 the product thinker ruled (decision dcn-2609290000000007 landing with lane recRulings) that an intent in progress appears only under Now, never also under Next or Later (BV2), and that the text board shows Later as a count while the site and --json keep the full list (BV1). BV2 makes decision 2's text false. The same day's ruling H10 settles how such a change is recorded: an issue names it (iss-2609292011569133), the shipped intent gains an Audit Notes line, and an ADR whose decision text is now false is superseded rather than amended in place. This record is that successor. It changes decision 2 only; every other decision stands as adr-2609212115255771 stated it, and is carried here so the record in force states the whole decision.

Decision

We retire the phase and the milestone as units of the record, and the word roadmap with them. Decisions 1 and 3 to 8 are adr-2609212115255771's, carried forward word for word; decision 2 is revised.

  1. Sequencing is dependencies plus the shelves. blocked_by and builds_on on the records (itd-78 derives a priority from them; the pick in abcd build next filters on them) and the lifecycle shelves drafts/ → planned/ → shipped/ carry the order. No stored unit sits above the intent for sequence.
  2. Now / Next / Later is a rendered status, never stored. The bare abcd board and the site's Status page compute it: Now is every intent in a lane (from the build's state file) plus the head of the pick order; Next is every planned intent the gate reports READY that is not in a lane; Later is the rest of planned and the drafts, again leaving out an intent in a lane. An intent in a lane is listed under Now only (BV2). The text board gives Later as a count, and the JSON and the Status page list its rows (BV1). A started state comes from the state file and is rendered (itd-2609212103568351). Nothing is called a roadmap.
  3. The checkpoint is the derived release plus each intent's acceptance criteria. No planned end condition exists apart from them. An intent may carry an optional target_release: that the cut reports and moves forward, never refuses on (itd-2609212103572513); that field is the one forward-looking line the derived release keeps.
  4. The unit below a spec is the step: an ordered ## Steps section in the spec, each step landable as one lane and one pull request; a spec with no steps is one step; the loop's implement step and the section share the word (itd-2609212103565953). No fourth record family.
  5. Two axes, kept apart. The lifecycle (what has been decided about a record) lives in the folders and gates; the position (how soon) is rendered from it. planned/ is not renamed Now, because sixty planned intents are not all being worked on and the word would lie.
  6. Issues carry no spec by design. An issue's design record is its remedy: field and the failing test its lane writes first; an issue that needs design is an intent in disguise and is promoted.
  7. The batch is the run's internal order, derived from dependencies and the pick, and is not a term of the record.
  8. One term per concept. The glossary marks phase, milestone and roadmap superseded with their successors named, gains bundle and step, and one page maps the families (itd-2609211913453478). The phase documents stay in the tree as history with a retirement line; the ROADMAP rule domain is replaced by this decision's statement.

Alternatives Considered

  • Amend adr-2609212115255771's decision 2 in place. Rejected by ruling H10: an ADR is not edited after it is accepted, and a decision whose text is false is superseded.
  • Supersede decision 2 alone, leaving the other seven in force in the old record. Rejected: the record has no partial supersession, and a record marked superseded whose other decisions still bind would read as retired to a reader following superseded_by. Carrying decisions 1 and 3 to 8 forward word for word keeps one record in force, as adr-2609151706587280 did for adr-46.
  • Keep the intent in a lane under Next as well. Rejected by ruling BV2: listing one intent twice says it is both being built and waiting to be.

Consequences

  • adr-2609212115255771 is superseded and retained: later records cite its numbered decisions, and those numbers mean the same here.
  • statusblock.Read leaves an intent in a lane out of Next and Later, so the board, --json and the site's Status page follow from one read; removing the state file returns each such intent to the list the gate places it in.
  • itd-2609212103568351's criteria 1 and 3 are read with the Audit Notes line the change adds to it; the criterion text is not edited.

Frontmatter

idadr-2609292012006845
typeadr
statusaccepted
date2026-09-29

.abcd/development/decisions/adrs/2609292012006845-now-next-and-later-list-an-intent-in-a.md
open on GitHub ↗ · commit history ↗

References6

  • adr-9Phase as a product-reflection layer between brief and intentrelated
  • adr-2609212115255771Phases and milestones are retired: sequencing is dependencies rendered as status, the checkpoint is the derived releasesupersedes
  • itd-2609211913453478One page maps the record families, and phase, milestone and roadmap are retiredrelated
  • itd-2609212103565953A spec lists its steps, and the build lands them one at a timerelated
  • itd-2609212103568351The status board shows Now, Next and Later, computed from the recordrelated
  • itd-2609212103572513An intent names the release it must land by, and the cut says whether it didrelated

Referenced by1

  • adr-2609212115255771Phases and milestones are retired: sequencing is dependencies rendered as status, the checkpoint is the derived releaserelated

mentions8

  • adr-46Persisting the hook binary never weakens the verification posture — every promotion re-verifies, and SessionEnd performs no network work
  • adr-2609151706587280The cache reaches PATH only through a home-scoped attestation the environment cannot write
  • adr-2609300107513982A provider adapter's allowlist alone decides which models it serves, and abcd bundles no vendor denylist
  • dcn-26092900000000072026-09-29 — The product thinker answered twenty-six owed rulings and the published-history question in one interview, asked one at a time by orchestrator abcd-23 of autonomous run A (recorded by lane recRulings for orchestrator abcd-cb). The answers are kept verbatim in the local-tier file `.abcd/.work.local/scratch/reports/rulings-answered-2609-29.md`, dated 2026-09-29, and are restated here because that file is not committed. Published history is left as it is, with no rewrite. The build loop's fidelity audit runs once, on the lane that closes the spec, over the whole delivery (AI). On the vendor denylist the product thinker answered, verbatim: "I think we need an allow list rather than trying to catch a deny list." The interviewer's reading of that answer, recorded as a reading and not as the product thinker's words, is that the per-provider allowlist is the control and the vendor denylist is not extended to chase spellings, with whether the bundled `anthropic/*` entry stays as a backstop left to the technical facilitator (AA(a)). Only a route the person set up on their own machine may use their paid key, and a repository's own route to it is refused, which replaces the route half of itd-2609081951381895 decision 8 (AA(b)). The live site setup, the API adapter and the decision adapter may each close on tests against a simulated service, with the live paid check recorded as owed to a person (iss-2609291925387011, iss-2609291925393913, iss-2609291925398978). itd-111's last criterion is met by an agent's timing check on macOS plus the Linux CI run, so the intent may be finished. Automated dependency updates are switched on, pushed with a personal or app token the person creates and stores as a repository secret (itd-2609221842494980; creating the token is the person's act, and the lane builds everything else and names the secret it expects). itd-6 adds a Go MCP module, proposed for the person's explicit sign-off before it is fetched; closing itd-6 on a fake server was not ruled in this interview. (A later answer the same day, H1b in the local-tier file `.abcd/.work.local/scratch/reports/rulings-answered-2609-29-b.md`, dated 2026-09-29, rules that it is not: itd-6 is finished only after running once against the real RepoPrompt app, a check owed to a person.) For itd-148: the store under the home folder wins (adr-2609091248200336); the store draft itd-2609091014076309 owns add, list and clean-up and itd-148 uses them; a session that declares itself the coordinator is exempt from the write block in the primary checkout and every other session is blocked; and the store draft is planned first, with nothing from the store draft, the merged-worktree clean-up included, built before its planning interview (Q4). itd-148's own wait is not part of that ruling: it follows from Q2, because itd-148 uses the store's verbs, and is carried by the `blocked_by` below. itd-148 and spc-42 are rewritten to match in this change, and itd-148 is now `blocked_by` the store draft. A release retrospective is seeded from a release, the intents a tag shipped (AD); itd-24 and its spec are rewritten to the release in this change. An unpointed route is refused naming the one setting to add, as built in 35100512e, so AC11 of itd-2609170822093401 is complete (BR1). A missed target becomes `next`, whatever the following release is numbered (BS1). Spec pieces keep "step" and the lane stages are renamed, a breaking change to the JSON fields `step`, `performed` and `refusal.step` that resolves iss-2609291313276243 and corrects the glossary entry `core/step.md` (BU1), and the old command spellings are removed in that same breaking release (BT1). The text board shows Later as a count only while the site and `--json` keep the full list (BV1), and an intent in progress appears only under Now (BV2). A pause of zero is allowed (BW1); drain stays in the agents' help list until it runs end to end (BX1); a managed repository must hold the drain eligibility decision in its own record, and drain refuses there until it does (BX2); a capture without a remedy is refused (BX3), which tightens the one-line capture friction `commands/capture.md` promises, so the lane that builds it reconciles that page, the principle wording and every caller that files a capture; a run's pick reason keeps the shared `pursued:` kind with its marker (BZ1); and an intent whose blocker was superseded waits on the successor, transitively (BZ2). The five itd-48 follow-ups are planned as one intent, drafted as itd-2609291923559186 (BT2), and all warn rules share one shrink-only baseline file in which a new warning fails, drafted as itd-2609291924469783 (BT3); both drafts wait on their planning interviews. Each ruling that contradicts a shipped behaviour or another record is amended in the change that builds it, not here. itd-7's planning interview stays owed.
  • iss-2609292011569133The product thinker's rulings BV1 and BV2 of 2026-09-29 change what the shipped status block promises: the text board gives Later as a count alone (--json and the site keep its rows), and an intent in a lane is listed under Now only, never also under Next or Later. That makes itd-2609212103568351 criteria 1 and 3 and adr-2609212115255771 decision 2 (Next is every planned intent the gate reports READY; Later is the rest) false as written.
  • iss-2610030807157970The bundled ROADMAP rule domain still teaches retired phases and milestones. internal/core/rules/defaults/rules.json:34 injects 'The roadmap is intent-driven; each phase ends in a milestone.' into every managed repository on a prompt that names a roadmap, milestone or phase, although adr-2609212115255771 retired the phase, the milestone and the word roadmap (decision 8 replaces this domain with the decision's statement) and adr-2609292012006845 carries that forward. abcd's own repository masks the defect with a repo override (.abcd/rules.json:127-131), so its own sessions never see it; a sibling session's user test of an adopted repository on v0.9.0 reported it on 2026-10-03. The brief-wide sweep iss-2609251618079479 does not name the defaults file.
  • itd-78abcd Knows What to Build First — Even When It's Something Small
  • itd-2610070550516046On the dashboard, a product thinker sees the brief and their ideas together, and puts the ideas in order