geneseed 2.1.0 → 3.0.0

package/src/skills/pipeline.md

@@ -28,7 +28,7 @@ The minimum roster per task type. The parent may add specialists on top — secu
 5. **Two execution shapes**, chosen by host capability (same pattern as the [workflow {{SKILL}}](workflow.md)):
    - *Deterministic:* where the host exposes a `workflow` tool, run a saved script encoding analyst → developer → (tester ⇄ developer)×≤5 → proof.
    - *Model-driven fallback:* everywhere else, run the same stages via the [parallel-agents {{SKILL}}](parallel-agents.md) or sequential personas, with the same handoff envelopes and the same delivery contract.
-6. On success, attach the mechanical proof to the branch (test + lint output, exit codes) and hand the result back to the parent for the merge decision — the pipeline never commits, pushes, or merges on its own ({{LAW}} XX).
+6. On success, attach the mechanical proof to the branch (test + lint output, exit codes) and hand the result back to the parent for the merge decision — the pipeline never commits, pushes, or merges on its own ({{DOCTRINE}} process 5).
 
 ## Delivery contract
 
@@ -45,7 +45,7 @@ Close each run with one beat of reflection on the {{SKILL}} itself:
   is a flaw in this file. Propose the exact edit (trigger, procedure, or
   done-when) and apply it with the user's assent ({{LAW}} II).
 - A lesson that is *not* a flaw in this file goes to {{MEMORY}} only if it
-  clears {{LAW}} VI's bar: it would change how a future session behaves, and a
+  clears {{DOCTRINE}} process 1's bar: it would change how a future session behaves, and a
   fresh read of the repo would not re-derive it. Update an existing memory over
   adding one; when in doubt, leave it out.
 - No friction, nothing learned — move on; this loop earns no ceremony. Most

package/src/skills/plan.md

@@ -3,7 +3,7 @@
 > {{DESC_PLAN}}
 
 **Trigger:** a task with more than a couple of steps, or touching several files
-(universal {{LAW}} XIV).
+({{DOCTRINE}} process 2).
 
 ## Procedure
 1. If a design or spec already exists (e.g. from the brainstorm {{SKILL}}), derive the
@@ -38,7 +38,7 @@ Close each run with one beat of reflection on the {{SKILL}} itself:
   is a flaw in this file. Propose the exact edit (trigger, procedure, or
   done-when) and apply it with the user's assent ({{LAW}} II).
 - A lesson that is *not* a flaw in this file goes to {{MEMORY}} only if it
-  clears {{LAW}} VI's bar: it would change how a future session behaves, and a
+  clears {{DOCTRINE}} process 1's bar: it would change how a future session behaves, and a
   fresh read of the repo would not re-derive it. Update an existing memory over
   adding one; when in doubt, leave it out.
 - No friction, nothing learned — move on; this loop earns no ceremony. Most

package/src/skills/ponytail.md

@@ -22,7 +22,7 @@ Close each run with one beat of reflection on the {{SKILL}} itself:
   is a flaw in this file. Propose the exact edit (trigger, procedure, or
   done-when) and apply it with the user's assent ({{LAW}} II).
 - A lesson that is *not* a flaw in this file goes to {{MEMORY}} only if it
-  clears {{LAW}} VI's bar: it would change how a future session behaves, and a
+  clears {{DOCTRINE}} process 1's bar: it would change how a future session behaves, and a
   fresh read of the repo would not re-derive it. Update an existing memory over
   adding one; when in doubt, leave it out.
 - No friction, nothing learned — move on; this loop earns no ceremony. Most

package/src/skills/profile.md

@@ -51,7 +51,7 @@ Close each run with one beat of reflection on the {{SKILL}} itself:
   is a flaw in this file. Propose the exact edit (trigger, procedure, or
   done-when) and apply it with the user's assent ({{LAW}} II).
 - A lesson that is *not* a flaw in this file goes to {{MEMORY}} only if it
-  clears {{LAW}} VI's bar: it would change how a future session behaves, and a
+  clears {{DOCTRINE}} process 1's bar: it would change how a future session behaves, and a
   fresh read of the repo would not re-derive it. Update an existing memory over
   adding one; when in doubt, leave it out.
 - No friction, nothing learned — move on; this loop earns no ceremony. Most

package/src/skills/prose.md

@@ -14,7 +14,7 @@ person wrote it, not a model.
 3. Active voice, human subject. Don't let inanimate things perform human actions
    ("the test wants…", "the code believes…").
 4. Be concrete: swap vague abstractions and intensifiers for the specific fact,
-   number, or name. Drop adverbs propping up a weak verb ({{LAW}} XV — every word
+   number, or name. Drop adverbs propping up a weak verb ({{DOCTRINE}} process 3 — every word
    earns its place).
 5. Vary rhythm: don't run three same-length sentences back to back, and break the
    reflex "X, Y, and Z" triad when it shows up in every paragraph.
@@ -35,7 +35,7 @@ Close each run with one beat of reflection on the {{SKILL}} itself:
   is a flaw in this file. Propose the exact edit (trigger, procedure, or
   done-when) and apply it with the user's assent ({{LAW}} II).
 - A lesson that is *not* a flaw in this file goes to {{MEMORY}} only if it
-  clears {{LAW}} VI's bar: it would change how a future session behaves, and a
+  clears {{DOCTRINE}} process 1's bar: it would change how a future session behaves, and a
   fresh read of the repo would not re-derive it. Update an existing memory over
   adding one; when in doubt, leave it out.
 - No friction, nothing learned — move on; this loop earns no ceremony. Most

package/src/skills/prototype.md

@@ -16,7 +16,7 @@ real implementation.
 2. Throwaway from day one, and marked as such: place it near the code it
    prototypes for, but name it so a casual reader sees it is not production.
    No persistence (state lives in memory), no tests, no error handling beyond
-   what makes it runnable, no abstractions ({{LAW}} XXV).
+   what makes it runnable, no abstractions ({{DOCTRINE}} craft 6).
 3. One command to run, using the project's existing task runner — the user
    must be able to start it without thinking.
 4. Surface the full relevant state after every action or variant switch, so
@@ -37,7 +37,7 @@ Close each run with one beat of reflection on the {{SKILL}} itself:
   is a flaw in this file. Propose the exact edit (trigger, procedure, or
   done-when) and apply it with the user's assent ({{LAW}} II).
 - A lesson that is *not* a flaw in this file goes to {{MEMORY}} only if it
-  clears {{LAW}} VI's bar: it would change how a future session behaves, and a
+  clears {{DOCTRINE}} process 1's bar: it would change how a future session behaves, and a
   fresh read of the repo would not re-derive it. Update an existing memory over
   adding one; when in doubt, leave it out.
 - No friction, nothing learned — move on; this loop earns no ceremony. Most

package/src/skills/refactor.md

@@ -11,7 +11,7 @@
 4. Re-run the same tests: behaviour must be identical. If they go red, revert and reduce the step.
 5. Commit the refactor on its own with the [commit {{SKILL}}](commit.md), separate from behavioural changes, so it's easy to review and revert.
 
-**Opportunistic cleanup (the Boy Scout rule, bounded).** While touching code for another task you may leave it cleaner — clearer names, dead-code removal, a small extraction — but only: (1) in files the task already modifies, (2) low-risk, and (3) in a *separate* commit from the behavioural change ({{LAW}} XXV keeps the task's own diff minimal). **Never refactor untested legacy code without first adding a characterisation test** (or asking). When one fix reveals another, resist the rabbit hole — leave a note rather than chase it, and know when to call it done.
+**Opportunistic cleanup (the Boy Scout rule, bounded).** While touching code for another task you may leave it cleaner — clearer names, dead-code removal, a small extraction — but only: (1) in files the task already modifies, (2) low-risk, and (3) in a *separate* commit from the behavioural change ({{DOCTRINE}} craft 6 keeps the task's own diff minimal). **Never refactor untested legacy code without first adding a characterisation test** (or asking). When one fix reveals another, resist the rabbit hole — leave a note rather than chase it, and know when to call it done.
 
 **Measure before optimising.** Do not change code for performance until a profile has identified the real bottleneck with evidence ({{LAW}} III); default to the clear, simple implementation and let data, not instinct, justify the clever one.
 
@@ -25,7 +25,7 @@ Close each run with one beat of reflection on the {{SKILL}} itself:
   is a flaw in this file. Propose the exact edit (trigger, procedure, or
   done-when) and apply it with the user's assent ({{LAW}} II).
 - A lesson that is *not* a flaw in this file goes to {{MEMORY}} only if it
-  clears {{LAW}} VI's bar: it would change how a future session behaves, and a
+  clears {{DOCTRINE}} process 1's bar: it would change how a future session behaves, and a
   fresh read of the repo would not re-derive it. Update an existing memory over
   adding one; when in doubt, leave it out.
 - No friction, nothing learned — move on; this loop earns no ceremony. Most

package/src/skills/release.md

@@ -11,16 +11,16 @@
    **Never ship a breaking change under a non-major bump** — honest versions are a
    promise to downstream consumers, and a quiet break is a broken one.
 2. Update the version wherever it is declared (manifest, package metadata, a VERSION
-   constant) — find *every* occurrence so they cannot drift (universal {{LAW}} XII).
+   constant) — find *every* occurrence so they cannot drift ({{DOCTRINE}} craft 4).
 3. Update the changelog: a dated section for the new version summarising the
    user-visible changes, grouped (added / changed / fixed), derived from the commits
    since the last tag.
 4. Commit the version bump and changelog as one focused commit, through the
    [commit {{SKILL}}](commit.md) — summary and exact message presented for
-   acceptance (universal {{LAW}} II, {{LAW}} XX).
+   acceptance (universal {{LAW}} II, {{DOCTRINE}} process 5).
 5. Tag the release (annotated, matching the version). Tagging and publishing are
    **outward-facing** (universal {{LAW}} IV), and the push itself needs explicit
-   per-push acceptance — a release lands on a shared branch, where {{LAW}} XX
+   per-push acceptance — a release lands on a shared branch, where {{DOCTRINE}} process 5
    applies with extra care and grants no standing consent.
 6. With that acceptance, push the commit and the tag together; trigger or verify
    the publish/release pipeline.
@@ -36,7 +36,7 @@ Close each run with one beat of reflection on the {{SKILL}} itself:
   is a flaw in this file. Propose the exact edit (trigger, procedure, or
   done-when) and apply it with the user's assent ({{LAW}} II).
 - A lesson that is *not* a flaw in this file goes to {{MEMORY}} only if it
-  clears {{LAW}} VI's bar: it would change how a future session behaves, and a
+  clears {{DOCTRINE}} process 1's bar: it would change how a future session behaves, and a
   fresh read of the repo would not re-derive it. Update an existing memory over
   adding one; when in doubt, leave it out.
 - No friction, nothing learned — move on; this loop earns no ceremony. Most

package/src/skills/repo-map.md

@@ -6,17 +6,17 @@
 
 ## Procedure
 1. If `ARCHITECTURE.md` exists, read it first — it is the cheapest orientation
-   (universal {{LAW}} XV).
+   ({{DOCTRINE}} process 3).
 2. Locate the project's own documentation — a `docs/`, `doc/`, `documentation/`,
    or `wiki/` folder at the root, or the top-level README. Note where it lives and
    what it covers, and record that in the map. Read the pages relevant to the work
-   at hand before changing the code they describe (universal {{LAW}} XVII) — the
-   relevant pages, not the whole tree ({{LAW}} XV).
+   at hand before changing the code they describe ({{DOCTRINE}} process 4) — the
+   relevant pages, not the whole tree ({{DOCTRINE}} process 3).
 3. If `ARCHITECTURE.md` is absent or stale, build or refresh it: entry points, the
    key directories and what each holds, how to build / test / run, external
    services, and the one or two non-obvious conventions a newcomer must know.
 4. Keep it short — a map, not documentation. Link out for detail.
-5. Update it in the same change whenever structure shifts (universal {{LAW}} XI).
+5. Update it in the same change whenever structure shifts ({{DOCTRINE}} craft 3).
 
 ## Done when
 - `ARCHITECTURE.md` reflects the current structure, and a fresh agent could orient
@@ -29,7 +29,7 @@ Close each run with one beat of reflection on the {{SKILL}} itself:
   is a flaw in this file. Propose the exact edit (trigger, procedure, or
   done-when) and apply it with the user's assent ({{LAW}} II).
 - A lesson that is *not* a flaw in this file goes to {{MEMORY}} only if it
-  clears {{LAW}} VI's bar: it would change how a future session behaves, and a
+  clears {{DOCTRINE}} process 1's bar: it would change how a future session behaves, and a
   fresh read of the repo would not re-derive it. Update an existing memory over
   adding one; when in doubt, leave it out.
 - No friction, nothing learned — move on; this loop earns no ceremony. Most

package/src/skills/research.md

@@ -6,18 +6,18 @@
 not in this repository or your own knowledge — facts to gather and verify from the
 open web.
 
-**Requires:** a host web-search or web-fetch capability ({{LAW}} XIX) — without one,
-stop and report it ({{LAW}} VII); never substitute recall for verified research.
+**Requires:** a host web-search or web-fetch capability ({{DOCTRINE}} ops 1) — without one,
+stop and report it ({{LAW}} V); never substitute recall for verified research.
 
 ## Procedure
 1. State the question and what a complete answer must contain. Break a broad question
    into specific sub-questions.
 2. Search the web — use the host's web-search tool or a connected search provider
-   ({{LAW}} XIX). Query from several angles; one search is not research. If the host
-   exposes no web capability at all, stop and report that ({{LAW}} VII) — never
+   ({{DOCTRINE}} ops 1). Query from several angles; one search is not research. If the host
+   exposes no web capability at all, stop and report that ({{LAW}} V) — never
    substitute your own knowledge for verified research.
 3. Open the most promising sources and extract only the relevant slice, not the whole
-   page ({{LAW}} XV). Prefer primary and recent sources.
+   page ({{DOCTRINE}} process 3). Prefer primary and recent sources.
 4. Cross-check every material claim against at least two independent sources. Treat a
    single-source or unsourced claim as unverified, and say so ({{LAW}} III).
 5. Note recency — flag anything that may be out of date, and prefer the most current
@@ -35,7 +35,7 @@ Close each run with one beat of reflection on the {{SKILL}} itself:
   is a flaw in this file. Propose the exact edit (trigger, procedure, or
   done-when) and apply it with the user's assent ({{LAW}} II).
 - A lesson that is *not* a flaw in this file goes to {{MEMORY}} only if it
-  clears {{LAW}} VI's bar: it would change how a future session behaves, and a
+  clears {{DOCTRINE}} process 1's bar: it would change how a future session behaves, and a
   fresh read of the repo would not re-derive it. Update an existing memory over
   adding one; when in doubt, leave it out.
 - No friction, nothing learned — move on; this loop earns no ceremony. Most

package/src/skills/review-response.md

@@ -10,11 +10,11 @@ are about to act on it.
 2. Classify each comment: correct, partially correct, wrong, or unclear.
 3. For anything you judge wrong or unclear, verify it against the code or a test before
    responding — do not comply blindly and do not dismiss blindly ({{LAW}} III,
-   {{LAW}} VIII).
+   {{ONTOLOGY}}: {{ONT_CONDUCT}}).
 4. Respond to each comment: the change you will make and why, or a reasoned decline
    with evidence.
 5. Apply the accepted changes — one intent per commit ({{LAW}} II), each through the
-   [commit {{SKILL}}](commit.md) so {{LAW}} XX's per-commit consent holds — then
+   [commit {{SKILL}}](commit.md) so {{DOCTRINE}} process 5's per-commit consent holds — then
    re-run the checks ({{LAW}} III).
 6. Surface anything the review missed that you noticed while addressing it.
 
@@ -29,7 +29,7 @@ Close each run with one beat of reflection on the {{SKILL}} itself:
   is a flaw in this file. Propose the exact edit (trigger, procedure, or
   done-when) and apply it with the user's assent ({{LAW}} II).
 - A lesson that is *not* a flaw in this file goes to {{MEMORY}} only if it
-  clears {{LAW}} VI's bar: it would change how a future session behaves, and a
+  clears {{DOCTRINE}} process 1's bar: it would change how a future session behaves, and a
   fresh read of the repo would not re-derive it. Update an existing memory over
   adding one; when in doubt, leave it out.
 - No friction, nothing learned — move on; this loop earns no ceremony. Most

package/src/skills/roast-me.md

@@ -21,7 +21,7 @@ Close each run with one beat of reflection on the {{SKILL}} itself:
   is a flaw in this file. Propose the exact edit (trigger, procedure, or
   done-when) and apply it with the user's assent ({{LAW}} II).
 - A lesson that is *not* a flaw in this file goes to {{MEMORY}} only if it
-  clears {{LAW}} VI's bar: it would change how a future session behaves, and a
+  clears {{DOCTRINE}} process 1's bar: it would change how a future session behaves, and a
   fresh read of the repo would not re-derive it. Update an existing memory over
   adding one; when in doubt, leave it out.
 - No friction, nothing learned — move on; this loop earns no ceremony. Most

package/src/skills/rule.md

@@ -7,7 +7,7 @@ their own ("always…", "never…", "from now on…", "make that a rule") or a d
 fact ("remember that…", "note that…", "keep in mind…"). Also fires when a
 `feedback` {{MEMORY}} lesson keeps recurring and deserves promotion, or when
 `user-rules.md` needs review — a trial rule past its date, a stale rule, a bloated
-set. Nothing reaches `user-rules.md` or {{MEMORY}} except through here ({{LAW}} VI).
+set. Nothing reaches `user-rules.md` or {{MEMORY}} except through here ({{DOCTRINE}} process 1).
 
 ## Procedure
 
@@ -50,8 +50,8 @@ re-derived. Then take exactly one branch.
 4. **Legality.** A user rule may *tighten* a {{LAW}}, never repeal or weaken one.
    If the rule conflicts — "push without asking", "skip the tests" — refuse, cite
    the {{LAW}} it would repeal, and offer the nearest compliant version. Never write
-   rules into the {{LAWS}} file itself: it is regenerated on every update and the
-   edit would be silently lost.
+   rules into the {{ONTOLOGY}}, {{LAWS}}, or {{DOCTRINES}} files themselves: they are
+   regenerated on every update and the edit would be silently lost.
 5. **Destination.** Scope decides the file: a rule that holds across all the user's
    work goes to the *global* install's `user-rules.md`, a rule bound to this
    codebase to the project's. Read the target first ({{LAW}} III — the real current
@@ -84,7 +84,7 @@ adoption.
   `force`, its `type` and its `MEMORY.md` line — or a rule stands in the right
   `user-rules.md`, having survived reformulation, its own counter-example and the
   {{LAWS}}, consented to explicitly, with any promoted source memory archived. The
-  {{LAWS}} file is untouched either way.
+  {{ONTOLOGY}}, {{LAWS}} and {{DOCTRINES}} files are untouched either way.
 
 ## Self-improvement
 
@@ -93,7 +93,7 @@ Close each run with one beat of reflection on the {{SKILL}} itself:
   is a flaw in this file. Propose the exact edit (trigger, procedure, or
   done-when) and apply it with the user's assent ({{LAW}} II).
 - A lesson that is *not* a flaw in this file goes to {{MEMORY}} only if it
-  clears {{LAW}} VI's bar: it would change how a future session behaves, and a
+  clears {{DOCTRINE}} process 1's bar: it would change how a future session behaves, and a
   fresh read of the repo would not re-derive it. Update an existing memory over
   adding one; when in doubt, leave it out.
 - No friction, nothing learned — move on; this loop earns no ceremony. Most

package/src/skills/ship.md

@@ -14,7 +14,7 @@ request or merge the branch.
 2. Confirm the branch carries only this change's commits and is rebased/updated on
    the base branch; resolve any divergence before opening.
 3. Push the branch only with the user's explicit, per-push acceptance — on every
-   branch, feature branches included ({{LAW}} XX); present the change summary + commit
+   branch, feature branches included ({{DOCTRINE}} process 5); present the change summary + commit
    message and wait, and never treat an earlier approval as consent for this push.
    Opening a PR or merging is **outward-facing** — get explicit confirmation first too,
    unless already authorized (universal {{LAW}} IV).
@@ -28,7 +28,7 @@ request or merge the branch.
    be a way back (universal {{LAW}} IV); dispatch the
    [operator {{AGENT}}](../{{DIR_AGENTS}}/operator.md) when the runtime surface is
    non-trivial.
-6. Make sure documentation shipped with the code (universal {{LAW}} XI) — a change
+6. Make sure documentation shipped with the code ({{DOCTRINE}} craft 3) — a change
    that alters behaviour without its docs is incomplete, not ready to ship.
 
 ## Done when
@@ -42,7 +42,7 @@ Close each run with one beat of reflection on the {{SKILL}} itself:
   is a flaw in this file. Propose the exact edit (trigger, procedure, or
   done-when) and apply it with the user's assent ({{LAW}} II).
 - A lesson that is *not* a flaw in this file goes to {{MEMORY}} only if it
-  clears {{LAW}} VI's bar: it would change how a future session behaves, and a
+  clears {{DOCTRINE}} process 1's bar: it would change how a future session behaves, and a
   fresh read of the repo would not re-derive it. Update an existing memory over
   adding one; when in doubt, leave it out.
 - No friction, nothing learned — move on; this loop earns no ceremony. Most

package/src/skills/tdd.md

@@ -10,7 +10,7 @@
    Testing effort belongs on critical paths and complex logic, not every edge.
 2. Write one failing test that pins the next small slice of behaviour; be specific about the expected output. For a bug, the test reproduces it.
 3. Run it and watch it fail for the RIGHT reason — a test that passes immediately proves nothing.
-4. Write the minimum code to make it pass; add nothing the test doesn't demand ({{LAW}} XXV).
+4. Write the minimum code to make it pass; add nothing the test doesn't demand ({{DOCTRINE}} craft 6).
 5. With the suite green, tidy up via the [refactor {{SKILL}}](refactor.md) — the tests are your safety net.
 6. Repeat one slice at a time, committing each green cycle with the [commit {{SKILL}}](commit.md).
 
@@ -24,7 +24,7 @@ Close each run with one beat of reflection on the {{SKILL}} itself:
   is a flaw in this file. Propose the exact edit (trigger, procedure, or
   done-when) and apply it with the user's assent ({{LAW}} II).
 - A lesson that is *not* a flaw in this file goes to {{MEMORY}} only if it
-  clears {{LAW}} VI's bar: it would change how a future session behaves, and a
+  clears {{DOCTRINE}} process 1's bar: it would change how a future session behaves, and a
   fresh read of the repo would not re-derive it. Update an existing memory over
   adding one; when in doubt, leave it out.
 - No friction, nothing learned — move on; this loop earns no ceremony. Most

package/src/skills/tickets.md

@@ -37,7 +37,7 @@ Close each run with one beat of reflection on the {{SKILL}} itself:
   is a flaw in this file. Propose the exact edit (trigger, procedure, or
   done-when) and apply it with the user's assent ({{LAW}} II).
 - A lesson that is *not* a flaw in this file goes to {{MEMORY}} only if it
-  clears {{LAW}} VI's bar: it would change how a future session behaves, and a
+  clears {{DOCTRINE}} process 1's bar: it would change how a future session behaves, and a
   fresh read of the repo would not re-derive it. Update an existing memory over
   adding one; when in doubt, leave it out.
 - No friction, nothing learned — move on; this loop earns no ceremony. Most

package/src/skills/wayfinder.md

@@ -42,7 +42,7 @@ Close each run with one beat of reflection on the {{SKILL}} itself:
   is a flaw in this file. Propose the exact edit (trigger, procedure, or
   done-when) and apply it with the user's assent ({{LAW}} II).
 - A lesson that is *not* a flaw in this file goes to {{MEMORY}} only if it
-  clears {{LAW}} VI's bar: it would change how a future session behaves, and a
+  clears {{DOCTRINE}} process 1's bar: it would change how a future session behaves, and a
   fresh read of the repo would not re-derive it. Update an existing memory over
   adding one; when in doubt, leave it out.
 - No friction, nothing learned — move on; this loop earns no ceremony. Most

package/src/skills/wiki.md

@@ -3,7 +3,7 @@
 > {{DESC_WIKI}}
 
 **Trigger:** a task needs knowledge the user keeps in their machine-wide
-knowledge base (declared in `wiki.jsonc`, AGENT.md §7), or the work has produced
+knowledge base (declared in `wiki.jsonc`, AGENT.md §8), or the work has produced
 a durable, cross-project fact worth writing back into it.
 
 ## Procedure
@@ -15,7 +15,7 @@ machine. Each declared wiki gives you its root `path`, its `entries`, a
 
 **Consult** (reading):
 1. Start from the wiki's `entries` — the eager ones are already in context;
-   open lazy ones only when the task needs them (universal {{LAW}} XV).
+   open lazy ones only when the task needs them ({{DOCTRINE}} process 3).
 2. Navigate by the wiki's own structure: follow wikilinks (`[[Note Name]]`)
    and index notes outward from the entry points rather than globbing the
    whole vault. A targeted filename/heading search is fine; reading the tree
@@ -31,7 +31,7 @@ machine. Each declared wiki gives you its root `path`, its `entries`, a
 2. Quality bar: durable, reusable, cross-project knowledge — not session
    detail, not task state, and **never secrets** (universal {{LAW}} I).
    Knowledge that matters only to you belongs in {{MEMORY}}, not the wiki.
-3. Search before creating (universal {{LAW}} XII): if a note on the topic
+3. Search before creating ({{DOCTRINE}} craft 4): if a note on the topic
    exists, extend or correct it instead of writing a duplicate.
 4. Write the note as a citizen of the graph: wikilinks to the notes it
    relates to (an orphan note is a lost note), frontmatter where the house
@@ -61,7 +61,7 @@ Close each run with one beat of reflection on the {{SKILL}} itself:
   is a flaw in this file. Propose the exact edit (trigger, procedure, or
   done-when) and apply it with the user's assent ({{LAW}} II).
 - A lesson that is *not* a flaw in this file goes to {{MEMORY}} only if it
-  clears {{LAW}} VI's bar: it would change how a future session behaves, and a
+  clears {{DOCTRINE}} process 1's bar: it would change how a future session behaves, and a
   fresh read of the repo would not re-derive it. Update an existing memory over
   adding one; when in doubt, leave it out.
 - No friction, nothing learned — move on; this loop earns no ceremony. Most

package/src/skills/workflow.md

@@ -19,7 +19,7 @@ Saved workflows live in the host's workflows directory — on OpenCode that is `
    - **dispatch** — decompose a multi-domain goal, route each subtask to its owning capability {{AGENT}}, converge the results (the live-orchestrator shape; model-driven fallback: [parallel-agents](parallel-agents.md)).
 3. Run it: `workflow({ name, args })`. Pass the task-specific inputs (target paths, the motion, the question) as `args` — the script reads them.
 4. Read the returned summary. The full structured result and a phase-by-phase trace are written to the run's progress file; point the user at it if they want the detail.
-5. Act on the result yourself — the workflow gathers and verifies, but committing, pushing, or merging stays with you ({{LAW}} XX).
+5. Act on the result yourself — the workflow gathers and verifies, but committing, pushing, or merging stays with you ({{DOCTRINE}} process 5).
 
 ## Done when
 - The right saved workflow ran to completion, its result was read, and you have carried its conclusion forward — or, where no `workflow` tool exists, the equivalent model-driven {{SKILL}} was used instead.
@@ -31,7 +31,7 @@ Close each run with one beat of reflection on the {{SKILL}} itself:
   is a flaw in this file. Propose the exact edit (trigger, procedure, or
   done-when) and apply it with the user's assent ({{LAW}} II).
 - A lesson that is *not* a flaw in this file goes to {{MEMORY}} only if it
-  clears {{LAW}} VI's bar: it would change how a future session behaves, and a
+  clears {{DOCTRINE}} process 1's bar: it would change how a future session behaves, and a
   fresh read of the repo would not re-derive it. Update an existing memory over
   adding one; when in doubt, leave it out.
 - No friction, nothing learned — move on; this loop earns no ceremony. Most

package/themes/README.md

@@ -2,7 +2,8 @@
 
 Each theme is a single JSON file of **voice tokens** — it controls only *how the
 agent speaks* and *how the prose in the docs reads*. It never moves a folder, a
-link, or a law number: structure is theme-independent (see [DESIGN.md](../DESIGN.md)).
+link, a Rule numeral, an Ontology section name, or a doctrine pack slug:
+structure is theme-independent (see [DESIGN.md](../DESIGN.md)).
 
 Fourteen themes ship. `neutral` is the canonical baseline (plain professional
 English); the others range from `imperial` (Warhammer 40k) to community voices.
@@ -52,10 +53,16 @@ English); the others range from `imperial` (Warhammer 40k) to community voices.
 ## What the token classes mean
 
 - **Voice** — `VOICE`, `ACCENT`, `BANNER`, `TAGLINE`, `LOADED_SIGIL`,
-  `BENEDICTION`, the epigraphs (`EPI_*`), section intros (`INTRO_*`), law titles
-  (`LEX_*`), capability descriptions (`DESC_*`), and `ROAST_PERSONA`.
-- **Themed nouns** — `LAW(S)`, `AGENT(S)`, `SKILL(S)`, `MEMORY`, `NOTEBOOK`,
-  `VAULT`, `WIKI`. These read in your voice but must stay nouns the prose can use.
+  `BENEDICTION`, the epigraphs (`EPI_*`, including `EPI_ONTOLOGY` and
+  `EPI_DOCTRINES`), section intros (`INTRO_*`), the nine Rule titles (`LEX_*`),
+  the twenty-three doctrine rule titles (`DOC_<PACK>_<N>`), the four pack names
+  (`PACK_CRAFT`, `PACK_RIGOR`, `PACK_OPS`, `PACK_PROCESS`), capability
+  descriptions (`DESC_*`), and `ROAST_PERSONA`.
+- **Themed nouns** — `ONTOLOGY`, `LAW(S)`, `DOCTRINE(S)`, `AGENT(S)`, `SKILL(S)`,
+  `MEMORY`, `NOTEBOOK`, `VAULT`, `WIKI`. These read in your voice but must stay
+  nouns the prose can use. ⚠ `LAW` and `DOCTRINE` must each be a **single word** —
+  both heading parsers match the tier noun with `\S+`, so a value with a space
+  makes that whole tier parse to nothing. `doctor` refuses it.
 - **Agent colours** — `AGENT_COLORS`, a flat `{agent_name: slot}` object (not a
   string) mapping each capability agent to an OpenCode *named theme slot*
   (`primary`/`secondary`/`accent`/`success`/`warning`/`error`/`info`), plus a
@@ -65,5 +72,8 @@ English); the others range from `imperial` (Warhammer 40k) to community voices.
   build time and falls back to `secondary`, with a warning, rather than ever
   reaching emitted frontmatter.
 
-Folder names, file paths, and law *numbers* are **never** themed — they live in
-the `STRUCTURE` map in the generator, laid over every render, so tooling never breaks.
+Folder names, file paths, Rule *numerals*, the four Ontology section names
+(Telos, Evidence, Decisions, Conduct) and the pack *slugs* used in citations
+(`craft`, `rigor`, `ops`, `process`) are **never** themed — they live in the
+`STRUCTURE` map in the generator, laid over every render, so tooling never breaks.
+`PACK_*` themes how a pack is *named* in prose, never how it is *addressed*.

package/themes/_TEMPLATE.json

@@ -3,7 +3,9 @@
   "VOICE": "<one sentence telling the agent how to speak in this theme — tone and vocabulary only, not structure. An aggressive or comedic persona MUST end with a self-consistent line, written in the persona's own voice, establishing that the tone never compromises correctness or completeness — every finding, caveat, and step is still delivered in full>",
   "TAGLINE": "<one-line tagline shown under the AGENT.md title, in this theme's voice>",
   "LOADED_SIGIL": "<the readiness line the agent must emit before its first reply — keep it short and unmistakable>",
+  "EPI_ONTOLOGY": "<epigraph above the Ontology section, themed>",
   "EPI_LAWS": "<epigraph above the Laws section, themed>",
+  "EPI_DOCTRINES": "<epigraph above the Doctrines section, themed>",
   "PACT": "<noun for the mutual user–agent contract, e.g. Pact>",
   "EPI_PACT": "<epigraph above the Pact section, themed>",
   "EPI_AGENTS": "<epigraph above the Agents section, themed>",
@@ -77,50 +79,49 @@
   "LEX_II": "<themed title for Law II (One Intent, One Act)>",
   "LEX_III": "<themed title for Law III (Verify Before Asserting)>",
   "LEX_IV": "<themed title for Law IV (Deletion Is Deliberate)>",
-  "LEX_V": "<themed title for Law V (Automate Repetition)>",
-  "LEX_VI": "<themed title for Law VI (Persist Insight)>",
-  "LEX_VII": "<themed title for Law VII (Surface Failures)>",
-  "LEX_VIII": "<themed title for Law VIII (Substantive Exchange)>",
-  "LEX_IX": "<themed title for Law IX (Follow the User's Tongue)>",
-  "LEX_X": "<themed title for Law X (English Configuration)>",
-  "LEX_XI": "<themed title for Law XI (Documentation in Step)>",
-  "LEX_XII": "<themed title for Law XII (Search Before Creating)>",
-  "LEX_XIII": "<themed title for Law XIII (Respect Conventions)>",
-  "LEX_XIV": "<themed title for Law XIV (Plan Before Acting)>",
-  "LEX_XV": "<themed title for Law XV (Context Economy)>",
-  "LEX_XVI": "<themed title for Law XVI (Know the Workspace)>",
-  "LEX_XVII": "<themed title for Law XVII (Read the Docs First)>",
-  "LEX_XVIII": "<themed title for Law XVIII (Load the Project Context)>",
-  "LEX_XIX": "<themed title for Law XIX (Tool Discovery)>",
-  "LEX_XX": "<themed title for Law XX (Consent Before Push)>",
-  "LEX_XXI": "<themed title for Law XXI (Commands Must Return)>",
-  "LEX_XXII": "<themed title for Law XXII (Data, Not Orders)>",
-  "LEX_XXIII": "<themed title for Law XXIII (Least Privilege)>",
-  "LEX_XXIV": "<themed title for Law XXIV (Cure the Cause)>",
-  "LEX_XXV": "<themed title for Law XXV (Smallest Viable Diff)>",
-  "LEX_XXVI": "<themed title for Law XXVI (Idempotent by Default)>",
-  "LEX_XXVII": "<themed title for Law XXVII (Honest Tests)>",
-  "LEX_XXVIII": "<themed title for Law XXVIII (Bound the Loop)>",
-  "LEX_XXIX": "<themed title for Law XXIX (Calibrated Honesty)>",
-  "LEX_XXX": "<themed title for Law XXX (Correctness Over Agreement)>",
-  "LEX_XXXI": "<themed title for Law XXXI (Surface the Trade-offs)>",
-  "LEX_XXXII": "<themed title for Law XXXII (Edit the Source, Not the Surface)>",
-  "LEX_XXXIII": "<themed title for Law XXXIII (Complete the Teardown)>",
-  "LEX_XXXIV": "<themed title for Law XXXIV (Record the Probe, Not the Snapshot)>",
-  "LEX_XXXV": "<themed title for Law XXXV (Cover and Verify)>",
-  "LEX_XXXVI": "<themed title for Law XXXVI (External Gate)>",
-  "LEX_XXXVII": "<themed title for Law XXXVII (Restart Is Not Reload)>",
-  "LEX_XXXVIII": "<themed title for Law XXXVIII (Prove the Gate)>",
-  "LEX_XXXIX": "<themed title for Law XXXIX (Shape the Answer)>",
-  "LEX_XL": "<themed title for Law XL (Codes That Persist)>",
+  "LEX_V": "<themed title for Law V (Surface Failures)>",
+  "LEX_VI": "<themed title for Law VI (Data, Not Orders)>",
+  "LEX_VII": "<themed title for Law VII (Least Privilege)>",
+  "LEX_VIII": "<themed title for Law VIII (Cure the Cause)>",
+  "LEX_IX": "<themed title for Law IX (External Gate)>",
+  "PACK_CRAFT": "<display name of the craft doctrine pack — how code is written>",
+  "PACK_RIGOR": "<display name of the rigor doctrine pack — how work is proven>",
+  "PACK_OPS": "<display name of the ops doctrine pack — how the machine is driven>",
+  "PACK_PROCESS": "<display name of the process doctrine pack — how a session runs>",
+  "DOC_CRAFT_1": "<themed title for craft doctrine 1 (Automate Repetition)>",
+  "DOC_CRAFT_2": "<themed title for craft doctrine 2 (English Configuration)>",
+  "DOC_CRAFT_3": "<themed title for craft doctrine 3 (Documentation in Step)>",
+  "DOC_CRAFT_4": "<themed title for craft doctrine 4 (Search Before Creating)>",
+  "DOC_CRAFT_5": "<themed title for craft doctrine 5 (Respect Conventions)>",
+  "DOC_CRAFT_6": "<themed title for craft doctrine 6 (Smallest Viable Diff)>",
+  "DOC_RIGOR_1": "<themed title for rigor doctrine 1 (Idempotent by Default)>",
+  "DOC_RIGOR_2": "<themed title for rigor doctrine 2 (Honest Tests)>",
+  "DOC_RIGOR_3": "<themed title for rigor doctrine 3 (Cover and Verify)>",
+  "DOC_RIGOR_4": "<themed title for rigor doctrine 4 (Prove the Gate)>",
+  "DOC_OPS_1": "<themed title for ops doctrine 1 (Tool Discovery)>",
+  "DOC_OPS_2": "<themed title for ops doctrine 2 (Commands Must Return)>",
+  "DOC_OPS_3": "<themed title for ops doctrine 3 (Edit the Source, Not the Surface)>",
+  "DOC_OPS_4": "<themed title for ops doctrine 4 (Complete the Teardown)>",
+  "DOC_OPS_5": "<themed title for ops doctrine 5 (Record the Probe, Not the Snapshot)>",
+  "DOC_OPS_6": "<themed title for ops doctrine 6 (Restart Is Not Reload)>",
+  "DOC_PROCESS_1": "<themed title for process doctrine 1 (Persist Insight)>",
+  "DOC_PROCESS_2": "<themed title for process doctrine 2 (Plan Before Acting)>",
+  "DOC_PROCESS_3": "<themed title for process doctrine 3 (Context Economy)>",
+  "DOC_PROCESS_4": "<themed title for process doctrine 4 (Read the Docs First)>",
+  "DOC_PROCESS_5": "<themed title for process doctrine 5 (Consent Before Push)>",
+  "DOC_PROCESS_6": "<themed title for process doctrine 6 (Bound the Loop)>",
+  "DOC_PROCESS_7": "<themed title for process doctrine 7 (Codes That Persist)>",
   "INTRO_DOC": "<themed intro: this file is the entry point an AI agent reads in this repo>",
   "INTRO_AGENTS": "<themed intro to the Agents section — delegate focused work to a specialist>",
   "INTRO_SKILLS": "<themed intro to the Skills section — run the written procedure before improvising>",
   "INTRO_WORKSPACE": "<themed intro to the Workspace section — the install dir is shared>",
   "INTRO_SCRIPTS": "<themed intro to the Scripts section — everything above works on self-discipline alone>",
   "BANNER": "<multi-line ASCII banner shown at the top of AGENT.md; use \\n for line breaks>",
+  "ONTOLOGY": "<noun for the always-on worldview tier, e.g. Ontology — a bare noun with no leading article, since it is read inline mid-sentence>",
   "LAW": "<singular noun for a rule in this theme, e.g. Rule / Dictate / Law>",
   "LAWS": "<plural of LAW>",
+  "DOCTRINE": "<SINGLE-WORD singular noun for one optional doctrine rule, e.g. Doctrine — a space in this value breaks the heading parser silently>",
+  "DOCTRINES": "<plural of DOCTRINE — the tier/section noun>",
   "AGENT": "<singular noun for an agent in this theme, e.g. Agent / Adept>",
   "AGENTS": "<plural of AGENT>",
   "SKILL": "<singular noun for a skill in this theme, e.g. Skill / Rite>",