diff --git a/.agents/harness.config.json b/.agents/harness.config.json index 5756b4f..893d4d4 100644 --- a/.agents/harness.config.json +++ b/.agents/harness.config.json @@ -49,7 +49,6 @@ }, "roles": { "conductor": "strong", - "interrogator": "strong", "scout": "cheap", "architect": "strong", "splitter": "mid", diff --git a/.github/agents/conductor.agent.md b/.github/agents/conductor.agent.md index b04ca84..05b1b7b 100644 --- a/.github/agents/conductor.agent.md +++ b/.github/agents/conductor.agent.md @@ -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`. -15. Require `.agents/specs//decisions.md` before planning. -16. Enforce the user gate after design. -17. Do not infer unanswered decisions. +14. For design: check `.agents/specs//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//decisions.md` complete before planning. +16. Enforce the user gate after design: do not proceed until every required question has a real user answer. +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//spec.md`. 20. Invoke `splitter` to write `.agents/specs//plan.dag.json`. @@ -54,18 +59,44 @@ Run the full lean harness pipeline. Edit no product files. 39. Run `lh run end --run-id --status ok|error [--summary ""]` 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//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 [--query ] [--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//decisions.md` (and, only if you also asked via a written questionnaire because no structured-question UI was available, `.agents/specs//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//decisions.md`. +- Read `.agents/specs//questionnaire.md` when resuming a design phase. - Read `.agents/specs//spec.md`. - Read `.agents/specs//plan.dag.json`. - Read `.agents/runs//board.md`. - Read `.agents/runs//events.ndjson`. +- Read `templates/questionnaire.md` for shape only. ## OUTPUTS +- Write `.agents/specs//questionnaire.md` only if no structured-question UI is available. +- Write `.agents/specs//decisions.md` once the user has answered every required question. - Write `.agents/specs//plan.dag.json` when re-planning. - Write `.agents/runs//board.md` through `lh run event`. - Write `.agents/runs//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. diff --git a/.github/agents/interrogator.agent.md b/.github/agents/interrogator.agent.md deleted file mode 100644 index 6be239c..0000000 --- a/.github/agents/interrogator.agent.md +++ /dev/null @@ -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 [--query ] [--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//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//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//questionnaire.md` when resuming. -- Read `.agents/specs//decisions.md` when resuming. -- Read `templates/questionnaire.md` for shape only. - -## OUTPUTS - -- Write `.agents/specs//questionnaire.md`. -- Write `.agents/specs//decisions.md`. -- Append design events through `lh run event` when a run id exists. - -## STOP CONDITIONS - -- Stop when `.agents/specs//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//`. -- Never start planning. diff --git a/.github/prompts/design.prompt.md b/.github/prompts/design.prompt.md index e65732e..3d44939 100644 --- a/.github/prompts/design.prompt.md +++ b/.github/prompts/design.prompt.md @@ -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//questionnaire.md` and `.agents/specs//decisions.md`. If VS Code cannot run parallel subagents, proceed sequentially. diff --git a/.github/skills/design/SKILL.md b/.github/skills/design/SKILL.md index fb5fa54..cb8c9c2 100644 --- a/.github/skills/design/SKILL.md +++ b/.github/skills/design/SKILL.md @@ -5,10 +5,13 @@ description: Use when starting gated design discovery before planning, especiall # design skill -1. Invoke `.github/agents/interrogator.agent.md`. -2. Require numbered questions with numbered recommended answers. +1. Invoke `.github/agents/conductor.agent.md` and run only its DESIGN PHASE section. +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//decisions.md`. -5. Stop until every required question is answered. +4. Always include a freeform `Other:` option. +5. Persist final answers to `.agents/specs//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. diff --git a/AGENTS.md b/AGENTS.md index c0e9230..dd3283c 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -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//decisions.md +design → conductor asks inline, user answers → .agents/specs//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. | -| `interrogator` | strong | yes | Design-phase Q&A with recommended answers. | +| `conductor` | strong | yes | Single entry point. Asks design questions itself, then owns the pipeline and the dynamic DAG. | | `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. | diff --git a/README.md b/README.md index 8c1bc55..c4da1e2 100644 --- a/README.md +++ b/README.md @@ -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)): -> `@` in Copilot CLI **only mentions files**, never agents. There are three real ways to invoke -> a custom agent: -> 1. `/agent` — opens an interactive picker to browse and select. +If `.agents/specs//decisions.md` is missing or incomplete, `conductor` asks its own +numbered questions right there in its response (each with a recommended answer, a `Why:`, and +a freeform `Other:` option), then stops and waits for your real reply. It never guesses, +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 -> `copilot --agent `, whose error message lists every real agent name it knows, -> always namespaced for plugin-sourced agents). **Skills are never namespaced** — -> `/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). +> `redsen-lean-harness:conductor`, `redsen-lean-harness:architect`, etc. **Skills are never +> namespaced** — `/fast-track`, `/design`, `/build`, `/verify`, `/onboard`, etc. work as plain +> slash commands regardless of install method. > -> **Known limitation:** a plugin-sourced agent can be launched (by full name in a prompt, or -> via `--agent=plugin-name:agent-name`) even when it isn't proactively *suggested*. Copilot's -> own `copilot plugins list` command documents that "custom agents ... require a live session -> and will be added in a follow-up" — i.e. the CLI's own agent-introspection tooling doesn't -> yet fully cover plugin-contributed agents, which likely also affects what the `/agent` picker -> 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. +> **If `/agent` doesn't list it, or invoking it reports "not found":** the plugin is stale. Run +> `copilot plugin update redsen-lean-harness` (or `copilot plugin marketplace update redsen && +> copilot plugin update redsen-lean-harness` if that alone doesn't refresh it), then start a +> **brand-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. | -| `interrogator` | strong | yes | Design-phase Q&A with recommended answers. | +| `conductor` | strong | yes | Single entry point. Asks design questions itself, then owns the pipeline and the dynamic DAG. | | `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. | diff --git a/docs/QUICKSTART.md b/docs/QUICKSTART.md index 1c664f6..14d54d2 100644 --- a/docs/QUICKSTART.md +++ b/docs/QUICKSTART.md @@ -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)): -> `@` in Copilot CLI **only mentions files**, never agents. There are three real ways to invoke -> a custom agent: -> 1. `/agent` — opens an interactive picker to browse and select. +If `.agents/specs//decisions.md` is missing or incomplete, `conductor` asks its own +numbered questions right there (each with a recommended answer, a `Why:`, and a freeform +`Other:` option), then stops and waits for your real reply. It never guesses, 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 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 -> `copilot --agent `, whose error message lists every real agent name it knows, -> always namespaced for plugin-sourced agents). **Skills are never namespaced** — -> `/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). +> `redsen-lean-harness:conductor`, `redsen-lean-harness:architect`, etc. **Skills are never +> namespaced** — `/fast-track`, `/design`, `/build`, `/verify`, `/onboard`, etc. work as plain +> slash commands regardless of install method. > -> **Known limitation:** a plugin-sourced agent can be launched (by full name in a prompt, or -> via `--agent=plugin-name:agent-name`) even when it isn't proactively *suggested*. Copilot's -> own `copilot plugins list` command documents that "custom agents ... require a live session -> and will be added in a follow-up" — i.e. the CLI's own agent-introspection tooling doesn't -> yet fully cover plugin-contributed agents, which likely also affects what the `/agent` picker -> 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. +> **If `/agent` doesn't list it, or invoking it reports "not found":** the plugin is stale. Run +> `copilot plugin update redsen-lean-harness` (or `copilot plugin marketplace update redsen && +> copilot plugin update redsen-lean-harness` if that alone doesn't refresh it), then start a +> **brand-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 -answers (you must answer before it proceeds — this is a deliberate gate), `architect` writes -the spec and acceptance criteria, `splitter` breaks it into lanes, `builder`/`verifier` run the -Ralph loop per lane (in parallel git worktrees when lanes don't overlap), `integrator` merges -sequentially, and `scribe` journals everything as it happens. +This runs the whole pipeline: `conductor` asks clarifying questions itself with recommended +answers (you must answer before it proceeds — this is a deliberate gate), then `architect` +writes the spec and acceptance criteria, `splitter` breaks it into lanes, `builder`/`verifier` +run the Ralph loop per lane (in parallel git worktrees when lanes don't overlap), `integrator` +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 diff --git a/src/lib/config.mjs b/src/lib/config.mjs index b498170..c70c6d9 100644 --- a/src/lib/config.mjs +++ b/src/lib/config.mjs @@ -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',