Development record

The Facilitator Is a Mode, Not a Person

intentdraftsmajoritd-97

Press Release

Facilitator-seeded draft (2026-07-25 role-ownership review) — the product thinker owns the final press-release framing.

abcd runs solo or duo: the facilitator is a configuration, not a hire. A project chooses duo — a human facilitator working alongside the product thinker, as today — or solo, where abcd itself performs the facilitator's work: shaping intents into plans, curating the backlog, firing reviews, triaging captures, and deciding when each of those happens. The gates do not move: solo and duo run the identical deterministic gates and the identical product-thinker decision points; the only thing that changes is who operates the machinery between them.

"I don't have a facilitator — and it turned out I didn't need to find one," said Alice, a product thinker. "abcd drafted the plan from my intent, queued the work, ran the reviews, and every time a decision was genuinely mine it arrived as a clear proposal with the price spelled out. Bob still prefers duo, with a human translator beside them — same framework, same gates, their choice."

Why This Matters

The README already records the ambition ("in a later version, abcd aims to offer an automated facilitator") but nothing owns it. The facilitator's what has shipped kernels — the planning interview, intent ready, the run protocol, the fidelity reviewer — with completions planned (itd-27, itd-50, itd-53, itd-58, itd-78, itd-82). The facilitator's when — acting unprompted at the right moment — exists only as drafts: the schedule (itd-13), self-firing reviews (itd-83), stage-aware defaults (itd-19), and the coordination/escalation contract (itd-33). Solo mode is the named composition of those parts behind one switch; making it first-class is also the precondition for testing solo against duo at all (itd-98).

The role boundary is already doctrine and does not change with the mode: steps owned by the product thinker (adoption, adjudication, dependency sign-off, irreversible actions) stay human in both modes (verifier-selects-gates-decide); solo automates only facilitator-owned work.

What's In Scope

A per-repo mode declaration (duo | solo) with duo the default; the status board and every run surface name the active mode — no ambient ambiguity about who the facilitator is.
Solo = the composed "when": scheduled sync, self-firing reviews, capture triage, backlog curation, and run initiation composed behind the mode switch, over the pluggable run seam (itd-29).
Duo unchanged: the same machinery surfaces queued facilitator work to the human instead of acting; nothing is removed from today's flow.
Gate parity: mode changes an operator, never a gate — the deterministic gates, review requirements, and STOP conditions are byte-identical across modes.
The escalation contract: solo stops at every product-thinker decision point with a proposal (options, recommendation, price), exactly where duo would hand over.

What's Out of Scope

The solo-vs-duo evaluation — itd-98 owns the measurement.
A team of product thinkers — itd-99 owns plural thinkers; this intent assumes one.
Any weakening of human gates in solo — --dangerously-unattended-style skips are the run protocol's concern and never cross the product-thinker line.
Model routing and credit contingency — operational policy, owned by the run PLAN contract.

Acceptance Criteria

Given a repo configured solo, when a new capture lands in the ledger, then triage runs without a human initiating it, and any routing that requires judgement lands as a proposal for the product thinker — never a silent action.
Given a repo configured duo, when the same events occur, then abcd surfaces the queued facilitator work to the human facilitator and performs none of it unprompted.
Given either mode, when the same change is driven to a PR, then the deterministic gates, reviews, and STOP conditions applied are identical (a diff of the gate configuration between modes is empty).
Given solo mode reaches a decision reserved for the product thinker (adoption, adjudication, new dependency, irreversible action), when it gets there, then it stops with a clear proposal and recorded reasoning and does not proceed until adoption.
Given a session starts in either mode, when the status board renders, then it names the active mode.
Given the technical facilitator is set to human (duo), when an agent would arm auto-merge on a pull request or add it to the merge queue, then that is refused as a hard rule, whoever asks, and the pull request waits for a human to merge it. (The first gate declared in both modes; proposed by the product thinker, 2026-10-11.)
Given the technical facilitator is set to auto (solo), when a pull request's required checks and gates pass, then auto-merge is armed on it automatically, with no one asked.

SOTA

Surveyed on 2026-10-23; sources, evidence tiers and the local fit risks are in the elicitation interviews SOTA note.

Autonomy is a design choice on a scale: Sheridan and Verplank's level 5 "executes that suggestion if the human approves", 6 "allows the human a restricted time to veto", 7 "executes automatically, then necessarily informs"; a 2025 framework names the user's role at each level (operator, collaborator, consultant, approver, observer; Feng, McDonald and Zhang). Human mode is the approver level, auto-merge the observer level, a merge queue with a veto window level 6.
The coding hosts have converged on classifier-gated auto with hard residual refusals: the host abcd ships for never auto-approves its question tool or writes to protected configuration paths, pauses after 3 consecutive or 20 total blocks, blocks by default "Merging a pull request no human has approved, approving Claude's own pull request, or disabling CI checks", and ignores auto set in a project's settings; another deprecated "Ask Every Time" but still prompts for deletion in every mode; a third allows its all-approve mode "only … via command line". The residual list (a question to a person, configuration paths, deletion, the product thinker's decisions) belongs in both modes.
Auto-merge is only a rule if something is required: it "merges a pull request automatically after all required reviews and status checks pass" and is offered "only on pull requests that cannot be merged immediately" (GitHub). "Checks pass" must mean success on the merge-group ref: GitHub "considers a 'neutral' check run conclusion as passing" (Kodiak).
The bots already live under the human-review rule: Renovate "can't automerge its own PR until such a review has happened"; GitHub's own coding agent needs "Another reviewer" because the requester's approval "won't count"; its reviewer's "approval assessment alone does not count toward merge requirements", but "When enabled, Copilot can submit an approval that counts toward the repository's required-approvals rule", off by default and enabled by an administrator, so the forge now lets a model approval satisfy a required review where that is switched on. A repository's policy can forbid the mode outright (QEMU declines AI-derived contributions on sign-off grounds).
The human gate decays: automation bias "cannot be prevented by training or instructions" (Parasuraman and Manzey, 2010); wrong advice raised error risk by a pooled 1.26 (Goddard et al., 2011). An audit of auto-merged pull requests (random re-review, rejection rate) is part of the mode.
On "is merging irreversible": no opened source states a position. That Renovate and the GitHub agent allow a merge under required reviews and checks is consistent with treating a reviewed, queued merge as revertable and re-validated, but that reading is this pass's inference, not a field position; the question stays with the product thinker, and the 2026-10-15 refinement reads the same way.

Path 2: a native two-point mode shaped to the levels scale and the hosts' convergence. Repository configuration can forbid auto but should not alone arm it: the hosts refuse to take their auto mode from project or local settings, and a committed .abcd/ file is writable by any agent in the run and by any pull request (the guard's protected-path list does not include it), so reading it from the repository root stops no agent from editing it. Either auto is armed from a user-level setting, with the repository able only to lower it, or the key is a protected path the guard refuses to write and only the person's own act changes; the planning interview rules which, and "Where does the mode live?" stays open. Solo v1 in-session and host-delegated; pause a temporary drop to human; "checks pass" defined as success with a human approval the requester cannot supply in human mode. No Go dependency.

The independent fit-challenge runs at plan time.

Open Questions

Where does the mode live? A .abcd/ config key, or a value of the itd-19 stage taxonomy (whose Autonomous/Collaborative axis is the nearest existing vocabulary)?
v1 initiative scope — which "when" triggers compose into the first solo cut (triage and reviews look smallest; scheduling has the itd-13 launchd/cron design)?
Relationship to itd-29's operator verbs — is pause in solo mode equivalent to a temporary drop to duo?
Does solo v1 require the run seam, or can it operate in-session (host-delegated) first, per script-first MVP?
Is merging an "irreversible action"? The fourth criterion keeps irreversible actions with the product thinker in both modes. If merging a pull request counts as one, an auto facilitator could not merge either, which contradicts the auto-merge gate the product thinker proposed. Settle which actions stay the product thinker's, and whether a revertable merge is among them.
How the hard rule is enforced. A gate an agent can talk its way past is not a hard rule: the guard registry could refuse gh pr merge --auto and an enqueue while the facilitator is human, which needs the guard to read the facilitator setting.
(SOTA 2026-10-23) Whether a model reviewer's approval may satisfy a forge's required review in auto mode, given the forge's own reviewer does not count by default and the requester's approval never does.

Decisions

2026-10-11: the product thinker proposed a toggle that automates the technical facilitator's role, set to human or auto, with auto-merge as the first example: always refused as a hard rule while the facilitator is human, so a human merges; armed automatically when it is auto. Shown that this draft already covers the switch, they chose "Add to the draft" over a new intent, so the example lands here as this intent's first two-mode gate, and other facilitator responsibilities follow the same pattern (adr-2609151528057260: every gate declares its behaviour in both modes). "human" and "auto" are the product thinker's names for duo and solo.
2026-10-15, the product thinker, refining the 2026-10-11 decision: with the facilitator automated, every ready pull request auto-merges, or is enqueued, with no human step; with a human facilitator, the facilitator reviews and approves, and the merge waits for them. Automated merging is not unreviewed merging: the reviews are automated by separate agents. A ready pull request has a passing preflight, a review pair of separate agents on different models with fresh context (principle evaluator-outside-the-loop), the stop rule (only a critical or major finding blocks; anything smaller becomes its own capture), and CI and the merge queue on the merged tree. The land defaults built for the next release (iss-2610150524235929, push after a passing preflight; iss-2610150524246898, enqueue every ready pull request) follow this gate rather than fixing either mode in place.

Audit Notes

Empty. Populated by intent-fidelity-reviewer when intent moves to shipped/.

References

README § Roles — the recorded automated-facilitator ambition this intent gives an owner.
itd-29 (run seam operator surface, planned); itd-13, itd-19, itd-33, itd-83 (the "when" drafts this composes).
.abcd/development/principles/verifier-selects-gates-decide.md — the role boundary both modes preserve.
itd-2610150602547271 (builds on this intent): its first slice, the facilitator mode declaration and the merge gate that obeys it.
itd-98 (the evaluation), itd-99 (plural thinkers) — the sibling drafts filed with this one.

Frontmatter

id	itd-97
type	intent
lifecycle	drafts
severity	major

.abcd/development/intents/drafts/itd-97-the-facilitator-is-a-mode-not-a-person.md
open on GitHub ↗ · commit history ↗

References1

itd-2609201916151817One verb takes a READY intent to delivered, and refuses while a decision is openbuilds on

Referenced by11

adr-40Review, audit, lint, and gate are four buckets, separated by what each comparesrelated
adr-2610150603484802A fresh install's facilitator is a person until the repository says autorelated
adr-2610240850193281A human-set autonomy grant permits, separately from the agent-written waiting-on badgerelated
iss-2610262031486321GRILL's asking rules say options widen and never recommend, but itd-97's escalation contract hands the product thinker a proposal with a recommendation.related
iss-2610262031496655Scope says itd-29 is superseded, but itd-97 builds solo mode over the pluggable run seam it names as itd-29.related
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.related
iss-2610262044004875itd-97 builds solo mode on the run seam of itd-29; itd-2609201916151817 says itd-29 is supersededrelated
iss-2610262044094024The facilitator mode's values are `duo | solo` in itd-97 and `human` / `auto` in itd-2610150602547271related
itd-98Solo vs. Duo Is Measured, Not Debatedbuilt on by
itd-2609212137129937abcd's text names the product thinker or the technical facilitator, never the maintainerrelated
itd-2610150602547271The facilitator's mode gates the mergebuilt on by

mentions26

adr-2609151528057260Three roles, who each artefact addresses, and when the loop stops
dcn-26081600000000032026-08-16 — the assessment vocabulary settled at a maintainer grill and filed as adr-40 (proposed): **four buckets — lint / review / audit / gate — separated by what each compares**, not by determinism, not by trigger. The rule was already half-recorded (05-internals/01-agents.md rules the two verdict families disjoint: "reviews assess a change, criterion verdicts assess a promise vs reality") and three shipped surfaces contradict it — `intent review` emits family 2 so it is an audit, `abcd audit` is deterministic rule-checking so it is a lint (and it consumed the `/abcd:audit` name 02-constraints/04-naming.md reserves for itd-16), and `disembark oracle` emits family 1 while the brief calls its output an audit. Grill rulings: **one surface performs exactly one act** (multi-act surfaces split at design time — cheap, because every multi-act surface abcd has is unbuilt, so they are specified rather than refactored); the buckets are a **closed list extended by PR, not a criterion** (an autonomous run given a criterion interprets it; a table lookup matches or fails); `intent ready` survives as the fourth bucket **gate** because it names a decision rather than a comparison, preserving itd-94's exit-code contract; determinism is orthogonal (itd-16's hash-chain check is a deterministic *audit*; itd-85's conformance check is a *lint* however built); automatic-vs-manual never enters a verb name (the trigger is the facilitator's, per itd-97); the oracle is the model-access seam beneath review and audit, never a bucket. **Clean break, no aliases** — pre-1.0.0, `--impact breaking` drives version derivation (iss-171 precedent), users re-download; an alias would additionally collide with the documentation discipline's ban on change-narration, leaving an undocumented silent forward. The role mapping is the operational reason the split earns its cost: product thinker reads `audit` and essentially nothing else, which makes itd-99's "never hand a product thinker a technical decision" mechanically checkable. Same grill corrected a wrong finding: iss-246 was filed claiming abcd's record documents a surface far larger than the binary with no gate catching it; **false** — the `Status` column in 04-surfaces/README.md is machine-checked by `surface_coverage` (iss-35), the brief carries ~100 inline `design target` markers, and adr-5 makes the brief aspirational by design. The real defect is narrower: `surface_coverage` is blind *inside* a row, so six of twenty rows read `shipped` then qualify themselves in prose, and documents outside the registry cite those sub-verbs as live (all three citing **predecessor-store** spec ids spc-29/spc-30, whose prose survived the migration to the native store). Fix per adr-40 §6: sub-verb tables carrying two facts per verb — bucket and existence — with `surface_coverage` extended to registered cobra sub-commands, one table serving both disciplines. Also established: the twelve-step record walk completes at ten steps; step 2 (`capture promote`) has no verb and step 12 (`capture resolve`) cannot write `resolved_by`, so **walkability is sequenced before coherence** — renaming ~90 files across a process nobody can walk is polish before function. Plan at plans/2026-08-16-process-coherence-and-walkability.md; six intents to plan, none plannable unattended. Rejected: one polymorphic `review <id>` verb (merges the disjoint families, erases the role signal), classifying acts rather than surfaces (makes the bucket a statement of intent rather than a guarantee, and hands product thinkers lint findings), three buckets without `gate` (forces `intent ready` to become `intent lint`), and adding `verify`/`validate` (itd-109's verification suite is a packaging of lints and audits, not a fifth kind).
dcn-26101809133884452026-10-18 — The stall fix is its own intent, not a spec of the checklist draft (facilitator-on-delegation, itd-2610180912189125 planning): the slice (the away mode held by abcd, the stop check, and the question reroute) is filed as itd-2610180912189125, which builds on itd-2610170638184486, rather than planned as a first spec of that draft closed with a remainder; planning the draft would move it to planned before the product thinker has walked its criteria on Thursday, and its open trade-offs (the phone, the shared options) would then sit inside a planned record. A separate intent keeps the split with the coordination intent unchanged, since the slice touches nothing on the shared remote, and follows the precedent of itd-2610150602547271, filed as the first slice of itd-97. The idle time a coordinator sees stays out of the slice and comes with the coordination intent's central view (grounds: brief invariant 17; itd-2610150602547271; itd-2610170638184486 scope split; the coordination prep's ship-first decision)
iss-321persona pronoun discipline itd-79 is violated by gendered pronouns in seven intent records including a shipped intent
iss-338Seven registry personas are given he/she/his/her pronouns across intents/drafts (itd-92,97,98,108,126,128) and intents/shipped (itd-100), violating the they/them persona discipline (itd-79); review-enforced convention with no mechanical gate, concentrated in one 2026-08 authoring batch — a cosmetics-batch cleanup
iss-2610150524235929A branch whose preflight passed is pushed only if someone remembers to: abcd pushes after the receipt for a build lane alone. abcd build's land step already refuses a push without a receipt naming the head and then plain-pushes the lane. Every branch landed outside the loop gets no such step: hand-built branches, cloud-session pull requests, release branches, record-only chores. On 2026-10-14 one such branch's preflight passed at 13:17 and the branch sat unpushed for about two hours, because the step after the gate was lost across a context compaction. The coordinator now runs a hand-written scratchpad script that pushes after a minted receipt; that is one session's workaround, not abcd. The product thinker asked (2026-10-15) for this to be abcd-wide, toggled in config, default on.
iss-2610150524246898Ready pull requests reach the merge queue one at a time, so a queue that can build four entries at once tests one. On 2026-10-15 abcd's own queue was configured to build up to four entries (max_entries_to_build 4), but the coordinator queued each pull request only after the previous one merged, through hand-run watchers. With each queue run taking 25 to 40 minutes, three ready pull requests cost about two hours instead of about forty minutes. abcd's land step arms auto-merge for a build lane, which lets the queue batch, but landings outside the loop have no such step, and iss-2610090642376032 already records that even a lane's arming can leave a pull request unqueued. The product thinker asked (2026-10-15) for queueing ready work together to be the default for every abcd-managed repository, toggled in config. Bound by the security standard rule: abcd adds the queueing, never changes how the repository's queue is configured.
iss-2610252215090992glossary/core/technical-facilitator.md:4 and :25 attribute 'the facilitator is a mode, not a person' to draft itd-97; adr-2609151528057260:52 accepted it, and adr-2610150603484802:34-42 set a fresh repository's facilitator to a person. docs/explanation/roles.md:3 and :23 still say the facilitator 'is an AI by default', against that amendment.
iss-2610262035378747The land chapter calls itd-97's auto/human merge toggle 'the facilitator mode'; the mode chapter uses `facilitator` as a value of `abcd mode`'s waiting-on state.
itd-13Reviews and Memory Stay Fresh, Always
itd-19Defaults That Match Where the Project Lives
itd-27Domain Experts Get Their Intents Grilled Before Anyone Codes Them
itd-29Domain Experts Run A Spec Autonomously And Recover From Anything Without Touching Git
itd-33Multiple Agents Coordinate On Intent And Spec Work Without Duplicating Effort Or Producing Competing Artefacts
itd-50The Audit Loop Drives An Intent To Acceptance — Or Calls For A Replan
itd-53A Shipped Intent No Longer Drifts Out Of Audit Just Because Nobody Ran The Review
itd-58A Real Reviewer's SHIP Verdict Reaches The Session Gate Through A Channel The Worker Cannot Forge
itd-78abcd Knows What to Build First — Even When It's Something Small
itd-82`abcd drain` fixes the issues that need no decision, and hands the rest back by kind
itd-83The Review Bar Fires By Itself, In Every Repo abcd Manages
itd-94An intent that is not planned cannot be implemented: abcd gains a machine-checkable implement-readiness gate that refuses with a remedy and offers the planning interview
itd-99A Team of Product Thinkers Decides as One
itd-107Autonomous Routines Assemble From One Versioned Template
itd-174Each repository configures how far its facilitator is consulted and when it escalates
itd-2610241015120503The person and the repository agree when abcd may merge, and what a cloud session may do
spc-2610161609350616The facilitator's mode gates the merge