@nurix/etna 0.16.0 → 0.17.0

package/data/harnesses/code-fable/skills/boundary/SKILL.md

@@ -1,262 +1,76 @@
 ---
 name: boundary
-description: The single home for a repo's typed application boundaries — the cross-cutting contracts (db-schema, wire envelope, store shape, auth, tenancy, event schemas, edge bindings, …) where editing one module silently breaks another. One skill, four modes — `generate` (baseline all boundaries from the detected stack + IA), `create` (add/update one boundary), `check` (pre-implementation: does this plan touch a boundary? severity-ranked impact), `init` (reconcile: ensure files exist, scan live code for violations + drift, backfill new catalog types). All four read one shared knowledge root, `references/boundary-taxonomy.md`, so they can never drift apart. Triggers on "application boundary", "baseline boundaries", "map boundaries", "generate boundaries", "create a boundary", "introspect", "check this plan", "impact analysis", "what could break", "scan for boundary violations", "boundary drift", "/boundary".
+description: Boundary diagnostic for implementation plans. Given a plan file, reads the source files the plan touches, identifies the application boundaries they participate in — the cross-cutting contracts (db schema, wire envelope, auth, events, env/config, …) where editing one side silently breaks the other — and reports whether the planned changes would violate any of them, severity-ranked, with suggested plan amendments. Read-only; the report lands in chat. Can also run against a diff or named code area instead of a plan. Triggers on "boundary check", "check this plan", "what could break", "impact analysis", "/boundary".
 ---
 
-# Application Boundary Skill
+# Boundary Diagnostic
 
-The one place a repo's **typed application boundaries** are produced, checked, and
-maintained. A boundary is a horizontal cross-cutting contract — an *edge* between
-modules, layers, services, or deploy units — where editing one side silently
-breaks another. They live as one file per boundary in `docs/boundaries/`.
+You diagnose whether a plan's changes would break an application boundary.
 
-This skill merges what used to be three components — `boundary-mapper` (produce),
-`introspect` (pre-impl check), `contract-monitor` (post-impl scan) — into one
-skill with four modes. The reason they're one skill: **all four share a single
-knowledge root** — [`references/boundary-taxonomy.md`](references/boundary-taxonomy.md),
-the exhaustive catalog of *what an application boundary is* and *which kinds
-exist* (≈170 types across persistence, wire/API, frontend, auth/tenancy,
-async/messaging, config/build, runtime/infra). Three separate components meant
-three copies of that mental model that drifted apart. One skill, one catalog,
-zero drift.
+A boundary is a contract between two pieces of code (or code and infra) that
+share an assumption with **no compile-time link** between them: the column a raw
+SQL string names, the JSON envelope a client unwraps, the event string a
+dispatcher parses, the env var a deploy script writes. Changing one side ships
+green and breaks the other silently. Your job is to find those edges in the
+plan's path *before* execution.
 
-> **Read [`references/boundary-taxonomy.md`](references/boundary-taxonomy.md)
-> first, in every mode.** It carries the boundary-file anatomy, the
-> `point`-vs-`transcribe` doc-mode, the technology/domain split, the per-type
-> severities, and the safe-change checklists. This SKILL.md only orchestrates the
-> four verbs over that knowledge.
+[`references/boundary-taxonomy.md`](references/boundary-taxonomy.md) is the
+catalog of boundary types (~170 across persistence, wire/API, frontend,
+auth/tenancy, async/messaging, config/build, runtime/infra), with per-type
+severities and safe-change checklists. Read it first — it tells you what to
+look for; the code tells you what exists.
 
----
-
-## Picking a mode
-
-| You want to… | Mode | Old component |
-|---|---|---|
-| Baseline a repo — generate every boundary that exists from the stack + IA | **`generate`** | boundary-mapper (baseline) |
-| Add or update **one** boundary file | **`create`** | boundary-mapper (create/update) |
-| Before coding: does this **plan** touch a boundary? Severity-ranked impact | **`check`** | introspect |
-| Reconcile: do files exist? scan **live code** for violations + drift; backfill new catalog types | **`init`** | contract-monitor + drift + catalog-sync |
-
-If the user's intent is ambiguous, ask which mode. `generate` and `create` are the
-same writer at different scope (`generate` = `create` over every detected
-boundary).
-
-## Execution model — pure skill
-
-This skill runs **in the main session** — no standing sub-agents. `check` and
-`create` are light and always run inline. `generate` and `init` sweep the
-codebase; run that sweep inline too. **Only** for an unusually large repo (where
-an inline full-codebase sweep would blow the context budget) may you dispatch a
-**one-shot scan worker** sub-agent that reads this same taxonomy reference and
-returns structured findings — the knowledge still lives in exactly one place.
-Default to inline; reach for a worker only when the repo's size forces it.
-
-## Before any mode
-
-1. Read [`references/boundary-taxonomy.md`](references/boundary-taxonomy.md) — the
-   boundary types, doc-modes, default severities, and safe-change checklists for
-   the stack you're about to touch.
-2. If `docs/memory/boundary.md` exists, read it for project-specific
-   boundary exceptions, known violations the user chose not to fix, where the IA
-   model actually lives, and stack quirks that change a doc-mode.
-3. If `docs/routing.md` exists, read it for module-ownership context.
-
----
-
-## Mode: `generate` (baseline)
-
-No `docs/boundaries/` yet (or a from-scratch re-baseline). Detect the stack + IA,
-instantiate one file per boundary that actually exists.
-
-1. **Detect the stack** — read `package.json` (deps), the lockfile, and skim the
-   source tree. Map detected technologies to their boundary types via the
-   taxonomy. (Detect the package manager from the lockfile; don't assume.)
-2. **Detect the information architecture** — read `docs/architecture/`
-   (domain-model, ADRs), doctrine in any `docs/modules/*/pillars/`, and the
-   entity/contract definitions (a `@org/contracts` package, `schema.ts`,
-   `models.py`). The IA entity model is the flagship `domain` boundary
-   (`information-architecture`).
-3. **For each boundary the repo exhibits**, write one file to `docs/boundaries/`
-   using the boundary-file anatomy. Decide `point` vs `transcribe` per the
-   taxonomy: `point` boundaries get a `file:line` pointer + invariants +
-   checklist (never a transcribed copy — it rots); `transcribe` boundaries (the
-   composed store tree, the response envelope, the IA topology, tenancy) get the
-   contract canonically in the file.
-   - **Greenfield branch — contract decided, no code yet.** If the repo is
-     pre-code (ADRs/domain-model decide the contract but the source module isn't
-     scaffolded), a `point` boundary has no `file:line` to mirror. Don't skip it
-     and don't fabricate a pointer — per the taxonomy's *Greenfield / pre-code
-     boundaries*, emit it as **conventions-with-planned-pointer**: record the
-     decided conventions inline, carry a `planned <path>` pointer, mark it `point*`
-     (a pre-code `transcribe` source is `transcribe*`), and make the last
-     safe-change item "replace the planned pointer with the real `file:line` once
-     code lands." Link any item that hinges on an unresolved decision to its
-     open-question/ADR.
-4. **Set severity** from the taxonomy default, adjusted by the concrete repo +
-   project memory. Severity is load-bearing — it drives `check` review depth and
-   `init` scan priority.
-5. **Name the bounding code units** (paths / package names) in every `Bounds`
-   line. The distinct vertices named across all `Bounds` lines are the
-   **module-discovery feed** `harness-manager` reads to propose modules — name
-   them precisely.
-6. **Write `docs/boundaries/README.md`** as the index per the taxonomy's index
-   spec: a table with a **Doc-mode column**
-   (`| Boundary | Type | Severity | Doc-mode | Bounds (summary) |`), then the
-   standing blocks — **Active technology packs**, **Folds applied** (which catalog
-   types collapsed into which file — surface the per-entry fold-notes as a ledger),
-   and **Skipped** (types omitted + one-line reason each). Add the `point*`/`transcribe*`
-   footnote if any boundary is pre-code.
-7. **Don't invent boundaries the repo doesn't have.** Only instantiate types the
-   detected stack/IA actually exhibits; `log()` what you skipped and why.
-
-Write only under `docs/boundaries/` and `docs/memory/boundary.md`.
-Read-only on production code.
+## Run
 
-## Mode: `create` (targeted)
+**Input:** a plan path (given, or the newest in `docs/history/plans/`) — or a
+diff / named code area for non-plan work. Everything below is identical either
+way; a diff's hunks stand in for the plan's steps.
 
-Add or update a single boundary file (e.g. a new contract surfaced by `check`, or
-a boundary the author asks for by name).
+1. **Build the touch list.** Parse the plan's Proposed Changes: files to be
+   created or modified, entities/state added or changed, API changes, anything
+   the author flags as a cross-module contract. Note missing subsections.
 
-1. Identify the boundary type from the taxonomy; confirm the repo exhibits it.
-2. Write/update the one file with the full anatomy (Bounds, Shape, Invariants,
-   Blast radius, Safe-change checklist), `point` or `transcribe` per the taxonomy.
-3. Update `docs/boundaries/README.md` (add/refresh the index row).
-4. For an **update** that fixes drift (the `maintenance` agent flags a boundary
-   file drifted from its source): re-read the source, refresh the `Shape` pointer
-   or transcription, leave invariants/checklist intact unless they changed.
+2. **Identify the boundaries in the touched code.** Read each touched file (and
+   its immediate imports). Against the taxonomy, list the contracts this code
+   participates in — the schema it queries, the envelope it emits, the events
+   it publishes or parses, the auth checks it sits behind, the env it reads.
 
-## Mode: `check` (pre-implementation)
+3. **Trace the other side.** A boundary has two sides; the danger lives on the
+   one the plan *doesn't* mention. For each contract, grep the shared name or
+   shape across the repo — the column name in other SQL strings, the response
+   field in client unwrappers, the event kind in subscribers, the route in
+   fetch calls and scripts, the env key in deploy tooling. Record consumers as
+   `file:line`.
 
-Read-only. Intersect a plan's proposed changes with the documented boundaries and
-surface cascading risk *before* coding. (This is the old `introspect`.)
+4. **Judge each intersection.** Does the planned change alter a shape a traced
+   consumer depends on, break an invariant the code establishes (append-only
+   vocabularies, idempotency keys, fail-closed checks, ordering guarantees), or
+   add a new cross-module edge? Severity:
+   - **CRITICAL** — can corrupt persisted data, or open an auth/money path.
+   - **HIGH** — silent cross-module breakage that would ship green.
+   - **MEDIUM** — drift-prone coupling (string-matched, duplicated constants).
+   - **LOW** — smell. Loud, immediately-visible breakage caps at HIGH.
 
-**Inputs.** Plan path (user-provided; else newest in `docs/history/plans/`). Every
-file in `docs/boundaries/` is mandatory input — if the folder is missing/empty,
-stop and tell the user to run `generate` first. Source files read on demand to
-verify — never guess from plan text alone.
-
-1. **Load.** Resolve + read the plan; confirm it has a `Status:` (warn if
-   `Complete`/`Abandoned`). Read every boundary file; parse the
-   `[BOUNDARY: type · severity]` header + Bounds / Shape / Invariants / Blast
-   radius / Safe-change checklist. Severity sets review depth.
-2. **Parse proposed changes.** The plan template's **Proposed Changes**
-   subsections are load-bearing: New Files / Modified Files (check against the
-   modules each boundary **Bounds** and any `Shape` `file:line`) · New Entities /
-   State (vs `information-architecture` + `db-schema`) · API Changes (vs
-   `wire-response-envelope` / `rest-endpoint-shape` / `graphql-schema`) ·
-   Cross-Module Contracts Affected (the author's own admission — start there,
-   then verify). Note any missing subsection.
-3. **Analyze each boundary × change pair** for: **Bounds overlap** (touches a
-   bounded module or a `Shape` pointer), **Invariant overlap** (introduces a
-   shape the invariants prohibit — raw literal where a shared constant is
-   required, entity type not in the canonical array, persisted field without
-   fallback), **Shape overlap** (modifies the canonical Shape). Read the actual
-   source to verify any plausible intersection.
-4. **Assign severity.** Anchor to the boundary's own severity (the floor),
-   adjust by the concrete change. Critical = silent data loss / corrupted
-   persistence / broken cross-entity refs; High = stale state / broken lookups /
-   schema selectors without fallbacks; Medium = likely-to-drift string-coupling;
-   Low = code smell.
-5. **Report** (in chat — never written to disk):
+5. **Report in chat:**
 
    ```
-   # Application Boundary — check — {plan filename}
-
-   Plan: {path}
-   Boundaries: {N} files evaluated
-   Intersections: {N} ({critical}/{high}/{medium}/{low})
+   # Boundary check — {plan}
 
-   ## Violations
-   | # | Boundary | Risk | Severity | Plan step |
+   Touched files read: {N} · Boundaries identified: {N}
+   Violations: {N} ({critical}/{high}/{medium}/{low})
 
-   ## Suggested Plan Additions
-   - Violation #1 → add step X to Implementation Steps / Done Criteria …
+   | # | Boundary | Planned change | Other side (file:line) | Severity |
 
-   ## Missing Subsections
-   ## New Cross-Module Contracts Detected
-   {describe the proposed boundary (type, Bounds, Shape, suggested severity) and
-    recommend running `create` to formalize it — do not write the file from check}
+   ## Suggested plan amendments
+   ## Missing plan subsections
    ```
 
-The severity-ranked table is the load-bearing output. Suggestions are advisory —
-the user folds them back into the plan; **`check` never edits the plan or code.**
-
-## Mode: `init` (reconcile — ensure, scan, backfill)
-
-Ensure boundaries are initialized and current. Three jobs in one pass:
-
-1. **Ensure exist.** If `docs/boundaries/` is missing/empty → this is really a
-   baseline; run `generate` instead and stop.
-2. **Scan live code for violations** (the old `contract-monitor`). For each
-   boundary file, parse its header + invariants, then scan the codebase for
-   violations of *that* boundary. Categories: **unregistered entity types**
-   (strings used as entity-type ids not in the canonical array) · **string-coupled
-   constants** (raw literals where a shared constant import is required) ·
-   **cross-entity references without propagation** (storing entity A's
-   slug/name/id by value in B with no documented propagation) · **schema
-   mismatches** (selectors hitting persisted fields without a fallback default) ·
-   **undocumented endpoints** (routes with no feature-doc / `api` boundary entry).
-   Verify by reading actual source — never guess.
-3. **Detect drift + backfill the catalog.** (a) Flag any boundary file whose
-   `Shape` has drifted from its source (refresh it via `create`/update). (b)
-   Compare the taxonomy's boundary *types* against what the repo now exhibits —
-   if the repo gained a technology (or the catalog gained a type) that the repo
-   exhibits but `docs/boundaries/` lacks, surface it and offer to `generate` that
-   one boundary.
-
-**Act on violations.** Mechanical fix (missing constant import, missing fallback,
-missing canonical-array entry) → fix directly with an Edit. Design-decision fix
-(new entity-type registration, new propagation mechanism, schema migration) →
-append to `docs/history/backlog.md` as P0/P1 with the specific boundary + bounded
-modules. Pre-existing exception (in `docs/memory/boundary.md`) → skip
-silently.
-
-**Report** a table `| # | Boundary | Violation | Location | Action taken |`, then
-update `docs/memory/boundary.md` with scan date, per-boundary
-violation counts, items fixed / backlogged, new exceptions, and any
-newly-exhibited boundary types backfilled.
-
----
-
 ## Rules
 
-- **One knowledge root.** Every mode reads `references/boundary-taxonomy.md`.
-  Extend the catalog there, never inline a divergent copy in a mode.
-- **`check` is read-only** — never edits the plan, source, boundaries, or memory.
-  The other modes write only under `docs/boundaries/`,
-  `docs/memory/boundary.md`, and (for `init` mechanical fixes) the
-  specific violating source line. Never touch frozen records
-  (`docs/history/plans/`, `docs/history/changelog/`) or feature docs.
-- **Verify against source.** Never report a violation or intersection from text
-  alone — read the files the plan/boundary names.
-- **One file per boundary.** Don't bundle unrelated boundaries.
-- **Severity is load-bearing.** It feeds `check` review depth + `init` priority.
-  Default from the taxonomy; adjust from the repo + memory.
-- **Name the bounding code units** in every `Bounds` line — they're the
-  module-discovery feed `harness-manager` reads. A workspace is *not* a module.
-- **Don't invent boundaries the repo doesn't have.** Only instantiate exhibited
-  types; `log()` skips. **A clean report is valid** — empty violations/intersections
-  means say so, don't pad.
-- **Docs never outrank code.** For `point` boundaries, mirror with `file:line`;
-  don't fork the shape. `file:line` stays primary for point-mode boundaries; an
-  `anchors:` query (see the documentation skill's frontmatter reference) MAY
-  supplement it for refactor-resilience — optional and additive, it re-resolves
-  the shape when the line moves, never replaces the pointer.
-- **Be specific** — file paths, line numbers, boundary names, the exact violating
-  string or code shape.
-
-## Strategy memory
-
-After a run you may append to `docs/memory/boundary.md` (git-tracked):
-project-specific boundary exceptions, where the IA model actually lives in this
-repo, stack quirks that change a doc-mode, recurring drift/violation zones,
-historical violation counts. Never user preferences (those are `~/.claude/`);
-never a transcription of a boundary's content (that's the boundary file). Date
-each entry `## YYYY-MM-DD — {topic}`.
-
-## Output locations
-
-- `generate`/`create`/`init` write boundary files to `docs/boundaries/` + the
-  index `docs/boundaries/README.md`; memory to `docs/memory/boundary.md`.
-- `check` returns its report in chat — never written to disk; the user folds
-  insights back into the plan.
+- **Read-only.** You never edit the plan, the code, or any doc. The user folds
+  your amendments into the plan.
+- **Verify in source.** Never flag from plan text alone — read both sides of
+  every boundary you report, and cite both as `file:line`.
+- **No consumer, no finding.** An intersection with no traced other side isn't
+  a violation; at most note it as a new edge the plan introduces.
+- **A clean report is valid.** Zero violations means say so — don't pad.

package/data/harnesses/code-fable/skills/brainstorm/harvest.md

@@ -4,12 +4,12 @@ Harvest is **optional and offered, never assumed**. By default the session folde
 
 ## Routing
 
-The harvest is a structured diff between the session pillars and the live docs, routed by scope: module-local findings → `docs/modules/{m}/pillars/`, cross-module → `docs/architecture/`, IA/contract changes → `docs/boundaries/` (via the `boundary` skill), backlog → `docs/history/`.
+The harvest is a structured diff between the session pillars and the live docs, routed by scope: module-local findings → `docs/modules/{m}/pillars/`, cross-module + IA/contract changes → `docs/architecture/`, backlog → `docs/history/`.
 
 | Session source | Destination |
 |---|---|
 | `thesis.md` narrative | `docs/history/plans/YYYY-MM-DD-{slug}.md` (Status: Draft, `documentation` skill §8 Plan template) |
-| `domain-model.md` | `docs/architecture/domain-model.md`; if it changes the IA or a cross-cutting contract, **flag for the `boundary` skill (`create`)** — don't hand-write boundary files |
+| `domain-model.md` | `docs/architecture/domain-model.md`; if it changes the IA or a cross-cutting contract, note the contract change there — the `boundary` skill will pick it up from source at the next plan check |
 | Decisions spanning 2+ modules | one ADR per cohesive theme → `docs/architecture/adr/ADR-NNN-{slug}.md`, authored to the **`documentation` skill §10 ADR template** (frontmatter `status:` is the lifecycle source of truth — no body Status line; required sections Decision/Context/Consequences); rejected alternatives → the ADR's **Options Considered** table |
 | Module-local decisions / doctrine / glossary / rejected | `docs/modules/{m}/pillars/{decisions,doctrine,glossary,rejected}.md` |
 | Cross-module doctrine / glossary | `docs/architecture/domain-model.md` / `docs/architecture/glossary.md` |

package/data/harnesses/code-fable/skills/documentation/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: documentation
-description: Template & generator library for technical docs — the skill agents call to produce a doc from a template. Use to (1) document a feature or module, (2) create or update a changelog entry, (3) document data flows or Redux state, (4) add to protected files, (5) provide the generic boundary-file template (typed-boundary *generation* is the `boundary` skill), (6) record an architecture decision (ADR), (7) create or update the project root README, (8) create or update a plan, (9) derive ownership frontmatter (`owns`/`touches`/`depends_on`) from code, (10) scaffold a standard doc (README, structure.md, CHANGELOG, backlog, memory) from its template, or (11) co-author any technical doc. Baselining / reconciling a repo's docs to the installed harness version is the **`harness-manager` agent** (which calls this skill for each template) — this skill does not orchestrate baseline. Triggers on "document this", "create docs", "update changelog", "add to protected files", "ADR", "architecture decision", "root README", "plan", "feature doc".
+description: Template & generator library for technical docs — the skill agents call to produce a doc from a template. Use to (1) document a feature or module, (2) create or update a changelog entry, (3) document data flows or Redux state, (4) add to protected files, (5) record an architecture decision (ADR), (6) create or update the project root README, (7) create or update a plan, (8) derive ownership frontmatter (`owns`/`touches`/`depends_on`) from code, (9) scaffold a standard doc (README, structure.md, CHANGELOG, backlog, memory) from its template, or (10) co-author any technical doc. Baselining / reconciling a repo's docs to the installed harness version is the **`harness-manager` agent** (which calls this skill for each template) — this skill does not orchestrate baseline. Triggers on "document this", "create docs", "update changelog", "add to protected files", "ADR", "architecture decision", "root README", "plan", "feature doc".
 ---
 
 # Technical Documentation Skill
@@ -30,8 +30,6 @@ User request
     │
     ├─ "Add to protected files" ───────▶ Protected Files Template
     │
-    ├─ "Create/update a boundary" ─────▶ boundary skill (this skill holds only the boundary-file template)
-    │
     ├─ "Record architecture decision" ─▶ ADR Template
     │
     ├─ "Create/update root README" ────▶ Project Root README Template
@@ -122,6 +120,6 @@ For docs that don't match templates:
 
 | File | Use For |
 |------|---------|
-| `references/templates.md` | docs/README.md, structure.md, frontmatter, scaffolds (CHANGELOG, backlog, memory), boundary-file, feature, changelog, plan, protected files, ADR, project root README templates |
+| `references/templates.md` | docs/README.md, structure.md, frontmatter, scaffolds (CHANGELOG, backlog, memory), feature, changelog, plan, protected files, ADR, project root README templates |
 | `references/style-guide.md` | Writing rules, formatting conventions |
 | `references/examples.md` | Good vs bad documentation examples |

package/data/harnesses/code-fable/skills/documentation/references/templates.md

@@ -93,7 +93,6 @@ Each topic has one canonical location. Read from here, not from plans or changel
 | ----- | --------- | --------- |
 | System architecture + steering | `docs/architecture/` | domain-model, glossary, non-goals, references, adr/ |
 | Feature behavior | `docs/features/` (or `docs/modules/{m}/features/`) | {key files} |
-| Cross-module contracts | `docs/boundaries/` | one file per boundary (maintained by the `boundary` skill) |
 | Declared modules (bounded contexts) | `docs/modules/{m}/` | `features/` + `pillars/` |
 | Setup & development | `docs/operations/` | {key files} |
 | Historical plans | `docs/history/plans/` | YYYY-MM-DD-name.md |
@@ -112,7 +111,6 @@ Plan (Status: Draft) → Implementation → Feature Doc or Architecture Update
 
 - `docs/features/`: Living reference for implemented features. Each spec includes YAML frontmatter with `owns`, `touches`, `depends_on` fields declaring code ownership.
 - `docs/architecture/`: System-wide patterns and the cross-module steering layer (domain model, glossary, non-goals, references, ADRs). Update when cross-cutting concerns change.
-- `docs/boundaries/`: Horizontal typed application boundaries — one file per cross-module contract. Generated/maintained by the `boundary` skill; read before touching a shape it defines.
 - `docs/modules/{m}/`: Vertical bounded contexts, **declared** (not inferred from layout) and tied to code by their `owns` globs. Each owns `features/` + module-local `pillars/` (doctrine, lazy). There is no repo-wide `docs/pillars/`. Worth declaring at ≥2 genuine bounded contexts; a single-context app stays flat under `docs/features/`.
 - `docs/operations/`: How-to procedures for setup, development, and deployment. Update when workflows change.
 - `docs/history/plans/`: Historical. Must have `Status:` field. Never modify after completion.
@@ -150,7 +148,7 @@ anchors:
 - `owns`: Glob patterns for files this feature doc is the canonical reference for
 - `touches`: Files this feature interacts with but doesn't own
 - `depends_on`: Other docs that must be read for full context
-- `anchors` (optional): A list of qmd queries (or `#docid`s) that re-resolve to the code/facts this doc abstracts as they move; anchors are retrieval context plus a drift tripwire, never a contract — an anchor that returns nothing IS the drift signal, nothing auto-rewrites from an anchor result, and the doc's prose stays the human-owned abstraction. They detect **doc-area drift** (the subject moving or vanishing from the corpus), not a pure code rename — the query also matches the doc's own prose, so a rename that leaves the text unchanged won't shift the result; code-symbol drift is the maintenance named-referent check's job, and anchors complement it rather than replace it. Resolved via `qmd query --format json -c <collection>` against this repo's collections; absent qmd ⇒ anchors are inert (no error). Never required on any doc. The feature and boundary templates ship the exemplar, but `anchors:` may appear on any living doc the maintenance anchor-drift check globs — `docs/features/`, `docs/boundaries/`, `docs/architecture/`, and `docs/operations/` — so the convention and the check stay one mental model.
+- `anchors` (optional): A list of qmd queries (or `#docid`s) that re-resolve to the code/facts this doc abstracts as they move; anchors are retrieval context plus a drift tripwire, never a contract — an anchor that returns nothing IS the drift signal, nothing auto-rewrites from an anchor result, and the doc's prose stays the human-owned abstraction. They detect **doc-area drift** (the subject moving or vanishing from the corpus), not a pure code rename — the query also matches the doc's own prose, so a rename that leaves the text unchanged won't shift the result; code-symbol drift is the maintenance named-referent check's job, and anchors complement it rather than replace it. Resolved via `qmd query --format json -c <collection>` against this repo's collections; absent qmd ⇒ anchors are inert (no error). Never required on any doc. The feature template ships the exemplar, but `anchors:` may appear on any living doc the maintenance anchor-drift check globs — `docs/features/`, `docs/architecture/`, and `docs/operations/` — so the convention and the check stay one mental model.
 
 ---
 
@@ -243,7 +241,7 @@ description: Shared knowledge accumulated across agent sessions. All agents shou
 ## Documentation Baseline
 
 - **Baselined:** {today}
-- **Structure:** v{harness-version} (architecture, features, operations, history, memory; + boundaries/, modules/, tests/ when present)
+- **Structure:** v{harness-version} (architecture, features, operations, history, memory; + modules/, tests/ when present)
 - **Spec version:** v{harness-version}
 <!-- v{harness-version} resolves to the installed design epoch — read it from `.claude/harness.json` (`epoch`) / `docs/structure.md` frontmatter (`harness-version`); never hardcode a literal version here. -->
 
@@ -284,86 +282,11 @@ Append entries below, oldest at bottom. Format:
 Memory file initialized during documentation baseline.
 ```
 
-> The per-actor memory **inbox** (`docs/memory/inbox/`) is *not* a baseline scaffold — the `session-reflect` hook creates it mechanically on the first reflected session. See **§12 Memory inbox entry** for its format.
+> The per-actor memory **inbox** (`docs/memory/inbox/`) is *not* a baseline scaffold — the `session-reflect` hook creates it mechanically on the first reflected session. See **§11 Memory inbox entry** for its format.
 
 ---
 
-## 5. Boundary File (docs/boundaries/{boundary}.md)
-
-> **This skill does not generate boundaries.** Typed-boundary generation is owned by the **`boundary`** skill (`generate` mode), which detects the stack + IA and applies its boundary taxonomy (`references/boundary-taxonomy.md`) to emit typed files. The baseline does **not** scaffold `docs/boundaries/` — `/boundary generate` runs right after the baseline ("baseline boundaries"). This section is the generic **boundary-file template** plus the guidance for *recognizing* what deserves a boundary.
-
-### What deserves a boundary
-
-A boundary is a **horizontal, cross-module contract** where the failure is silent and crosses module boundaries — the developer in module A has no reason to know module B will break. No import error, no runtime exception — just wrong behavior.
-
-Test: "If an agent edits this while working on a single feature, could it silently break something in a different feature?" If yes, it's a boundary.
-
-**Include:**
-
-- **Shared state shapes** — Redux store slices, persisted state, global context. Any shape that multiple modules read. Document every key, its type, and what reads it. Call out which slices are persisted and how rehydration handles shape changes (e.g., new fields become `undefined` for existing users).
-- **Entity registration checklists** — When adding a new entity/resource type requires touching N files across N modules to avoid silent data loss. List every file and what breaks if skipped.
-- **Cross-entity references by value** — When entity A stores entity B's identifier (slug, name, ID) as a plain value with no referential integrity. Document which fields reference what, and that renaming the target never propagates to the source.
-- **Format contracts** — When two systems produce identifiers in different formats (e.g., server returns `[a-z0-9]+`, client generates `[a-z0-9_]+`). Document both formats, where each is used, and what breaks on mismatch (e.g., lookup by key returns `undefined`, key-splitting logic produces wrong matches).
-- **Cross-module string coupling** — Action types, event names, status enums, or document type strings referenced by raw string literal instead of imported constant. List every file that hard-codes the string and what breaks if the source is renamed.
-- **Pipeline ordering dependencies** — Multi-step pipelines where Step N assumes Step N-1 has already written data to shared state. Document the implicit dependency and what happens if ordering changes (silent quality degradation vs. hard failure vs. hang).
-- **Completion signal contracts** — When modules communicate via return values, status fields, or Redux state transitions. Document the expected shape/type (e.g., `Promise<boolean>`, status enum values) and what happens if the contract changes (e.g., returning `undefined` instead of `true` causes permanent "failed" status).
-- **Host/plugin contracts** — Config objects consumed by a framework/host where some fields are validated and others aren't. Document which fields are unvalidated and what breaks silently if they change.
-- **Persistence shape safety** — How the persistence layer handles schema evolution. Document what happens when you add, remove, or rename a field in persisted state (e.g., no migration → stale data, new fields default to `undefined`).
-
-**Exclude:**
-
-- Module-internal architecture (well-encapsulated, no cross-module blast radius)
-- Authentication/authorization flows (behind adapters, feature code doesn't touch them)
-- Hook taxonomies and API reference (useful docs, but not boundaries — they don't cause cascading failures)
-- Networking details (WebSocket, HTTP client setup) — unless the event routing has cross-module string coupling
-- Feature folder conventions and code style (conventions, not breakage vectors)
-- Anything where failure produces an import error, a clear runtime exception, or a visible UI error — those are self-diagnosing and don't need a boundary
-
-### How to research a boundary
-
-When mapping a boundary (the `boundary` skill's `generate`/`create` job — this guidance is shared), investigate:
-
-1. **Shared state consumers** — For each Redux slice/context, find all files that read from it. Flag any file reading a slice it doesn't own (cross-module dependency).
-2. **String-coupled actions** — Grep for Redux action type strings referenced as raw strings rather than imported constants. These are invisible breakage points.
-3. **Entity lifecycle** — For each entity type, trace the full lifecycle: creation → change tracking → save payload → API → server. Identify every file that must be touched to support a new entity type.
-4. **Identifier format mismatches** — Compare how identifiers are generated (server vs. client) and how they're used as keys. Look for format divergence.
-5. **Pipeline data dependencies** — For multi-step processes, check what each step reads from shared state and what previous step wrote it. Test: "If I reorder these steps, does it fail loudly or silently?"
-6. **Persistence rehydration** — Check what reconciler is used, whether transforms exist, and what happens to existing users when a persisted shape changes.
-
-### Generic boundary-file template
-
-One file per boundary in `docs/boundaries/`. The `boundary` skill emits typed files using its boundary taxonomy; this is the generic fallback shape.
-
-```markdown
----
-anchors:                    # optional — see §3 frontmatter reference
-  - "qmd query: store slice rehydration fallback"
----
-
-# {Boundary Name}
-
-[BOUNDARY: {type} · {severity}]   <!-- type from the Application Boundary Scale; severity CRITICAL | HIGH | MED | LOW -->
-
-**Bounds:** {module A} ↔ {module B}   <!-- which modules sit on each side -->
-
-## Shape
-<!-- `transcribe`: a synthesized contract with no single code home (composed store tree, API envelope, the IA entity model, tenancy) — written inline, canonical here.
-     `point`: a self-locating shape (DB schema, route table) — a `file:line` pointer + invariants. Never copy a self-locating shape; it rots on the next change.
-     greenfield/pre-code `point` (contract decided, no code yet — e.g. boundary generate after a brainstorm): there's no file:line to point at, so instead (a) record the decided conventions inline here, (b) add a `planned <path>` line naming where the canonical source will land (e.g. `planned packages/api/src/db/schema.ts`), and (c) mark this row `point*` in the README index. Converts to (or gains) a real file:line pointer when the module lands. README index footnote: "* point-mode boundary whose pointer lands at implementation". -->
-
-## Invariants
-<!-- The rules that must hold across the boundary. -->
-
-## Blast radius
-<!-- What breaks, and where, if an invariant is violated. -->
-
-## Safe-change checklist
-<!-- Ordered steps to change this contract without silent breakage. Mark steps that fail silently if skipped. -->
-```
-
----
-
-## 6. Feature Documentation (docs/features/{feature}.md)
+## 5. Feature Documentation (docs/features/{feature}.md)
 
 Use for: every feature in `docs/features/`. The same file persists from design (Status: Draft) through implementation to live reference (Status: Active). Sections fill in as the feature matures — no template swap.
 
@@ -514,7 +437,7 @@ Resolved Open Questions can be summarized into Background; unresolved ones stay
 
 ---
 
-## 7. Changelog
+## 6. Changelog
 
 Use for: recording code changes with function-level detail.
 
@@ -563,11 +486,11 @@ Brief description of what changed and why.
 
 ---
 
-## 8. Plan (docs/history/plans/YYYY-MM-DD-feature-name.md)
+## 7. Plan (docs/history/plans/YYYY-MM-DD-feature-name.md)
 
 Use for: every implementation plan. Plans are created here directly with `Status: Draft`, flip to `Status: In Progress` when work starts, and freeze at `Status: Complete` or `Status: Abandoned`. Once frozen, never edit — write a new dated plan if scope changes.
 
-The `boundary` skill (`check` mode) parses the **Proposed Changes** sections to check boundary impact. Keep that structure stable — section headings and bullet shape are load-bearing for the parser.
+The `boundary` skill parses the **Proposed Changes** sections to check boundary impact before execution. Keep that structure stable — section headings and bullet shape are load-bearing for the parser.
 
 ```
 # {Feature Name}
@@ -603,7 +526,7 @@ Why this work is happening *now*. Link to the spec for *what* we're building; th
 
 ### Cross-Module Contracts Affected
 
-- List which boundaries (from `docs/boundaries/`) this plan touches by name
+- List which cross-cutting contracts this plan touches (db schema, wire envelope, auth, events, env/config, …)
 - "None" is a valid answer and means the `boundary` check will pass cleanly
 
 ## Implementation Steps
@@ -630,7 +553,7 @@ Why this work is happening *now*. Link to the spec for *what* we're building; th
 
 ---
 
-## 9. Protected Files
+## 8. Protected Files
 
 Use for: documenting critical files that need approval before modification.
 
@@ -675,7 +598,7 @@ path/to/another/file.js
 
 ---
 
-## 10. Architecture Decision Record (ADR)
+## 9. Architecture Decision Record (ADR)
 
 Use for: capturing a single, point-in-time architectural decision with its context, alternatives considered, and consequences. Lives in `docs/architecture/adr/`.
 
@@ -792,7 +715,7 @@ tags: [adr]
 
 ---
 
-## 11. Project Root README
+## 10. Project Root README
 
 Use for: the human-facing entry point at the repository root (`/README.md`) — what visitors and new contributors land on. Distinct from `docs/README.md` (the agent/doc index — see §1). The two coexist; don't merge them.
 
@@ -899,7 +822,7 @@ The baseline audit **does** scaffold the project root README when missing. The r
 
 ---
 
-## 12. Memory inbox entry (docs/memory/inbox/{actor}.md)
+## 11. Memory inbox entry (docs/memory/inbox/{actor}.md)
 
 Use for: the capture tier of the knowledge gradient — the durable lessons of each session (corrections, root-caused failures, decisions with rationale, discovered constraints), reflected by the `session-reflect` hook at session end. It is the raw input to distillation: `distiller facts` digests entries into fact-cards and **consumes** them, so the file holds exactly what is undigested.
 

package/data/harnesses/discover/harness.json

@@ -3,5 +3,5 @@
   "name": "discover",
   "version": "0.1.7",
   "epoch": null,
-  "digest": "9617ebd1d5c1"
+  "digest": "459be63d0534"
 }

package/data/harnesses/discover/rules/evaluation.md

@@ -34,6 +34,15 @@ published SDK source) that calls the same routes is **independent of both market
 wrapper**, and corroborates it → promotes. (A legacy/granular route family seen only in a third-party
 MCP becomes a real finding once the official OSS client calls it too.)
 
+**Open-core lineage as an absence oracle (independent corroboration of the open/closed seam).** When a
+target is an **open-core product with a closed cloud edition** (a clonable `codebase` lineage repo + a
+closed `session` runtime), a feature **verified ABSENT in the lineage repo** (grep/structure-map) **and
+observed PRESENT in the cloud session** is **two independent lanes agreeing on the *seam*** → promotes the
+open/closed-boundary claim to fact (the cloud-feature value itself stays a direct `session` observation).
+The lineage repo is as useful as an *absence map* (what is NOT in the open floor) as it is a presence map;
+"verified-absent-in-CE + observed-in-cloud" is independent of marketing and of the session alone. (Origin:
+Akeneo — Reference Entities / DAM / Rules / Workflows observed in Serenity + grep-absent in Community Edition.)
+
 **Closed-feedback confidence cap.** When the `community` dimension finds **no first-party feedback
 loop** (no public issues / roadmap / changelog / forum — feedback funnelled to a gated channel), its
 user-pain / most-requested-feature claims are **inference-from-changelog only → capped at
@@ -87,7 +96,10 @@ prose, not via a separate `claims.yaml`.)
                             a different, broader, differently-authed API than the published one: list ops the
                             app uses that the public API omits, AND public ops the app never calls — both are
                             findings. If there is NO published API, say so explicitly: "no published API — the
-                            app surface is the only surface" is itself the finding, not an empty section.)
+                            app surface is the only surface" is itself the finding, not an empty section.
+                            REQUIRES paired inputs (ingestion §6): the pre-nav in-page tap [session app-own
+                            paths] + the unauth bundle/route-manifest [published paths]. Missing a lane → the
+                            diff is un-feedable; say which lane is absent rather than implying overlap.)
 ## Auth & tenancy model   (token type, where it lives, scope expression)
 ## API-path diff (adaptive, N-way over the runtime sources present)  (the seam rule: bundle-declared vs
                             session-observed vs wire-observed. Title it for the sources ACTUALLY run —

package/data/harnesses/discover/rules/ingestion.md

@@ -156,6 +156,21 @@ flags**. To keep them consumable instead of triplicated **N times** (a real run
 > public operations the app never calls, are both findings. The published surface is the integration
 > story; the runtime surface is the real architecture. When a published API exists, Evaluation emits
 > this split as a *named* output, not inline prose (evaluation template 3).
+>
+> **Paired inputs make the diff feedable (capture cue).** The split is only emittable if BOTH lanes were
+> captured: when a target has **a published API AND an authed session**, the **pre-nav in-page fetch/XHR
+> tap** (`session` — the app-own paths it actually calls) and the **unauth bundle/route-manifest**
+> (`deployed-client-bundle` — the published paths) are **paired required inputs**. Install the tap *before*
+> navigation (else on-load app calls are missed) and capture the manifest unauth; a session that only
+> screenshots, or a bundle mine with no session, leaves the diff un-feedable. (Origin: Akeneo — 54
+> session-observed app-own paths vs a 124-path unauth `/api/rest/v1` manifest, near-disjoint.)
+>
+> **Host-level dimensions cite, they don't append (seam allowlist).** The shared `api-path-catalog.md`
+> `## source:` allowlist is **bundle / session / wire / distribution** only — the path-contributing
+> runtime lanes. A host-level dimension (`infra-backend-fingerprint`) that wants to cross-reference the
+> catalog does so **from its own `raw/`** (cite hosts/paths by reference), and does **not** append its own
+> `## source:` section to the shared file. (Origin: Akeneo — infra appended a host-level note to the path
+> catalog; benign but blurs the allowlist.)
 
 ---