wicked-garden 12.32.0 → 12.32.1

package/.claude-plugin/components.json

@@ -2,7 +2,7 @@
   "_comment": "Issue #328: Component declarations for wicked-garden plugin. Claude Code plugin.json does not yet support inline component declarations beyond path overrides. This manifest documents all components for tooling, validation, and future schema support. When plugin.json gains a 'components' field, merge this data into plugin.json. The plugin is skills-only: former commands/ became actions of consolidated per-domain skills, and former agents/ became standalone context:fork worker skills (enumerated under fork_skills). Regenerate derived blocks with scripts/ci/sync_components.py.",
   "domains": ["agentic", "crew", "data", "engineering", "jam", "mem", "persona", "platform", "product", "qe", "search", "smaht"],
   "summary": {
-    "skills": 141,
+    "skills": 142,
     "fork_skills": 78,
     "hooks": 13,
     "specialists": 7
@@ -92,6 +92,7 @@
     "qe-testability-reviewer": ["qe-testability-reviewer"],
     "qe-ui-component-test-engineer": ["qe-ui-component-test-engineer"],
     "qe-visual-regression-engineer": ["qe-visual-regression-engineer"],
+    "repo-learn": ["repo-learn"],
     "runtime-exec": ["runtime-exec"],
     "search": ["codebase-narrator", "search"],
     "smaht": ["discovery", "intent", "propose-skills", "smaht"],

package/.claude-plugin/marketplace.json

@@ -1 +1 @@
-{"name": "wicked-garden", "owner": {"name": "Mike Parcewski"}, "plugins": [{"name": "wicked-garden", "source": "./", "description": "Your coding agent already plans and swarms \u2014 Wicked Garden is the curated toolkit for what it can't: proof-not-claims gates, code links grep can't see, deterministic refactor, cross-session memory, real multi-model second opinions. Don't fight the harness; fill its gaps. The gate needs wicked-vault (a self-contained infra peer, installed directly) and re-derives through garden's built-in engine; estate/bus are opt-in layers (wicked-testing and wicked-brain are retired \u2014 QE ships in-catalog as the qe domain, memory lives in wicked-estate).", "version": "12.32.0"}], "version": "12.32.0"}
+{"name": "wicked-garden", "owner": {"name": "Mike Parcewski"}, "plugins": [{"name": "wicked-garden", "source": "./", "description": "Your coding agent already plans and swarms \u2014 Wicked Garden is the curated toolkit for what it can't: proof-not-claims gates, code links grep can't see, deterministic refactor, cross-session memory, real multi-model second opinions. Don't fight the harness; fill its gaps. The gate needs wicked-vault (a self-contained infra peer, installed directly) and re-derives through garden's built-in engine; estate/bus are opt-in layers (wicked-testing and wicked-brain are retired \u2014 QE ships in-catalog as the qe domain, memory lives in wicked-estate).", "version": "12.32.1"}], "version": "12.32.1"}

package/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "wicked-garden",
-  "version": "12.32.0",
+  "version": "12.32.1",
   "description": "Your coding agent's harness already plans and swarms; Wicked Garden is the curated toolkit for what it can't do alone. Proof, not claims \u2014 gates re-derive 'done' through the internal loom engine (fail-closed, independently attested via wicked-vault), so a self-asserted pass can't lie its way green. Relationships grep can't see \u2014 the wicked-estate code graph + injected bus/dispatch/capability/archetype edges power blast-radius & lineage. Plus deterministic multi-file refactor (wicked-patch), cross-session memory + knowledge (the mem domain over wicked-estate), real multi-model second opinions (jam:council), portable expertise as on-demand skill-refs, and evidence-gated testing (the in-catalog qe domain). It reads the shape of your work to apply the right rigor \u2014 steering, not a pipeline \u2014 then gets out of the way. The compiler stamps a self-contained evidence gate into any repo that runs with no wicked-garden installed. Don't fight the harness; fill its gaps. The evidence gate requires wicked-vault, a self-contained infra peer wicked-garden installs directly; wicked-bus is an opt-in layer \u2014 install what you'll use, the toolkit works without the rest.",
   "wicked_vault_version": "^0.5.0",
   "wicked_ledger_version": "^0.4.0",

package/CHANGELOG.md

@@ -22,6 +22,18 @@
 - **Site: the wicked-interactive card tells the document-engine story** (recon DT-12) — wicked-interactive moved planes rather than retiring: it is the foundation's document engine (storage, version lineage, HTML/PDF/PPTX/video rendering) that wicked-crew spawns and proxies, not a standalone visual builder. Install command unchanged (two-step marketplace add + install).
 - **Backfilled the 12.30.0 and 12.31.0 changelog entries below** (recon DT-17) — the previous release entry was 12.29.1 while npm shipped 12.31.0; the vault-direct-peer entry that sat under [Unreleased] shipped in 12.31.0 and now lives there.
 
+## [12.32.1] — 2026-09-09
+
+### Fixed
+- **Skills: the five dangling `${CLAUDE_PLUGIN_ROOT}` paths and the broken qe evidence-schema link (#1111, fixed in #1113).** wicked-crew's skills publish analyzer (crew#480) resolves every plugin-root and relative reference in the shipped plugin against the would-be snapshot; the five targets parked in `tests/test_skill_dispatch_refs_resolve.py::KNOWN_DANGLING_PATHS` are now fixed at the source and the allowlist is empty (the test fails if any of them dangles again). Imagery `alter`/`create` (+ `alter/refs/editing-reference.md` and the `scripts/{edit,generate}.sh` wrappers) invoke `skills/product/imagery/scripts/provider.py` — the sub-skills kept the pre-move `skills/imagery/` path after imagery moved under `skills/product/` (the wrappers' `PLUGIN_ROOT` fallback also climbed one directory too few); the requirements output-format ref's **Templates** section points at the two skeletons already inline instead of a `templates/` directory cut in v12.21; the user-story guide's "generate template" line (a script that never shipped) points at the inline **Template for New Stories** block; the runtime-exec example is written as the quoted `"path/to/your_script.py"` placeholder it always was (copy-safe, and no longer shaped like a plugin-root path); and `skills/qe/refs/evidence.md` cites `schemas/evidence.json` as shipped in the `wicked-vault` npm package (garden never vendored it, so the relative link had nothing to resolve to). `scripts/ci/validate.py` §6 now reports 0 broken script paths (was 11). Deliberately untouched: the architecture deployment-template links (`skills/engineering/architecture/refs/architecture-template-deployment.md`, they target the user's repo) and the domain vendor README's sibling-checkout prose.
+- **repo-learn: the tier/severity enum tokens are spelled out unmissably** in the skill, so capture workers stop drifting onto values wicked-estate's `proposal.submit` rejects (#1108).
+
+### Added
+- **`wicked-garden-repo-learn`** — churn-led repo-learning skill: churn → hotspots → captured memories + policy proposals (#1107).
+
+### Changed
+- Docs: the architecture-wiki skill pointers route to Steering (`STEERING.md` — #1103); site additive messaging refresh — steering, governed knowledge, requirements graph (#1109); stale doc counts, version stamp and markers corrected (#1110).
+
 ## [12.32.0] — 2026-08-30
 
 ### Added

package/docs/README.md

@@ -2,16 +2,16 @@
 
 Detailed guides for getting the most out of wicked-garden.
 
-Work in wicked-garden is organized around **9 work-shape archetypes** — not a fixed pipeline. Each prompt classifies into one or more archetypes (triage, explore, specify, decide, ship, review, incident, build, migrate); each owns its own phase shape, produces contract, and HITL discipline.
+Work in wicked-garden is organized around **10 work-shape archetypes** — not a fixed pipeline. Each prompt classifies into one or more archetypes (triage, explore, specify, decide, ship, review, incident, build, migrate, modernize); each owns its own phase shape, produces contract, and HITL discipline.
 
 ## Guides
 
 | Guide | Description |
 |-------|-------------|
 | [Getting Started](getting-started.md) | Installation, required peers, first session, common workflows |
-| [Archetypes](v11/archetypes.md) | The 9 work-shape archetypes — why the universal pipeline went away |
-| [Domains](domains.md) | The 10 domain skills archetypes invoke for expertise |
-| [Required Peers](required-peers.md) | The five required peer plugins and the install/runtime stance |
+| [Archetypes](v11/archetypes.md) | The 10 work-shape archetypes — why the universal pipeline went away |
+| [Domains](domains.md) | The 9 domain skills archetypes invoke for expertise |
+| [Required Peers](required-peers.md) | The one required peer (plus the opt-in layers) and the install/runtime stance |
 | [The Compiler](compiler.md) | `/wicked-garden-prove compile` — emit a self-contained vault-backed gate into any repo |
 | [Extending the Catalog](extending.md) | Ship a third-party pack — `{vendor}-{domain}-{role}` skills, the `wicked-pack.json` manifest, the shipped conformance gate, install + crew routing |
 | [Output Governance (Per-Turn)](outgov-per-turn.md) | The advisory hook lane — `WG_OUTGOV` modes (default `warn`), `rules.recall` as the single per-turn rule source, content-hash provenance for the graph-derived rules dir |

package/docs/brain-chunk-format.md

@@ -9,7 +9,7 @@
 > today, use wicked-garden's `mem` domain (`wicked-garden-mem` `store`/`ingest`)
 > over wicked-estate. Everything below is historical reference only.
 
-This document defines the wicked-brain chunk format so any CLI (Claude Code, Codex, Gemini, Copilot) can write chunks that integrate into the shared knowledge graph.
+This document defines the wicked-brain chunk format so any CLI (Claude Code, Antigravity, Codex, OpenCode, Pi) can write chunks that integrate into the shared knowledge graph.
 
 ## Chunk File Structure
 

package/docs/getting-started.md

@@ -50,7 +50,7 @@ fail-soft (degrades to `🌱 wg │ idle`), and never blocks a render.
 
 ## Your First Session
 
-There is no fixed pipeline. Work is organized around **9 work-shape archetypes** — `triage`, `explore`, `specify`, `decide`, `ship`, `review`, `incident`, `build`, and `migrate`. Each archetype owns its own phase shape, what it produces, and how much human-in-the-loop discipline it demands. After installing, you can invoke any skill immediately. Here are five ways to start:
+There is no fixed pipeline. Work is organized around **10 work-shape archetypes** — `triage`, `explore`, `specify`, `decide`, `ship`, `review`, `incident`, `build`, `migrate`, and `modernize`. Each archetype owns its own phase shape, what it produces, and how much human-in-the-loop discipline it demands. After installing, you can invoke any skill immediately. Here are five ways to start:
 
 ### 1. Just Describe What You Want
 
@@ -73,7 +73,7 @@ When you already know the shape of the work, skip auto-routing and call the arch
 /wicked-garden-archetype decide "Redis vs Postgres for session storage"
 ```
 
-All nine are available: `triage`, `explore`, `specify`, `decide`, `ship`, `review`, `incident`, `build`, `migrate`. Gates re-derive "done" through wicked-loom — which re-runs the verifier via wicked-vault — and fail closed if loom is unavailable; sign-off is evidence-backed, never self-asserted.
+All ten are available: `triage`, `explore`, `specify`, `decide`, `ship`, `review`, `incident`, `build`, `migrate`, `modernize`. Gates re-derive "done" through wicked-loom — which re-runs the verifier via wicked-vault — and fail closed if loom is unavailable; sign-off is evidence-backed, never self-asserted.
 
 ### 3. Use a Domain Skill Directly
 
@@ -201,7 +201,7 @@ Your data is stored locally in `~/.something-wicked/wicked-garden/` as JSON file
 
 ## Next Steps
 
-- [Archetypes](v11/archetypes.md) — the 9 work-shapes: phases, produces, human-in-the-loop (HITL) discipline, cost bands
+- [Archetypes](v11/archetypes.md) — the 10 work-shapes: phases, produces, human-in-the-loop (HITL) discipline, cost bands
 - [Required Peers](required-peers.md) — wicked-vault, wicked-estate, wicked-bus
 - [Compiler](compiler.md) — emit a standalone, vault-backed build gate into any repo
 - [Domains](domains.md) — browse the domain skills and their actions

package/docs/v11/archetypes.md

@@ -64,7 +64,7 @@ The dogfood findings were patches on a foundation that was wrong-shaped.
 
 ## The reframe
 
-Instead of one pipeline + a rigor dial, v11 has **9 archetypes**, each
+Instead of one pipeline + a rigor dial, v11 has **10 archetypes**, each
 with its own:
 
 - **Phase shape** — the actual phase order for that kind of work.
@@ -86,6 +86,7 @@ The archetypes:
 | incident  | triage → investigate → mitigate → resolve → followup    | mitigation / RCA / followup    | hard:mitigate         |
 | build     | plan → implement → test → review                        | shipped code / test report     | discrete:review       |
 | migrate   | plan → expand → backfill → cutover → contract           | shape change / rollback proof  | hard:cutover          |
+| modernize | discover → extract → blueprint → transform → parity → cutover | modernization blueprint / parity proof | hard:cutover-gate |
 
 Each archetype is self-contained. Phase names are NOT shared across
 archetypes — `plan` in `build` is not `plan` in `migrate`. We
@@ -188,12 +189,12 @@ See `CHANGELOG.md` v11.0.0 for the comprehensive list. Headlines:
 
 ## How to extend
 
-Adding a 10th archetype:
+Adding an 11th archetype:
 
 1. Add an entry to `.claude-plugin/archetypes.json`. Declare phases,
    produces, HITL, signals, etc.
 2. Write `skills/archetype/refs/{name}.md` — the playbook for the
-   archetype, ~70-100 lines, following the template of the existing 9.
+   archetype, ~70-100 lines, following the template of the existing 10.
 3. Register the new work-shape in `skills/archetype/SKILL.md` — add it to the
    dispatch table so `/wicked-garden-archetype {name}` loads its playbook. (The
    plugin is skills-only: there is no per-archetype command file; the archetype

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "wicked-garden",
-  "version": "12.32.0",
+  "version": "12.32.1",
   "type": "module",
   "description": "Curated toolkit for what AI coding agents can't do alone: evidence-gated work, codegraph relationships, deterministic multi-file refactor, multi-model second opinions, and cross-session memory. Installs as a Claude Code plugin.",
   "keywords": [

package/skills/core/SKILL.md

@@ -89,6 +89,7 @@ Each domain is one consolidated skill that routes to its actions.
 | `wicked-garden-platform` | Security, infrastructure, compliance, CI/CD, incidents, traces, and plugin diagnostics | security · compliance · incident · health |
 | `wicked-garden-product` | Requirements, customer feedback, strategy, UX, accessibility, and design review | elicit · acceptance · analyze · strategy · ux-review |
 | `wicked-garden-qe` | Evidence-gated quality engineering: strategy, scenario authoring, execution, independent verdicts, ledger insight, and the 3-agent acceptance pipeline | setup · plan · author · execute · review · insight · accept |
+| `wicked-garden-repo-learn` | Learn an unfamiliar repo (churn → hotspots → read the load-bearing intersection) and capture BOTH memories and policies as inert estate proposals a human reviews | churn · hotspots · read · capture |
 | `wicked-garden-search` | Structural code search, lineage, blast-radius, and codebase intelligence | blast-radius · lineage · hotspots · service-map · index |
 | `wicked-garden-smaht` | On-demand context assembly + session briefing from the knowledge layer, search, and the event log | briefing · state · events-import · intent |
 

package/skills/engineering-conformance-reviewer/SKILL.md

@@ -45,10 +45,11 @@ whether the artifact or diff actually violates each applicable rule.
    language/layer/framework facets to narrow). Each rule has:
    `id` (PAT-NNN), `statement` (the pattern text), `severity`, `targets`
    (language/layer/framework facets — absent = wildcard), and a provenance
-   ref (`<doc>@<blob sha>#<RULE-ID>`) — the architecture-wiki doc that minted
-   the rule; cite it in findings so a reviewer can read the doctrine behind
-   the verdict. (Rules are authored as wiki docs, never written by agents —
-   the lifecycle is wicked-core's `crates/wicked-governance/WIKI.md`.)
+   ref (`<doc>@<blob sha>#<RULE-ID>`) — the Steering doc that minted the
+   rule; cite it in findings so a reviewer can read the doctrine behind the
+   verdict. (Steering rules are authored by doc PR or through crew's
+   governed UI/chat surface — never via this MCP, which stays read-only;
+   the lifecycle is wicked-core's `crates/wicked-governance/STEERING.md`.)
 
 2. **Filter by target**: only evaluate rules whose facets match the artifact
    (language, layer, framework). Absent facets match everything.

package/skills/mem/SKILL.md

@@ -88,13 +88,15 @@ and score; present the top hits and cite `memory_id`/scope when the user
 needs provenance. For a synthesized, citation-bearing answer use the
 `answer` action instead.
 
-**Architecture-wiki doctrine** lives in the knowledge store under `wiki:`
-scopes (e.g. `wiki:architecture` — planes, storage doctrine, event grammar,
-ADR rationale): recall it with `knowledge.recall` /
+**Steering doctrine** (the governance rules, 7 steering types) lives in the
+knowledge store under `wiki:` scopes (a historical prefix — e.g.
+`wiki:architecture`: planes, storage doctrine, event grammar, ADR
+rationale): recall it with `knowledge.recall` /
 `{"scope_prefix": "wiki:"}` via `answer`, and recall the *enforceable* rules
 behind it with the estate MCP `rules.recall` tool (faceted, severity-ordered,
-each hit citing its source doc). Authoring/seeding/retiring the wiki is
-operator work — see wicked-core's `crates/wicked-governance/WIKI.md`.
+each hit citing its source doc). Managing steering (import / chat / edit /
+retire) is operator work — see `crates/wicked-governance/STEERING.md`
+in wicked-core.
 
 ## Review / Maintain
 

package/skills/product/imagery/alter/SKILL.md

@@ -27,7 +27,7 @@ AI-powered modification of existing images through two primary modes: image-to-i
 Changes the overall style or adds global elements while preserving core composition.
 
 ```bash
-sh "${CLAUDE_PLUGIN_ROOT}/scripts/_python.sh" "${CLAUDE_PLUGIN_ROOT}/skills/imagery/scripts/provider.py" edit \
+sh "${CLAUDE_PLUGIN_ROOT}/scripts/_python.sh" "${CLAUDE_PLUGIN_ROOT}/skills/product/imagery/scripts/provider.py" edit \
   --image ./source.png \
   --prompt "Same scene but with a dramatic sunset sky" \
   --output ./v2.png
@@ -43,7 +43,7 @@ sh "${CLAUDE_PLUGIN_ROOT}/scripts/_python.sh" "${CLAUDE_PLUGIN_ROOT}/skills/imag
 Precise edits to specific regions using a binary mask (white = edit area, black = preserve).
 
 ```bash
-sh "${CLAUDE_PLUGIN_ROOT}/scripts/_python.sh" "${CLAUDE_PLUGIN_ROOT}/skills/imagery/scripts/provider.py" inpaint \
+sh "${CLAUDE_PLUGIN_ROOT}/scripts/_python.sh" "${CLAUDE_PLUGIN_ROOT}/skills/product/imagery/scripts/provider.py" inpaint \
   --image ./source.png \
   --mask ./mask.png \
   --prompt "Replace with floating lanterns" \
@@ -87,7 +87,7 @@ Use upscaling as the last step to bring a draft to production quality:
 
 ```bash
 # Upscaling (cstudio only — other providers may not support this)
-sh "${CLAUDE_PLUGIN_ROOT}/scripts/_python.sh" "${CLAUDE_PLUGIN_ROOT}/skills/imagery/scripts/provider.py" generate \
+sh "${CLAUDE_PLUGIN_ROOT}/scripts/_python.sh" "${CLAUDE_PLUGIN_ROOT}/skills/product/imagery/scripts/provider.py" generate \
   --provider cstudio \
   --prompt "upscale" \
   --output ./final_hires.png

package/skills/product/imagery/alter/refs/editing-reference.md

@@ -69,20 +69,20 @@ When the output is "almost there" but not quite:
 
 ```bash
 # Image-to-image edit
-sh "${CLAUDE_PLUGIN_ROOT}/scripts/_python.sh" "${CLAUDE_PLUGIN_ROOT}/skills/imagery/scripts/provider.py" edit \
+sh "${CLAUDE_PLUGIN_ROOT}/scripts/_python.sh" "${CLAUDE_PLUGIN_ROOT}/skills/product/imagery/scripts/provider.py" edit \
   --image ./source.png \
   --prompt "Same scene but with dramatic sunset sky" \
   --output ./v2.png
 
 # Inpainting with mask
-sh "${CLAUDE_PLUGIN_ROOT}/scripts/_python.sh" "${CLAUDE_PLUGIN_ROOT}/skills/imagery/scripts/provider.py" inpaint \
+sh "${CLAUDE_PLUGIN_ROOT}/scripts/_python.sh" "${CLAUDE_PLUGIN_ROOT}/skills/product/imagery/scripts/provider.py" inpaint \
   --image ./source.png \
   --mask ./mask.png \
   --prompt "Replace with floating lanterns" \
   --output ./v2_inpaint.png
 
 # Use a specific provider
-sh "${CLAUDE_PLUGIN_ROOT}/scripts/_python.sh" "${CLAUDE_PLUGIN_ROOT}/skills/imagery/scripts/provider.py" edit \
+sh "${CLAUDE_PLUGIN_ROOT}/scripts/_python.sh" "${CLAUDE_PLUGIN_ROOT}/skills/product/imagery/scripts/provider.py" edit \
   --provider stability \
   --image ./source.png \
   --prompt "Oil painting style" \

package/skills/product/imagery/create/SKILL.md

@@ -34,7 +34,7 @@ AI-powered image generation from text prompts. Supports multiple providers throu
 
 ```bash
 # Check which providers are available
-sh "${CLAUDE_PLUGIN_ROOT}/scripts/_python.sh" "${CLAUDE_PLUGIN_ROOT}/skills/imagery/scripts/provider.py" detect
+sh "${CLAUDE_PLUGIN_ROOT}/scripts/_python.sh" "${CLAUDE_PLUGIN_ROOT}/skills/product/imagery/scripts/provider.py" detect
 ```
 
 The provider abstraction selects the best available provider automatically. A specific provider can be forced when needed.
@@ -74,12 +74,12 @@ For detailed prompt engineering techniques, see [refs/prompt-engineering.md](ref
 
 ```bash
 # Basic generation (auto-detects best available provider)
-sh "${CLAUDE_PLUGIN_ROOT}/scripts/_python.sh" "${CLAUDE_PLUGIN_ROOT}/skills/imagery/scripts/provider.py" generate \
+sh "${CLAUDE_PLUGIN_ROOT}/scripts/_python.sh" "${CLAUDE_PLUGIN_ROOT}/skills/product/imagery/scripts/provider.py" generate \
   --prompt "Your crafted prompt" \
   --output ./output/v1.png
 
 # Use a specific provider
-sh "${CLAUDE_PLUGIN_ROOT}/scripts/_python.sh" "${CLAUDE_PLUGIN_ROOT}/skills/imagery/scripts/provider.py" generate \
+sh "${CLAUDE_PLUGIN_ROOT}/scripts/_python.sh" "${CLAUDE_PLUGIN_ROOT}/skills/product/imagery/scripts/provider.py" generate \
   --prompt "Your crafted prompt" \
   --provider openai \
   --output ./output/v1.png

package/skills/product/imagery/scripts/analyze.sh

@@ -19,5 +19,5 @@ if [ -z "$IMAGE" ]; then
 fi
 
 echo "Image analysis for '$IMAGE' should be performed by reading the file directly."
-echo "See: skills/imagery/review/SKILL.md"
+echo "See: skills/product/imagery/review/SKILL.md"
 exit 0

package/skills/product/imagery/scripts/edit.sh

@@ -1,6 +1,7 @@
 #!/bin/bash
 # edit.sh - Delegates to provider.py for multi-provider image editing
-PLUGIN_ROOT="${CLAUDE_PLUGIN_ROOT:-$(cd "$(dirname "$0")/../../.." && pwd)}"
+# skills/product/imagery/scripts/ -> plugin root is four levels up.
+PLUGIN_ROOT="${CLAUDE_PLUGIN_ROOT:-$(cd "$(dirname "$0")/../../../.." && pwd)}"
 
 IMAGE="$1"
 PROMPT="$2"
@@ -11,4 +12,4 @@ if [ -z "$IMAGE" ] || [ -z "$PROMPT" ]; then
   exit 1
 fi
 
-python3 "${PLUGIN_ROOT}/skills/imagery/scripts/provider.py" edit --image "$IMAGE" --prompt "$PROMPT" --output "$OUT_FILE"
+python3 "${PLUGIN_ROOT}/skills/product/imagery/scripts/provider.py" edit --image "$IMAGE" --prompt "$PROMPT" --output "$OUT_FILE"

package/skills/product/imagery/scripts/generate.sh

@@ -1,6 +1,7 @@
 #!/bin/bash
 # generate.sh - Delegates to provider.py for multi-provider image generation
-PLUGIN_ROOT="${CLAUDE_PLUGIN_ROOT:-$(cd "$(dirname "$0")/../../.." && pwd)}"
+# skills/product/imagery/scripts/ -> plugin root is four levels up.
+PLUGIN_ROOT="${CLAUDE_PLUGIN_ROOT:-$(cd "$(dirname "$0")/../../../.." && pwd)}"
 
 PROMPT="$1"
 OUT_FILE="${2:-./output.png}"
@@ -10,4 +11,4 @@ if [ -z "$PROMPT" ]; then
   exit 1
 fi
 
-python3 "${PLUGIN_ROOT}/skills/imagery/scripts/provider.py" generate --prompt "$PROMPT" --output "$OUT_FILE"
+python3 "${PLUGIN_ROOT}/skills/product/imagery/scripts/provider.py" generate --prompt "$PROMPT" --output "$OUT_FILE"

package/skills/product/requirements-analysis/refs/requirements-output-format-template.md

@@ -226,19 +226,19 @@ Requirements should be saved to:
 
 ## Templates
 
-### Quick Start Template
-```bash
-# Copy minimal template for new requirements
-cp "${CLAUDE_PLUGIN_ROOT}/templates/requirements-minimal.md" \
-   requirements.md
-```
-
-### Full Template
-```bash
-# Copy full template for comprehensive analysis
-cp "${CLAUDE_PLUGIN_ROOT}/templates/requirements-full.md" \
-   requirements.md
-```
+Both skeletons live in this document — there is no separate `templates/`
+directory to copy from (it was cut in v12.21). Start a new document by copying
+the fenced markdown block from the matching section above and filling in the
+`{placeholders}`:
+
+- **Quick start** — the **Minimal Output Format** section, for smaller
+  features or rapid analysis (3-5 core stories, out of scope, open questions).
+- **Full** — the **Standard Output Structure** section, for a comprehensive
+  analysis (personas, functional + non-functional requirements, scope,
+  dependencies, risks, traceability).
+
+Save the result where **Output Delivery** says (`requirements.md`, or
+`phases/requirements/analysis.md` inside a project workflow).
 
 ## Resources
 

package/skills/product/requirements-analysis/refs/user-story-guide.md

@@ -291,6 +291,8 @@ Use this template when creating new user stories:
 
 ## Resources
 
-- Domain-specific examples: `skills/requirements-analysis/refs/story-examples/`
-- Generate template: `sh "${CLAUDE_PLUGIN_ROOT}/scripts/_python.sh" "${CLAUDE_PLUGIN_ROOT}/scripts/user-story-template.sh"`
+- Domain-specific examples: `requirements-example-auth.md` and
+  `requirements-example-export-integration.md` in this skill's `refs/`
+- New-story skeleton: copy the fenced block in the **Template for New Stories**
+  section above (there is no generator script)
 - Validate against INVEST criteria checklist above

package/skills/qe/refs/evidence.md

@@ -32,7 +32,9 @@ is portable by directory copy.
 
 ## 2. `manifest.json` Schema (public)
 
-Formal JSON Schema: [`schemas/evidence.json`](../schemas/evidence.json)
+Formal JSON Schema: `schemas/evidence.json`, shipped in the `wicked-vault` npm
+package (not vendored in this plugin — resolve it locally with
+`ls "$(npm root -g)/wicked-vault/schemas/evidence.json"`).
 
 ```jsonc
 {

package/skills/repo-learn/SKILL.md

@@ -0,0 +1,163 @@
+---
+name: wicked-garden-repo-learn
+user-invocable: true
+description: |
+  Learn an unfamiliar repo the way a senior engineer does: follow where the code
+  actually churns, find what that churn touches that the rest of the system leans
+  on, read the load-bearing code for real, then write down BOTH what you learned
+  (memories) and what should hold (policies) — as inert estate proposals a human
+  reviews, never as asserted fact.
+
+  Four BOUNDED phases: (1) SAMPLED git-churn → ranked active areas (explicit
+  top-N cap + a sampling rule for large histories — never streams every commit);
+  (2) hotspots + blast-radius via wicked-garden-search, cross-referenced with
+  churn to isolate load-bearing volatile code; (3) READ the intersection through
+  the estate graph (FetchContent / RetrieveEntity / TraverseGraph) for genuine
+  technical understanding; (4) DERIVE memories AND policies and submit them via
+  the estate `proposal.submit` tool (inert queue, safe under --readonly).
+
+  Use when: "learn this repo", "onboard me to this codebase", "study the active
+  areas", "what should I know before working here", "derive memories / policies
+  from this repo", "capture what matters about this codebase". Durable
+  orientation + capture — for a read-only narrative with no capture, use
+  wicked-garden-search `narrate` instead.
+phase_relevance: ["*"]
+archetype_relevance: ["*"]
+---
+
+# wicked-garden-repo-learn — churn-led repo learning that captures back
+
+A repo teaches you where to look if you follow two independent signals at once:
+**temporal** (where the code churns) and **structural** (what the rest of the
+system depends on). This skill walks the intersection, reads it for real, and
+**captures the learning back** as estate proposals — memories (what is true) and
+policies (what should hold). Garden ORCHESTRATES; estate GROUNDS (graph + read)
+and RECEIVES (the proposal queue); a human APPROVES. Nothing here asserts a fact
+into the record — every capture is an inert proposal the studio Memories /
+Policies surfaces review.
+
+**Why churn is a separate step:** estate's `RankHotspots` is *structural*
+PageRank, not temporal — it never sees git history. Churn is the gap this skill
+fills, with a **bounded, sampled** git-log method (never one that streams every
+commit). The two signals are complementary, not redundant; § Cross-reference is
+where the value is.
+
+## The four phases
+
+| # | Phase | Produces | Where |
+|---|-------|----------|-------|
+| 1 | **churn** | ranked active paths/areas over a window, top-N capped | [refs/churn-sampling.md](refs/churn-sampling.md) |
+| 2 | **hotspots** | most-central symbols + blast-radius of the churn set | `wicked-garden-search` (reused — do NOT reimplement) |
+| 3 | **read** | real understanding of the load-bearing, volatile code | § Read the intersection |
+| 4 | **capture** | memories AND policies as inert `proposal.submit` entries | [refs/capture-proposals.md](refs/capture-proposals.md) |
+
+Run them in order — each phase narrows the next. A partial run is still useful
+(churn alone orients; churn+hotspots+read without capture is a briefing), but the
+skill's contract is that **understanding ends in captured proposals**, not prose.
+
+## Phase 1 — churn (the bounded, sampled step)
+
+Rank the paths that changed most over a window. The method is fully specified in
+[refs/churn-sampling.md](refs/churn-sampling.md); the non-negotiables:
+
+- **Size the window first** (`git rev-list --count`) — choose full-scan vs sample
+  by commit count, never by hoping.
+- **Explicit top-N cap** (default **40** paths) — the final list is always
+  `head -N`; the raw `--name-only` stream stays inside the shell pipe (sort /
+  uniq), never in your context.
+- **Sampling rule for large histories** — above the commit cap (default
+  **2000**), switch to a recency-capped or even-stride sample; never `git log`
+  the full history unbounded. Worker output is capped ~25K chars — a full-history
+  churn dump both blows that and starves the phases that matter.
+- **Roll up to directories** for wide monorepos; **filter generated/vendored
+  noise** (lockfiles, `dist/`, `target/`, `node_modules/`).
+
+Output of phase 1: a ranked list of ≤N `count  path` (or `count  dir/`) rows.
+
+## Phase 2 — hotspots + blast-radius (reuse wicked-garden-search)
+
+Do NOT reimplement centrality. Use the **wicked-garden-search** skill:
+
+- `hotspots` — most-central symbols by PageRank (`RankHotspots`). Read its
+  [refs/hotspots.md](../search/refs/hotspots.md); pass `--limit` near your top-N.
+- `blast-radius <path>` — for each top churn path, the dependents estate sees
+  (including injected bus/dispatch/capability/archetype edges grep can't). This
+  is what tells you a churny file is load-bearing vs peripheral.
+
+Freshness is a precondition: run the search skill's `index` action first
+(`wicked-estate index <path>`) and heed any `STALENESS` marker.
+
+## Cross-reference — the 2×2 that picks read targets
+
+Churn and centrality answer different questions; the intersection ranks targets.
+
+|                       | **High churn** | **Low churn** |
+|-----------------------|----------------|---------------|
+| **High centrality**   | load-bearing + volatile → **read deeply**; likely yields BOTH a memory (how it works / why it moves) AND a policy (what must hold as it changes) | stable core → **read for invariants**; yields policies (severity `error`/`critical`) more than memories |
+| **Low centrality**    | churny periphery (config, fixtures, generated) → **mostly noise**; skip unless it's a hot integration seam | quiet leaf → **skip** |
+
+The prime targets are the top-left cell: paths that appear in BOTH the phase-1
+churn list and the phase-2 hotspot/blast-radius set. Read those first.
+
+## Phase 3 — read the intersection
+
+For each cross-referenced target, build **genuine** understanding — not a file
+listing — via the estate MCP (all read-only):
+
+1. `SearchEntity` `{"name": "<symbol-or-path>"}` → resolve to node ids/kinds.
+2. `RetrieveEntity` → the symbol's structured record; `FetchContent` → the actual
+   source slice (read the code, don't infer from names).
+3. `TraverseGraph` (bounded — it carries `max_depth`/`max_nodes`) or `Lineage` →
+   how the target connects: what it calls, what calls it, which events/commands
+   inject edges into it.
+4. Recall what's already known before writing anything new: `wicked-garden-mem`
+   `recall` (`scope_prefix: ""`) so you extend the record rather than duplicate it.
+
+Stop when you can state, per target, **what it does, why it changes, what it
+depends on, and what would break** — that is the input to phase 4.
+
+## Phase 4 — capture: memories AND policies as proposals
+
+Turn understanding into two kinds of reviewable record via the estate
+MCP **`proposal.submit`** tool (inert queue; a PERMITTED safe write even under
+`--readonly`). Full contract, payloads, facets, and derivation heuristics:
+[refs/capture-proposals.md](refs/capture-proposals.md). The essentials — use the
+enum values EXACTLY as written (an out-of-enum `tier` or `severity` is rejected
+when the proposal is approved, so the learning is lost):
+
+- **Memory** — what is *true* about this repo. `kind_type: "memory"`; payload
+  `{"content": "<1–3 sentences>", "tier": "<value>"}` where `tier` is EXACTLY one
+  of `working` / `episodic` / `semantic` / `procedural` / `archival` — for a repo
+  learning use `semantic` (a fact/decision) or `procedural` (a how-to/convention);
+  NEVER invent a tier like `durable`. Facets `{"repo": "<name>", "project": "<name>"}`.
+- **Policy** — what *should hold*. `kind_type: "policy:<type>"` where `<type>` ∈
+  architecture · development · security · testing · operations · compliance ·
+  design-ux; payload `{"rule": "<imperative>", "severity": "<value>"}` where
+  `severity` is EXACTLY one of `info` / `warn` / `error` / `critical` — the middle
+  band is `warn`, NOT `warning`. Facets `{"repo": "<name>", "project": "<name>", "language": "<lang>"}`.
+- **Never pass `provenance`** — the server stamps it from `WICKED_RUN_*`. Passing
+  it is at best ignored; treat provenance as not yours to set.
+- Derive **both** per target where the 2×2 warrants it: the memory records the
+  *is*, the policy records the *ought*. A stable high-centrality invariant is a
+  policy; a "this is how X actually wires up" discovery is a memory.
+
+## Degrade + honesty
+
+- **Estate unreachable** (index/MCP down): phase 1 still runs (pure git); for
+  phases 2–3 fall back per the search skill's ladder (CLI → Grep, flagging that
+  injected edges are MISSING). Say so — don't present a grep approximation as the
+  graph answer.
+- **`proposal.submit` fails (a JSON-RPC error, e.g. -32602 / -32603)**: do NOT silently drop the learning.
+  Emit the derived memories and policies as a structured block in your report so
+  a human (or a later run) can submit them, and name the degrade.
+- Capture is a **proposal**, not an assertion — report it as "proposed N
+  memories, M policies (pending review)", never "recorded".
+
+## Depth
+
+- [refs/churn-sampling.md](refs/churn-sampling.md) — the bounded/sampled git-log
+  method: window sizing, the sample rule, the top-N cap, directory rollup, noise
+  filters, and the cross-platform counting fallback.
+- [refs/capture-proposals.md](refs/capture-proposals.md) — the `proposal.submit`
+  contract for memories and policies, the derivation heuristics (2×2 → what to
+  propose), worked examples, and the idempotency/dedup discipline.

package/skills/repo-learn/refs/capture-proposals.md

@@ -0,0 +1,162 @@
+# Capture — memories AND policies as estate proposals
+
+The learning phase ends by writing back **two kinds** of record through the estate
+MCP **`proposal.submit`** tool: **memories** (what is *true* about this repo) and
+**policies** (what *should hold* in it). Both land in estate's **inert proposal
+queue** — a type-generic write surface that is a PERMITTED safe write **even under
+`--readonly`**, because a proposal is never recalled or applied until an operator
+approves it. A governed worker's estate MCP already opens the operator GLOBAL
+store and permits `proposal.submit`, so proposals surface in the studio Memories /
+Policies review UI. This is *propose, not assert* — you never inject a fact into
+the record; a human promotes it.
+
+## The `proposal.submit` contract (wire shape)
+
+`proposal.submit` takes exactly three caller-supplied fields:
+
+| Field | Type | Rule |
+|-------|------|------|
+| `kind_type` | string | `"memory"` OR `"policy:<type>"`; must match `^[a-z][a-z0-9_-]*(:[a-z][a-z0-9_-]*)?$` |
+| `payload`   | JSON **object** | required; a present non-object is rejected `-32602` (never silently defaulted) |
+| `facets`    | JSON object of `axis:value` strings | optional; each axis is a lowercase token `^[a-z][a-z0-9_-]*$`, each value non-empty |
+
+**`provenance` is NOT a caller field.** The server stamps it from its own launch
+env (`WICKED_RUN_ID` / `WICKED_RUN_UNIT` / `WICKED_RUN_AGENT`) — a worker cannot
+forge its own attribution, and passing `provenance` in args is not honored. Do not
+construct it.
+
+On success the tool returns `{"id": "<proposal-id>"}`. A malformed `kind_type`,
+`facets`, or a non-object `payload` fails loud with `-32602` — fix and resubmit,
+never swallow.
+
+### `<type>` for policies (the seven steering types)
+
+`policy:` must be suffixed with exactly one: `architecture` · `development` ·
+`security` · `testing` · `operations` · `compliance` · `design-ux`. These are the
+estate/steering types — pick the one the rule governs, not a freeform tag.
+
+## Memory payload + facets
+
+```json
+{
+  "kind_type": "memory",
+  "payload": { "content": "<1–3 self-contained sentences>", "tier": "semantic" },
+  "facets": { "repo": "<repo-name>", "project": "<project-name>" }
+}
+```
+
+- `content` — distilled, self-contained: the *why* and *what* a future session
+  needs, not a paragraph of *how*. One to three sentences. If it needs the current
+  file open to make sense, it isn't distilled yet.
+- `tier` — `"semantic"` for stable facts/decisions/gotchas ("X is wired via the
+  bus, not a direct call"); `"procedural"` for a repeatable how-to/convention
+  ("to add a language, drop a row in languages.toml + a .scm file — no core
+  change").
+- `facets` — `repo:` and `project:` locate the memory so faceted recall admits it
+  for the right work. Use the repo's directory/remote name and the umbrella
+  project (here, `wicked`).
+
+## Policy payload + facets
+
+```json
+{
+  "kind_type": "policy:architecture",
+  "payload": { "rule": "<imperative statement of what must hold>", "severity": "error" },
+  "facets": { "repo": "<repo-name>", "project": "<project-name>", "language": "<lang>" }
+}
+```
+
+- `rule` — an imperative the code should satisfy, phrased so a reviewer can judge
+  a diff against it ("Every emitted Edge carries {confidence, provenance,
+  resolved_by}"; "No content-hash or line-number node ids"). Not a description —
+  a *ought*.
+- `severity` — `info` (advisory) · `warn` (should) · `error` (must; a violation
+  blocks) · `critical` (must; a violation is a security/data-loss class). Map from
+  the 2×2 below and from what the code's own guardrails signal.
+- `facets` — policies add `language:` on top of `repo:`/`project:`, so a rule that
+  is language-scoped ("Rust: no bare `panic!` in library crates") admits only for
+  that language. Omit `language:` for a language-agnostic architectural rule.
+
+## Deriving BOTH — the 2×2 → proposal map
+
+The cross-reference cell (SKILL.md § Cross-reference) tells you *what kind* of
+proposal a read target warrants:
+
+| Cell | Signal | Propose |
+|------|--------|---------|
+| **high churn + high centrality** | load-bearing and moving | **BOTH**: a memory (how it works / why it churns / what it wires) + a policy (the invariant that must survive the churn — often `error`) |
+| **low churn + high centrality** | stable core / invariant | mostly **policy** (`error`/`critical`) capturing the invariant; add a memory only if the *why* is non-obvious |
+| **high churn + low centrality** | churny periphery | usually **neither**; a memory only if it's a hot integration seam worth flagging (e.g. "config X is edited every release — treat as an interface") |
+| **low churn + low centrality** | quiet leaf | **skip** |
+
+The discipline: a memory records the **is** (this is how the system is), a policy
+records the **ought** (this is what a change must preserve). A single load-bearing
+target frequently yields one of each — the memory so the next reader understands
+it, the policy so the next editor doesn't break it. Do not force a proposal from a
+cell that says skip; a thin capture pollutes the queue the operator must triage.
+
+## Worked examples
+
+Memory (procedural, from reading a high-churn/high-centrality extractor):
+
+```json
+{
+  "kind_type": "memory",
+  "payload": {
+    "content": "Language extractors are data, not code: a new language is a row in wicked-estate-extract/languages.toml plus a <name>.scm query file — zero core change. Per-language match arms in Rust are a rejected pattern.",
+    "tier": "procedural"
+  },
+  "facets": { "repo": "wicked-estate", "project": "wicked" }
+}
+```
+
+Policy (architecture, from the same subsystem's invariant):
+
+```json
+{
+  "kind_type": "policy:architecture",
+  "payload": {
+    "rule": "Every emitted Edge must carry {confidence, provenance, resolved_by}; never present a heuristic edge as a fact.",
+    "severity": "error"
+  },
+  "facets": { "repo": "wicked-estate", "project": "wicked", "language": "rust" }
+}
+```
+
+Policy (development, language-scoped, from a stable core with a clear guardrail):
+
+```json
+{
+  "kind_type": "policy:development",
+  "payload": {
+    "rule": "Rust: no bare panic!/unwrap in library crates; surface a typed error.",
+    "severity": "warn"
+  },
+  "facets": { "repo": "wicked-estate", "project": "wicked", "language": "rust" }
+}
+```
+
+## Before you submit — recall first, then dedup
+
+1. **Recall the existing record** (`wicked-garden-mem` `recall`, `scope_prefix:
+   ""`, and estate `rules.recall` for policies). If the learning already exists,
+   do not re-propose it — the queue is a human's triage list, and duplicates cost
+   review time. Propose only the *delta*.
+2. **One claim per proposal.** A memory that bundles three facts, or a policy that
+   bundles three rules, can't be approved/rejected cleanly. Split them.
+3. **Ground the claim in what you read.** Every proposal must trace to a target
+   you actually opened in phase 3 (`FetchContent`/`RetrieveEntity`), not to a name
+   you inferred. An ungrounded proposal is exactly the asserted-not-evidenced
+   failure this method exists to avoid.
+
+## Failure handling
+
+- `-32602` (invalid kind_type/facets/payload): a *your-args* bug — fix the shape
+  (lowercase kind_type suffix, object payload, valid axis tokens) and resubmit.
+- `-32603` / transport / MCP unreachable: the store or server failed. Do **not**
+  drop the learning — collect the derived memories and policies into a structured
+  block in your final report (the exact `{kind_type, payload, facets}` objects) so
+  a human or a later run can submit them, and name the degrade explicitly.
+- Report captures honestly: "**proposed** N memories, M policies (pending
+  review)", never "recorded" or "stored" — nothing is in the record until an
+  operator approves it.

package/skills/repo-learn/refs/churn-sampling.md

@@ -0,0 +1,197 @@
+# Churn sampling — the bounded, top-N git-log method
+
+Estate does **not** rank git churn: `RankHotspots` is structural PageRank over
+Calls+Imports edges, blind to history. Temporal ranking is this phase's job, and
+it is a git-log method — but a *disciplined* one. The failure mode to design out:
+a naive `git log --name-only` over a long history streams megabytes, blows the
+worker's ~25K-char output cap (estate agent-behavior R4), and starves the phases
+that actually matter. Every recipe below is **bounded** — an explicit top-N cap
+plus a sampling rule keyed to history size.
+
+## The three invariants
+
+1. **Cap the output.** The list you keep is always `head -N` (default **40**).
+   The raw `--name-only` stream is consumed *inside the shell pipe* (`sort | uniq
+   | sort | head`); only the final ≤N rows reach your context. Never `cat` or echo
+   the full stream.
+2. **Cap the input.** Above a commit threshold (default **2000**) you MUST sample
+   or window — never `git log` the full history unbounded. Bound it even when you
+   think it's small; size it first and find out.
+3. **Two signals, not one.** Churn alone over-weights churny-but-shallow files
+   (config, generated). The output of this phase is an *input* to the cross-
+   reference against structural hotspots (SKILL.md § Cross-reference), never a
+   standalone verdict.
+
+## Step 0 — size the window (bounded probe, no materialization)
+
+Count commits in the window without listing them, and count tracked files for the
+rollup decision:
+
+```bash
+WINDOW="12.months"                                   # default; override per ask
+C=$(git rev-list --count --since="$WINDOW" HEAD)     # commits in window
+F=$(git ls-files | wc -l)                            # tracked files
+echo "commits_in_window=$C tracked_files=$F"
+```
+
+`git rev-list --count` is O(commits) but materializes nothing — safe on any
+history. Choose the mode from `C`:
+
+| `C` (commits in window) | Mode | Recipe |
+|-------------------------|------|--------|
+| `C ≤ 2000`              | **full-scan** | § Full-scan churn |
+| `C > 2000`              | **sampled**   | § Sampled churn (pick a strategy) |
+
+And choose granularity from `F`:
+
+| `F` (tracked files) | Granularity |
+|---------------------|-------------|
+| `F ≤ 5000`          | file-level (default) |
+| `F > 5000`, or file-level top-N is dominated by single-change files | **directory rollup** (§ Directory rollup) |
+
+Thresholds are defaults, not laws — a repo with enormous commits (vendored blobs)
+may warrant a lower cap; a tiny repo with a 5-year window may stay full-scan above
+2000. State the mode you picked and why.
+
+## Full-scan churn (small histories, `C ≤ 2000`)
+
+```bash
+git log --since="$WINDOW" --no-renames --name-only --pretty=format: -- . \
+  | grep -v '^$' \
+  | grep -Ev '(^|/)(node_modules|dist|build|target|vendor|\.min\.|package-lock\.json|Cargo\.lock|pnpm-lock\.yaml|yarn\.lock)(/|$)' \
+  | sort | uniq -c | sort -rn \
+  | head -40
+```
+
+- `--no-renames` (git's default; stated for intent) — do **not** `--follow`
+  (per-path only, incompatible with a whole-tree scan).
+- `--pretty=format:` empties the commit-header lines so only file paths remain;
+  `grep -v '^$'` drops the blank separators.
+- The two `grep -Ev` filters strip generated/vendored/lockfile noise — churn there
+  is not active *development*. Extend the pattern per repo (e.g. `__generated__`,
+  `.pb.go`, `migrations/` if autogenerated).
+- `sort | uniq -c | sort -rn | head -40` = count per path, most-changed first,
+  top-N capped. This is the whole method for small histories.
+
+Output rows are `<count>  <path>`. That ranked list is phase 1's product.
+
+## Sampled churn (large histories, `C > 2000`)
+
+Pick ONE strategy. Both keep the *input* bounded; the output cap (`head -40`) is
+unchanged.
+
+### Strategy A — recency cap (default)
+
+Most-recent-N commits. Recent churn is the better signal for "active areas", and
+it's a single git call:
+
+```bash
+git log --since="$WINDOW" --no-renames --name-only --pretty=format: --max-count=2000 -- . \
+  | grep -v '^$' \
+  | grep -Ev '(^|/)(node_modules|dist|build|target|vendor|\.min\.|package-lock\.json|Cargo\.lock|pnpm-lock\.yaml|yarn\.lock)(/|$)' \
+  | sort | uniq -c | sort -rn \
+  | head -40
+```
+
+`--max-count=2000` bounds the walk to the 2000 newest commits in the window.
+Deterministic, recency-biased, one process. Use this unless the window's *tail*
+matters.
+
+### Strategy B — even stride (representative across the window)
+
+When you need the whole window represented (e.g. auditing a long-lived module's
+history, not just its recent activity), sample every k-th commit:
+
+```bash
+K=$(( (C + 1999) / 2000 ))                           # ceil(C / 2000) → ~2000 samples
+git rev-list --since="$WINDOW" HEAD \
+  | awk -v k="$K" 'NR % k == 1' \
+  | while IFS= read -r sha; do
+      git show --no-renames --name-only --pretty=format: "$sha"
+    done \
+  | grep -v '^$' \
+  | grep -Ev '(^|/)(node_modules|dist|build|target|vendor|\.min\.|package-lock\.json|Cargo\.lock|pnpm-lock\.yaml|yarn\.lock)(/|$)' \
+  | sort | uniq -c | sort -rn \
+  | head -40
+```
+
+`awk 'NR % k == 1'` takes a deterministic evenly-spaced sample (~2000 SHAs). More
+processes than Strategy A (one `git show` per sampled commit) — heavier, so reserve
+it for when tail coverage is worth the cost. Note the sample is of *commits*, so
+counts are proportional, not absolute; rank is what you use, not the raw count.
+
+## Directory rollup (wide repos)
+
+When file-level churn fragments (a monorepo where every top file changed once),
+roll up to a directory prefix to find active *areas*:
+
+```bash
+git log --since="$WINDOW" --no-renames --name-only --pretty=format: --max-count=2000 -- . \
+  | grep -v '^$' \
+  | grep -Ev '(^|/)(node_modules|dist|build|target|vendor)(/|$)' \
+  | awk -F/ 'NF>=2 {print $1"/"$2} NF==1 {print $1}' \
+  | sort | uniq -c | sort -rn \
+  | head -40
+```
+
+`awk -F/ '{print $1"/"$2}'` collapses each path to its first two segments (tune to
+1 or 3 per repo shape). The ranked areas then seed phase-2 hotspots/blast-radius
+at the subsystem level. You can run file-level and rollup both and present each.
+
+## Cross-platform counting fallback (Windows / no coreutils)
+
+`sort | uniq -c | sort -rn` is fine on macOS/Linux/WSL/Git-Bash but not native
+PowerShell. `git log` itself is cross-platform; only the counting pipe isn't.
+Feed git's output to a stdlib Python counter (per the repo's cross-platform rule):
+
+Save the counter below as `churn_count.py`, then pipe git's output through it —
+NOT `python3 -` (in a pipe, stdin is git's output, so `-` would try to run that
+output as the program):
+
+```bash
+git log --since="12.months" --no-renames --name-only --pretty=format: --max-count=2000 -- . \
+  | python3 churn_count.py 40 2>/dev/null \
+  || git log --since="12.months" --no-renames --name-only --pretty=format: --max-count=2000 -- . | python churn_count.py 40
+```
+
+with this counter saved as `churn_count.py`:
+
+```python
+import sys, collections, re
+n = int(sys.argv[1]) if len(sys.argv) > 1 else 40
+noise = re.compile(r'(^|/)(node_modules|dist|build|target|vendor|\.min\.|'
+                   r'package-lock\.json|Cargo\.lock|pnpm-lock\.yaml|yarn\.lock)(/|$)')
+counts = collections.Counter()
+for line in sys.stdin:
+    p = line.strip()
+    if p and not noise.search(p):
+        counts[p] += 1
+for path, c in counts.most_common(n):
+    sys.stdout.write("%6d  %s\n" % (c, path))
+```
+
+Same top-N cap, same noise filter, no coreutils dependency. The `--max-count` bound
+still applies — Python counting an unbounded history would still be unbounded work.
+
+## What phase 1 hands off
+
+A ranked list of ≤N rows: `<count>  <path>` (or `<count>  <dir>/`). Carry it into
+phase 2 — for each of the top paths, ask `wicked-garden-search` `blast-radius
+<path>` and consult `hotspots` — and into the § Cross-reference 2×2. Do not treat
+a high churn count as importance on its own: a generated file that changes every
+commit tops this list and means nothing until the structural signal confirms (or
+denies) that anything depends on it.
+
+## Pitfalls
+
+- **Streaming the full log.** The one thing this method exists to prevent. Always
+  `--max-count`/sample above the threshold and always `head -N`.
+- **`--follow` on a whole-tree scan.** It's per-path; it silently does the wrong
+  thing here. Leave renames alone (`--no-renames`).
+- **Counting merge commits' squashed diffs twice.** Add `--no-merges` if the repo
+  merges heavily and you want first-parent-ish churn; state it if you do.
+- **Trusting counts across strategies.** Strategy B counts are sample-proportional.
+  Compare *ranks*, never raw counts, between a full-scan and a sampled run.
+- **Forgetting the window is a knob.** 12 months is the default signal for "active
+  now"; widen it to learn a mature system's long-lived churn, narrow it to learn
+  what a team touched this quarter. Always report the window you used.

package/skills/runtime-exec/SKILL.md

@@ -21,7 +21,8 @@ or `py -3` based on what's available and handles macOS, Linux, and Windows
 in one call. Bare `python3` is not available on Windows.
 
 ```bash
-sh "${CLAUDE_PLUGIN_ROOT}/scripts/_python.sh" "${CLAUDE_PLUGIN_ROOT}/scripts/some/script.py"
+# "path/to/your_script.py" is a placeholder for the script to run
+sh "${CLAUDE_PLUGIN_ROOT}/scripts/_python.sh" "path/to/your_script.py"
 ```
 
 The detection logic below is reference material for skills that need a

package/skills/search/SKILL.md

@@ -47,7 +47,7 @@ graph via the drop-in TOML rules in
 | `narrate` | codebase orientation / architecture walkthrough | [codebase-narrator/SKILL.md](codebase-narrator/SKILL.md) |
 | `answer` | cited answer from the estate knowledge/memory stores | [refs/answer.md](refs/answer.md) |
 
-Doctrine / which-rules-apply: the **architecture wiki** is in the same stores — `knowledge.recall {"scope_prefix": "wiki:"}` + estate MCP `rules.recall` (cited); lifecycle: wicked-core `crates/wicked-governance/WIKI.md`.
+Doctrine / which-rules-apply: **Steering** (the governance rules, 7 steering types) is in the same stores — `knowledge.recall {"scope_prefix": "wiki:"}` (historical prefix) + estate MCP `rules.recall` (cited, read-only); management: wicked-core `crates/wicked-governance/STEERING.md`.
 
 ## Index / freshness (shared by every action)