ultimate-pi 0.20.0 → 0.22.1

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

@@ -8,7 +8,7 @@ description: Compile task-specific harness context using context-mode and graphi
 ## When to use
 
 - Preparing context for `/harness-plan`, `/harness-run`, or `/harness-auto`
-- Navigating harness-related code and ADRs without reading entire repos
+- Navigating harness-related code and governance decisions without reading entire repos
 
 ## Mandatory: context-mode only
 
@@ -25,7 +25,7 @@ Use these in rough priority order — not every tool on every task:
 | Structural code patterns | `sg -p '…'` (ast-grep) |
 | Semantic implementation search | `ccc search` (harness pre-indexes before subprocess spawns) |
 | File detail | context-mode maps/signatures, then targeted reads |
-| Harness governance | `.pi/harness/docs/adrs/README.md` |
+| Harness governance | approved policies and decision logs in the target project |
 
 For `/harness-plan` Phase 1, parent compiles findings into `artifacts/planning-context.yaml` — see **harness-plan** skill.
 
@@ -33,7 +33,7 @@ For `/harness-plan` Phase 1, parent compiles findings into `artifacts/planning-c
 
 Compact context block:
 
-- Relevant ADRs (ids + one-line decision)
+- Relevant governance decisions (id/title + one-line decision)
 - Extension entry points (policy-gate, trace-recorder, harness-telemetry)
 - Schema versions in play
 

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

@@ -5,7 +5,7 @@ description: Plan-phase Review Gate debate — pi-messenger threads, lane YAML,
 
 # harness-debate-plan
 
-**Practice map:** `.pi/harness/docs/practice-map.md` (Review Gate RACI).
+Review Gate RACI: parent is chair; lane agents provide structured evidence in sequence.
 
 Use when running **Phase 5** of `/harness-plan` — **Fagan-style structured inspection** per focus (`spec` | `wbs` | `schedule` | `quality`). Parent is **chair**; within-round dialogue (claims → rebuttals → clarifications → counters → integrate).
 
@@ -78,4 +78,4 @@ Resume: `harness_debate_round_status({ round_index: N })` → run listed `next_t
 
 Do not `approve_plan` on `policy_decision: block`. On `human_required` → `ask_user` first.
 
-Rubrics: `.pi/harness/docs/planning-rubrics.md`.
+Rubrics: use the focus-specific checklist ids passed by the parent for the active round.

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

@@ -54,7 +54,73 @@ Parent orchestrator calls **`approve_plan`** with the full `plan_packet` (scroll
 }
 ```
 
-## Example (plan — scope)
+## Phase 0 — task contract (before reconnaissance)
+
+Use during **`/harness-plan` Phase 0** only. Purpose: disambiguate the **task** (scope, success, risk) — not research-backed implementation forks (those are Phase 4 after Phase 3.5).
+
+### Example (Phase 0 — success criteria)
+
+```json
+{
+  "question": "What does done look like for this task?",
+  "context": "The request could mean harness-only changes, product code, or docs. Phase 0 must lock acceptance before reconnaissance.",
+  "options": [
+    { "title": "Harness contract only", "description": "Changes under .pi/harness and prompts; harness-verify passes" },
+    { "title": "End-to-end feature", "description": "User-visible behavior + tests in the app repo" },
+    { "title": "Docs / decision-record only", "description": "No runtime code changes" }
+  ],
+  "allowFreeform": true
+}
+```
+
+### Example (Phase 0 — risk when `--risk` omitted)
+
+```json
+{
+  "question": "What risk level should tailor debate and research depth?",
+  "options": [
+    { "title": "Low", "description": "Small, localized change; fast plan-verify profile" },
+    { "title": "Med (default)", "description": "Typical feature or multi-file harness work" },
+    { "title": "High", "description": "Architecture, security, or broad blast radius" }
+  ],
+  "allowFreeform": false
+}
+```
+
+### Example (Phase 0 — questionnaire: scope + success in one call)
+
+Use **`questions[]`** when ≥2 independent dimensions must be resolved together. One tool call per clarification round (not one sub-question per round). After the user answers, merge into `artifacts/task-clarification.yaml` — do not hand-edit YAML for structured fields.
+
+```json
+{
+  "question": "Lock the task contract before reconnaissance",
+  "context": "Phase 0 task-clarification gate. Answer both forks to set scope and acceptance.",
+  "questions": [
+    {
+      "title": "Scope surface",
+      "options": [
+        { "title": "Harness only", "description": ".pi/harness, prompts, verify" },
+        { "title": "Product code", "description": "App/runtime changes + tests" }
+      ]
+    },
+    {
+      "title": "Done means",
+      "options": [
+        { "title": "Tests green", "description": "CI + harness-verify pass" },
+        { "title": "Docs shipped", "description": "User-facing docs updated" }
+      ],
+      "allowMultiple": true
+    }
+  ],
+  "allowComment": true
+}
+```
+
+Parent: map the tool result with `applyAskUserToTaskClarification` (see `.pi/lib/ask-user/merge-task-clarification.ts`) before `write_harness_yaml`.
+
+**Rich UI:** `HARNESS_ASK_USER_UI=auto` tries Glimpse when available; WSL without a display falls back to TUI (`ui_degraded` in tool details). Use `displayMode: "inline"` only for transcript-inline prompts (e.g. under a plan block).
+
+## Example (plan — scope) — Phase 4 fork, not Phase 0
 
 ```json
 {
@@ -69,6 +135,6 @@ 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.
+- **Parent orchestrator** during `/harness-plan` — Phase 0: `ask_user` for **task contract** → `artifacts/task-clarification.yaml`; later: **`approve_plan`** then **`create_plan`** for the plan file; Phase 4: `ask_user` for **dialectical forks** only.
 - `harness/planning/*` (scouts, decompose, hypothesis, hypothesis-eval) — JSON only; no `ask_user` / `approve_plan` / `create_plan`.
 - `harness/reviewing/evaluator`, `harness/reviewing/adversary`, and `harness/reviewing/tie-breaker` — emit `human_required`; the **parent orchestrator** calls `ask_user`.

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

@@ -9,4 +9,4 @@ description: >-
 
 Use **`harness-review`** skill and **`/harness-review`** instead.
 
-The master command runs benchmark + policy verdict (+ adversary unless `--quick`) with `submit_eval_verdict` / `submit_adversary_report` and parent `harness_artifact_ready` gates (ADR 0037, ADR 0039).
+The master command runs benchmark + policy verdict (+ adversary unless `--quick`) with `submit_eval_verdict` / `submit_adversary_report` and parent `harness_artifact_ready` gates.

package/.agents/skills/harness-git-commit/SKILL.md

@@ -0,0 +1,72 @@
+---
+name: harness-git-commit
+description: Commit staged git changes with configurable message format and Co-authored-by trailer from .pi/auto-commit.json. Use when the user asks to commit, when /harness-auto or harness run completion requires a commit, or before any git commit — never use raw git commit -m.
+---
+
+# harness-git-commit
+
+Deterministic commits via bundled CLI. Config merges **project** `.pi/auto-commit.json` over **package** defaults (`$UP_PKG/.pi/auto-commit.json`). Project `coAuthor` fully replaces the package default after merge.
+
+## When to use
+
+- User explicitly asks to create a git commit
+- Harness pipeline step says commit after review pass
+- You are about to run `git commit`, `git commit -m`, or `git commit --amend`
+
+## Forbidden
+
+- **Do not** run raw `git commit` / `git commit -m` / `git commit --amend` in shell
+- **Do not** hardcode `Co-authored-by:` lines in shell or HEREDOC — use this skill's CLI instead of HEREDOC `git commit` when committing harness work
+- **Do not** `git push` unless the user asked
+- **Do not** commit unless the user asked (or harness-auto locked gate explicitly requires it)
+
+## Workflow
+
+1. Resolve `UP_PKG` — see [`$UP_PKG/.pi/scripts/README.md`](../../.pi/scripts/README.md) (`harness-resolve-up-pkg.mjs`).
+2. From **project root** (repo that owns `.pi/auto-commit.json`, not a submodule):
+   ```bash
+   node "$UP_PKG/.pi/scripts/harness-auto-commit-bootstrap.mjs"
+   ```
+3. Stage files: `git add …` (CLI does not stage).
+4. Commit via CLI (examples):
+   ```bash
+   # Conventional subject from config template
+   node "$UP_PKG/.pi/scripts/harness-git-commit.mjs" \
+     --type fix --scope my-app --subject "short description"
+
+   # Full message override (--message wins over --subject)
+   node "$UP_PKG/.pi/scripts/harness-git-commit.mjs" \
+     --message "chore(release): bump version" --body "- detail lines"
+
+   # Amend: preserve body, ensure trailer
+   node "$UP_PKG/.pi/scripts/harness-git-commit.mjs" --amend --message "$(git log -1 --format=%B)"
+
+   # Preview only
+   node "$UP_PKG/.pi/scripts/harness-git-commit.mjs" --dry-run --subject "preview"
+   ```
+
+## Config (project `.pi/auto-commit.json`)
+
+| Field | Purpose |
+|-------|---------|
+| `message.template` | `{type}({scope}): {subject}` when scope set |
+| `message.templateNoScope` | `{type}: {subject}` when scope empty |
+| `message.typeDefault` / `scopeDefault` | Defaults for omitted CLI flags |
+| `message.coAuthorTrailer` | `Co-authored-by: {login} <{email}>` |
+| `coAuthor.login` / `coAuthor.email` | Attribution (project overrides package) |
+| `coAuthor.required` | When false, skip trailer (default true) |
+
+Edit project file to change format or co-author for external repos.
+
+## Limitations
+
+- Skill + CLI only — humans or bypassing agents can still run raw `git commit`
+- Submodule/nested repos: commit from the root that owns `.pi/auto-commit.json`
+- Squash/rebase on GitHub may drop co-author trailers — not fixable here
+- Signed commits: pass `--signoff` on CLI if needed; GPG `-S` is caller responsibility
+
+## References
+
+- Auto-commit lifecycle policy: use bootstrap + commit CLI so co-author and message format stay consistent.
+- Scripts — `harness-git-commit.mjs`, `harness-auto-commit-bootstrap.mjs`
+- Library — `.pi/lib/harness-auto-commit-config.mjs`

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

@@ -14,11 +14,11 @@ description: Enforce harness governance phases, policy gates, budgets, and promo
 ## Workflow
 
 1. Read current phase from `/harness-policy-status` or session `harness-policy-state`.
-2. Check ADRs: constitution (0001), eval promotion (0003), Sentrux (0006), drift (0007), rules lifecycle (0009), AGT policy (0046), AGT security layers (0047).
+2. Check governance policies: phase constitution, eval promotion rules, Sentrux requirements, drift handling, rules lifecycle, and AGT policy/security layers.
 3. Tool allow/deny is enforced by AGT `PolicyEngine` + `.pi/harness/policies/*.yaml` (parent `policy-gate`, subprocess `harness-subagent-governance`). Disable with `HARNESS_AGT_POLICY=0`. Audit: `.pi/harness/runs/<run_id>/agt-audit.jsonl`.
 4. For promotion: require eval pass, no abort lock, debate consensus if escalated, Sentrux when `HARNESS_SENTRUX_REQUIRED=true` (`artifacts/sentrux-signal.yaml` from `/harness-run`, not executor self-report).
-5. **Intent vs observation:** Manifest/layer/boundary changes → `/harness-sentrux-steward` proposal + chair approval + ADR when material, then `sentrux-rules-sync --force`. `sentrux check`/`gate` degradation after execute → replan or fix code — do not tune manifest on a single noisy gate.
-6. After approved manifest edits: `node "$UP_PKG/.pi/scripts/harness-sentrux-bootstrap.mjs" --force` or `/harness-sentrux-sync`; emit `harness-architecture-changed` for the extension.
+5. **Intent vs observation:** Sentrux manifest changes → `/harness-sentrux-steward` + chair + formal decision record when material, then `sentrux-rules-sync --force`. Naming manifest changes → `/harness-ls-lint-steward` + chair, then `ls-lint-rules-sync --force`. CLI degradation after execute → fix paths or replan — do not tune manifest on a single noisy run.
+6. After approved Sentrux edits: `harness-sentrux-bootstrap.mjs --force` or `/harness-sentrux-sync`; emit `harness-architecture-changed`. After naming edits: `harness-ls-lint-bootstrap.mjs --force` or `/harness-ls-lint-sync`; emit `harness-naming-changed`.
 7. Run `node "$UP_PKG/.pi/scripts/harness-verify.mjs"` before claiming release readiness (includes AGT policy doctor).
 
 ## Spec Distiller integration
@@ -30,13 +30,13 @@ When refining plans from noisy requirements:
 3. When gates return `human_required` or promotion is blocked, the orchestrator calls `ask_user` — do not guess scope.
 4. Reference graphify wiki or `graphify query` for architecture constraints before execute.
 
-## Budgets (ADR 0038)
+## Budgets
 
 - Default: **`HARNESS_BUDGET_ENFORCE` off** — token/debate caps are telemetry-only (`harness-budget-telemetry`, `harness-budget-soft-limit`). They do **not** block phases or debate lanes.
 - Do **not** skip reconnaissance artifacts (`planning-context.yaml`), debate rounds, or `approve_plan` because of soft budget hints in the widget.
 - Re-enable hard caps only with `HARNESS_BUDGET_ENFORCE=1` and `HARNESS_BUDGET_HARD_STOP` / `HARNESS_DEBATE_HARD_STOP`.
 
-## Subagent artifacts (ADR 0037)
+## Subagent artifacts
 
 - Subagents call scoped **`submit_*`** tools; parent verifies with **`harness_artifact_ready`**, not JSON parsing from `finalOutput`.
 - Parent **`write_harness_yaml`** is for merges (`research-brief.yaml`, plan shell) — not subagent payloads.
@@ -44,4 +44,4 @@ When refining plans from noisy requirements:
 ## Rules
 
 - Never auto-merge; harness-auto may open PR only when all gates pass (see release-readiness-report).
-- Do not invoke posthog-analyst in Phase 2 (ADR 0005).
+- Do not invoke posthog-analyst in Phase 2.

package/.agents/skills/harness-ls-lint-setup/SKILL.md

@@ -0,0 +1,59 @@
+---
+name: harness-ls-lint-setup
+description: Bootstrap ls-lint filename rules for harness projects — seed naming.manifest.json, generate merge-safe .ls-lint.yml, and document bootstrap vs --force sync. Use during /harness-setup, when adding ls-lint to a repo, or when .ls-lint.yml is missing or out of date.
+---
+
+# harness-ls-lint-setup
+
+## When to use
+
+- `/harness-setup` Step 4.3 (ls-lint naming bootstrap)
+- Target repo has no `.ls-lint.yml` or `harness-verify` reports naming config drift
+- User edited `.pi/harness/ls-lint/naming.manifest.json` (`global_rules`, `scoped_rules`, `ignores`)
+
+## Roles (do not conflate)
+
+| Role | Agent / command | Layer |
+|------|-----------------|-------|
+| **Bootstrap** | `harness-ls-lint-bootstrap.mjs` | Greenfield seed + first sync |
+| **Steward** | `harness/ls-lint-steward`, `/harness-ls-lint-steward` | Proposes manifest changes (`artifacts/ls-lint-manifest-proposal.yaml`); chair applies |
+| **Sync** | `ls-lint-rules-sync.mjs`, `/harness-ls-lint-sync` | Regenerates `.ls-lint.yml` from manifest after intent change |
+| **Observation** | `/harness-run`, `/harness-review` | `harness-ls-lint-cli.mjs` → `artifacts/ls-lint-signal.yaml` |
+
+Never auto-sync manifest from directory trees. Material manifest edits need steward evidence + chair approval.
+
+## Canonical layout
+
+| Path | Role |
+|------|------|
+| `.pi/harness/ls-lint/naming.manifest.json` | Source of truth |
+| `.ls-lint.yml` | Generated ls-lint config (commit to git) |
+| `.ls-lint/.harness-naming-meta.json` | Sync metadata (gitignored) |
+
+Custom YAML **outside** `# --- harness:managed:start/end ---` is preserved on every sync.
+
+## Commands (resolve `UP_PKG` via `.pi/scripts/README.md`)
+
+| Situation | Command |
+|-----------|---------|
+| First-time / harness-setup (idempotent) | `node "$UP_PKG/.pi/scripts/harness-ls-lint-bootstrap.mjs"` |
+| After manifest edits | `node "$UP_PKG/.pi/scripts/harness-ls-lint-bootstrap.mjs" --force` |
+| CI / verify only | `node "$UP_PKG/.pi/scripts/ls-lint-rules-sync.mjs" --check` |
+| Run/review observation | `node "$UP_PKG/.pi/scripts/harness-ls-lint-cli.mjs"` or `--json` |
+| In pi session | `/harness-ls-lint-sync` (extension; uses `--force`) |
+
+## Workflow
+
+1. Ensure ls-lint CLI is installed (`harness-setup` Step 2.9 or `harness-cli-verify.sh`).
+2. Run bootstrap from **project root**:
+   ```bash
+   node "$UP_PKG/.pi/scripts/harness-ls-lint-bootstrap.mjs"
+   ```
+3. `node "$UP_PKG/.pi/scripts/harness-ls-lint-cli.mjs"` — fix violations or tune manifest rules/ignores.
+4. Commit `.ls-lint.yml` and project-specific `naming.manifest.json`.
+
+## References
+
+- Naming lifecycle policy: steward proposal + chair approval before material manifest changes.
+- Scripts — `ls-lint-rules-sync.mjs`, `harness-ls-lint-bootstrap.mjs`, `harness-ls-lint-cli.mjs`
+- Agent — `harness/ls-lint-steward`

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

@@ -8,14 +8,14 @@ description: >-
 
 # Harness orchestration
 
-**Practice map:** `.pi/harness/docs/practice-map.md` · **ADR 0040** · **ADR 0041**.
+Follow the orchestration rules and phase sequence in this skill directly.
 
 ## Team management rules
 
 1. **Parallelism law** — Parallel `tasks` only when outputs are independent inputs to a later merge (implementation ∥ stack). Never parallelize debate lanes or decompose ∥ hypothesis.
 2. **Two-pizza cap per batch** — Max 2 research lanes, 1 optional `planning-context` subagent, 1 executor, 1 debate agent per `subagent` call.
 3. **No redundant thinkers** — Downstream agents read artifacts; do not re-derive.
-4. **Sequential dependency chain** — planning context → decompose → hypothesis → research → author → DAG → debate → approve → execute → **/harness-review** → optional **/harness-steer** loop (ADR 0044).
+4. **Sequential dependency chain** — planning context → decompose → hypothesis → research → author → DAG → debate → approve → execute → **/harness-review** → optional **/harness-steer** loop.
 5. **Path-first parent tools** — `approve_plan`, `create_plan`, `submit_*` via `source_path`, `merge_harness_yaml`, `harness_synthesize_repair_brief`.
 6. **Debate = meeting** — Parent is chair; parallel_probes allows evaluator ∥ adversary per batch.
 7. **Tool intelligence** — Parent uses graphify, sg, ccc, and reads by task need; subprocesses optional.
@@ -41,7 +41,7 @@ Harness subprocesses load **`harness-subagent-submit`** (`PI_HARNESS_SUBPROCESS=
 |---------|---------|
 | `/harness-plan` | Parent: planning context (tools) → decompose → hypothesis → Phase 3.5 artifacts → PlanPacket → eligibility + Review Gate → `approve_plan` + `create_plan` |
 | `/harness-run` | `harness/running/executor` (single worker) |
-| `/harness-review` | Parent verify → `evaluator` benchmark → `evaluator` verdict → `adversary` → optional `tie-breaker` (ADR 0039) |
+| `/harness-review` | Parent verify → `evaluator` benchmark → `evaluator` verdict → `adversary` → optional `tie-breaker` |
 | `/harness-eval` | **Deprecated** → `/harness-review` |
 | `/harness-critic` | **Deprecated** → `/harness-review` |
 | `/harness-auto` | plan per `/harness-plan`; `--quick` skips adversary + tie-breaker in review |
@@ -80,5 +80,5 @@ Then execution-plan-author, DAG gate, debate eligibility, sequential debate roun
 
 ## References
 
-- ADR 0032, ADR 0033, ADR 0040, ADR 0041, `.pi/harness/specs/harness-spawn-context.schema.json`
+- Subagent isolation, submit-tool artifact flow, and spawn-context contract: `.pi/harness/specs/harness-spawn-context.schema.json`
 - `node "$UP_PKG/.pi/scripts/harness-agents-manifest.mjs" --check`

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

@@ -5,7 +5,7 @@ description: Agent-native harness plans — lakes/context bundles, planning cont
 
 # harness-plan
 
-**Practice map:** `.pi/harness/docs/practice-map.md` · **ADR 0040** · **ADR 0042** · **ADR 0043**.
+Use this skill's phase order, spawn laws, and artifact contract directly.
 
 ## When to use
 
@@ -16,26 +16,28 @@ description: Agent-native harness plans — lakes/context bundles, planning cont
 1. **Parallelism law** — Parallel `tasks` only for independent lanes (implementation ∥ stack ≤2). Never parallelize debate or decompose ∥ hypothesis.
 2. **Two-pizza cap** — Max 1 debate agent, 1 optional planning-context subagent, per `subagent` call.
 3. **No redundant thinkers** — Read upstream YAML; do not re-run graphify in decompose when `planning-context` architecture coverage is ok.
-4. **Sequential chain** — planning context → decompose → hypothesis → research → author → DAG → debate → approve.
+4. **Sequential chain** — task clarification → planning context → decompose → hypothesis → research → author → DAG → debate → approve.
 5. **Tool intelligence** — Parent picks graphify, sg, ccc by task; no mandatory tool-tied scout subprocesses.
 
 ## Workflow (parent orchestrator)
 
-1. **Phase 1:** Compile `artifacts/planning-context.yaml` with tools (default) or optional `planning-context` subagent.
-2. **Sequential** decompose → gate `artifacts/decomposition.yaml`.
-3. **Sequential** hypothesis (requires decomposition).
-4. **Phase 3.5:** `implementation-research.yaml` + `stack.yaml` (parent inline and/or parallel researchers).
-5. Draft `PlanPacket` shell; `ask_user` on material fork **after** Phase 3.5.
-6. `execution-plan-author` → merge `execution_plan`.
-7. **`validate-plan-dag.mjs`** (must pass).
-8. **`harness_plan_debate_eligibility`** — `parallel_probes` spawns plan-evaluator ∥ plan-adversary, then integrator round.
-9. **`approve_plan({ human_summary? })`** / **`create_plan()`** — packet from `plan_packet_path` on disk (path-first).
+1. **Phase 0:** `artifacts/task-clarification.yaml` — investigate (code + web OK), `ask_user` until unambiguous, gate before any planning subagent.
+2. **Phase 1:** Compile `artifacts/planning-context.yaml` with tools (default) or optional `planning-context` subagent; inherit Phase 0 grounding.
+3. **Sequential** decompose → gate `artifacts/decomposition.yaml`.
+4. **Sequential** hypothesis (requires decomposition).
+5. **Phase 3.5:** `implementation-research.yaml` + `stack.yaml` (parent inline and/or parallel researchers).
+6. Draft `PlanPacket` shell; `ask_user` on material fork **after** Phase 3.5 (research-backed; not Phase 0).
+7. `execution-plan-author` → merge `execution_plan`.
+8. **`validate-plan-dag.mjs`** (must pass).
+9. **`harness_plan_debate_eligibility`** — `parallel_probes` spawns plan-evaluator ∥ plan-adversary, then integrator round.
+10. **`approve_plan({ human_summary? })`** / **`create_plan()`** — packet from `plan_packet_path` on disk (path-first).
 
 `--quick` skips semantic coverage in planning context and post-run adversary only — **not** adequate reconnaissance, implementation/stack artifacts (med/high risk), or plan debate.
 
 ## Rules
 
-- On-disk plan artifacts are **YAML** (`plan-packet.yaml`, `research-brief.yaml`, `planning-context.yaml`).
+- On-disk plan artifacts are **YAML** (`task-clarification.yaml`, `plan-packet.yaml`, `research-brief.yaml`, `planning-context.yaml`).
+- Phase 0 allows codebase + web reads; blocks planning subagents and plan artifacts until clarification is `ready`.
 - Subagents read-only; parent writes run artifacts and calls `approve_plan` / `create_plan`.
 - context-mode only on harness paths.
 - Phase 3.5 artifacts required for med/high risk unless documented waiver.

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

@@ -9,7 +9,7 @@ description: >-
 
 # harness-review
 
-**Practice map:** `.pi/harness/docs/practice-map.md` (Monitoring and Controlling: measure → judge → red team).
+Monitoring and Controlling flow: measure → judge → red team.
 
 ## When to use
 
@@ -21,7 +21,7 @@ description: >-
 
 | Phase | Practice | Actor | Artifact |
 |-------|----------|-------|----------|
-| 1 | Automated QC + Sentrux fitness functions | Parent | `harness-verify.mjs`, `harness-sentrux-cli.mjs gate`, `benchmark-log.yaml`, `sentrux-signal.yaml` |
+| 1 | Automated QC + fitness functions | Parent | `harness-verify.mjs`, Sentrux gate, ls-lint CLI, `benchmark-log.yaml`, `sentrux-signal.yaml`, `ls-lint-signal.yaml` |
 | 2 | Measure actuals (EVM) | `harness/reviewing/evaluator` benchmark | `eval-verdict.yaml` |
 | 2b | Controlling | Parent | Write `review-outcome.yaml`; route via `remediation_class` (not fail-fast abort) |
 | 6 | Outcome | Parent | `review-outcome.yaml` → `/harness-steer` or replan |
@@ -42,7 +42,7 @@ Pass `sentrux-signal.yaml` path to evaluator `mode: benchmark` spawn context. Ev
 
 ## Rules
 
-- Parent never writes eval/adversary YAML — subprocess `submit_*` only (ADR 0037).
+- Parent never writes eval/adversary YAML — subprocess `submit_*` only.
 - Auto-claim run ownership unless `--readonly`.
 - Disk verdict drives `next_recommended_command` (`resolveCompletionStatuses`).
 

package/.agents/skills/harness-sentrux-repair/SKILL.md

@@ -0,0 +1,48 @@
+---
+name: harness-sentrux-repair
+description: |
+  OSS Sentrux capture, diagnostics synthesis, and repair-plan loop for harness runs.
+  Use during /harness-run post-work, /harness-review Phase 1/1b, /harness-steer, or when
+  artifacts/sentrux-report.json or sentrux-repair-plan.yaml are mentioned. No Sentrux Pro or MCP.
+---
+
+# harness-sentrux-repair
+
+Structured structural feedback for the harness. **OSS CLI only.**
+
+## Artifacts (per run)
+
+| File | Producer |
+|------|----------|
+| `artifacts/sentrux-report.json` | `harness-sentrux-report.mjs` (single check+gate scan) |
+| `artifacts/sentrux-diagnostics.json` | `harness-sentrux-diagnostics.mjs` |
+| `artifacts/sentrux-signal.yaml` | report script `--signal` (schema 1.1.0) |
+| `artifacts/sentrux-repair-plan.yaml` | `harness/sentrux-repair-advisor` via `submit_sentrux_repair_plan` |
+
+## Commands
+
+```bash
+node "$UP_PKG/.pi/scripts/harness-sentrux-report.mjs" --out "<run_dir>" --run-id "<id>" --signal
+node "$UP_PKG/.pi/scripts/harness-sentrux-diagnostics.mjs" --report "<run_dir>/artifacts/sentrux-report.json" --out "<run_dir>" --churn
+```
+
+Re-run capture only when artifacts are missing or `HARNESS_SENTRUX_RESCAN=1`.
+
+## Phase wiring
+
+- **`/harness-run`** — post-executor capture (replaces separate check+gate + hand-written signal).
+- **`/harness-review`** — Phase 1: reuse or capture; Phase 1b: spawn `harness/sentrux-repair-advisor` when violations/degradation.
+- **`/harness-steer`** — `repair-brief.yaml` merges `[sentrux:…]` directives from repair plan.
+
+## Agent boundaries
+
+| Agent | Role |
+|-------|------|
+| `harness/sentrux-steward` | Manifest intent proposals (`submit_sentrux_manifest_proposal`) |
+| `harness/sentrux-repair-advisor` | Code repair plan only (`submit_sentrux_repair_plan`); no bash |
+
+## Related
+
+- **sentrux** skill — CLI install, rules sync, gate loop
+- **harness-sentrux-setup** — bootstrap manifest/rules
+- **harness-review** / **harness-steer** prompts

package/.agents/skills/harness-sentrux-setup/SKILL.md

@@ -20,7 +20,7 @@ description: Bootstrap Sentrux architectural rules for harness projects — seed
 | **Sync** | `sentrux-rules-sync.mjs`, `/harness-sentrux-sync` | Regenerates `rules.toml` from manifest after intent change |
 | **Observation** | `/harness-run`, `/harness-review` | `harness-sentrux-cli.mjs gate --save` / `check` / `gate` → `artifacts/sentrux-signal.yaml` |
 
-Never auto-sync manifest from directory trees. Material manifest edits need steward evidence + chair approval (ADR 0009).
+Never auto-sync manifest from directory trees. Material manifest edits need steward evidence + chair approval.
 
 ## Canonical layout
 
@@ -63,7 +63,7 @@ Do **not** copy ultimate-pi's layer paths blindly into unrelated layouts — edi
 
 ## References
 
-- ADR 0009 — `.pi/harness/docs/adrs/0009-sentrux-rules-lifecycle.md`
+- Rules lifecycle policy: manifest is source of truth; bootstrap/sync regenerate rules from approved intent.
 - Scripts — `.pi/scripts/sentrux-rules-sync.mjs`, `harness-sentrux-bootstrap.mjs`, `harness-sentrux-cli.mjs`
 - Agents — `harness/sentrux-bootstrap` (setup), `harness/sentrux-steward` (intent proposals)
 - Specs — `sentrux-manifest-proposal.schema.json`, `sentrux-signal.schema.json`

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

@@ -17,7 +17,7 @@ description: Draft or refine harness artifact contracts under .pi/harness/specs.
 2. Edit or add schema under `.pi/harness/specs/`.
 3. Update affected extensions to emit matching custom entries.
 4. Run `node "$UP_PKG/.pi/scripts/harness-verify.mjs"` (see `.pi/scripts/README.md`).
-5. Add or update an ADR under `.pi/harness/docs/adrs/` for breaking changes.
+5. Add or update a formal decision record in the target project's standard decision-log location for breaking changes.
 
 ## Rules
 

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

@@ -1,6 +1,6 @@
 ---
 name: harness-steer
-description: Post-review repair loop via harness-steer and executor repair mode (ADR 0044).
+description: Post-review repair loop via harness-steer and executor repair mode.
 ---
 
 # harness-steer
@@ -11,4 +11,4 @@ Use after `/harness-review` when `artifacts/review-outcome.yaml` has `remediatio
 2. Set policy phase `execute`; spawn `harness/running/executor` with `mode: repair`.
 3. Always follow with `/harness-review`.
 
-See `.pi/prompts/harness-steer.md` and `.pi/harness/docs/adrs/0044-harness-steer-loop.md`.
+See `.pi/prompts/harness-steer.md` for the steer-loop procedure and guardrails.

package/.agents/skills/posthog-analyst/SKILL.md

@@ -264,7 +264,7 @@ status: complete
 | Medium | ... | ... | ... | ... |
 
 ## Next Steps
-[What to do with these findings. Suggest ADR if recommendations are significant.]
+[What to do with these findings. Suggest a formal decision record update if recommendations are significant.]
 ```
 
 After filing, update `vault/wiki/index.md` (add to analyses if category exists, or note inline), update `vault/wiki/log.md` (append entry at TOP), and update `vault/wiki/hot.md` (add key findings to Recent Context).

package/.agents/skills/sentrux/SKILL.md

@@ -42,6 +42,7 @@ Run from the **target repo root** (where `.sentrux/rules.toml` lives), or prefer
 | CI / pre-commit | `node "$UP_PKG/.pi/scripts/harness-sentrux-cli.mjs" check` | Exit 0 = pass, 1 = violations |
 | Before agent work | `node "$UP_PKG/.pi/scripts/harness-sentrux-cli.mjs" gate --save` | Save session baseline |
 | After agent work | `node "$UP_PKG/.pi/scripts/harness-sentrux-cli.mjs" gate` | Detect degradation vs baseline |
+| Harness run/review capture | `harness-sentrux-report.mjs` + `harness-sentrux-diagnostics.mjs` | Single scan → JSON artifacts |
 | Explore structure | `sentrux` or `sentrux .` | GUI treemap (optional) |
 
 Typical agent loop:
@@ -75,9 +76,10 @@ Custom TOML outside `# --- harness:managed:start/end ---` is preserved on sync.
 | `/harness-sentrux-sync` | Force-regenerate rules from manifest (pi command) |
 | `harness-verify.mjs` | Runs rules sync and Sentrux checks when rules are present |
 | **observation-bus** | Maps `harness-sentrux-signal` custom entries → evaluator observations |
-| **harness-eval** | Evaluate phase may require a Sentrux quality signal (stub or future MCP) per ADR 0006 |
+| **harness-sentrux-repair** skill | Report/diagnostics scripts + `sentrux-repair-advisor` + repair plan artifact |
+| **harness-eval** | Evaluate phase may require a Sentrux quality signal before promotion |
 
-High level: **execute** uses CLI gate/check around edits; **evaluate** consumes observation-bus quality signals (`harness-sentrux-signal`) alongside tests and policy. Record CLI outcomes in session notes when no bus entry exists yet.
+High level: **execute** runs one capture (`sentrux-report.json`, `sentrux-diagnostics.json`, signal v1.1.0); **review** may spawn **sentrux-repair-advisor** (Phase 1b); **steer** merges repair plan into `repair-brief.yaml`. No Sentrux Pro or MCP in Pi sessions.
 
 ## Related skills
 
@@ -94,6 +96,6 @@ High level: **execute** uses CLI gate/check around edits; **evaluate** consumes
 
 ## References
 
-- ADR 0006 — `.pi/harness/docs/adrs/0006-sentrux-dual-layer.md`
-- ADR 0009 — `.pi/harness/docs/adrs/0009-sentrux-rules-lifecycle.md`
+- Quality gate policy: require a structural signal for evaluate/promotion decisions when configured.
+- Rules lifecycle policy: manifest is source of truth; sync rules from manifest after approved intent changes.
 - `CONTRIBUTING.md` — Sentrux quick start

package/.agents/skills/web-retrieval/SKILL.md

@@ -160,4 +160,4 @@ Diagnostics: `python3 "$UP_PKG/.pi/scripts/harness-web.py" status` (JSON).
 | `HARNESS_WEB_HEURISTIC_ANGLES_FILE` | — | Extra heuristic angles YAML |
 | `HARNESS_WEB_FAST_MODEL` / `EXPANDER` / `QUALITY` | — | Web subagent models |
 
-See `.pi/harness/docs/harness-web-search.md` for internals.
+Internal implementation notes are package-maintainer-only; this skill already contains the external-facing operating guidance.

package/.agents/skills/wiki-save/SKILL.md

@@ -4,7 +4,7 @@ description: >
   Save the current conversation, answer, or insight into the Obsidian wiki vault as a
   structured note. Analyzes the chat, determines the right note type, creates frontmatter,
   files it in the correct wiki folder, and updates index, log, and hot cache.
-  Triggers on: "save this", "save that answer", "/save", "file this",
+  Triggers on: "save this", "save that answer", "/wiki-save", "/save", "file this",
   "save to wiki", "save this session", "file this conversation", "keep this",
   "save this analysis", "add this to the wiki".
 allowed-tools: Read Write Edit Glob Grep

package/.pi/PACKAGING.md

@@ -10,6 +10,12 @@ Aligned with [pi packages](https://github.com/badlogic/pi-mono/blob/main/package
 | `skills` | `.agents/skills`, `.pi/skills` | Agent Skills + pi-local skills |
 | `prompts` | `.pi/prompts` | Slash-command prompt templates |
 
+### Slash autocomplete
+
+- **Prompt templates** (`.pi/prompts/*.md`): YAML `description` + optional `argument-hint` per [Pi prompt-templates](https://github.com/badlogic/pi-mono/blob/main/packages/coding-agent/docs/prompt-templates.md). Filename → `/command` (e.g. `harness-plan.md` → `/harness-plan`). `release.md` is dev-only and excluded from npm `files`.
+- **Extension commands** (`.pi/extensions/*.ts`): `pi.registerCommand({ description, getArgumentCompletions? })` for dynamic args (run IDs, `--strict`, etc.). Shared helpers: `.pi/lib/harness-slash-completions.ts`.
+- **Contract:** `node "$UP_PKG/.pi/scripts/harness-verify.mjs"` validates shipped prompt frontmatter.
+
 Pi does **not** define `scripts`, `agents`, or `providers` in the manifest.
 
 - **Harness scripts** → `.pi/scripts/` — run via `node` / `bash` and `$UP_PKG` (see `.pi/scripts/README.md`); do not require npm script aliases in consumer `package.json`