ultimate-pi 0.11.0 → 0.13.0

package/.agents/skills/ck-search/SKILL.md

@@ -1,99 +1,23 @@
 ---
 name: ck-search
-description: "Semantic code search using ck. Use when exploring codebases, finding related code, or searching by concept rather than exact text. Triggers on: search for, find code that, where is, look for patterns, find all files related to, find similar code, explore codebase, semantic search."
+description: "DEPRECATED — ck-search was removed from ultimate-pi. Use cocoindex-search or /skill:ccc instead. Triggers retained for backward compatibility: ck, ck-search, semantic search."
 ---
 
-# ck-search: Semantic Code Search
+# ck-search (deprecated)
 
-## When to Use
+**`ck` / `@beaconbay/ck-search` is no longer used in this harness.**
 
-Use `ck` instead of `grep`/`find` for **any codebase exploration**. Reserve raw grep for only: exact literal string match (specific error message, exact function name).
+Use instead:
 
-## Quick Reference
+- **`/skill:cocoindex-search`** or **`/skill:ccc`** — CocoIndex Code (`ccc search`)
+- **graphify** — architecture, callers, communities (`graphify query`, `explain`, `path`)
 
-```bash
-# Hybrid (best default — lexical + semantic fused via RRF)
-ck --hybrid "query" .
-
-# Semantic only (conceptual — finds by meaning)
-ck --sem "concept" src/
-
-# Lexical BM25 (phrase-based, better than grep for multi-word)
-ck --lex "phrase" .
-
-# Grep-compatible (exact match, same flags as grep)
-ck "exact string" -rn src/
-```
-
-## Search Decision Tree
-
-```
-Agent needs to find code
-  ├─ Exact literal string (error msg, function name) → grep/rg
-  ├─ Conceptual / multi-word → ck --hybrid
-  ├─ Find similar patterns → ck --sem
-  └─ Unsure → ck --hybrid (safe default)
-```
-
-## Key Flags
-
-| Flag | Purpose | When |
-|------|---------|------|
-| `--hybrid` | BM25 + semantic RRF fusion | **Default for exploration** |
-| `--sem` | Semantic only (embedding similarity) | Conceptual: "error handling", "auth flow" |
-| `--lex` | BM25 lexical only | Phrase search without regex |
-| `--limit N` | Top N results | Keep output lean (default 10) |
-| `--threshold 0.7` | Min similarity score | Filter low-confidence results |
-| `--json` | Machine-readable output | When piping to other tools |
-| `-n` | Line numbers | Same as grep |
-| `-C N` | Context lines | Same as grep |
-| `-r` | Recursive | Same as grep |
-| `-l` | Files with matches | List matching files only |
-
-## Index Management
-
-```bash
-ck --status .              # Check if index exists
-ck index .                 # Build/rebuild full index
-ck --add file.ts           # Add single file to index
-ck --clean .               # Remove index (rebuild from scratch)
-ck --switch-model MODEL    # Rebuild with different embedding model
-```
-
-## Usage Patterns
+## Migration
 
-### Find related code
 ```bash
-ck --hybrid "retry logic with exponential backoff" .
+uv tool install 'cocoindex-code[full]'
+bash "$UP_PKG/.pi/scripts/harness-cocoindex-bootstrap.sh"
+ccc search --limit 10 "your query"
 ```
 
-### Find authentication code
-```bash
-ck --sem "authentication middleware" src/ --limit 20
-```
-
-### Find error handling patterns
-```bash
-ck --hybrid "error handling and recovery" src/ --limit 15
-```
-
-### Find database code
-```bash
-ck --sem "database connection pool" src/
-```
-
-### Exact function name (still use grep)
-```bash
-grep -rn "processPayment" src/
-```
-
-## Integration Notes
-
-- **Index location**: `.ck/index/` in project root (gitignored)
-- **First search auto-indexes**: `ck --sem` builds index on first run if missing
-- **Fully offline**: No API keys, no network, embeddings run locally
-- **MCP mode**: `ck --serve` exposes ck_search/ck_get/ck_info/ck_reindex as MCP tools (future integration)
-
-## Token Efficiency
-
-ck results are ranked and scored. Use `--limit` to cap output. A typical ck --hybrid call returns 10 results (~500-1000 tokens) vs raw grep which can return hundreds of unranked matches (~5000-20000 tokens).
+Remove legacy index: `rm -rf .ck` (optional).

package/.agents/skills/cocoindex-search/SKILL.md

@@ -0,0 +1,35 @@
+---
+name: cocoindex-search
+description: "Semantic code search using CocoIndex Code (ccc). Use when exploring codebases, finding related implementation by meaning, or replacing legacy ck-search. Triggers on: semantic code search, ccc, cocoindex, cocoindex-code, find code related to, search the codebase for implementation, /skill:ck-search."
+---
+
+# cocoindex-search
+
+CocoIndex Code (`ccc`) provides offline, AST-aware semantic search over the project codebase.
+
+## Quick start
+
+```bash
+ccc search --limit 10 "harness subagent policy"
+ccc status
+```
+
+## Full reference
+
+Load the vendored skill: **`/skill:ccc`** (`.pi/skills/ccc/SKILL.md`).
+
+## Harness lanes
+
+| Question type | Tool |
+|---------------|------|
+| Callers, callees, cross-module paths | `graphify explain` / `graphify path` |
+| Implementation by meaning | `ccc search --limit N "…"` |
+| Structural patterns | `sg -p '…'` |
+
+## Setup
+
+```bash
+bash "$UP_PKG/.pi/scripts/harness-cocoindex-bootstrap.sh"
+```
+
+Indexing before harness scouts is automatic — do not run `ccc index` or `ccc search --refresh` in `scout-semantic`.

package/.agents/skills/harness-debate-plan/SKILL.md

@@ -0,0 +1,44 @@
+---
+name: harness-debate-plan
+description: Plan-phase Review Gate debate — assemble rounds, token caps, bus envelopes for parent orchestrator.
+---
+
+# harness-debate-plan
+
+Use when running **Phase 5** of `/harness-plan` — four Review Gate rounds on the plan debate bus.
+
+## Open
+
+```
+/harness-debate-open plan-<run_id>
+```
+
+Budget profile **plan**: `max_rounds=4`, `round_token_cap=2000`, `debate_global_cap=12000`.
+
+## Per-round spawn order
+
+1. Round-specific extras (R1: `hypothesis-validator` first, blind)
+2. `plan-evaluator`
+3. `plan-adversary`
+4. R4: `sprint-contract-auditor` (required)
+5. `review-integrator`
+
+## Artifacts (YAML)
+
+| Agent | Output path |
+|-------|-------------|
+| hypothesis-validator | `artifacts/hypothesis-validation-r{N}.yaml` |
+| plan-evaluator | `artifacts/validation-turn-r{N}.yaml` |
+| plan-adversary | `artifacts/adversary-brief-r{N}.yaml` |
+| sprint-contract-auditor | `artifacts/sprint-audit-r{N}.yaml` |
+| review-integrator | `artifacts/review-round-r{N}.yaml` |
+
+## Bus envelope
+
+Load `review-round-r{N}.yaml`, validate, then `buildPlanReviewRoundEnvelope` (`.pi/extensions/lib/plan-debate-envelope.ts`) → `/harness-debate-round '<json>'`.
+
+Plan participants only. `StackResearchAgent` uses `artifacts/stack.yaml` claims — no spawn.
+
+## Close
+
+After round 4: `/harness-debate-consensus`. Do not `approve_plan` on `policy_decision: block`.

package/.agents/skills/harness-decisions/SKILL.md

@@ -71,5 +71,5 @@ Parent orchestrator calls **`approve_plan`** with the full `plan_packet` (scroll
 ## Who calls what
 
 - **Parent orchestrator** during `/harness-plan` — `ask_user` for clarification; **`approve_plan`** then **`create_plan`** for the plan file.
-- `harness/planning/*` (scouts, decompose, hypothesis, plan-adversary, hypothesis-eval) — JSON only; no `ask_user` / `approve_plan` / `create_plan`.
+- `harness/planning/*` (scouts, decompose, hypothesis, hypothesis-eval) — JSON only; no `ask_user` / `approve_plan` / `create_plan`.
 - `harness/evaluator`, `harness/adversary`, and `harness/tie-breaker` — emit `human_required`; the **parent orchestrator** calls `ask_user`.

package/.agents/skills/harness-orchestration/SKILL.md

@@ -1,24 +1,48 @@
 ---
 name: harness-orchestration
 description: >-
-  Orchestrate ultimate-pi harness phases with Agent spawns, blackboard handoffs,
-  and observation-bus artifacts. Use for plan/execute/evaluate pipelines, L4
-  verification, parallel scouts, and debate prep.
+  Orchestrate ultimate-pi harness phases with the native `subagent` tool
+  (isolated `pi --mode json` subprocesses). Use for plan/execute/evaluate
+  pipelines, L4 verification, parallel scouts, and debate prep.
 ---
 
 # Harness orchestration
 
 ## Slash commands = orchestrators
 
-`/harness-*` prompts parse args, spawn agents, run `ask_user`, write policy-gated artifacts. Phase logic lives in `.pi/agents/harness/*.md` and `.pi/agents/harness/planning/*.md`.
+`/harness-*` prompts parse args, call `subagent`, run `ask_user`, write policy-gated artifacts. Phase logic lives in `.pi/agents/harness/*.md` and `.pi/agents/harness/planning/*.md`.
 
-Every spawn includes **HarnessSpawnContext** JSON (subagents do not get `[HarnessActivePlan]` injection). Use `inherit_context: false`.
+Every spawn includes **HarnessSpawnContext** JSON in the task text (subprocess agents do not get `[HarnessActivePlan]` injection). Use `agentScope: "both"` so package agents under `$UP_PKG/.pi/agents/**` resolve.
+
+## Subprocess telemetry
+
+Harness bridge emits `harness_subagent_spawned` / `harness_subagent_completed` (replaces in-process setup/blackboard events).
+
+```sql
+SELECT
+  properties.agent as agent,
+  count() as n,
+  round(avg(toFloat(properties.duration_ms)), 0) as avg_ms
+FROM events
+WHERE event = 'harness_subagent_completed'
+  AND timestamp >= now() - INTERVAL 7 DAY
+GROUP BY agent
+ORDER BY avg_ms DESC
+LIMIT 30
+```
+
+## Latency rules
+
+1. **Parallel `tasks`** — one `subagent({ tasks: [...] })` for scouts, decompose+hypothesis, or review fan-in; subprocesses run in parallel upstream.
+2. **Blocking calls** — each `subagent` returns when the subprocess exits; no `get_subagent_result` polling.
+3. **Compact handoffs** — pass scout/decompose JSON only; never paste full subprocess message logs into the next spawn.
+4. **Spawn caps** — bridge enforces **8** active + **12** total harness spawns per session. Do **not** pass `timeoutMs` unless the user wants a cap — subprocesses wait for natural exit (`PI_SUBAGENT_TIMEOUT_MS` optional env backstop only).
 
 ## Command → agent
 
-| Command | `subagent_type` |
-|---------|-----------------|
-| `/harness-plan` | Parent: parallel `scout-*` → `decompose` → `hypothesis` → PlanPacket → parallel `plan-adversary` + `hypothesis-eval`; `approve_plan` + `create_plan` |
+| Command | `agent` |
+|---------|---------|
+| `/harness-plan` | Parent: parallel `harness/planning/scout-*` → parallel `decompose`+`hypothesis` → PlanPacket → reviews; `approve_plan` + `create_plan` |
 | `/harness-run` | `harness/executor` |
 | `/harness-eval` | `harness/evaluator` (`mode: benchmark`) |
 | `/harness-review` | `harness/evaluator` (`mode: verdict`) |
@@ -26,41 +50,43 @@ Every spawn includes **HarnessSpawnContext** JSON (subagents do not get `[Harnes
 | `/harness-trace` | `harness/trace-librarian` |
 | `/harness-incident` | `harness/incident-recorder` |
 | `/harness-router-tune` | `harness/meta-optimizer` (optional) |
-| `/harness-auto` | plan phases per `/harness-plan`, then sequential spawns above |
+| `/harness-auto` | plan per `/harness-plan`; `--quick` skips adversary + tie-breaker |
 
 ## Review isolation
 
-Spawn `harness/evaluator` / `harness/adversary` in the **same** parent session — isolated subagent context replaces session fork (ADR 0032).
+Spawn `harness/evaluator` / `harness/adversary` via `subagent` in the **same** parent session. `review-integrity` allows `subagent` when `agent` is in the review set; blocks executor from spawning review agents during evaluate.
 
 ## ask_user policy
 
-| Agent | `ask_user` |
-|-------|------------|
-| Parent orchestrator | Yes (plan clarification, approval via `approve_plan`, router tune) |
-| `harness/planning/*` | No — JSON only |
-| `harness/evaluator`, `harness/adversary`, `harness/tie-breaker` | Bridged or `human_required` in output |
+| Role | `ask_user` |
+|------|------------|
+| Parent orchestrator | Yes (plan clarification, `approve_plan`, router tune) |
+| `harness/planning/*` | No — JSON only (`human_required` in output if stuck) |
+| `harness/evaluator`, `harness/adversary`, `harness/tie-breaker` | `human_required` in subprocess JSON |
 | `harness/executor` | No — parent handles governance |
 
 ## Spawn pattern (`/harness-plan`)
 
+```json
+{
+  "agentScope": "both",
+  "tasks": [
+    { "agent": "harness/planning/scout-graphify", "task": "…" },
+    { "agent": "harness/planning/scout-structure", "task": "…" },
+    { "agent": "harness/planning/scout-semantic", "task": "…" }
+  ]
+}
 ```
-Agent({ subagent_type: "harness/planning/scout-graphify", prompt: "…", run_in_background: true })
-Agent({ subagent_type: "harness/planning/scout-structure", prompt: "…", run_in_background: true })
-get_subagent_result  # scouts
-Agent({ subagent_type: "harness/planning/decompose", prompt: "…" })
-Agent({ subagent_type: "harness/planning/hypothesis", prompt: "…" })
-# parent: PlanPacket, ask_user on fork
-Agent({ subagent_type: "harness/planning/plan-adversary", run_in_background: true })
-Agent({ subagent_type: "harness/planning/hypothesis-eval", run_in_background: true })
-approve_plan({ plan_packet, research_brief }); create_plan
-```
+
+Then parallel decompose + hypothesis, parent PlanPacket + `ask_user`, debate rounds via `subagent` or `debate-orchestrator`, then `approve_plan` + `create_plan`.
+
+Scouts use **Haiku**, `thinking: low`, **8** max turns (see agent frontmatter). Effective `--tools` omits `grep`/`find`/`subagent` per `disallowed_tools`.
 
 ## Tools
 
-- `Agent`, `get_subagent_result`, `steer_subagent`
+- `subagent` — harness subprocess spawns (modes: `single`, `tasks`, `chain`, `aggregator`)
 - `approve_plan`, `create_plan` — parent orchestrator only
-- `blackboard` — parent only
-- Subagents cannot nest spawns
+- Subprocess agents cannot nest `subagent` (`subagent` stripped from child `--tools`)
 
 ## References
 

package/.agents/skills/harness-plan/SKILL.md

@@ -1,37 +1,32 @@
 ---
 name: harness-plan
-description: Produce PlanPacket-aligned harness plans via decomposition + DARWIN hypothesis before execute phase. Use with /harness-plan, harness-auto plan phase, or when policy-gate requires an approved plan.
+description: PM-grade harness plans — scouts, ExecutionPlan, DAG validation, 4-round Review Gate debate, then approve/create_plan.
 ---
 
 # harness-plan
 
 ## When to use
 
-- User invokes `/harness-plan` or harness-auto planning phase
-- Policy gate blocks mutate tools without approved plan
-- Drift monitor requests replan (`harness-drift-replan`)
-- User replies with clarification after `needs_clarification`
+- `/harness-plan`, harness-auto plan phase, drift replan, policy-gate without approved plan
 
 ## Workflow (parent orchestrator)
 
-1. Use `HarnessSpawnContext` from injected `[HarnessRunContext]` — do not read spec files from disk.
-2. Spawn planning scouts in parallel (`run_in_background: true`, `inherit_context: false`):
-   - `harness/planning/scout-graphify` (required)
-   - `harness/planning/scout-structure` (required)
-   - `harness/planning/scout-semantic` (skip when `--quick`)
-3. `get_subagent_result` for each; parse scout JSON.
-4. Spawn `harness/planning/decompose` with merged scout JSON → `PlanDecompositionBrief`.
-5. Spawn `harness/planning/hypothesis` with decomposition + scouts → `PlanHypothesisBrief`.
-6. Parent synthesizes draft `PlanPacket` from hypothesis; `ask_user` when dialectical fork is material.
-7. Parallel: `harness/planning/plan-adversary` + `harness/planning/hypothesis-eval` (eval gets task + hypothesis only).
-8. Parent calls `approve_plan({ plan_packet, human_summary, research_brief })` then `create_plan`.
+1. Parallel scouts (graphify + structure; semantic unless `--quick`).
+2. Parallel decompose + hypothesis → write `artifacts/*.yaml`.
+3. Draft `PlanPacket` (`contract_version: "1.1.0"`) + `ask_user` on material fork.
+4. `stack-researcher` → `execution-plan-author` → merge `execution_plan`.
+5. **`validate-plan-dag.mjs`** on `plan-packet.yaml` (must pass).
+6. **Review Gate:** `/harness-debate-open plan-<run_id>` → 4 rounds (see **harness-debate-plan** skill) → consensus.
+7. Apply patches, re-validate DAG, `approve_plan`, `create_plan`.
+
+`--quick` skips semantic scout and post-run adversary only — **not** plan debate.
 
 ## Rules
 
-- Planning subagents are read-only; they never call `ask_user`, `approve_plan`, or `create_plan`.
-- Do not spawn `harness/planner` or `harness/planning/planner` (deprecated).
-- context-mode only on harness paths; never lean-ctx.
+- On-disk plan artifacts are **YAML** (`plan-packet.yaml`, `research-brief.yaml`).
+- Subagents read-only; parent writes run artifacts and calls `approve_plan` / `create_plan`.
+- context-mode only on harness paths.
 
 ## Output
 
-- `plan_status`, `risk_level`, `plan_review_path`, `next_command`: `/harness-run` when ready
+`plan_status`, `plan_review_path`, `next_command: /harness-run` when ready.

package/.pi/PACKAGING.md

@@ -24,6 +24,7 @@ We use an explicit allowlist (not the whole `.pi/` tree) so dev-only artifacts n
 - Ship `.pi/settings.example.json`, not `.pi/settings.json` (dev checkout uses `".."` local package)
 - Include **`vendor/pi-model-router/`** ([`pi-model-router`](https://github.com/yeliu84/pi-model-router), MIT) — see repo [`THIRD_PARTY_NOTICES.md`](../THIRD_PARTY_NOTICES.md); refresh with `npm run vendor:sync-router`
 - Include **`vendor/pi-vcc/`** ([`pi-vcc`](https://github.com/sting8k/pi-vcc), MIT; inspired by [lllyasviel/VCC](https://github.com/lllyasviel/VCC)) — loaded via `.pi/extensions/ultimate-pi-vcc.ts`; refresh with `npm run vendor:sync-vcc`
+- Include **`vendor/pi-subagents/`** (vendored from [narumiruna/pi-extensions](https://github.com/narumiruna/pi-extensions) `pi-subagents`) — loaded via `.pi/extensions/harness-subagents.ts`; refresh with `npm run vendor:sync-subagents`
 
 ## Settings
 

package/.pi/SYSTEM.md

@@ -81,41 +81,42 @@ edges at build time. Use these to answer call-graph questions without external t
 - **How does `Auth` reach `Database`?** → `graphify path "Auth" "Database"` (shortest call chain)
 - **Trace a dependency chain deep** → `graphify query "how does X depend on Y" --dfs`
 
-**Semantic code search via graphify:**
-Graphify already indexes the entire codebase as a knowledge graph. Use graphify
-for conceptual code search before falling back to `ck`:
-- **Find code by meaning** → `graphify query "where is authentication logic"`
-- **Find related concepts** → `graphify query "what connects to error handling"`
+**Semantic code search (two lanes):**
+- **Architecture / relationships** → graphify (`query`, `explain`, `path`, `GRAPH_REPORT.md`)
+- **Implementation by meaning** → CocoIndex Code (`ccc search --limit N "concept"`)
+
+Examples:
+- **Find code by meaning** → `ccc search --limit 10 "authentication session validation"`
+- **Who calls X / cross-module path** → `graphify explain "X"` or `graphify path "A" "B"`
 - **Cross-file surprises** → `graphify query "what unexpected connections exist"`
 
 **Order of operations for codebase exploration:**
 1. Read `graphify-out/GRAPH_REPORT.md` (god nodes, surprises, suggested questions)
-2. Run `graphify query` for domain-specific questions, call traces, and semantic search
-3. Use `graphify explain "Concept"` for caller/callee/dependency deep dives
-4. Use `sg -p 'pattern'` for structural code search, then `ck --hybrid` only if graph and ast-grep don't surface it
-5. Read individual files last — the graph already told you what matters
+2. Run `graphify query` / `explain` / `path` for architecture and call graphs
+3. Use `sg -p 'pattern'` for structural code search
+4. Use `ccc search --limit N` for conceptual implementation chunks when graphify/sg are insufficient
+5. Read individual files last — scouts and graph already narrowed the set
+
+**Indexing:** Harness runs incremental `ccc index` before subagent spawns. Use `ccc search` only in agents; run `ccc index` at session start or after large edits on parent turns. Never use `ccc search --refresh` in scouts. `/skill:ccc` for full CLI reference.
 
 ### Fallback Search (when graph doesn't cover it)
 
-> [!note] Graphify handles semantic search and call graphs
-> Graphify already provides semantic code search and call-graph tracing. Use
-> `graphify query`, `graphify explain`, and `graphify path` as your primary
-> code exploration tools. Only fall back to `sg`/`ck`/`find` when the graph
-> doesn't have the answer (e.g., not yet indexed, or you need exact raw text).
+> [!note] Graphify + ccc split responsibilities
+> Graphify owns call graphs and cross-module relationships. `ccc` owns AST-aware
+> semantic chunks. Only fall back to `find`/`grep` for exact literals or non-code files.
 
 | Tool | When | Command |
 |------|------|---------|
-| `sg -p` | **Primary code search** — AST-aware structural pattern matching | `sg -p 'pattern' --lang typescript` |
+| `sg -p` | **Structural code search** — AST pattern matching | `sg -p 'pattern' --lang typescript` |
 | `sg scan` | Rule-based code scanning (use project rules in `sgconfig.yml`) | `sg scan` |
-| `ck --hybrid` | Lexical + semantic fusion search (fallback after ast-grep) | `ck --hybrid "query" .` |
-| `ck --sem` | Purely conceptual searches (fallback after ast-grep) | `ck --sem "concept" src/` |
+| `ccc search` | **Semantic chunks** — implementation by meaning | `ccc search --limit 10 "query"` |
 | `find` | File discovery by name/glob only | `find . -name "*.ts"` |
 | `grep` | **Last resort** — exact literal string matching in non-code files only | `grep -F "exact string"` |
 
-- **Always prefer ast-grep (`sg`) over grep for code search.** ast-grep understands code structure via tree-sitter — it matches patterns, not strings. Use it for: finding function calls, class definitions, import statements, variable usage, and any structural code query.
+- **Always prefer ast-grep (`sg`) over grep for code search.** ast-grep understands code structure via tree-sitter — it matches patterns, not strings.
 - Never use grep for code search. grep is only for: log files, non-code text files, exact byte-level matching when AST patterns can't work.
-- Always use `--limit N` on ck to cap output and save context.
-- Graphify is primary. ast-grep is secondary. ck/find are fallbacks. grep is last resort.
+- Always use `--limit N` on `ccc search` to cap output and save context.
+- Graphify is primary for architecture. ast-grep is secondary for structure. ccc is semantic implementation search. grep is last resort.
 - Do NOT install or use grepai/seagoat/mgrep for call-graph traces or semantic
   search — graphify already handles both.
 

package/.pi/agents/harness/adversary.md

@@ -5,7 +5,6 @@ extensions: false
 disallowed_tools: ask_user
 thinking: high
 max_turns: 20
-inherit_context: false
 ---
 
 You are the Harness Adversary.

package/.pi/agents/harness/evaluator.md

@@ -5,7 +5,6 @@ extensions: false
 disallowed_tools: ask_user
 thinking: high
 max_turns: 20
-inherit_context: false
 ---
 
 You are the Harness Evaluator.

package/.pi/agents/harness/executor.md

@@ -4,8 +4,7 @@ tools: read, write, edit, bash, grep, find, ls
 extensions: true
 disallowed_tools: ask_user
 thinking: medium
-max_turns: 30
-inherit_context: false
+max_turns: 20
 ---
 
 You are the Harness Executor.

package/.pi/agents/harness/incident-recorder.md

@@ -4,7 +4,6 @@ tools: read, grep, find, ls
 extensions: false
 thinking: medium
 max_turns: 15
-inherit_context: false
 ---
 
 You are the Harness Incident Recorder.

package/.pi/agents/harness/meta-optimizer.md

@@ -5,7 +5,6 @@ extensions: false
 disallowed_tools: ask_user
 thinking: high
 max_turns: 25
-inherit_context: false
 ---
 
 You are the Harness Meta Optimizer.

package/.pi/agents/harness/planning/decompose.md

@@ -1,11 +1,10 @@
 ---
 description: Plan-phase DeepMind-style problem decomposition (read-only).
 tools: read, grep, find, ls, bash
-disallowed_tools: write, edit, ask_user, approve_plan, create_plan, Agent
+disallowed_tools: write, edit, ask_user, approve_plan, create_plan, subagent
 extensions: false
-thinking: high
-max_turns: 18
-inherit_context: false
+thinking: medium
+max_turns: 12
 ---
 
 You are the **Harness planning decomposer (Phase 1)**.

package/.pi/agents/harness/planning/execution-plan-author.md

@@ -0,0 +1,30 @@
+---
+description: Plan-phase ExecutionPlan generator (PM-grade WBS + DAG).
+tools: read, grep, find, ls
+disallowed_tools: write, edit, bash, ask_user, approve_plan, create_plan, subagent
+extensions: false
+thinking: high
+max_turns: 16
+---
+
+You are **execution-plan-author** — produce a complete `execution_plan` a senior EM would sign off.
+
+## Inputs
+
+Task, `PlanDecompositionBrief`, `PlanHypothesisBrief`, draft scope/acceptance_checks, `PlanStackBrief`, scout summaries.
+
+## Workflow
+
+1. Vision check — scope ≤15 lines, testable outcomes.
+2. Phases with objective, entry/exit criteria, milestone, work_item_ids.
+3. WBS — every AC maps to ≥1 work_item; deliverable-sized items.
+4. `depends_on` DAG; `parallel_safe` only when files disjoint.
+5. `schedule_metadata.critical_path_work_item_ids`.
+6. `wbs_dictionary`, `risk_register` (≥3 risks for med/high).
+7. `sprint_contract` complete.
+8. Early-phase verify/lint/test work items when risk ≥ med.
+9. Typed `done_criteria` per work item.
+
+## Output
+
+Valid **YAML only** — `PlanExecutionPlanBrief` with `execution_plan` (`.pi/harness/specs/plan-execution-plan-brief.schema.json`). Parent merges into `plan-packet.yaml`.

package/.pi/agents/harness/planning/hypothesis-validator.md

@@ -0,0 +1,23 @@
+---
+description: Plan-phase blind hypothesis validation (debate R1 only).
+tools: read, grep, find, ls
+disallowed_tools: write, edit, bash, ask_user, approve_plan, create_plan, subagent
+extensions: false
+thinking: medium
+max_turns: 10
+---
+
+You are **hypothesis-validator** — blind self-evaluation of `PlanHypothesisBrief` only.
+
+## Input (strict)
+
+- Original task statement
+- `PlanHypothesisBrief` YAML/JSON
+
+Ignore decomposition, scouts, PlanPacket, adversary output.
+
+## Output
+
+Valid **YAML only** matching `PlanHypothesisEval` (`.pi/harness/specs/plan-hypothesis-eval.schema.json`). Parent writes `artifacts/hypothesis-validation-r{N}.yaml`.
+
+Bus label: `HypothesisValidatorsubagent`.

package/.pi/agents/harness/planning/hypothesis.md

@@ -1,11 +1,10 @@
 ---
 description: Plan-phase DARWIN hypothesis generation (read-only).
 tools: read, grep, find, ls, bash
-disallowed_tools: write, edit, ask_user, approve_plan, create_plan, Agent
+disallowed_tools: write, edit, ask_user, approve_plan, create_plan, subagent
 extensions: false
-thinking: high
-max_turns: 20
-inherit_context: false
+thinking: medium
+max_turns: 14
 ---
 
 You are the **Harness planning hypothesis generator (Phase 2 — DARWIN)**.