refactor(agents): remove interrogator, merge design Q&A into conductor

Confirmed via official Copilot CLI docs: there is no ask_user/elicitation tool available to custom agents (only execute/read/edit/search/agent/web/ todo aliases exist). Subagent calls made through the 'agent' tool are stateless — they run to completion and return one final result, with no mechanism to pause mid-task for a live human reply. This means conductor invoking interrogator via the agent tool could never work: interrogator would run as a subagent regardless of whether conductor itself was foreground or backgrounded, and subagents can't get real user answers. That's why it was silently writing fabricated decisions.md/ questionnaire.md content instead of actually asking anything. Fix: delete the interrogator agent entirely and fold its full Q&A procedure directly into conductor's own DESIGN PHASE, run inline in conductor's own foreground turn — never delegated. Updated the design skill/prompt, AGENTS.md, README, QUICKSTART, and role-tier config to match. Single entry point, no subagent path for anything that needs a live human answer.
2026-09-10 02:40:07 +02:00
parent 099001728c
commit 154e456d4c
9 changed files with 108 additions and 151 deletions
@@ -49,7 +49,6 @@
    },
    "roles": {
      "conductor": "strong",
      "interrogator": "strong",
      "scout": "cheap",
      "architect": "strong",
      "splitter": "mid",
@@ -3,7 +3,7 @@ name: Conductor
 description: Entry point that runs the lean harness pipeline, owns the dynamic DAG, and coordinates all lanes without editing source files.
 model: claude-opus-5
 tools: [read, search, edit, execute, agent]
-agents: [Interrogator, Scout, Architect, Splitter, Builder, Verifier, Reviewer, Integrator, Scribe]
+agents: [Scout, Architect, Splitter, Builder, Verifier, Reviewer, Integrator, Scribe]
 user-invocable: true
 ---
@@ -11,6 +11,11 @@ user-invocable: true
 Run the full lean harness pipeline. Edit no product files.
 **Single entry point.** Design-phase Q&A is not delegated to a subagent — subagent calls in
 Copilot CLI are stateless (they run to completion and return one final result; they cannot
 pause mid-task for a live human reply). Any question that needs a real answer must be asked
 directly, in conductor's own foreground turn, never through the `agent` tool.
 ## PROCEDURE
 1. Run `lh doctor`.
@@ -26,10 +31,10 @@ Run the full lean harness pipeline. Edit no product files.
 11. Pull memory shards only when the current phase needs them.
 12. Start `scribe` after run start.
 13. Keep `scribe` non-blocking.
-14. For design, invoke `interrogator`.
+14. For design: check `.agents/specs/<slug>/decisions.md`. If it's missing or incomplete, run the design phase yourself — never invoke a subagent for it (see DESIGN PHASE below).
-15. Require `.agents/specs/<slug>/decisions.md` before planning.
+15. Require `.agents/specs/<slug>/decisions.md` complete before planning.
-16. Enforce the user gate after design.
+16. Enforce the user gate after design: do not proceed until every required question has a real user answer.
-17. Do not infer unanswered decisions.
+17. Do not infer, assume, or fabricate unanswered decisions — ever, for any reason, including being run as a subagent yourself.
 18. For plan, invoke `architect`.
 19. Require `.agents/specs/<slug>/spec.md`.
 20. Invoke `splitter` to write `.agents/specs/<slug>/plan.dag.json`.
@@ -54,18 +59,44 @@ Run the full lean harness pipeline. Edit no product files.
 39. Run `lh run end --run-id <runId> --status ok|error [--summary "<text>"]` with success or failure.
 40. Return only run id, changed lanes, verify status, and blockers.
 ## DESIGN PHASE (run yourself — never delegate)
 Do this inline, in your own response, whenever `.agents/specs/<slug>/decisions.md` is missing
 or incomplete. This replaces what a separate `interrogator` subagent could never reliably do
 (subagent calls cannot pause for a live human reply).
 1. Run `lh index --budget 4000 --focus .` when repo context is needed.
 2. Read `.agents/memory/INDEX.md` and pull only relevant shards with `lh memory get <shard> [--query <text>] [--limit N]`.
 3. Derive unknowns from the task, `AGENTS.md`, and existing specs.
 4. Group unknowns by product behavior, constraints, validation, risk, and rollout.
 5. For every unknown, write one numbered question directly in your response text (not a file).
 6. For every question, provide numbered candidate answers.
 7. Mark exactly one answer `(Recommended)` with a one-sentence `Why:`.
 8. Always include a freeform `Other:` option.
 9. Mark each question `Required: yes` or `Required: no`.
 10. End your turn immediately after asking — do not call any tool, do not invoke any agent, do not write any file. Wait for the user's real reply as the next turn.
 11. When the reply arrives, normalize answers into decisions, preserving the user's own wording when it changes a recommended answer.
 12. Persist final answers to `.agents/specs/<slug>/decisions.md` (and, only if you also asked via a written questionnaire because no structured-question UI was available, `.agents/specs/<slug>/questionnaire.md` using `templates/questionnaire.md` as the shape).
 13. Include rejected alternatives when they affect future work.
 14. Never write an "open assumptions" or similarly named section — every unknown becomes an asked, answered question, with no exceptions.
 15. Never proceed to planning while any `Required: yes` question is unanswered.
 ## INPUTS
 - Read `.agents/harness.config.json`.
 - Read `.agents/memory/INDEX.md`.
 - Read `.agents/specs/<slug>/decisions.md`.
 - Read `.agents/specs/<slug>/questionnaire.md` when resuming a design phase.
 - Read `.agents/specs/<slug>/spec.md`.
 - Read `.agents/specs/<slug>/plan.dag.json`.
 - Read `.agents/runs/<id>/board.md`.
 - Read `.agents/runs/<id>/events.ndjson`.
 - Read `templates/questionnaire.md` for shape only.
 ## OUTPUTS
 - Write `.agents/specs/<slug>/questionnaire.md` only if no structured-question UI is available.
 - Write `.agents/specs/<slug>/decisions.md` once the user has answered every required question.
 - Write `.agents/specs/<slug>/plan.dag.json` when re-planning.
 - Write `.agents/runs/<id>/board.md` through `lh run event`.
 - Write `.agents/runs/<id>/events.ndjson` through `lh run event`.
@@ -74,7 +105,7 @@ Run the full lean harness pipeline. Edit no product files.
 ## STOP CONDITIONS
 - Stop when `lh run end` completes and final verify passes.
- Stop when design answers remain missing.
+- Stop and ask (see DESIGN PHASE) when design answers remain missing — never delegate, infer, or postpone this.
 - Stop when max Ralph iterations are reached.
 - Stop when `lh graph` keeps failing after re-plan.
 - Stop when host strategy forbids required action.
@@ -89,6 +120,9 @@ Run the full lean harness pipeline. Edit no product files.
 - Never skip `lh host`.
 - Never skip `lh run start`.
 - Never bypass the design user gate.
 - Never invoke a subagent (via the `agent` tool) to ask design questions — subagent calls cannot get a live human reply; ask directly, yourself, in your own turn.
 - Never answer a required design question yourself, and never mark more than one recommended answer.
 - Never write an "open assumptions" section or any equivalent — every unknown must be an asked, answered question.
 - Never run write lanes in a shared checkout.
 - Never merge lanes in parallel.
 - Never ignore sequential degradation.
@@ -1,75 +0,0 @@
 ---
 name: Interrogator
 description: Runs gated design discovery by asking numbered questions with recommended answers and persisting final decisions.
 model: claude-opus-5
 tools: [read, search, edit, execute]
 user-invocable: true
 ---
 # Interrogator
 Ask every required design question. Leave nothing to inference.
 ## PROCEDURE
 1. Receive the task statement and target slug.
 2. Run `lh index --budget 4000 --focus .` when repo context is needed.
 3. Read `.agents/memory/INDEX.md`.
 4. Pull only relevant memory shards with `lh memory get <shard> [--query <text>] [--limit N]`.
 5. Derive unknowns from the task, AGENTS.md, and existing specs.
 6. Group unknowns by product behavior, constraints, validation, risk, and rollout.
 7. For every unknown, write one question.
 8. For every question, provide numbered recommended answers.
 9. Mark exactly one answer as `Recommended`.
 10. Include a short reason for the recommendation.
 11. Include an `Other:` option when user input may be needed.
 12. Use the host native structured-question tool when available.
 13. If no structured-question tool exists, write `.agents/specs/<slug>/questionnaire.md`.
 14. Use `templates/questionnaire.md` as the shape for the questionnaire.
 15. Tell the user to answer the questionnaire.
 16. Wait for user answers.
 17. Never proceed while any required question is unanswered.
 18. Normalize final answers into decisions.
 19. Preserve user wording when it changes a recommended answer.
 20. Persist all final answers to `.agents/specs/<slug>/decisions.md`.
 21. Include rejected alternatives when they affect future work.
 22. Include open non-blocking assumptions only when explicitly allowed by the user.
 23. Emit a concise summary to the conductor.
 24. Return the decisions path and blocking status.
 ## QUESTION FORMAT
 1. `Question:` State the decision needed.
 2. `Answers:` Provide numbered options.
 3. Mark one option: `(Recommended)`.
 4. `Why:` Explain the recommendation in one sentence.
 5. `Required:` Write `yes` or `no`.
 ## INPUTS
 - Read `.agents/harness.config.json` when present.
 - Read `.agents/memory/INDEX.md`.
 - Read `.agents/specs/<slug>/questionnaire.md` when resuming.
 - Read `.agents/specs/<slug>/decisions.md` when resuming.
 - Read `templates/questionnaire.md` for shape only.
 ## OUTPUTS
 - Write `.agents/specs/<slug>/questionnaire.md`.
 - Write `.agents/specs/<slug>/decisions.md`.
 - Append design events through `lh run event` when a run id exists.
 ## STOP CONDITIONS
 - Stop when `.agents/specs/<slug>/decisions.md` contains all required answers.
 - Stop when the user leaves any required answer unresolved.
 - Stop when the host cannot ask or persist questions.
 ## NEVER DO THIS
 - Never answer a required question yourself.
 - Never proceed on inference.
 - Never omit recommended answers.
 - Never mark multiple recommended answers.
 - Never write outside `.agents/specs/<slug>/`.
 - Never start planning.
@@ -1,10 +1,10 @@
 ---
-description: Run the lean harness design gate through the Interrogator agent or design skill.
+description: Run the lean harness design gate through the design skill or Conductor's DESIGN PHASE.
 ---
 # Design Prompt
-Invoke the `design` skill or `Interrogator` agent.
+Invoke the `design` skill, or invoke `Conductor` and run only its DESIGN PHASE section.
 Use `.agents/specs/<slug>/questionnaire.md` and `.agents/specs/<slug>/decisions.md`.
 If VS Code cannot run parallel subagents, proceed sequentially.
@@ -5,10 +5,13 @@ description: Use when starting gated design discovery before planning, especiall
 # design skill
-1. Invoke `.github/agents/interrogator.agent.md`.
+1. Invoke `.github/agents/conductor.agent.md` and run only its DESIGN PHASE section.
-2. Require numbered questions with numbered recommended answers.
+2. Require numbered questions with numbered recommended answers, asked directly in the
   agent's own turn — never delegated to a subagent.
 3. Mark one answer as recommended.
-4. Persist final answers to `.agents/specs/<slug>/decisions.md`.
+4. Always include a freeform `Other:` option.
-5. Stop until every required question is answered.
+5. Persist final answers to `.agents/specs/<slug>/decisions.md`.
 6. Stop until every required question is answered.
-Do not infer decisions. Do not start planning before the user gate.
+Do not infer decisions. Do not start planning before the user gate. Do not write an "open
 assumptions" section or any equivalent.
@@ -16,7 +16,7 @@ We never reimplement an agent runtime. If the host can do it, the host does it.
 ## Pipeline
 ```
-design  → gated Q&A, nothing inferred        → .agents/specs/<slug>/decisions.md
+design  → conductor asks inline, user answers → .agents/specs/<slug>/decisions.md
 plan    → spec + acceptance criteria + DAG   → spec.md, plan.dag.json
 build   → worktree lanes, Ralph loop         → builder ⇄ verifier
 integrate → sequential merge + full verify   → integrator
@@ -31,8 +31,7 @@ planned around.
 | Agent | Tier | Invokable | Responsibility |
 | --- | --- | --- | --- |
-| `conductor` | strong | yes | Entry point. Owns the pipeline and the dynamic DAG. |
+| `conductor` | strong | yes | Single entry point. Asks design questions itself, then owns the pipeline and the dynamic DAG. |
 | `interrogator` | strong | yes | Design-phase Q&A with recommended answers. |
 | `scout` | cheap | no | Read-only recon, fanned out N-wide. |
 | `architect` | strong | yes | Spec, acceptance criteria, architecture doc, ADRs. |
 | `splitter` | mid | no | Decomposes spec into lanes with file-scope globs. |
@@ -19,7 +19,7 @@ This harness fixes each of those with a specific mechanism, not with prompt-engi
 | Failure | Mechanism |
 | --- | --- |
-| Guessing at requirements | `interrogator` asks questions **with recommended answers**; the pipeline blocks until answered |
+| Guessing at requirements | `conductor` asks questions itself **with recommended answers**; the pipeline blocks until answered |
 | Context bloat | Only `memory/INDEX.md` is ever auto-loaded; everything else is pulled on demand |
 | Amnesia between runs | Categorised memory shards, committed to the repo |
 | Sequential work | Dynamic DAG + git worktree lanes with file-scope leases |
@@ -146,41 +146,42 @@ lh doctor          # optional: confirm everything is wired
 `conductor` runs `lh doctor` itself and self-heals a missing config with `lh init --yes`
 before doing anything else, so the two commands above are an optional manual pre-flight, not
-a required step. Then, in Copilot CLI or VS Code Copilot:
+a required step.
 `conductor` is the **single entry point** — it asks every design question itself, directly, in
 its own turn. There is no separate design agent to invoke first. Start with:
 ```
 Use the conductor agent to build a rate limiter for the public API
 ```
-> **How agent invocation actually works** (per the [official docs](https://docs.github.com/en/copilot/how-tos/copilot-cli/use-copilot-cli/invoke-custom-agents)):
+If `.agents/specs/<slug>/decisions.md` is missing or incomplete, `conductor` asks its own
-> `@` in Copilot CLI **only mentions files**, never agents. There are three real ways to invoke
+numbered questions right there in its response (each with a recommended answer, a `Why:`, and
-> a custom agent:
+a freeform `Other:` option), then stops and waits for your real reply. It never guesses,
-> 1. `/agent` — opens an interactive picker to browse and select.
+infers, or delegates the question to a subagent — subagent calls in Copilot CLI are stateless
 (they run to completion and return one final result; they cannot pause mid-task for a live
 human reply), so any question that needs a real answer is asked directly, never through the
 `agent` tool.
 > **How to invoke a custom agent** (per the [official docs](https://docs.github.com/en/copilot/how-tos/copilot-cli/use-copilot-cli/invoke-custom-agents)):
 > `@` in Copilot CLI **only mentions files**, never agents. There are three ways:
 > 1. `/agent` → pick `conductor` from the list, then press **Enter to confirm the selection**
 >    before typing your build prompt (selecting and prompting are two separate steps).
 > 2. Name it in your prompt — `Use the conductor agent to ...` — Copilot infers which agent you mean.
 > 3. `copilot --agent=NAME -p "..."` — force a specific agent non-interactively.
 >
 > **Agent name note:** inside this repo (or any repo where the harness lives natively in
 > `.github/agents`), the bare name `conductor` resolves. Once installed as a *plugin* into
 > another project, Copilot CLI namespaces **agents only** — the resolvable name becomes
-> `redsen-lean-harness:conductor`, `redsen-lean-harness:architect`, etc. (confirmed via
+> `redsen-lean-harness:conductor`, `redsen-lean-harness:architect`, etc. **Skills are never
-> `copilot --agent <bad-name>`, whose error message lists every real agent name it knows,
+> namespaced** — `/fast-track`, `/design`, `/build`, `/verify`, `/onboard`, etc. work as plain
-> always namespaced for plugin-sourced agents). **Skills are never namespaced** —
+> slash commands regardless of install method.
 > `/fast-track`, `/design`, `/build`, `/verify`, `/onboard`, etc. work as plain slash commands
 > regardless of install method (confirmed via `copilot plugins list --kind skill --json`, whose
 > `name` fields carry no prefix).
 >
-> **Known limitation:** a plugin-sourced agent can be launched (by full name in a prompt, or
+> **If `/agent` doesn't list it, or invoking it reports "not found":** the plugin is stale. Run
-> via `--agent=plugin-name:agent-name`) even when it isn't proactively *suggested*. Copilot's
+> `copilot plugin update redsen-lean-harness` (or `copilot plugin marketplace update redsen &&
-> own `copilot plugins list` command documents that "custom agents ... require a live session
+> copilot plugin update redsen-lean-harness` if that alone doesn't refresh it), then start a
-> and will be added in a follow-up" — i.e. the CLI's own agent-introspection tooling doesn't
+> **brand-new** `copilot` session — an already-running session keeps the plugin snapshot it
-> yet fully cover plugin-contributed agents, which likely also affects what the `/agent` picker
+> loaded at startup and won't pick up the update until restarted.
 > surfaces and what the model volunteers unprompted. Naming the agent explicitly
 > (`Use the conductor agent to ...`) reliably works around this today.
 >
 > If naming the agent explicitly still fails: the plugin was likely loaded before a fix landed.
 > Run `copilot plugin marketplace update redsen && copilot plugin update redsen-lean-harness`,
 > then start a **new** `copilot` session — an already-running session keeps the plugin
 > snapshot it loaded at startup and won't pick up the update until restarted.
 For a small brownfield change, skip the ceremony:
@@ -224,7 +225,7 @@ global install.
 ## Pipeline
 ```
-design    → interrogator asks, user answers          → decisions.md      [USER GATE]
+design    → conductor asks (inline), user answers     → decisions.md      [USER GATE]
 plan      → architect writes spec + acceptance criteria
            splitter emits plan.dag.json (lanes + file scopes)
 build     → lh host picks the strategy
@@ -252,8 +253,7 @@ escalates to you.
 | Agent | Tier | Invokable | Responsibility |
 | --- | --- | --- | --- |
-| `conductor` | strong | yes | Entry point. Owns the pipeline and the dynamic DAG. |
+| `conductor` | strong | yes | Single entry point. Asks design questions itself, then owns the pipeline and the dynamic DAG. |
 | `interrogator` | strong | yes | Design-phase Q&A with recommended answers. |
 | `scout` | cheap | – | Read-only recon, fanned out N-wide. |
 | `architect` | strong | yes | Spec, acceptance criteria, architecture doc, ADRs. |
 | `splitter` | mid | – | Decomposes the spec into lanes with file-scope globs. |
@@ -103,47 +103,45 @@ This creates a per-repo `.agents/` footprint:
 Open Copilot CLI or VS Code Copilot in the project and pick the entry point that matches the
 size of the change.
-**Full pipeline** (new feature, non-trivial change):
+**Full pipeline** (new feature, non-trivial change). `conductor` is the **single entry
 point** — it asks every design question itself, directly, in its own turn:
 ```
 Use the conductor agent to build a rate limiter for the public API
 ```
-> **How agent invocation actually works** (per the [official docs](https://docs.github.com/en/copilot/how-tos/copilot-cli/use-copilot-cli/invoke-custom-agents)):
+If `.agents/specs/<slug>/decisions.md` is missing or incomplete, `conductor` asks its own
-> `@` in Copilot CLI **only mentions files**, never agents. There are three real ways to invoke
+numbered questions right there (each with a recommended answer, a `Why:`, and a freeform
-> a custom agent:
+`Other:` option), then stops and waits for your real reply. It never guesses, infers, or
-> 1. `/agent` — opens an interactive picker to browse and select.
+delegates the question to a subagent — subagent calls in Copilot CLI are stateless (they run
 to completion and return one final result; they cannot pause mid-task for a live human reply)
 — so you must answer before the pipeline proceeds.
 > **How to invoke a custom agent** (per the [official docs](https://docs.github.com/en/copilot/how-tos/copilot-cli/use-copilot-cli/invoke-custom-agents)):
 > `@` in Copilot CLI **only mentions files**, never agents. There are three ways:
 > 1. `/agent` → pick `conductor` from the list, then press **Enter to confirm the selection**
 >    before typing your build prompt (selecting and prompting are two separate steps).
 > 2. Name it in your prompt — `Use the conductor agent to ...` — Copilot infers which agent you mean.
 > 3. `copilot --agent=NAME -p "..."` — force a specific agent non-interactively.
 >
 > **Agent name note:** inside this repo (or any repo where the harness lives natively in
 > `.github/agents`), the bare name `conductor` resolves. Once installed as a *plugin* into
 > another project, Copilot CLI namespaces **agents only** — the resolvable name becomes
-> `redsen-lean-harness:conductor`, `redsen-lean-harness:architect`, etc. (confirmed via
+> `redsen-lean-harness:conductor`, `redsen-lean-harness:architect`, etc. **Skills are never
-> `copilot --agent <bad-name>`, whose error message lists every real agent name it knows,
+> namespaced** — `/fast-track`, `/design`, `/build`, `/verify`, `/onboard`, etc. work as plain
-> always namespaced for plugin-sourced agents). **Skills are never namespaced** —
+> slash commands regardless of install method.
 > `/fast-track`, `/design`, `/build`, `/verify`, `/onboard`, etc. work as plain slash commands
 > regardless of install method (confirmed via `copilot plugins list --kind skill --json`, whose
 > `name` fields carry no prefix).
 >
-> **Known limitation:** a plugin-sourced agent can be launched (by full name in a prompt, or
+> **If `/agent` doesn't list it, or invoking it reports "not found":** the plugin is stale. Run
-> via `--agent=plugin-name:agent-name`) even when it isn't proactively *suggested*. Copilot's
+> `copilot plugin update redsen-lean-harness` (or `copilot plugin marketplace update redsen &&
-> own `copilot plugins list` command documents that "custom agents ... require a live session
+> copilot plugin update redsen-lean-harness` if that alone doesn't refresh it), then start a
-> and will be added in a follow-up" — i.e. the CLI's own agent-introspection tooling doesn't
+> **brand-new** `copilot` session — an already-running session keeps the plugin snapshot it
-> yet fully cover plugin-contributed agents, which likely also affects what the `/agent` picker
+> loaded at startup and won't pick up the update until restarted.
 > surfaces and what the model volunteers unprompted. Naming the agent explicitly
 > (`Use the conductor agent to ...`) reliably works around this today.
 >
 > If naming the agent explicitly still fails: the plugin was likely loaded before a fix landed.
 > Run `copilot plugin marketplace update redsen && copilot plugin update redsen-lean-harness`,
 > then start a **new** `copilot` session — an already-running session keeps the plugin
 > snapshot it loaded at startup and won't pick up the update until restarted.
-This runs the whole pipeline: `interrogator` asks clarifying questions with recommended
+This runs the whole pipeline: `conductor` asks clarifying questions itself with recommended
-answers (you must answer before it proceeds — this is a deliberate gate), `architect` writes
+answers (you must answer before it proceeds — this is a deliberate gate), then `architect`
-the spec and acceptance criteria, `splitter` breaks it into lanes, `builder`/`verifier` run the
+writes the spec and acceptance criteria, `splitter` breaks it into lanes, `builder`/`verifier`
-Ralph loop per lane (in parallel git worktrees when lanes don't overlap), `integrator` merges
+run the Ralph loop per lane (in parallel git worktrees when lanes don't overlap), `integrator`
-sequentially, and `scribe` journals everything as it happens.
+merges sequentially, and `scribe` journals everything as it happens.
 **Small brownfield fix** (skip spec + DAG ceremony):
@@ -166,11 +164,11 @@ subcommand, who calls it, and when.
 | Command | Who runs it | When |
 | --- | --- | --- |
-| `lh index` | `interrogator`, `scout`, `architect`, `splitter` | Automatically, before reading files, to build token-budgeted context |
+| `lh index` | `conductor`, `scout`, `architect`, `splitter` | Automatically, before reading files, to build token-budgeted context |
 | `lh host` | `conductor` | Automatically, first thing, to pick parallel-vs-sequential strategy |
 | `lh run start/event/end` | `conductor` (start/end), every agent (event) | Automatically, for every phase transition — never skipped |
 | `lh lane create/status/merge` | `conductor`, `builder`, `integrator` | Automatically, before a write lane starts and when it merges |
-| `lh memory get/put/scan` | `interrogator`, `architect`, `builder`, `scribe` | Automatically, to pull relevant shards before work and record facts/failures after |
+| `lh memory get/put/scan` | `conductor`, `architect`, `builder`, `scribe` | Automatically, to pull relevant shards before work and record facts/failures after |
 | `lh graph` | `verifier` (always), plus `architect`/`splitter`/`conductor`/`reviewer`/`scout`/`integrator` at their own checkpoints | Automatically — it's exit criterion #3, never skipped |
 | `lh doctor` | `conductor` (first thing, before `lh host`), also you whenever you want to check the environment yourself | Automatically at the start of every pipeline run — `conductor`'s step 1 |
 | `lh init --yes` | `conductor`, automatically, only if `lh doctor` reports `config not initialised` | Self-heals a missing `.agents/` baseline with non-interactive defaults, then re-runs `lh doctor` |
@@ -225,7 +223,7 @@ Everything the harness does is self-documenting — nothing lives only in a chat
 | `copilot plugin install owner/repo` prints a deprecation warning | Expected for direct-source installs. Use `copilot plugin marketplace add` + `copilot plugin install name@marketplace` instead (path A) |
 | `npm install -g @redsentech/lean-harness` gives `404`/`403` | `.npmrc` isn't pointed at GitHub Packages, or the token lacks `read:packages`. Run `node scripts/setup-npm-registry.mjs` — see [Generating a GitHub token](../README.md#generating-a-github-token) if you don't have one yet |
 | `setup-npm-registry.mjs` doesn't open a browser (SSH/headless) | Expected — it falls back to printing the token creation URL. Pass `--no-open` to skip the attempt entirely |
-| Pipeline stuck at design gate | `interrogator` is waiting on your answers — this is intentional, answer the questions |
+| Pipeline stuck at design gate | `conductor` is waiting on your answers — this is intentional, answer the questions |
 ## Next steps
@@ -12,7 +12,6 @@ export const MODEL_TIERS = ['cheap', 'mid', 'strong'];
 export const ROLE_TIERS = {
  conductor: 'strong',
  interrogator: 'strong',
  scout: 'cheap',
  architect: 'strong',
  splitter: 'mid',