oh-my-second-brain 0.2.0 → 0.6.1

package/core/skills/doctor/SKILL.md

@@ -1,49 +0,0 @@
----
-name: doctor
-description: Validate vault notes against the Oh My Second Brain convention and report violations (REAL today).
----
-
-# Skill: doctor
-
-Check every note in your vault against its declared concept schema.
-This skill is **REAL in v0** — the CLI command is fully implemented.
-
-## Shell-out
-
-```bash
-oms doctor [--vault <path>]
-```
-
-- `--vault <path>` — path to your Obsidian vault root (default: current directory).
-- Always **exits 0** in v0 (non-blocking; `onViolation: warn`).
-
-## What the command does
-
-1. Loads `vault/.oms/` and `vault/.oms/taxonomy.yaml`.
-2. Walks every `.md` note in the vault.
-3. For each note, resolves its **concept** from the taxonomy folder binding.
-4. Calls `validateFrontmatter(frontmatter, concept)` and collects `Violation[]`.
-5. Prints a per-note summary of violations (field, rule, message).
-6. Prints total counts: notes checked, violations found.
-7. Exits 0 regardless of violation count (v0 is advisory only).
-
-## Violation rules
-
-| Rule | Description |
-|------|-------------|
-| `required` | A field declared `required: true` is missing from the note's frontmatter |
-| `type` | The field value does not match the declared type |
-| `immutable` | Field changed after initial set — **suppressed in v0** (no baseline available) |
-
-Undeclared frontmatter fields are **never** reported as violations
-(`additionalProperties: preserve`).
-
-## Recommended usage
-
-Run `oms doctor` after:
-- Any `oms setup` run
-- Adding a new field via `oms define`
-- Bulk-editing notes
-
-Integrate into CI by adding `npx oms doctor --vault ./vault` to your workflow.
-It will never fail the build in v0.

package/core/skills/link/SKILL.md

@@ -1,130 +0,0 @@
----
-name: link
-version: 0.1.0
-description: Two-path note-linking skill — Path A (pre-write): compose a new note body that already carries [[wikilinks]] to existing term notes; Path B (retrofit): add missing links to notes that already exist, via oms linkify or oms_link_apply.
-trigger: /link
-tags: [link, wikilink, linkify, term, backlink, second-brain, oms]
----
-
-## link
-
-Keep the vault interlinked. There is no autolink daemon — follow this recipe as
-the agent. Requires `OMS_VAULT` (or a resolved vault target).
-
-## Which path?
-
-Determine which path applies **before acting**:
-
-| | Path A — pre-write | Path B — retrofit |
-|---|---|---|
-| **When to use** | You are about to write or rewrite a note | The note already exists on disk |
-| **Entry point** | MCP `oms_link_suggest` on a sibling note, then MCP `write` | `oms linkify` (report) → `oms linkify --apply --yes`, or MCP `oms_link_suggest` → `oms_link_apply` |
-| **Writes to** | The new note only | Existing notes in scope |
-| **Prerequisite** | Term notes exist to link at | Term notes exist to link at |
-
-These paths are **mutually exclusive and never combined in a single invocation.**
-
----
-
-## The link universe — term notes only
-
-A link target is a note bound to the `term` concept in `vault/.oms/taxonomy.yaml`.
-Notes bound to any other concept are never proposed as targets, in either path.
-Surface forms of a target are its **basename** and its frontmatter **`aliases`**.
-
-If a run reports `0 term note(s) available as link targets`, the vault has no
-term layer yet — build one with the `wiki` skill (Path B) first. Linking is not
-the tool that creates vocabulary; it is the tool that connects it.
-
-## Three rules the engine enforces — do not fight them
-
-1. **Surface-anchored.** A candidate exists only because the term's basename or
-   alias literally appears in the note. Retrieval never invents a link. Do not
-   hand-add a `[[link]]` to a note whose title does not appear in the text —
-   write the sentence that mentions it instead.
-2. **First occurrence only.** One link per target note per body. A term linked
-   ten times is noise, not navigation.
-3. **Ambiguity is reported, never auto-resolved.** When 2+ notes claim one span,
-   the candidate carries `ambiguous: true` and every `rivalPaths` entry. Ask the
-   user which note is meant, or skip the span. Never guess.
-
-Protected regions are masked out before matching: frontmatter, fenced and inline
-code, existing wikilinks and markdown links, image embeds, HTML, headings, URLs,
-block ids, and tags. A "missing" link inside any of those is correct behavior.
-
----
-
-## Path A — pre-write linking
-
-*(Use while drafting. The goal is that the body arrives on disk already linked,
-so no retrofit pass is ever needed for this note.)*
-
-### Agent-guided steps
-
-1. Establish the vocabulary **before** drafting: call MCP `oms_link_suggest` on
-   an existing note in the same folder (or run `oms linkify --folder <folder>`
-   in report mode) and read the `targetPath` list. That list IS the vault's
-   current term vocabulary.
-2. Draft the body using those exact surface forms, and write `[[wikilinks]]`
-   inline as you compose — first mention of each term only.
-3. Commit through MCP `write`. Host `Write`/`Edit` never touches vault `.md`.
-4. Re-check with `oms_link_suggest` on the committed note. Zero candidates means
-   the draft was already fully linked; remaining candidates are terms you missed.
-
-### Example agent steps (Path A)
-
-```
-User: "Write a note about our retrieval pipeline."
-
-1. oms_link_suggest { notePath: "notes/software-engineering/indexing.md" }
-   → targets: notes/terms/embedding.md, notes/terms/reranker.md, notes/terms/chunk.md
-2. Draft body mentioning embedding / reranker / chunk, each first mention
-   written as [[embedding]], [[reranker]], [[chunk]]
-3. write { mode: "create", notePath: "notes/software-engineering/retrieval-pipeline.md", ... }
-4. oms_link_suggest on the new note → 0 candidates ✓
-```
-
----
-
-## Path B — retrofit existing notes
-
-*(Use when the note is already on disk. Report first, always.)*
-
-### Batch — `oms linkify` (whole vault or one folder)
-
-```bash
-oms linkify --folder notes          # report only, writes nothing
-oms linkify --folder notes --apply --yes   # rewrite in place
-```
-
-`--apply` without `--yes` refuses before reading a single note and writes
-nothing. Show the user the report and get agreement before adding `--yes`.
-Every write still goes through the capture kernel, so path safety and the
-concept contract hold exactly as they do for MCP `write`.
-
-### Single note — `oms_link_suggest` → `oms_link_apply`
-
-Use when the user wants to accept some candidates and reject others:
-
-1. `oms_link_suggest { notePath, folder? }` → candidates + `baseContentHash`.
-2. Present the candidates; drop ambiguous ones the user does not resolve.
-3. `oms_link_apply { notePath, baseContentHash, candidateIds, folder? }` —
-   pass back the **same** `baseContentHash` and the **same** `folder` scope.
-
-`oms_link_apply` refuses without writing when the note changed since the
-suggest call (`note-changed`), when a candidate's text moved (`candidate-drift`),
-or when accepted candidates overlap. A refusal is a correct outcome: re-run
-`oms_link_suggest` for fresh offsets rather than retrying the stale ids.
-
-### Example agent steps (Path B)
-
-```
-User: "Link up the notes I wrote last week."
-
-1. oms linkify --folder notes            ← report only
-   → 14 candidate(s) across 9 note(s); 2 marked ambiguous
-2. Show the report; ask which note the 2 ambiguous spans mean
-3. Accepted whole folder → oms linkify --folder notes --apply --yes
-   Accepted per-note → oms_link_suggest → oms_link_apply with the chosen ids
-4. Run `oms doctor` (non-blocking, exits 0)
-```

package/core/skills/retrieve/SKILL.md

@@ -1,78 +0,0 @@
----
-name: retrieve
-description: Retrieve knowledge from the vault through declared Oh My Second Brain lenses (인출).
----
-
-# Skill: retrieve
-
-Surface the right notes and fields for a given purpose using the vault's
-declared retrieval lenses.
-
-## What this skill does
-
-1. Identify the **retrieval purpose** from the user's request (e.g. "synthesize this topic", "audit my sources").
-2. Match the purpose to a declared **lens** (e.g. `synthesis`, `audit`) on the relevant concept.
-3. For each matching note, return only the fields listed in that lens — not all frontmatter.
-4. Present results grouped by concept/folder with lens-filtered frontmatter.
-
-## Lenses (인출 뷰)
-
-A lens is a pre-declared named retrieval view, not a query filter.
-Each concept declares which fields matter for which purpose:
-
-```yaml
-lenses:
-  - name: synthesis
-    intent: "Surface what was argued and where to find it"
-    fields: [title, thesis, source-url]
-  - name: audit
-    intent: "Check provenance and capture date"
-    fields: [title, source-url, captured-at]
-```
-
-The retrieval skill reads these declarations from `vault/.oms/concepts/*.yaml`.
-
-## Engine
-
-Use MCP `oms_retrieve_context` first for natural-language retrieval. It combines:
-
-- live folder/frontmatter/wikilink graph exploration without requiring a warm cache
-- taxonomy-axis seeds from concept, folder, property, value, or wikilink inputs
-- graph neighbors through shared frontmatter values, wikilinks, and backlinks
-- optional OMS native semantic lexical, SQLite-vector, and HYDE candidates when the semantic index is available
-
-Use `semanticScope: "global"` for broad semantic search across the vault. Use
-`semanticScope: "graph"` when semantic candidates must stay inside the selected
-OMS graph candidates. The semantic provider is fail-soft: retrieval must still
-return OMS graph hits when the native semantic index is unavailable or disabled.
-
-For semantic retrieval, keep semantic-index and search controls on the OMS retrieve surface:
-
-- pass `semanticMode: "query" | "search" | "vsearch"` to choose hybrid, lexical, or vector search
-- pass `semanticIntent`, `semanticLex`, `semanticVec`, `semanticHyde`, or `semanticSearches` for typed query documents
-- pass `semanticMinScore`, `semanticAll`, `semanticFull`, `semanticLineNumbers`, or `semanticFullPath` when the retrieval task needs search flags
-- pass `embeddingSyncBeforeSearch: true` when the native semantic index must be fresh before retrieval
-- use `oms_sync_embeddings` for an explicit semantic-index sync without doing a retrieval query
-- use `oms_semantic_query`, `oms_semantic_status`, `oms_semantic_collections`, and `oms_semantic_contexts` for qmd-compatible semantic follow-ups on the native OMS index
-- use read-only `oms_get_document` or `oms_multi_get_documents` to rehydrate selected docids, paths, globs, or line ranges
-
-Use the older MCP tools only for narrower follow-up steps:
-
-- **`oms_retrieve_by_axis`** — legacy cache-backed axis retrieval by concept, folder, property, value, or wikilink.
-- **`oms_lazy_load_note`** — fetches the full body of a single selected note on demand, avoiding loading all note bodies upfront.
-
-## Example agent steps
-
-```
-User: "Synthesize my literature notes on transformers"
-
-1. purpose  = synthesis
-2. concept  = literature  →  lens = synthesis  →  fields = [title, thesis, source-url]
-3. scan     = vault/references/*.md
-4. for each note: extract only those three frontmatter fields
-5. return a grouped summary with citations
-```
-
-## Persona
-
-Use the **retriever** agent persona for this skill (`core/agents/retriever.md`).

package/core/skills/setup/CHANGELOG.md

@@ -1,49 +0,0 @@
-# setup — CHANGELOG
-
-## 0.2.0 — 2026-06-13
-
-Rewrote skill to embed the Socratic setup interview methodology (M5 step 2).
-
-### What changed
-
-- Added 5-key frontmatter (name, version, description, trigger, tags) per compile skill convention.
-- Embedded Socratic clarity loop with configurable ambiguity threshold (default 0.20),
-  dimension scoring across Goal / Constraint / Criteria / Context, a Round-0 topology gate,
-  and three challenge modes: Contrarian, Simplifier, Ontologist.
-- Defined exactly 6 binding dimensions: tier folder mapping, provenance grade mapping,
-  lint schema SSOT, embedder selection, ignore_for_external_apis glob, agent-writable zone
-  + write routing law.
-- Added Non-Sticky Guard (HARD): output written ONLY to `vault/.oms/taxonomy.yaml`.
-  Engine default `core/ontology/taxonomy.yaml` is never modified.
-- Added output shape YAML spec and executable helper reference.
-- Created `src/engine/setup/` with pure stateless helpers + co-located vitest tests.
-
-### Attribution
-
-- **omc deep-interview methodology** (self-reimplemented — method only, no code copied):
-  Socratic clarity loop structure, ambiguity scoring formula (1 − mean of sub-dimension scores),
-  Round-0 topology gate pattern, and Contrarian / Simplifier / Ontologist challenge modes
-  are reimplemented from the omc deep-interview skill methodology.
-  No source code was copied. The implementation is original TypeScript.
-
-### Files created or modified
-
-- `core/skills/setup/SKILL.md` — rewritten (this milestone)
-- `core/skills/setup/CHANGELOG.md` — created
-- `core/skills/setup/ACKNOWLEDGMENTS.partial.md` — created
-- `src/engine/setup/types.ts` — local types (DimensionScore, InterviewConfig, TaxonomyOutput)
-- `src/engine/setup/ambiguity.ts` — ambiguity scoring (computeAmbiguity, meetsThreshold, validateScores)
-- `src/engine/setup/writer.ts` — Non-Sticky Guard writer (writeTaxonomyToVaultOverride)
-- `src/engine/setup/ambiguity.test.ts` — vitest suite for ambiguity functions
-- `src/engine/setup/writer.test.ts` — vitest suite for Non-Sticky Guard enforcement
-
----
-
-## 0.1.0 — 2026-06-01
-
-Initial release (M0 setup CLI, `oms setup`).
-
-- Scanned existing top-level vault folders.
-- Asked intent and concept binding per folder.
-- Wrote `vault/.oms/taxonomy.yaml` with `version: 0`.
-- Copied shipped default concepts into `vault/.oms/concepts/`.

package/core/skills/setup/SKILL.md

@@ -1,246 +0,0 @@
----
-name: setup
-version: 0.2.0
-description: Socratic setup interview — guides the vault owner through exactly 6 binding dimensions (tier-folder mapping, provenance grades, lint-schema SSOT, embedder, ignore glob, agent-writable zone) and writes the result ONLY to vault/.oms/taxonomy.yaml.
-trigger: /setup
-tags: [setup, interview, socratic, taxonomy, config, oms]
----
-
-# Skill: setup
-
-Adopt an existing Obsidian vault into the Oh My Second Brain convention via a self-contained
-Socratic interview. This skill is the engine's OWN config/setup interview — it does NOT import
-or depend on the omc deep-interview skill. It self-reimplements the methodology; see CHANGELOG.md
-for attribution.
-
-**Non-Sticky Guard (HARD):** Interview output is written ONLY to
-`vault/.oms/taxonomy.yaml`. The engine default `core/ontology/taxonomy.yaml` is NEVER modified.
-
-## Methodology
-
-This skill embeds a Socratic clarity loop self-reimplemented from the omc deep-interview
-methodology (method only — no code copied; see CHANGELOG.md and ACKNOWLEDGMENTS.partial.md).
-
-### Ambiguity scoring
-
-Each response is scored across four sub-dimensions:
-
-| Sub-dimension | Question |
-|---------------|----------|
-| Goal | Does this dimension have a clear, testable outcome? |
-| Constraint | Are hard limits (paths, protocols, formats) explicit? |
-| Criteria | Can we verify completeness or correctness? |
-| Context | Is vault-specific context captured (not generic defaults)? |
-
-Score each sub-dimension 0–1 (1 = fully resolved).
-
-```
-ambiguity = 1 − mean(goal, constraint, criteria, context)
-```
-
-Loop continues while `ambiguity > threshold`. Default threshold: **0.20**.
-
-Threshold is configurable: set `OMS_AMBIGUITY_THRESHOLD=<float>` or pass
-`--ambiguity-threshold <float>` at the CLI.
-
-### Round-0 topology gate
-
-Run Round 0 before any dimension interview:
-
-1. List all top-level folders in the vault.
-2. Ask the owner to describe the vault's purpose in one sentence.
-3. Provisionally map folders to three canonical tiers: `raw`, `processed`, `wiki`.
-4. Gate check: if all three tiers cannot be provisionally assigned, stay in Round 0.
-   Do not advance to D1–D6 until the topology is clear.
-
-Round 0 has no round limit — it is a prerequisite, not a binding dimension.
-
-### Challenge modes
-
-After each dimension reaches `ambiguity ≤ threshold`, run one challenge pass in sequence:
-
-- **Contrarian**: Argue the opposite mapping. Does the dimension still hold?
-- **Simplifier**: Is there a simpler folder/path that achieves the same goal?
-- **Ontologist**: Is this dimension naming the right concept, or a surface symptom?
-
-A challenge that raises ambiguity above threshold re-opens the Socratic loop for that
-dimension only (up to the per-dimension round limit).
-
-## 6 Binding Dimensions
-
-Exactly these 6 — no more, no less. Each is time-boxed to **≤ 5 exchange rounds**.
-
-### D1 — Tier folder mapping
-
-Map vault top-level folders to the three canonical tiers:
-
-- `raw` — unprocessed captures; nothing required yet
-- `processed` — synthesised / reformatted external material
-- `wiki` — compiled concept pages (output of `oms compile`)
-
-**Output key:** `folders.<name>.tier` (`raw` | `processed` | `wiki`)
-
-Reference defaults (Ataraxia vault — clearly-labelled example; do NOT pre-fill):
-```yaml
-# Ataraxia reference only — discover the user's actual mapping
-raw: ["Inbox", "Fleeting"]
-processed: ["Literature", "Notes"]
-wiki: ["Wiki", "Concepts"]
-```
-
-### D2 — Provenance grade mapping
-
-Map vault folders to provenance grades used by the compile engine:
-
-- `authored` — written by the vault owner
-- `curated` — external sources the owner has read and synthesised
-- `external-raw` — raw captures, unverified external material
-
-**Output key:** `folders.<name>.provenance` (`authored` | `curated` | `external-raw`)
-
-Reference defaults (Ataraxia vault — example only; do NOT pre-fill):
-```yaml
-# Ataraxia reference only
-authored: ["Journal", "Essays"]
-curated: ["Literature", "Notes"]
-external-raw: ["Inbox"]
-```
-
-### D3 — Lint schema SSOT location
-
-Identify the single source of truth for the lint schema used by `oms doctor`:
-
-- `engine_default` — use the shipped defaults at `core/ontology/` unchanged
-- `vault_override` — the vault extends/overrides via `vault/.oms/concepts/`
-
-Elicit: has the owner customised any concept fields beyond the shipped defaults?
-
-**Output key:** `lint.schema_ssot` (`engine_default` | `vault_override`)
-
-### D4 — Embedder selection
-
-Select the embedding strategy for semantic retrieval:
-
-- `local` — local model (e.g. nomic-embed-text, all-MiniLM-L6-v2)
-- `openai` — OpenAI text-embedding-* API
-- `stub` — deterministic test stub (no real calls; for CI / offline use)
-
-**Output key:** `embedder.provider` and `embedder.model`
-
-### D5 — ignore_for_external_apis glob
-
-One or more glob patterns identifying notes that MUST NOT be sent to any external API.
-
-Discover from the vault — do NOT pre-fill categories. Prompt the owner to identify:
-- Sensitivity categories they care about
-- Existing frontmatter fields that signal privacy (e.g. `private: true`)
-- Folder naming conventions that imply sensitivity
-
-**Output key:** `ignore_for_external_apis` (array of glob strings)
-
-### D6 — Agent-writable zone + write routing law
-
-Define the paths agents are permitted to write to, and the routing law:
-
-- `agent_writable_zone` — array of vault-relative path prefixes agents may write
-- `write_routing_law`:
-  - `append_only` — agents may only append; never overwrite existing content
-  - `overwrite_allowed` — agents may create or overwrite within the zone
-  - `create_only` — agents may only create new files; never modify existing ones
-
-Paths outside `agent_writable_zone` are read-only to all agents.
-
-**Output key:** `agent_writable_zone` (string[]) and `write_routing_law`
-
-## Non-Sticky Guard (HARD)
-
-> Interview output is written ONLY to `vault/.oms/taxonomy.yaml`.
-> Writing to `core/ontology/taxonomy.yaml` or any engine path is FORBIDDEN.
-
-This guard is enforced by `oms setup` (`src/cli/setup-command.ts`) and by this skill:
-
-- The only write target is `{vaultRoot}/.oms/taxonomy.yaml`.
-- Never write to `core/ontology/taxonomy.yaml` or any other engine path.
-
-**Why this matters:** The engine default at `core/ontology/taxonomy.yaml` is the shared
-fallback for every vault. Overwriting it would silently propagate one vault's assumptions
-to all future users. Vault-local overrides preserve this separation permanently.
-
-## Recipe
-
-1. **Round-0 topology gate** — list folders, elicit one-sentence vault purpose, provisionally
-   map tiers. Block until three tiers are provisionally assigned.
-
-2. **Compute initial ambiguity** across Goal / Constraint / Criteria / Context for all 6
-   dimensions together. First pass always yields high ambiguity (~0.8); record it.
-
-3. **Interview D1–D6 in order.** For each dimension:
-   a. Ask the targeted dimension question.
-   b. Score all four sub-dimensions (goal / constraint / criteria / context).
-   c. While `ambiguity > threshold`, probe deeper (max 5 rounds per dimension).
-   d. Run Contrarian → Simplifier → Ontologist challenge passes.
-   e. If any challenge re-raises ambiguity, re-enter the loop for that dimension only.
-
-4. **Validate completeness** — confirm all 6 output keys are present and non-empty.
-
-5. **Write** to `{vaultRoot}/.oms/taxonomy.yaml` ONLY:
-   - Prefer `oms setup --vault <path>` for the non-interactive/default path.
-   - If writing during the interview, create `{vaultRoot}/.oms/` if needed, merge
-     with any existing file (do not clobber unrelated keys), and keep `version: 1`.
-
-6. **Confirm** — print the written path and the resolved values. Never silently succeed.
-
-## Output shape
-
-```yaml
-version: 1
-folders:
-  <name>:
-    intent: "<elicited intent>"
-    tier: raw | processed | wiki
-    provenance: authored | curated | external-raw
-    concept: <concept-name> | null
-lint:
-  schema_ssot: engine_default | vault_override
-embedder:
-  provider: local | openai | stub
-  model: "<model-id>"
-ignore_for_external_apis:
-  - "<glob>"
-agent_writable_zone:
-  - "<vault-relative-prefix>"
-write_routing_law: append_only | overwrite_allowed | create_only
-```
-
-## Shell-out (legacy CLI)
-
-The legacy `oms setup` CLI command remains available for non-interactive use:
-
-```bash
-oms setup [--vault <path>] [--yes]
-```
-
-`--yes` / `OMS_NON_INTERACTIVE=1` skips all interview prompts and accepts defaults (CI / non-TTY).
-
-## What setup does NOT do
-
-- Does NOT rename, move, or delete any existing notes.
-- Does NOT impose a new folder structure.
-- Does NOT modify existing frontmatter.
-- Does NOT touch `core/ontology/taxonomy.yaml`.
-
-## After setup
-
-Run the `doctor` skill to validate existing notes against the resolved convention:
-
-```bash
-oms doctor [--vault <path>]
-```
-
-## Executable helper
-
-Use the live CLI writer, not a parallel engine setup module:
-
-```bash
-oms setup [--vault <path>] [--yes]
-```

package/core/skills/uninstall/SKILL.md

@@ -1,34 +0,0 @@
----
-name: oms-uninstall
-description: Remove Oh My Second Brain host adapter and MCP registrations by running oms uninstall.
----
-
-# Skill: oms-uninstall (Claude Code)
-
-Remove Oh My Second Brain host registrations and adapter files. This does **not** delete vault notes or `vault/.oms/` ontology data.
-
-## Invocation
-
-```
-/oms-uninstall
-```
-
-## What this skill does
-
-Shells out to:
-
-```bash
-oms uninstall [--runtime <all|claude|codex|hermes>] [--dry-run] [--execute] [--yes]
-```
-
-## Recommended flow
-
-```bash
-# Preview first:
-oms uninstall --runtime all --dry-run
-
-# Remove Oh My Second Brain host registrations:
-oms uninstall --runtime all --yes
-```
-
-Use `--execute` only when you want Oh My Second Brain to call external host CLIs such as `claude mcp remove oms` or `claude plugin uninstall oms`.

package/core/skills/vault-decision-record/CHANGELOG.md

@@ -1,24 +0,0 @@
-# vault-decision-record — CHANGELOG
-
-## 0.1.0 — 2026-06-13
-
-Initial release (M5 governance skills, step 5).
-
-### Added
-
-- `core/skills/vault-decision-record/SKILL.md` — /skillify recipe for recording vault
-  structural changes as ADR markdown under .oms/governance/decisions/, with SUPERSEDE-ONLY
-  update semantics and an explicit Layer 1 CONTRACT guard.
-
-### Attribution
-
-- **ADR format (id / title / date / status / supersedes / superseded_by / context /
-  decision / consequences)**: derived from Michael Nygard's original ADR template
-  (https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions) —
-  IDEA-ONLY, no verbatim text, format reimplemented independently.
-- **SUPERSEDE-ONLY immutability rule**: self-authored; extends the append-only ledger
-  convention established in `src/engine/wiki/ledger.ts` (M3 staleness FSM).
-- **Layer 1 CONTRACT guard**: self-authored; mirrors the vault-confinement guard already
-  present in `src/capture/safe.ts` (`oms_capture_commit` rejects writes to `.oms/`).
-- **decisions/ zone**: generalised from the Ataraxia "95. Decisions" folder convention —
-  CONCEPT-ONLY, no verbatim content. Paired with `vault-scaffold` skill.