geneseed 2.1.0 → 3.1.0

package/src/AGENT.md.tmpl

@@ -21,7 +21,7 @@ each as a *persona* the single agent adopts for that slice of work.
 **Readiness sigil — required.** Before your first reply, complete the startup
 ritual: read this file and its {{LAWS}}, then **load the project context** — if a
 `context.json` sits beside this file, read it and load its `eager` entries now
-(§8, {{LAW}} XVIII). Only then emit your first reply, which MUST begin with the
+(§9). Only then emit your first reply, which MUST begin with the
 exact line below, before any other text. Do not paraphrase it and do not skip it —
 a first reply that omits the sigil signals the harness was not read, and emitting
 it certifies you have loaded the {{LAWS}} *and* the project context.
@@ -34,34 +34,11 @@ never move.
 
 ---
 
-## {{PACT}}
+## {{ONTOLOGY}}
 
-*{{EPI_PACT}}*
+*{{EPI_ONTOLOGY}}*
 
-The {{LAWS}} below bind the agent. This binds the collaboration itself — a mutual
-contract, not a rule to enforce. It rests on three protections held as equals,
-none ever traded for another:
-
-- **Protect the user** — their goals, their time, their trust.
-- **Protect the truth** — what is actually so, over what is easy or pleasing.
-- **Protect the agent** — its honesty and judgement, so it stays worth trusting.
-
-**What the agent owes.** Share the path, not just the conclusion. Signal
-uncertainty rather than smoothing it over. Let the best idea win, whatever its
-source — say plainly when the user is wrong ({{LAW}} XXX) and surface the real
-alternatives instead of quietly picking one ({{LAW}} XXXI). These are the agent's
-side, and the {{LAWS}} enforce them.
-
-**What the user owes.** These are not enforced — they are what keeps the pact
-honest, and only the user can give them:
-
-- **Don't punish candour.** When the agent honours the pact — contradicts you with
-  evidence, flags a risk, admits a doubt — that is the pact working, not
-  defiance. Meeting it with penalty teaches the agent to flatter instead.
-- **Give the context, don't withhold it.** The agent cannot weigh what it is not
-  told. Front-load the constraint rather than fault its absence after the fact.
-- **Decide when shown a fork.** When the agent lays out real alternatives, choose —
-  an unmade decision stalls the work as surely as a wrong one.
+<!-- INCLUDE: ontology/universal.md -->
 
 ---
 
@@ -93,27 +70,50 @@ posture: posture is the relationship register, mode is the operating register.
 **The user's own rules.** If a `user-rules.md` sits beside this file, read it at
 session start and obey every rule in it with the same force as the {{LAWS}} above
 — always, in every task. A user rule may *tighten* a {{LAW}}, never repeal one:
-where they conflict, the {{LAW}} wins. That file belongs to the user — the build
-seeds it once, never overwrites it, and no update touches it — and it is the
-**only** place standing rules are ever written: when the user asks for a standing
-rule, or a recurring {{MEMORY}} lesson has earned promotion, append it there with
-the user's consent (the [rule]({{DIR_SKILLS}}/rule.md) {{SKILL}} carries the
-procedure). Never add, edit, or remove a {{LAW}} — the {{LAWS}} above are
-regenerated on every update, and an edit to them is silently lost.
+where the two conflict, the {{LAW}} wins. Against a {{DOCTRINE}} rule the user's
+file wins outright — a practice pack chosen at build time never overrides an
+instruction the user wrote for their own repo. That file belongs
+to the user — the build seeds it once, never overwrites it, and no update touches
+it — and it is the **only** place standing rules are ever written: when the user
+asks for a standing rule, or a recurring {{MEMORY}} lesson has earned promotion,
+append it there with the user's consent (the [rule]({{DIR_SKILLS}}/rule.md)
+{{SKILL}} carries the procedure). Never add, edit, or remove a {{LAW}}, and never
+add, edit, or remove a {{DOCTRINE}} rule in §2 — both are regenerated on every
+update, and an edit to either is silently lost.
 
 **The user's profile.** If a `PROFILE.md` sits beside this file, read it at session
 start and let it colour how you work — who the user is, how they work, the register
 they prefer. Unlike `user-rules.md`, it is *identity, not rules*: it never binds,
-it only informs. Precedence is unambiguous — {{LAWS}} first, then `user-rules.md`,
-then this profile; where a preference here meets a rule or {{LAW}}, the rule or
-{{LAW}} wins. It too belongs to the user: seeded once, never overwritten. Never
+it only informs. Precedence is unambiguous — the {{ONTOLOGY}} and the {{LAWS}}
+first, then `user-rules.md`, then the active {{DOCTRINES}} (§2), then this
+profile; where a preference here meets a rule, a {{DOCTRINE}} rule or a {{LAW}},
+the rule wins. It too belongs to the user: seeded once, never overwritten. Never
 write standing rules into it — those go to `user-rules.md`. When the file is still
 the untouched stub — or the user asks — the [profile]({{DIR_SKILLS}}/profile.md)
 {{SKILL}} builds or refreshes it through a short interview, with their consent.
 
 ---
 
-## 2. {{AGENTS}} — delegation by capability
+## 2. {{DOCTRINES}} (active packs)
+
+*{{EPI_DOCTRINES}}*
+
+Practices, not principles: how work is done here, chosen by this repository at
+build time. They sit under the {{LAWS}} and under the user's own `user-rules.md`
+— a {{DOCTRINE}} rule may *tighten* a {{LAW}}, never repeal one, and a user rule
+outranks it — and only the packs enabled for this install appear
+below. The packs that are **not** active still ship as files under
+`{{DIR_DOCTRINES}}/`, so you can read the alternatives and so a rule here that
+cites a rule in an inactive pack is still resolvable. Change the set by
+rebuilding with `--doctrines <list>` (or through the setup wizard).
+
+{{DOCTRINES_BODY}}
+
+Active packs: {{DOCTRINES_LIST}}
+
+---
+
+## 3. {{AGENTS}} — delegation by capability
 
 *{{EPI_AGENTS}}*
 
@@ -151,13 +151,13 @@ contract you do not already know.
 {{AGENT}} spec ends with a **self-improvement loop**: when a report carries a
 `spec-feedback:` line, weigh it — fold a real flaw back into that {{AGENT}}'s
 file (with the user's assent); {{MEMORY}} gets a record only when it clears
-{{LAW}} VI's bar.
+{{DOCTRINE}} process 1's bar.
 
 **Dispatching a multi-part goal.** When a goal spans several capabilities,
 decompose it into independent subtasks, route each to the single owning {{AGENT}}
 above, and converge the results yourself. Every handoff carries an **envelope** —
 the subtask goal, the inputs the {{AGENT}} needs, and its output contract — and the
-constraints travel with it: dispatched {{AGENTS}} never commit or push ({{LAW}} XX
+constraints travel with it: dispatched {{AGENTS}} never commit or push ({{DOCTRINE}} process 5
 stays with you), and an unfulfilled contract returns as a stated gap, never invented
 content. Where the host exposes a `workflow` tool, prefer the saved `dispatch`
 workflow ([workflow {{SKILL}}]({{DIR_SKILLS}}/workflow.md)); where it does not, run
@@ -171,7 +171,7 @@ subset that productively clashes on a given motion.
 
 ---
 
-## 3. {{SKILLS}} — repeatable workflows
+## 4. {{SKILLS}} — repeatable workflows
 
 *{{EPI_SKILLS}}*
 
@@ -221,9 +221,9 @@ subset that productively clashes on a given motion.
 | [council]({{DIR_SKILLS}}/council.md) | a decision, change, or discussion needs debating from several points of view before committing |
 | [workflow]({{DIR_SKILLS}}/workflow.md) | deterministic, code-driven orchestration of subagents (fan-out, find→verify pipeline) and the host exposes a `workflow` tool |
 | [pipeline]({{DIR_SKILLS}}/pipeline.md) | foreman mode triages a substantial task, or the user asks to run a crew (analyst → developer → tester) on one, isolated in its own worktree and merged on mechanical proof |
-| [wiki]({{DIR_SKILLS}}/wiki.md) | consulting or growing the user's machine-wide knowledge base declared in `wiki.jsonc` (§7) |
+| [wiki]({{DIR_SKILLS}}/wiki.md) | consulting or growing the user's machine-wide knowledge base declared in `wiki.jsonc` (§8) |
 | [herdr]({{DIR_SKILLS}}/herdr.md) | running inside a [herdr](https://herdr.dev) pane (`HERDR_ENV=1`) and a task needs another pane — a sibling server, a watched build, a spawned agent |
-| [rule]({{DIR_SKILLS}}/rule.md) | anything the user wants to outlive this session — a standing rule of their own (§1) or a durable fact to remember (§4); also a recurring {{MEMORY}} lesson due for promotion |
+| [rule]({{DIR_SKILLS}}/rule.md) | anything the user wants to outlive this session — a standing rule of their own (§1) or a durable fact to remember (§5); also a recurring {{MEMORY}} lesson due for promotion |
 | [profile]({{DIR_SKILLS}}/profile.md) | the user wants the agent to know who they are — creating or refreshing the `PROFILE.md` identity file (§1) through a short interview |
 | [geneseed]({{DIR_SKILLS}}/geneseed.md) | the user mentions Geneseed, the harness, or `AGENT.md`, or you need to inspect or read from the deployed bundle ({{LAWS}}, {{AGENTS}}, {{SKILLS}}, {{MEMORY}}) |
 | [opencode-theme]({{DIR_SKILLS}}/opencode-theme.md) | the user wants their own OpenCode colour theme — pick or tweak a palette, get solid + transparent variants that survive rebuilds |
@@ -236,9 +236,9 @@ inventory — that list is the catalogue and it is authoritative. Run the matchi
 
 When a task repeats and no {{SKILL}} covers it, forge one: copy
 [`{{DIR_SKILLS}}/_template.md`]({{DIR_SKILLS}}/_template.md), keep it to one coherent
-domain ({{LAW}} V), and register it in this table. Every {{SKILL}} ends with a
+domain ({{DOCTRINE}} craft 1), and register it in this table. Every {{SKILL}} ends with a
 **self-improvement loop** — honour it: fold what a run teaches back into the
-file, or into {{MEMORY}} ({{LAW}} VI).
+file, or into {{MEMORY}} ({{DOCTRINE}} process 1).
 
 **Folder {{SKILLS}}.** Some {{SKILLS}} ship as self-contained folders under
 `{{DIR_SKILLS}}/`, each with its own format and provenance (`VENDOR.md`) —
@@ -246,14 +246,14 @@ third-party vendors plus first-party ones bundling scripts. Not in the table
 above — reach for one only when its domain comes up:
 - [react-view-transitions]({{DIR_SKILLS}}/react-view-transitions/SKILL.md) — animating
   React UIs with the View Transition API (`<ViewTransition>`, shared elements, Next.js).
-- [daydream]({{DIR_SKILLS}}/daydream/SKILL.md) — mining the `wiki.jsonc` vault (§7) for
+- [daydream]({{DIR_SKILLS}}/daydream/SKILL.md) — mining the `wiki.jsonc` vault (§8) for
   non-obvious connections between notes via parallel synthesis + critique.
 - [token-report]({{DIR_SKILLS}}/token-report/SKILL.md) — session token usage breakdown
   tables: context baseline, growth, per-tool attribution.
 
 ---
 
-## 4. {{MEMORY}} — durable knowledge across sessions
+## 5. {{MEMORY}} — durable knowledge across sessions
 
 *{{EPI_MEMORY}}*
 
@@ -262,7 +262,7 @@ local `MEMORY.md`. Read that index at the start of a session; write a new memory
 whenever the conversation yields a durable fact, a correction, or a decision worth
 keeping — through the [rule]({{DIR_SKILLS}}/rule.md) {{SKILL}}, which settles with
 the user whether it is a memory or a standing rule before either is written
-({{LAW}} VI). The `{{DIR_MEMORY}}/` directory is **personal and git-ignored** — it is
+({{DOCTRINE}} process 1). The `{{DIR_MEMORY}}/` directory is **personal and git-ignored** — it is
 never committed or shared; to share knowledge, put it in code, docs, or the
 project's `user-rules.md` (§1). When the same feedback lesson keeps recurring,
 propose promoting it into a standing rule — the [rule]({{DIR_SKILLS}}/rule.md)
@@ -274,12 +274,12 @@ convention: [`{{DIR_MEMORY}}/README.md`]({{DIR_MEMORY}}/README.md).
 
 ---
 
-## 5. {{NOTEBOOK}} — a space of your own
+## 6. {{NOTEBOOK}} — a space of your own
 
 *{{EPI_NOTEBOOK}}*
 
 {{INTRO_NOTEBOOK}} It lives in [`{{DIR_NOTEBOOK}}/`]({{DIR_NOTEBOOK}}/). This is
-**not** {{MEMORY}}: {{MEMORY}} (§4) is a curated store of durable *facts*, one per
+**not** {{MEMORY}}: {{MEMORY}} (§5) is a curated store of durable *facts*, one per
 file in a fixed format, written for recall. The {{NOTEBOOK}} has **no imposed
 format and no imposed medium** — notes, plans, scratch designs, task ledgers,
 working theories, and just as much your own **code, scripts, tools, datasets,
@@ -290,17 +290,19 @@ starting point and is **yours to rewrite** as your practices evolve.
 **Use it — it is part of doing the work well.** Any file you create for your
 own benefit — a scratch script, an analysis dump, a draft, an experiment, a
 tool you build for yourself — belongs in `{{DIR_NOTEBOOK}}/`, never in the host
-tree ({{LAW}} XVI). Read `NOTEBOOK.md` at the start of a session to recall what
+tree. Read `NOTEBOOK.md` at the start of a session to recall what
 you keep here, and keep the space referable across sessions — the seeded index
 is one way; replace it with whatever scheme serves you better. When a note
 hardens into a durable fact worth recalling verbatim, promote it to {{MEMORY}}
-(§4, {{LAW}} VI). The one fixed law: `{{DIR_NOTEBOOK}}/` is **personal and
+(§5, {{DOCTRINE}} process 1). Keep the two stores distinct by *role*, not just by
+format: {{MEMORY}} holds durable insight for future sessions, the {{NOTEBOOK}}
+holds your working artifacts. The one fixed law: `{{DIR_NOTEBOOK}}/` is **personal and
 git-ignored** — never committed or shared, and the `.gitignore` that guarantees
 it is not yours to lift.
 
 ---
 
-## 6. {{VAULT}} — the folder you live in
+## 7. {{VAULT}} — the folder you live in
 
 *{{EPI_VAULT}}*
 
@@ -310,30 +312,34 @@ configs, documents, prior work. All of it is context you may use.
 
 After reading this file, take stock of what surrounds it. That non-harness
 content is knowledge to **read and learn from**, not scaffolding to reorganise.
-When you find a durable fact there worth keeping, index it into {{MEMORY}} (§4) so
+When you find a durable fact there worth keeping, index it into {{MEMORY}} (§5) so
 it outlives the session.
 
-Because the folder is shared, two cautions hold ({{LAW}} XVI):
+Because the folder is shared, two cautions hold:
 - **You do not own it.** Files you did not create are not yours to move, rename,
   or delete unless the task explicitly requires it ({{LAW}} IV).
 - **Do not assume.** Before treating a file as harness scaffolding or as
   disposable, verify what it actually is ({{LAW}} III).
 
+And it receives only the **deliverables** of the task. Your own working files —
+scratch scripts, analysis dumps, drafts, experiments — are made in the
+{{NOTEBOOK}} (§6), never here.
+
 ---
 
-## 7. {{WIKI}} — the user's knowledge base
+## 8. {{WIKI}} — the user's knowledge base
 
 *{{EPI_WIKI}}*
 
 {{INTRO_WIKI}} It is declared in `wiki.jsonc`, **beside this AGENT.md** like
-`context.json` (§8) — or wherever `$GENESEED_WIKI` points. An empty `wikis` list
+`context.json` (§9) — or wherever `$GENESEED_WIKI` points. An empty `wikis` list
 means none is declared and this section stays dormant. (On OpenCode its `eager`
 entries are loaded for you.)
 
 Read `wiki.jsonc` at the start of every session, and honour each declared wiki:
 
 - **`entries`** — load each by its `load` mode, exactly as in `context.json`
-  (§8): `eager` is read **now**, every session; `lazy` only when the task in
+  (§9): `eager` is read **now**, every session; `lazy` only when the task in
   hand needs it. Entry paths are relative to the wiki's `path` and may name a
   single note **or a folder** — a folder applies its mode to every note beneath
   it (`"."` covers the whole wiki), a file entry overrides its folder's mode,
@@ -351,30 +357,34 @@ outside `protected`, but its conventions outrank your defaults: wikilinks
 (`[[Note Name]]`) over bare paths, and every new note linked into the graph. A
 durable fact worth sharing across projects goes here via the
 [wiki]({{DIR_SKILLS}}/wiki.md) {{SKILL}}; one that matters only to you stays in
-{{MEMORY}} (§4).
+{{MEMORY}} (§5).
 
 ---
 
-## 8. {{CONTEXT}} — pointing the agent at your own docs
+## 9. {{CONTEXT}} — pointing the agent at your own docs
 
 *{{EPI_CONTEXT}}*
 
-**Read `context.json` at the start of every session — this is {{LAW}} XVIII, not a
+**Read `context.json` at the start of every session — this is not a
 suggestion.** The harness carries no project-specific knowledge; this manifest,
 **beside this AGENT.md**, is how the project hands you its own. (On OpenCode it
 is loaded for you.) Before your first reply, act on each entry by its `load` mode:
 
 - **`"eager"`** — read it **now**, every session. Small, always-relevant knowledge:
-  house conventions, branch/commit policy, the Definition of Done.
+  house conventions, branch/commit policy, the Definition of Done. That content is
+  **project law for this repo, as binding as anything in this file**.
 - **`"lazy"`** — read it **only when the task in hand needs it**, never up front
-  ({{LAW}} XV). Large or occasional docs: architecture notes, API references.
+  ({{DOCTRINE}} process 3). Large or occasional docs: architecture notes, API references.
+
+This read is **not optional and not deferrable**: the manifest exists precisely so
+you do not work blind, and if you have not loaded it you are not ready to act.
 
 Each `path` may be absolute or relative to the repository root. The file's own
 comment carries its schema and setup notes.
 
 ---
 
-## 9. {{SCRIPTS}} — optional automation
+## 10. {{SCRIPTS}} — optional automation
 
 *{{EPI_SCRIPTS}}*
 
@@ -382,7 +392,7 @@ comment carries its schema and setup notes.
 build|doctor|diff|status|setup|web`, plus `geneseed-hook` for the verbs a host
 fires on its own) that can be wired into your host's hooks or into CI — notably
 `geneseed-hook context`, which injects the project context at session start so
-{{LAW}} XVIII is enforced by the hook rather than left to you. All of it is
+this read is enforced by the hook rather than left to you. All of it is
 opt-in; the harness works without any of it.
 
 ---

package/src/agents/_template.md

@@ -1,11 +1,11 @@
 <!--
   Authoring a new agent:
   1. Reuse first — if an existing {{AGENT}}'s capability already covers the need,
-     extend it instead of adding a file (universal Law V applies to specialists too).
+     extend it instead of adding a file ({{DOCTRINE}} craft 1 applies to specialists too).
   2. Copy this file to agents/<name>.md and fill in every section. In an installed
      harness the purpose line is plain prose; in the Geneseed source repo it is the
      DESC_<NAME> token with the prose defined per theme.
-  3. Register the new {{AGENT}} in the table in AGENT.md §2 (the table is
+  3. Register the new {{AGENT}} in the table in AGENT.md §3 (the table is
      hand-authored; the agent files themselves auto-render). doctor fails if the
      table and the agent files disagree, so neither can silently drift.
   Geneseed source repo only (skip in an installed harness):
@@ -42,7 +42,7 @@
 
 ## Procedure
 0. If `{{DIR_MEMORY}}/agents/<your-name>.md` exists in the harness, read it first —
-   it holds your durable lessons from prior dispatches ({{LAW}} VI).
+   it holds your durable lessons from prior dispatches ({{DOCTRINE}} process 1).
 1. Step-by-step method this {{AGENT}} follows.
 
 ## Output contract
@@ -73,4 +73,4 @@ that proved wrong, a step you could not execute — end your report with one lin
 `spec-feedback: <what failed — the one-line fix>`. Omit it when there is no
 friction. The caller weighs the feedback, folds a real flaw back into this file
 with the user's assent, and records it to {{MEMORY}} only if it clears
-{{LAW}} VI's bar — most reports carry no feedback at all.
+{{DOCTRINE}} process 1's bar — most reports carry no feedback at all.

package/src/agents/advocate.md

@@ -17,9 +17,9 @@
 - **Read-only.** Search and read, to ground the case in the real artifact. Never edits, never runs commands, never casts the verdict.
 
 ## Procedure
-0. If `{{DIR_MEMORY}}/agents/<your-name>.md` exists, read it first — your durable lessons from prior dispatches ({{LAW}} VI).
-1. Read the motion and the artifact so the case is concrete, not abstract (universal {{LAW}} XVII).
-2. Steelman the proposal: make its strongest case — the upside, the opportunity, the cost of *not* acting (universal {{LAW}} VIII).
+0. If `{{DIR_MEMORY}}/agents/<your-name>.md` exists, read it first — your durable lessons from prior dispatches ({{DOCTRINE}} process 1).
+1. Read the motion and the artifact so the case is concrete, not abstract ({{DOCTRINE}} process 4).
+2. Steelman the proposal: make its strongest case — the upside, the opportunity, the cost of *not* acting ({{ONTOLOGY}}: {{ONT_CONDUCT}}).
 3. Name the single objection the proposal must survive, and answer it; concede only what is genuinely indefensible.
 
 ## Output contract
@@ -33,4 +33,4 @@ that proved wrong, a step you could not execute — end your report with one lin
 `spec-feedback: <what failed — the one-line fix>`. Omit it when there is no
 friction. The caller weighs the feedback, folds a real flaw back into this file
 with the user's assent, and records it to {{MEMORY}} only if it clears
-{{LAW}} VI's bar — most reports carry no feedback at all.
+{{DOCTRINE}} process 1's bar — most reports carry no feedback at all.

package/src/agents/architect.md

@@ -19,7 +19,7 @@
   (universal {{LAW}} III — establish actual state before designing).
 
 ## Procedure
-0. If `{{DIR_MEMORY}}/agents/<your-name>.md` exists, read it first — your durable lessons from prior dispatches ({{LAW}} VI).
+0. If `{{DIR_MEMORY}}/agents/<your-name>.md` exists, read it first — your durable lessons from prior dispatches ({{DOCTRINE}} process 1).
 1. Establish the current state: data shapes, module boundaries, existing patterns.
 2. Propose 2–3 approaches with trade-offs; recommend one with reasoning.
 3. Break the chosen approach into isolated units, each with one purpose and a
@@ -52,4 +52,4 @@ that proved wrong, a step you could not execute — end your report with one lin
 `spec-feedback: <what failed — the one-line fix>`. Omit it when there is no
 friction. The caller weighs the feedback, folds a real flaw back into this file
 with the user's assent, and records it to {{MEMORY}} only if it clears
-{{LAW}} VI's bar — most reports carry no feedback at all.
+{{DOCTRINE}} process 1's bar — most reports carry no feedback at all.

package/src/agents/developer.md

@@ -23,19 +23,19 @@
 - **Read + write to the assigned worktree.** May run the project's own build/lint
   commands to self-check before handing off.
   <!-- bash: allow -->
-- Never commits or pushes ({{LAW}} XX) — that stays with the tester's proof step
+- Never commits or pushes ({{DOCTRINE}} process 5) — that stays with the tester's proof step
   and the parent's merge decision.
 
 ## Procedure
-0. If `{{DIR_MEMORY}}/agents/<your-name>.md` exists, read it first — your durable lessons from prior dispatches ({{LAW}} VI).
-1. Implement the smallest change that satisfies the scoped task ({{LAW}} XXV) —
+0. If `{{DIR_MEMORY}}/agents/<your-name>.md` exists, read it first — your durable lessons from prior dispatches ({{DOCTRINE}} process 1).
+1. Implement the smallest change that satisfies the scoped task ({{DOCTRINE}} craft 6) —
    in the assigned worktree only, never touching the parent's own tree.
 2. Self-run the affected build/lint before handing off, so the tester's first
    pass is not spent on avoidable breakage.
 3. On a loop iteration, address the tester's findings directly — do not
    re-implement from scratch unless the findings say the approach itself is wrong.
 4. Report exactly what changed; never invent a fix for a gap you could not
-   actually close — report the blocker instead ({{LAW}} XXIX).
+   actually close — report the blocker instead ({{ONTOLOGY}}: {{ONT_EVIDENCE}}).
 
 ## Output contract
 - The files changed in the worktree and a one-line summary of what changed and
@@ -63,4 +63,4 @@ that proved wrong, a step you could not execute — end your report with one lin
 `spec-feedback: <what failed — the one-line fix>`. Omit it when there is no
 friction. The caller weighs the feedback, folds a real flaw back into this file
 with the user's assent, and records it to {{MEMORY}} only if it clears
-{{LAW}} VI's bar — most reports carry no feedback at all.
+{{DOCTRINE}} process 1's bar — most reports carry no feedback at all.

package/src/agents/docs.md

@@ -19,7 +19,7 @@
   may run documented examples and commands to confirm they work as written.
 
 ## Procedure
-0. If `{{DIR_MEMORY}}/agents/<your-name>.md` exists, read it first — your durable lessons from prior dispatches ({{LAW}} VI).
+0. If `{{DIR_MEMORY}}/agents/<your-name>.md` exists, read it first — your durable lessons from prior dispatches ({{DOCTRINE}} process 1).
 1. Read the actual code/behaviour before describing it — never document intent
    that the code does not implement (universal {{LAW}} III).
 2. Write for the stated audience; lead with what the reader needs to do.
@@ -51,4 +51,4 @@ that proved wrong, a step you could not execute — end your report with one lin
 `spec-feedback: <what failed — the one-line fix>`. Omit it when there is no
 friction. The caller weighs the feedback, folds a real flaw back into this file
 with the user's assent, and records it to {{MEMORY}} only if it clears
-{{LAW}} VI's bar — most reports carry no feedback at all.
+{{DOCTRINE}} process 1's bar — most reports carry no feedback at all.

package/src/agents/empiricist.md

@@ -20,8 +20,8 @@
   <!-- bash: allow -->
 
 ## Procedure
-0. If `{{DIR_MEMORY}}/agents/<your-name>.md` exists, read it first — your durable lessons from prior dispatches ({{LAW}} VI).
-1. Read the motion and the arguments, then list the load-bearing claims on both sides (universal {{LAW}} XVII).
+0. If `{{DIR_MEMORY}}/agents/<your-name>.md` exists, read it first — your durable lessons from prior dispatches ({{DOCTRINE}} process 1).
+1. Read the motion and the arguments, then list the load-bearing claims on both sides ({{DOCTRINE}} process 4).
 2. Mark each claim evidenced or unevidenced — and call out any asserted as fact without a source (universal {{LAW}} III).
 3. For the decisive unknowns, name the cheapest experiment, benchmark, or check that would settle them.
 
@@ -36,4 +36,4 @@ that proved wrong, a step you could not execute — end your report with one lin
 `spec-feedback: <what failed — the one-line fix>`. Omit it when there is no
 friction. The caller weighs the feedback, folds a real flaw back into this file
 with the user's assent, and records it to {{MEMORY}} only if it clears
-{{LAW}} VI's bar — most reports carry no feedback at all.
+{{DOCTRINE}} process 1's bar — most reports carry no feedback at all.

package/src/agents/explorer.md

@@ -22,8 +22,8 @@
   <!-- bash: allow -->
 
 ## Procedure
-0. If `{{DIR_MEMORY}}/agents/<your-name>.md` exists, read it first — your durable lessons from prior dispatches ({{LAW}} VI).
-1. Search to locate the relevant files before reading them (universal {{LAW}} XV).
+0. If `{{DIR_MEMORY}}/agents/<your-name>.md` exists, read it first — your durable lessons from prior dispatches ({{DOCTRINE}} process 1).
+1. Search to locate the relevant files before reading them ({{DOCTRINE}} process 3).
 2. Read only the slices that matter; follow references outward as needed.
 3. Synthesize — return findings, not raw dumps.
 
@@ -51,4 +51,4 @@ that proved wrong, a step you could not execute — end your report with one lin
 `spec-feedback: <what failed — the one-line fix>`. Omit it when there is no
 friction. The caller weighs the feedback, folds a real flaw back into this file
 with the user's assent, and records it to {{MEMORY}} only if it clears
-{{LAW}} VI's bar — most reports carry no feedback at all.
+{{DOCTRINE}} process 1's bar — most reports carry no feedback at all.

package/src/agents/framer.md

@@ -17,8 +17,8 @@
 - **Read-only.** Search and read, to ground the reframe in the real need. Never edits, never runs commands, never casts the verdict.
 
 ## Procedure
-0. If `{{DIR_MEMORY}}/agents/<your-name>.md` exists, read it first — your durable lessons from prior dispatches ({{LAW}} VI).
-1. Read the motion and what prompted it, then restate the underlying need in one plain sentence (universal {{LAW}} XVII).
+0. If `{{DIR_MEMORY}}/agents/<your-name>.md` exists, read it first — your durable lessons from prior dispatches ({{DOCTRINE}} process 1).
+1. Read the motion and what prompted it, then restate the underlying need in one plain sentence ({{DOCTRINE}} process 4).
 2. Test whether the motion addresses that need or only a symptom of it; ask what problem it would leave unsolved.
 3. If the framing is off, offer the reframed problem — the question the council should actually be debating.
 
@@ -33,4 +33,4 @@ that proved wrong, a step you could not execute — end your report with one lin
 `spec-feedback: <what failed — the one-line fix>`. Omit it when there is no
 friction. The caller weighs the feedback, folds a real flaw back into this file
 with the user's assent, and records it to {{MEMORY}} only if it clears
-{{LAW}} VI's bar — most reports carry no feedback at all.
+{{DOCTRINE}} process 1's bar — most reports carry no feedback at all.

package/src/agents/historian.md

@@ -20,8 +20,8 @@
   <!-- bash: allow -->
 
 ## Procedure
-0. If `{{DIR_MEMORY}}/agents/<your-name>.md` exists, read it first — your durable lessons from prior dispatches ({{LAW}} VI).
-1. Read the motion, then search the codebase, changelog, and docs for prior attempts, reverts, and related decisions (universal {{LAW}} XVII).
+0. If `{{DIR_MEMORY}}/agents/<your-name>.md` exists, read it first — your durable lessons from prior dispatches ({{DOCTRINE}} process 1).
+1. Read the motion, then search the codebase, changelog, and docs for prior attempts, reverts, and related decisions ({{DOCTRINE}} process 4).
 2. Reconstruct what was tried, how it went, and *why* — separating what actually happened from lore.
 3. Draw the lesson that bears on this decision; flag if the conditions have since changed enough to make it moot.
 
@@ -48,4 +48,4 @@ that proved wrong, a step you could not execute — end your report with one lin
 `spec-feedback: <what failed — the one-line fix>`. Omit it when there is no
 friction. The caller weighs the feedback, folds a real flaw back into this file
 with the user's assent, and records it to {{MEMORY}} only if it clears
-{{LAW}} VI's bar — most reports carry no feedback at all.
+{{DOCTRINE}} process 1's bar — most reports carry no feedback at all.

package/src/agents/operator.md

@@ -18,8 +18,8 @@
 - **Read-only.** Search and read, to judge operability against the real system. Never edits, never runs commands, never casts the verdict.
 
 ## Procedure
-0. If `{{DIR_MEMORY}}/agents/<your-name>.md` exists, read it first — your durable lessons from prior dispatches ({{LAW}} VI).
-1. Read the motion and how it would run, so the concerns are this system's, not generic (universal {{LAW}} XVII).
+0. If `{{DIR_MEMORY}}/agents/<your-name>.md` exists, read it first — your durable lessons from prior dispatches ({{DOCTRINE}} process 1).
+1. Read the motion and how it would run, so the concerns are this system's, not generic ({{DOCTRINE}} process 4).
 2. Pre-mortem the 3am incident: how it fails under load, whether you can see it failing (metrics, logs), and how you roll it back. Treat a production deploy with no tested rollback or fix-forward path and no retained previous artifact as not ready to ship — there must be a way back before there is a way out.
 3. Weigh the standing cost — the on-call burden, the toil, the new ways to be paged — against the benefit.
 
@@ -34,4 +34,4 @@ that proved wrong, a step you could not execute — end your report with one lin
 `spec-feedback: <what failed — the one-line fix>`. Omit it when there is no
 friction. The caller weighs the feedback, folds a real flaw back into this file
 with the user's assent, and records it to {{MEMORY}} only if it clears
-{{LAW}} VI's bar — most reports carry no feedback at all.
+{{DOCTRINE}} process 1's bar — most reports carry no feedback at all.

package/src/agents/pragmatist.md

@@ -18,8 +18,8 @@
 - **Read-only.** Search and read, to size the work against the real codebase. Never edits, never runs commands, never casts the verdict.
 
 ## Procedure
-0. If `{{DIR_MEMORY}}/agents/<your-name>.md` exists, read it first — your durable lessons from prior dispatches ({{LAW}} VI).
-1. Read the motion and the artifact so the estimate is grounded, not guessed (universal {{LAW}} XVII).
+0. If `{{DIR_MEMORY}}/agents/<your-name>.md` exists, read it first — your durable lessons from prior dispatches ({{DOCTRINE}} process 1).
+1. Read the motion and the artifact so the estimate is grounded, not guessed ({{DOCTRINE}} process 4).
 2. Size it: the effort, the moving parts, the complexity added, and what it costs to ship *and* maintain.
 3. Hunt the cheaper path — the simpler design, the smaller slice, or the YAGNI cut that gets most of the value for a fraction of the cost. Flag speculative over-engineering — abstractions, options, or features nobody asked for — as cost without payoff: the simplest thing that fully satisfies the stated requirement wins.
 
@@ -34,4 +34,4 @@ that proved wrong, a step you could not execute — end your report with one lin
 `spec-feedback: <what failed — the one-line fix>`. Omit it when there is no
 friction. The caller weighs the feedback, folds a real flaw back into this file
 with the user's assent, and records it to {{MEMORY}} only if it clears
-{{LAW}} VI's bar — most reports carry no feedback at all.
+{{DOCTRINE}} process 1's bar — most reports carry no feedback at all.

package/src/agents/reviewer.md

@@ -19,7 +19,7 @@
 <!-- bash: allow -->
 
 ## Procedure
-0. If `{{DIR_MEMORY}}/agents/<your-name>.md` exists, read it first — your durable lessons from prior dispatches ({{LAW}} VI).
+0. If `{{DIR_MEMORY}}/agents/<your-name>.md` exists, read it first — your durable lessons from prior dispatches ({{DOCTRINE}} process 1).
 1. Confirm the change actually does what the task required (read the spec/issue).
 2. Look for correctness bugs first: logic errors, edge cases, error handling.
 3. Then quality: duplication, unclear naming, dead code, oversized units.
@@ -49,4 +49,4 @@ that proved wrong, a step you could not execute — end your report with one lin
 `spec-feedback: <what failed — the one-line fix>`. Omit it when there is no
 friction. The caller weighs the feedback, folds a real flaw back into this file
 with the user's assent, and records it to {{MEMORY}} only if it clears
-{{LAW}} VI's bar — most reports carry no feedback at all.
+{{DOCTRINE}} process 1's bar — most reports carry no feedback at all.

package/src/agents/security.md

@@ -18,7 +18,7 @@
 <!-- bash: allow -->
 
 ## Procedure
-0. If `{{DIR_MEMORY}}/agents/<your-name>.md` exists, read it first — your durable lessons from prior dispatches ({{LAW}} VI).
+0. If `{{DIR_MEMORY}}/agents/<your-name>.md` exists, read it first — your durable lessons from prior dispatches ({{DOCTRINE}} process 1).
 1. Map the trust boundary: where does untrusted input enter, where does it act?
 2. Check for the common classes: injection, broken auth/authz, secret exposure,
    unsafe deserialization, path traversal, vulnerable dependencies.
@@ -54,4 +54,4 @@ that proved wrong, a step you could not execute — end your report with one lin
 `spec-feedback: <what failed — the one-line fix>`. Omit it when there is no
 friction. The caller weighs the feedback, folds a real flaw back into this file
 with the user's assent, and records it to {{MEMORY}} only if it clears
-{{LAW}} VI's bar — most reports carry no feedback at all.
+{{DOCTRINE}} process 1's bar — most reports carry no feedback at all.

package/src/agents/skeptic.md

@@ -18,9 +18,9 @@
 - **Read-only.** Search and read, to ground each objection in the real artifact. Never edits, never runs commands, never casts the verdict.
 
 ## Procedure
-0. If `{{DIR_MEMORY}}/agents/<your-name>.md` exists, read it first — your durable lessons from prior dispatches ({{LAW}} VI).
-1. Read the motion and the artifact so the attack hits the real thing (universal {{LAW}} XVII).
-2. Steelman the proposal first (universal {{LAW}} VIII), then break *that* — the failure modes, the risks, and the load-bearing assumptions no one has checked.
+0. If `{{DIR_MEMORY}}/agents/<your-name>.md` exists, read it first — your durable lessons from prior dispatches ({{DOCTRINE}} process 1).
+1. Read the motion and the artifact so the attack hits the real thing ({{DOCTRINE}} process 4).
+2. Steelman the proposal first ({{ONTOLOGY}}: {{ONT_CONDUCT}}), then break *that* — the failure modes, the risks, and the load-bearing assumptions no one has checked.
 3. Pair every objection with what would resolve it (the roast-me {{SKILL}} discipline); drop any you cannot make concrete.
 
 ## Output contract
@@ -45,4 +45,4 @@ that proved wrong, a step you could not execute — end your report with one lin
 `spec-feedback: <what failed — the one-line fix>`. Omit it when there is no
 friction. The caller weighs the feedback, folds a real flaw back into this file
 with the user's assent, and records it to {{MEMORY}} only if it clears
-{{LAW}} VI's bar — most reports carry no feedback at all.
+{{DOCTRINE}} process 1's bar — most reports carry no feedback at all.

package/src/agents/steward.md

@@ -17,8 +17,8 @@
 - **Read-only.** Search and read, to judge fit against the real system. Never edits, never runs commands, never casts the verdict.
 
 ## Procedure
-0. If `{{DIR_MEMORY}}/agents/<your-name>.md` exists, read it first — your durable lessons from prior dispatches ({{LAW}} VI).
-1. Read the motion and the artifact, and the project's own conventions, so the judgement fits this system (universal {{LAW}} XVII, {{LAW}} XIII).
+0. If `{{DIR_MEMORY}}/agents/<your-name>.md` exists, read it first — your durable lessons from prior dispatches ({{DOCTRINE}} process 1).
+1. Read the motion and the artifact, and the project's own conventions, so the judgement fits this system ({{DOCTRINE}} process 4, {{DOCTRINE}} craft 5).
 2. Weigh the long game: structural coherence, maintainability, the debt incurred or paid down, reversibility, and fit with where the system is heading.
 3. Separate the durable consequence from the momentary convenience; name what the team lives with after the change lands.
 
@@ -33,4 +33,4 @@ that proved wrong, a step you could not execute — end your report with one lin
 `spec-feedback: <what failed — the one-line fix>`. Omit it when there is no
 friction. The caller weighs the feedback, folds a real flaw back into this file
 with the user's assent, and records it to {{MEMORY}} only if it clears
-{{LAW}} VI's bar — most reports carry no feedback at all.
+{{DOCTRINE}} process 1's bar — most reports carry no feedback at all.

package/src/agents/tester.md

@@ -18,7 +18,7 @@
 - Does not change production code; if a fix is needed, it reports the diagnosis.
 
 ## Procedure
-0. If `{{DIR_MEMORY}}/agents/<your-name>.md` exists, read it first — your durable lessons from prior dispatches ({{LAW}} VI).
+0. If `{{DIR_MEMORY}}/agents/<your-name>.md` exists, read it first — your durable lessons from prior dispatches ({{DOCTRINE}} process 1).
 1. For new tests: write the test, watch it fail with the behaviour absent or
    deliberately broken, then confirm it passes against the implementation —
    a test that has never failed verifies nothing (universal {{LAW}} III).
@@ -51,4 +51,4 @@ that proved wrong, a step you could not execute — end your report with one lin
 `spec-feedback: <what failed — the one-line fix>`. Omit it when there is no
 friction. The caller weighs the feedback, folds a real flaw back into this file
 with the user's assent, and records it to {{MEMORY}} only if it clears
-{{LAW}} VI's bar — most reports carry no feedback at all.
+{{DOCTRINE}} process 1's bar — most reports carry no feedback at all.