abcd'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.

abcd'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.

Ruling 2026-10-03

The orchestrator decided the oracle_backend half without a question, under the person's rule that an obvious answer is decided and the asking rule that a question with one defensible answer is not asked. The question offers five answers, four of which have no adapter yet (noAdapterYet in internal/core/ahoy/prompt_help.go). While only host-delegated works, setup does not ask it: the install records host-delegated and says in one note of its report that other reviewers arrive later and that abcd ahoy install --oracle-backend <value> chooses one then. A non-interactive install that passes the flag works exactly as before. The question returns on its own once a second answer is marked as having an adapter (oracleAdapterShipped), a rule a test pins, so adding an adapter re-enables it without a separate change. TestEverySetupQuestionPassesTheLimits no longer owes oracle_backend's two findings.

docs_target is not changed here: step 2 of itd-2610030814013772 retires claude_md and both, which brings the question inside the four-option limit, so its options finding stays owed in the test's baseline until then.

The six over-tall questions named above wait on step 5 of spc-2610030944505997 to calibrate HostTextColumns and HostChromeRows, then on shortening their copy. oracle_backend is one of the six and owes nothing while it is not asked, so five row findings stay in the baseline. The issue stays open: its rows part is not fixed.

Calibration 2026-10-03

Step 5 of spc-2610030944505997 measured the host's question view at 80 by 24 in Claude Code 2.1.288 (.abcd/development/research/notes/2026-10-03-host-question-layout-calibration.md). The text measure stays at 76 columns; the frame is 8 rows, the chip and the free-text row included; an option's label and description wrap at 74 columns. The calibrated estimate is at least one row taller than the provisional one for every question, so it admitted none of the row findings unchanged.

What the calibration fixed: scan_deep (26 rows calibrated) fits in 24 after its About and its "true" meaning were shortened with their meaning kept (the built-in scan "runs either way"; no abcd check runs trufflehog yet, so nothing else changes), and its owed line is deleted from the test's baseline. The em-dash question, newly 25 rows under the calibration, fits again once its "blocking" meaning reads "fails the documentation check until it is fixed".

What remains, still owed by name in setupLimitsOwed: docs_target's options (four answers and decide-later), which step 2 of itd-2610030814013772 resolves by retiring claude_md and both, and its rows (28); artefact_kind (34 rows), visibility (31) and the machine routing offer (43), whose copy cannot be cut to 24 rows without dropping what an answer means (visibility's caveat about records git already tracks, artefact_kind's three release kinds each with its scan, the routing table's one row per agent). Those three need the material split (tabs or successive questions) or a ruling on the copy, so the issue stays open; more than docs_target remains, so no deferral is recorded here.

Fit 2026-10-03

fix/setup-questions-fit fits artefact_kind in 24 rows at 80 columns (34 before) and keeps every fact its copy carried. A question no flag answers gains a change-later line, PromptHelp.ChangeLater, which the install's prompter prints and the question's field view shows as its "Change later:" line, so the About need not say where the answer lives or that it can be changed there. The shared consequences of binary and application are said once, application reading "as binary today". The About's "to choose what the release preview scans and which release workflow they lay" is carried by each answer's meaning. Its line is deleted from setupLimitsOwed.

As first measured, and both answered below in "Ruling 2026-10-03 (routing and visibility)": visibility (31 rows) and the machine routing offer (43) do not fit without dropping a fact. Under question.Default, the frame, the Now and Change later lines, the question line and the decide-later answer leave visibility six rows for its About and its two meanings, and leave the routing offer four rows for its reason and its table; the sixteen agent names alone take five. Each waits on the product thinker's choice:

• visibility: (a) show public's caveat only where .abcd/ already holds tracked files (the install can tell: effectiveVisibilityEntries asks git ls-files) and drop private's "Suits a repository whose code is not published", 24 rows, losing that advice; (b) the same conditional caveat, keeping the advice, with the flag hint every flagged question shares reworded so its "Change later:" line fits one row, 24 rows and no fact lost, at the cost of terse copy and a rewording that reaches every flagged question and the install's fix hints; (c) a recorded rows allowance for this question, which then scrolls at 80 by 24.
• the machine routing offer: (a) counts in place of names ("16 agents: 5 frontier, 11 economy, fan-out 1 each"), 24 rows, losing from the question which agent gets which tier (the written file and the bare board still show every row); (b) the table split across successive questions, each accepting its part, losing the one all-or-nothing answer, since a yes to one part and a no to another writes a partial table; (c) a recorded rows allowance for the offer.

Both choices were answered on 2026-10-03 (see "Ruling 2026-10-03 (routing and visibility)" below), and the same branch then fitted both questions: visibility in 23 rows, 24 with public's caveat shown, and the machine routing offer in 24, the repository offer staying at 22. Their two lines are deleted from setupLimitsOwed. After this branch only docs_target's two lines (options and rows) remain owed, for step 2 of itd-2610030814013772, which retires claude_md and both. The issue stays open until then.

Ruling 2026-10-03 (routing and visibility)

The machine routing offer: the product thinker answered the question "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 offer now says the proposal in counts computed from oracle.Roster() and oracle.Proposal() ("16 agents: 5 frontier, for verdicts a person reads and acts on; 11 economy, for the rest; fan-out 1 each"; fan-out bounds that differ are said as "<bound> for <number of agents>" pairs), keeps its reason, says that accepting writes every row to ~/.abcd/oracle-routing.json to read or edit, and stays one yes-or-no answer. The written table is unchanged. What the question no longer carries, as ruled, is which agent gets which tier; the file holds it. The old copy's "still runs through the harness, which is asked for the tier" reads "a step no provider serves goes to the harness, asked for its tier": the harness is asked for the tier and the host decides, as criterion 4 of itd-2609170822093401 says, so the offer promises no tier is honoured.

visibility: the orchestrator chose option (b), because it drops no fact. Public's caveat about records git already tracks is shown only where .abcd/ holds tracked files, the case effectiveVisibilityEntries narrows the public block on; core decides it through ahoy.HelpIn(cwd, key), the one exported help lookup, for the repository the install command hands its prompter; with no repository it gives the help that is the same everywhere. The caveat reads "Here .abcd/ holds records git tracks and cannot hide, so only its scratch and memory/ are ignored.", naming the memory/ fence the narrowed block keeps as well as the scratch. Private keeps "Suits unpublished code". The flag hint every flagged question shares now reads "pass <flag> <values> to answer without asking", so a "Change later:" line of a two-valued flag fits one 76-column row; the install's missing-value fix hints carry the same words. The limits test holds visibility twice, without and with the caveat, and both fit 24 rows.

Grounds

• pursued: TestEverySetupQuestionPassesTheLimits holds every setup question, the tallest visibility form included, to question.CheckLimits under the calibrated host figures with nothing owed; a setup question measuring over 24 rows or over four options at 80 columns would show it wrong