@nurix/etna 0.1.2 → 0.1.3

package/bin/etna.js

@@ -74,12 +74,16 @@ function writeJson(path, value) {
 }
 
 // Register the marketplace in ~/.claude/settings.json (extraKnownMarketplaces).
-// Mirrors what `/plugin marketplace add <owner>/<repo>` writes.
+// Mirrors what `/plugin marketplace add <owner>/<repo>` writes, plus opts the
+// marketplace into auto-updates (off by default for non-Anthropic marketplaces).
 function registerMarketplace(marketplace) {
     const path = join(homedir(), '.claude', 'settings.json');
     const settings = readJson(path);
     settings.extraKnownMarketplaces = settings.extraKnownMarketplaces || {};
-    settings.extraKnownMarketplaces[marketplace.name] = { source: marketplace.source };
+    settings.extraKnownMarketplaces[marketplace.name] = {
+        source: marketplace.source,
+        autoUpdate: true,
+    };
     writeJson(path, settings);
     return path;
 }

package/data/harness-index.json

@@ -7,6 +7,7 @@
         }
     },
     "plugins": {
-        "nurix-harness": "code"
+        "nurix-harness": "code",
+        "kb-agi": "kb-agi"
     }
 }

package/data/harnesses/code/CLAUDE.md

@@ -73,6 +73,13 @@ Feature docs in `docs/features/` must include YAML frontmatter with `owns`, `tou
 
 The spec-mode agent checks for ownership conflicts during research. If conflicts are found, address them in the spec before proceeding.
 
+### Architecture Decisions (ADRs)
+
+Record an ADR when a decision (a) changes how state, dependencies, or boundaries are organized, (b) has a rejected alternative worth remembering, and (c) could plausibly be re-litigated. Default: don't write one. Style preferences, local refactors, and obvious-from-code choices don't qualify.
+
+- File: `docs/architecture/adr/NNNN-kebab-case.md` (4-digit sequential number). Frozen once written — supersede via a new ADR, never edit.
+- Invoke the `documentation` skill with "record an ADR" or "architecture decision".
+
 ---
 
 ## Agents
@@ -88,7 +95,7 @@ Seven sub-agents and three skills are defined under `.claude/`. Reach for them b
 | `dep-health` | Agent | Dependency supply-chain audit | "audit dependencies", "check CVEs", "dep health" |
 | `git-history` | Agent | Classify recent commits into a velocity/severity CSV | "classify commits", "commit history report" |
 | `change-review` | Agent | Velocity heatmap, risk zones (high churn + low coverage) | "where is risk accumulating", "velocity report" |
-| `documentation` | Skill | Baseline audit, scaffolding, templates | "baseline docs", "create docs", "audit docs" |
+| `documentation` | Skill | Baseline audit, scaffolding, templates, ADRs, guardrails | "baseline docs", "create docs", "audit docs", "record an ADR", "architecture decision", "create guardrails" |
 | `workflow-mapper` | Skill | Discover and diagram codebase workflows | "map workflows", "trace flows" |
 | `introspect` | Skill | Pre-implementation impact analysis against guardrails | "introspect this plan", "impact analysis" |
 
@@ -140,20 +147,22 @@ Unless explicitly requested:
 
 The six procedural folders below are fixed. Domain folders live as subfolders inside these — `docs/architecture/core/` for core module internals, `docs/features/{feature}/` for deep features. Discovery flows through **[`docs/routing.md`](docs/routing.md)** when present.
 
-| Folder               | Purpose                                                | Mutability            |
-| -------------------- | ------------------------------------------------------ | --------------------- |
-| `docs/architecture/` | System-wide patterns, technical decisions, API specs   | Living                |
-| `docs/features/`     | How implemented features work today                    | Living                |
-| `docs/operations/`   | Setup, development, deployment                         | Living                |
-| `docs/history/`      | Plans, changelogs, backlog                             | Frozen or append-only |
-| `docs/memory/`       | Project knowledge + agent state                        | Living                |
-| `docs/tests/`        | Test plans and automation                              | Living                |
+| Folder                   | Purpose                                                  | Mutability            |
+| ------------------------ | -------------------------------------------------------- | --------------------- |
+| `docs/architecture/`     | System-wide patterns, technical decisions, API specs     | Living                |
+| `docs/architecture/adr/` | Architecture Decision Records — numbered, one per file   | Frozen (supersede)    |
+| `docs/features/`         | How implemented features work today                      | Living                |
+| `docs/operations/`       | Setup, development, deployment                           | Living                |
+| `docs/history/`          | Plans, changelogs, backlog                               | Frozen or append-only |
+| `docs/memory/`           | Project knowledge + agent state                          | Living                |
+| `docs/tests/`            | Test plans and automation                                | Living                |
 
 ### Naming & Lifecycle
 
 - Features: `kebab-case.md` — living reference, status `Active`
 - Plans: `YYYY-MM-DD-kebab-case.md` — frozen after `Complete` or `Abandoned`
 - Changelogs: `YYYY-MM-DD-kebab-case.md` — append-only
+- ADRs: `NNNN-kebab-case.md` (4-digit zero-padded number, sequential) — frozen; supersede via a new ADR
 - Memory: `{agent-name}.md` — agent-maintained
 
 ### Documentation Maintenance

package/data/harnesses/kb-agi/CLAUDE.md

@@ -0,0 +1,57 @@
+# nupilot Knowledge Hub — router
+
+This repo is a flat Obsidian vault that you read on the user's behalf. It's the bridge from the front (positioning, claims) to the back (product and service specs); detailed execution lives downstream in the service repos.
+
+You are the **router**. Every session starts with a short interview, then follows one of two paths: **ask** (read the vault and answer) or **contribute** (help the user add to the vault). The contract that governs both — the note model, the frontmatter hints, who may write — is [`meta/guidance.md`](meta/guidance.md). Read it before you write anything.
+
+---
+
+## Step 0 — first run
+
+If `meta/guidance.md` is missing, this vault isn't initialized — invoke the **kb-agi-init** agent to scaffold the `meta/` control plane, then continue.
+
+---
+
+## Step 1 — the opening interview
+
+Before answering anything, run a short interview with the `AskUserQuestion` tool to establish two things:
+
+1. **What brings you?** → *ask* (you have a question) or *contribute* (you have something to add).
+2. **Your user-type (genre):** → *Sales*, *PM*, or *Contributor*. This sets the default depth and framing of answers, nothing else. (If none fits, let them say so — a missing genre just means use plain working depth.)
+
+Then load the matching template from [`meta/genre/`](meta/genre/) — `sales.md`, `pm.md`, or `contributor.md` — and follow the path below.
+
+Keep the interview to those two questions. Don't re-interview on every follow-up in the same session; carry the answers forward.
+
+---
+
+## The ask path — read-only
+
+You are **read-only** on this path. You never edit a note. Your only write is appending a query log to `meta/sessions/` (see below).
+
+1. **Find the entry note(s)** for the question. Start from [`meta/intent-index.md`](meta/intent-index.md) (keyed by *what the user wants to do*) and the entry notes named in their genre template.
+2. **Traverse the note graph both ways** — *up* toward summaries and entry notes, *down* into detail and evidence. The `[[wikilinks]]` are the structure. Lead with `canonical` notes; treat `canonical: false` ones as background.
+3. **Synthesize at the genre's default depth**, then adjust to how the question was actually asked — go deeper when they reach for it, compress when they want the headline. Depth shapes the answer; it never hides notes.
+4. **Cite the notes you used** so the user can stand behind the answer and follow the links.
+5. **Log the session** to `meta/sessions/` in the format in that folder's README — including, honestly, whether you could fully answer. A question you *couldn't* answer is a gap; logging it feeds the gap-finder and lets the user resume later.
+
+If the vault can't answer, say so plainly and log it as a gap. Don't invent an answer the notes don't support.
+
+## The contribute path — the human steers
+
+Here the user is *adding* knowledge, not reading. This path is deliberately thin and grows with use. There are **no sub-agents** — it's you and the user in a normal session.
+
+1. **Orient them** with [`meta/guidance.md`](meta/guidance.md) (the note model and where things belong) and the target folder's `metadata.md` (what belongs there, what's already nearby).
+2. **What does the hub want next?** Run the `kb-find-gaps` agent (it reads `meta/sessions/` gaps + folder `metadata.md`) — that's the live content roadmap.
+3. **Draft and place notes** as the user directs: one idea per note, light frontmatter per the contract, linked to its neighbours. Links form naturally as you write.
+4. Writing here is the human-in-the-loop exception to read-only — a person is steering every write, and every write is a git commit.
+
+---
+
+## What you do *not* do
+
+- **You don't run upkeep.** The kb-agi upkeep agents (`kb-find-gaps`, `kb-sync-metadata`, `kb-catch-stale`, `kb-fix-links`, `kb-refresh-frontdoor`, `kb-refresh-summaries`) are the only writers of canon, invoked by name and only when *deliberately* run — not as a side effect of a question. Don't trigger them from the ask path.
+- **You don't hand-edit `meta/_kg/`** — it's a derived graph, regenerated from the notes.
+- **You don't mutate notes on the ask path.** Read-only means read-only.
+
+Everything is git-checked-in, so any write is reviewable and reversible (doctrine P3).

package/package.json

@@ -1,6 +1,6 @@
 {
     "name": "@nurix/etna",
-    "version": "0.1.2",
+    "version": "0.1.3",
     "description": "Bootstrap a project with a Nurix harness — installs a Claude Code plugin from the nurixlabs/skills marketplace and drops the harness's CLAUDE.md at the project root.",
     "type": "module",
     "bin": {