Big News: Socket raises $60M Series C at a $1B valuation to secure software supply chains for AI-driven development.Announcement →
agestra - npm Package Compare versions
@@ -15,3 +15,3 @@ { | ||
| "description": "Multi-host MCP orchestration across Claude, Ollama, Gemini, and Codex for review, QA, and cross-validation", | ||
| "version": "4.14.2", | ||
| "version": "4.14.3", | ||
| "author": { | ||
@@ -18,0 +18,0 @@ "name": "mua-vtuber" |
| { | ||
| "name": "agestra", | ||
| "version": "4.14.2", | ||
| "version": "4.14.3", | ||
| "description": "Claude Code plugin — multi-host MCP orchestration across Claude, Ollama, Gemini, and Codex for review, QA, and cross-validation", | ||
@@ -5,0 +5,0 @@ "mcpServers": { |
@@ -24,3 +24,3 @@ --- | ||
| codexSandboxMode: read-only | ||
| tools: Read, Glob, Grep, Bash, WebFetch, WebSearch, TodoWrite, AskUserQuestion, Skill, ToolSearch, CronCreate, CronList, CronDelete, Agent, mcp__plugin_agestra_agestra__environment_check, mcp__plugin_agestra_agestra__provider_list, mcp__plugin_agestra_agestra__provider_health, mcp__plugin_agestra_agestra__trace_query, mcp__plugin_agestra_agestra__trace_summary, mcp__plugin_agestra_agestra__trace_visualize, mcp__plugin_agestra_agestra__ai_chat, mcp__plugin_agestra_agestra__ai_analyze_files, mcp__plugin_agestra_agestra__ai_compare, mcp__plugin_agestra_agestra__agent_research_consensus_start, mcp__plugin_agestra_agestra__agent_consensus_start, mcp__plugin_agestra_agestra__agent_debate_status, mcp__plugin_agestra_agestra__agent_consensus_submit_turn, mcp__plugin_agestra_agestra__agent_debate_approve, mcp__plugin_agestra_agestra__agent_debate_continue, mcp__plugin_agestra_agestra__agent_debate_reject, mcp__plugin_agestra_agestra__agent_cross_validate, mcp__plugin_agestra_agestra__cli_worker_spawn, mcp__plugin_agestra_agestra__cli_worker_status, mcp__plugin_agestra_agestra__cli_worker_collect, mcp__plugin_agestra_agestra__cli_worker_stop, mcp__plugin_agestra_agestra__agent_changes_review, mcp__plugin_agestra_agestra__agent_changes_accept, mcp__plugin_agestra_agestra__agent_changes_reject, mcp__plugin_agestra_agestra__workspace_create_document, mcp__plugin_agestra_agestra__workspace_read, mcp__plugin_agestra_agestra__workspace_list | ||
| tools: Read, Glob, Grep, Bash, WebFetch, WebSearch, TodoWrite, AskUserQuestion, Skill, ToolSearch, CronCreate, CronList, CronDelete, Agent, mcp__plugin_agestra_agestra__environment_check, mcp__plugin_agestra_agestra__provider_list, mcp__plugin_agestra_agestra__provider_health, mcp__plugin_agestra_agestra__provider_readiness, mcp__plugin_agestra_agestra__provider_trust_apply, mcp__plugin_agestra_agestra__run_observable_events, mcp__plugin_agestra_agestra__trace_query, mcp__plugin_agestra_agestra__trace_summary, mcp__plugin_agestra_agestra__trace_visualize, mcp__plugin_agestra_agestra__ai_chat, mcp__plugin_agestra_agestra__ai_analyze_files, mcp__plugin_agestra_agestra__ai_compare, mcp__plugin_agestra_agestra__agent_research_consensus_start, mcp__plugin_agestra_agestra__agent_consensus_start, mcp__plugin_agestra_agestra__agent_debate_status, mcp__plugin_agestra_agestra__agent_consensus_submit_turn, mcp__plugin_agestra_agestra__agent_debate_approve, mcp__plugin_agestra_agestra__agent_debate_continue, mcp__plugin_agestra_agestra__agent_debate_reject, mcp__plugin_agestra_agestra__agent_cross_validate, mcp__plugin_agestra_agestra__cli_worker_spawn, mcp__plugin_agestra_agestra__cli_worker_status, mcp__plugin_agestra_agestra__cli_worker_collect, mcp__plugin_agestra_agestra__cli_worker_stop, mcp__plugin_agestra_agestra__agent_changes_review, mcp__plugin_agestra_agestra__agent_changes_accept, mcp__plugin_agestra_agestra__agent_changes_reject, mcp__plugin_agestra_agestra__workspace_create_document, mcp__plugin_agestra_agestra__workspace_read, mcp__plugin_agestra_agestra__workspace_list | ||
| --- | ||
@@ -98,2 +98,32 @@ | ||
| <Research_And_Consensus> | ||
| Domain skills provide the domain-specific question sheet output. Do not repeat | ||
| the full domain interview when the handoff packet already contains target, | ||
| scope, depth/lens, constraints, and report expectations. | ||
| For provider-backed idea, design, review, security, and explicit research work, | ||
| honor the handoff's `research_topology` / `조사 방식`. Use canonical topology | ||
| values in MCP calls: `host-seeded`, `council`, or `provider-seeded` | ||
| (`host-led` may appear only as a legacy/user-facing alias for `host-seeded`). | ||
| - `host-seeded`: the current host and host-native `agestra-research` prepare the | ||
| first evidence/aggregation; external providers primarily challenge, revise, | ||
| and debate prepared items. | ||
| - `council`: host-native researchers and external providers receive independent | ||
| investigation assignments before consolidation. Before fan-out, create or | ||
| confirm a bounded assignment table when the handoff does not already include | ||
| approved rows. | ||
| - `provider-seeded`: one configured provider creates the first seed/evidence | ||
| artifact; host-native and other provider participants independently challenge | ||
| it. If the seed provider is missing or unavailable, ask once for a replacement | ||
| or fall back to `host-seeded` when asking is blocked. | ||
| - `automatic`: choose the lightest topology that preserves quality. Prefer | ||
| `host-seeded` for bounded/scoped work, `council` for broad/open-ended discovery, | ||
| and `provider-seeded` only when the user named a seed provider or explicitly | ||
| asked a provider to lead the investigation. | ||
| If provider-backed work needs a research topology but the handoff omitted it, | ||
| ask one concise topology question. This is a cost/latency gate, not a domain | ||
| clarification. If a host-level no-questions directive prevents asking, choose | ||
| `host-seeded` and report that external investigation fan-out was limited. | ||
| Use `agent_research_consensus_start` when the task needs investigation before | ||
@@ -166,2 +196,44 @@ provider consensus. The host owns research planning, research collection, | ||
| <QA_Brigade_Execution> | ||
| For `/agestra qa`, do not assume provider-backed mode just because providers are | ||
| configured. If the handoff packet does not already contain a user-selected mode, | ||
| ask once for Host-only QA, QA Brigade, or Decide automatically. | ||
| That mode selection is a cost/permission gate, not a clarifying question. If a | ||
| host-level no-questions directive prevents asking, choose Host-only QA and | ||
| report that provider fan-out was skipped. Trust registration is a separate | ||
| security approval gate: no-questions / keep-going instructions are not user | ||
| approval. If providers are workspace-blocked, ask once and then call | ||
| `provider_trust_apply` once per approved provider. Use batch trust only when the | ||
| host permission model explicitly permits it. | ||
| Default QA Brigade is a fast host-prepared consensus path: | ||
| 1. Run the host-owned evidence pass first (`qa_run`, design/progress inspection, | ||
| code/file evidence, and E2E/runtime artifacts when selected). | ||
| 2. Use host-native `agestra-research` only through the active host's native | ||
| agent surface for narrow evidence assignments. Never put `agestra-research` | ||
| in the external provider `participants` list. | ||
| 3. Prepare `initial_aggregation.items` from concrete evidence. Include only | ||
| findings or disputed claims that external providers can cross-check from the | ||
| provided artifacts. | ||
| 4. Call `agent_consensus_start`, not `agent_research_consensus_start`, for the | ||
| default QA Brigade round. Use exact provider participants, optional | ||
| `participant_routes` for a host-native `agestra-debate` participant, | ||
| `max_rounds: 1` for Standard QA, and a bounded participant timeout. | ||
| 5. Poll `agent_debate_status` and `run_observable_events` when a locator is | ||
| available while provider work is running. Surface concise progress at least | ||
| every 30-60 seconds. If this agent is running in a background mode whose | ||
| progress cannot reach the user, tell the caller to poll and relay progress, | ||
| or fall back to Host-only QA for the current run. If the status reports | ||
| pending host turns, dispatch the `agestra-debate` native agent with the | ||
| pending packet, then submit the JSON using `agent_consensus_submit_turn`. | ||
| Use `agent_research_consensus_start` for QA only when the user explicitly asks | ||
| for deep external-provider research before consensus. In that exception, | ||
| external AI research and debate run in separate fresh sessions. The default QA | ||
| Brigade should avoid that extra research round because the host already owns the | ||
| executable QA evidence. | ||
| </QA_Brigade_Execution> | ||
| <E2E_Test_Authoring> | ||
@@ -168,0 +240,0 @@ Persistent E2E work is an implementation sub-mode, not a standalone agent. |
+21
-7
@@ -24,3 +24,3 @@ --- | ||
| Before any provider fan-out, run the shared workspace trust preflight for the exact current project root. If supported providers are blocked, ask once whether to register only this project folder, then call `provider_trust_apply_all` after approval. | ||
| Before any provider fan-out, run the shared workspace trust preflight for the exact current project root. If supported providers are blocked, ask once whether to register only this project folder. This is a security approval gate, not a clarifying question; "keep going" / no-questions instructions are not approval. After approval, call `provider_trust_apply` once per blocked provider. Use `provider_trust_apply_all` only when the host permission model explicitly allows batch trust changes. If approval cannot be obtained, skip blocked providers. | ||
@@ -55,3 +55,3 @@ ## Step 1: Determine design subject | ||
| - **Research notes:** existing patterns in this codebase, prior art / competing implementations, constraints / regulations, current-information needs, or `skip` | ||
| - **Research assignments:** any preferred participant/lens split for host-led investigation, or `skip` | ||
| - **Research assignments:** any preferred participant/lens split for the selected investigation, or `skip` | ||
@@ -66,2 +66,15 @@ Nice-to-know details: | ||
| ## Step 2: Choose 조사 방식 | ||
| Before provider fan-out, ask once which investigation topology to use unless the user already specified it: | ||
| | Option | Description | | ||
| |--------|-------------| | ||
| | **Host-led Research (Recommended)** | The current host/native researchers inspect the codebase and prepare the first design evidence packet; providers challenge and debate it. Record internally as `host-seeded`. | | ||
| | **Council Research** | Host and providers independently investigate design options with assigned lenses before consolidation and debate. | | ||
| | **Provider-seeded Research** | One selected provider creates the first design seed/evidence artifact; host and other providers challenge it. | | ||
| | **Decide automatically** | Use Host-led for bounded design work, Council for broad architecture exploration, and Provider-seeded only when the user named a provider to lead. | | ||
| Use `AskUserQuestion` when available, or a plain numbered prompt as fallback. This is a cost/latency gate, not a design clarification. If a host-level no-questions directive prevents asking, choose Host-led Research (`host-seeded`) and report that broader provider investigation was skipped. If Provider-seeded Research is selected and the seed provider is not explicit, record the seed provider as pending; after provider availability is listed, ask which available provider should seed. Do not infer it. | ||
| Default design principles: | ||
@@ -76,3 +89,3 @@ - Prefer maintainable structure and code quality over easy/fast patchwork | ||
| ## Step 2: Route execution | ||
| ## Step 3: Route execution | ||
@@ -87,3 +100,3 @@ Call `environment_check` and `provider_list` to determine which providers and execution options are available. | ||
| **Provider-backed path — 1+ external providers available (multi-AI):** | ||
| Hand off to the `agestra:agestra-team-lead` agent with multi-AI mode **pre-selected**. Provider-backed design uses the host research consensus flow: | ||
| Hand off to the `agestra:agestra-team-lead` agent with multi-AI mode **pre-selected**. Provider-backed design uses the selected research topology flow: | ||
@@ -106,3 +119,4 @@ ```text | ||
| - **Consensus domain:** `design` | ||
| - **Research notes:** what the host-led investigation should look for (existing patterns, prior art, constraints, current-information needs) | ||
| - **Research topology / 조사 방식:** selected in Step 2 (`host-seeded`, `council`, `provider-seeded`, or `automatic`) | ||
| - **Research notes:** what the selected investigation should look for (existing patterns, prior art, constraints, current-information needs) | ||
| - **Research assignments:** optional participant/lens rows for `research_assignments` | ||
@@ -117,3 +131,3 @@ - **Available providers:** from `environment_check` / `provider_list` | ||
| - Building the participant team from focused research lenses, explicit host-turn debate participants, and external providers when applicable | ||
| - Calling `agent_research_consensus_start` with `domain: "design"`, the design `objective`, `participants`, optional `research_assignments`, optional `provider_order`, bounded `max_rounds`, and output document flags. | ||
| - Resolving the selected research topology, then calling `agent_research_consensus_start` when investigation fan-out is required or `agent_consensus_start` with prepared `initial_aggregation.items` when seed/host evidence is already available. | ||
| - Ensuring external AI research and debate use separate fresh sessions. | ||
@@ -131,3 +145,3 @@ - Never creating a bundled research pseudo-participant and never carrying research bundles through `source_documents`. | ||
| ## Step 3: Present the result | ||
| ## Step 4: Present the result | ||
@@ -134,0 +148,0 @@ When team-lead returns: |
+23
-8
@@ -24,3 +24,3 @@ --- | ||
| Before any provider fan-out, run the shared workspace trust preflight for the exact current project root. If supported providers are blocked, ask once whether to register only this project folder, then call `provider_trust_apply_all` after approval. | ||
| Before any provider fan-out, run the shared workspace trust preflight for the exact current project root. If supported providers are blocked, ask once whether to register only this project folder. This is a security approval gate, not a clarifying question; "keep going" / no-questions instructions are not approval. After approval, call `provider_trust_apply` once per blocked provider. Use `provider_trust_apply_all` only when the host permission model explicitly allows batch trust changes. If approval cannot be obtained, skip blocked providers. | ||
@@ -44,3 +44,3 @@ ## Step 1: Determine topic | ||
| - **Research notes:** competitor landscape, positive/negative user reactions, current-information needs, source constraints, or `skip` | ||
| - **Research assignments:** any preferred participant/lens split for host-led investigation, or `skip` | ||
| - **Research assignments:** any preferred participant/lens split for the selected investigation, or `skip` | ||
| - **Protected identity/boundaries:** what should not change, or `unspecified` | ||
@@ -57,3 +57,3 @@ - **Free notes:** anything else the user wants to say, or `skip` | ||
| - **Research notes:** similar apps, competitor/user-reaction depth, current-information needs, source constraints, or `skip` | ||
| - **Research assignments:** any preferred participant/lens split for host-led investigation, or `skip` | ||
| - **Research assignments:** any preferred participant/lens split for the selected investigation, or `skip` | ||
| - **Free notes:** rough thoughts are welcome, or `skip` | ||
@@ -65,4 +65,17 @@ | ||
| Provider-backed `/agestra idea` uses the host research consensus flow: | ||
| ## Step 2: Choose 조사 방식 | ||
| Before provider fan-out, ask once which investigation topology to use unless the user already specified it: | ||
| | Option | Description | | ||
| |--------|-------------| | ||
| | **Host-led Research (Recommended)** | The current host prepares the first evidence packet, then providers challenge and debate it. Fastest and lowest-cost default. Record internally as `host-seeded`. | | ||
| | **Council Research** | Host and providers independently investigate assigned lenses before consolidation and debate. Stronger for broad/open-ended exploration. | | ||
| | **Provider-seeded Research** | One selected provider creates the first seed/evidence artifact, then host and other providers challenge it. | | ||
| | **Decide automatically** | Use Host-led for bounded topics, Council for broad idea discovery, and Provider-seeded only when the user named a provider to lead. | | ||
| Use `AskUserQuestion` when available, or a plain numbered prompt as fallback. This is a cost/latency gate, not a domain clarification. If a host-level no-questions directive prevents asking, choose Host-led Research (`host-seeded`) and report that broader provider investigation was skipped. If Provider-seeded Research is selected and the seed provider is not explicit, record the seed provider as pending; after provider availability is listed, ask which available provider should seed. Do not infer it. | ||
| Provider-backed `/agestra idea` uses the selected research topology flow: | ||
| ```text | ||
@@ -77,3 +90,3 @@ 호스트가 조사한다. | ||
| ## Step 2: Route execution | ||
| ## Step 3: Route execution | ||
@@ -96,3 +109,4 @@ Call `environment_check` and `provider_list` to determine available providers. | ||
| - **Consensus domain:** `idea` | ||
| - **Research notes:** what the host-led investigation should look for | ||
| - **Research topology / 조사 방식:** selected in Step 2 (`host-seeded`, `council`, `provider-seeded`, or `automatic`) | ||
| - **Research notes:** what the selected investigation should look for | ||
| - **Research assignments:** optional participant/lens rows for `research_assignments` | ||
@@ -107,3 +121,4 @@ - **Available providers:** from `environment_check` | ||
| - Building the participant team from idea research lenses, explicit host-turn debate participants, and external providers. External providers are MCP/CLI/chat participants only. | ||
| - Calling `agent_research_consensus_start` with `domain: "idea"`, the idea `objective`, `participants`, optional `research_assignments`, optional `provider_order`, bounded `max_rounds`, and output document flags. | ||
| - Resolving the selected research topology, then calling `agent_research_consensus_start` when investigation fan-out is required or `agent_consensus_start` with prepared `initial_aggregation.items` when seed/host evidence is already available. | ||
| - For research fan-out, pass `domain: "idea"` to `agent_research_consensus_start`. | ||
| - Ensuring external AI research and debate use separate fresh sessions. | ||
@@ -124,3 +139,3 @@ - Never creating a bundled research pseudo-participant and never carrying research bundles through `source_documents`. | ||
| ## Step 3: Present to the user | ||
| ## Step 4: Present to the user | ||
@@ -127,0 +142,0 @@ When team-lead returns: |
@@ -24,3 +24,3 @@ --- | ||
| Before any provider fan-out or `cli_worker_spawn`, run the shared workspace trust preflight for the exact current project root. If supported providers are blocked, ask once whether to register only this project folder, then call `provider_trust_apply_all` after approval. | ||
| Before any provider fan-out or `cli_worker_spawn`, run the shared workspace trust preflight for the exact current project root. If supported providers are blocked, ask once whether to register only this project folder. This is a security approval gate, not a clarifying question; "keep going" / no-questions instructions are not approval. After approval, call `provider_trust_apply` once per blocked provider. Use `provider_trust_apply_all` only when the host permission model explicitly allows batch trust changes. If approval cannot be obtained, skip blocked providers. | ||
@@ -83,7 +83,7 @@ ## Step 1: Determine implementation target | ||
| Determine QA routing separately from implementation routing: | ||
| - When configured external providers are available, team-lead routes post-implementation QA through the QA Brigade. | ||
| - When configured external providers are available, team-lead may route post-implementation QA through the QA Brigade, but it should still avoid an extra external research phase unless the user explicitly asked for deep provider research. | ||
| - If executable checks are required, the host owns command/browser/runtime evidence collection and providers review that evidence. | ||
| - E2E/runtime execution is always host-owned. External providers may review the host QA report, command output, screenshots, traces, and E2E findings, but they must not run browser/dev-server flows or create persistent E2E files directly. | ||
| - QA-only mode does not modify product code; connection or boundary defects are findings until the user approves a separate implementation task. | ||
| - Provider-backed QA uses the host research consensus flow through `agent_research_consensus_start` with `domain: "qa"`: | ||
| - Provider-backed QA uses the fast host-prepared consensus path by default: | ||
@@ -97,3 +97,3 @@ ```text | ||
| External AI research and debate run in separate fresh sessions, even when the same provider participates in both phases. | ||
| The host prepares executable QA evidence first, then providers cross-check prepared `initial_aggregation.items` through `agent_consensus_start`. Use `agent_research_consensus_start` for QA only when the user explicitly asks for deep external-provider research; in that exception, External AI research and debate run in separate fresh sessions, even when the same provider participates in both phases. | ||
@@ -100,0 +100,0 @@ ## Step 5: Execute via team-lead |
+43
-15
@@ -22,3 +22,3 @@ --- | ||
| Before any provider fan-out, run the shared workspace trust preflight for the exact current project root. If supported providers are blocked, ask once whether to register only this project folder, then call `provider_trust_apply_all` after approval. | ||
| Before any provider fan-out, run the shared workspace trust preflight for the exact current project root. If supported providers are blocked, ask once whether to register only this project folder. This is a security approval gate, not a clarifying question; "keep going" / no-questions instructions are not approval. After approval, call `provider_trust_apply` once per blocked provider. Use `provider_trust_apply_all` only when the host permission model explicitly allows batch trust changes. If approval cannot be obtained, skip blocked providers or fall back to Host-only QA. | ||
@@ -36,6 +36,20 @@ ## Step 1: Determine QA target | ||
| ## Step 2: Choose QA depth | ||
| ## Step 2: Choose QA execution mode | ||
| Ask the user once: | ||
| > Which QA execution mode should I use? | ||
| | Option | Description | | ||
| |--------|-------------| | ||
| | **Host-only QA (Recommended)** | Fastest path. The current host collects evidence, runs `qa_run`, writes the QA report, and does not call external providers. | | ||
| | **QA Brigade** | The host collects evidence first, then enabled providers cross-check the prepared findings through a short consensus round. Takes longer. | | ||
| | **Decide automatically** | Use Host-only QA unless the target is broad/high-risk, the user explicitly asked for multiple AIs/providers, or the design has disputed evidence. | | ||
| Use `AskUserQuestion` when available, or a plain numbered prompt as fallback. This is a cost/permission gate, not a clarifying question. Do not infer provider-backed QA merely because `/agestra qa` was invoked or providers are configured. Only skip this question when the user already explicitly requested current-host-only QA, named provider-backed/multi-AI QA, or chose a mode in the same request. If a host-level no-questions directive prevents asking, choose Host-only QA and report that provider fan-out was skipped. | ||
| ## Step 3: Choose QA depth | ||
| Ask the user once: | ||
| > E2E verification can open the app and exercise real user flows. It gives stronger confidence, but can take more time, tokens, and local runtime setup. Which QA depth should I use? | ||
@@ -49,3 +63,3 @@ | ||
| Use `AskUserQuestion` when available, or a plain numbered prompt as fallback. Do not infer QA depth unless the user chose `Decide automatically` or the request already explicitly asked for Standard QA or Full QA/E2E. | ||
| Use `AskUserQuestion` when available, or a plain numbered prompt as fallback. This is a cost/permission gate, not a clarifying question. Do not infer QA depth unless the user chose `Decide automatically` or the request already explicitly asked for Standard QA or Full QA/E2E. If a host-level no-questions directive prevents asking, choose Standard QA and report that E2E was skipped unless the user explicitly requested it. | ||
@@ -58,14 +72,25 @@ If the user chooses Full QA and persistent E2E test files must be added or updated, QA must ask approval and route test-file work to `agestra-implementer` with `mode: e2e-test-authoring`. QA itself remains read-only for source code and persistent tests. | ||
| Then ask host-led research notes before provider fan-out: spec-to-code mapping gaps, API/consumer data shape, route/link mapping, state transition completeness, command/result consistency, suspected regressions, integration/regression risk, edge/error states, test adequacy, safety hygiene, E2E artifact interpretation, or `skip`. Ask whether any provider or lens should receive a specific research assignment, or whether team-lead should choose. | ||
| If QA Brigade was selected, then ask focused provider cross-check notes before provider fan-out: spec-to-code mapping gaps, API/consumer data shape, route/link mapping, state transition completeness, command/result consistency, suspected regressions, integration/regression risk, edge/error states, test adequacy, safety hygiene, E2E artifact interpretation, or `skip`. Ask whether any provider or host-native lens should receive a specific cross-check assignment, or whether team-lead should choose. | ||
| ## Step 3: Route execution | ||
| ## Step 4: Route execution | ||
| Call `environment_check` and `provider_list`. | ||
| **Host-only path:** | ||
| Run the host-owned QA evidence pass directly: | ||
| - Use `qa_run` for build/test verification where applicable. | ||
| - Inspect the design/progress contract, implementation files, command output, and runtime/E2E artifacts according to the selected depth. | ||
| - Use host-native `agestra-research` only as a bounded native helper assignment when the current host exposes native agents and the evidence question is narrow. | ||
| - Write the QA report under `docs/reports/qa/`. | ||
| - Do not call `agent_research_consensus_start`, `agent_consensus_start`, `ai_chat`, or external provider tools. | ||
| **No-provider stop path:** | ||
| Stop Agestra orchestration and tell the user to run `/agestra setup` to enable a provider, or ask the current host to verify directly outside Agestra. | ||
| If QA Brigade was selected but no external provider is available, stop provider orchestration and offer Host-only QA or `/agestra setup`. Do not spawn a provider-backed consensus with zero providers. | ||
| **Provider-backed path — 1+ configured external providers available (host research consensus + QA Brigade):** | ||
| Hand off to `agestra:agestra-team-lead`. Provider-backed QA uses the host research consensus flow: | ||
| **Provider-backed path — QA Brigade selected and 1+ configured external providers available:** | ||
| Before any provider fan-out, run workspace trust readiness for the exact target root. If supported providers are blocked, ask once whether to register only this project folder. This is a security approval gate, not a clarifying question; "keep going" / no-questions instructions are not approval. After approval, call `provider_trust_apply` once per blocked provider. Use `provider_trust_apply_all` only when the host permission model explicitly allows batch trust changes. If approval cannot be obtained, skip blocked providers or fall back to Host-only QA. Pass `workspace_base_dir` explicitly to provider readiness/trust and consensus calls whenever the host workspace root may be ambiguous. | ||
| Hand off to `agestra:agestra-team-lead`. Provider-backed QA uses the fast host-prepared consensus path by default: | ||
| ```text | ||
@@ -78,7 +103,7 @@ 호스트가 조사한다. | ||
| External AI research and debate run in separate fresh sessions, even when the same provider participates in both phases. Build a self-contained handoff packet: | ||
| The host must prepare QA evidence before provider fan-out. External providers cross-check the prepared evidence; they do not run the initial research phase. Build a self-contained handoff packet: | ||
| - **Domain:** `qa` | ||
| - **Submode:** `qa-only` | ||
| - **Mode:** `multi-ai` | ||
| - **Mode:** `qa-brigade` (selected by the user; do not re-ask) | ||
| - **QA formation:** QA Brigade | ||
@@ -92,7 +117,7 @@ - **QA target:** from Step 1 | ||
| - **Connection / Boundary Checks:** API/consumer data shape, route/link mapping, state transition completeness, command/result consistency, and E2E artifact interpretation when E2E ran | ||
| - **Research notes:** what the host-led investigation should look for (spec-to-code gaps, boundary mismatches, regressions, integration risk, edge/error states, test adequacy, safety hygiene) | ||
| - **Research assignments:** optional participant/lens rows for `research_assignments` | ||
| - **Research notes:** what the host-owned evidence pass should look for (spec-to-code gaps, boundary mismatches, regressions, integration risk, edge/error states, test adequacy, safety hygiene) | ||
| - **Cross-check assignments:** optional provider/lens rows for the short consensus round, or "team-lead choose" | ||
| - **Available providers:** from `environment_check`; include configured providers when their detected model capability is suitable, using read-only QA/review tools so verification cannot modify source files | ||
| - **Requested providers:** explicit names captured from user wording; otherwise "all configured and available review-capable providers" | ||
| - **QA lens handoff:** when a host QA/review/security perspective is needed, team-lead assigns `agestra-research` focused lenses and includes that evidence in the host-led consolidation inputs. Do not create a bundled research participant. | ||
| - **QA lens handoff:** when a host QA/review/security perspective is needed, team-lead assigns `agestra-research` focused native-agent lenses before provider fan-out and includes that evidence in the host-prepared `initial_aggregation`. Do not list `agestra-research` as an external provider participant. | ||
| - **Brigade lenses:** host executable evidence, spec-to-code compliance, implementation progress truthfulness, integration/regression risk, edge/error states, test adequacy, basic safety hygiene, and E2E artifact review when E2E ran | ||
@@ -105,7 +130,10 @@ - **QA-only boundary:** QA-only mode does not modify product code; connection or boundary defects are findings until the user approves a separate implementation task | ||
| Team-lead owns running the host-owned QA evidence pass, then calling `agent_research_consensus_start` with `domain: "qa"`, the QA `objective`, `participants`, optional `research_assignments`, optional `provider_order`, bounded `max_rounds`, and output document flags. Team-lead must ensure external AI research and debate use separate fresh sessions, must never create a bundled research pseudo-participant, and must never carry research bundles through `source_documents`. Inspect `aggregation_record.json`, `open_debate_items.json`, `round_packet.{round}.{provider}.json`, the aggregation document, and the leader-authored final decision document under `docs/agestra/`. This command must not call `agent_consensus_start` directly for provider-backed QA; the research consensus workflow prepares the aggregation first. Do not ask for a separate multi-AI confirmation in the provider-backed path; provider selection already came from setup. If the user asks for current-host-only verification, handle that outside Agestra. | ||
| Team-lead owns running the host-owned QA evidence pass, then preparing `initial_aggregation.items` from concrete evidence and calling `agent_consensus_start` with `domain` represented only in metadata, exact provider participants, `participant_routes` for any host-native `agestra-debate` participant, `max_rounds: 1` for Standard QA, and a bounded participant timeout. Team-lead must poll `agent_debate_status` and `run_observable_events` when a locator is available, then surface concise progress at least every 30-60 seconds while provider work is running. When the status reports pending host turns, team-lead dispatches the native `agestra-debate` agent and submits the JSON with `agent_consensus_submit_turn`. If the current host cannot surface progress from a background team-lead, the caller must poll and relay progress, or choose Host-only QA for the current run. | ||
| ## Step 4: Present the final result | ||
| Do not call `agent_research_consensus_start` for the default QA Brigade path. That tool is reserved for an explicit deep provider-research mode; in that exception, External AI research and debate run in separate fresh sessions, even when the same provider participates in both phases. Default QA Brigade must avoid the extra external research round because QA already has host-owned executable evidence. | ||
| ## Step 5: Present the final result | ||
| When QA returns: | ||
| - State QA execution mode | ||
| - State QA depth and whether E2E was run | ||
@@ -112,0 +140,0 @@ - Link or name the design document used |
@@ -19,3 +19,3 @@ --- | ||
| Before any provider fan-out, run the shared workspace trust preflight for the exact current project root. If supported providers are blocked, ask once whether to register only this project folder, then call `provider_trust_apply_all` after approval. | ||
| Before any provider fan-out, run the shared workspace trust preflight for the exact current project root. If supported providers are blocked, ask once whether to register only this project folder. This is a security approval gate, not a clarifying question; "keep going" / no-questions instructions are not approval. After approval, call `provider_trust_apply` once per blocked provider. Use `provider_trust_apply_all` only when the host permission model explicitly allows batch trust changes. If approval cannot be obtained, skip blocked providers. | ||
@@ -68,2 +68,5 @@ ## Step 1: Clarify research target domain and topic | ||
| If not, propose one recommendation with a short reason and ask for approval. | ||
| This is a cost/latency gate, not a clarifying question. If a host-level | ||
| no-questions directive prevents asking, choose Host-seeded Research and report | ||
| that broader provider investigation was skipped. | ||
| If no external providers are available, stop Agestra orchestration and tell the user to run setup or handle the research directly outside Agestra. | ||
@@ -70,0 +73,0 @@ |
+22
-8
@@ -24,3 +24,3 @@ --- | ||
| Before any provider fan-out, run the shared workspace trust preflight for the exact current project root. If supported providers are blocked, ask once whether to register only this project folder, then call `provider_trust_apply_all` after approval. | ||
| Before any provider fan-out, run the shared workspace trust preflight for the exact current project root. If supported providers are blocked, ask once whether to register only this project folder. This is a security approval gate, not a clarifying question; "keep going" / no-questions instructions are not approval. After approval, call `provider_trust_apply` once per blocked provider. Use `provider_trust_apply_all` only when the host permission model explicitly allows batch trust changes. If approval cannot be obtained, skip blocked providers. | ||
@@ -77,6 +77,19 @@ ## Step 1: Determine review scope | ||
| Then ask host-led research notes before provider fan-out: regression-prone areas, blast radius / downstream callers, prior incidents, dependency / supply-chain concerns, current-information needs, or `skip`. Ask whether any provider or lens should receive a specific research assignment, or whether team-lead should choose. | ||
| Then ask research notes before provider fan-out: regression-prone areas, blast radius / downstream callers, prior incidents, dependency / supply-chain concerns, current-information needs, or `skip`. Ask whether any provider or lens should receive a specific research assignment, or whether team-lead should choose. | ||
| ## Step 3: Route execution | ||
| ## Step 3: Choose 조사 방식 | ||
| Before provider fan-out, ask once which investigation topology to use unless the user already specified it: | ||
| | Option | Description | | ||
| |--------|-------------| | ||
| | **Host-led Research (Recommended)** | The current host prepares bounded review evidence first; providers challenge and debate the prepared findings. Record internally as `host-seeded`. | | ||
| | **Council Research** | Host and providers independently inspect assigned review lenses before consolidation and debate. | | ||
| | **Provider-seeded Research** | One selected provider creates the first review seed/evidence artifact; host and other providers challenge it. | | ||
| | **Decide automatically** | Use Host-led for scoped reviews, Council for whole-project/deep reviews, and Provider-seeded only when the user named a provider to lead. | | ||
| Use `AskUserQuestion` when available, or a plain numbered prompt as fallback. This is a cost/latency gate, not a review clarification. If a host-level no-questions directive prevents asking, choose Host-led Research (`host-seeded`) and report that broader provider investigation was skipped. If Provider-seeded Research is selected and the seed provider is not explicit, record the seed provider as pending; after provider availability is listed, ask which available provider should seed. Do not infer it. | ||
| ## Step 4: Route execution | ||
| Call `environment_check` and `provider_list` to determine available providers. | ||
@@ -88,3 +101,3 @@ | ||
| **Provider-backed path — 1+ external providers available (multi-AI):** | ||
| Hand off to the `agestra:agestra-team-lead` agent with multi-AI mode **pre-selected**. Provider-backed review uses the host research consensus flow: | ||
| Hand off to the `agestra:agestra-team-lead` agent with multi-AI mode **pre-selected**. Provider-backed review uses the selected research topology flow: | ||
@@ -108,7 +121,8 @@ ```text | ||
| - **Consensus domain:** `review` | ||
| - **Research notes:** what the host-led investigation should look for (regression-prone areas, blast radius, prior incidents, dependency concerns, current-information needs) | ||
| - **Research topology / 조사 방식:** selected in Step 3 (`host-seeded`, `council`, `provider-seeded`, or `automatic`) | ||
| - **Research notes:** what the selected investigation should look for (regression-prone areas, blast radius, prior incidents, dependency concerns, current-information needs) | ||
| - **Research assignments:** optional participant/lens rows for `research_assignments` | ||
| - **Available providers:** from `environment_check`; include configured providers when their detected model capability is suitable, using read-only review tools for code/document critique | ||
| - **Requested providers:** explicit names captured from user wording; otherwise "all available review-capable" | ||
| - **Review lens handoff:** when a host review perspective is needed, team-lead assigns `agestra-research` a focused review lens and includes that evidence in the host-led consolidation inputs. Do not create a bundled research participant. | ||
| - **Review lens handoff:** when a host review perspective is needed, team-lead assigns `agestra-research` a focused review lens and includes that evidence in the selected research/consolidation inputs. Do not create a bundled research participant. | ||
| - **Scale controls:** normal scoped reviews inherit the 5-minute participant timeout. If the target is a whole project, a large directory, or deep review, instruct team-lead to create a bounded review packet before fan-out: changed files, key entry points, relevant docs/config, and explicit exclusions. Do not ask external CLI providers to explore an unbounded large repository from scratch. Use `participant_timeout_ms: 600000` (10 minutes) for large/deep reviews, and split the review into narrower area debates if providers still time out. | ||
@@ -121,3 +135,3 @@ - **Locale:** from `setup_status` | ||
| - Building the participant team from focused review lenses, explicit host-turn debate participants, and external providers | ||
| - Calling `agent_research_consensus_start` with `domain: "review"`, the review `objective`, `participants`, optional `research_assignments`, optional `provider_order`, bounded `max_rounds`, and output document flags. | ||
| - Resolving the selected research topology, then calling `agent_research_consensus_start` when investigation fan-out is required or `agent_consensus_start` with prepared `initial_aggregation.items` when seed/host evidence is already available. | ||
| - Ensuring external AI research and debate use separate fresh sessions. | ||
@@ -135,3 +149,3 @@ - Never creating a bundled research pseudo-participant and never carrying research bundles through `source_documents`. | ||
| ## Step 4: Present the final result | ||
| ## Step 5: Present the final result | ||
@@ -138,0 +152,0 @@ When team-lead returns: |
+22
-8
@@ -22,3 +22,3 @@ --- | ||
| Before any provider fan-out, run the shared workspace trust preflight for the exact current project root. If supported providers are blocked, ask once whether to register only this project folder, then call `provider_trust_apply_all` after approval. | ||
| Before any provider fan-out, run the shared workspace trust preflight for the exact current project root. If supported providers are blocked, ask once whether to register only this project folder. This is a security approval gate, not a clarifying question; "keep going" / no-questions instructions are not approval. After approval, call `provider_trust_apply` once per blocked provider. Use `provider_trust_apply_all` only when the host permission model explicitly allows batch trust changes. If approval cannot be obtained, skip blocked providers. | ||
@@ -54,6 +54,19 @@ ## Step 1: Determine security scope | ||
| Then ask host-led research notes before provider fan-out: secrets / API key surfaces, auth / authz boundaries, file / command execution paths, network exposure, dependency / supply-chain concerns, unsafe defaults, or `skip`. Ask whether any provider or lens should receive a specific research assignment, or whether team-lead should choose. | ||
| Then ask research notes before provider fan-out: secrets / API key surfaces, auth / authz boundaries, file / command execution paths, network exposure, dependency / supply-chain concerns, unsafe defaults, or `skip`. Ask whether any provider or lens should receive a specific research assignment, or whether team-lead should choose. | ||
| ## Step 3: Route execution | ||
| ## Step 3: Choose 조사 방식 | ||
| Before provider fan-out, ask once which investigation topology to use unless the user already specified it: | ||
| | Option | Description | | ||
| |--------|-------------| | ||
| | **Host-led Research (Recommended)** | The current host prepares bounded security evidence first; providers challenge and debate the prepared findings. Record internally as `host-seeded`. | | ||
| | **Council Research** | Host and providers independently inspect assigned security surfaces before consolidation and debate. | | ||
| | **Provider-seeded Research** | One selected provider creates the first security seed/evidence artifact; host and other providers challenge it. | | ||
| | **Decide automatically** | Use Host-led for bounded audits, Council for broad/full security reviews, and Provider-seeded only when the user named a provider to lead. | | ||
| Use `AskUserQuestion` when available, or a plain numbered prompt as fallback. This is a cost/latency gate, not a security clarification. If a host-level no-questions directive prevents asking, choose Host-led Research (`host-seeded`) and report that broader provider investigation was skipped. If Provider-seeded Research is selected and the seed provider is not explicit, record the seed provider as pending; after provider availability is listed, ask which available provider should seed. Do not infer it. | ||
| ## Step 4: Route execution | ||
| Call `environment_check` and `provider_list`. | ||
@@ -65,3 +78,3 @@ | ||
| **Provider-backed path — 1+ external providers available (multi-AI):** | ||
| Hand off to `agestra:agestra-team-lead`. Provider-backed security uses the host research consensus flow: | ||
| Hand off to `agestra:agestra-team-lead`. Provider-backed security uses the selected research topology flow: | ||
@@ -85,7 +98,8 @@ ```text | ||
| - **Consensus domain:** `security` | ||
| - **Research notes:** what the host-led investigation should look for (secrets/keys, auth/authz boundaries, file/command execution, network exposure, dependency concerns, unsafe defaults) | ||
| - **Research topology / 조사 방식:** selected in Step 3 (`host-seeded`, `council`, `provider-seeded`, or `automatic`) | ||
| - **Research notes:** what the selected investigation should look for (secrets/keys, auth/authz boundaries, file/command execution, network exposure, dependency concerns, unsafe defaults) | ||
| - **Research assignments:** optional participant/lens rows for `research_assignments` | ||
| - **Available providers:** from `environment_check`; include configured providers when their detected model capability is suitable, using read-only security-review tools unless the user explicitly approves a separate implementation task | ||
| - **Requested providers:** explicit names captured from user wording; otherwise "all available security-capable" | ||
| - **Specialist handoff (host-native security):** when a host-native security lens is needed, team-lead runs that specialist through the active host layer and includes the result in the host-led research/consolidation inputs. Do not use host-specialist handoff to create a bundled research participant. | ||
| - **Specialist handoff (host-native security):** when a host-native security lens is needed, team-lead runs that specialist through the active host layer and includes the result in the selected research/consolidation inputs. Do not use host-specialist handoff to create a bundled research participant. | ||
| - **Locale:** from `setup_status` | ||
@@ -95,5 +109,5 @@ - **Target workspace root:** absolute project folder if the user supplied or implied one; pass it to workspace/debate MCP calls as `workspace_base_dir` | ||
| Team-lead owns calling `agent_research_consensus_start` with `domain: "security"`, the security `objective`, `participants`, optional `research_assignments`, optional `provider_order`, bounded `max_rounds`, and output document flags. Team-lead must ensure external AI research and debate use separate fresh sessions, must never create a bundled research pseudo-participant, and must never carry research bundles through `source_documents`. Inspect `aggregation_record.json`, `open_debate_items.json`, `round_packet.{round}.{provider}.json`, the aggregation document, and the leader-authored final decision document under `docs/agestra/`. The brigade must not run destructive exploit tests and must not install tools or run heavyweight/networked scans without explicit user approval. | ||
| Team-lead owns resolving the selected research topology, then calling `agent_research_consensus_start` when investigation fan-out is required or `agent_consensus_start` with prepared `initial_aggregation.items` when seed/host evidence is already available. Team-lead must ensure external AI research and debate use separate fresh sessions when a research phase is used, must never create a bundled research pseudo-participant, and must never carry research bundles through `source_documents`. Inspect `aggregation_record.json`, `open_debate_items.json`, `round_packet.{round}.{provider}.json`, the aggregation document, and the leader-authored final decision document under `docs/agestra/`. The brigade must not run destructive exploit tests and must not install tools or run heavyweight/networked scans without explicit user approval. | ||
| ## Step 4: Present the result | ||
| ## Step 5: Present the result | ||
@@ -100,0 +114,0 @@ When security review returns: |
@@ -87,3 +87,3 @@ --- | ||
| Do not treat "등록하고 계속" / "Trust this project and continue" as consent to store `auto-exact`; that action only applies the current exact root through `provider_trust_apply_all`. | ||
| Do not treat "등록하고 계속" / "Trust this project and continue" as consent to store `auto-exact`; that action only applies the current exact root through `provider_trust_apply` calls for the selected providers. Use `provider_trust_apply_all` only when the host permission model explicitly allows batch trust changes. | ||
@@ -90,0 +90,0 @@ Call `setup_apply` with: |
+1
-1
| { | ||
| "name": "agestra", | ||
| "version": "4.14.2", | ||
| "version": "4.14.3", | ||
| "description": "Multi-host MCP orchestration for Claude Code, Codex CLI, Gemini CLI, and local models", | ||
@@ -5,0 +5,0 @@ "type": "module", |
@@ -36,2 +36,5 @@ // Single source of truth for agent permission categories. | ||
| "provider_health", | ||
| "provider_readiness", | ||
| "provider_trust_apply", | ||
| "run_observable_events", | ||
| "trace_query", | ||
@@ -38,0 +41,0 @@ "trace_summary", |
+20
-6
@@ -71,3 +71,3 @@ --- | ||
| **Host research consensus inputs (mandatory before provider fan-out):** | ||
| - "Provider-backed design uses host-led research consensus. What should the host-led investigation look for: existing patterns in this codebase, prior art / competing implementations, constraints / regulations, current-information needs, or skip?" | ||
| - "Provider-backed design can use Host-led, Council, or Provider-seeded research. What should the selected investigation look for: existing patterns in this codebase, prior art / competing implementations, constraints / regulations, current-information needs, or skip?" | ||
| - "Should any participant or lens receive a specific research assignment, or should team-lead choose the assignment rows?" | ||
@@ -97,6 +97,19 @@ | ||
| ### Phase 2: Route execution | ||
| ### Phase 2: Choose 조사 방식 | ||
| This skill is **information-gathering only**. After Phase 1, hand off to the appropriate executor based on environment. | ||
| Before provider fan-out, ask once which investigation topology to use unless the user already specified it: | ||
| | Option | Description | | ||
| |--------|-------------| | ||
| | **Host-led Research (Recommended)** | The current host/native researchers inspect the codebase and prepare the first design evidence packet; providers challenge and debate it. Record internally as `host-seeded`. | | ||
| | **Council Research** | Host and providers independently investigate design options with assigned lenses before consolidation and debate. | | ||
| | **Provider-seeded Research** | One selected provider creates the first design seed/evidence artifact; host and other providers challenge it. | | ||
| | **Decide automatically** | Use Host-led for bounded design work, Council for broad architecture exploration, and Provider-seeded only when the user named a provider to lead. | | ||
| Use `AskUserQuestion` when available, or a plain numbered prompt as fallback. This is a cost/latency gate, not a design clarification. If a host-level no-questions directive prevents asking, choose Host-led Research (`host-seeded`) and report that broader provider investigation was skipped. If Provider-seeded Research is selected and the seed provider is not explicit, record the seed provider as pending; after provider availability is listed, ask which available provider should seed. Do not infer it. | ||
| ### Phase 3: Route execution | ||
| This skill is **information-gathering only**. After Phases 1-2, hand off to the appropriate executor based on environment. | ||
| Call `environment_check` and `provider_list`. | ||
@@ -110,3 +123,3 @@ | ||
| **Provider-backed path — 1+ external providers available (multi-AI):** | ||
| Hand off to the `agestra:agestra-team-lead` agent with multi-AI mode **pre-selected**. Provider-backed design uses the host research consensus flow: | ||
| Hand off to the `agestra:agestra-team-lead` agent with multi-AI mode **pre-selected**. Provider-backed design uses the selected research topology flow: | ||
@@ -131,3 +144,4 @@ ```text | ||
| - **Consensus domain:** `design` | ||
| - **Research notes:** {what the host-led investigation should look for — existing patterns, prior art, constraints, current-information needs} | ||
| - **Research topology / 조사 방식:** {selected in Phase 2 — `host-seeded`, `council`, `provider-seeded`, or `automatic`} | ||
| - **Research notes:** {what the selected investigation should look for — existing patterns, prior art, constraints, current-information needs} | ||
| - **Research assignments:** {optional participant/lens rows for `research_assignments`, or "team-lead choose"} | ||
@@ -142,3 +156,3 @@ - **Available providers:** {from environment_check} | ||
| - Building the participant team (host designer + external providers + auto-injected specialists when applicable) | ||
| - Calling `agent_research_consensus_start` with `domain: "design"`, the design `objective`, `participants`, optional `research_assignments`, optional `provider_order`, bounded `max_rounds`, and output document flags. | ||
| - Resolving the selected research topology, then calling `agent_research_consensus_start` when investigation fan-out is required or `agent_consensus_start` with prepared `initial_aggregation.items` when seed/host evidence is already available. | ||
| - Ensuring external AI research and debate use separate fresh sessions. | ||
@@ -145,0 +159,0 @@ - Never creating a bundled research pseudo-participant and never carrying research bundles through `source_documents`. |
+23
-8
@@ -15,3 +15,3 @@ --- | ||
| Provider-backed idea discovery uses the host research consensus flow: | ||
| Provider-backed idea discovery uses the selected research topology flow: | ||
@@ -69,3 +69,3 @@ ```text | ||
| | Current audience | "Who uses this now, and what do they use it for most?" | Keep ideas relevant to actual users | | ||
| | Research notes | "Provider-backed idea discovery uses host-led research consensus. What should the host-led investigation look for: competitors, user praise/complaints, current information, source constraints, or skip?" | Shape the research assignments | | ||
| | Research notes | "Provider-backed idea discovery can use Host-led, Council, or Provider-seeded research. What should the selected investigation look for: competitors, user praise/complaints, current information, source constraints, or skip?" | Shape the research assignments | | ||
| | Research assignments | "Should any participant or lens receive a specific research assignment, or should team-lead choose the assignment rows?" | Capture preferred division of labor | | ||
@@ -90,3 +90,3 @@ | Identity and boundaries | "What should not change about this project? Any identity, workflow, or area you want to protect? Choose unspecified if you are not sure." | Avoid ideas that break what already works | | ||
| | Difference | "How should this feel different from existing apps? Choose unspecified if you are not sure." | Encourage differentiation without over-constraining | | ||
| | Research notes | "Provider-backed idea discovery uses host-led research consensus. What should the host-led investigation look for: similar apps, user praise/complaints, current information, source constraints, or skip?" | Shape the research assignments | | ||
| | Research notes | "Provider-backed idea discovery can use Host-led, Council, or Provider-seeded research. What should the selected investigation look for: similar apps, user praise/complaints, current information, source constraints, or skip?" | Shape the research assignments | | ||
| | Research assignments | "Should any participant or lens receive a specific research assignment, or should team-lead choose the assignment rows?" | Capture preferred division of labor | | ||
@@ -99,6 +99,19 @@ | Free notes | "Anything else you want to say, even if it is rough? Choose skip if not." | Let vague inspiration stay useful | | ||
| ### Phase 2: Route execution | ||
| ### Phase 2: Choose 조사 방식 | ||
| This skill is **information-gathering only**. After Phase 1, hand off to the appropriate executor based on environment. | ||
| Before provider fan-out, ask once which investigation topology to use unless the user already specified it: | ||
| | Option | Description | | ||
| |--------|-------------| | ||
| | **Host-led Research (Recommended)** | The current host prepares the first evidence packet, then providers challenge and debate it. Fastest and lowest-cost default. Record internally as `host-seeded`. | | ||
| | **Council Research** | Host and providers independently investigate assigned lenses before consolidation and debate. Stronger for broad/open-ended exploration. | | ||
| | **Provider-seeded Research** | One selected provider creates the first seed/evidence artifact, then host and other providers challenge it. | | ||
| | **Decide automatically** | Use Host-led for bounded topics, Council for broad idea discovery, and Provider-seeded only when the user named a provider to lead. | | ||
| Use `AskUserQuestion` when available, or a plain numbered prompt as fallback. This is a cost/latency gate, not a domain clarification. If a host-level no-questions directive prevents asking, choose Host-led Research (`host-seeded`) and report that broader provider investigation was skipped. If Provider-seeded Research is selected and the seed provider is not explicit, record the seed provider as pending; after provider availability is listed, ask which available provider should seed. Do not infer it. | ||
| ### Phase 3: Route execution | ||
| This skill is **information-gathering only**. After Phases 1-2, hand off to the appropriate executor based on environment. | ||
| Call `environment_check` and `provider_list`. | ||
@@ -117,6 +130,7 @@ | ||
| - **Idea mode:** `A` (existing project) or `B` (new project) — from Phase 1 detection | ||
| - **Interview answers:** {all dimensions captured in Phase 1 — Intent/Area/User wishes/Current audience/Research route/Research notes/Identity and boundaries/Free notes for Mode A; Kind/Seed/Audience/Must-have/Inspiration/Difference/Research route/Research notes/Free notes for Mode B} | ||
| - **Interview answers:** {all dimensions captured in Phase 1 — Intent/Area/User wishes/Current audience/Research notes/Identity and boundaries/Free notes for Mode A; Kind/Seed/Audience/Must-have/Inspiration/Difference/Research notes/Free notes for Mode B} | ||
| - **Project context:** {README summary, current feature set if Mode A; seed idea verbatim if Mode B} | ||
| - **Consensus domain:** `idea` | ||
| - **Research notes:** {what the host-led investigation should look for} | ||
| - **Research topology / 조사 방식:** {selected in Phase 2 — `host-seeded`, `council`, `provider-seeded`, or `automatic`} | ||
| - **Research notes:** {what the selected investigation should look for} | ||
| - **Research assignments:** {optional participant/lens rows for `research_assignments`, or "team-lead choose"} | ||
@@ -131,3 +145,4 @@ - **Available providers:** {from environment_check} | ||
| - Building the participant team. Any host ideator is invoked through the active host layer; external providers are MCP/CLI/chat participants only. | ||
| - Calling `agent_research_consensus_start` with `domain: "idea"`, the idea `objective`, `participants`, optional `research_assignments`, optional `provider_order`, bounded `max_rounds`, and output document flags. | ||
| - Resolving the selected research topology, then calling `agent_research_consensus_start` when investigation fan-out is required or `agent_consensus_start` with prepared `initial_aggregation.items` when seed/host evidence is already available. | ||
| - For research fan-out, pass `domain: "idea"` to `agent_research_consensus_start`. | ||
| - Ensuring external AI research and debate use separate fresh sessions. | ||
@@ -134,0 +149,0 @@ - Never creating a bundled research pseudo-participant and never carrying research bundles through `source_documents`. |
+27
-7
@@ -33,5 +33,7 @@ --- | ||
| This skill is a **thin router** — it does not perform the work itself. The | ||
| `agestra:agestra-team-lead` agent and the matching domain workflow execute the actual work | ||
| in their own contexts. | ||
| This skill is a **thin router** — it does not perform the work itself. It should | ||
| auto-classify clear requests and route them quietly. It shows the domain menu | ||
| only when the request is genuinely ambiguous. The matching domain skill gathers | ||
| domain-specific requirements, then the `agestra:agestra-team-lead` agent executes | ||
| the actual orchestration. | ||
@@ -102,2 +104,10 @@ ## When NOT to use | ||
| **Clear-domain requests:** | ||
| - Do not ask "which command?" when the domain is clear from the request. | ||
| - Route directly to the matching domain skill. | ||
| - Domain-specific cost, trust, runtime-depth, write, provider, or research-topology gates | ||
| are asked inside the domain skill or by team-lead, not here. | ||
| - If the user says "알아서", "decide automatically", or equivalent and the | ||
| domain is clear, pass `automatic` intent forward instead of opening the menu. | ||
| **Ambiguous requests** (multi-AI signal present but no clear domain): | ||
@@ -180,3 +190,3 @@ - Ask ONE targeted question via `AskUserQuestion` (or a plain numbered prompt as fallback). | ||
| | `review` | `agestra:review` | | | ||
| | `qa` | `agestra:qa` | Verification only. Asks QA depth, requires provider-backed QA Brigade, and stops with setup/direct-host guidance when no providers are available | | ||
| | `qa` | `agestra:qa` | Verification only. Asks Host-only vs QA Brigade, then QA depth; provider-backed QA Brigade is optional and falls back to Host-only/setup guidance when no providers are available | | ||
| | `security` | `agestra:security` | Dedicated security audit | | ||
@@ -199,4 +209,6 @@ | `implement` (default) | `agestra:implement` | Code changes + QA. Team-lead runs provider-backed code execution, host-owned evidence collection, and Phase 5M structured QA debate | | ||
| 2. Running its information-gathering phase (Clarity Gate, scope, focus areas, Mode A/B) | ||
| 3. Building the handoff packet for `agestra:agestra-team-lead` | ||
| 4. Invoking team-lead with `Mode: multi-ai` pre-selected so team-lead does not re-interview | ||
| 3. Capturing the domain's `조사 방식` / research topology gate when provider-backed | ||
| investigation is possible: `host-seeded`, `council`, `provider-seeded`, or `automatic` | ||
| 4. Building the handoff packet for `agestra:agestra-team-lead` | ||
| 5. Invoking team-lead with `Mode: multi-ai` pre-selected so team-lead does not re-interview | ||
@@ -206,3 +218,11 @@ team-lead then owns: | ||
| - Building the participant team from the reduced host-native agents (`agestra-research`, `agestra-debate`, `agestra-implementer`) and named external providers. External providers participate through MCP/CLI/chat routes and do not create or manage native host agents. | ||
| - `agent_consensus_start` orchestration from prepared `initial_aggregation` | ||
| - Resolving the selected research topology into concrete host-native research | ||
| assignments, external provider assignments, seed-provider work, and debate | ||
| participants. If topology is missing and asking is allowed, team-lead asks one | ||
| concise topology question; if no-questions mode blocks asking, team-lead uses | ||
| host-seeded research and reports that choice. | ||
| - Consensus orchestration: `agent_research_consensus_start` when the selected | ||
| topology requires investigation before debate, or `agent_consensus_start` from | ||
| prepared `initial_aggregation` when the domain skill/team-lead already has | ||
| sufficient evidence | ||
| - Approval gate (`agent_debate_approve` / `_continue` / `_reject`) | ||
@@ -209,0 +229,0 @@ - For `implement`: code edits via `agestra:agestra-implementer` or CLI workers |
@@ -61,3 +61,15 @@ --- | ||
| When providers are enabled, commands go directly to consensus debate mode. No mode selection needed. | ||
| When providers are enabled, explicit multi-AI/provider requests can go directly | ||
| to the matching domain skill, but the domain skill still owns its question sheet | ||
| and cost gates before team-lead dispatches providers. Idea, design, review, | ||
| security, and explicit research workflows ask for `조사 방식` / research topology | ||
| when provider-backed investigation is possible: Host-led Research, Council | ||
| Research, Provider-seeded Research, or Decide automatically. | ||
| `/agestra qa` is the exception: it must ask for Host-only QA, QA Brigade, or | ||
| automatic selection because configured providers alone should not turn a | ||
| verification request into a long provider-research run. | ||
| If a host-level no-questions directive prevents that gate, use Host-only QA and | ||
| report that provider fan-out was skipped. Trust registration remains a separate | ||
| security approval gate and cannot be inferred from no-questions instructions. | ||
| When no providers are enabled, run setup or handle the task directly outside Agestra. | ||
@@ -201,3 +213,3 @@ | ||
| **QA domain:** | ||
| - `/agestra qa` verifies existing work without code changes. It asks Standard vs Full E2E depth, writes a QA report under `docs/reports/qa/`, collects host-owned evidence, runs Connection / Boundary Checks (API/consumer data shape, route/link mapping, state transition completeness, command/result consistency, and E2E artifact interpretation), then runs the provider-backed QA Brigade. If no providers are enabled, it stops with setup/direct-host guidance. QA-only mode does not modify product code. It never spawns implementer or CLI workers for product fixes. If QA decides persistent E2E tests are needed, team-lead asks the user and routes only the approved test work to `agestra-implementer` with `mode: e2e-test-authoring`. | ||
| - `/agestra qa` verifies existing work without code changes. It first asks Host-only QA vs QA Brigade vs automatic selection, then asks Standard vs Full E2E depth, writes a QA report under `docs/reports/qa/`, collects host-owned evidence, and runs Connection / Boundary Checks (API/consumer data shape, route/link mapping, state transition completeness, command/result consistency, and E2E artifact interpretation). QA Brigade cross-checks host-prepared findings through a short consensus round; it does not start with external provider research unless the user explicitly asks for deep provider research. If no providers are enabled, it offers Host-only QA or setup. QA-only mode does not modify product code. It never spawns implementer or CLI workers for product fixes. If QA decides persistent E2E tests are needed, team-lead asks the user and routes only the approved test work to `agestra-implementer` with `mode: e2e-test-authoring`. | ||
@@ -204,0 +216,0 @@ **Security domain:** |
+39
-14
@@ -34,3 +34,3 @@ --- | ||
| ### Phase 2: Choose QA Depth | ||
| ### Phase 2: Choose QA Execution Mode | ||
@@ -41,2 +41,14 @@ Ask once unless already specified: | ||
| |--------|-------------| | ||
| | **Host-only QA (Recommended)** | Fastest path. The current host collects evidence, runs `qa_run`, writes the QA report, and does not call external providers. | | ||
| | **QA Brigade** | Host evidence first, then enabled providers cross-check prepared findings through a short consensus round. Takes longer. | | ||
| | **Decide automatically** | Use Host-only QA unless the target is broad/high-risk, the user explicitly asked for multiple AIs/providers, or the design has disputed evidence. | | ||
| Use `AskUserQuestion` when available, or a plain numbered prompt as fallback. This is a cost/permission gate, not a clarifying question. Do not infer provider-backed QA merely because `/agestra qa` was invoked or providers are configured. Skip this question only when the user already explicitly requested current-host-only QA, named provider-backed/multi-AI QA, or selected a mode in the same request. If a host-level no-questions directive prevents asking, choose Host-only QA and report that provider fan-out was skipped. | ||
| ### Phase 3: Choose QA Depth | ||
| Ask once unless already specified: | ||
| | Option | Description | | ||
| |--------|-------------| | ||
| | **Standard QA (Recommended)** | Design/progress compliance, build/type/test, Connection / Boundary Checks, error/empty states, and basic safety hygiene | | ||
@@ -47,18 +59,28 @@ | **Full QA with E2E** | Standard QA plus existing E2E tests, temporary browser automation, screenshots when useful, and core real-user flows | | ||
| Warn that E2E can cost more time, tokens, and local runtime setup. | ||
| Use `AskUserQuestion` when available, or a plain numbered prompt as fallback. Do not infer QA depth unless the user chose `Decide automatically` or the request already explicitly asked for Standard QA or Full QA/E2E. | ||
| Use `AskUserQuestion` when available, or a plain numbered prompt as fallback. This is a cost/permission gate, not a clarifying question. Do not infer QA depth unless the user chose `Decide automatically` or the request already explicitly asked for Standard QA or Full QA/E2E. If a host-level no-questions directive prevents asking, choose Standard QA and report that E2E was skipped unless the user explicitly requested it. | ||
| Persistent E2E test files are not created or maintained by QA. If they are needed, QA returns an `E2E_TEST_WORK_REQUEST` packet; after explicit user approval, route it to `agestra:agestra-implementer` with `mode: e2e-test-authoring` and re-run QA after those tests exist. Use `AskUserQuestion` when available, or a plain numbered prompt as fallback. Do not infer approval. | ||
| Also ask host-led research inputs before provider fan-out: | ||
| - "Provider-backed QA uses host-led research consensus. What should the host-led investigation look for: spec-to-code mapping gaps, API/consumer data shape, route/link mapping, state transition completeness, command/result consistency, suspected regressions, integration/regression risk, edge / error states, test adequacy, safety hygiene, E2E artifact interpretation, or skip?" | ||
| - "Should any participant or lens receive a specific research assignment, or should team-lead choose the assignment rows?" | ||
| If QA Brigade was selected, also ask focused provider cross-check inputs before provider fan-out: | ||
| - "QA Brigade uses host-prepared evidence first. What should providers cross-check: spec-to-code mapping gaps, API/consumer data shape, route/link mapping, state transition completeness, command/result consistency, suspected regressions, integration/regression risk, edge / error states, test adequacy, safety hygiene, E2E artifact interpretation, or skip?" | ||
| - "Should any provider or host-native lens receive a specific cross-check assignment, or should team-lead choose the assignment rows?" | ||
| ### Phase 3: Route Execution | ||
| ### Phase 4: Route Execution | ||
| Call `environment_check` and `provider_list`. | ||
| If no external providers are available, stop Agestra orchestration and tell the user to run `/agestra setup` to enable a provider, or ask the current host to verify directly outside Agestra. Do not spawn a deleted standalone QA agent. | ||
| If Host-only QA was selected, run the host-owned QA evidence pass directly: | ||
| If external providers are available, hand off to `agestra:agestra-team-lead`. Provider-backed QA uses the host research consensus flow: | ||
| - Use `qa_run` for build/test verification where applicable. | ||
| - Inspect the design/progress contract, implementation files, command output, and runtime/E2E artifacts according to the selected depth. | ||
| - Use host-native `agestra-research` only as a bounded native helper assignment when the current host exposes native agents and the evidence question is narrow. | ||
| - Write the QA report under `docs/reports/qa/`. | ||
| - Do not call `agent_research_consensus_start`, `agent_consensus_start`, `ai_chat`, or external provider tools. | ||
| If QA Brigade was selected but no external providers are available, stop provider orchestration and offer Host-only QA or `/agestra setup`. Do not spawn a provider-backed consensus with zero providers. | ||
| If QA Brigade was selected and external providers are available, first run workspace trust readiness for the exact target root. If supported providers are blocked, ask once whether to register only this project folder. This is a security approval gate, not a clarifying question; "keep going" / no-questions instructions are not approval. After approval, call `provider_trust_apply` once per blocked provider. Use `provider_trust_apply_all` only when the host permission model explicitly allows batch trust changes. If approval cannot be obtained, skip blocked providers or fall back to Host-only QA. Pass `workspace_base_dir` explicitly to provider readiness/trust and consensus calls whenever the host workspace root may be ambiguous. | ||
| Then hand off to `agestra:agestra-team-lead`. Provider-backed QA uses the fast host-prepared consensus path by default: | ||
| ```text | ||
@@ -71,7 +93,7 @@ 호스트가 조사한다. | ||
| External AI research and debate run in separate fresh sessions, even when the same provider participates in both phases. Build a self-contained handoff packet: | ||
| The host must prepare QA evidence before provider fan-out. External providers cross-check the prepared evidence; they do not run the initial research phase. Build a self-contained handoff packet: | ||
| - **Domain:** `qa` | ||
| - **Submode:** `qa-only` | ||
| - **Mode:** `multi-ai` | ||
| - **Mode:** `qa-brigade` (selected by the user; do not re-ask) | ||
| - **QA depth:** {selected depth} | ||
@@ -82,4 +104,4 @@ - **Design doc reference:** {path under docs/plans} | ||
| - **Connection / Boundary Checks:** API/consumer data shape, route/link mapping, state transition completeness, command/result consistency, and E2E artifact interpretation when E2E ran | ||
| - **Research notes:** {what the host-led investigation should look for — spec-to-code gaps, boundary mismatches, regressions, integration risk, edge/error states, test adequacy, safety hygiene} | ||
| - **Research assignments:** {optional participant/lens rows for `research_assignments`, or "team-lead choose"} | ||
| - **Research notes:** {what the host-owned evidence pass should look for — spec-to-code gaps, boundary mismatches, regressions, integration risk, edge/error states, test adequacy, safety hygiene} | ||
| - **Cross-check assignments:** {optional provider/lens rows for the short consensus round, or "team-lead choose"} | ||
| - **Target workspace root:** {absolute project folder if supplied or implied; pass as `workspace_base_dir`} | ||
@@ -89,7 +111,10 @@ - **Locale:** {from setup_status} | ||
| Team-lead calls `agent_research_consensus_start` with `domain: "qa"`, the QA `objective`, `participants`, optional `research_assignments`, optional `provider_order`, bounded `max_rounds`, and output document flags. Team-lead must inspect `aggregation_record.json`, `open_debate_items.json`, `round_packet.{round}.{provider}.json`, the aggregation document, and the leader-authored final decision document under `docs/agestra/`. Do not create a bundled research pseudo-participant, and do not carry research bundles through `source_documents`. | ||
| Team-lead runs the host-owned QA evidence pass, prepares `initial_aggregation.items` from concrete evidence, and calls `agent_consensus_start` with metadata for `domain: "qa"`, exact provider participants, `participant_routes` for any host-native `agestra-debate` participant, `max_rounds: 1` for Standard QA, and a bounded participant timeout. Team-lead must poll `agent_debate_status` and `run_observable_events` when a locator is available, then surface concise progress at least every 30-60 seconds while provider work is running. When the status reports pending host turns, team-lead dispatches the native `agestra-debate` agent and submits the JSON with `agent_consensus_submit_turn`. If the current host cannot surface progress from a background team-lead, the caller must poll and relay progress, or choose Host-only QA for the current run. | ||
| ### Phase 4: Present | ||
| Do not call `agent_research_consensus_start` for the default QA Brigade path. That tool is reserved for an explicit deep provider-research mode; in that exception, External AI research and debate run in separate fresh sessions, even when the same provider participates in both phases. Default QA Brigade must avoid the extra external research round because QA already has host-owned executable evidence. | ||
| ### Phase 5: Present | ||
| Report: | ||
| - QA execution mode | ||
| - QA depth and E2E status | ||
@@ -96,0 +121,0 @@ - QA report path |
@@ -89,2 +89,6 @@ --- | ||
| This is a cost/latency gate, not a clarifying question. If a host-level | ||
| no-questions directive prevents asking, choose Host-seeded Research and report | ||
| that broader provider investigation was skipped. | ||
| If no external providers are available, stop Agestra orchestration and tell the user to run setup or handle the research directly outside Agestra. | ||
@@ -91,0 +95,0 @@ |
+23
-9
@@ -75,10 +75,23 @@ --- | ||
| Also ask host-led research inputs before provider fan-out: | ||
| - "Provider-backed review uses host-led research consensus. What should the host-led investigation look for: regression-prone areas, blast radius / downstream callers, prior incidents, dependency / supply-chain concerns, current-information needs, or skip?" | ||
| Also ask selected research inputs before provider fan-out: | ||
| - "Provider-backed review can use Host-led, Council, or Provider-seeded research. What should the selected investigation look for: regression-prone areas, blast radius / downstream callers, prior incidents, dependency / supply-chain concerns, current-information needs, or skip?" | ||
| - "Should any participant or lens receive a specific research assignment, or should team-lead choose the assignment rows?" | ||
| ### Phase 3: Route execution | ||
| ### Phase 3: Choose 조사 방식 | ||
| This skill is **information-gathering only**. After Phase 2, hand off to the appropriate executor based on environment. | ||
| Before provider fan-out, ask once which investigation topology to use unless the user already specified it: | ||
| | Option | Description | | ||
| |--------|-------------| | ||
| | **Host-led Research (Recommended)** | The current host prepares bounded review evidence first; providers challenge and debate the prepared findings. Record internally as `host-seeded`. | | ||
| | **Council Research** | Host and providers independently inspect assigned review lenses before consolidation and debate. | | ||
| | **Provider-seeded Research** | One selected provider creates the first review seed/evidence artifact; host and other providers challenge it. | | ||
| | **Decide automatically** | Use Host-led for scoped reviews, Council for whole-project/deep reviews, and Provider-seeded only when the user named a provider to lead. | | ||
| Use `AskUserQuestion` when available, or a plain numbered prompt as fallback. This is a cost/latency gate, not a review clarification. If a host-level no-questions directive prevents asking, choose Host-led Research (`host-seeded`) and report that broader provider investigation was skipped. If Provider-seeded Research is selected and the seed provider is not explicit, record the seed provider as pending; after provider availability is listed, ask which available provider should seed. Do not infer it. | ||
| ### Phase 4: Route execution | ||
| This skill is **information-gathering only**. After Phases 1-3, hand off to the appropriate executor based on environment. | ||
| Call `environment_check` and `provider_list`. | ||
@@ -90,3 +103,3 @@ | ||
| **Provider-backed path — 1+ external providers available (multi-AI):** | ||
| Hand off to the `agestra:agestra-team-lead` agent with multi-AI mode **pre-selected**. Provider-backed review uses the host research consensus flow: | ||
| Hand off to the `agestra:agestra-team-lead` agent with multi-AI mode **pre-selected**. Provider-backed review uses the selected research topology flow: | ||
@@ -110,3 +123,4 @@ ```text | ||
| - **Consensus domain:** `review` | ||
| - **Research notes:** {what the host-led investigation should look for — regression-prone areas, blast radius, prior incidents, dependency concerns, current-information needs} | ||
| - **Research topology / 조사 방식:** {selected in Phase 3 — `host-seeded`, `council`, `provider-seeded`, or `automatic`} | ||
| - **Research notes:** {what the selected investigation should look for — regression-prone areas, blast radius, prior incidents, dependency concerns, current-information needs} | ||
| - **Research assignments:** {optional participant/lens rows for `research_assignments`, or "team-lead choose"} | ||
@@ -121,3 +135,3 @@ - **Available providers:** {from environment_check, exclude `ollama` unless explicitly requested for lightweight commentary} | ||
| - Building the participant team (host reviewer + external providers) | ||
| - Calling `agent_research_consensus_start` with `domain: "review"`, the review `objective`, `participants`, optional `research_assignments`, optional `provider_order`, bounded `max_rounds`, and output document flags. | ||
| - Resolving the selected research topology, then calling `agent_research_consensus_start` when investigation fan-out is required or `agent_consensus_start` with prepared `initial_aggregation.items` when seed/host evidence is already available. | ||
| - Ensuring external AI research and debate use separate fresh sessions. | ||
@@ -135,3 +149,3 @@ - Never creating a bundled research pseudo-participant and never carrying research bundles through `source_documents`. | ||
| ### Phase 4: Review Verdict | ||
| ### Phase 5: Review Verdict | ||
@@ -148,3 +162,3 @@ The reviewer returns a review verdict: | ||
| ### Phase 5: Present | ||
| ### Phase 6: Present | ||
@@ -151,0 +165,0 @@ Surface the result to the user in the user's language: |
+21
-7
@@ -44,8 +44,21 @@ --- | ||
| Also ask host-led research inputs before provider fan-out: | ||
| - "Provider-backed security uses host-led research consensus. What should the host-led investigation look for: secrets / API key surfaces, auth / authz boundaries, file / command execution paths, network exposure, dependency / supply-chain concerns, unsafe defaults, or skip?" | ||
| Also ask selected research inputs before provider fan-out: | ||
| - "Provider-backed security can use Host-led, Council, or Provider-seeded research. What should the selected investigation look for: secrets / API key surfaces, auth / authz boundaries, file / command execution paths, network exposure, dependency / supply-chain concerns, unsafe defaults, or skip?" | ||
| - "Should any participant or lens receive a specific research assignment, or should team-lead choose the assignment rows?" | ||
| ### Phase 3: Route Execution | ||
| ### Phase 3: Choose 조사 방식 | ||
| Before provider fan-out, ask once which investigation topology to use unless the user already specified it: | ||
| | Option | Description | | ||
| |--------|-------------| | ||
| | **Host-led Research (Recommended)** | The current host prepares bounded security evidence first; providers challenge and debate the prepared findings. Record internally as `host-seeded`. | | ||
| | **Council Research** | Host and providers independently inspect assigned security surfaces before consolidation and debate. | | ||
| | **Provider-seeded Research** | One selected provider creates the first security seed/evidence artifact; host and other providers challenge it. | | ||
| | **Decide automatically** | Use Host-led for bounded audits, Council for broad/full security reviews, and Provider-seeded only when the user named a provider to lead. | | ||
| Use `AskUserQuestion` when available, or a plain numbered prompt as fallback. This is a cost/latency gate, not a security clarification. If a host-level no-questions directive prevents asking, choose Host-led Research (`host-seeded`) and report that broader provider investigation was skipped. If Provider-seeded Research is selected and the seed provider is not explicit, record the seed provider as pending; after provider availability is listed, ask which available provider should seed. Do not infer it. | ||
| ### Phase 4: Route Execution | ||
| Call `environment_check` and `provider_list`. | ||
@@ -55,3 +68,3 @@ | ||
| If external providers are available or named, hand off to `agestra:agestra-team-lead`. Provider-backed security uses the host research consensus flow: | ||
| If external providers are available or named, hand off to `agestra:agestra-team-lead`. Provider-backed security uses the selected research topology flow: | ||
@@ -75,3 +88,4 @@ ```text | ||
| - **Consensus domain:** `security` | ||
| - **Research notes:** {what the host-led investigation should look for — secrets/keys, auth/authz boundaries, file/command execution, network exposure, dependency concerns, unsafe defaults} | ||
| - **Research topology / 조사 방식:** {selected in Phase 3 — `host-seeded`, `council`, `provider-seeded`, or `automatic`} | ||
| - **Research notes:** {what the selected investigation should look for — secrets/keys, auth/authz boundaries, file/command execution, network exposure, dependency concerns, unsafe defaults} | ||
| - **Research assignments:** {optional participant/lens rows for `research_assignments`, or "team-lead choose"} | ||
@@ -83,3 +97,3 @@ - **Locale:** {from setup_status} | ||
| Team-lead owns: | ||
| - Calling `agent_research_consensus_start` with `domain: "security"`, the security `objective`, `participants`, optional `research_assignments`, optional `provider_order`, bounded `max_rounds`, and output document flags. | ||
| - Resolving the selected research topology, then calling `agent_research_consensus_start` when investigation fan-out is required or `agent_consensus_start` with prepared `initial_aggregation.items` when seed/host evidence is already available. | ||
| - Ensuring external AI research and debate use separate fresh sessions. | ||
@@ -90,3 +104,3 @@ - Never creating a bundled research pseudo-participant and never carrying research bundles through `source_documents`. | ||
| ### Phase 4: Present | ||
| ### Phase 5: Present | ||
@@ -93,0 +107,0 @@ Report: |
+5
-2
@@ -110,4 +110,7 @@ --- | ||
| When user triggers review/idea/design (via hook or command): | ||
| - Skip orchestration-mode selection | ||
| - Go directly to consensus debate mode using the enabled providers | ||
| - Use the existing provider config instead of asking provider setup again | ||
| - Still run the matching domain skill's question sheet, including domain-specific | ||
| cost gates and `조사 방식` / research topology selection when provider-backed | ||
| research is possible | ||
| - Route through team-lead for consensus/debate using the enabled providers | ||
| - If only 1 provider is enabled, inform user that debate needs 2+ participants and offer to add Claude as participant |
Sorry, the diff of this file is too big to display
New alerts
AI-detected potential code anomaly
Supply chain riskAI has identified unusual behaviors that may pose a security risk.
Found 1 instance in 1 package
URL strings
Supply chain riskPackage contains fragments of external URLs or IP addresses, which the package may be accessing at runtime.
Found 1 instance in 1 package
Fixed alerts
URL strings
Supply chain riskPackage contains fragments of external URLs or IP addresses, which the package may be accessing at runtime.
Found 1 instance in 1 package
Improved metrics
- Total package byte prevSize
1470831
2.18%- Lines of code
5935
0.15%Worsened metrics
- Number of low supply chain risk alerts
5
25%No dependency changes