Development record

One verb takes a READY intent to delivered, and refuses while a decision is open

intentplannedmajorstandaloneitd-2609201916151817

Press Release

abcd build <itd-N> runs one intent from READY to delivered with nobody in the loop, and refuses to start while a design decision is still open. build is the verb a person types; implement is the machinery it hands over to, the loop an agent or a driving host calls. The verb is a loop over a state file, not a model holding the run in its head: every invocation reads the state, does one step, writes the state and exits, so a killed process loses nothing and a pause is a timestamp. A host session drives it step by step by default, and a process can drive the same loop through a configured runner. Two modes are explicit: abcd intent plan stays the human's act, and implement --auto-plan is the agent's, adversarial reviews included, ruled on in its own decision record before it ships.

"The pilot did all of this by hand: a brief composed from three files, a receipt checked by eye, a range typed into the auditor's prompt, eight transcript captures one by one," said a technical facilitator who ran one intent through a coordinator, an implementer, three reviewers and an adjudicator. "Every one of those is a thing the binary already knows."

Why This Matters

Four sessions in two managed repositories ran the whole lifecycle through sub-agents between 2026-09-17 and 2026-09-20, and one of them asked outright whether the pattern becomes an abcd recipe. The Dessau pilot then measured it: an orchestrator reading reports only reached 187k of context, a coordinator 188k, and a single implementer 349k after one fix round on a nine-commit intent, which is past the point where compaction loses the evidence the reports need. The product thinker there rebuilt the orchestrator as a loop script over a state file, launching one fresh process per lane, and listed the pieces abcd would have to own: the brief renderer, the receipt writer and verifier, the state file, the worktree creation, the spec close and the capture resolve after the receipt, the audit request's delivered range, and the capture of the run's own transcripts. adr-27 already rules that the autonomous run's loop is a thin native seam that gates on receipts; this intent is that seam with its pieces named.

Mechanism

We expect a re-entrant loop over a state file, launching one fresh process per lane, to take an intent to delivered without a human because every step the pilot did by hand is a read of the record or a write the verbs already make, and the state the run needs between steps fits in a file rather than a context window; shown wrong if a lane needs a judgement the record does not hold and the loop cannot refuse on it, or if the receipts a lane writes cannot be verified without reading the lane's transcript.

Scope Conditions

Holds for a repository abcd manages, with a merge queue or branch protection on the default branch, and an intent in planned/ whose gate reads READY.
Holds where the harness or a configured runner can start a fresh agent process for a lane and return; a harness that offers no way to launch one is a stop condition the run names.
Holds at the pilot's measured scale: one intent of nine commits and four packages per lane, with the lane's own context under 350k; a lane that would exceed it is split by the spec, not by the loop.
The model a lane ran is recorded as the runner reported it; the binary cannot verify it.

What's In Scope

The loop and its state file under .abcd/.work.local/run/: lanes, status, branch heads, receipts, pull-request numbers, the window clock; every invocation advances it and exits.
The readiness and decision check before anything starts: READY, no open question, no unanswered claim section, not held, and, from the peer listing, no peer holding the record. The held state (iss-2609200830076665) is a prerequisite this intent depends on; until it ships the check reads the hold as prose and says so.
The brief renderer: Intent, spec, the conventions section of AGENTS.md, the decision lines the intent cites, into one file the implementer is handed.
The lane: A worktree in abcd's form, one fresh implementer, the receipt (commits on the branch, the definition of done's output, the report file), verified by the loop before any validator runs.
Validators that never implemented: The ruthless and security reviewers on the lane's diff, the fidelity auditor on the request the loop completes (it supplies the delivered range from the branch's base and head); findings applied by a fresh implementer or rejected in writing.
The landing: spec close and capture resolve invoked by the loop after the receipt, the pull request opened with the repository's own merge rule, the branch cleaned after the merge is an ancestor of the default branch.
The run record and the transcripts: One record per run under the local tier, and history capture of the run's own transcripts; the current-session capture (iss-2609202046145653) is a prerequisite, and until it ships the loop captures each transcript by path.
Refusals: An unplanned intent, an open decision, a peer holding the record, a runner that cannot be started, a receipt that does not verify.

What's Out of Scope

The pace and the ceiling (itd-2609201925079472); the runner a lane goes through (itd-2609201916056194); the worktree store's own verbs (itd-2609091014076309); the peer listing (itd-2609091416295622); the claim and the register.
The interview itself: A draft is planned by a human through abcd intent plan, or by --auto-plan once its decision record exists.

Decisions

Settled on 2026-09-20 with one defensible answer each, on the product thinker's ruling that such a decision is recorded rather than asked (iss-2609202055103741):

The orchestrator is the verb's own loop over a state file, never a model. The pilot's context numbers and adr-27 leave one shape. Roles are implementer and validators only.
Re-entrant, never blocking. A multi-hour process launched from a harness tool dies at the tool's timeout; every invocation does one step and exits, and a pause is next_eligible_at in the state file.
The merge target is the one merge gate's (amended 2026-10-30, dcn-2610300955154851): the loop asks the gate abcd land asks. In auto a ready pull request is armed, into the merge queue where one gates the branch and as auto-merge where none does, once a review receipt names its head; in human it is armed only once the technical facilitator's approval of its head counts, and is otherwise left open. The loop never pushes to a pull request after arming it.
The binary-owned pieces the pilot listed are this intent's scope, not seven records: They share the state file and are worthless apart.

Asked and answered on 2026-09-20:

Both drivers, host-driven by default. A host session drives the loop through a step interface (abcd implement step returns the brief; abcd implement receipt <path> advances the state), so its context stays bounded because the binary holds the state, and no boundary changes. A process driver, the same loop calling the CLI adapter (itd-2609201916056194) for each lane, is opt-in. That opt-in is a reversal flag on the host-delegated boundary in AGENTS.md, confirmed by the product thinker for the opt-in path only, and the ADR for --auto-plan records it beside the planning reversal.
--auto-plan, explicit and autonomous. The flag is named for what it does: it lets the planning path run without a human, the two adversarial reviews included, on a draft whose decisions are all recorded. abcd intent plan stays the human's act. The decision record states the substitute for the sign-off (recorded decisions, grounds present, the two review receipts, criteria provenance) and is minted before the path ships.
itd-29 is superseded by this intent. Its budget check before a run and its checkpoint on a rate-limit response move into the pacing intent as criteria; its telemetry and hand verbs are dropped until someone wants them.

Ruled by the product thinker on 2026-09-21, in the interview that filed itd-2609211116005482 (abcd build next) and revived itd-82 (abcd drain):

build for people, implement for the machinery. abcd build <itd-N> is what a person types and is the verb this record's press release names; abcd build next and abcd drain are the two customised runs that hand over to the same loop. abcd implement is that loop, with the step-level words a driving host calls renamed from next to step (implement step returns the brief, implement receipt <path> advances) so that next is free to mean the pick. Which verbs the command list shows a person and which it shows an agent is its own record (iss-2609211119023345).
Only the loop writes a verdict (itd-58 folded in). A validator's verdict is recorded by the loop from the validator's own return, into the state file, before the advance is decided; a lane has no write to it, and a receipt carrying a verdict the loop did not record is refused at the advance, naming the receipt.

The loop takes an issue as well as an intent (ruled 2026-09-21 for abcd drain, itd-82). abcd implement is keyed by itd-N or iss-N; for an issue the brief is the record and its remedy: field, the checks before it starts are drain's eligibility rule, the validators are the same, and the landing is capture resolve --commit in the lane's change; the lane report carries a handback: field the loop reads as a first-class outcome. abcd build <iss-N> is the person's form.

SOTA

Surveyed on 2026-10-23; sources, evidence tiers and the local fit risks are in the autonomous-loops SOTA note. The decisions are settled; the pass checks the loop's shape against durable execution and the host's current non-interactive surface, and names what the decisions leave implicit.

Replay from recorded outcomes is the durable-execution rule. DBOS records each step's output and a step with a checkpoint "returns the checkpointed output instead of executing", recovery resumes from the last completed step, steps must be idempotent, and there is no separate orchestration server (it needs Postgres); Temporal requires deterministic workflow code with non-deterministic work in activities "outside the replay path", and versioning for a code change under a running execution (DBOS and Temporal docs). LangGraph warns that code before a pause "runs again" on resume (LangGraph docs).
The host's result is the receipt's machine half. claude -p --output-format json returns session_id, num_turns, is_error, total_cost_usd, modelUsage keyed by model, permission_denials, and on failure a subtype (error_max_turns, error_during_execution, error_max_budget_usd) with errors; --max-budget-usd caps a lane and --permission-prompts none removes AskUserQuestion (Claude Code headless docs). The result is not always whole: after a process crash the final error_during_execution result "may carry zeroed usage, total_cost_usd, and modelUsage", and an error_max_budget_usd result's usage leaves out the response that crossed the budget, so the receipt accounts from total_cost_usd or modelUsage where present and records "unknown" otherwise (Agent SDK cost tracking). From host v2.1.302 a -p run with no permission mode set starts in Manual mode, so a lane sets its mode explicitly (headless docs).
Bare mode and signals. --bare is the host's recommendation for scripts and skips hooks and plugins; it also "doesn't use your subscription login", so a bare run needs ANTHROPIC_API_KEY or an apiKeyHelper in --settings, and a plugin and its hooks are passed explicitly with --plugin-dir and --settings; SIGTERM exits 143 with the turn unrecorded, SIGINT ends the turn first, and SessionEnd still runs (Claude Code headless docs).
abcd's runner already launches lanes bare. The shipped claude runner starts a lane with --print --bare and --no-session-persistence, on a paid key only (RN2, dcn-2610020000000016: "runner keeps --bare with an API key"). The guard does not reach it as a hook: it is supplied as the run's permission-prompt answerer, an abcd guard approve MCP server passed inline (dcn-2610161624025493). Its transcript is still kept: the dispatcher captures every runner lane from its stream, storing each lane's transcript as a native record through history.Capture and its redaction door, keyed on the session id and the role (runner.HistoryStore, wired into build and drain). A host-route lane, the default, runs in the person's session, where the SubagentStop hook captures it.
The host's own session state is not a read for the loop. The supervisor's state.json "is not a stable interface"; claude agents --json is (Claude Code agent view).

Path 2, the decided shape with two rules made explicit: every step is recorded with an idempotency key (lane, step, attempt) and its outcome before the next step is considered, and a re-entry replays a recorded outcome rather than re-running the step; every non-deterministic read (the forge, the runner, the peer listing) is written into the state file as an activity result; the state file carries a schema version and refuses a newer one. On the host: a lane runs as the shipped runner launches it (bare, on a paid key, with the guard as its permission-prompt answerer and no session persisted), sets its permission mode explicitly, is ended with SIGINT before SIGTERM, and its result JSON is read by the runner adapter, not the loop, with a zeroed crash result accounted as "unknown". No Go dependency. The independent fit-challenge is still owed before the build, and the questions below are kept for it.

Questions this pass raised for the fit-challenge before the build. They are kept here, not under Open Questions, so they do not hold a build the record already rules ready:

Whether every step's outcome, and every non-deterministic read the loop makes, is recorded under an idempotency key in the state file so a re-entry replays rather than re-asks, and whether the state file's schema version is refused when newer than the binary knows.

Open Questions

None open; decisions 5 to 7 settle the interview's questions, and decisions 8 to 10 record the rulings of 2026-09-21 (the verb's name, the unforgeable verdict, the issue key).

Acceptance Criteria

Given an intent not in planned/, or READY with an open question, an unanswered claim section or a hold, when the verb runs without --auto-plan, then it refuses naming the check that failed and writes no state.
Given a READY intent a peer holds, when the verb runs, then it refuses naming the peer, and writes no state.
Given a READY intent nobody holds, when abcd build <itd-N> runs, then the state file exists with one lane, the worktree exists in abcd's form on a branch off the default branch, and the brief file names the intent, the spec and the conventions it was rendered from.
Given a lane whose implementer has returned, when the loop verifies the receipt, then a receipt without commits on the branch, without the definition of done's output or without the report refuses and names what is missing, and the lane is not advanced.
Given a verified receipt, when the validators run, then each runs as a fresh agent that did not implement, every finding is either applied by a fresh implementer or rejected in writing in the lane's report, and the fidelity request carries the delivered range from the branch's base to its head.
Given validators passed, when the loop lands the lane, then the spec is closed in the landing change, every capture the lane fixed is resolved with its commit, the pull request exists with the repository's merge rule applied, and nothing is pushed to it afterwards.
Given the loop's process is killed at any step, when the verb is invoked again, then it resumes from the state file at the step that did not complete, and repeats no completed step.
Given a host with no configured runner, when abcd implement step returns a brief, then the host is told which agent to start and where the receipt goes, and the loop advances only on abcd implement receipt.
Given a configured runner and the process driver opted in, when the loop reaches a lane, then it starts the lane through the runner itself, and the run record names the runner.
Given a completed run, when the run record is read, then it names every lane, receipt, reviewer verdict, the model each runner reported, and the transcripts captured into the history store.
Given an eligible issue, when abcd build <iss-N> runs, then the lane's brief is the record and its remedy, its landing resolves the record with the fix commit, and a handback: in the lane report stops the lane and is reported as its own outcome.
Given a validator has returned, when the loop records its verdict, then the verdict in the state file is the one the loop parsed from the validator's return, and a lane report carrying a verdict the loop did not record is refused at the advance, naming the report; a real SHIP recorded by the loop lets the advance proceed.
Given any refusal, when it is rendered, then it names the step, the reason and the remedy, in text and in --json.

Typed Links

builds_on itd-2609201916056194 (the CLI adapter), itd-2609091014076309 (the worktree store) and itd-2609091416295622 (the peer listing): The runner, the worktree and the peer read this loop calls.
refines adr-27 (the autonomous run's pluggable seam): This is the thin native loop it names, with its pieces.
refines itd-50 (the audit loop to acceptance): The verb's validator stage is where that loop would run.
refines itd-2609170822093401 (the model tier): Decides which runner a role gets.
supersedes itd-29 (the autonomous spec run): Its run verbs re-land here on the intent key; its budget check and rate-limit checkpoint live in the pacing intent.
built on by itd-2610161733316518 (one feature built across a model matrix): Builds one intent several times on a frozen base, once per cell of a model matrix, with this loop's stages and none of its landing.

Audit Notes

2026-10-02 — Declared mutual pair with itd-2609201916056194 (the technical facilitator's ruling CY1 of 2026-10-02, verbatim: "KEEP BOTH, DECLARED (a declared mutual pair)"). itd-2609201916151817's builds_on itd-2609201916056194 needs the runner a lane goes through: the command-line adapter the loop's process driver calls for each lane (the loop's decision 5). itd-2609201916056194's builds_on itd-2609201916151817 needs the loop's lane, where a role is reached, and its run record, where each fallback receipt and the per-runner and per-role fallback counts are written (the runner's criteria 1 to 4). Both edges stand. The record has no field record-lint's edge_cycle rule reads as a declared pair, so the linter still reports the cycle at warn until it does (iss-2610020836255174). Each piece is read from the two records' own scope, criteria and decisions; the ruling names none. Recorded by lane rd2 of autonomous run A.

Grounds

pursued: we expect a re-entrant loop over a state file, launching one fresh process per lane, to take an intent to delivered without a human, because every step the pilot did by hand is a read of the record or a write the verbs already make, and the state the run needs between steps fits in a file rather than a context window; shown wrong if a lane needs a judgement the record does not hold and the loop cannot refuse on it

Frontmatter

id	itd-2609201916151817
type	intent
lifecycle	planned
kind	standalone
severity	major

.abcd/development/intents/planned/itd-2609201916151817-one-verb-takes-a-single-intent-from.md
open on GitHub ↗ · commit history ↗

References9

itd-2In-Session Subagent Dispatch — the Default Host-Delegated Oraclerelated
itd-29Domain Experts Run A Spec Autonomously And Recover From Anything Without Touching Gitrelated
itd-29Domain Experts Run A Spec Autonomously And Recover From Anything Without Touching Gitsupersedes
itd-50The Audit Loop Drives An Intent To Acceptance — Or Calls For A Replanrelated
itd-58A Real Reviewer's SHIP Verdict Reaches The Session Gate Through A Channel The Worker Cannot Forgesupersedes
itd-2609091014076309Session and agent worktrees live in a machine-scoped store that abcd lists and reclaims, never beside the user's own projectsbuilds on
itd-2609091416295622A session sees the records its peers hold before it mints or fixes onebuilds on
itd-2609170822093401abcd proposes the model each agent deserves, and facilitates it where it canrelated
itd-2609201916056194A role runs through the command-line harness the operator chose, and every fall back to the host is recordedbuilds on

Referenced by32

adr-2609291342092738A drain takes an issue alone only when its fields say it needs no decisionrelated
adr-2610222222326104abcd drives agents with no host session only on the person's own invocation, on the person's own account behind a wall, and hands back what it cannot finishrelated
adr-2610310235000654An unattended plan stands in for the sign-off only on a recorded, reviewed, unchanged draftrelated
iss-2610262031503691The mental model uses 'brief' for the project's canvas, but itd-2609201916151817 uses 'the brief' for the file an implementer is handed for one lane.related
iss-2610262031524343The personas page forbids generic, unnamed quote attributions, but itd-2609201916151817's quote is credited to 'a technical facilitator'.related
iss-2610262034312865itd-2609201916151817 attributes its quote to 'a technical facilitator'; the intent chapter says every press-release attribution is checked against the persona roster's names.related
iss-2610262037294601The build intent arms auto-merge wherever a queue gates the default branch; the build brief arms it only when a ruleset also requires a person's approvalrelated
iss-2610262037301480The build intent says each invocation does one step; the build brief keeps 'step' for a spec's steps and calls one invocation's work a stagerelated
iss-2610262037311796The build intent puts an issue lane's hand-back in the lane report; the drain brief puts handback in the receiptrelated
iss-2610262039262634The build intent arms auto-merge wherever the ruleset gates merges through a queue, but the land page says AM1 arms it only where a queue and a required approval both existrelated
iss-2610262040545166The glossary says abcd never owns the run loop; the build intent makes abcd's own verb that loop.related
iss-2610262040551548The glossary keeps 'step' in the build loop for a spec's piece only; the build intent uses it for one invocation of the loop.related
iss-2610262040570378The glossary makes planning the product thinker's sign-off and never unattended; the build intent adds `--auto-plan`, which plans with no human.related
iss-2610262043535279The build loop arms auto-merge whenever the ruleset gates through a queue; the facilitator-mode intent says that by default abcd never arms or queues a pull requestrelated
iss-2610262044004875itd-97 builds solo mode on the run seam of itd-29; itd-2609201916151817 says itd-29 is supersededrelated
iss-2610262044057318itd-59 and itd-2609201916151817 both claim capturing the autonomous run's transcripts into the transcript storerelated
iss-2610262044060780Keeping a record from autonomous pickup is a sentinel-spec dependency in itd-57 and a held state the build loop checks in itd-2609201916151817related
itd-6RepoPrompt over MCP is one opt-in reviewer route, beside the host's own agentsbuilt on by
itd-33Multiple Agents Coordinate On Intent And Spec Work Without Duplicating Effort Or Producing Competing Artefactsbuilt on by
itd-59Every Autonomous Run Pass Leaves the Same Durable, Queryable Transcript an Interactive Session Doesbuilt on by
itd-82`abcd drain` fixes the issues that need no decision, and hands the rest back by kindbuilt on by
itd-97The Facilitator Is a Mode, Not a Personbuilt on by
itd-2609091416295622A session sees the records its peers hold before it mints or fixes onerelated
itd-2609201916056194A role runs through the command-line harness the operator chose, and every fall back to the host is recordedbuilt on by
itd-2609201925079472An autonomous run paces itself by default, and one flag sets the pacebuilt on by
itd-2609211116005482`abcd build next` picks the readiest planned intent itself, and writes down whybuilt on by
itd-2609212103565953A spec lists its steps, and the build lands them one at a timebuilt on by
itd-2609212103568351The status board shows Now, Next and Later, computed from the recordbuilt on by
itd-2610161733316518One task done across a model matrix, re-runnablybuilt on by
itd-2610170634394993Headless agents in parallel coordinate through the shared remote, not conversationrelated
itd-2610240922461281The review set is a setting, in model classesbuilt on by
spc-2609202134338445one-verb-takes-a-single-intent-from-ready-to-delivered-withoimplemented by

mentions36

adr-27The autonomous run is a pluggable seam, not a Ralph port
dcn-26092100000000012026-09-21 — Phases and milestones are retired, and the word roadmap with them (product thinker, at an interactive interview after an independent research pass; adr-2609212115255771 supersedes adr-9). Sequencing is dependencies plus the lifecycle shelves, rendered as a Now / Next / Later status block on the `abcd` board and the site (itd-2609212103568351), never stored; the checkpoint is the derived release plus each intent's acceptance criteria, with an optional `target_release` the cut reports and moves forward (itd-2609212103572513); the unit below a spec is the step, a section not a family (itd-2609212103565953); an issue carries no spec by design; the batch is the run's internal order; one page maps the families (itd-2609211913453478). itd-24 becomes release retrospectives; itd-34 drops its phase rule. Same interview: `build` is the verb a person types and `implement` the loop (itd-2609201916151817 decision 8), the loop takes an issue key (decision 10), only the loop writes a verdict (decision 9); the person's command list is grouped with an agents block behind `--agent` (itd-146), every verb opens with a does/writes/refuses sentence (itd-2609212113220149), modes become flags and five checks one lint (itd-2609212130136102, breaking); the status-line badge is guarded and reset (itd-2609212130146198); a new capture or draft is matched and linked at filing, never refused (itd-2609212137116617); abcd's text names the product thinker or the technical facilitator and never the maintainer (itd-2609212137129937, captured for the run, no sweep today); the lab conventions become `abcd lab` (itd-2609212137128014); a managed repository's site goes live by one verb behind a provider seam (itd-2609061543533170).
dcn-26092200000000032026-09-22 — The control-programme idea is REFRAMED, not adopted as put (product thinker, after the ideate gauntlet; research/notes/2026-09-22-ideate-abcd-operator-console.md). Two kill attempts were fatal to the idea as stated: it named the product thinker as the configurer of operator-register material, which adr-2609151528057260 bars, and it made harness-less operation the destination, inverting the host-delegated boundary whose reversal itd-2609201916151817 records as opt-in only. The reframing, adopted: an operator console SERVED BY THE BINARY over local web (no new dependency), which is also the resident process that hosts the opt-in process driver, with a separate product-thinker pane in their own register (open stops, the plain-language verdict, the pace) — the web page itd-167 already decided on; configuration stays operator-side; many repositories waits for a registered-checkout store; a localhost surface that accepts secrets needs a per-launch token; the whole sequenced after the runner and routing intents; and it must carry a falsifier, since no evidence exists that a GUI control plane beats a CLI plus a status page. Ruled with it: where abcd runs as the binary with no host session, the fallback is a HOST THE OPERATOR CONFIGURED (their main connector), never nothing; and EVERY fall back to the host is recorded — a receipt per event and a count per runner and per role in the run record — as intel on what to improve (itd-2609201916056194, planned; itd-22 widened so that "any harness" includes none).
dcn-26093000000000222026-09-30 — The worktree store is planned (itd-2609091014076309, spc-2609301811532881), after two adversarial reviews and a planning interview with the product thinker and technical facilitator, asked one at a time. Decomposition: file as is, with no new ADR or principle; the build loop's lane primitive moves into the store's package, so the intent `refines` itd-2609201916151817. Rulings: the verb is `abcd ahoy worktree add|list|prune`; "merged" is the forge's recorded pull-request state or patch-equivalence, and it works with no forge; an unmerged worktree quiet for 14 days (repo-configurable) is surfaced with a dossier and removed only when named (`--yes <name>`), never forced; a reclaimed worktree's local tier is moved, never deleted, into a new sibling store `~/.abcd/notes/<root-sha>/<timestamp>-<name>/`, redacted on write with a manifest; the plugin page carries `add` as a host-run step; the worktree directory is `0o700`; prune exits 0 when it reclaimed something, 1 when it reclaimed nothing, 2 on a refusal; a directory keyed on an abbreviated root commit is listed as "not a lane" and names the full-key lane; the board line keeps "can be cleared" as an estimate. The 21 acceptance criteria are the product thinker's. Grounds: "pursued: working copies keep piling up with nothing to list or clear them; wrong if, after it ships, copies still accumulate outside the store." Carried from itd-148's 2026-08-26 interview and confirmed here: the merge proof and the quiet sweep. Also ruled: itd-148 keeps its mint-visibility criterion as peer awareness (its Decision 5).
dcn-26100200000000112026-10-02 — Ruling CY1 of the technical facilitator (2026-10-02, asked in plain words by the interviewer abcd-a2 [75597f]; same local-tier file as the H3-0 entry above; recorded by lane rd2), verbatim: "runner <-> loop mutual builds_on: KEEP BOTH, DECLARED (a declared mutual pair)." The person's note, verbatim: "in future, I think we need an intent to ensure this is checked first, so that the loop -- while acceptable -- is precise about what is needed each way." Applied: itd-2609201916056194 (the command-line runner) and itd-2609201916151817 (the build loop) keep both builds_on edges, and each carries a dated Audit Notes line naming the pair and each direction's piece. The record has no field record-lint's edge_cycle rule reads as a declared pair, so none is invented, edge_cycle still warns on the pair, and the gap is captured as iss-2610020836255174. This answers the ruling iss-2609300848016421's remedy waited on. Not filed: the intent the note asks for, whose routing waits on the person's decomposition confirm.
dcn-26100200000000162026-10-02 — Ruling RN2 of the technical facilitator, FINAL (2026-10-02, asked in plain words by abcd-a2 [75597f]; same local-tier file as the H3-0 entry above; recorded by lane rd2), verbatim: "YES, SEALED, PAID KEY ONLY — runner keeps --bare with an API key; only machine-layer (personal) routes may hand a role to a runner; repo routes skipped with a warning; subscription-only owners run the role in their own session." It supersedes the provisional answer, "TREAT IT LIKE A PAID SERVICE", given with the note "are you sure it cannot run via a subscription? Investigate first.", which stood only until a research pass returned: no flag set short of the bare flag seals project instructions, plugins, skills and agents (code.claude.com/docs/en/cli-reference, read 2026-10-02), and the vendor's terms do not permit third-party developers to route requests through Free, Pro or Max plan credentials on behalf of their users (code.claude.com/docs/en/legal-and-compliance, read 2026-10-02). Not built at this entry's base; lane runnerSeal of autonomous run A builds it with OC1 and OC2.
dcn-26101616240254932026-10-16 — A headless claude run whose role's contract grants the shell gets its permission prompts answered by abcd's guard through the harness's --permission-prompt-tool, naming the one tool of an 'abcd guard approve' MCP server that the launch passes inline with --mcp-config and --strict-mcp-config, under --permission-mode default; the shell is no longer pre-granted on that launch, so every shell command the harness would ask about reaches the guard, which approves only a clean allow (no entry, signal or diagnostic, a program the line names, no inline code handed to a non-shell interpreter) and refuses every other prompt with the guard's reason. The expected shape, a PreToolUse hook in a per-launch --settings file, cannot work: --bare skips every hook, those --settings declares included (probed on claude 2.1.301: a SessionStart and a UserPromptSubmit hook from --settings ran without --bare and not with it), and dropping --bare would let the repository's hooks, plugins and CLAUDE.md run. A role whose contract grants no shell keeps dontAsk, which already refuses every prompt; opencode has no per-launch approval callback and is unchanged; the person's host settings are never touched. This change adds no sandbox; sandboxing autonomous runs is a separate later step (dcn-2610161619296615). Grounds: claude --help 2.1.301; code.claude.com/docs/en/cli-reference, /headless, /agent-sdk/permissions, /agent-sdk/user-input; live probes of the prompt tool's request and allow/deny answers, and of --bare connecting an --mcp-config server.
dcn-26102222163464482026-10-22 — The plain-terminal drain is one intent that refines the shipped drain bundle (facilitator, on the product thinker's delegation of 2026-10-14 and 2026-10-16, itd-2610222215485265): the decomposition table routes it FILE-AS-IS, since its fence (itd-2610161621364075), its routed judge's isolation (commands/drain.md) and the consent to start agents are rules already in force, cited rather than restated; it refines itd-2610161016401115, whose press release promised a plain-terminal drain and which delivered the routed judge but no loop, rather than reopening a shipped record; revised after review round 1: the path reverses the host-delegated boundary for an opt-in use, as itd-2609201916151817's decision 5 flagged, so that reversal is recorded as adr-2610222222326104, proposed until the sign-off (grounds: the decomposition-calibration note under 2026-10-22; itd-84)
dcn-26103009551548512026-10-30 — Merge approval and pull-request check rulings. Human mode's merge approval is a rule agents keep, not a proof of who approved: it stops an agent merging by mistake, not one set on getting round it, abcd says so wherever it describes the mode, and no proof mechanism enters this release. The person approves in the terminal through an abcd command (abcd land --approve today, or a dedicated verb), so the current act stands; the dashboard or a web app is one more channel for the same approval (itd-2610300955049260), not a gap. Agents working under a forge account of their own is optional work, designed from current practice to run in the cloud and locally, through an API key or a subscription (itd-2610300955026531). Requiring a security key touch for an approval is later work (itd-2610300955031405). The three checks every pull request runs, the change labeller, the dependency review and the vulnerability scan, stay non-blocking, and a failure in any of them is fixed without being asked until it passes.
dcn-26103120420315392026-10-31 — Stop run-2610310228179894 after lane-1 (spec step 11, --auto-plan) merged as c6e6bfb50; do not take lane-2 (step 12, the no-host drive), which the loop opened on its own straight after lane-1's land stage. The session's mandate covered step 11 only and took no new work, and the iss-2610311224444576 lane is waiting for this reservation. The reservation is tombstoned (412aaa904); lane-2's worktree stays at c6e6bfb50, with nothing on it, so a later abcd build itd-2609201916151817 reserves again and resumes at lane-2's brief stage.
iss-59Two-layer verification lesson from the iss-36 sweep: 73 mechanical fixers + per-file grep-verify reported 100% clean, yet a 4-segment judgement review found ~30 real truth defects (invented homes for unmigrated material, false present-tense capability claims). For the run seam (itd-29/Phase 5) and any future corpus sweep: grep-verify proves pattern absence, never truth; a sweep is done only after a judgement review layer passes. Also: fix agents given precise per-finding instructions applied 100% cleanly — precision of the fix list, not agent capability, was the quality lever.
iss-381The delivery pipeline abcd runs on itself is hand-orchestrated and should be deterministic. This session hand-ran the full sequence: SOTA research -> itd-84 decomposition -> draft intent -> TWO independent adversarial reviews (design/feasibility + record-discipline) -> planning interview -> plan+spec -> test-first implementation -> TWO more adversarial reviews of the diff (ruthless + security) -> apply/refute findings -> gates (preflight, record-lint) -> atomic commits + PR -> resolve the ledger issue with provenance -> seed the deferred items back into the ledger. Every hand-off, gate, and review-pair was driven by judgement, not a deterministic harness. The individual stages already have records — itd-83 (the review bar fires itself), itd-84 (decompose before filing), itd-82 (ledger drain), itd-78 (intent-dependency graph) — but ALL are drafts/staged and NONE composes the others into one orchestrated pipeline. Honest constraint (loud-staging): the pipeline cannot be MORE automated than its stages, so full automation waits on those disciplines shipping; but the deterministic SCAFFOLD — the fixed stage order, the mandatory review-pair gate before plan and before merge, the hand-offs to the host for the human-in-the-loop steps, the ledger-seed-the-deferrals close-out — can be built now as a workflow/routine (itd-107 versioned-routine-template is the nearest delivery vehicle). Routing note: this is a big, cross-record idea, not a decomposed intent — it likely needs /abcd:ideate then itd-84 decomposition before it becomes filable, and it may reshape rather than duplicate itd-83/82/78.
iss-2609181121301638The fidelity review request lists the acceptance criteria but never the scope-condition identities the verdict must dispose. auditPromptBody in internal/core/intent/audit.go writes an Acceptance Criteria block numbered ac-1..ac-K and the rubric, while the verdict schema (verdictCondition, keyed on condition_id) and the intent-auditor contract require scope_conditions to cover the intent's conditions exactly, one disposition per cond-… identity; the identities reach the auditor only as HTML comments in the intent record that the request does not quote. Relayed from the Gropius managed-repo session gropiusllm-56 on 2026-09-18 after seven fidelity audits at v0.9.0: the reviewer scraped the cond comments by hand, and a miscount quarantined the verdict at ingest. Wanted: the request carries a Scope Conditions block listing each cond-… identity with its text, as it carries the criteria, so the auditor disposes exactly the set the ingest will check. The prompt body is hashed for provenance, so the block is part of the pure composition and the prompt_hash policy version moves with it.
iss-2609200830076665A held draft has no frontmatter state, so nothing mechanical stops a lane from planning it. A hold on an intent draft is prose (a Review or Open Questions section saying it is held and why); the intent frontmatter the loader reads carries no hold field, and abcd intent plan checks the draft's sections and the bucket, never a hold. The surface page makes plan a human sign-off act that is never run unattended, which is the convention that holds today, and a sub-agent lane that follows its own brief rather than the page has nothing in its way. Relayed from the Gropius session gropiusllm-2b on 2026-09-20, which ran five record-only lanes on held drafts with a written prohibition on planning as the only guard. Wanted: a held: <reason> frontmatter key on a draft, written by a verb and refused as free text, with plan refusing a held draft and naming the reason, and the record dispatcher (abcd <itd-N>) reporting the hold as the next move. Sibling of iss-2609170726457256 (no verb stamps judged fields on a draft): this is the state field, that one the judgement fields.
iss-2609202046145653history capture has no current-session mode, so a run captures its own transcripts by listing files by hand. At v0.9.0 the verb takes one transcript path, and bare abcd history capture with no file answers "--session <id> is required when reading from stdin"; nothing discovers the session that is running or the sub-agent transcripts it spawned. The Dessau pilot (session gropiusllm-64, 2026-09-20) captured its session and seven sub-agent transcripts with eight invocations after listing ~/.claude/projects/<escaped-cwd>/<session>/subagents/agent-*.jsonl by hand, which is exactly the path knowledge the store already has (list --session reaches a session and every sub-agent it spawned on the read side). Wanted: a write-side twin of that read, history capture --session <id> --all (the main thread and every sub-agent), with the current session as the default when the harness exposes its id, so a loop captures its own run in one call. Evidence for the implement verb (itd-2609201916151817), which would call it at the end of every lane.
iss-2609202055103741The interview rule makes the agent offer options that are not real choices, and asks a question where only one answer is sound. The GRILL domain in .abcd/rules.json says options widen and never recommend, no starred default, the null answer always available, and every question through the interactive tool one at a time. Followed literally on 2026-09-20 during the peer-listing interview, that produced a question whose three options were one sound answer beside two the record's own principle (loud-staging) already rules out, and the product thinker answered "why these options? Isn't 1 the obvious choice here?". The rule as written confuses two things: not steering the human (right) and manufacturing alternatives so a question has three of them (wrong). Ruled by the product thinker on 2026-09-20: the rule should not offer nonsense options; if there are no sensible alternatives, do not show them; if there is a single genuine answer, record it with the reason and do not put the question to the product thinker or the technical facilitator at all. Wanted: the GRILL domain reworded to say that a question is asked only where two or more answers are each defensible on the record, that the option set is exactly those answers plus the null answer, and that a decision with one defensible answer is recorded as a decision line naming why no question was asked; the itd-201 draft (every question asked one at a time, in plain language) is where the surface rule lives and should carry the same change.
iss-2609211119023345The command list shows a person and an agent the same verbs. abcd --help and the plugin's command pages list every verb alike, but the verbs split by who types them: a person types abcd build <itd-N>, abcd build next, abcd drain, abcd intent, abcd capture; a driving host or an agent calls abcd implement step, abcd implement receipt, abcd reading assemble, abcd intent audit ingest and the other machinery verbs a person never types. A product thinker reading the list today cannot tell which half is theirs, and the ruling of 2026-09-21 that build is the verb for people and implement the loop for the machine (itd-2609201916151817, decision 8) needs a place to show. Wanted: the command list distinguishes the two, the person's verbs by default and the agent's behind a flag such as --agent (or a section), with each command page saying which it is; the product thinker recalls an existing record asking for this cleanup, so the first step is to find and link it rather than file twice.
iss-2609230720193756The implement run state has two same-uid hygiene gaps the security review of itd-2609221656373558 rated LOW and shipped past on the record: fsutil.AppendLineIn's openAppendIn (internal/fsutil/fsutil.go) opens the log leaf without the Lstat and symlink refusal its read twin ReadGuardedInRoot applies, so an in-root symlink leaf redirects every appended line (demonstrated: a log symlinked onto a claim file makes the claim unreadable); and readClaim (internal/core/implement/claim.go) checks a claim file's session and lane only for non-empty before they reach HeldError and the release refusal, printed to stderr unsanitised, so a hand-edited claim can put terminal escapes on the operator's screen. Remedy, each test-held: refuse a symlink leaf in openAppendIn as the read primitive does, and run validName on the claim's session and lane in readClaim treating failure as unreadable. Also: .lock is created 0644 beside 0600 run files (internal/fsutil/flock.go), and commands/implement.md does not say the release refusal rests on a cooperative, unauthenticated role. The next lane that extends internal/core/implement (the build verb, itd-2609201916151817) takes it.
iss-2609240227236354itd-6 passes its readiness gate (intent ready itd-6: READY, all seven checks ok) but cannot be built from today's tree: its spec spc-2609211950427074 stands on four things that do not exist. (1) The build loop's validator stage the adapter implements, itd-2609201916151817 (planned, spec spc-2609202134338445 open; there is no build verb). (2) The layered oracle.review resolver the model-tier and pacing intents share, itd-2609170822093401 and itd-2609201925079472 (both planned, specs spc-2609180535002478 and spc-2609202134341288 open). (3) The command-line runner the adapters chapter entry sits beside, itd-2609201916056194 (planned, spec spc-2609221533057881 open). (4) An MCP client, which the spec's Approach names as a new dependency subject to the new-dependency sign-off; go.mod has none. itd-6 declares builds_on [itd-2] only, so the gate has no edge to refuse on and READY reads as buildable to a run that picks it.
iss-2609240646542516Nothing in `abcd implement` counts the agents alive, so a run's ceiling rests on the orchestrator's arithmetic: `implement join --ceiling N` records the ceiling and the report repeats it, and the v0.10.0 changelog says as much (recorded and reported, not enforced). Autonomous run A went over its ceiling three ways. At the start two lane agents each forked themselves into three parallel workers that no count saw, until the lane brief forbade forks. At 10:28Z on 2026-09-23 the orchestrator had six agents alive against a ruled five. During the v0.10.0 cut, at 05:06Z on 2026-09-24, it launched two cross-check agents into one free slot, five alive against four, and stopped one within a minute. Each was found by the orchestrator recounting, never by a tool. Wanted, for the implement verb (itd-2609201916151817): agent_start and agent_end kept by the verb itself, a live count derived from them, and a refusal to start an agent over the ceiling. A fork cannot be seen from outside the host, so the lane brief's no-fork rule stays the discipline for that half.
iss-2609240648533996What `abcd implement` (itd-2609201916151817) would have to carry to launch autonomous run A without its hand-written prompt, from having run it over 2026-09-23/24. The pilot's list (iss-2609211105021406) stands; this adds what a two-day run across three orchestrator sessions and a second session needed. (1) The run manifest as data: the batches and lanes in order with their record ids, the decisions the run may not reopen, the stop list, and the release step with the agenda line that authorises the publish approval. (2) The routing table as a verb output the orchestrator reads, not a scratch file its first lane derived by hand: 490 open captures split into 249 to build, 203 for the product thinker, 38 to judge on their merits, with 11 duplicates marked. (3) The pace and ceiling rulings as dated values that supersede one another, which the verb enforces and the log cites: the run lived under four ceilings (two implementers and one reviewer, then five, six and four agents) and three paces (two hours on and five off, three on and two off, then no pauses), each re-read by hand from a notes file by every orchestrator. (4) The roles and the model per role: implementers and fix rounds on one model, reviewers and auditors on another and one at a time, a fresh implementer per fix round, a reviewer that never implemented, and the model id each agent writes into its trailer. (5) The review receipts: which reviews a lane owes before it lands (ruthless, security at a trust boundary, a second lens on an ADR, the fidelity audit after merge) and the verdict each returned, so that "owed" is a query rather than a list in the handover. (6) The rotation chain and the handover block: the named successor sessions, the trigger at about 60% of context, and the block's fields (rulings in force, queue state, each lane's next move, hazards, owed items) written by the verb from run state; a fresh orchestrator started from a handover of about 650 words in 4% of its context. (7) A live-agent count that enforces the ceiling: agent_start and agent_end kept by the verb, a refusal to start an agent over the ceiling, and a ceiling_overrun event when one is found (iss-2609240646542516, iss-2609240646549900). (8) Lane retirement as a step: the ancestor check against the remote default branch, the worktree removal, and a branch delete that does not wait on the local default branch (`git branch -d` refuses a branch the merge queue merged until the local default branch is fast-forwarded). (9) Measurement the verb writes itself, with required fields per event, since the hand-written log lost its agent, gate and review lines at the first rotation (iss-2609240646555891). Evidence: the run's prompt, run file and lane brief were about 50 KB of prose; the first orchestrator's start-up reading cost about 15% of its context before any lane opened, and each rotation re-read the rulings from the top of the notes file.
iss-2609300848016421itd-2609201916056194 (the CLI runner) and itd-2609201916151817 (the implement loop) each declare builds_on the other, so the dependency graph that sequences work (adr-2609212115255771) holds a two-node cycle and neither can be ordered first. The loop's record states its edge (it calls the runner for each lane, decision 5 and its builds_on note); the runner's record gives no reason for its edge on the loop. Found by a read-only sweep of planned and draft edges; record-lint has no cycle rule, so the gate passes it.
iss-2610020836255174The intent record has no way to declare a mutual builds_on pair that record-lint's edge_cycle rule honours. The technical facilitator ruled on 2026-10-02 that three two-intent cycles stay as declared mutual pairs, each direction naming the piece it needs (CY1: itd-2609201916056194 and itd-2609201916151817; CY2: itd-14 and itd-15, itd-2609081951381895 and itd-2609170822093401), but the frontmatter offers only builds_on and blocked_by, and edge_cycle reports every strongly connected set whatever the records say, so the three pairs are declared only in each intent's Audit Notes and still read as cycles to the linter, and to anything that orders work by these edges. Until a declared pair is something the linter can read, edge_cycle cannot be promoted from warn to blocker without refusing the ruled pairs.
iss-2610080546203039The implement loop titles a lane's pull request from its issue's title; when that title names another record id, RS004 refuses the PR because no Refs line declares it (PR #865 named iss-2609261536147903 from its issue's title; fixed by hand by editing the body).
iss-2610262030301816The press release lists `/abcd:run` as in-scope operator wiring; the scope page says it is not built and its intent is superseded
iss-2610262031280238The press release counts /abcd:run, the itd-29 operator surface, among the plumbing in scope; the build sequence says the run seam does not ship, no run verb is registered and itd-29 is superseded.
iss-2610262031496655Scope says itd-29 is superseded, but itd-97 builds solo mode over the pluggable run seam it names as itd-29.
iss-2610262041130402The solo-mode draft runs on the pluggable run seam via itd-29; the build sequence says itd-29's surface is superseded and the seam does not ship.
itd-53A Shipped Intent No Longer Drifts Out Of Audit Just Because Nobody Ran The Review
itd-57Every abcd Voyage Ships With A Manual-Hold Sentinel That Blocks A Spec From Autonomous Pickup Until A Human Lifts It
itd-2609150819440345Which session holds which worktree, branch or record is coordinated entirely by conversation, so every new session repeats a handshake that nothing records. A session joining work in progress has no way to ask what is already claimed: it messages the peers it can see, waits for replies, and rebuilds a picture that the sessions before it had already built and did not write down. One measured encounter cost four messages and about fifteen minutes before any work began, and the picture it produced is not durable, so the session after that pays again. The convention that a diff you did not make is a peer's work depends on knowing who the peers are and what they hold, which is precisely the thing no artefact carries. The repository already records this gap for the narrow case of detecting a peer session before mutating git state; the wider case is claim rather than presence, and the two want the same substrate. Whatever holds it should be as cheap to write as it is to read, because a coordination record nobody updates is worse than the chat it replaced.
itd-2610222215485265abcd drain --drive works through the ledger from a plain terminal
spc-2609202134341288an-autonomous-implementation-run-paces-itself-by-default-and
spc-2609212015048113abcd-build-next-picks-the-readiest-planned-intent-itself-wri
spc-2609212138246060a-spec-lists-its-steps-and-the-build-lands-them-one-at-a
spc-2609221533057881abcd-runs-a-delegated-agent-through-a-command-line-model-run