@nurix/etna 0.16.0 → 0.17.1

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/.prettierignore

@@ -0,0 +1,12 @@
+# Dependencies & build output
+node_modules
+dist
+build
+
+# Lockfiles
+pnpm-lock.yaml
+package-lock.json
+yarn.lock
+
+# Harness-managed agent/skill definitions (installed under .claude/)
+.claude

package/data/harnesses/discover/.prettierrc.json

@@ -0,0 +1,3 @@
+{
+  "proseWrap": "never"
+}

package/data/harnesses/discover/.vscode/settings.json

@@ -0,0 +1,10 @@
+{
+  // Markdown: Prettier unwraps prose to one logical line per paragraph
+  // (see .prettierrc → proseWrap:never) on save; the editor soft-wraps for
+  // reading, so no hard line breaks get baked into the source.
+  "[markdown]": {
+    "editor.defaultFormatter": "esbenp.prettier-vscode",
+    "editor.formatOnSave": true,
+    "editor.wordWrap": "on"
+  }
+}

package/data/harnesses/discover/harness.json

@@ -3,5 +3,10 @@
   "name": "discover",
   "version": "0.1.7",
   "epoch": null,
-  "digest": "9617ebd1d5c1"
+  "files": [
+    ".prettierrc.json",
+    ".prettierignore",
+    ".vscode/settings.json"
+  ],
+  "digest": "bd18173c697a"
 }

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.)
 
 ---
 

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

@@ -478,6 +478,19 @@ Inferences from `localStorage` / `sessionStorage` / cookie / IndexedDB **key nam
 | **Opaque session cookie** (HttpOnly, same-origin, auto-attached) | No `Authorization` header anywhere on the SPA; the cookie auto-attaches because all API is same-origin. **The negative finding is the tell.** | No |
 | **Firebase ID token in IndexedDB** | `firebaseLocalStorageDb` → `stsTokenManager.accessToken`; Firebase Modular SDK v9+ store; short-lived (3600 s) + auto-refreshed. Confirm the Bearer model with one Firestore REST `GET documents/users/{uid}`. | Partially (IDB is JS-reachable, but token is short-lived + refreshed) |
 
+> **Same-origin replay — mine an opaque-session-cookie API without ever reading the cookie.** When the
+> taxonomy lands on **opaque session cookie** above (no `Authorization`, no JS-readable token, no CSRF
+> meta — a server-session app: Symfony/PHP, Rails, Django, classic ASP.NET), the *absence* in JS storage
+> **is** the positive fingerprint, not a dead end. Mine it with **in-page `fetch(path, {credentials:'same-origin'})`
+> replay from the app origin**: the browser auto-attaches the httpOnly cookie, so once the in-page tap has
+> revealed an endpoint you replay it for verbatim read bodies (and, Pass-2-gated, write bodies) **without
+> ever reading, returning, or writing the cookie value** — the secret never reaches the harness, which is
+> what keeps this inside the §7 ethics line. You do **not** need raw CDP `Network` for this case (it would
+> only add the literal `Cookie`/request headers, which you'd redact anyway); the in-page fetch/XHR tap +
+> same-origin replay is the complete tool. Reach for raw CDP only to reconstruct exact request headers for
+> an *out-of-browser* reproducer, or for non-`fetch` transports (WS frames). (Origin tag: Akeneo — httpOnly
+> `BAPID` Symfony session, 54-path internal API mined entirely by same-origin replay.)
+
 **Key claims to look for in the JWT payload** (decode *structure* only — redact `sub`/`email`/`session_id`/`provider_id`, never log the signature):
 
 | Claim | What it tells you |

package/data/harnesses/hr/.prettierignore

@@ -0,0 +1,12 @@
+# Dependencies & build output
+node_modules
+dist
+build
+
+# Lockfiles
+pnpm-lock.yaml
+package-lock.json
+yarn.lock
+
+# Harness-managed agent/skill definitions (installed under .claude/)
+.claude

package/data/harnesses/hr/.prettierrc.json

@@ -0,0 +1,3 @@
+{
+  "proseWrap": "never"
+}

package/data/harnesses/hr/.vscode/settings.json

@@ -0,0 +1,10 @@
+{
+  // Markdown: Prettier unwraps prose to one logical line per paragraph
+  // (see .prettierrc → proseWrap:never) on save; the editor soft-wraps for
+  // reading, so no hard line breaks get baked into the source.
+  "[markdown]": {
+    "editor.defaultFormatter": "esbenp.prettier-vscode",
+    "editor.formatOnSave": true,
+    "editor.wordWrap": "on"
+  }
+}

package/data/harnesses/hr/harness.json

@@ -3,5 +3,10 @@
   "name": "hr",
   "version": "0.1.1",
   "epoch": null,
-  "digest": "dfc7c529bbec"
+  "files": [
+    ".prettierrc.json",
+    ".prettierignore",
+    ".vscode/settings.json"
+  ],
+  "digest": "95bc2ce3024d"
 }

package/data/harnesses/kb-agi/.prettierignore

@@ -0,0 +1,12 @@
+# Dependencies & build output
+node_modules
+dist
+build
+
+# Lockfiles
+pnpm-lock.yaml
+package-lock.json
+yarn.lock
+
+# Harness-managed agent/skill definitions (installed under .claude/)
+.claude

package/data/harnesses/kb-agi/.prettierrc.json

@@ -0,0 +1,3 @@
+{
+  "proseWrap": "never"
+}

package/data/harnesses/kb-agi/.vscode/settings.json

@@ -0,0 +1,10 @@
+{
+  // Markdown: Prettier unwraps prose to one logical line per paragraph
+  // (see .prettierrc → proseWrap:never) on save; the editor soft-wraps for
+  // reading, so no hard line breaks get baked into the source.
+  "[markdown]": {
+    "editor.defaultFormatter": "esbenp.prettier-vscode",
+    "editor.formatOnSave": true,
+    "editor.wordWrap": "on"
+  }
+}

package/data/harnesses/kb-agi/harness.json

@@ -3,5 +3,10 @@
   "name": "kb-agi",
   "version": "0.10.1",
   "epoch": null,
-  "digest": "856a9f4e297a"
+  "files": [
+    ".prettierrc.json",
+    ".prettierignore",
+    ".vscode/settings.json"
+  ],
+  "digest": "25e1cb993a7f"
 }

package/package.json

@@ -1,11 +1,14 @@
 {
     "name": "@nurix/etna",
-    "version": "0.16.0",
+    "version": "0.17.1",
     "description": "Bootstrap a project with a Nurix harness — copies the harness's CLAUDE.md, skills, agents, rules, and hooks directly into the project from a bundled payload (no marketplace fetch, no network).",
     "type": "module",
     "bin": {
         "etna": "bin/etna.js"
     },
+    "dependencies": {
+        "@clack/prompts": "^0.11.0"
+    },
     "files": [
         "bin/",
         "data/",