wicked-garden 12.55.0 → 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.0"}], "version": "12.55.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, 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,8 +1,8 @@
 {
   "name": "wicked-garden",
-  "version": "12.55.0",
+  "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.5.0",
+  "wicked_vault_version": ">=0.8.0",
   "wicked_ledger_version": "^0.6.0",
   "wicked_bus_version": "^2.0.0",
   "author": {

package/CHANGELOG.md

@@ -2,6 +2,42 @@
 
 ## [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
+- **Bump the `wicked-vault` peer floor to `>= 0.8.0` and drop stale "unreleased manifest-2.1 twin" notes (garden#1309).** `.claude-plugin/plugin.json` now declares `"wicked_vault_version": ">=0.8.0"` (replacing `"^0.5.0"`, whose `0.x` caret excluded every later minor), in lockstep with `scripts/loom/manifest.py` (`version_pin="0.8"`) and every `<!-- vault-floor -->` doc/skill restatement. `VAULT_RELEASE_REQUIREMENT` in `scripts/qe/lib/vault-evidence.mjs` and the QE docs/help strings now point to `npm i -g wicked-vault@latest` (the manifest-2.1 twin shipped in 0.7.0; 0.8.0 is the current floor).
+- **The plugin's Python range stops below 3.15 until its dependencies ship 3.15 wheels.** `pydantic-core` (via `pydantic`) has no CPython 3.15 wheel. A 3.15 default interpreter (the macOS GitHub runners and Homebrew `python@3.15`) made `uv sync` build it from source with Rust, which fails without a toolchain. That blocked wicked-crew's first skills publish (its release smoke S02 on macOS, and any 3.15-only host without Rust). `requires-python` is now `>=3.10,<3.15` (uv.lock relocked at the same lock revision), so uv picks or downloads a 3.14. Lift the bound once pydantic-core publishes cp315 wheels.
+
 ## [12.55.0] — 2026-10-14
 
 ### Added
@@ -1129,7 +1165,9 @@ 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.0...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
 [12.53.3]: https://github.com/mikeparcewski/wicked-garden/compare/v12.53.2...v12.53.3

package/CONTRIBUTING.md

@@ -29,7 +29,7 @@ uv run pytest tests/ -x
 
 **For offline CI and dev environments without the wicked-vault peer only.**
 
-wicked-vault (npm, ≥ 0.5.0 <!-- vault-floor -->, install `npm i -g wicked-vault`)
+wicked-vault (npm, ≥ 0.8.0 <!-- vault-floor -->, install `npm i -g wicked-vault`)
 is the one required peer (the loom engine is built into the garden; bus is an
 opt-in layer). The garden's produces-gates re-derive
 evidence through the built-in loom engine — `scripts/qe/vault_gate.py` runs

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.
 
@@ -86,7 +86,7 @@ Then, in a Claude Code session:
 **One required peer, the rest opt-in.** The evidence gate is the floor we won't fake, so it needs one external peer — setup blocks without it:
 
 ```bash
-npm i -g wicked-vault          # wicked-vault (≥ 0.5.0), the honest-evidence backend the gate re-derives against
+npm i -g wicked-vault          # wicked-vault (≥ 0.8.0), the honest-evidence backend the gate re-derives against
 ```
 
 > The gate/resolve engine (formerly the separate `wicked-loom` package) is now **absorbed in-package** as of v12.27.0 (`scripts/loom/`) — nothing extra to install. The gate re-hashes recorded evidence and re-runs its verifier through that engine; a false "tests pass" is **rejected**, a missing backend **fails closed**.
@@ -170,7 +170,7 @@ Full author guide: [`docs/extending.md`](docs/extending.md).
 
 ## Requirements
 
-A coding-agent harness ([Claude Code](https://docs.anthropic.com/en/docs/claude-code/overview) ≥ 1.0 for the plugin surface; the peers + compiled gate are harness-agnostic) · Python 3.9+ (stdlib-only hooks) · Node + `npx` · the gate's one required peer (`wicked-vault` ≥ 0.5.0) plus opt-in layers (`wicked-estate` · `wicked-bus`).
+A coding-agent harness ([Claude Code](https://docs.anthropic.com/en/docs/claude-code/overview) ≥ 1.0 for the plugin surface; the peers + compiled gate are harness-agnostic) · Python 3.9+ (stdlib-only hooks) · Node + `npx` · the gate's one required peer (`wicked-vault` ≥ 0.8.0) plus opt-in layers (`wicked-estate` · `wicked-bus`).
 
 ## License
 

package/docs/extending.md

@@ -51,7 +51,7 @@ A complete working example (used as garden's own e2e fixture):
       ]
     }
   ],
-  "peers": { "wicked-garden": ">=12.0.0", "wicked-vault": ">=0.5.0" },
+  "peers": { "wicked-garden": ">=12.0.0", "wicked-vault": ">=0.8.0" },
   "provenance": { "source": "https://github.com/acme/acme-seo-pack", "publisher": "acme" }
 }
 ```

package/docs/required-peers.md

@@ -18,7 +18,7 @@ works.
 
 | Peer | What it does | Install |
 |------|--------------|---------|
-| **wicked-vault** | The honest-evidence backend the gate re-derives against: record → re-hash + re-run the verifier → cross-check. Never trusts a cached status. | `npm i -g wicked-vault` — puts the `wicked-vault` binary on PATH (optionally run `wicked-vault-install` afterwards to copy the vault skills into your AI CLIs). Declared floor: **≥ 0.5.0** <!-- vault-floor --> (on 0.4.x or older, upgrade with `npm i -g wicked-vault@latest` — the peer registry's health probe, `loom doctor` / the peer-health command, reports a below-floor vault as `drift` and fails its check). Resolved at runtime via `WICKED_VAULT_BIN` → config → `PATH` → `node_modules` → `npx wicked-vault`. |
+| **wicked-vault** | The honest-evidence backend the gate re-derives against: record → re-hash + re-run the verifier → cross-check. Never trusts a cached status. | `npm i -g wicked-vault` — puts the `wicked-vault` binary on PATH (optionally run `wicked-vault-install` afterwards to copy the vault skills into your AI CLIs). Declared floor: **≥ 0.8.0** <!-- vault-floor --> (below 0.8.0, upgrade with `npm i -g wicked-vault@latest` — the peer registry's health probe, `loom doctor` / the peer-health command, reports a below-floor vault as `drift` and fails its check). Resolved at runtime via `WICKED_VAULT_BIN` → config → `PATH` → `node_modules` → `npx wicked-vault`. |
 
 The core skill's `setup` action (`/wicked-garden-core setup`) **blocks** without
 it — a toolkit whose headline is "done is re-derived, not asserted" cannot ship
@@ -35,7 +35,7 @@ single source of truth; every doc restatement of the number is tagged with a
 `<!-- vault-floor -->` marker (README's bash-comment restatement can't carry an
 HTML comment, so grep the number too). **To bump the floor:** change
 `manifest.py` + `plugin.json`, then
-`grep -rn "vault-floor\|0\.5\.0" README.md CONTRIBUTING.md docs/ skills/` and
+`grep -rn "vault-floor\|0\.8\.0" README.md CONTRIBUTING.md docs/ skills/` and
 update every tagged restatement in the same commit.
 
 ## The built-in gate engine (loom) — nothing to install

package/package.json

@@ -1,8 +1,8 @@
 {
   "name": "wicked-garden",
-  "version": "12.55.0",
+  "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/pyproject.toml

@@ -7,7 +7,11 @@ name = "wicked-garden"
 # not bump it — PEP 621 requires a value, so it is pinned to the placeholder 0.0.0 (mirrored in uv.lock).
 version = "0.0.0"
 description = "AI-Native SDLC delivered as a single Claude Code plugin"
-requires-python = ">=3.10"
+# <3.15 (garden 12.55.1): pydantic-core (via pydantic) ships no CPython 3.15 wheel yet, so a 3.15
+# default interpreter (macOS runners and Homebrew since 2026-10) made `uv sync` build it from source
+# with Rust — which fails without a toolchain, blocking crew's first skills publish. With the bound,
+# uv picks (or downloads) a 3.14. Lift it once pydantic-core publishes cp315 wheels.
+requires-python = ">=3.10,<3.15"
 dependencies = [
     "rapidfuzz>=3.0",
     "aiofiles>=23.0",

package/schemas/wicked-pack.schema.json

@@ -107,7 +107,7 @@
     },
     "peers": {
       "type": "object",
-      "description": "Peer version floors (extension-contract gap 6), e.g. {\"wicked-garden\": \">=12.29.0\", \"wicked-vault\": \">=0.5.0\"}. Checked FAIL-OPEN: violations are surfaced at SessionStart and by `pack floors`, never blocked on.",
+      "description": "Peer version floors (extension-contract gap 6), e.g. {\"wicked-garden\": \">=12.29.0\", \"wicked-vault\": \">=0.8.0\"}. Checked FAIL-OPEN: violations are surfaced at SessionStart and by `pack floors`, never blocked on.",
       "additionalProperties": { "type": "string", "pattern": "^(>=|\\^)\\s*\\d+\\.\\d+\\.\\d+$" }
     },
     "provenance": {

package/scripts/_pack_registry.py

@@ -28,7 +28,7 @@ skills tree. There is NO signing — the hashes detect post-registration drift,
 they do not prove authorship. See docs/extending.md "Trust model".
 
 Peer floors (gap 6, fail-open): a pack may declare ``peers`` —
-``{"wicked-garden": ">=12.29.0", "wicked-vault": ">=0.5.0"}``.
+``{"wicked-garden": ">=12.29.0", "wicked-vault": ">=0.8.0"}``.
 ``check_peer_floors()`` compares floors against what is actually installed
 and returns violations as data. It NEVER raises and never blocks: an
 unprobeable peer reports status "unknown", not a violation.

package/scripts/loom/manifest.py

@@ -94,10 +94,11 @@ PEERS: dict = {
         name="vault",
         npm_package="wicked-vault",
         env_var="WICKED_VAULT_BIN",
-        # 0.5 floor (Phase 6c): vault >= 0.5.0 stamps bus events with the qe
-        # domain (0.4 floor was the hard-gate attest baseline). Keep this
-        # MAJOR.MINOR floor in lockstep with plugin.json's ``wicked_vault_version``.
-        version_pin="0.5",
+        # 0.8 floor: the manifest-2.1 twin the QE evidence flow needs shipped
+        # in 0.7.0, and 0.8.0 enforces contract pins and re-validates
+        # attestations. Keep this MAJOR.MINOR floor in lockstep with
+        # plugin.json's ``wicked_vault_version``.
+        version_pin="0.8",
         # wicked-vault is a DIRECT infra peer, published from its own repo
         # (mikeparcewski/wicked-vault): self-contained, zero runtime deps. Install
         # it directly. ``npm i -g wicked-vault``

package/scripts/qe/lib/gate.mjs

@@ -73,10 +73,10 @@
  *   - A bundle that failed manifest validation (downgraded above) is NOT
  *     vaulted — the downgraded INCONCLUSIVE verdict records with
  *     `vault: {skipped}` instead (never freeze a nonconforming bundle).
- *   - Release dependency: needs the wicked-vault manifest-2.1 twin —
- *     UNRELEASED (npm 0.6.0 predates it). Until the next wicked-vault
- *     release, `WICKED_QE_VAULT_PKG` must point at a local checkout of
- *     wicked-vault main; a pre-2.1 vault is refused fail-closed.
+ *   - Release dependency: needs wicked-vault >= 0.8.0 (the manifest-2.1 twin
+ *     shipped in 0.7.0; garden's floor is 0.8.0). An older vault is refused
+ *     fail-closed — upgrade with `npm i -g wicked-vault@latest` (or set
+ *     `WICKED_QE_VAULT_PKG` to point at a specific 0.8.0+ install).
  */
 
 import { existsSync, readdirSync, readFileSync } from "node:fs";
@@ -339,7 +339,8 @@ export async function runGate({ projectId, runId, verdict, verdictSummary, ratio
   // 2c. TH-17: resolve wicked-vault up front when vault integrity was asked
   //     for — fail fast (exit 3) on an unresolvable or pre-2.1 vault, BEFORE
   //     anything is written anywhere. The refusal message carries the release
-  //     dependency (the manifest-2.1 twin is unreleased; npm 0.6.0 predates it).
+  //     dependency (the manifest-2.1 twin shipped in 0.7.0; floor is 0.8.0 —
+  //     upgrade with `npm i -g wicked-vault@latest`).
   const wantsVault = Boolean(vaultRecord || vaultEntry);
   let vaultModule = null;
   if (wantsVault) {
@@ -556,8 +557,9 @@ Optional:
                             (content-addressed) and attest the verdict as the reviewer's
                             opinion; the verdicts row carries vault_payload_sha. REFUSES
                             unredacted bundles (TH-19 ordering) — exit 3, nothing recorded.
-                            Needs the wicked-vault manifest-2.1 twin (unreleased; set
-                            WICKED_QE_VAULT_PKG to a wicked-vault main checkout until then)
+                            Needs wicked-vault >= 0.8.0 (the manifest-2.1 twin shipped in
+                            0.7.0; upgrade with \`npm i -g wicked-vault@latest\`, or set
+                            WICKED_QE_VAULT_PKG to a specific 0.8.0+ install)
   --vault-entry <id>        TH-17: link an already-vaulted bundle instead of recording;
                             re-derived fail-closed before the verdict is recorded
   --vault-actor <id>        Recording (worker) identity for --vault-record (default: qe-runner)

package/scripts/qe/lib/vault-evidence.mjs

@@ -44,12 +44,10 @@
  *
  * RELEASE DEPENDENCY (documented, enforced by `resolveVaultModule`):
  * this flow needs the wicked-vault manifest-2.1 twin (`validateManifest` +
- * `CLAIM_LEVELS` exports — on wicked-vault main, UNRELEASED as of
- * 2026-08-30; npm wicked-vault 0.6.0 predates it and its vendored schema
- * rejects every 2.1 bundle). Until the next wicked-vault release, point
- * `WICKED_QE_VAULT_PKG` at a local checkout of wicked-vault main (or
- * `npm link` it); a pre-2.1 vault is refused fail-closed, never silently
- * degraded.
+ * `CLAIM_LEVELS` exports, shipped in wicked-vault 0.7.0; garden's floor is
+ * 0.8.0). An older vault is refused fail-closed, never silently degraded —
+ * upgrade with `npm i -g wicked-vault@latest` (or set `WICKED_QE_VAULT_PKG`
+ * to point at a specific wicked-vault 0.8.0+ install).
  *
  * CLI (from the target repo's root):
  *   node vault-evidence.mjs record   --evidence-dir <dir> [--repo-root <dir>]
@@ -75,10 +73,9 @@ import { scanForSecrets, compileExtraPatterns } from "../runner/src/redact.mjs";
 
 /** The one-line release dependency, stamped on every pre-2.1 refusal. */
 export const VAULT_RELEASE_REQUIREMENT =
-  "wicked-vault with the manifest-2.1 twin (validateManifest + CLAIM_LEVELS) is required — " +
-  "on wicked-vault main but UNRELEASED (npm 0.6.0 predates it and rejects 2.1 bundles). " +
-  "Until the next wicked-vault release: set WICKED_QE_VAULT_PKG to a local checkout of " +
-  "wicked-vault main, or `npm link wicked-vault` from one.";
+  "wicked-vault >= 0.8.0 is required (the manifest-2.1 twin, validateManifest + CLAIM_LEVELS, " +
+  "shipped in 0.7.0) — upgrade with `npm i -g wicked-vault@latest`, or set WICKED_QE_VAULT_PKG " +
+  "to a wicked-vault 0.8.0+ install.";
 
 /** Typed refusal so callers (gate.mjs, tests) can tell WHY the write was refused. */
 export class VaultEvidenceError extends Error {
@@ -116,9 +113,9 @@ function esmEntryForPackage(resolvedFile) {
 
 /**
  * Capability gate: is this module a wicked-vault WITH the manifest-2.1 twin?
- * npm 0.6.0 has record/attest/verify but NOT validateManifest/CLAIM_LEVELS —
- * that is the unreleased seam this flow depends on (see
- * VAULT_RELEASE_REQUIREMENT). Exported for tests.
+ * The twin (`validateManifest` + `CLAIM_LEVELS`) shipped in wicked-vault 0.7.0
+ * and garden's floor is 0.8.0; an older vault without those exports is refused
+ * fail-closed (see VAULT_RELEASE_REQUIREMENT). Exported for tests.
  */
 export function checkVaultCapability(mod) {
   if (!mod || typeof mod !== "object") return { ok: false, reason: "not a module" };
@@ -135,8 +132,8 @@ export function checkVaultCapability(mod) {
 
 /**
  * Resolve the wicked-vault module, fail-closed on capability:
- *   1. `WICKED_QE_VAULT_PKG` env — path to a wicked-vault package dir (or its
- *      entry file). The documented bridge until the next vault release.
+ *   1. `WICKED_QE_VAULT_PKG` env — optional pointer to a specific wicked-vault
+ *      package dir (or its entry file).
  *   2. bare `import("wicked-vault")` (global / hoisted install).
  *   3. the target repo's node_modules (cwd-anchored resolution).
  * A resolved-but-pre-2.1 vault is a refusal, not a fallback.
@@ -551,9 +548,10 @@ Subcommands:
             Re-derive the bundle months later: vault hashes + every artifact
             re-hashed on disk. Exit 1 on ANY divergence.
 
-wicked-vault resolution: WICKED_QE_VAULT_PKG (local checkout — required until
-the next wicked-vault release ships the manifest-2.1 twin) → global install →
-the repo's node_modules. A pre-2.1 vault is refused fail-closed.
+wicked-vault resolution: WICKED_QE_VAULT_PKG (optional pointer to a specific
+wicked-vault 0.8.0+ install) → global install → the repo's node_modules. An
+older vault without the manifest-2.1 twin (shipped in 0.7.0; floor 0.8.0) is
+refused fail-closed — upgrade with \`npm i -g wicked-vault@latest\`.
 
 Exit codes: 0 ok · 1 rederive divergence · 3 refusal / usage / system error.
 `;

package/scripts/qe/runner/README.md

@@ -218,12 +218,11 @@ the reviewer's grade appended as an opinion attestation — see
 --vault-record`. The vault payload is `manifest.json` (content-addressed; it
 binds every artifact's sha256), so a campaign PASS re-derives months later.
 **Release dependency:** the flow needs the wicked-vault manifest-2.1 twin
-(`validateManifest` + `CLAIM_LEVELS`) — on wicked-vault main, **unreleased**
-(npm 0.6.0 predates it and its vendored schema rejects 2.1 bundles). Until
-the next wicked-vault release, set `WICKED_QE_VAULT_PKG` to a local checkout
-of wicked-vault main (or `npm link` one); a pre-2.1 vault is refused
-fail-closed. The `th17-vault-evidence` tests skip with that exact message
-when no 2.1 vault is resolvable.
+(`validateManifest` + `CLAIM_LEVELS`), which shipped in wicked-vault 0.7.0;
+garden's floor is 0.8.0. An older vault is refused fail-closed — upgrade with
+`npm i -g wicked-vault@latest` (or set `WICKED_QE_VAULT_PKG` to point at a
+specific wicked-vault 0.8.0+ install). The `th17-vault-evidence` tests skip
+with that message when no 2.1-capable vault is resolvable.
 
 ## Tests
 

package/scripts/qe/runner/test/th17-vault-evidence.test.mjs

@@ -15,11 +15,11 @@
  *      refusal happens in code, not in docs.
  *
  * Release dependency (documented in vault-evidence.mjs): these tests need
- * the wicked-vault manifest-2.1 twin, which is on wicked-vault main but
- * UNRELEASED (npm 0.6.0 predates it). Until the next wicked-vault release,
- * set WICKED_QE_VAULT_PKG to a local checkout of wicked-vault main; without
- * one the vault-dependent tests SKIP with that exact message (the pure
- * mapping/capability tests still run).
+ * the wicked-vault manifest-2.1 twin (shipped in wicked-vault 0.7.0;
+ * garden's floor is 0.8.0). An older vault is refused fail-closed — upgrade
+ * with `npm i -g wicked-vault@latest` (or set WICKED_QE_VAULT_PKG to point
+ * at a specific 0.8.0+ install); without one the vault-dependent tests SKIP
+ * with that message (the pure mapping/capability tests still run).
  */
 
 import test from "node:test";
@@ -149,7 +149,7 @@ test("checkVaultCapability: a pre-2.1 vault is refused WITH the release requirem
   const r = checkVaultCapability(pre21);
   assert.equal(r.ok, false);
   assert.equal(r.pre21, true);
-  assert.match(r.reason, /UNRELEASED/);
+  assert.match(r.reason, /0\.8\.0/);
   assert.match(r.reason, /WICKED_QE_VAULT_PKG/);
   // and a non-vault module is a different refusal (not "release the vault")
   const notVault = checkVaultCapability({ record: fn });

package/skills/archetype/refs/incident.md

@@ -76,7 +76,7 @@ confirming the bleeding stopped. Don't skip to followup before resolve.
 2. **Confirm the bleeding stopped.** Watch the same dashboards that
    surfaced the incident. Don't declare mitigated based on logs alone.
 3. Record the mitigation as re-derivable evidence (vault present;
-   **wicked-vault ≥ 0.5.0** <!-- vault-floor -->):
+   **wicked-vault ≥ 0.8.0** <!-- vault-floor -->):
    `wicked-vault record --scope <scope> --phase incident --claim mitigation
    --kind mitigation-check --source "<the symptom-check command>"
    --criteria "symptom check passes post-mitigation"
@@ -106,7 +106,7 @@ confirming the bleeding stopped. Don't skip to followup before resolve.
 2. Use `wicked-garden-qe-incident-to-scenario-synthesizer` to convert the
    incident into a regression scenario that would catch the same break.
 3. Track action items in github. Don't bury them in a Slack thread.
-4. Record the docs evidence (vault present; **wicked-vault ≥ 0.5.0** <!-- vault-floor -->):
+4. Record the docs evidence (vault present; **wicked-vault ≥ 0.8.0** <!-- vault-floor -->):
    `wicked-vault record --scope <scope> --phase incident --claim rca
    --kind doc --artifact docs/postmortems/INC-{N}.md
    --criteria "required RCA sections present"

package/skills/archetype/refs/migrate.md

@@ -83,7 +83,7 @@ them mid-cutover. Absent? Discover it the usual way — and consider
    the old shape.
 3. Land + deploy expand. Don't combine with backfill.
 4. Record the **shape-change** as re-derivable evidence (vault present;
-   **wicked-vault ≥ 0.5.0** <!-- vault-floor -->):
+   **wicked-vault ≥ 0.8.0** <!-- vault-floor -->):
    `wicked-vault record --scope <scope> --phase migrate --claim shape-change
    --kind schema-state --source "<migration-applied verification>"
    --criteria "<the post-condition>" --verifier exit_code_eq:0

package/skills/archetype/refs/modernize.md

@@ -141,7 +141,7 @@ core's fail-closed build. See `skills/domain/SKILL.md`.
 2. Harden the result with `code-modernization:modernize-harden` (security/CVEs,
    error handling) before it carries traffic.
 3. Record the parity proof as re-derivable evidence (vault present; **wicked-vault
-   ≥ 0.5.0** <!-- vault-floor -->):
+   ≥ 0.8.0** <!-- vault-floor -->):
    `wicked-vault record --scope <scope> --phase modernize --claim parity-proof
    --kind differential --source "<the differential harness command>"
    --criteria "old(input) == new(input) on seeded data" --verifier exit_code_eq:0

package/skills/archetype/refs/review.md

@@ -121,7 +121,7 @@ in three domains").
 4. Append to the audit log with `wicked-garden run scripts/qe/verdict_audit.py append`
    so the verdict is replayable.
    Then record both produces as re-derivable evidence (vault present;
-   **wicked-vault ≥ 0.5.0** <!-- vault-floor -->):
+   **wicked-vault ≥ 0.8.0** <!-- vault-floor -->):
    `wicked-vault record --scope <scope> --phase review --claim verdict
    --kind verdict --source "<verdict.json>" --criteria "<the bar>"
    --verifier exit_code_eq:0 --actor "${WICKED_VAULT_ACTOR:-garden-prove}"

package/skills/archetype/refs/specify.md

@@ -62,7 +62,7 @@ proceed past validate without explicit user agreement on the AC set.
 4. Keep ACs minimal — 3–7 is the sweet spot. More than 10 means you're
    treating ACs as design.
 5. Record the AC artifact as re-derivable evidence (vault present;
-   **wicked-vault ≥ 0.5.0** <!-- vault-floor -->):
+   **wicked-vault ≥ 0.8.0** <!-- vault-floor -->):
    `wicked-vault record --scope <scope> --phase specify
    --claim smart-acceptance-criteria --kind spec-doc
    --artifact <path/to/requirements.md>

package/skills/core/refs/setup.md

@@ -97,7 +97,7 @@ npx wicked-vault --version 2>/dev/null || echo "MISSING"
 ```
 
 - `MISSING` → blocking. wicked-vault is the evidence backend every archetype gate re-derives against — without it, "done" can only be self-asserted. Show "wicked-vault is not installed. wicked-garden requires it as a direct infra peer (sibling to wicked-bus)." **INTERACTIVE mode**: native prompt header "wicked-vault Required", options "Install now (Required)" = "Run: npm i -g wicked-vault" / "Exit setup" = "Cancel — I'll install manually and re-run". **PLAIN_TEXT mode**: present numbered options and STOP. If install: run `npm i -g wicked-vault` (puts the `wicked-vault` binary on PATH) and confirm the CLI resolves with `npx wicked-vault --version`. On failure, show stderr and exit with manual instructions (`npm i -g wicked-vault`). If exit: "Run `npm i -g wicked-vault` then restart by invoking the wicked-garden-core skill's `setup` action."
-- Version string → compare it against the declared peer floor **≥ 0.5.0** <!-- vault-floor --> (single source: `scripts/loom/manifest.py` `version_pin`, lockstep with plugin.json `wicked_vault_version`). **Below the floor** (e.g. `0.4.5`) → tell the user to upgrade: "wicked-vault {version} is below the floor 0.5.0 — peer health checks (`loom doctor` / peer-health) report it as drift and fail. Upgrade: `npm i -g wicked-vault@latest`." At or above (e.g. `0.6.0`) → show "wicked-vault {version} — ready." Then verify the garden can resolve it for gating: `wicked-garden run scripts/qe/vault_gate.py resolve` should report `resolvable: true`. If `installed: false` (resolving only via npx), suggest `npm i -g wicked-vault` for faster gate latency — recommended, not a hard block.
+- Version string → compare it against the declared peer floor **≥ 0.8.0** <!-- vault-floor --> (single source: `scripts/loom/manifest.py` `version_pin`, lockstep with plugin.json `wicked_vault_version`). **Below the floor** (e.g. `0.7.0`) → tell the user to upgrade: "wicked-vault {version} is below the floor 0.8.0 — peer health checks (`loom doctor` / peer-health) report it as drift and fail. Upgrade: `npm i -g wicked-vault@latest`." At or above (e.g. `0.8.0`) → show "wicked-vault {version} — ready." Then verify the garden can resolve it for gating: `wicked-garden run scripts/qe/vault_gate.py resolve` should report `resolvable: true`. If `installed: false` (resolving only via npx), suggest `npm i -g wicked-vault` for faster gate latency — recommended, not a hard block.
 
 ### 2.7 Verify wicked-bus (Recommended — audit-trail layer)
 
@@ -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
 
@@ -304,7 +304,7 @@ wicked-garden is ready!
 Storage:         Local (DomainStore)
 wicked-estate:   {"ready (binary present)" or "MISSING — memory/context layer degraded"}
 wicked-bus:      {"ready (skills installed)" or "MISSING — install required"}
-wicked-vault:    {version e.g. "0.6.0 — ready" or "MISSING — install required" or "{version} — below the 0.5.0 floor, upgrade required"}
+wicked-vault:    {version e.g. "0.8.0 — ready" or "MISSING — install required" or "{version} — below the 0.8.0 floor, upgrade required"}
 loom engine:     {"ready (internal — scripts/loom/)" or "MISSING — garden installation problem"}
 Onboarding:      {Full | Quick scout | Skipped}
 Directories:     {paths onboarded}

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/qe/refs/campaign-grading.md

@@ -216,10 +216,10 @@ wicked-garden run scripts/qe/lib/gate.mjs \
   ```
 
 - **Release dependency:** needs the wicked-vault **manifest-2.1 twin**
-  (`validateManifest` + `CLAIM_LEVELS`) — merged on wicked-vault main,
-  **unreleased** (npm 0.6.0 predates it). Until the next wicked-vault
-  release, set `WICKED_QE_VAULT_PKG` to a local checkout of wicked-vault
-  main; a pre-2.1 vault is refused fail-closed, never silently degraded.
+  (`validateManifest` + `CLAIM_LEVELS`), which shipped in wicked-vault 0.7.0;
+  garden's floor is **0.8.0**. An older vault is refused fail-closed, never
+  silently degraded — upgrade with `npm i -g wicked-vault@latest` (or set
+  `WICKED_QE_VAULT_PKG` to point at a specific 0.8.0+ install).
 
 ## Wiring context
 

package/skills/qe/refs/evidence.md

@@ -279,7 +279,7 @@ Rules, all fail-closed:
 3. **Grades are opinions, not re-derivable facts**: `attest` appends, never
    edits; the vault refuses a self-grade (evaluator = recording actor) and
    a grade over a tampered artifact.
-4. **Release dependency**: needs the wicked-vault manifest-2.1 twin —
-   on wicked-vault main, **unreleased** (npm 0.6.0 predates it). Until the
-   next wicked-vault release, set `WICKED_QE_VAULT_PKG` to a local checkout
-   of wicked-vault main; a pre-2.1 vault is refused with that message.
+4. **Release dependency**: needs the wicked-vault manifest-2.1 twin
+   (shipped in wicked-vault 0.7.0; garden's floor is **0.8.0**). An older
+   vault is refused fail-closed — upgrade with `npm i -g wicked-vault@latest`
+   (or set `WICKED_QE_VAULT_PKG` to point at a specific 0.8.0+ install).

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.

package/uv.lock

@@ -1,6 +1,6 @@
 version = 1
 revision = 3
-requires-python = ">=3.10"
+requires-python = ">=3.10, <3.15"
 
 [[package]]
 name = "aiofiles"