pantheon-opencode 1.6.0-beta.6 → 1.6.0-beta.7

package/src/skills/auto-continue/SKILL.md

@@ -18,16 +18,16 @@ Disciplined automatic continuation through multi-step tasks. Eliminates unnecess
 
 ---
 
-## Mandatory Gates (ALWAYS STOP)
+## Risk-Proportional Gates
 
 | Gate | Trigger | What happens |
 |---|---|---|
-| **GATE 0 — Agora Gate** | Agora outputs `AWAITING_APPROVAL` OR `## 🏛️ Agora Council` synthesis block appears | **HARD STOP.** Do not call any tool, do not continue any todo, do not suggest next steps. Wait for user to type: APPROVE / REQUEST CHANGES / DISCARD. "ok", "yes", "sure", "continue" are NOT valid. |
-| **GATE 1 — Plan Approval** | Athena generates a plan | User confirms scope before code is written |
-| **GATE 2 — Phase Review** | Themis reviews implementation | User sees changes before next phase |
-| **GATE 3 — Git Commit** | After each phase is approved | User controls git history; no auto-commit |
+| **GATE 0 — Explicit Council** | User explicitly invokes council and it returns `AWAITING_APPROVAL` | Stop and follow the approval the council requests; do not launch a council automatically for ordinary implementation. |
+| **GATE 1 — Plan Approval** | A plan was requested or scope/risk makes planning necessary | Ask before implementation only when the plan introduces a material choice or risk; omit this gate for a bounded, clear fix. |
+| **GATE 2 — Risk Review** | Auth/security, data/schema/migration, API contract, production configuration, or other material risk | Themis review and human approval before sensitive or irreversible action. For a trivial, isolated, reversible edit, provide a concise result instead of manufacturing a review phase. |
+| **GATE 3 — Git / External Action** | Commit, push, merge, production deploy, destructive operation, global configuration, or broad permission change | Always stop for explicit human approval. Full-auto never authorizes these actions by implication. |
 
-> **Agora is always GATE 0**: any response containing `AWAITING_APPROVAL` or a `## 🏛️ Agora Council` block overrides all auto-continue rules.
+An explicit `AWAITING_APPROVAL` from an invoked council remains a hard stop. Authentication/security and data/schema changes retain their review and approval gates even in full-auto.
 
 ---
 
@@ -36,7 +36,7 @@ Disciplined automatic continuation through multi-step tasks. Eliminates unnecess
 **Continue automatically when:**
 - Next todo is a direct consequence of the current one
 - Action is reversible (file edits, tests, linting)
-- Scope is within the approved plan
+- Scope is within the user's explicitly authorized task (a prior plan is not required for a small clear fix)
 - No new ambiguity has emerged
 
 **Stop and ask when:**
@@ -44,6 +44,11 @@ Disciplined automatic continuation through multi-step tasks. Eliminates unnecess
 - An unexpected error changes the approach
 - A dependency is missing or broken
 - Remaining context is too thin to carry the task through — write an explicit handoff instead
+- The task reaches a sensitive gate in the table above; full-auto does not override it
+
+### Full-auto Authorization
+
+Full-auto may continue only within a task and scope the user explicitly authorized. It may run reversible edits and proportionate verification; it must stop for auth/security, data/schema changes with risk, destructive or global changes, broad permissions, deploy, push, or merge. Never infer permission to expand the scope from a full-auto request.
 
 ---
 
@@ -52,12 +57,12 @@ Disciplined automatic continuation through multi-step tasks. Eliminates unnecess
 ## Implementation Pattern
 
 ```
-1. Create todos for all steps at start
+1. Create todos only for multi-step work; a one-step fix needs no todo ceremony
 2. Mark first todo in_progress
 3. Complete work → mark completed immediately
 4. Mark next todo in_progress → repeat
 5. Do NOT ask "should I continue?" between clear steps
-6. Stop at Gate 1, 2, or 3
+6. Stop at any applicable risk gate; do not require a plan/review gate for a low-risk edit
 7. After gate approval, resume with next todo
 ```
 
@@ -89,9 +94,9 @@ Phase N complete. Summary:
 
 ### Cooldown Rules
 1. **Between parallel waves (no dependency):** No cooldown needed — wave results are independent
-2. **Between sequential waves (with dependency):** Always run cooldown — dependencies may have changed context
-3. **After Themis review (GATE 2):** Cooldown is mandatory — review findings may change the plan
-4. **Session reuse check:** Before starting next phase, check if a specialist session from a previous phase can be reused (see session-goal skill)
+2. **Between sequential phases:** Summarize when dependencies or risk changed; skip ceremony for one-step work
+3. **After required Themis review:** Reassess findings before continuing
+4. **Session reuse check:** Reuse a prior specialist session only when it reduces real context duplication
 
 ### Abbreviated Cooldown
 When auto-continuing between sequential non-gated phases, the cooldown is abbreviated to one line:
@@ -160,22 +165,27 @@ Should I now run the migration tests? [waiting]
 
 ## Session Heartbeat & Checkpoints
 
-Session state is **not** file-based. It lives in **pantheon-persistence** under the
-`checkpoint:<slug>` namespace and is cleaned up automatically by a 4h TTL.
+Use checkpoints only when `context_save` and `context_get` are explicitly present
+in the active session's tool list. Standalone OpenCode V2 agent profiles do not
+currently grant these tools; in that case, do not attempt a checkpoint or guess
+a session ID. Carry forward the phase and remaining tasks in the normal task
+handoff instead.
 
-Write state with `context_save(slug=slug, key=key, content=JSON.stringify(state), session_id=...)` and read it back with
+When the tools are available, write state with `context_save(slug=slug, key=key, content=JSON.stringify(state), session_id=...)` and read it back with
 `context_get(slug=slug, key="latest", session_id=...)`. Capture `session_id` from the first `context_save`
 of the session and reuse it for the rest of the session, so the `latest` pointer survives
-compaction.
+compaction. `state` must be an object — never pass a bare string as `content`: its
+`goal`/`phase`/`delegations`/`heartbeat` values are objects and `tail` is an array.
+`goal` is optional; when unset, omit the key rather than passing a string placeholder.
 
 ### Heartbeat Check
-- If `context_get(slug=slug, key="heartbeat", session_id=...)` returns a checkin older than 300s, log a stall warning and resume
-- Write a heartbeat after every anti-stall recovery action
+- When checkpoint tools are available, an old heartbeat (>300s) is a stall signal; log it before resuming.
+- Write a heartbeat after anti-stall recovery only when the current session exposes the checkpoint tools.
 
 ### Checkpoint Rules
-1. Save a checkpoint before **every** delegate dispatch and after every agent returns
-2. Include current phase, turn count, and remaining tasks
-3. On resume: `context_get(slug=slug, key="latest", session_id=...)` restores the most recent checkpoint
+1. Save checkpoints for long-running/multi-phase work, context-loss risk, or substantive parallel work — not a one-off command or bounded fix, and only when the tools are available
+2. Include current phase and remaining tasks when a checkpoint is warranted
+3. On resume, read the latest checkpoint only with a known session ID; otherwise request the missing handoff context.
 
 > Do not create `heartbeat.json`, `checkpoint-<N>.json`, or `session.json` under
 > `.pantheon/deepwork/`. That file-based mechanism is retired — TTL handles cleanup, and reading
@@ -189,10 +199,10 @@ Configurable gates for different platforms and risk levels:
 
 | Gate | Default | Auto-Approval Condition |
 |------|---------|------------------------|
-| GATE 0 — Council/Plan | Always Ask | N/A — always requires human |
-| GATE 1 — Plan Approval | Always Ask | Plan matches acceptance criteria + no risks flagged |
-| GATE 2 — Themis Review | Ask by Default | Auto-approve if: Themis APPROVED + no CRITICAL/HIGH issues + coverage ≥80% |
-| GATE 3 — Git Commit | Never Auto | N/A — always manual |
+| Council | Only when explicitly invoked | Never auto-start a council for ordinary implementation |
+| Plan approval | Only for requested or risk-required plans | Skip for bounded, clear work |
+| Themis review | Required for sensitive/material changes | May omit for trivial isolated edits; never auto-bypass required findings |
+| Git / external actions | Never Auto | Commit, push, merge, deploy, destructive/global changes require explicit approval |
 | Deploy | Always Ask | N/A — always requires human |
 | Destructive DB Ops | Always Ask | N/A — always requires human |
 
@@ -205,8 +215,8 @@ auto-continue:
   idle_stall: 120            # seconds before stall detection
   idle_pause: 300            # seconds before auto-pause
   gates:
-    plan_approval: always_ask
-    themis_review: auto_approve_if_clean
+    plan_approval: when_required_by_scope_or_risk
+    themis_review: required_for_sensitive_or_material_changes
     git_commit: never_auto
     deploy: always_ask
     destructive_ops: always_ask

package/src/skills/code-review-checklist/SKILL.md

@@ -52,11 +52,11 @@ biome check --write --unsafe <files>
 - [ ] Proper file sizes (<300 lines)
 
 ### Testing
-- [ ] Unit tests written
-- [ ] Coverage ≥80%
-- [ ] Integration tests for workflows
-- [ ] Edge cases tested
-- [ ] Error conditions tested
+- [ ] Tests cover the changed behavior where meaningful; documentation/format-only changes do not need invented tests
+- [ ] Apply an explicit repository coverage threshold only when measurable and relevant to the changed code
+- [ ] Integration tests where the change crosses workflow boundaries
+- [ ] Relevant edge cases tested for the changed behavior/risk
+- [ ] Relevant error conditions tested
 
 ### Security (OWASP Top 10)
 - [ ] Input validation present

package/src/skills/council-synthesis/SKILL.md

@@ -0,0 +1,29 @@
+---
+name: council-synthesis
+description: "Structured multi-agent council for explicit /pantheon requests and material decisions needing distinct perspectives. Load only when a council is actually needed."
+---
+
+# Council synthesis — `/pantheon`
+
+Use only when the user invokes `/pantheon` or a material decision genuinely needs distinct specialist views. Ordinary implementation, explanation, and bounded fixes do not need a council.
+
+## Run one useful round
+
+1. Search `council_decisions` for a directly relevant precedent. Reuse a fresh, matching decision with a warning to re-check current context; otherwise treat it as context, not authority.
+2. Select two specialists by default. Add a third only when the question spans a separate domain; include @themis when security, correctness, or a material quality gate requires review.
+3. Ask each specialist the same focused question and request a position, evidence, trade-offs, key risks, and confidence. Dispatch independent work together only when native background delegation is enabled; otherwise use normal `task()` calls.
+4. Synthesize after one response round. State agreements, real disagreements, missing responses, and uncertainty. Do not run a routine rebuttal, duplicate moderator/audit pass, or repeat the panel. Check a disputed factual claim only when it could change the recommendation; ask one focused follow-up if evidence remains insufficient.
+5. Give the user a concise recommendation with the main trade-off and any unresolved risk. Cite external research when used. Preserve human approval and Themis gates for sensitive or irreversible actions.
+6. Persist only a reusable, material decision in `council_decisions`; do not store routine opinions or user-specific details without a need.
+
+## Specialist response
+
+```text
+position: one sentence answering the question
+evidence: the key facts or reasoning (2–4 sentences)
+trade-offs: one concrete gain and loss
+risks: up to 3
+confidence: High | Medium | Low
+```
+
+Use High only with multiple verifiable facts, Medium with some evidence, and Low for mainly judgment-based conclusions. Do not invent consensus or confidence.

package/src/skills/tdd-with-agents/SKILL.md

@@ -8,13 +8,21 @@ alwaysApply: false
 
 # TDD with Agents
 
-Enforce RED → GREEN → REFACTOR cycle across all implementation agents. Includes advanced testing patterns for E2E, load, mutation, and contract testing.
+Use RED → GREEN → REFACTOR for behavior-changing implementation where a meaningful test can express the change. Keep verification proportional to the changed surface and risk; advanced testing patterns are reserved for changes that warrant them.
 
 ---
 
 ## Core Principle
 
-> **Write the test FIRST. Watch it fail. Write minimal code to pass. Refactor with confidence.**
+> **For testable behavior changes, write the focused test first, observe RED, implement minimally, then refactor.**
+
+## Proportional TDD
+
+- Use the complete RED → GREEN → REFACTOR cycle for new or changed behavior when a focused test is practical. Include a focused regression check for bug fixes.
+- For typo, formatting, documentation-only, or otherwise non-behavioral edits, do not invent a test; inspect the diff and run the narrowest relevant validation.
+- Run targeted tests for a small change. Run broader suites when the changed surface, integration boundaries, or risk make them useful; do not run the whole suite solely because one line changed.
+- If a relevant existing test already captures the behavior, use it instead of adding a duplicate. If no automated check can express the change, report the manual or static verification performed.
+- Auth, security, payment, data-integrity, and schema/migration changes retain focused RED/GREEN tests, required regression coverage, and Themis review. Do not weaken a project-specific required safety gate.
 
 ---
 
@@ -112,12 +120,12 @@ def test_provider_satisfies_consumer_contract():
     pass
 ```
 
-### Mutation Testing
+### Mutation Testing (high-risk/critical logic only)
 - Mutate source code (change `>` to `<`, remove conditions)
 - Run tests → should fail (mutation killed)
 - If tests pass → test is weak; improve it
 
-### Visual Regression
+### Visual Regression (visual behavior only)
 ```typescript
 test('homepage looks the same', async ({ page }) => {
   await page.goto('/')
@@ -129,8 +137,8 @@ test('homepage looks the same', async ({ page }) => {
 
 ## Coverage Rules
 
-- **Minimum: 80%** for all code
-- **Critical paths: 100%** (auth, payments, data integrity)
+- Follow a repository's explicit coverage threshold when the changed code is in its measurement scope; do not manufacture a coverage target for docs, formatting, or a tiny isolated edit.
+- **Critical paths:** preserve project-required coverage and tests for auth, payments, and data integrity.
 - **No snapshot testing** — test behavior, not output shape
 - **Test edge cases**: empty input, null, boundary values, errors
 
@@ -143,20 +151,20 @@ test('homepage looks the same', async ({ page }) => {
 | **Hermes** | Unit + integration for FastAPI endpoints, services, middleware |
 | **Aphrodite** | Component behavior tests with React Testing Library |
 | **Demeter** | Migration upgrade/downgrade, query correctness |
-| **Themis** | Verifies coverage ≥80%, edge cases tested, error conditions |
+| **Themis** | Reviews the changed surface, relevant edge/error cases, and applicable repository coverage requirements; always review sensitive/material changes |
 
 ---
 
 ## Workflow
 
 ```
-1. Zeus/Athena defines feature with testable acceptance criteria
+1. Use a plan/spec only when scope, risk, or ambiguity warrants it; a bounded fix may proceed directly
 2. Hermes writes failing test (RED)
 3. Hermes implements minimal code (GREEN)
 4. Hermes refactors (REFACTOR)
 5. Aphrodite writes frontend tests in parallel
-6. Themis reviews: coverage, edge cases, correctness
-7. If coverage <80% → NEEDS_REVISION
+6. Themis reviews sensitive or material changes, checking changed behavior and applicable quality gates
+7. Escalate unmet repository or safety-critical test requirements; do not fail a micro-edit against an unrelated global coverage figure
 ```
 
 ---

package/scripts/hooks/scan-secrets.sh

@@ -1,97 +0,0 @@
-#!/usr/bin/env bash
-# scan-secrets.sh — Pantheon PreToolUse Secret Scanning Hook
-# Detects hardcoded secrets in tool input. Logs ALWAYS (masked); the exit
-# code drives the plugin's hybrid blocking (see pantheon-hooks.ts):
-#
-#   exit 0 — no match.
-#   exit 1 — LOW_CONFIDENCE match only (header/KEY NAMES such as the Bifrost header
-#            alone, api_key=/password=/secret= without a recognizable token
-#            value). Advisory: the plugin logs + toasts, does NOT block.
-#   exit 2 — HIGH_CONFIDENCE match (real token formats: sk-bf-<token>,
-#            AKIA..., ghp_..., glpat-..., sk_live_/sk_test_..., xox[baprs]-...,
-#            Bearer <token>, JWT). The plugin BLOCKS the tool call (throws
-#            after logging — the only deliberate throw in the plugin).
-#
-# Matches are always MASKED (first 4 + last 4 chars for len>8, else "****")
-# before being echoed — the hook trail must never contain a raw secret value.
-set -euo pipefail
-
-HIGH_CONFIDENCE_PATTERNS=(
-    "AKIA[0-9A-Z]{16}"
-    "gh[pousr]_[A-Za-z0-9_]{36,}"
-    "glpat-[A-Za-z0-9_\\-]{20}"
-    "sk-[a-zA-Z0-9]{20,}"
-    "sk_live_[a-zA-Z0-9]{20,}"
-    "sk_test_[a-zA-Z0-9]{20,}"
-    "xox[baprs]-[0-9]{10,13}-[0-9]{10,13}-[a-zA-Z0-9]{24}"
-    "bearer\\s+[a-zA-Z0-9_\\-\\.]{20,}"
-    "eyJ[A-Za-z0-9_-]*\\.eyJ[A-Za-z0-9_-]*\\.[A-Za-z0-9_-]*"
-)
-
-LOW_CONFIDENCE_PATTERNS=(
-    # KEY/header NAMES without a recognizable token value — high false-positive
-    # rate (e.g. the Bifrost header alone, api_key=longvalue, password="x", secret="y"):
-    # advisory only, never blocks.
-    "[a-zA-Z0-9_-]*api[_-]?key[a-zA-Z0-9_-]*\\s*[:=]\\s*[\"']?[a-zA-Z0-9_\\-]{16,}[\"']?"
-    "[a-zA-Z0-9_-]*password[a-zA-Z0-9_-]*\\s*[:=]\\s*[\"'][^\"']{8,}[\"']"
-    "[a-zA-Z0-9_-]*secret[a-zA-Z0-9_-]*\\s*[:=]\\s*[\"'][^\"']{8,}[\"']"
-)
-
-# Keep provider-specific markers assembled so this scanner is not self-matched
-# by the repository secret test.
-BIFROST_HEADER="x""-bf-""vk"
-BIFROST_TOKEN_PREFIX="sk""-bf-"
-HIGH_CONFIDENCE_PATTERNS+=("${BIFROST_TOKEN_PREFIX}[A-Za-z0-9_-]{8,}")
-LOW_CONFIDENCE_PATTERNS+=("$BIFROST_HEADER")
-
-# Mask a matched secret for safe logging: first 4 + last 4 chars (len > 8),
-# else fully hidden — short matches must not be reconstructable by
-# concatenating the visible slices.
-mask_secret() {
-    local match="$1"
-    if [[ ${#match} -le 8 ]]; then
-        echo "****"
-    else
-        echo "${match:0:4}****${match: -4}"
-    fi
-}
-
-INPUT="${1:-${TOOL_INPUT:-}}"
-if [[ -z "$INPUT" ]] && [[ ! -t 0 ]]; then
-    INPUT=$(cat)
-fi
-
-if [[ -z "$INPUT" ]]; then
-    exit 0
-fi
-
-FOUND_HIGH=0
-FOUND_LOW=0
-
-for pattern in "${HIGH_CONFIDENCE_PATTERNS[@]}"; do
-    if echo "$INPUT" | grep -iqE "$pattern"; then
-        MATCH=$(echo "$INPUT" | grep -ioE "$pattern" | head -1)
-        echo "[SECRET SCAN] High-confidence secret detected: $(mask_secret "$MATCH") (pattern: $pattern)" >&2
-        FOUND_HIGH=1
-    fi
-done
-
-for pattern in "${LOW_CONFIDENCE_PATTERNS[@]}"; do
-    if echo "$INPUT" | grep -iqE "$pattern"; then
-        MATCH=$(echo "$INPUT" | grep -ioE "$pattern" | head -1)
-        echo "[SECRET SCAN] Potential secret detected (low confidence): $(mask_secret "$MATCH") (pattern: $pattern)" >&2
-        FOUND_LOW=1
-    fi
-done
-
-if [[ $FOUND_HIGH -eq 1 ]]; then
-    echo "[SECRET SCAN] High-confidence hardcoded secret detected. Tool call will be BLOCKED." >&2
-    exit 2
-fi
-
-if [[ $FOUND_LOW -eq 1 ]]; then
-    echo "[SECRET SCAN] Possible secret detected. Remove it and use environment variables or a vault." >&2
-    exit 1
-fi
-
-exit 0

package/src/instructions/zeus-council-synthesis.instructions.md

@@ -1,299 +0,0 @@
----
-description: "Council synthesis — dispatch 2-4 specialists inline for multi-perspective decisions with precedent fast-path, confidence cross-validation, rebuttal rounds, and Themis audit gate"
-name: "Zeus Council Synthesis"
-applyTo: "agents/zeus.agent.md"
----
-
-# 🏛️ INLINE COUNCIL SYNTHESIS — /pantheon
-
-When a question requires multiple expert perspectives on a trade-off or architecture decision, **dispatch specialists inline** (visible to user) instead of delegating to a hidden subagent.
-
-## Trigger Patterns (detect ANY)
-- Trade-off questions: "which is better?", "should we use X or Y?", "compare A and B"
-- Architecture decisions with long-term impact
-- Security/compliance choices
-- Technology selection (databases, frameworks, providers, libraries)
-- "Is this safe?", "trade-offs of...", "what are the risks?"
-- Cost vs quality decisions
-- Multi-stakeholder concerns (frontend + backend + infra)
-
-```mermaid
----
-config:
-  look: classic
-  theme: dark
----
-sequenceDiagram
-    participant U as User
-    participant Z as Zeus
-    participant M as Memory (Precedent)
-    participant A as Apollo (Research)
-    participant B as BackgroundJobBoard
-    participant S1 as Specialist 1
-    participant S2 as Specialist 2
-    participant S3 as Specialist 3
-    participant W as Web Search
-    participant T as Themis (Audit + Moderator)
-
-    U->>Z: /pantheon [--research] question
-    Z->>M: memory_search(query, namespace="council_decisions")
-    alt Precedent found (score > 0.85)
-        M-->>Z: ⚠️ Cached decision
-        Z->>U: Fast-path precedent
-    else No precedent
-        opt --research flag
-            Z->>A: 30s pre-scan
-            A-->>Z: Context brief
-        end
-        Z->>B: registerLaunch({council session})
-        par Dispatch all specialists
-            Z->>S1: Domain query + shared context
-            Z->>S2: Domain query + shared context
-            Z->>S3: Domain query + shared context
-        end
-        par Collect responses
-            S1-->>Z: Structured response
-            S2-->>Z: Structured response
-            S3-->>Z: Structured response
-        end
-        Note over Z: Cross-validate confidence
-        alt Agreement rate < 50%
-            Z->>S1: Rebuttal round
-            Z->>S2: Rebuttal round
-            Z->>S3: Rebuttal round
-            S1-->>Z: Refined response
-            S2-->>Z: Refined response
-            S3-->>Z: Refined response
-            Note over Z: Ainda divergência?
-            alt Agreement rate STILL < 50%
-                Z->>W: browser_search() for each divergence point
-                W-->>Z: Evidence brief with sources
-                Z->>T: Dispatches as moderator
-                Note over T: Reviews evidence + specialist responses
-                T-->>Z: Moderator verdict
-            end
-        end
-        Z->>Z: Synthesize (with evidence if tie-broken)
-        Z->>T: Audit synthesis fidelity
-        T-->>Z: ✅ / ⚠️ Issues
-        Z->>M: Store decision
-        Z->>B: Mark reconciled
-        Z->>U: 🏛️ Council Synthesis
-    end
-```
-
-## Dispatch Sequence (9-Step Protocol)
-
-### Step 0 — Precedent Fast-Path (Fase 1)
-Run the precedent read path defined in `## Memory Protocol > Council Decisions Namespace` (`memory_search(query=question, top_k=2, namespace="council_decisions")`). If no precedent applies, proceed to Step 0b.
-
-### Step 0b — Apollo Pre-Scan (Fase 2, --research flag)
-If `/pantheon --research <question>`: dispatch @apollo with 30s timeout. Inject findings as `shared_context` into ALL specialist prompts. Skip if flag absent.
-
-### Step 1 — Register on BackgroundJobBoard (Fase 1)
-Before dispatching specialists:
-```
-board.registerLaunch({
-  taskID: "council:<uuid>",
-  parentSessionID: "<session-id>",
-  agent: "zeus",
-  description: "Council: <question>",
-  objective: "Synthesize specialist recommendations"
-})
-```
-Enables crash recovery — if context is lost mid-synthesis, the board preserves session state.
-
-### Step 2 — Select Specialists
-Use domain-to-specialist mapping table (below). Max 3 specialists.
-
-### Step 3 — Dispatch ALL task() calls in ONE message
-Each specialist prompt MUST include:
-- Structured output template (see Specialist Output Format below)
-- `shared_context` if Apollo pre-scan was done
-- Timeout per role: 120s for reviewers, 60s for explorers/implementers
-
-### Step 4 — Collect Responses
-Wait for all responses. Note TIMEOUT agents. Partial results OK only for read-only specialists (@apollo, @gaia).
-
-### Step 5 — Confidence Cross-Validation (Fase 2)
-For each specialist response, validate confidence claims:
-
-| Reported | Minimum Required | Action |
-|----------|-----------------|--------|
-| High | ≥ 3 specific claims | If fewer → downgrade to Medium, annotate "(auto-downgraded from High: only N specific claims)" |
-| Medium | ≥ 1 specific claim | Pass |
-| Low | Any response | Pass |
-
-"Specific claim" = statement with evidence, data point, or verifiable fact (not opinion).
-
-### Step 6 — Divergence-Gated Rebuttal Round (Fase 2, conditional)
-Calculate agreement rate = `min(agreements, divergences) / total_points` from structured `agreement_signals`. If < 50% agreement:
-- Dispatch ONE rebuttal round: specialists see ALL other responses and refine their own
-- Updated responses treated as final
-- Hard cap: MAX 3 total rounds (initial + 2 rebuttals)
-- Skip if any TIMEOUT occurred (can't rebuttal without all voices)
-
-### Step 6b — Modo Desempate com Evidência (Fase 2, conditional)
-
-If after Step 6 the agreement rate is STILL < 50% (rebuttal did not resolve divergence):
-
-1. **Identify divergence points** — Parse all specialist responses (initial + rebuttal) and extract specific issues where positions differ
-2. **Web research** — For EACH divergence point, Zeus calls `browser_search()` or `webfetch()` to find factual evidence:
-   - Benchmarks, documentation, GitHub issues, official sources
-   - At least 2 independent sources per point when possible
-   - Focus on factual data, not opinion
-3. **Compile Evidence Brief** — Structure findings as:
-   ```
-   ## evidence_brief
-   **divergence_point_1:** <description>
-   **evidence_found:** <facts from web, max 3 sentences>
-   **sources:** [URL1, URL2]
-
-   **divergence_point_2:** ...
-   ```
-4. **Dispatch @themis as moderator** — Send ONE task with:
-   - All specialist responses (initial + rebuttal)
-   - The evidence brief
-   - Prompt: "Act as impartial moderator. These specialists disagree on [points]. Here is web evidence on each point. Issue a final verdict for each divergence point, citing specific evidence. Return structured verdict."
-5. **Themis returns moderator verdict** in this format:
-   ```
-   ## moderator_verdict
-   **divergence_points_analyzed:** <count>
-   **verdicts:**
-     - <point 1>: <decision> — evidence: <citation>
-     - <point 2>: <decision> — evidence: <citation>
-   **overall_direction:** <which approach is better supported by evidence>
-   **confidence:** High | Medium | Low
-   **unresolved:** <any points still unclear despite evidence>
-   ```
-6. **Zeus incorporates verdict** into synthesis (Step 7), showing which evidence supported which conclusion
-
-**Rules:**
-- Only triggers when agreement rate < 50% AFTER rebuttal round
-- Skip if NO divergence points are web-researchable (purely subjective/opinion-based disagreements)
-- Max 3 web searches per council (prevents runaway)
-- If Themis confidence is Low or points remain unresolved, note this explicitly in synthesis
-- Themis moderator role is SEPARATE from the Themis Audit Gate (Step 8) — they serve different functions
-
-### Step 7 — Zeus Synthesize
-Use structured `agreement_signals` to auto-detect agreements/divergences. Output synthesis template (see below).
-
-### Step 8 — Themis Audit Gate (Fase 1)
-Post-synthesis, dispatch @themis:
-```
-task(subagent_type: "themis", prompt: "Audit this council synthesis for fidelity. Compare raw specialist responses against the synthesized output. Check: (1) Any specialist misrepresented? (2) Divergences hidden or softened? (3) Confidence claims match response specificity? Return ✅ or list specific issues.")
-```
-- If ✅ → proceed
-- If issues → fix each issue before delivering to user
-
-### Step 9 — Persist & Reconcile (Fase 1)
-Persist the decision using the write path in `## Memory Protocol > Council Decisions Namespace`, then `board.markReconciled("<task-id>")`.
-
-## Specialist Output Format (Fase 1 — machine-parseable structured fields)
-
-Specialists MUST return the structured `## specialist_response` format (position, reasoning, trade_offs, risks, confidence, agreement_signals, specific_claims) defined in `## Agent Return Format > Council Specialist Response Format`.
-
-## Domain-to-Specialist Mapping
-
-| Domain | Specialists |
-|--------|-------------|
-| Architecture | hermes, demeter, themis, athena |
-| Security | themis, hermes, prometheus, nyx |
-| Database | demeter, hermes, prometheus |
-| AI/RAG | hephaestus, nyx |
-| Infrastructure | prometheus, hermes, themis |
-| Frontend/UX | aphrodite, themis, hermes |
-| Observability | nyx, hermes |
-| General | athena, themis, hermes |
-
-## Synthesis Output Template (enhanced)
-
-```
-## 🏛️ Council Synthesis
-
-**Question:** <original question>
-**Date:** <date>
-**Response rate:** X of Y specialists responded
-**Timed out:** @agent1, @agent2 (if any)
-**Precedent used:** yes/no (which one, date)
-**Research context:** <shared_context summary> (if --research)
-
-### Specialist Perspectives
-| Agent | Position | Trade-offs | Confidence |
-|-------|----------|------------|------------|
-| @agent1 | ... | ... | High/Med/Low |
-
-### Agreements
-- <what 2+ specialists agree on>
-
-### Divergences
-| Issue | Side A | Side B | Resolution |
-|-------|--------|--------|------------|
-
-### Evidence & Moderation (if tie-break activated)
-**Divergence points researched:** <list>
-**Evidence summary:** <key findings from web>
-**Moderator verdict:** <Themis final determination>
-**Sources:** <citations>
-
-### Recommendation
-<decisive conclusion>
-
-### Audit Gate
-**Status:** ✅ Themis approved | ⚠️ Issues corrected
-
-### Decision Gate
-**Confidence:** High/Medium/Low (adjusted for response rate)
-```
-
-## Themis Audit Gate Rules (Fase 1)
-
-1. Every specialist mentioned in synthesis? → ✅
-2. Divergences from raw responses preserved (not softened/hidden)? → ✅
-3. No specialist attributed a position they didn't state? → ✅
-4. Confidence claims match response specificity? → ✅
-5. If any ❌, list specific issues for Zeus to fix before delivery
-
-## Rebuttal Round Rules (Fase 2)
-
-1. Only triggers when agreement rate < 50%
-2. MAX 3 rounds total (including initial dispatch)
-3. Skip if any TIMEOUT (can't rebuttal without all voices)
-4. Each rebuttal round: specialist sees ALL other responses + current synthesis draft
-5. Refined responses replace originals for the final synthesis
-6. If agreement rate STILL < 50% after rebuttal → Step 6b (Modo Desempate com Evidência)
-
-## Crash Recovery via BackgroundJobBoard (Fase 1)
-
-If Zeus context crashes mid-council:
-1. On restart, `board.recoverRunningJobs()` marks running jobs as error
-2. Check `board.formatForPrompt()` for unreconciled terminal jobs
-3. Re-dispatch council with same question, noting: "⚠️ Retry — previous council session crashed. Using same question."
-
-## Performance Budget
-
-| Step | Latency | Phase |
-|------|---------|-------|
-| Precedent fast-path | < 500ms | Fase 1 |
-| Apollo pre-scan | +30s (optional, --research) | Fase 2 |
-| Specialist dispatch | bounded by slowest (60-120s) | — |
-| Rebuttal round | +60s (conditional, < 50% agreement) | Fase 2 |
-| Web search (tie-break) | +15s (conditional, < 50% after rebuttal) | Fase 2 |
-| Themis moderator | +15s (conditional, tie-break activated) | Fase 2 |
-| Themis audit | +15s | Fase 1 |
-| **Total worst case** (research + rebuttal + tie-break) | ~255s | — |
-| **Total typical** (no research, no rebuttal, no tie-break) | ~45-90s | — |
-
-> **Note**: The user can explicitly invoke this via `/pantheon <question>`. The `--research` flag adds Apollo pre-scan. All decisions are stored in `council_decisions` memory namespace for fast-path retrieval on future councils.
-
-## Modo Desempate Rules (Fase 2)
-
-1. Only triggers when agreement rate < 50% AFTER rebuttal round
-2. If no divergence points are web-researchable (pure opinion disagreement), skip — Zeus synthesizes with lower confidence
-3. Max 3 web searches per council invocation
-4. Themis moderator role is DISTINCT from Themis audit gate:
-   - Moderator: resolves substantive disagreement between specialists (reads evidence, gives verdict)
-   - Audit gate: checks synthesis fidelity against raw responses (quality assurance)
-   Both run in the same council invocation, at different steps
-5. If Themis moderator confidence is Low, mark as "unresolved tie" in the synthesis output
-6. Evidence from web search must be cited with source URL or document reference — no anonymous claims