wicked-garden 12.55.1 → 12.56.0

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, multi-model second opinions (fallback seats labelled). 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.55.1"}], "version": "12.55.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, multi-model second opinions (fallback seats labelled). 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.56.0"}], "version": "12.56.0"}

package/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "wicked-garden",
-  "version": "12.55.1",
+  "version": "12.56.0",
   "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), multi-model second opinions (fallback seats labelled) (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.8.0",
   "wicked_ledger_version": "^0.6.0",

package/CHANGELOG.md

@@ -2,6 +2,36 @@
 
 ## [Unreleased]
 
+## [12.56.0] — 2026-10-17
+
+### Added
+- **Operator memories and an explicit reach (needs wicked-estate with the operator scope).**
+  - How the user works (style, preferences, the extra steps they always take) is an operator memory. `mem-capture` stores it at `operator:local`, which every project's recall includes, so it is never pinned to one project.
+  - Every policy proposal now carries `payload.reach`: `operator` (every project), or `project` (that project or repo). A rule the user states defaults to `operator` unless they named a project. A rule repo-learn learns from a repo is `project`.
+  - `mem/refs/scopes.md` documents the operator scope and the reach vocabulary.
+
+### Fixed
+- **Session capture files standing rules for review instead of storing them as memory.** The
+  `mem-capture` worker swept "always use…", "never do…" and team conventions into the memory
+  batch, so an enforceable rule became a memory nobody approved. A standing rule the user stated
+  now goes to the review queue as a `policy:<type>` proposal (Step 3b); a preference that is not a
+  checkable rule stays a memory. The `mem` skill and `refs/scopes.md` say the same.
+- **repo-learn no longer files code-wiring facts as memory.** Its 2×2 map and "derive both"
+  guidance told the worker to record "how X wires up" as a memory, contradicting its own rule that
+  what is read from code is knowledge. Those findings are now `knowledge` proposals; a memory is
+  only what the worker witnessed or was told. The skill's summary and memory guidance say the
+  same, and a convention the team must follow is a policy. Its capture reference no longer
+  documents piping long JSON to `propose -` (the shim never read stdin).
+- **Onboarding records the detected languages, frameworks and tools as knowledge.** `core` setup
+  stored them as a `skill` memory; they are read from the repository, so they go through the mem
+  `write` action now.
+- **Answer synthesis takes "what should hold" from approved steering rules, not memory.** On a
+  conflict, `search` answer cited an operator memory as the ruling; an approved rule
+  (`rules.recall`) now governs, and a memory gives what was decided and why.
+
+### Changed
+- **The site's skill count is counted at build time, and the council is described as what it is.** `site/astro.config.mjs` counts `SKILL.md` under `skills/**` (`__WICKED_GARDEN_SKILLS__`), so the hero, the toolbox and the page description can no longer disagree (they said 143 and 142; the tree holds 138). The site no longer says "the multi-model council IS the router": a panel of other models settles a disputed decision. The hero drops "capability plane" for plain words, the README drops the retired Zed/ACP mention, and the npm description names every host it installs into (takes effect on the next publish).
+
 ## [12.55.1] — 2026-10-15
 
 ### Fixed
@@ -1135,7 +1165,8 @@ through `v9.2.18`. Major themes across that span:
 
 For each of those releases, see the corresponding tag in git history.
 
-[Unreleased]: https://github.com/mikeparcewski/wicked-garden/compare/v12.55.1...HEAD
+[Unreleased]: https://github.com/mikeparcewski/wicked-garden/compare/v12.56.0...HEAD
+[12.56.0]: https://github.com/mikeparcewski/wicked-garden/compare/v12.55.1...v12.56.0
 [12.55.1]: https://github.com/mikeparcewski/wicked-garden/compare/v12.55.0...v12.55.1
 [12.55.0]: https://github.com/mikeparcewski/wicked-garden/compare/v12.54.0...v12.55.0
 [12.54.0]: https://github.com/mikeparcewski/wicked-garden/compare/v12.53.3...v12.54.0

package/README.md

@@ -17,7 +17,7 @@
 
 ## The premise
 
-Coding agents grew up. Claude Code, Codex, Cursor, Antigravity, Aider, OpenCode, Zed/ACP — they're not autocomplete anymore. They plan. They parallelize. And each has *strong opinions* about how it likes to work.
+Coding agents grew up. Claude Code, Codex, Cursor, Antigravity, Aider, OpenCode — they're not autocomplete anymore. They plan. They parallelize. And each has *strong opinions* about how it likes to work.
 
 Most plugins try to boss them around — re-implement planning, impose a workflow, make the agent dance. You end up fighting your own tools.
 

package/package.json

@@ -1,8 +1,8 @@
 {
   "name": "wicked-garden",
-  "version": "12.55.1",
+  "version": "12.56.0",
   "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.",
+  "description": "The skills your coding agent can't build alone: \"done\" re-checked from evidence, graph-aware search and multi-file refactor, 40 QE specialists, review panels from other models, and cross-session memory. Works in Claude Code, Codex, Antigravity, OpenCode and Pi, in CI, or in a wicked-crew job.",
   "keywords": [
     "ai",
     "coding-agent",

package/skills/core/refs/setup.md

@@ -233,16 +233,16 @@ First, ask which directories to onboard. **INTERACTIVE mode**: native prompt wit
 
 **Hand-off** — open the `wicked-garden-mem` skill and run its `ingest` action with `{selected_directory}` as the argument; on Claude Code this is the Skill tool, on any other seat open the named skill from your catalog and carry it out inline, then continue here.
 
-**Step D — Store onboarding memory**. `{DETECTED_TOOLS_SUMMARY}` lists only available tools (e.g. "gh, docker"):
-**Hand-off** — open the `wicked-garden-mem` skill and run its `store` action with the memory text `Onboarding: {project} fully onboarded on {date}. Languages: {DETECTED_LANGS}. Frameworks: {DETECTED_FWS}. Tools available: {DETECTED_TOOLS_SUMMARY}.` and `kind=skill, about=[onboarding, project-context, {project}]`; on Claude Code this is the Skill tool, on any other seat open the named skill from your catalog and carry it out inline, then continue here.
+**Step D — Record the onboarding scan as knowledge**. `{DETECTED_TOOLS_SUMMARY}` lists only available tools (e.g. "gh, docker"). Languages, frameworks and tools were read from the repository, so they are knowledge, not memory:
+**Hand-off** — open the `wicked-garden-mem` skill and run its `write` action with content `{project} project context: languages {DETECTED_LANGS}; frameworks {DETECTED_FWS}; tools available {DETECTED_TOOLS_SUMMARY}.`, `class=concept` and `source={selected_directory}`; on Claude Code this is the Skill tool, on any other seat open the named skill from your catalog and carry it out inline, then continue here.
 
 Show: "Onboarding complete — knowledge store has {N} chunks (mem review reports totals)."
 
 #### 5.2 Quick Scout
 
-Ask which directories to scout (same question mode pattern as 5.1 — native prompt or plain text depending on mode). Then Glob/Read the key entry points and store an enriched onboarding memory with detected context from Step 5.0:
+Ask which directories to scout (same question mode pattern as 5.1 — native prompt or plain text depending on mode). Then Glob/Read the key entry points and record the detected context from Step 5.0 as knowledge (it was read from the repository):
 
-**Hand-off** — open the `wicked-garden-mem` skill and run its `store` action with the memory text `Onboarding: {project} quick-scouted on {date}. Languages: {DETECTED_LANGS}. Frameworks: {DETECTED_FWS}. Tools: {DETECTED_TOOLS_SUMMARY}. Full onboarding not yet run.` and `kind=skill, about=[onboarding, project-context, {project}]`; on Claude Code this is the Skill tool, on any other seat open the named skill from your catalog and carry it out inline, then continue here.
+**Hand-off** — open the `wicked-garden-mem` skill and run its `write` action with content `{project} project context (quick scout): languages {DETECTED_LANGS}; frameworks {DETECTED_FWS}; tools {DETECTED_TOOLS_SUMMARY}.`, `class=concept` and `source={project}`; on Claude Code this is the Skill tool, on any other seat open the named skill from your catalog and carry it out inline, then continue here.
 
 #### 5.3 Skip
 

package/skills/mem/SKILL.md

@@ -97,7 +97,9 @@ A chat seat asked by wicked-crew to label the operator's decisions reads
    (`{"content","class":"concept","source"}`) or `ingest` instead; `store`
    refuses content that carries a `source`.
 2. Pick `kind` (+ tier defaults): `fact` → semantic (decisions, gotchas,
-   stable facts) · `skill` → procedural (patterns, conventions, how-tos) ·
+   stable facts) · `skill` → procedural (patterns, how-tos; a convention the
+   team must follow is a rule: propose it as `policy:<type>`, see the
+   mem-capture worker's Step 3b) ·
    `entity` → semantic (a person/system profile). Add `about` tags for
    recall hooks.
 3. Run the backend:
@@ -117,7 +119,8 @@ A chat seat asked by wicked-crew to label the operator's decisions reads
 
 By default recall searches the current project (`project:<cwd-basename>`)
 and its ancestors, so root-scoped memories stay visible and other projects'
-memories do not leak in. Pass `"scope"` to recall another project the same
+memories do not leak in. Operator memories (`operator:<id>`, how the user
+works) are recalled in every project. Pass `"scope"` to recall another project the same
 way. Searching everything, brain-migrated leaves
 (`brain:<project>/doc:<id>`) included, is an explicit opt-in:
 `"scope_prefix": ""` (or `"scope_prefix": "project:<name>"` for one subtree). Items return content, scope, tier,
@@ -175,7 +178,12 @@ Dispatch the **wicked-garden-mem-capture** fork worker at session end ("
 capture what we learned", before /clear or exit). It sweeps the conversation
 for decisions, patterns, gotchas, discoveries, and preferences, classifies
 each onto the estate kind/tier vocabulary, and batch-writes them via
-`capture-batch`. Report what it stored.
+`capture-batch`. A standing rule the user stated ("always…", "never…") is
+filed as a `policy:<type>` proposal for review (reach `operator`, every
+project, unless they named a project), not stored as a memory. How the user
+works (style, preferences, standing extra steps) is an operator memory at
+`operator:local`, recalled in every project.
+Report what it stored and proposed.
 
 No hook extracts memories from the transcript. The Stop hook used to
 pattern-match "decided to…" / "going to…" and filled the store with

package/skills/mem/refs/scopes.md

@@ -14,8 +14,18 @@ project:wicked-garden
 org:acme/agent:claude
 brain:wicked-garden/doc:4f2a91
 project:wicked-estate/session:2026-08-11
+operator:local
 ```
 
+**Operator scope.** `operator:<id>` (`operator:local` by default) holds
+memories about how the operator works: style, preferences, the extra steps
+they always take. Every scoped recall includes it, whatever the project, so
+these follow the operator everywhere. A memory about a project's work stays
+at `project:<name>`. A rule the operator wants enforced is neither: it is a
+`policy:<type>` proposal. A proposal says which with `payload.reach`:
+`project`, `pattern`, or `operator`. For a policy it is `project` or
+`operator`.
+
 Rules of thumb:
 
 - **Store** under the narrowest scope that still makes the memory findable.
@@ -24,8 +34,9 @@ Rules of thumb:
 - **Recall** uses one of two filters (mutually exclusive on the wire):
   - `scope` — estate's ancestor-visible inheritance: memories at this scope
     plus those inherited from ancestor scopes. **The default**, at
-    `project:<cwd-basename>`, so a session sees its own project's memories
-    and root-scoped ones, never another project's.
+    `project:<cwd-basename>`, so a session sees its own project's memories,
+    root-scoped ones and operator memories (`operator:<id>`), never another
+    project's.
   - `scope_prefix` — subtree match: every memory whose scope equals the
     prefix or descends from it. `scope_prefix: ""` = the root subtree =
     **everything**. Opt-in only: pass it when the user asks to search
@@ -47,7 +58,7 @@ for review or cleanup).
 | Kind | Default tier | Store when… |
 |------|--------------|-------------|
 | `fact` | `semantic` | a decision, gotcha, or stable distilled fact ("we chose X because Y") |
-| `skill` | `procedural` | a pattern, convention, or how-to that gets reinforced by use |
+| `skill` | `procedural` | a pattern or how-to that gets reinforced by use (a convention the team must follow is a rule: a `policy:<type>` proposal, not a memory) |
 | `episode` | `episodic` | raw experience estate distills from; not a capture target (store the rule an event taught as a `fact`) |
 | `entity` | `semantic` | a profile of a person/system/component |
 | `working` | `working` | session-local scratch written by hooks; estate expires it after 24 h |
@@ -68,7 +79,8 @@ Brain's memory types map onto estate kinds as follows (used by
 |------------|-------------|------|
 | decision | `fact` | `semantic` |
 | pattern / procedural | `skill` | `procedural` |
-| preference | `fact` | `semantic` |
+| preference, style, standing extra step (how the operator works) | `fact` at `operator:local` | `semantic` |
+| standing rule ("always…", "never…") | none: a `policy:<type>` proposal | n/a |
 | gotcha | `fact` | `semantic` |
 | discovery | `fact` (the rule it taught) | `semantic` |
 

package/skills/mem-capture/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: wicked-garden-mem-capture
-description: "Session-teardown memory capture: sweep the conversation for durable learnings (decisions with a reason, patterns, gotchas, preferences), keep only what passes the durability test, classify each onto the estate kind/tier vocabulary, and batch-write them to wicked-estate memory. Use when: dispatched by the wicked-garden-mem skill's capture action, at session end, before /clear or exit, or when the user says 'capture what we learned' / 'remember this session'."
+description: "Session-teardown memory capture: sweep the conversation for durable learnings (decisions with a reason, patterns, gotchas, preferences), keep only what passes the durability test, classify each onto the estate kind/tier vocabulary, and batch-write them to wicked-estate memory; standing rules the user stated go to the review queue as policy proposals instead. Use when: dispatched by the wicked-garden-mem skill's capture action, at session end, before /clear or exit, or when the user says 'capture what we learned' / 'remember this session'."
 metadata:
   role: worker
 ---
@@ -26,9 +26,17 @@ Relative paths in this skill are relative to the directory that contains this SK
 Look for things the session *learned*, not things it *did*:
 
 - **Decisions with a reason**: "chose X over Y because…"
-- **Patterns / conventions**: "this always…", "the convention is…"
+- **Patterns**: "this always…" (how something behaves, witnessed)
 - **Gotchas**: "this broke because…", "don't X because…"
-- **Preferences** the user stated: "always use…", "never do…"
+- **Standing rules** the user wants ENFORCED on the work: "always use…",
+  "never do…", "the convention is…", something a change can be checked
+  against ("UI work is not done without a screenshot"). These are steering, not memory: Step 3b files them as policy
+  proposals for review.
+- **How the user works**: their style, preferences and the extra steps they
+  always take ("prefers tables in replies", "likes short commit subjects",
+  "usually opens the rendered page before reviewing CSS"). When the user
+  said it must be enforced, it is a standing rule instead. These are
+  **operator memories**: they apply in every project (Step 3).
 
 Then apply the **provenance test**: memory is what we *witnessed*, were
 *told*, or *decided*. What was read out of code, docs or the web is
@@ -74,14 +82,57 @@ applies), then map it onto the estate vocabulary
 | Finding | `kind` | tier (default) |
 |---------|--------|----------------|
 | decision, preference, gotcha, stable fact | `fact` | `semantic` |
-| pattern, convention, how-to | `skill` | `procedural` |
+| pattern, how-to | `skill` | `procedural` |
+
+A standing rule is not in this table: it goes to Step 3b, never to the
+memory batch.
 
 Events ("X happened when Y") are not memories. Keep only the rule the event
 taught, as a `fact`.
 
 Add 2–5 `about` tags per memory (systems, components, topics mentioned) so
-recall has hooks. Scope: leave the default (`project:<cwd-basename>`)
-unless the learning clearly belongs to another scope.
+recall has hooks.
+
+Scope follows what the memory is about:
+
+- **About this project or its code** (a decision, gotcha or pattern here):
+  leave the default (`project:<cwd-basename>`).
+- **About how the user works** (style, preferences, standing extra steps):
+  pass `"scope": "operator:local"`. Every project's recall includes the
+  operator scope, so the memory follows the user everywhere. Never pin an
+  operator memory to one project.
+
+## Step 3b — standing rules go to review as policy proposals
+
+A rule the user stated for the work ("always use X", "never do Y", "the
+convention is Z") is enforceable: a reviewer can judge a change against it.
+That makes it steering, and steering is approved by a person before it
+applies. Do not write it as a memory. File one proposal per rule through the
+estate shim's `propose` action (the review queue; nothing applies until the
+user approves it):
+
+```bash
+wicked-garden run scripts/_estate_client.py --readonly propose '{"kind_type":"policy:development","payload":{"rule":"<imperative: what must hold>","severity":"warn","capture":"rule","reach":"operator"},"facets":{"project":"<project>"}}'
+```
+
+- `kind_type` is `policy:<type>`, with `<type>` exactly one of
+  `architecture`, `development`, `security`, `testing`, `operations`,
+  `compliance` or `design-ux`.
+- `severity` is exactly one of `info`, `warn`, `error` or `critical`.
+- `reach` says where the rule applies. A rule the user states is theirs
+  for **every** project: `"reach": "operator"`. Use `"reach": "project"`
+  only when they named this project or one of its repos (add `repo` to the
+  facets for a repo). The reviewer sees the reach and can change it; never
+  leave it out.
+- `facets.project` is required (the shim refuses a proposal without it). It
+  records where the rule was said; with `"reach": "operator"` it does not
+  narrow the rule.
+- Never pass `provenance`.
+
+Store a pointer memory only when the *reason* for the rule is worth
+recalling on its own ("we ban X because incident Y"). The rule itself lives
+in the proposal. If the shim answers `ok: false`, report the rule text and
+the degrade; never fall back to storing it as a memory.
 
 ## Step 4 — batch write
 
@@ -90,7 +141,8 @@ One backend call, JSON on stdin (never argv — summaries contain quotes):
 ```bash
 printf '%s' '{"memories":[
   {"content":"<summary 1>","kind":"fact","about":["tag1","tag2"]},
-  {"content":"<summary 2>","kind":"skill","about":["tag3"]}
+  {"content":"<summary 2>","kind":"skill","about":["tag3"]},
+  {"content":"<how the user works>","kind":"fact","about":["style"],"scope":"operator:local"}
 ]}' | wicked-garden run \
   scripts/mem/estate_memory.py capture-batch -
 ```
@@ -112,6 +164,7 @@ wicked-garden run \
 ## Step 6 — report
 
 - `{N} memories stored` (+ `{K} failed` if any, with each refusal reason), with kinds
+- `{P} rules proposed for review` (Step 3b), with each proposal id
 - one-line topic list
 - if estate was unreachable (`ok: false`): report the degrade explicitly so
   the learnings can be re-captured later — never claim success on a

package/skills/repo-learn/SKILL.md

@@ -4,7 +4,7 @@ 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
+  (knowledge) and what should hold (policies) — as inert estate proposals a human
   reviews, never as asserted fact.
 
   Three BOUNDED phases, one wicked-crew unit each: (1) CHURN — sampled git churn →
@@ -28,8 +28,8 @@ metadata:
 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
+learning back** as estate proposals — knowledge (what is true, read from the code) and
+policies (what should hold); a memory only for what you witnessed or were told. Garden ORCHESTRATES; estate GROUNDS (graph + read) and RECEIVES (the proposal
 queue); a human APPROVES — every capture is an inert proposal the studio Memories /
 Policies surfaces review, never an asserted fact.
 
@@ -97,7 +97,7 @@ 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 |
+| **High centrality**   | load-bearing + volatile → **read deeply**; likely yields BOTH knowledge (how it works / why it moves, read from the code) AND a policy (what must hold as it changes) | stable core → **read for invariants**; yields policies (severity `error`/`critical`) more than knowledge |
 | **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
@@ -148,18 +148,21 @@ when the proposal is approved, so the learning is lost):
   knowledge. `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>"}`.
+  learning use `semantic` (a decision or gotcha) or `procedural` (a how-to you were
+  taught); NEVER invent a tier like `durable`. A convention or rule the team must
+  follow ("our convention is always X") is a **policy**, never a memory. 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
+  design-ux; payload `{"rule": "<imperative>", "severity": "<value>", "reach": "project"}`
+  (a rule learned from this repo applies to its project) 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.
+- Derive **both** per target where the 2×2 warrants it: the knowledge record
+  holds the *is*, the policy holds the *ought*. A stable high-centrality
+  invariant is a policy; a "this is how X actually wires up" discovery was read
+  from the code, so it is knowledge, never a memory.
 
 ## In a governed run
 
@@ -187,7 +190,7 @@ default; the shim refuses an unpinned store — report that, never guess one.
    call, no variants, no wrappers (governed-worker A2/A5). The read-only CLI is still
    allowed by the fence but is not a documented rung.
 2. **Capture** (phase 3) submits each proposal through the shim —
-   `wicked-garden run scripts/_estate_client.py --readonly propose '{"kind_type":"memory","payload":{…},"facets":{…}}'`
+   `wicked-garden run scripts/_estate_client.py --readonly propose '{"kind_type":"knowledge","payload":{…},"facets":{…}}'`
    (`proposal.submit`; provenance is server-stamped from the `WICKED_RUN_*` markers on your
    environment, never passed). **There is no deliverable file and no file fallback**: write
    nothing into the repository (governed-worker E1) and nothing elsewhere either. If the shim

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

@@ -1,4 +1,4 @@
-# Capture — memories AND policies as estate proposals
+# Capture — knowledge, memories AND policies as estate proposals
 
 The learning phase ends by writing back records through the estate
 **`proposal.submit`** tool (reached through the estate shim): **knowledge** (how the
@@ -17,7 +17,7 @@ the record; a human promotes it.
 
 | Field | Type | Rule |
 |-------|------|------|
-| `kind_type` | string | `"memory"` OR `"policy:<type>"`; must match `^[a-z][a-z0-9_-]*(:[a-z][a-z0-9_-]*)?$` |
+| `kind_type` | string | `"knowledge"`, `"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 | each axis is a lowercase token `^[a-z][a-z0-9_-]*$`, each value non-empty; `project` is **required** (the shim refuses a proposal without it) |
 
@@ -36,7 +36,7 @@ The estate shim reaches `proposal.submit` without an MCP server being registered
 with your harness, on every seat CLI:
 
 ```bash
-wicked-garden run scripts/_estate_client.py --readonly propose '{"kind_type":"memory","payload":{"content":"…","tier":"semantic"},"facets":{"repo":"<name>","project":"<name>"}}'
+wicked-garden run scripts/_estate_client.py --readonly propose '{"kind_type":"knowledge","payload":{"content":"…","class":"concept","source":"<repo>:<path>","source_rev":"<sha>"},"facets":{"repo":"<name>","project":"<name>"}}'
 ```
 
 `--readonly` is literal (the shim spawns `wicked-estate-mcp --readonly`; `proposal.submit`
@@ -45,8 +45,9 @@ is the safe write it still permits). The store is pinned from the worker environ
 unpinned store is refused with `{"ok": false, "reason": …}` — report it, do not guess a
 store. The shim answers `{"ok": true, "id": "<proposal-id>"}` or `{"ok": false,
 "reason": …, "code": <json-rpc code or null>}`: `-32602` is a *your-args* bug (fix the
-shape), `null` means the estate was unreachable (keep the objects — next section). Long
-JSON: pass `-` as the json-args and pipe it on stdin. A `provenance` key is dropped.
+shape), `null` means the estate was unreachable (keep the objects — next section). Pass
+the JSON as ONE quoted argument, even when it is long: `propose` does not read stdin. A
+`provenance` key is dropped.
 
 ### When `propose` fails in a governed run — no file fallback
 
@@ -113,10 +114,11 @@ implementation fails closed" is knowledge.
 - `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").
+- `tier` — `"semantic"` for a decision or gotcha you witnessed or were told
+  ("the bus path was chosen over a direct call because direct calls dropped
+  events in incident X"); `"procedural"` for a how-to you were taught. How the
+  code is wired ("X is wired via the bus") was read from the code: that is a
+  `knowledge` proposal, not a memory.
 - `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`). **`project:` is required** on every proposal,
@@ -133,7 +135,7 @@ implementation fails closed" is knowledge.
 ```json
 {
   "kind_type": "policy:architecture",
-  "payload": { "rule": "<imperative statement of what must hold>", "severity": "error" },
+  "payload": { "rule": "<imperative statement of what must hold>", "severity": "error", "reach": "project" },
   "facets": { "repo": "<repo-name>", "project": "<project-name>", "language": "<lang>" }
 }
 ```
@@ -142,6 +144,9 @@ implementation fails closed" is knowledge.
   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*.
+- `reach` — `"project"`: a rule learned from this repo applies to this
+  repo's project. (`"operator"` = every project is for rules the operator
+  states, not for what a repo teaches.)
 - `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.
@@ -156,16 +161,17 @@ 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") |
+| **high churn + high centrality** | load-bearing and moving | **BOTH**: knowledge (how it works / what it wires, read from the code) + 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 knowledge only if the *why* is non-obvious from the code, and a memory only if the operator told you the why |
+| **high churn + low centrality** | churny periphery | usually **neither**; knowledge 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.
+The discipline: knowledge records the **is** (this is how the system is, read
+from the code), a policy records the **ought** (this is what a change must
+preserve). A single load-bearing target frequently yields one of each — the
+knowledge so the next reader understands it, the policy so the next editor
+doesn't break it. A memory is only for what you witnessed or were told.
+Do not force a proposal from a cell that says skip; a thin capture pollutes the queue the operator must triage.
 
 ## Worked examples
 
@@ -191,7 +197,8 @@ Policy (architecture, from the same subsystem's invariant):
   "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"
+    "severity": "error",
+    "reach": "project"
   },
   "facets": { "repo": "wicked-estate", "project": "wicked", "language": "rust" }
 }
@@ -204,7 +211,8 @@ Policy (development, language-scoped, from a stable core with a clear guardrail)
   "kind_type": "policy:development",
   "payload": {
     "rule": "Rust: no bare panic!/unwrap in library crates; surface a typed error.",
-    "severity": "warn"
+    "severity": "warn",
+    "reach": "project"
   },
   "facets": { "repo": "wicked-estate", "project": "wicked", "language": "rust" }
 }

package/skills/search/refs/answer.md

@@ -41,9 +41,10 @@ every project, on explicit request); `--budget <tokens>`
      `[knowledge · src docs/adr/0005.md]` or
      `[memory · fact · 2026-10-10 · project:wicked-garden]`, so the reader
      sees which side it came from and how old it is
-   - on conflict, an operator ruling (memory) governs what *should* hold and
-     the source (knowledge) governs what *does*: show the disagreement, never
-     pick silently by date
+   - on conflict, an approved steering rule (estate `rules.recall`) governs
+     what *should* hold and the source (knowledge) governs what *does*; a
+     memory says what was decided or told and why, not what is enforced.
+     Show the disagreement, never pick silently by date
 
    End with a `Sources:` list — every distinct `source` / scope used, so
    the reader can verify each claim.