@deepseek-insight/dsi 0.5.18 → 0.5.20

package/.agents/skills/dsi-adr/SKILL.md

@@ -0,0 +1,121 @@
+---
+name: dsi-adr
+description: Use when writing, reviewing, extending, or marking done any ADR in deepseek-insight's dev/architectural-decission/ — before drafting the first line, before approving one, and as the final self-audit before claiming an ADR is finished.
+---
+
+# DeepSeek Insight ADR Standard
+
+Match depth to the decision space, never to the most recent ADR. Recent thin
+ADRs are not authority — the exemplars are. This skill exists because an
+agent under context rot reaches for the nearest template and produces a
+decision record that asserts outcomes without recording why the alternatives
+lost; that document re-litigates itself in six months. It is guidance with a
+hard core: the self-audit in §5 is not optional.
+
+Exemplars, in authority order (paths relative to the DSI repo root):
+
+1. `dev/architectural-decission/2026-08-27 - The Lineage Pin — Sub-Agents Below Their Spawner, Swap-Proof.md` — the gold standard: D1–D7, sequence + flowchart + state homes + control matrix, glossary, amendments log.
+2. `dev/architectural-decission/2026-08-24 - The Panel Floor — Many Conversations, One Page.md` — decision set with honest give-ups.
+3. `dev/architectural-decission/2026-08-29 - The Prompt Macro — Bang Runs the Shelf, Line by Line.md` — deep format on a composer-scale feature.
+
+Read the exemplar closest to your subject before drafting a new ADR kind.
+
+## 1. ADR or KB?
+
+An ADR records a **decision and its cost** — what we chose, what we rejected,
+what we accept by choosing it. A KB note records **mechanics** — how a
+surface works today, for the newcomer. The pair discipline: a KB that
+documents current behavior ends by naming the open question; the ADR that
+answers it cites the KB as companion. If your draft asserts choices but
+names no rejected alternative, it is a KB note wearing an ADR's filename —
+rehome it or deepen it.
+
+## 2. The skeleton (old-guard format)
+
+```markdown
+# ADR — <The Name>: <The Claim in One Line>
+
+- **Date:** YYYY-MM-DD
+- **Status:** Proposed          ← Accepted only after implementation proves it
+- **Companions:** <linked KB notes + ADRs this stands on>
+- **Supersedes:** <what it retires, or "nothing — …">
+- **Question this answers:** *<the operator-visible question, one sentence>*
+
+## TL;DR — for the reader in a hurry
+## 1. The problem, in plain words          ← operator story, not architecture story
+## 2. What the codebase/host already gives us (the facts)   ← numbered, sourced
+## 3. The principle, unfolded              ← the rule the decisions instantiate
+## 4. Decisions
+### D1 — <decision as a claim>             ← why + REJECTED alternative + why it loses
+### D2 — …
+## 5. <lifecycle sequence diagram>         ← wherever state changes hands
+## 6. <flowchart / control matrix / state homes — as the subject needs;
+##       split into further numbered sections when several apply>
+## Diagrams: mermaid (flow & sequence) blocks; state homes and control
+##       matrices stay markdown tables
+## 7. Consequences                         ← gains / accepted give-ups / what does NOT change
+## 8. File map (implementation footprint)  ← every file + the tests that pin it
+## Glossary (for the layman)               ← a newcomer reads without the codebase
+## Post-implementation amendments          ← dated entries, never edit the body in place
+```
+
+Number the decisions `D1…Dn` and treat the numbers as addresses: later ADRs
+and KB notes cite "D3" instead of re-describing the rule. Diagram menu — pick
+what the subject needs, skip none that applies: sequence (a lifecycle),
+flowchart (branching rules), state-homes table (where a fact lives and which
+copy is authority), control matrix (who may do what per row species). Create
+sequence and flowchart diagrams as mermaid (```mermaid sequenceDiagram /
+flowchart) blocks — the exemplars' house format; state-homes and control
+matrix stay markdown tables. Validate every mermaid block parses (e.g.
+mermaid.parse) before claiming done — mermaid treats `;` as a statement
+separator, so message text cannot carry one.
+
+## 3. The depth rule
+
+Count the real alternatives BEFORE choosing a length. The honest test:
+
+- Name every alternative you actually weighed. If you cannot name at least
+  two rejected alternatives across the ADR, either the decision is too small
+  for an ADR (write a KB note or a code comment instead) or you have not
+  thought hard enough yet. Both happen; only one is excusable.
+- Length follows the alternative space, not a template minimum or maximum.
+  The thin five-section format (context / rule / lives / gave-up / proving)
+  is acceptable ONLY for mechanical moves with no real alternative space —
+  and the absence of alternatives must be a finding, not an oversight.
+- Fusing alternatives into one assertive paragraph is the failure this skill
+  exists to prevent. A rejected alternative needs its rejection reason in
+  writing, at the decision it lost to.
+
+## 4. Fact discipline
+
+Every fact in §2 traces to something you actually inspected this session: a
+file and line, a wire capture, a test, a dated ADR. Never carry a fact
+forward from memory of a previous session, and never cite a line number
+without re-reading it. In the final document, keep the sources concrete
+(file paths, ADR names, dated specs) so a reviewer can re-walk the evidence.
+
+## 5. The self-audit (before claiming done)
+
+Answer each aloud, in the transcript, yes or no:
+
+1. Did I enumerate the real alternatives, or fuse them into a paragraph?
+2. Does EVERY decision name what it rejected and why the rejection lost?
+3. Can a newcomer follow the TL;DR + glossary without opening the codebase?
+4. Does every §2 fact carry a source I read THIS session?
+5. Is there a diagram wherever state changes hands or authority moves —
+   mermaid (`sequenceDiagram` / `flowchart`) for flows and sequences, and
+   does every mermaid block parse clean?
+6. Did I copy a recent ADR's shape instead of matching the trade?
+7. Does Consequences include what does NOT change (so reviewers see the
+   blast radius is bounded)?
+8. Does the file map name the tests that will pin the behavior?
+
+Any "no" is an unfinished ADR. Fix it or shrink the ADR's claim — never
+declare done with a standing "no".
+
+## 6. Reviewing an ADR
+
+Run the same audit from the outside. The three rejection reasons that matter
+most: a decision with no named alternative; a fact with no source; a
+consequence section that lists only gains. Style is negotiable; those three
+are not.

package/.agents/skills/dsi-i18n-migrate/SKILL.md

@@ -0,0 +1,87 @@
+---
+name: dsi-i18n-migrate
+description: Use when UI copy in deepseek-insight needs migrating to the translation catalogs (new components, raw copy found by verify-ui-i18n, or a new locale being added) — enforces the t(m.x) reactive seat, en/zh/id catalog triples, brand skip-markers, and the full gate list. Delegatable to a subagent for bulk sweeps.
+---
+
+# DSI i18n Migration Standard
+
+Make UI copy flow through the catalogs — never paste sentences into
+components. This skill packages the procedure proven in waves 1–4 of the
+Three Tongues (companion: ADR 2026-09-12 + KB `dev/kb/translation/`).
+
+## 0. Ground rules (read first)
+
+- The ONLY files owning copy are `messages/en.json`, `messages/zh.json`,
+  `messages/id.json`. Components render via `t(m.key)`.
+- `t` is the reactive seat from `$lib/services/locale/locale-state.svelte` —
+  a bare `m.key()` reads no reactive state, so the label would freeze until
+  reload. Never ship a bare `m.key()` in a template.
+- Keys are flat camelCase, one per sentence/label; reuse an existing key when
+  the English value is identical (check all three catalogs first).
+- Catalog triples are written [en, zh, id] — en = the exact original string;
+  zh = Simplified Chinese; id = Indonesian. Concise UI tone; keep proper nouns
+  (DSH, DSI, Deepseek, Monaco) as-is; no trailing periods unless the original
+  has one.
+- Brand strings (`— deepseek-insight`, `DEEPSEEK INSIGHT`) are never
+  translated: mark the flagged line's preceding line with `<!-- i18n-skip:
+  brand -->` (same indentation) and skip.
+- Dynamic literals become paraglide placeholders: catalog `"Delete {n} selected"`,
+  call site `t(() => m.deleteSelected({ n: selected.size }))` (the deferred
+  closure keeps the locale tracking alive).
+- Native-language names (menu entries like 中文 / Bahasa Indonesia) are
+  constants, NOT catalog keys — a language menu shows every name in its own
+  language.
+
+## 1. Inventory
+
+Run `pnpm run verify-ui-i18n`. The scanner covers: raw text nodes,
+copy-bearing attributes (title / aria-label / placeholder / *Label…), string
+literals and template quasis inside template expressions, and {#if}
+consequent/alternate blocks. Save the output (e.g. `/tmp/violations.txt`) —
+it is the worklist; every line must end resolved, skip-marked, or explained.
+
+Known scanner blind spots to check by hand: lowercase-only literals (e.g.
+`answering…`) fail the natural-text heuristic; copy built in script sections
+is invisible.
+
+## 2. Migration
+
+For each violation: replace the literal with `t(m.keyName)` /
+`attr={t(m.keyName)}` / `t(() => m.key({ p }))`, add the missing imports
+(`* as m from '$lib/paraglide/messages'`, `t` from the locale-state service —
+note some components have no `<script>` block and need one created).
+Idempotent exact-replacement scripts are fine for bulk sweeps (see
+`scripts/migrate-w3.mjs` in git history for the shape); hand-edit for the
+tricky sites (ternaries, `${}` fragments → split keys).
+
+If the sweep is large (>20 files), delegate it to a subagent with this skill
+attached, the inventory file path, and instruction to leave the tree
+uncommitted; the parent verifies gates (step 4) before accepting.
+
+## 3. Catalogs and recompile
+
+Append the new keys to all three catalogs, then recompile:
+`pnpm exec paraglide-js compile --project ./project.inlang --outdir ./src/lib/paraglide`
+— or run `pnpm build`, which does the same through the vite plugin. Prefer the
+plugin (vitest runs it too); never ship CLI-compiled output as the built
+artifact (it resets cookieName — ADR D6).
+
+## 4. Gates (all must pass)
+
+1. `pnpm run verify-ui-i18n` → "verify-ui-i18n: clean"
+2. `pnpm vitest run tests/unit/messages-parity.test.ts tests/unit/ui-i18n-clean.test.ts tests/unit/locale-instant-switch.test.ts` → green
+3. `pnpm test` → only the known pre-existing `sessions-list.test.ts` failure
+   allowed (document any new failure as yours and fix it)
+4. `pnpm check` → zero diagnostics in files you touched
+5. `pnpm build` → exit 0 (compiled runtime must carry cookieName `dsi.locale`)
+6. `pnpm exec playwright test tests/e2e/locale.spec.ts` → green
+
+Report: violations fixed, keys added, files touched, gate results, anything
+skipped with reason.
+
+## 5. Adding a locale (not just strings)
+
+New language L = one `messages/L.json` (key-complete — the parity test
+enforces it) + add L to `project.inlang/settings.json` locales + `UI_LOCALES`
+in `src/lib/config.ts` + `localeName_L` native name + the locale pickers'
+native-name constants. The ADR D6 compiled-truth rule applies unchanged.

package/.agents/skills/dsi-ov-setup/SKILL.md

@@ -0,0 +1,114 @@
+---
+name: dsi-ov-setup
+description: Use when OpenViking memory is broken or missing in DeepSeek Harness — server disconnected, server not installed, ov.conf missing, plugin not loaded, or a fresh machine needs the whole OpenViking + DSH memory integration set up (plugin, skill, server). Covers diagnosis, install, config, start, and verification.
+---
+
+# OpenViking + DSH Setup and Recovery
+
+Companion KB: `dev/kb/setup/2026-09-16 - OpenViking Server + DSH Memory Plugin — From Cold Start to Recalled Memory.md` — read it for the why behind every step. This skill is the do-path.
+
+## 0. Diagnose first — which failure is this?
+
+Run in order; stop at the first failing gate:
+
+| Gate | Command | Healthy looks like |
+|---|---|---|
+| Server process | `curl -s --max-time 3 http://127.0.0.1:1933/health` | `{"status":"ok","healthy":true,...}` |
+| Server config | `ls ~/.openviking/ov.conf` | exists |
+| Client config | `cat ~/.openviking/ovcli.conf` | `url` = `http://127.0.0.1:1933` |
+| Package | `openviking-server --version` | prints a version |
+| MCP connection | harness tool list shows `mcp__openviking__*` | tools present |
+
+- Health fails + `ov.conf` missing → **Recovery path (§2)**, the common case.
+- Health fails + `ov.conf` exists → run `openviking-server doctor`, fix what it names, go to §2 step 4.
+- Health ok but MCP disconnected → the plugin reconnects on its own within a turn or two; if not after a full turn, restart the harness session. Do not reinstall anything.
+- Package missing → fresh install: do §2 steps 1–6 from scratch.
+
+## 1. Facts to keep straight (most-confused pair)
+
+- `~/.openviking/ovcli.conf` — **client** pointer: `{"url": "http://127.0.0.1:1933", "api_key": ""}`. Missing it breaks CLI commands only.
+- `~/.openviking/ov.conf` — **server** model config (embedding + VLM). Missing it means the server process cannot start at all. This is the usual blocker.
+- The DSH plugin (`@openviking/dsh-memory-plugin`, in the profile bundles at `~/.dsh/profiles/web/package.json`) is a **client only** — it never starts the server, and it reconnects automatically once the server is healthy. Never "fix" a disconnected MCP by touching the plugin.
+- `openviking`/`ov` = CLI/SDK; `openviking-server` = the daemon. Same pip package.
+
+## 2. Recovery / install path
+
+### Step 1 — Install the package (skip if `openviking-server --version` works)
+
+```sh
+pip install openviking --upgrade --force-reinstall
+```
+
+Entry points land in `~/.local/bin`: `ov`, `openviking`, `openviking-server`, `vikingbot`.
+
+### Step 2 — CLI housekeeping
+
+```sh
+ov language en        # v0.3.23+ refuses most commands without this; writes ovcli.settings.conf
+ov config add custom --name local --url http://127.0.0.1:1933 --activate -o json   # only if ovcli.conf missing
+```
+
+Note: both write under `~/.openviking/` — they fail under a workspace-only file sandbox; run with full file access.
+
+### Step 3 — Create the server config: `openviking-server init`
+
+Preferred: run it interactively and let the human answer. If driving it with piped answers, the wizard's prompt order is exact and hidden prompts exist — the tested sequence for the recommended local setup:
+
+```
+1     # mode: step-by-step
+3     # embedding: lightweight CPU (llama.cpp, bge-small-zh-v1.5-f16, no key)
+1     # embedding model: (only option — EASY TO MISS; missing this shifts every later answer)
+6     # VLM: GLM (subscription API key)
+2     # GLM plan: coding
+<key> # API key — pass via stdin from an env var; NEVER in the command line or logs
+N     # query planner via Ollama: no
+1     # bind 127.0.0.1 (dev, no auth)
+1933  # port
+Y     # save
+```
+
+After saving the wizard echoes the resolved API key in its summary — **redact any captured log** before storing it.
+
+Decision guardrails (from the KB §4): embedding `[3]` CPU is the default because it is keyless and tiny; offer `[1]` cloud embedding only when the user cares about retrieval quality and has a key; VLM is the piece worth a strong model — GLM via an existing subscription beats skipping it. `[9]` skip-VLM gives a server that stores but extracts poorly.
+
+### Step 4 — Wait out the build
+
+Choosing CPU embedding triggers `pip install "openviking[local-embed]"`, which **builds `llama-cpp-python` from source** — several minutes of silent wheel-building. It is not hung. Do not kill it; verify with `ps aux | grep "openviking-server init"`.
+
+### Step 5 — Validate and start
+
+```sh
+openviking-server doctor    # expect: all checks PASS (config, auth, disk ≥ several GB)
+openviking-server           # foreground proof; then move to a supervisor
+```
+
+For persistence: launchd/nohup/systemd — never rely on an agent shell outliving the session. Verify:
+
+```sh
+curl -s http://127.0.0.1:1933/health   # {"status":"ok","healthy":true,...}
+ov status                              # "Connected (Healthy)", queue 0 pending / 0 errors
+```
+
+A stale `~/.openviking/pending/` queue (hundreds of files) from the downtime drains on its own — do not delete it.
+
+### Step 6 — Confirm the integration
+
+Within a turn of the server going healthy, the plugin reconnects (MCP tools answer, `<openviking-context>` appears at the next session start). If MCP tools still error after a full turn: restart the harness session once. Only then suspect the bundle (`~/.dsh/profiles/web/package.json` must list `@openviking/dsh-memory-plugin` in `dsh.profile.bundles`).
+
+## 3. Verification checklist (all seven, in order)
+
+1. `openviking-server --version` → prints version
+2. `ls ~/.openviking/ov.conf ~/.openviking/ovcli.conf` → both exist
+3. `openviking-server doctor` → all PASS
+4. `curl -s http://127.0.0.1:1933/health` → `"healthy":true`
+5. `ov status` → Connected (Healthy), 0 errors
+6. `ov find "smoke test"` after any resource exists → ranked hits, not a connection error
+7. New session → `<openviking-context>` block present
+
+## 4. Known traps
+
+- `ov status` saying "Unreachable" while the server is fine → the language gate; run `ov language en` first.
+- Two config files, one directory (§1) — check the right one for the symptom.
+- `auth_mode: "dev"` = no auth, localhost only. Never bind `0.0.0.0` without switching to API-key auth (docs: Authentication guide).
+- Piped `init` answers are prompt-order-fragile (Step 3) — count prompts, don't trust defaults.
+- Re-examine actual prompt output on every version bump; this sequence was tested against OpenViking 0.4.20 / plugin 0.3.2 (2026-09-16) and the wizard's prompts are not a stable contract.

package/.agents/skills/dsi-release/SKILL.md

@@ -0,0 +1,175 @@
+---
+name: dsi-release
+description: Use when a DSH release/tag jump needs analyzing for DeepSeek Insight impact — deciding whether DSI owes an update, fix, or feature, and writing the KB release note that records the verdict. Covers fetching the tag range, diffing the three touchpoints (wire, rejection codes, session ledger), probing DSI's matchers, and the report template with self-audit.
+---
+
+# DSH Release → DSI KB Comparison Standard
+
+Every DSH alpha/tag jump must be *checked, not trusted*: pre-release, the
+harness renames freely and owes guests no translation layer. This skill runs
+that check mechanically and records the verdict as a KB note in
+`dev/kb/releases/`, so each jump has a written baseline the next one diffs
+from. It exists because the failure mode is a quiet break — the alpha.2
+rejection-code rename kept everything working until a user opened a missing
+session and got a wrong-flavored error card.
+
+Exemplars, in authority order (paths relative to the DSI repo root):
+
+1. `dev/kb/releases/2026-09-01 - The Alpha Jump — DSH 0.1.2-alpha.1 to alpha.3, What Changed and What DSI Must Adapt.md` — the deep case: a wholesale rename found, five files patched, live probe, dead-code discovery.
+2. `dev/kb/releases/2026-09-03 - The Quiet Jump — DSH 0.1.2-alpha.3 to alpha.5, What Changed and What DSI Owes.md` — the quiet case: 302 commits, nothing owed, one polish item, every "unchanged" diff-verified at the tags.
+
+Read the exemplar matching your jump's size before drafting.
+
+## 1. Establish the range
+
+The previous release KB names the edition DSI was last verified against —
+that tag, not "whatever we remember", is the range start. The new tag is the
+one the host now runs (confirm: `git log -1` on the tag, the running `dsh web`
+process, or the compare URL the operator supplies). If the previous KB stops
+more than one edition back, analyze every missing gap — an untouched middle
+edition is a finding, not a reason to skip it.
+
+```sh
+cd ~/agentic-ai/deepseek-harness
+git remote -v                        # origin may be a fork without dsh-* tags
+git fetch --tags https://github.com/deepseek-ai/deepseek-harness.git
+git tag -l 'dsh-v*'
+git log --oneline <old>..<new> | wc -l
+git log --oneline <old>..<new> | grep -oE '^[a-f0-9]+ [a-z]+\([^)]*\)' \
+  | sed 's/^[a-f0-9]* //' | sort | uniq -c | sort -rn   # theme census
+```
+
+## 2. Diff the three touchpoints (the whole compatibility question)
+
+DSI touches the host in exactly three places. Diff each **at the tags**, in
+the DSH checkout — commit messages and Agent Notes are claims until grepped.
+
+**a. The wire** (method names, argument/result fields, paging semantics):
+
+```sh
+git diff <old>..<new> -- packages/api/session-controller/src/client/contract \
+  packages/api/session-controller/src/history.ts \
+  packages/api/session-controller/src/list.ts \
+  packages/api/session-controller/src/commands.ts
+```
+Filter out internal type-branding noise (`SessionSeq`, `SessionLogOffset`,
+`Branded`) — it is compile-time; the notes must say whether numeric wires
+change, and you verify the wire adapter anyway (e.g. `wireHeader()`).
+
+**b. The rejection codes** DSI matches (`grep -rn "err.code\|=== '"` in
+DSI's `src/lib/server/`, then):
+
+```sh
+git diff <old>..<new> -- packages/api | grep -E "^[+-].*RemoteError\("
+git grep -n '<code-spelling>' <new> -- packages/api
+```
+
+**c. The ledger** DSI reads (JSONL contract):
+
+```sh
+for t in <old> <new>; do git grep -h 'SESSION_FORMAT_VERSION =' $t -- packages; done
+# Event-type vocabulary has NO single home: SessionEventMap members are declared
+# across capability packages (tool events live in packages/core/tools/src/types.ts),
+# so set-diff the known-type LIST at both tags. Never trust a single file diff -
+# the 2026-09-09 Missed Rename: events.ts diffed empty while the ptc-dispatch
+# rename landed in tools/types.ts. Set-diff the union of declaring files:
+for t in <old> <new>; do
+  git grep -h "dispatch\|tool/\|turn/\|step/\|assistant/" $t -- \
+    packages/core/session/src/known-event-types.ts \
+    "packages/*/[^/]*/src/types.ts" 2>/dev/null | sort -u > /tmp/evt-$t.txt
+done
+diff /tmp/evt-<old>.txt /tmp/evt-<new>.txt   # every moved spelling shows here
+```
+
+Also check `SESSION_FORMAT_VERSION`, the `SessionEventMap` members (a new
+model-visible event type is a DSI rendering opportunity), and the
+`ignorable: true` rule (unknown events required-on-read unless marked).
+
+## 3. Check DSI's matchers against the diff
+
+For every wire string, code spelling, or validation message that moved,
+grep DSI for who matches it (`src/lib/server/dsh-rpc.ts`,
+`dsh-connection.ts`, route `+page.server.ts`/`+server.ts`, command
+parser/executor prose). Classify each hit: **live matcher** (code compares
+`err.code`), **prose** (docstring/JSDoc naming a code), or **local mirror**
+(DSI re-validates what the host also validates — flag divergence in either
+strictness direction).
+
+## 4. Probe and verify before writing the verdict
+
+- If matchers changed: patch them, then run the loop:
+  `npx vitest run` → `npm run check` → `DSH_LIVE=1 npm run test:live`
+  (live tests need a valid cookie against the running host; a dev server
+  minted before a restart still works — signed cookies survive host
+  restarts, launch tokens do not).
+- If nothing changed: say so with tag-diff evidence, and confirm the
+  existing live suite still applies unedited.
+- A matcher that *cannot fire* is a fact worth probing, not keeping (the
+  Alpha Jump's `not-pending` and dead-404 discoveries). When in doubt,
+  probe through DSI's own stack (the dev server proxying a real call).
+
+## 5. The KB note template
+
+Filename: `dev/kb/releases/YYYY-MM-DD - <The Name> — DSH <old> to <new>, <What Changed and What DSI Owes/Must Adapt>.md` — date is when the analysis ran.
+
+```markdown
+# <The Name> — DSH <old> to <new>, …
+
+> KB note, YYYY-MM-DD. Written <the trigger: what jumped, when, what DSI's
+> live-verified claims still described>. Sources: <git ranges with commit
+> counts>, the range's Agent Notes, and tag-vs-tag greps — every claim
+> confirmed in both trees. Successor to <previous release KB>.
+
+## The question, restated in plain terms
+<Operator-story framing; the switchboard mental model; the one-sentence
+verdict up front — "nothing owed" or "N spellings across M files".>
+
+## The journey, edition by edition
+<mermaid flowchart: one node per edition, child nodes per notable change;
+count the PRs/commits per hop; color the DSI-breaking node(s).>
+
+## What changed, by DSI touchpoint
+### The wire (what DSI speaks) — <verdict>
+### The rejection codes (what DSI matches) — <verdict>
+### The ledger (what DSI reads) — <verdict>
+### What the host bought itself (gratitude, not action)
+<Host-internal upside DSI need not copy — recorded so the next jump's
+reader knows it was considered, not missed.>
+
+## What DSI owes the new edition
+<Table: item | where (file:line) | why it matters | cost. Old→new spelling
+pairs each verified in both trees. If nothing: the one polish item, or an
+explicit zero with the verification loop restated for the next jump.>
+
+## Takeaway
+<The debt paid or the quiet jump confirmed; the operating rule restated.>
+
+**Open question:** <a KB ends by naming its open question — the next
+decision this note surfaces but does not answer.>
+```
+
+## 6. The self-audit (before claiming done)
+
+Answer each aloud, yes or no:
+
+1. Did the range start at the edition the previous KB actually verified, and cover every gap since?
+2. Were all three touchpoints diffed at the tags — not read from commit messages or notes alone?
+   For the ledger: was the known-event-type SET set-diffed across declaring files (step 2c),
+   not one file diff? A per-file diff can pass while the vocabulary moves — the 2026-09-09 Missed Rename.
+3. Does every "unchanged" claim name the files the diff covered?
+4. Was every DSI matcher greped and classified (live / prose / mirrored-validation)?
+5. If matchers moved: did the verification loop run green (unit, check, live)?
+6. Does the note state the verdict in its first screen (a reader in a hurry must not excavate it)?
+7. Does "What the host bought itself" show considered-and-skipped work, not silently-missed work?
+8. Does the note end with a real open question (not a restated takeaway)?
+
+Any "no" is an unfinished report. Fix it — never declare done with a
+standing "no".
+
+## 7. Mirror discipline
+
+The repo-local copy (`.agents/skills/dsi-release-kb/SKILL.md`, DSI repo) is
+the versioned source of truth; the mirror at `~/.agents/skills/dsi-release-kb/`
+makes it visible to every harness host's `skills/list`. After editing the
+repo copy, re-copy it to the mirror — a skill the slash menu never sees is
+a skill nobody invokes (RCA 2026-09-03 — The Skill the Slash Menu Never Saw).