docs: file future-direction drafts, review captures, and fix the run queue

.abcd/development/intents/drafts/itd-97-the-facilitator-is-a-mode-not-a-person-abcd-runs-duo-with-a.md

@@ -0,0 +1,126 @@
+---
+id: itd-97
+slug: the-facilitator-is-a-mode-not-a-person-abcd-runs-duo-with-a
+spec_id: null
+kind: null
+suggested_kind: null
+reclassification_history: []
+builds_on: [itd-29]
+severity: major
+---
+
+# The Facilitator Is a Mode, Not a Person
+
+## 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 him — same framework, same gates, his
+> 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.
+
+## 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?
+
+## 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-98 (the evaluation), itd-99 (plural thinkers) — the sibling drafts
+  filed with this one.

.abcd/development/intents/drafts/itd-98-solo-vs-duo-is-measured-not-debated-paired-runs-on-a-matched.md

@@ -0,0 +1,112 @@
+---
+id: itd-98
+slug: solo-vs-duo-is-measured-not-debated-paired-runs-on-a-matched
+spec_id: null
+kind: null
+suggested_kind: null
+reclassification_history: []
+builds_on: [itd-97]
+severity: major
+---
+
+# Solo vs. Duo Is Measured, Not Debated
+
+## Press Release
+
+> _Facilitator-seeded draft (2026-07-25 role-ownership review) — the product
+> thinker owns the final press-release framing._
+
+> **Whether an automated facilitator matches a human one is answered with
+> receipts, not opinions.** Point abcd at a matched backlog and it runs the
+> same work twice — one arm solo, one arm duo — and returns a scored
+> comparison: what shipped, what the gates refused, how often a human had to
+> step in and whether those escalations were the right ones, and how the
+> fidelity verdicts compare. Every number in the report traces to a receipt —
+> a PR, a gate log, a verdict file — and every blank is loud.
+>
+> "We stopped arguing about whether solo was ready," said Carol, a product
+> thinker evaluating abcd for her team. "The report showed solo landed nine of
+> eleven items clean and escalated exactly the two it should have. That's not
+> a vibe — it's a table I can take to Bob."
+
+## Why This Matters
+
+Solo vs. duo is a key axis on which abcd itself will be tested (maintainer
+direction, 2026-07-25): the framework is designed while being built, and the
+claim "the facilitator can be a mode" (itd-97) is only credible with a
+measured comparison behind it. The measurement substrate has recorded homes —
+the CLI eval harness (itd-75), effectiveness tracking (itd-17), and
+benchmark-driven configuration (itd-64) — and the judging discipline already
+exists: itd-81 (judge calibration) encodes the correlated-errors and
+effective-votes findings any outcome panel must respect. What is missing is
+the experiment itself: a paired-run protocol, a metric set, and a comparison
+report with receipts. abcd-cli's own backlog is the first corpus — pure
+dogfooding.
+
+## What's In Scope
+
+- **A paired-run protocol**: the same (or twinned) backlog executed once in
+  solo mode and once in duo mode, under the same run contract, gates, and
+  budget accounting.
+- **A metric set with receipts**: items landed; gate refusals; escalation
+  count *and* escalation quality (were the human handoffs the ones the role
+  boundary demands?); fidelity-review verdicts; wall-clock and token cost.
+- **An outcome judge panel under the itd-81 discipline** — independent
+  votes, correlated-error check, effective-agreement reported.
+- **The comparison report artefact** — one document, per-metric values, each
+  citing its receipt; divergent items itemised (what solo did vs. what duo
+  did), never averaged away.
+- **First corpus: abcd-cli** — the experiment runs against this repo's own
+  queue before any managed repo.
+
+## What's Out of Scope
+
+- **Shipping the mode itself** — itd-97.
+- **Statistical machinery beyond honest counts** in v1 — no significance
+  claims from n=1 paired runs; the report says what happened, not what
+  generalises.
+- **Host/model benchmarking** — itd-17 and itd-64 own model-level
+  effectiveness; this intent compares *modes*, holding the rest fixed.
+
+## Acceptance Criteria
+
+- **Given** a matched backlog and both modes configured, **when** the paired
+  run completes, **then** a comparison report lands with per-metric values
+  each citing its receipts — no uncited number appears.
+- **Given** the two arms diverge on an item, **when** the report renders,
+  **then** the divergence is itemised per item rather than folded into an
+  aggregate.
+- **Given** the outcome panel scores quality, **when** the judges run,
+  **then** the itd-81 calibration discipline applies and the report records
+  effective agreement, not just raw vote counts.
+- **Given** a metric cannot be measured for an arm, **when** the report
+  renders, **then** the blank is named and loud — never silently zero.
+- **Given** the first paired run on abcd-cli's own backlog completes,
+  **when** the report is read, **then** it supports a recorded
+  solo-readiness decision by the product thinker (adopt, hold, or rerun),
+  filed as a dated decision.
+
+## Open Questions
+
+- **Matched-backlog construction** — the same items run twice risk
+  contamination (the second arm inherits knowledge via the record); twinned
+  item pairs risk unequal difficulty. Which bias is cheaper to control?
+- **Who plays duo's human in the experiment** — the maintainer's time is the
+  scarce input; does a scoped "human budget" per arm make the comparison
+  honest?
+- **The pass bar** — what does "solo is ready" mean (parity on landed items?
+  zero missed escalations?) and who sets it (product thinker decision by
+  design)?
+
+## Audit Notes
+
+_Empty. Populated by intent-fidelity-reviewer when intent moves to shipped/._
+
+## References
+
+- itd-97 (the mode this measures), itd-99 (plural thinkers — a later
+  experiment axis).
+- itd-75 (CLI eval harness), itd-17 (model-effectiveness tracking), itd-64
+  (benchmark-driven config) — the measurement substrate.
+- `.abcd/development/intents/disciplines/itd-81-judge-calibration.md` — the
+  panel discipline the outcome judges must follow.

.abcd/development/intents/drafts/itd-99-a-team-of-product-thinkers-decides-as-one-individual-thinkin.md

@@ -0,0 +1,133 @@
+---
+id: itd-99
+slug: a-team-of-product-thinkers-decides-as-one-individual-thinkin
+spec_id: null
+kind: null
+suggested_kind: null
+reclassification_history: []
+builds_on: []
+severity: major
+---
+
+# A Team of Product Thinkers Decides as One
+
+## Press Release
+
+> _Facilitator-seeded draft (2026-07-25 role-ownership review) — the product
+> thinkers own the final press-release framing._
+
+> **The product thinker can be a team.** Each thinker takes their own
+> thinking session — the same interview a solo thinker gets, wherever they
+> work, on their own time — and abcd collates the authored inputs into one
+> joint proposal: agreements merged with citations, disagreements surfaced
+> side-by-side with their authors' names, nothing averaged into mush. The
+> team then holds one collective discussion over that proposal and records
+> the decision. Throughout, abcd never asks a product thinker to make a
+> technical decision — only to decide on a clear proposal that names its
+> options, its recommendation, and its price.
+>
+> "Alice, Bob and I each wrote our version of the why separately," said
+> Carol. "The joint proposal showed where the three of us actually disagreed
+> — two places, not the ten we expected. The discussion took an hour, the
+> decision is on record with all three names on it, and my dissent about
+> scope is preserved next to the adoption instead of papered over."
+
+## Why This Matters
+
+The governing assumption is already doctrine: a verdict is a proposal and
+the human's adoption is the gate (verifier-selects-gates-decide); itd-41
+phases roadmaps as decide-knowing-the-price proposals; itd-90 hands a
+product thinker an interview whose answers land authored-by a named person
+on a date. But everything shipped and recorded assumes **one** product
+thinker. Three things are missing, in dependency order:
+
+1. **A participant model** — abcd has no representation of multiple named
+   humans (personas.json holds the fictional Alice/Bob/Carol; attribution
+   knows one maintainer).
+2. **Person-keyed thinking sessions** — the itd-90 interview pattern,
+   extended so each thinker's input is captured separately and stamped as
+   theirs.
+3. **Collation and decision machinery** — the press-release-composer already
+   composes one grounded document from many sources under cite-or-be-dropped,
+   and itd-81 supplies the independence discipline a human panel equally
+   needs; neither is wired to human inputs.
+
+## What's In Scope
+
+- **The participant model**: named product thinkers with authorship
+  stamping; every team-workflow artefact records who wrote what, when.
+- **Individual thinking sessions**: per-person interviews (itd-90 pattern)
+  captured independently — thinkers do not see each other's answers before
+  writing their own (independence before aggregation, per itd-81's
+  rationale).
+- **Automatic collation into a joint proposal**: cite-or-be-dropped against
+  the authored inputs; agreements merged with citations; disagreements
+  listed as first-class items with their authors; uncited synthesis dropped.
+- **The proposal contract for teams**: any technical choice in the joint
+  proposal is framed as options + recommendation + stated costs — never a
+  question requiring technical design from a thinker.
+- **The decision record**: the collective discussion's outcome lands with
+  named adopters, the date, and dissent preserved verbatim beside the
+  adoption.
+
+## What's Out of Scope
+
+- **Real-time meeting/chat tooling** — the discussion happens wherever the
+  team talks; abcd records its outcome, not its transcript.
+- **Voting and quorum arithmetic** in v1 — a decision is a recorded
+  adoption, not a vote count.
+- **Agent-to-agent coordination** — itd-33 owns agents; this intent is about
+  humans.
+- **Facilitator staffing** — works identically under duo or solo (itd-97).
+
+## Acceptance Criteria
+
+- **Given** three thinkers each complete an individual session, **when**
+  collation runs, **then** exactly one joint proposal lands in which every
+  claim cites the authored input(s) it came from and every disagreement is
+  listed with its authors — uncited synthesis is dropped, not kept.
+- **Given** a joint proposal contains a technical choice, **when** it is
+  presented to the team, **then** it appears as options with a
+  recommendation and stated costs, never as an open technical question.
+- **Given** the collective discussion concludes, **when** the decision is
+  recorded, **then** it names the adopters and the date and preserves any
+  recorded dissent verbatim alongside the adoption.
+- **Given** a named participant's session is missing, **when** collation is
+  attempted, **then** the gap is loud (the missing participant is named) —
+  never a silent smaller-team proposal.
+- **Given** an individual session's content, **when** it appears anywhere
+  downstream (proposal, brief, decision), **then** it is stamped as authored
+  by that person on that date, never disguised as something extracted from
+  the repository (itd-90 symmetry).
+
+## Open Questions
+
+- **Where do participants live, and the privacy collision**: the PII
+  discipline forbids committing real names/emails, yet authorship stamping
+  wants named humans in the record. A deliberate carve-out (participants
+  opt in to being named in their own repo) or an indirection (participant
+  ids mapped in an uncommitted local file)? This must be settled before any
+  schema exists.
+- **Async vs. sync** — is the collective discussion an artefact the team
+  edits asynchronously, or a session whose outcome one person records?
+- **Dissent and the lifecycle** — can a dissenting thinker block planning,
+  or is adoption by the recorded decision rule always sufficient?
+- **Collation engine home** — transpose the press-release-composer agent, or
+  a new dedicated collation agent? (One-canonical-primitive says extend.)
+
+## Audit Notes
+
+_Empty. Populated by intent-fidelity-reviewer when intent moves to shipped/._
+
+## References
+
+- itd-90 (brief-interview-for-the-blanks) — the authored-answer,
+  role-separated interview pattern this extends from one thinker to many.
+- itd-41 (phase negotiator) — decide-knowing-the-price proposals.
+- `.abcd/development/principles/verifier-selects-gates-decide.md` — the
+  decision contract, unchanged for teams: the collated proposal is the
+  verdict; the team's adoption is the gate.
+- `.abcd/development/intents/disciplines/itd-81-judge-calibration.md` —
+  independence-before-aggregation, transposed from LLM judges to human
+  panels.
+- itd-97, itd-98 — the sibling drafts filed with this one.