Development record

abcd proposes the model each agent deserves, and facilitates it where it can

intentplannedminorstandaloneitd-2609170822093401

Press Release

abcd now ships its own proposal for which model tier each of its agents deserves, shows it, applies it once the operator accepts it, and makes a best effort to satisfy it — a local or cloud provider where one is configured and reachable, the harness otherwise, always. Today the oracle backend is one repo-wide value that nothing reads, and every delegated step reaches whatever model the harness picks at whatever it costs. The proposal is a table with one row per agent: a tier from a small closed set (local, economy, frontier, host-decides) that survives model churn, and a fan-out bound that may tighten the ceiling the agent's own trust contract declares but never raise it. Nothing is applied until it is accepted: the install step renders the proposal and writes it, on consent, as the machine's table under ~/.abcd.noindex/; a repository may commit its own rows at .abcd/config/oracle-routing.json, and a repo row wins over a machine row, which wins over the bundled proposal. Above all three sits a manual override for one invocation — --route <agent>=<tier>[@<connection>], repeatable, on every delegating verb — so an autonomous experiment can run the same agent across backends and configurations and read the outcome from receipts that name the override verbatim. A provider's sampling settings — temperature, seed, and whatever else that provider accepts — default on the connection, and a row or a --route may override them for one agent or one run; a setting a provider does not accept is refused by that provider's adapter, never dropped. At run time abcd resolves the winning row against the connections configured on the machine: a configured provider that is reachable and can serve the tier is used directly; otherwise the step goes to the harness with the tier named in its request, one line on stderr says so before the step runs, and the receipt records the tier asked, the connection tried, the connection used and the model the host or provider reported. A machine with nothing accepted behaves exactly as today. The proposal is the surface a later learner updates from measurements across repositories; this intent ships the best guess and the machinery that carries it.

"The release gate's semantic review and the cold reading's four positions were reaching the same model at the same price, and I could not say which steps I had actually read the output of," said Maya, AI/agent researcher. "abcd's proposal already had the split right — the verdicts I read at frontier, the rest at economy — and once I pointed it at the local server the economy rows ran there without my touching a row. The receipt shows me what ran next to what was asked." Dave, security engineer, put it more simply: "The row says local, and if the local server is down the receipt says the step went to the cloud instead. I would rather know than guess."

Why This Matters

Graduated from iss-2609170818061083. The host-delegated oracle (adr-25) made model access the host's problem, which was right, but it left abcd with no way to express which model an agent deserves or how much parallel work it may spawn, and the repo-wide oracle.backend the install step writes is read by no verb. Cost is undifferentiated: every delegated step is paid for as if it carried a verdict somebody reads. Privacy is undifferentiated: a step over sensitive material is routed like one over a public brief, so an operator with a local provider has no switch that sends the sensitive passes there. Fan-out is unbounded by anything the record can see.

The operator should not have to write this table from nothing. Which agents carry judgement a human reads and which are plumbing is a property of the agents, not of the repository, so abcd can propose the split and be right for most operators; what a machine can reach is a property of the machine, so the proposal is resolved against configured connections at run time rather than written into rows. Acceptance is the opt-in that adr-25 asks for: a configured provider and an accepted table are the operator's two acts, and after them abcd routes without asking. The host still owns model choice, credentials and execution on the harness leg, which is why this refines adr-25 rather than reversing it; on a provider leg abcd owns the connection, and that adapter's own intent (itd-2609081951381895) records what that means.

Two intents share the seam. The enforced half — every ingested payload must name its model and its agent count — is itd-2609180517121254, which this one builds on: the routing table is what those fields are checked against. Learned routing (itd-17) refines this: the proposal is the floor a learner adjusts from measurements across repositories, and the invocation-time override is how those measurements are taken — the same agent run under several routes, each receipt naming the route that governed it.

What's In Scope

The bundled proposal: one row per agent, tier and fan-out bound, shipped with the binary.
Rendering the proposal and writing it only on consent, at machine level (~/.abcd.noindex/) and, offered separately, at repository level (.abcd/config/oracle-routing.json); repo over machine over bundled.
Run-time resolution of the winning row against the machine's configured connections: provider where reachable and able to serve the tier, harness otherwise, the fallback announced on stderr and recorded on the receipt.
The closed tier vocabulary and the host-decides floor.
The request block carrying the tier and bound on the harness leg; the receipt carrying tier asked, connection tried, connection used and model reported.
An orphan row reported by name when a table is read.
The invocation-time override, --route <agent>=<tier>[@<connection>], repeatable, on every delegating verb: it wins over every layer for that run alone, and the receipt records it as an override so a measurement run is never mistaken for accepted routing.
Provider settings carried on a route: a connection's defaults, overridden per row and per --route, passed through to the provider and recorded on the receipt as sent.

What's Out of Scope

Requiring and refusing on the payload's model and agents_used fields — itd-2609180517121254.
The provider adapters themselves, how a connection is configured and probed, and which settings each provider accepts — itd-2609081951381895 and iss-2609081951416843; this intent resolves against whatever connections they establish and hands settings through, and the adapter refuses one its provider does not accept.
Updating the proposal from measurements — itd-17.
Enforcing a fan-out bound at ingest; here a row carries the number and the request block states it.
A lint rule over the tables; run-time reporting is the gate here.

Mechanism

We expect a routing row to change which model a harness-run step uses because the harness already exposes model selection to a sub-agent request, so a plainly stated tier in the request block is enough; shown wrong if receipts show the host ignoring the tier on a material share of runs.
We expect cost to fall without judgement suffering because the steps whose output a human reads are a small minority of delegated steps, so tiering the rest down changes nothing a person acts on; shown wrong if economy-tier outputs fail the ingesting verbs' schema gates or the audit verdicts drift.

Scope Conditions

Providers the operator configured at machine level: abcd never reaches a connection nobody set up, and a step on a machine with no provider runs through the harness whatever the row says.
Single-operator repositories: one person or one small team accepts the tables, and no claim is made about a table contested across many contributors.
Hosts that report the model used: on the harness leg the self-report is the only evidence, and a host that cannot name its model cannot be checked, so rows for it are advice with a receipt that says so.
Escalation applies to tier-routed reviewers only: the agent that writes each fix round has no level row and never escalates (Decision 6, the product thinker's ruling of 2026-10-23).

Decisions

Ruled by the product thinker on 2026-09-22, after the research pass on model routing:

Escalation inside a lane is a rule, not a router. A lane starts at its role's tier; on a failed fix round the next round runs one tier up, and the switch is recorded as a fact in the state file with the round and the gate output that caused it.
A route through a provider adapter must be on that provider's allowlist (adr-2609221009491186); the tier proposes only routes the resolver admits.
No learned per-request router (itd-17 superseded by itd-2609221009495079).

Settled by the technical facilitator on the product thinker's delegation, relayed by the coordinator on 2026-10-22, each from this intent's own What's Out of Scope:

A row's fan-out bound is carried, not enforced, until the payload names the agents it used. Out of Scope lists "Enforcing a fan-out bound at ingest; here a row carries the number and the request block states it". No verb reads the bound before itd-2609180517121254 gives the payload agents_used; resolution clamps it to the ceiling (internal/core/oracle/resolve.go) and the request block states it, as today.
The proposal is held to the agent roster at run time and by a test, not by a lint rule. Out of Scope lists "A lint rule over the tables; run-time reporting is the gate here". An orphan row is reported at run time as a diagnostic (internal/core/oracle/store.go), and TestProposalNamesEveryAgentInTheRosterAndNoOther keeps the bundled proposal and agents/ in step both ways.

Ruled by the product thinker on 2026-10-23, relayed by the coordinator:

Escalation covers tier-routed reviewers only. The agent that writes each fix round has no level row in the routing tables and never moves up a tier, and accepted tables are not offered a new row. A failed round's next round asks one tier up for each reviewer whose route resolves from a tier; a route that names no tier (a runner route, the reviewer route, a pointed role, host-decides, the fix agent) is recorded with the gate output and does not move. The scope condition saying so was stamped by abcd intent plan, which here carries the product thinker's direct answer of 2026-10-23, relayed by the coordinator, and changes nothing else on the intent.

Acceptance Criteria

Given a machine with no accepted table and a repository with no routing file, when any delegating step runs, then it runs through the harness at host-decides under the agent contract's own fan-out ceiling, and no provider is contacted.
Given the install step on a machine with no accepted table, when it runs, then it says abcd's proposal in counts (how many agents, how many at each tier, their fan-out bounds) and where every row can be read once accepted, and writes the table, one row per agent with tier and fan-out bound, under ~/.abcd.noindex/ only on consent; a repository-level file is offered separately and written only on consent.
Given an accepted row for an agent naming a tier, and a configured provider on this machine that is reachable and can serve that tier, when a step dispatching that agent runs, then abcd routes the step to that provider directly.
Given an accepted row for an agent, and no configured provider that is reachable and can serve its tier, when a step dispatching that agent runs, then the step goes to the harness with the tier and bound named in its request block, one line on stderr names the fallback and its reason before the step runs, and the receipt records the tier asked, the connection tried, and the connection used.
Given a step's payload is ingested, when the receipt is written, then it carries the tier requested, the connection used and the model reported, side by side, verbatim.
Given a repository file and a machine file that disagree on an agent, when a step dispatching that agent runs, then the repository row is the one resolved, and the bare abcd board shows all three layers for that agent with the winning row marked.
Given --route <agent>=<tier>[@<connection>] on a delegating verb, when a step dispatching that agent runs, then the flag's row is the one resolved regardless of the accepted tables, a second --route for a different agent applies alongside it, and the receipt records the route as an invocation override, verbatim; a --route naming an agent the verb does not dispatch, or a connection that is not configured, is refused before the step runs.
Given a connection carrying default provider settings, a row that overrides some of them, and a --route that overrides others, when a step resolves to that connection, then the settings sent are the connection's defaults with the row's overrides applied and then the flag's, and the receipt records the settings as sent; a setting the provider's adapter does not accept is refused before the step runs, never dropped.
Given a table carrying a row for a name that is not an agent in the roster, when the table is read, then the orphan row is reported by name on stderr and the remaining rows still apply.
Given a lane whose fix round failed, when the next round starts, then it runs one tier up from the role's tier and the state file records the round, the gate output and the switch.
Given a proposed route through a provider adapter, when the tier proposes it, then it is one the provider's allowlist admits, or the proposal names the refusal instead.

SOTA

Surveyed on 2026-10-23; sources, evidence tiers and the local fit risks are in the models, prompts and measurement SOTA note, which reuses the Jev and model-routing pass and the model-matrix note for everything the decisions already rest on.

The harness leg works as the Mechanism claims. The host's sub-agent docs resolve a model in a fixed order: per-invocation parameter, then the definition's model frontmatter (inherit means the main model), then a CLAUDE_CODE_SUBAGENT_MODEL default, then the main conversation's model; effort is settable on the same two surfaces (Claude Code sub-agents documentation).
A host force switch can override a row silently. CLAUDE_CODE_SUBAGENT_MODEL_FORCE=1 makes the environment value beat both the frontmatter and the per-invocation parameter, and a mod's spawn hook can replace the parameter; CLAUDE_CODE_EFFORT_LEVEL in the environment likewise beats both the definition's and the per-invocation effort. The receipt's "model reported" beside "tier asked" is the only check (the third scope condition), and a mismatch that matches the force variable should be named as such.
Two-model cascades pay; deeper ones rarely do. Two-model cascades gained 2.1–8.2 points over single-model selection; allowing more than two models did not improve mean accuracy in 118 of 135 comparisons (at most +0.43 points); depth beyond two helped only when the deferral signal reflected whether the current model was wrong rather than difficulty shared across models (Bouchard, arXiv 2605.06350, 2026). Whether a failed fix round is a current-model-error signal or a shared-difficulty signal decides whether a second step pays; it is a plausible instance of the first, not a tested one, and the paper studies single-query cascades, not fix loops. Decision 1's one-tier-per-failed-round rule is consistent with this, and the matrix run is where a second step is tested.
Router benchmarking exists (RouterArena, arXiv 2510.00202), and nothing in it reopens decision 3.
Served versus asked stays as the matrix note has it: the receipt carries the served model, provider and fallback attempts where the source exposes them.

Path 2, as planned: a native table resolved onto the host's per-invocation model and effort parameters on the harness leg and onto a connection on the provider leg; the request-block mapping is the seam. No 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 a receipt whose reported model contradicts the tier asked, on a host where the force variable is set, is recorded as a host override by name, so a measurement run never mistakes a forced model for the row's.

Open Questions

Whether a fan-out bound on a row is read by any verb before itd-2609180517121254 gives the payload an agents_used field, or only carried in the request block until then.
- Resolved: carried in the request block until then (Decision 4).
How the bundled proposal is versioned against the agent roster: an agent added without a row, or a row for an agent since removed, must be a lint finding on the payload rather than a run-time surprise.
- Resolved: run-time reporting and the roster test are the gate, not a lint rule (Decision 5).

Typed Links

built on by itd-2610161733316518 (one feature built across a model matrix): Routes each copy through the per-invocation override, extended to name a runner and its model.

Audit Notes

2026-10-03 — Acceptance criterion 2 says the proposal in counts rather than one row per agent. The product thinker ruled on 2026-10-03, answering "setup offers a plan giving each of abcd's 16 helpers a model level; with all listed it cannot fit" (options: counts only, split into parts, let it scroll, decide later), verbatim: "Show counts only". The written table is unchanged; only the question's text is (iss-2610031236155833).
2026-10-02 — Declared mutual pair with itd-2609081951381895 (the technical facilitator's ruling CY2 of 2026-10-02, verbatim: "SAME, DECLARED PAIRS — each direction names the piece it needs"). itd-2609081951381895's builds_on itd-2609170822093401 needs the routing seam: the per-agent route and the invocation-time --route override that point a role or a judgement type at <provider>/<model>, the only ways a provider is reached (the adapter's decision 9). itd-2609170822093401's builds_on itd-2609081951381895 needs the provider connections its winning rows are resolved against, and the adapter's refusal of a setting its provider does not accept (its out-of-scope list names the adapter for both). 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.

Linkage note (2026-09-30)

builds_on named itd-2 (in-session subagent dispatch), which is superseded by itd-2609201916056194. The edge is dropped rather than relinked: itd-2's supersession hands the repo-wide oracle backend it keyed on to this record, and itd-2609201916056194 declares builds_on this record, so the relinked edge would run against the dependency the successor already states and close a cycle.

Grounds

pursued: flexibility first — each delegated step routed to the model it deserves, with privacy as an option (a local model where the material must not leave the machine) and cost as the essential lever: abcd proposes the split between judgement-bearing and plumbing steps, the operator accepts it once, and abcd facilitates it where a configured provider can serve the tier, the harness always the fallback; sub-agent fan-out declared and bounded per agent, because unbounded fan-out is where cost and unpredictability come from. Shown wrong if the locally-routed or bounded steps start failing the binary's schema gates or their verdicts drift from the frontier-routed ones, if accepted tables diverge widely from the proposal, or if bounded runs cost the same and vary as much as unbounded ones.

Frontmatter

id	itd-2609170822093401
type	intent
lifecycle	planned
kind	standalone
severity	minor

.abcd/development/intents/planned/itd-2609170822093401-the-oracle-choice-is-one-repo-wide-value.md
open on GitHub ↗ · commit history ↗

References4

adr-25The LLM is host-delegated by default; oracles are opt-in adaptersrelated
itd-17Pick the Right Oracle for the Job, Automaticallyrelated
itd-2609081951381895abcd ships an OpenAI-compatible API adapter, and a provider serves only the models it listsbuilds on
itd-2609180517121254Every payload a host hands back from a delegated step names the model that produced it and the number of agents that ran, and the ingesting verb refuses one that does notbuilds on

Referenced by25

adr-2609221009491186A provider adapter serves only the models it lists, under a vendor denylist no listing overrides; everything else runs on the hostrelated
adr-2609300107513982A provider adapter's allowlist alone decides which models it serves, and abcd bundles no vendor denylistrelated
iss-2609170818061083The oracle choice is one repo-wide value in .abcd/config.json (host-delegated | native | cli | api | mcp), so every delegated step reaches a model the same way. The choice should be configurable per task: some steps want a local model (a cheap, private first pass over a transcript), some want the harness to decide, some want the harness told to use a high-end frontier model (a release gate's semantic review, an intent audit) and some a cheaper one (a slug, a summary). Alongside the backend, the same per-task configuration should say whether the harness may use sub-agents for the step at all, and how many, so a fan-out review can be bounded and a single-pass composition kept to one. Today none of this is expressible: the backend is global, and sub-agent use is whatever the command page tells the host in prose. The task classes the agent trust contract already declares (capability_scope.task_classes) are the natural key; the api adapter draft itd-2609081951381895 would be the first backend such a table could route to.related
iss-2610262031505758Dependencies present RepoPrompt and codex as oracle adapters an operator can select, but itd-2609170822093401 says nothing reads the oracle backend value today.related
iss-2610262033059301The routing intent has the install render the proposal, a table with one row per agent, before consent; the ahoy page states the proposal in counts and names no agent.related
iss-2610262036163231itd-2609170822093401's press release says the oracle choice is one repo-wide value that nothing reads; the reading chapter has the ingest resolve that intent's model-tier route before anything runs.related
iss-2610262037365749The model-tier intent says nothing reads the oracle setting and every delegated step goes where the harness picks; the build brief reads oracle.review to route a lane's reviewsrelated
iss-2610262039253719The oracle-routing intent sends a step to a configured provider that can serve its tier, but the adapters page says a tier alone never reaches a providerrelated
iss-2610262041018201The routing intent says nothing reads the oracle choice today; the verification matrix has close read the intent-auditor's own oracle role and send it to a provider.related
iss-2610262042426018itd-19's stage profiles switch one oracle value per stage; itd-2609170822093401 says that repo-wide value is read by nothing and routes per agent tier insteadrelated
iss-2610262043598765The routing intent leaves updating the proposal from measurements to itd-17; the decision-adapter intent records itd-17 as supersededrelated
iss-2610262044146690The routing intent always falls back to the harness when a provider cannot serve; the model-matrix intent switches that fallback off inside a cellrelated
iss-2610262044285635Tier routing sends a row to a provider that can serve its tier, but the shipped adapter rules that no provider serves any tierrelated
iss-2610262044485589Shipped itd-6 says abcd has no oracle logic and no routing of its own; itd-2609170822093401 has abcd propose and apply a model tier for each agentrelated
iss-2610262044499326Shipped itd-6 sends a lane's reviews to RepoPrompt through `oracle.review`; itd-2609170822093401 says nothing reads the oracle value and builds a separate routing table for each agentrelated
itd-6RepoPrompt over MCP is one opt-in reviewer route, beside the host's own agentsbuilt on by
itd-2609081951381895abcd ships an OpenAI-compatible API adapter, and a provider serves only the models it listsbuilt on by
itd-2609201916056194A role runs through the command-line harness the operator chose, and every fall back to the host is recordedbuilt on by
itd-2609201916151817One verb takes a READY intent to delivered, and refuses while a decision is openrelated
itd-2609221009495079abcd's typed judgements can run through a decision adapter, measured in a lab before it decides anythingbuilt on by
itd-2609301918174237A remote provider takes a file-reading agent only as a fixed, blanked, capped bundlebuilt on by
itd-2610161733316518One task done across a model matrix, re-runnablybuilt on by
spc-2609180535002478abcd proposes the model each agent deserves, and facilitates it where it canimplemented by
spc-2609251028149555A failed fix round escalates one tier, and a provider route stays on its allowlistimplemented by
spc-2610281649196051consult-only-advisor-roleimplemented by

mentions17

dcn-26092200000000012026-09-22 — Model routing, after an independent research pass (product thinker, at an interactive interview). Jev (TypeSafe AI, on OpenRouter) is a typed-decision model, not a router: it fits abcd's closed-option judgements and nothing generative. Rulings: a provider adapter serves only the models it lists under a vendor denylist no listing overrides, everything else on the host (adr-2609221009491186); the OpenAI-compatible API adapter is planned with OpenRouter as configuration, a one-time walkthrough at ahoy and the key kept out of the harness (itd-2609081951381895); a decision adapter for the typed judgements runs in shadow as an abcd lab and a research note is the evidence a ruling turns a judgement type on with (itd-2609221009495079); escalation inside a lane is a rule on a failed fix round, recorded on the model tier (itd-2609170822093401); model per role, the pick and consistency are not routing and stand as ruled; itd-17's learned router is superseded. Every external credential abcd holds goes through one store with three homes the person chooses (adr-2609221017021499, itd-2609221017023290); the API adapter and the site setup read through it. The research is filed as research/notes/2026-09-22-jev-and-model-routing-sota.md.
dcn-26092500000000052026-09-25 — The layered configuration resolver has one home, `internal/core/layered`, and two file families; every later consumer reads through it rather than opening a file of its own (lane implementer, autonomous run A, on spc-2609180535002478 part 1). Precedence is flag, then repository, then machine, then bundled, and every value comes back with the layer and the origin that supplied it. The families are `layered.Config`, which is `.abcd/config.json` in the checkout the session resolved and `~/.abcd/config.json` on the machine, and `layered.OracleRouting`, which is `.abcd/config/oracle-routing.json` and `~/.abcd/oracle-routing.json`, the files itd-2609170822093401 names. Scalar keys go in `Config` under a namespace: `pace.*` (itd-2609201925079472), `oracle.review` (itd-6), `roles.<role>.runner` (itd-2609201916056194) and `match.threshold` (itd-2609212137116617). The per-agent routing table keeps its own file, as its intent names, and no new file family is added without an entry here. Loudness: an absent file is an absent layer; a present file that is malformed, symlinked, carries a key twice, trails content, declares the wrong `schema_version`, or (machine layer) is not the caller's own owner-only-writable file is an error naming it; a consumer claims its namespace and every key in it (`Stack.Claim`, with `*` for an open segment such as the role name), and an unknown key under a claimed namespace is refused. Because ahoy writes `oracle.backend` into the shared file, whoever claims `oracle` lists `backend` too. A winning value that does not decode or fails its check is refused, and nothing falls through to a lower layer or to the default.
dcn-26092500000000092026-09-25 — One `--route` per delegating invocation, for the one agent it dispatches; a `--route` naming any other agent is refused before anything runs, never merged and never ignored (lane implementer, autonomous run A, fix round 1 on spc-2609180535002478, after the tier2 review's finding 1). AC 7 of itd-2609170822093401 says a second `--route` for a different agent "applies alongside" the first, and the closed spec's plan said it merges. Every delegating invocation dispatches exactly one agent (a dual-mode verb in its payload mode, or `reading ingest` for the position its output names), so a second agent has no step to apply to: merging would record an override nothing used, and ignoring it would let a mistyped agent name read as honoured. The refusal speaks of the invocation, not the verb ("this invocation dispatches <agent>, not <other>"), because `reading ingest` registers all four positions and dispatches one per output. The flag's help and the four command pages say one per invocation instead of "repeatable". A verb that one day dispatches two agents in one invocation passes both to `ParseRoutes` and gets AC 7's "alongside" as written.
dcn-26092500000000282026-09-25 — The build's open-question check reads the record's own settled convention and stays fail-closed (lane implementer, autonomous run A, fix round 1 of the loop lane, on iss-2609252053576085; the lane's first ruling, that every list item under `## Open Questions` is a question whatever it says, lived only in its report and refused intents the record had settled). `intent.OpenQuestions` recognises exactly two markers, learned from the 12 planned intents that carry list items there. A section whose first non-blank line is an italic `_All resolved …_`, with at most one count word (`_All four resolved …_`), is settled whole (itd-111, itd-93); `_All but one resolved_` is not. An item explicitly marked resolved or deferred is not a question: a bold span opening with the word (`**Resolved — …**`, `**Deferred**`, `**Deferred to a follow-up intent**`, `**explicitly deferred**`, `**explicit deferral**`) or the word as a label (`resolved:`, `RESOLVED:`, `Deferred:`), anywhere in the item including its continuation lines. Everything else stays a question: an item led `**Open` whatever it goes on to say (itd-60's "Open, and not gating scope"), an item that only points to another record (itd-76's "travel with itd-126"), `**Out of scope …**`, and a question that merely mentions deferral. With the rule, itd-111 and itd-93 pass the check; itd-7, itd-60, itd-65, itd-66, itd-76, itd-82, itd-117, itd-131, itd-2609170822093401 and itd-2609211116005482 still refuse, each on an item the record does not mark settled. Relabelling those items is the product thinker's call through the planning interview, not the loop's.
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.
dcn-26100200000000122026-10-02 — Ruling CY2 of the technical facilitator (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: "itd-14<->itd-15 and itd-2609081951381895<->itd-2609170822093401: SAME, DECLARED PAIRS — each direction names the piece it needs." Applied as CY1 above: both edges of each pair stand, and each of the four intents carries a dated Audit Notes line naming its pair and the piece each direction needs; edge_cycle still warns on both pairs until the linter can read a declared pair (iss-2610020836255174). This answers the ruling iss-2609300903551032's remedy waited on.
dcn-26100300000000042026-10-03 — The machine's model-tier routing offer in `ahoy install` says abcd's proposal in counts, never one row per agent (ruling of the product thinker, 2026-10-03, relayed by the orchestrator of autonomous run A; applied by lane setupFit2; iss-2610031236155833). Asked: setup offers a plan giving each of abcd's 16 helpers a model level, and with all listed it cannot fit (options: counts only, split into parts, let it scroll, decide later). The answer, verbatim: "Show counts only". The question stays one yes-or-no answer; the counts are computed from the bundled proposal and the written table is unchanged; acceptance criterion 2 of itd-2609170822093401 is amended to match.
iss-2609081951416843Setup discovery (ahoy) could probe OpenRouter reachability and, when reachable, offer it to the user as an opt-in code-review oracle — once the OpenAI-compatible api oracle adapter ships, OpenRouter is provider config (baseURL https://openrouter.ai/api/v1 + key), and the offer is an ahoy-time question, never an auto-selected backend.
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-2609300903551032Two more builds_on cycles sit in the intent store beside the runner and loop one: the drafts itd-14 and itd-15 each declare builds_on the other, and the planned itd-2609081951381895 (the OpenAI-compatible API oracle adapter) and itd-2609170822093401 (the oracle choice is one repo-wide value) each declare builds_on the other; record-lint's edge_cycle rule reports both
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-2610031236155833abcd's own setup questions break the asking limits its question check enforces. docs_target offers four answers and oracle_backend five, so with the decide-later answer they exceed the four options per question that the check and the host's question tool allow; and under the provisional row estimate artefact_kind (33 rows), docs_target (28), oracle_backend (43), scan_deep (25), visibility (30) and the machine routing offer (42) exceed 24 rows at 80 columns. TestEverySetupQuestionPassesTheLimits holds them as a baseline that may only shrink.
iss-2610080618506115Route work to model tiers by role, per task as well as per agent: thinking (Opus today), default (Sonnet) and quick (Haiku), so that, for example, a summary written for the product thinker goes to the quick tier rather than the thinking tier. The tier names are what abcd stores; each model family maps them to its own models, so a move to another vendor changes the mapping and nothing else. This refines the planned per-agent tier table (itd-2609170822093401), which has economy and frontier but no middle tier and no per-task routing. Before a cheaper tier takes over any task it should earn it: keep the thinking tier doing the live work and run the quick tier on the same task in the shadow, recording both outputs, so a later evaluation can show where the quick tier is good enough.
iss-2610230015137603When the rp reviewer route is configured and reachable as a step starts but its call then fails, the review falls back to the host, and the round's record still says the rp reviewer route took it with no tier, so the host runs that review without a tier and a later failed round never escalates it: tier escalation (itd-2609170822093401 criterion 10) does not apply to a review that fell back. The behaviour predates the escalation work; the escalation fix round covered only a route with no URL.
itd-2In-Session Subagent Dispatch — the Default Host-Delegated Oracle
itd-2609201925079472An autonomous run paces itself by default, and one flag sets the pace
itd-2610240922461281The review set is a setting, in model classes