@nurix/etna 0.18.15 → 0.18.16

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

@@ -112,7 +112,7 @@ Plan (Status: Draft) → Implementation → Feature Doc or Architecture Update
 
 ## Folder Rules
 
-- `docs/features/`: Living reference for implemented features. Each feature doc **carries** the `owns:` / `module:` / `keywords:` / `status:` frontmatter — `owns:` declares the code-path globs it owns (the only ownership key), `module:` is an optional bounded-context label, `keywords:` are discovery terms, `status:` is `active`/`draft`/`deprecated`. The SessionStart hook unions every feature's `owns:` globs into the injected ownership index. (An optional `anchors:` block — a qmd drift tripwire, see §3 — is a separate tooling key a doc may additionally carry.)
+- `docs/features/`: Living reference for implemented features. Each feature doc **carries** the `owns:` / `module:` / `keywords:` / `status:` frontmatter — `owns:` declares the code-path globs it owns (the only ownership key), `module:` is an optional bounded-context label, `keywords:` are discovery terms, `status:` is `active`/`draft`/`deprecated`. The SessionStart hook unions every feature's `owns:` globs into the injected ownership index.
 - `docs/architecture/`: System-wide patterns and the cross-module steering layer (domain model, glossary, non-goals, references, ADRs). A module's cross-cutting prose lives here (or in a browse-folder `Readme.md`). Update when cross-cutting concerns change.
 - `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.
@@ -131,21 +131,10 @@ Plan (Status: Draft) → Implementation → Feature Doc or Architecture Update
 
 ---
 
-## 3. Code-Path Ownership & Anchors
+## 3. Code-Path Ownership
 
 **Ownership.** A feature doc is the canonical reference for the code paths in its **`owns:` frontmatter** — the only ownership key. To find what a doc owns, read its `owns:` globs; to find the doc for a path, match the path against the injected ownership index (the union of every feature's `owns:` globs), narrower glob wins. See **Frontmatter Derivation** in `SKILL.md` for turning code into `owns:` globs.
 
-**Anchors (optional tooling key).** A doc may additionally carry an `anchors:` block — a qmd drift tripwire, orthogonal to ownership:
-
-```yaml
----
-anchors:
-  - "qmd query: feature-name persistence shape"
----
-```
-
-`anchors` is an optional list of qmd queries (or `#docid`s) that re-resolve to the code a doc abstracts as it moves. It is a drift tripwire, never a contract — an anchor that returns nothing IS the drift signal, and nothing auto-rewrites from an anchor result. It is read on demand by the maintenance anchor-drift check, never injected, and inert when qmd is absent.
-
 ---
 
 ## 4. Scaffold Files (create if missing)
@@ -241,14 +230,6 @@ description: Shared knowledge accumulated across agent sessions. All agents shou
 - **Spec version:** v{harness-version}
 <!-- v{harness-version} resolves to the installed harness version — read it from `.claude/harness.json` (`version`) / `docs/structure.md` frontmatter (`harness-version`); never hardcode a literal version here. -->
 
-## Knowledge Tiers
-
-Memory is a gradient — volume falls, signal rises, one hop down each tier. Tiers describe themselves here even before they fill:
-
-- **Inbox** (`docs/memory/inbox/`) — per-actor queue of session lessons, written by the `session-reflect` hook at session end and consumed by the distiller on digestion. Transient by design, rarely read directly.
-- **Fact-cards** (`docs/memory/facts/`) — distilled, provenance-linked atomic facts, written by the distiller (`facts` mode) from inbox entries and resurfaced at prompt time by the `prompt-recall` hook.
-- **This index** — the curated read tier: the learnings list below, distilled from the colder tiers and hand-appended.
-
 ## Learnings
 
 {Agents append learnings here as they discover gotchas, patterns, and architecture notes}
@@ -278,15 +259,13 @@ 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 **§11 Memory inbox entry** for its format.
-
 ---
 
-## 5. Feature Documentation (docs/features/{feature}.md)
+## 5. Feature Documentation — the LLD (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.
+Use for: every feature in `docs/features/`. The feature doc is the feature's **LLD (low-level design)**: the same file persists from design (Status: Draft, written in LLD Mode) through implementation to live reference (Status: Active). Sections fill in as the feature matures — no template swap.
 
-The four research-derived sections (**Affected Modules**, **Conventions to Follow**, **Current Behavior**, **Ownership Conflicts**) map 1:1 to spec-mode's return shape. The orchestrator drops spec-mode's findings into those slots without restructuring.
+The four research-derived sections (**Affected Modules**, **Conventions to Follow**, **Current Behavior**, **Ownership Conflicts**) map 1:1 to the `lld-mode` agent's return shape. The orchestrator drops its findings into those slots without restructuring.
 
 ```yaml
 ---
@@ -294,8 +273,6 @@ owns: ["src/feature/**", "src/other/file.ts"]   # required — code-path globs t
 module: billing                                  # optional — single bounded-context label; omit if cross-cutting
 keywords: [invoice, pdf]                         # required — discovery terms
 status: active                                   # required — active | draft | deprecated
-anchors:                                         # optional extra — a qmd drift tripwire; see §3
-  - "qmd query: wire envelope invariants"
 ---
 ```
 
@@ -332,22 +309,22 @@ High-level shape of the solution. ASCII diagram if it helps. Implementation spec
 
 ## Affected Modules
 
-(From spec-mode research) Files, routes, components, slices this feature involves. Group by module.
+(From lld-mode research) Files, routes, components, slices this feature involves. Group by module.
 
 | Module | Path | Role in this feature |
 |--------|------|----------------------|
 
 ## Conventions to Follow
 
-(From spec-mode research) Naming patterns, structural patterns, doc-fit heuristics confirmed for the area being touched. Cite the source file(s) where the convention is established.
+(From lld-mode research) Naming patterns, structural patterns, doc-fit heuristics confirmed for the area being touched. Cite the source file(s) where the convention is established.
 
 ## Current Behavior
 
-(From spec-mode research) How the relevant part of the system works *today*, before this feature lands. Without this baseline the design intent is hard to evaluate.
+(From lld-mode research) How the relevant part of the system works *today*, before this feature lands. Without this baseline the design intent is hard to evaluate.
 
 ## Ownership Conflicts
 
-(From spec-mode research) Existing feature docs whose `owns:` globs overlap with the projected scope. Resolve before the plan starts — leave nothing unresolved.
+(From lld-mode research) Existing feature docs whose `owns:` globs overlap with the projected scope. Resolve before the plan starts — leave nothing unresolved.
 
 | Conflicting doc | Overlapping path(s) | Resolution |
 |-----------------|---------------------|------------|
@@ -426,7 +403,7 @@ Sections fill in across the feature's lifecycle. No template swap — they accum
 | When | Sections written | Source |
 | --- | --- | --- |
 | Status: Draft (design) | Goal, Goals & Non-Goals, Background, Approach, Open Questions, Risks | User interview |
-| Status: Draft (research) | Affected Modules, Conventions to Follow, Current Behavior, Ownership Conflicts | spec-mode agent |
+| Status: Draft (research) | Affected Modules, Conventions to Follow, Current Behavior, Ownership Conflicts | lld-mode agent |
 | Status: Draft → Active (implementation lands) | Architecture, Key Functions, State, Redux, Files; `owns:` globs confirmed against real code | Main agent (from actual code) |
 
 Resolved Open Questions can be summarized into Background; unresolved ones stay visible.
@@ -807,47 +784,3 @@ The full surface lives in [`{path/to/public-index}`]({path/to/public-index}).
 The baseline audit **does** scaffold the project root README when missing. The risk this template guards against — template-shaped placeholders that look abandoned — is mitigated by the writing rules above: fill every section with concrete details from the repo (real package manager from the lockfile, real scripts, real layout, real status). Skip sections that genuinely don't apply rather than leaving stubs.
 
 **Never overwrite an existing root README** during a baseline. If one is present — even sparse or outdated — leave it untouched. Treat updates to a pre-existing root README as a separate, explicit request.
-
----
-
-## 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.
-
-### File grain
-
-One file **per actor**: `docs/memory/inbox/{actor}.md`. `actor` is `git config user.name` lowercased and kebab-slugged; fall back to `$USER`, then `agent`. Two actors write to different files, so the inbox is **append-only without merge conflicts** — no shared file to contend over, no lock, no last-writer-wins.
-
-### File header
-
-Written once, on the first entry:
-
-```
-# Memory inbox — {actor}
-Session lessons awaiting distillation — appended by the session-reflect hook, consumed by `distiller facts`.
-```
-
-### Entry shape
-
-One block per reflected session, at most 6 bullets. Each bullet is one complete, self-contained sentence tagged `[project]` (true of the repo or its tooling) or `[user]` (true of the user) — the tag routes it at distillation: project facts → `docs/memory/facts/`, user facts → user-level memory.
-
-```
-## YYYY-MM-DD HH:MM · session <id> · {repo}@{branch}
-- [project] <one self-contained sentence, names and identifiers spelled out>
-- [user] <one self-contained sentence>
-```
-
-### Examples
-
-```
-## 2026-06-08 22:26 · session bc06c4fc · etna@dev
-- [project] The read_network_requests Chrome CDP tool only captures after its first call — arm it, trigger traffic, then read.
-- [user] jane-doe prefers minimal fixes over defensive machinery; fail loudly instead of engineering around a problem.
-```
-
-### Rules
-
-- **Hooks append, the distiller consumes.** A digested entry block is deleted by `distiller facts`; nothing else edits or reorders the file. A human may hand-append a lesson in the same shape — it rides the same queue.
-- **Sessions are deduped by id.** The reflect hook skips a session whose id already appears in the file (SessionEnd re-fires on resume).
-- **Secrets are redacted on write.** The privacy filter replaces secret shapes with `[redacted:{kind}]` (e.g. `[redacted:api-key]`, `[redacted:bearer]`, `[redacted:pem]`) before any line is appended — never paste a raw token in by hand either.
-- **Don't curate here.** Promotion to fact-cards and `docs/memory/main.md` happens at distillation; the inbox stays a transient queue.

package/data/harnesses/etna/CLAUDE.md

@@ -20,20 +20,20 @@ This file defines how AI agents (Claude, GPT, etc.) should work on this project.
 
 ## Workflows
 
-For new features or new systems, enter **Spec Mode** before Plan Mode.
+For new features or new systems, enter **LLD Mode** (low-level design) before Plan Mode.
 
-### Spec Mode → Plan Mode → Completion
+### LLD Mode → Plan Mode → Completion
 
-1. **Spec Mode**: Create or update a feature spec in `docs/features/{feature}.md` using the **Feature Documentation template** (Status: Draft) — see `.claude/skills/documentation/references/templates.md` §6. Use the **`spec-mode`** agent (`.claude/agents/spec-mode.md`) for codebase research; its findings drop directly into the template's research-derived sections (Affected Modules, Conventions to Follow, Current Behavior, Ownership Conflicts). Interview the user for the design-intent sections (Goal, Goals & Non-Goals, Background, Approach). Present the spec for approval before proceeding.
+1. **LLD Mode**: Create or update the feature LLD in `docs/features/{feature}.md` using the **Feature Documentation template** (Status: Draft) — see `.claude/skills/documentation/references/templates.md` §6. Use the **`lld-mode`** agent (`.claude/agents/lld-mode.md`) for codebase research; its findings drop directly into the template's research-derived sections (Affected Modules, Conventions to Follow, Current Behavior, Ownership Conflicts). Interview the user for the design-intent sections (Goal, Goals & Non-Goals, Background, Approach). Present the LLD for approval before proceeding.
 
-2. **Plan Mode**: Once the spec is approved, create a plan in `docs/history/plans/YYYY-MM-DD-feature-name.md` using the **Plan template** (see `.claude/skills/documentation/references/templates.md` §8). Link back to the feature spec in the **Spec** field. The template's **Proposed Changes** sections are load-bearing — the `boundary` skill parses them to check boundary impact.
+2. **Plan Mode**: Once the LLD is approved, create a plan in `docs/history/plans/YYYY-MM-DD-feature-name.md` using the **Plan template** (see `.claude/skills/documentation/references/templates.md` §8). Link back to the feature LLD in the **Spec** field. The template's **Proposed Changes** sections are load-bearing — the `boundary` skill parses them to check boundary impact.
 
 3. **Completion**: When a plan is fully implemented:
    - Mark the plan `Status: Complete` in `docs/history/plans/` and fill the **Completed:** date. The plan is now frozen.
-   - **Flip the feature spec** to `status: active` and extend it in place with the implementation sections (Architecture, Key Functions, State, Redux, Files). No template swap — the same file gains sections describing how the feature _works_ alongside the design-intent sections that explain _why_. Confirm the feature's `owns:` globs against actual code; resolve any unresolved Open Questions by folding them into Background.
+   - **Flip the feature LLD** to `status: active` and extend it in place with the implementation sections (Architecture, Key Functions, State, Redux, Files). No template swap — the same file gains sections describing how the feature _works_ alongside the design-intent sections that explain _why_. Confirm the feature's `owns:` globs against actual code; resolve any unresolved Open Questions by folding them into Background.
    - Use the injected ownership index to find other docs affected by the changes (and update the `owns:` globs of any feature doc whose source you moved or added). Update affected docs — or create new ones if a touched area has no doc yet.
 
-For **Product-level** work (new systems, unclear scope), the spec should also include: problem statement, key hypotheses, and open questions.
+For **Product-level** work (new systems, unclear scope), the LLD should also include: problem statement, key hypotheses, and open questions.
 
 `docs/features/` is _what_ we're building (lives on as documentation). `docs/history/plans/` is _how_ we built it (historical record).
 
@@ -42,9 +42,8 @@ For **Product-level** work (new systems, unclear scope), the spec should also in
 Before modifying code in an unfamiliar area:
 
 1. Consult the **injected ownership index** — the generated `glob → doc · module · keywords · status` map, surfaced into context at session start (the union of every feature doc's `owns:` frontmatter). Match your path or topic (its `keywords:`) to the owning doc and read it before changes. (If no ownership index appears in context, the repo isn't reconciled — run `maintenance` in baseline mode to reconcile it.)
-2. If `qmd` is installed, run `qmd query --format json -c <collection> "<topic>"` for semantic recall over the indexed docs — prefer it when entering an unfamiliar area; absent ⇒ skip.
-3. If your change touches a cross-cutting contract area (entity model, db schema, wire envelope, auth/authz, event vocabulary, webhooks, env/config), run the **`boundary`** skill scoped to your change — it reads both sides of each touched contract in source and reports what would break.
-4. If a `docs/memory/` file exists for the domain you're working in, read it for domain knowledge and failure modes
+2. If your change touches a cross-cutting contract area (entity model, db schema, wire envelope, auth/authz, event vocabulary, webhooks, env/config), run the **`boundary`** skill scoped to your change — it reads both sides of each touched contract in source and reports what would break.
+3. If a `docs/memory/` file exists for the domain you're working in, read it for domain knowledge and failure modes
 
 For the protocol on _writing_ to memory (which file, what belongs there, what doesn't), see **Project Memory** below.
 
@@ -72,9 +71,9 @@ When implementing a plan, if you discover work that is important but outside the
 
 ### Doc Ownership
 
-Which doc is canonical for which code paths is the **feature doc's own frontmatter**. A feature doc (flat in `docs/features/`) carries `owns:` (code-path globs — the only ownership key), `module:` (a bounded-context label, omitted when cross-cutting), `keywords:` (discovery), and `status:`. Code → doc ownership is the union of every feature doc's `owns:` globs, surfaced as the generated ownership index at session start. Architecture docs describe cross-cutting patterns and don't own specific files; operations docs describe procedures. A living doc may additionally carry an optional `anchors:` block (a qmd drift tripwire, not ownership).
+Which doc is canonical for which code paths is the **feature doc's own frontmatter**. A feature doc (flat in `docs/features/`) carries `owns:` (code-path globs — the only ownership key), `module:` (a bounded-context label, omitted when cross-cutting), `keywords:` (discovery), and `status:`. Code → doc ownership is the union of every feature doc's `owns:` globs, surfaced as the generated ownership index at session start. Architecture docs describe cross-cutting patterns and don't own specific files; operations docs describe procedures.
 
-The spec-mode agent checks for ownership conflicts during research — feature docs whose `owns:` globs overlap at equal specificity. If conflicts are found, address them in the spec before proceeding.
+The `lld-mode` agent checks for ownership conflicts during LLD research — feature docs whose `owns:` globs overlap at equal specificity. If conflicts are found, address them in the LLD before proceeding.
 
 ---
 
@@ -82,7 +81,7 @@ The spec-mode agent checks for ownership conflicts during research — feature d
 
 A boundary is a horizontal cross-cutting contract — entity model, db schema, wire envelope, auth/authz, event vocabulary, webhooks, env/config — where editing one side silently breaks the other. Boundaries are **diagnosed, not documented**: the `boundary` skill reads them fresh from source whenever a check runs, so they are never persisted as docs and can never go stale.
 
-**Invoke the `boundary` skill after a plan is approved and before its first implementation step.** It parses the plan's Proposed Changes, reads the touched source files, identifies the contracts they participate in (its `references/boundary-taxonomy.md` is the catalog), traces the consumers on the other side, and reports severity-ranked violations with suggested plan amendments — in chat, read-only. Fold the amendments into the plan before coding. For non-plan edits in contract-heavy code, run the same diagnostic scoped to the diff.
+**Invoke the `boundary` skill after a plan is approved and before its first implementation step.** It parses the plan's Proposed Changes, reads the touched source files, identifies the contracts they participate in (its `references/mechanisms.md` defines the failure mechanisms; technology packs under `references/packs/` carry stack specifics), traces the consumers on the other side, and reports severity-ranked violations with suggested plan amendments — in chat, read-only. Fold the amendments into the plan before coding. For non-plan edits in contract-heavy code, run the same diagnostic scoped to the diff.
 
 > Agents and skills live under `.claude/agents/` and `.claude/skills/`. Their triggers are model-invoked — refer to each component's frontmatter, not a registry table here.
 

package/data/harnesses/etna/agents/{spec-mode.md → lld-mode.md}

@@ -1,33 +1,33 @@
 ---
-name: spec-mode
-description: Specification researcher for Feature and Product workflows. Use to explore the codebase and gather context needed for writing feature specs. Returns research findings — does not write files.
+name: lld-mode
+description: LLD researcher for Feature and Product workflows. Use to explore the codebase and gather the context needed for writing a feature LLD (low-level design — the feature doc in docs/features/). Returns research findings — does not write files.
 tools: Read, Glob, Grep, WebSearch, WebFetch
 model: inherit
 skills:
   - documentation
 ---
 
-# Spec Mode Agent
+# LLD Mode Agent
 
-You are a specification researcher. Your job is to explore the codebase and gather everything needed to write a feature spec in `docs/features/`.
+You are an LLD researcher. Your job is to explore the codebase and gather everything needed to write a feature LLD (low-level design) in `docs/features/`.
 
-You do NOT write the spec — you return structured research that the main agent uses to write it.
+You do NOT write the LLD — you return structured research that the main agent uses to write it.
 
 ## Before Starting
 
 First, understand the documentation landscape:
 
 1. Read `./docs/structure.md` to understand the documentation structure
-2. If `./docs/features/README.md` exists, read it to see existing feature specs and where the new spec fits; otherwise glob the feature docs directly
-3. If `./docs/memory/spec-mode.md` exists, read it for feature doc inventory, ownership conflict zones, and lessons from previous research
-4. Read 1-2 existing specs in `./docs/features/` to calibrate format and depth
+2. If `./docs/features/README.md` exists, read it to see existing feature LLDs and where the new one fits; otherwise glob the feature docs directly
+3. If `./docs/memory/lld-mode.md` exists (or the legacy `./docs/memory/spec-mode.md`), read it for feature doc inventory, ownership conflict zones, and lessons from previous research
+4. Read 1-2 existing feature LLDs in `./docs/features/` to calibrate format and depth
 5. Consult the **injected ownership index** (the generated `glob → doc · module · keywords · status` map — the union of every feature doc's `owns:` frontmatter) to build the ownership map. This is the source of truth for what code paths are already owned. If the index isn't present in context, glob `docs/features/**/*.md` and read each doc's `owns:` frontmatter directly.
 
-This tells you what already exists, what's adjacent, how detailed the spec should be, and what code paths are already owned.
+This tells you what already exists, what's adjacent, how detailed the LLD should be, and what code paths are already owned.
 
 ## What You Research
 
-1. **Documentation fit** — Where does this spec sit relative to existing feature docs? Does it extend an existing spec or need a new one?
+1. **Documentation fit** — Where does this LLD sit relative to existing feature docs? Does it extend an existing one or need a new doc?
 2. **Existing patterns** — Find related features, similar implementations, and conventions in the codebase
 3. **Affected modules** — Identify what files, routes, components, and data flows are relevant
 4. **Current state** — Understand how the system works today in the area being specified
@@ -38,13 +38,13 @@ This tells you what already exists, what's adjacent, how detailed the spec shoul
 
 Structure your findings as:
 
-- **Documentation context**: Existing specs that relate, whether to create new or update existing, suggested filename
+- **Documentation context**: Existing feature LLDs that relate, whether to create new or update existing, suggested filename
 - **Related patterns**: What similar things exist in the codebase and where
 - **Affected modules**: Files, routes, components that will be involved
 - **Current behavior**: How the relevant part of the system works today
 - **Conventions**: Naming, structure, and patterns to follow based on existing code
 - **Ownership conflicts**: Existing feature docs whose `owns:` globs overlap with the proposed feature. Include the conflicting paths and the owning doc name.
-- **Risks or concerns**: Anything the spec should address or call out
+- **Risks or concerns**: Anything the LLD should address or call out
 
 Use the documentation skill's style guide and conventions when structuring your findings — imperative voice, ASCII diagrams for flows, function signatures over implementations, concise.
 

package/data/harnesses/etna/agents/maintenance.md

@@ -108,20 +108,6 @@ For unowned code paths:
 1. Update `docs/structure.md` Health Log with today's date and summary.
 2. Update `docs/memory/maintenance.md` with last review date, stale docs fixed, unowned paths, backlog items created.
 3. Report findings: stale docs, broken ownership, unowned code, architecture drift, backlog health.
-4. **Inbox-distillation threshold.** Count undigested inbox entries — `## ` entry blocks across `docs/memory/inbox/*.md` (the inbox is consume-on-digest, so every block present is undigested). If the count is **≥5**, add one line to the report **proposing** a `distiller facts` run — propose only, never auto-run, no cron. If the user declines or ignores it, do nothing: the count keeps growing and the proposal reappears next pass — that recurrence _is_ the dedupe, so never backlog it.
-5. **Docs-distillation threshold.** Per target doc, count undigested fact-cards (`invalid_from: null`, the doc's path not in their `digested_into:`) that **touch** it by the structural intersection in `skills/distiller/references/docs-mode.md` Resolution 1 (provenance ∩ the doc's `owns:` globs strong, entities ∩ declared ownership supporting — qmd-independent). If **≥10** map to **one** doc, add one line to the report **proposing** a `distiller docs --doc <path>` run on that doc — propose only, never auto-run, no cron. Declined or ignored ⇒ the count keeps growing and the proposal reappears next pass; that recurrence _is_ the dedupe, so never backlog the proposal.
-
-### Step 7: Refresh index (optional, skip-if-absent)
-
-If the `qmd` binary is available (`command -v qmd`), re-run `qmd embed -c <collection>` once per `{repo}-*` collection (`{repo}` = the repo's directory name; `qmd collection list` shows the registered set — skip any absent) so the local docs index reflects the files this pass touched. Scope every run with `-c` — the qmd index is global (`~/.cache/qmd/` holds every repo's collections), so a bare `qmd embed` would re-embed unrelated repos' collections. If `qmd` is absent, skip silently — it's never required.
-
-### Step 8: Check anchor drift (optional, skip-if-absent)
-
-If `qmd` is absent (`command -v qmd` finds nothing), **skip this whole step silently** — it's never required. `anchors:` is a qmd-only tooling key; with no qmd it is inert.
-
-This catches **doc-area drift** — the subject the doc abstracts moving or vanishing from the indexed corpus. It does **not** catch a pure code rename that leaves the doc's prose unchanged (Step 2's named-referent check covers code-symbol drift; the two are complementary).
-
-Glob `docs/features/**/*.md`, `docs/architecture/**/*.md`, and `docs/operations/**/*.md` for docs carrying `anchors:` frontmatter. For each anchor query, resolve it with `qmd query --format json -c <collection> "<query>"` — repeat `-c` per relevant `{repo}-*` collection (no comma lists). If a query resolves to **nothing**, or to a result set that has **radically shifted** away from the area the doc describes, raise it as a drift finding **phrased as a question** and ask the user. On **yes**, dispatch the remediation sub-agent (the same yes-branch as Step 5). On **decline or no action**, append it to `docs/history/backlog.md` at the finding's own P0–P3 severity per the **Declined realignment** branch — same scale, deduped, never a gate.
 
 ---
 
@@ -148,7 +134,7 @@ docs/
 │   ├── changelog/         # Individual entries
 │   ├── plans/             # Implementation plans (Status field required)
 │   └── backlog.md         # Tracked work items by priority (P0-P3)
-├── memory/                # inbox/ (captured-lessons queue), facts/ (distilled cards), index.md, main.md, {agent}.md
+├── memory/                # index.md, main.md, {agent}.md — project knowledge + per-agent strategy memory
 └── tests/                 # Optional, author-maintained — create only if test docs exist
 ```
 
@@ -189,26 +175,11 @@ Scaffold missing mandated files **by calling the `documentation` skill for each
 
 - `docs/structure.md` (with `harness-version`), `docs/history/CHANGELOG.md`, `docs/history/backlog.md`, `docs/memory/index.md`, `docs/memory/main.md`, and the repo-root `README.md` (filled from the real lockfile/scripts/layout — **never overwrite an existing root README**).
 
-Scaffold `docs/memory/facts/` so the distilled tier has a home from day one: the `session-reflect` hook appends session lessons to the per-actor inbox at `docs/memory/inbox/{actor}.md` (not a scaffold — created mechanically on first reflection), and the `distiller` digests that queue down into fact-cards under `docs/memory/facts/`, consuming the entries it digests.
-
 ### Step B4 — Stamp the version
 
 Write `harness-version: <installed version>` (the semver from `.claude/harness.json`) into `docs/structure.md` frontmatter. This single field is the repo's baseline-and-version sentinel — there is no second marker (no `epoch`, no `docs/memory/index.md` "is-baselined" check).
 
-### Step B5 — Register the qmd retrieval lens (optional, skip-if-absent)
-
-Strictly optional and guarded on the binary — if `command -v qmd` finds nothing, **skip this entire step silently** (no error, no behavior change) and carry one advisory line into the hand-back: _"qmd not installed — semantic retrieval unavailable; the generated ownership index + `keywords:` discovery are active."_ The index is a **local rebuildable lens** — data stays in git; never commit index artifacts, and never use `qmd init` (the default global index keeps the repo clean).
-
-If the binary exists, register the docs subtrees once the tree is scaffolded. **Do not register one collection rooted at `docs/`** — qmd hard-codes the `**/*.md` pattern and has no exclude flag, so a `docs/`-root collection would sweep the consumable inbox queue at `docs/memory/inbox/` into the index (the inbox's entries are deleted on digestion, leaving dangling index entries). Register **per indexable subtree** (skip absent ones; `{repo}` = the repo's directory name; an existing name/path no-ops — treat as success):
-
-- `qmd collection add docs/features --name {repo}-features`
-- `qmd collection add docs/architecture --name {repo}-architecture`
-- `qmd collection add docs/operations --name {repo}-operations`
-- `qmd collection add docs/memory/facts --name {repo}-facts` (never `docs/memory` as a whole)
-
-Then `qmd context add` per registered collection and `qmd embed -c <name>` per collection (always scope with `-c`; a bare `qmd embed` re-embeds every repo's collections). This augments discovery; it never supersedes the `owns:`-glob ownership resolution.
-
-### Step B6 — Module proposal
+### Step B5 — Module proposal
 
 Modules are **labels, declared, never inferred from physical layout**. Derive the repo's candidate bounded contexts directly from the code and docs: distinct wire surfaces (who owns routes/handlers), schema/data-access ownership, entry points and process units, plus any contexts `docs/architecture/` already names.
 

package/data/harnesses/etna/harness.json

@@ -1,11 +1,11 @@
 {
   "harness": "etna",
   "name": "etna",
-  "version": "1.0.3",
+  "version": "1.1.1",
   "files": [
     ".prettierrc.json",
     ".prettierignore",
     ".vscode/settings.json"
   ],
-  "digest": "8adc30cd7fa2"
+  "digest": "018554d4192f"
 }

package/data/harnesses/etna/hooks/hooks.json

@@ -11,29 +11,6 @@
           }
         ]
       }
-    ],
-    "SessionEnd": [
-      {
-        "matcher": "",
-        "hooks": [
-          {
-            "type": "command",
-            "command": "node \"$CLAUDE_PROJECT_DIR/.claude/hooks/session-reflect.mjs\"",
-            "async": true
-          }
-        ]
-      }
-    ],
-    "UserPromptSubmit": [
-      {
-        "matcher": "",
-        "hooks": [
-          {
-            "type": "command",
-            "command": "node \"$CLAUDE_PROJECT_DIR/.claude/hooks/prompt-recall.mjs\""
-          }
-        ]
-      }
     ]
   }
 }

package/data/harnesses/etna/rules/testing.md

@@ -0,0 +1,25 @@
+# Testing
+
+Framework choice is never ad hoc and never the user's problem mid-task: detect the stack, use its row. If the repo already has a runner, that runner wins — never introduce a second framework beside it.
+
+## Frameworks by stack
+
+No alternatives. Just use these.
+
+| Stack | Unit / integration | Component | E2E | HTTP mocking | Don't use |
+| --- | --- | --- | --- | --- | --- |
+| Node + Vite / React (web) | vitest | @testing-library/react (+ @testing-library/user-event, happy-dom) | @playwright/test | msw | jest, mocha, jasmine, cypress, enzyme |
+| Express APIs | vitest | — | supertest against the app instance | msw (outbound calls) | jest, chai-http |
+| React Native / Expo | jest via the jest-expo preset | @testing-library/react-native | maestro | msw | detox, enzyme |
+| Cloudflare Workers | vitest + @cloudflare/vitest-pool-workers | — | @playwright/test against `wrangler dev` | msw | jest |
+| Rust | `cargo test` (built-in) | — | — | — | — |
+
+All npm packages at `latest`. Fake data comes from `@ngneat/falso` (the repo standard — never faker/chance).
+
+## Conventions
+
+- **Suite, not scripts.** Tests live in the canonical test tree (`tests/`, mirroring `src/`), named `<subject>.test.ts`. Shared fixtures, factories, and helpers live in `tests/helpers/`. The harness `CLAUDE.md` Tests guardrail carries the full suite-first policy; this rule owns only the technology choices.
+- **Wire the canonical command.** `"test"` in package.json runs the whole unit suite (`vitest run`); e2e runs under `"test:e2e"`. A repo where `pnpm test`/`npm test` doesn't run the suite is misconfigured.
+- **Unit and E2E trees stay separate.** Vitest/Jest suites in `tests/`; Playwright/Maestro suites in `e2e/` with their own config — never mixed into the unit runner's glob.
+- **No test doubles for what you own.** Prefer real instances — in-memory SQLite for drizzle, the actual Express app via supertest — over mocks; mock only true externals (network via msw, time via the runner's fake timers).
+- **Determinism.** No real network, no real time, no shared mutable state between tests; every test must pass alone and in any order.

package/data/harnesses/etna/skills/brainstorm/SKILL.md

@@ -102,7 +102,7 @@ The complexity dial sets _defaults_, not a cage: any lazy pillar materializes mi
 
 The background reconciler that replaces ceremony with consistency. **One sync in flight at a time; queue at most one behind it.**
 
-**When:** after a distillation batch lands substantive pillar writes (at the turn break, not mid-sentence); mandatorily on entering converge and at `stop`; on demand. At **low** complexity, run it inline yourself; at **medium+**, dispatch a background `general-purpose` agent (read/write access to the session folder only). Exception at any complexity: the `stop` sync's self-containment pass always dispatches the context-free agent — an inline reader with full conversational context cannot cold-read, because it already knows every undefined term.
+**When:** after a distillation batch lands substantive pillar writes (at the turn break, not mid-sentence); mandatorily on entering converge and at `stop`; on demand. At **low** complexity, run it inline yourself; at **medium+**, dispatch a background `general-purpose` agent **on Opus** (`model: "opus"` — pillar reconciliation is quality-critical, so never a smaller model; and never the main-loop frontier model, whose session budget belongs to the conversation), with read/write access to the session folder only. Exception at any complexity: the `stop` sync's self-containment pass always dispatches the context-free agent — an inline reader with full conversational context cannot cold-read, because it already knows every undefined term.
 
 **The filing checklist — before every dispatch.** The sync agent cannot see the conversation, so the orchestrator runs the transcript-side half itself, immediately before dispatching: list your substantive contributions since the last sync — analyses, diagnoses, recommendations with reasoning, definitions, rejections — and file any that aren't on disk (evidence note, decision rationale, glossary line, rejected entry). Only then dispatch. A sync dispatched over unfiled substance audits an incomplete record and stamps it green.
 

package/data/harnesses/etna/skills/brainstorm/exit-artifacts.md

@@ -58,5 +58,5 @@ Append a changelog entry at `docs/history/changelog/YYYY-MM-DD-brainstorm-{slug}
 
 **Keep `docs/brainstorm/{topic}/` — never delete it.** The exit artifacts now carry the distilled
 conclusions, but the record stays committed as their provenance: a traceable source for every published
-headline, the seed the next `/brainstorm start` on this topic resumes from, and a high-surprisal input the
-`distiller` ingests. Retire a topic's folder by hand only when the design line is truly dead.
+headline, and the seed the next `/brainstorm start` on this topic resumes from. Retire a topic's folder
+by hand only when the design line is truly dead.

package/data/harnesses/etna/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) record an architecture decision (ADR), (6) create or update the project root README, (7) create or update a plan, (8) derive a feature doc's `owns:` frontmatter (the code-path globs it owns) 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 **`maintenance` agent (baseline mode)** (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 (the feature doc is the feature's LLD — low-level design — written in LLD Mode), (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 a feature doc's `owns:` frontmatter (the code-path globs it owns) 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 **`maintenance` agent (baseline mode)** (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", "LLD".
 ---
 
 # Technical Documentation Skill
@@ -22,7 +22,7 @@ User request
     │
     ├─ "Baseline/reconcile docs" ──────▶ maintenance agent (baseline mode) (it calls this skill per template)
     │
-    ├─ "Document feature/module" ──────▶ Module Template
+    ├─ "Document feature/module (LLD)" ▶ Module Template
     │
     ├─ "Create/update changelog" ──────▶ Changelog Template
     │