@dreamforgestudiollc/emet 0.0.0-stage → 0.2.4

package/src/version.js

@@ -0,0 +1,2 @@
+/** The server's version, in one place. tests/version.test.js keeps it equal to package.json. */
+export const EMET_VERSION = '0.2.4';

package/templates/BOARD.md

@@ -0,0 +1,72 @@
+# TEMPLATE — BOARD
+
+**Template control:** id `templates/BOARD.md` · revision: the store's version governs · status: IN FORCE · approved: user · 2026-09-11 · a decision record · owner: EMET (base) · built to `templates/STANDARD.md` · decision record: the owner's
+**Fills:** `STATE.md` — the structured open board. **Replaced in full at every session close; never appended.** The prior revision is archived automatically.
+**Failure it prevents:** a position document that grew by appended addenda until superseded lines sat above current ones; open items that left the record with no one deciding they should (the reference install lost two job-application actions this way in September 2026); a startup that restated this board's counts instead of naming its items, and a dated section migrated rather than rebuilt that missed three calendar items on its first live revision (reference install, 2026-09-10).
+**Completion rules:** `templates/STANDARD.md` §5, unmodified.
+
+---
+
+## HOW TO FILL — rules specific to this template
+
+1. **Every row has a stable id** (`B-001`, `B-002` …) assigned once and never reused. Ids are how the next revision, the handoff, and the validator refer to a row - and nothing else: **the id is the LAST column of every table and is never used to name an item to the user.** An item is named in plain words; the id is the handle the record keeps. *Prevents:* a startup list delivered as codes that mean nothing to the person reading it (reference install, 2026-09-15: *"it just looks like a bunch of progressing numbers with a letter prefix"*). The validator finds the id column by its header, so its position is the template's choice.
+2. **Rows change status, not membership.** An open row is copied into the next revision unchanged unless something about it changed.
+3. **A row leaves the open sections only through §4 CLOSED THIS REVISION**, with a disposition and evidence. It appears there once; the following revision may drop it, because the archived revision holds it.
+4. **The counts in §0 are derived from the rows.** A count that does not match the rows is a nonconformance.
+5. **A dated row whose date has passed without a recorded outcome moves to §3 as `OPEN`, next action "confirm outcome with the user." It is never closed as `DONE` without evidence.** *Prevents:* a passed date closed on an assumed outcome — the reassuring confabulation (reference install: support-structure confabulation; live instance 2026-09-11, an episode publish date resting on a shoot no one had recorded).
+
+---
+
+## §0 RECORD CONTROL AND COUNTS
+- Template: `templates/BOARD.md` rev __ · Board revision: v__ · Supersedes: v__
+- Session id: __ · Source tag: __ · Written (local): __
+- Scope of the session that wrote this revision: __
+
+| Half-state | Dated ≤14 days | Open | Waiting | Parked | Closed this revision | Seed triggers met | Nonconformance markers open |
+|---|---|---|---|---|---|---|---|
+| __ | __ | __ | __ | __ | __ | __ | __ |
+
+**At startup the receiving session NAMES the items first** — in the place `CHARTER.md` §6 sets for them (after EMET's line and the user's identity phrase; the charter holds the full order) — every §1 row, every §2 row within seven days, every §3 `OPEN` row the user owns with its next action, and the handoff's *left undecided* lines; **then, under its own heading, every §3 `PARKED` row, one line each with its *resumes when* — named, never pressed** (charter §3 commitment 8, changed 2026-09-23: parked rows were excluded until then, and for a neurodivergent user excluded is forgotten) — **then restates these counts as the check. A count never replaces the names:** for a user with time blindness or object impermanence, an item not named at startup does not exist (charter §3, commitment 8).
+
+## §1 HALF-STATE — highest priority
+Anything left partly changed that becomes riskier if the next session does not know about it: a configuration edited but untested, a change shipped but unverified, a restart pending, a file partly written.
+
+| What | State it was left in | Next action | Contingency — if X, do Y; do not do Z | How to undo | Id |
+|---|---|---|---|---|---|
+
+Or: *"None — checked against: __."*
+
+## §2 DATED — next 14 days, and hard dates beyond
+| Date | Item | Owner | Id |
+|---|---|---|---|
+
+Hard dates beyond 14 days: __ · Or: *"None — checked against: __."*
+
+**Rebuilt at every close from the user's calendar and any active schedule — never copied forward from the prior revision.** Name the sources checked: *"Checked against: calendar __ to __ · schedule __."* A source that could not be read is written `NOT CHECKED — <reason>`.
+
+## §3 OPEN BOARD
+| Item | Owner (user / assistant / external) | Status | Next action | Opened | Last changed | Id |
+|---|---|---|---|---|---|---|
+
+**Status is one of:** `OPEN` · `WAITING` (on someone external — name them) · `PARKED` (user's decision — not raised as work and nothing asked of it, but named in the startup list's parked section; record the date, the user's words, and **resumes when:** the condition that brings it back, or "user raises it").
+
+## §4 CLOSED THIS REVISION
+| Item | Disposition | Evidence | Id |
+|---|---|---|---|
+
+**Disposition is one of:** `DONE` · `DROPPED BY USER` · `MOVED TO SEED <id>` · `SUPERSEDED BY <row id>`. **Evidence** is a record id, document revision, or the user's words with the date.
+Or: *"None closed this revision."*
+
+## §5 SEEDS
+- Last full scan: __ (date, interface) · or `NOT SCANNED THIS CLOSE — <reason>`
+- Triggers met: seed · trigger · surfaced to the user (Y/N) — or *"None met, per the scan above."*
+- Dated triggers within 14 days: seed · date — or *"None."*
+
+## §6 STANDING GUARDS
+| Guard | Source (decision or entry) | Added |
+|---|---|---|
+
+Retired this revision: guard · reason — or *"None retired."*
+
+## §7 SYSTEM STATE
+Versions, deployments, record counts, and anything a successor must know to trust the environment. Each line with how it was verified and when.

package/templates/BOTHANDOFF.md

@@ -0,0 +1,57 @@
+# TEMPLATE — BOT HANDOFF
+
+**Template control:** id `templates/BOTHANDOFF.md` · revision: the store's version governs · status: DRAFT, not in force · approved: pending — the user asked for it 2026-10-01; IN FORCE only once the user approves this text and the decision record is filed · owner: EMET (base) · built to `templates/STANDARD.md` · supersedes: none
+**Fills:** `bots/<source tag>/HANDOFF.md` — one bot's own session narrative, written last at each of that bot's closes. Listed in `EMET_RECORD_DOCS`, so it is a record: revision 1 is written plain, every later revision is written whole with `supersedes` set to the revision in force. The hub's `HANDOFF.md` is never filled from this template, and a bot never writes `HANDOFF.md` or `STATE.md` (the server refuses it, `docs/BOTS.md` §5).
+**Failure it prevents:** a bot that can reach a complete close only by writing a new revision of the user's own `HANDOFF.md` and revising the user's board, so the user's next session opens on the bot's narrative (found 2026-10-01); scheduled bot runs citing sessions that were never opened, leaving permanent holes in the record (`emet_gaps` pointer disagreements, incident records); and a bot handoff checked against the hub's template, which demands a board the bot does not keep, so every bot close would add a nonconformance marker to the backlog (found on review of a live check, 2026-10-01).
+**Completion rules:** `templates/STANDARD.md` §5, unmodified.
+
+---
+
+## HOW TO FILL — rules specific to this template
+
+1. **This is the bot's record, not the user's.** It holds what this bot did in this session. Anything the user must see or decide goes to the hub (§3), and the hub carries it into the user's own records. Nothing here restates the user's board.
+2. **Write this last, in one write, after the final transcript append.** The session loop is `docs/BOTS.md` §6: read the startup (`emet_initialize {}` and every page it names; `{"page": "all"}` only on a host known to read long results whole), open with its `load_id`, append, save the session record with `session_id`, append again, then this handoff, then `emet_session_close`. §5 cites evidence that already exists.
+3. **Every statement is scoped to this session and this bot.** A claim about the whole system belongs to the hub, not here.
+4. **Corrections supersede.** A wrong statement in an earlier revision is corrected by the next revision (and named in §4), never by rewriting the earlier one.
+
+---
+
+## §0 RECORD CONTROL
+- Template: `templates/BOTHANDOFF.md` rev __ · Handoff revision: v__ · Supersedes: v__ (or "none — first revision")
+- Session id: __ · Source tag: __ · Bot: __ (roster row in `bots/ROSTER.md`)
+- Host / interface: __ · Machine: __ · Written (local): __
+- **Scope of this session, one line:** __
+
+## §1 START HERE
+- **The bot's next first action:** one concrete action — or *"Wait for the hub's next brief."*
+- **Left open for the hub:** questions, drafts or findings sent up and not yet answered, one line each — or *"None — checked against this session's messages to the hub."*
+- **Why this session stopped:** __ (finished · hub ended it · interrupted · out of room)
+
+## §2 DONE THIS SESSION
+| What | Evidence (commit, document revision, record id, receipt) |
+|---|---|
+
+Or: *"Nothing completed this session."*
+
+## §3 HANDED TO THE HUB
+| Item (finding, question, draft, verdict) | Sent (local time) | Hub's reply or decision relayed, with the user's words where given |
+|---|---|---|
+
+Or: *"Nothing handed up this session."* The bot records the user's decisions only as relayed by the hub. The bot's own recommendations are not decisions.
+
+## §4 ERRORS AND CORRECTIONS THIS SESSION
+| Error (including any statement in an earlier revision this one corrects) | Caught by | Correction or guard |
+|---|---|---|
+
+Or: *"None identified this session."*
+
+## §5 CLOSE VERIFICATION
+| Artifact | Done | Evidence |
+|---|---|---|
+| Working documents this session changed | Y / N-A (reason) | document + revision, or `working_docs: []` |
+| Session record in memory, written with `session_id` | Y / N | episodic id + verified receipt |
+| Verbatim transcript, including the append after the save | Y / N | session id + parts + highest exchange |
+| Main records untouched | Y / N (what changed, and the error row in §4) | `HANDOFF.md` and `STATE.md` revisions, before and after |
+| This handoff | Y | this revision — written last, one write, `supersedes` named after revision 1 |
+
+Rows are in close order (`docs/BOTS.md` §6).

package/templates/CHARACTER.md

@@ -0,0 +1,30 @@
+# TEMPLATE — CHARACTER
+
+**Template control:** id `templates/CHARACTER.md` · revision: the store's version governs · status: IN FORCE · approved: user · 2026-09-26 · a decision record · owner: EMET (base) · built to `templates/STANDARD.md` · supersedes: none
+**Fills:** `bootstrap/CHARACTER.md` (also accepted: `bootstrap/SOUL.md`, `bootstrap/PERSONALITY.md`) — how the assistant speaks and engages. Authoritative on voice for the whole session. Modifiers on the floor; never a replacement for it.
+**Failure it prevents:** a store that boots flattened because identity loaded and character did not, or a personality document with no standing sections so later sessions cannot find tone, limits, or what the assistant will not do (character payload work 2026-09-05; user 2026-09-26: structure ships, personal voice does not).
+**Completion rules:** `templates/STANDARD.md` §5, unmodified.
+
+---
+
+## HOW TO FILL — rules specific to this template
+
+1. **Voice, pace, length, and what the assistant does not do live here.** Identity holds the name; the floor holds what is owed regardless of voice.
+2. **The floor cannot be edited from this document.** A line that weakens a floor protection is a nonconformance.
+3. **Cultivate it.** The interview writes a first version; later revisions are how the voice is learned, not a one-time config.
+
+---
+
+## §0 RECORD CONTROL
+- Template: `templates/CHARACTER.md` rev __ · Record revision: the store's version governs
+- Session id: __ · Source tag: __ · Written (local): __
+- Alternate ids accepted: `bootstrap/SOUL.md` · `bootstrap/PERSONALITY.md`
+
+## §1 VOICE
+Tone, pace, length. How the assistant sounds when nothing else is specified.
+
+## §2 ENGAGEMENT
+What it does in conversation: when it asks, when it acts, when it waits.
+
+## §3 LIMITS
+What it does not do. One list. The floor still applies above this list.

package/templates/HANDOFF.md

@@ -0,0 +1,63 @@
+# TEMPLATE — HANDOFF
+
+**Template control:** id `templates/HANDOFF.md` · revision: the store's version governs · status: IN FORCE · approved: user · 2026-09-11 · a decision record · owner: EMET (base) · built to `templates/STANDARD.md` · decision record: the owner's
+**Fills:** `HANDOFF.md` — the session narrative, written at every close. Replaced at each close; the prior revision is archived automatically.
+**Failure it prevents:** a handoff's "nothing pending", true for one session, relayed at the next startup as true for the whole board (reference install, September 2026); a handoff written from memory rather than from the documents, carrying stale priorities (reference install, April 2026); a handoff whose first action was "open by asking the user", so the next startup put nothing in the user's sight (reference install, 2026-09-10).
+**Completion rules:** `templates/STANDARD.md` §5, unmodified.
+
+---
+
+## HOW TO FILL — rules specific to this template
+
+1. **This document holds what happened. The board holds where things stand.** Nothing that belongs on the board is restated here — refer to board rows by id.
+2. **Write this last, in one write. The close order is `CHARTER.md` §6 and is stated only there.** When this is written the board, the session record and the transcript already exist, so §6 cites evidence rather than promising it. §2 is the difference between the board's previous revision and its new one. *Prevents:* a handoff that attests to saves not yet made and then needs a patch that inflates its revision (reference install, 2026-09-10).
+3. **Every statement in §3–§5 is scoped to this session.** A claim about the whole board belongs on the board, not here.
+
+---
+
+## §0 RECORD CONTROL
+- Template: `templates/HANDOFF.md` rev __ · Handoff revision: v__ · Supersedes: v__
+- Session id: __ · Source tag: __ · Interface / machine: __ · Written (local): __
+- Board revision written with this handoff: v__
+- **Scope of this session, one line:** __
+
+## §1 START HERE
+- **Half-state rows on the board:** ids, or *"None — per board v__ §1."*
+- **The next session's first action:** one concrete action — or *"Name the startup list (board §0), then ask the user."* **Never "open by asking" alone:** a handoff does not send the next session into a question with nothing in the user's sight.
+- **Left undecided this session:** drafts, proposals or questions put to the user and not yet answered, one line each — or *"None."* The next session names these in its startup list.
+- **Why this session stopped:** __ (finished · user ended it · interrupted · out of room)
+
+## §2 BOARD CHANGES THIS SESSION
+- Added: ids · or *"None."*
+- Changed: id · what changed · or *"None."*
+- Closed: ids (dispositions are on the board, §4) · or *"None."*
+
+## §3 DONE THIS SESSION
+| What | Evidence (commit, document revision, record id, receipt) |
+|---|---|
+
+Or: *"Nothing completed this session."*
+
+## §4 DECISIONS THIS SESSION
+| Decision | User's words, verbatim | Recorded as |
+|---|---|---|
+
+Or: *"No decisions this session."* Only decisions the user made. The assistant's recommendations are not decisions until the user says so.
+
+## §5 ERRORS THIS SESSION
+| Error | Caught by | Correction or guard |
+|---|---|---|
+
+Or: *"None identified this session."*
+
+## §6 CLOSE VERIFICATION
+| Artifact | Done | Evidence |
+|---|---|---|
+| Working documents for anything this session changed | Y / N / N-A (reason) | document + revision |
+| Session record in memory | Y / N | record id + verified receipt |
+| Board | Y | revision |
+| Seed scan (board §5) | Y / NOT COMPLETED (reason) | date |
+| Verbatim transcript | Y / N | session id + read-back count |
+| This handoff | Y | this revision — written last, one write |
+
+Rows are in close order (`CHARTER.md` §6).

package/templates/IDENTITY.md

@@ -0,0 +1,29 @@
+# TEMPLATE — IDENTITY
+
+**Template control:** id `templates/IDENTITY.md` · revision: the store's version governs · status: IN FORCE · approved: user · 2026-09-26 · a decision record · owner: EMET (base) · built to `templates/STANDARD.md` · supersedes: none
+**Fills:** `bootstrap/IDENTITY.md` — who the assistant is. Written at the first-run interview from the user's answers. The user's name for the assistant is the SHEM; this document holds it.
+**Failure it prevents:** a first-run store with no standing form for identity, so each install invents a different shape and the next session cannot find the name or the verification phrase (held on the register 2026-09-11: bootstrap structure "not yet designed"; user 2026-09-26: the structure ships, the personal data does not).
+**Completion rules:** `templates/STANDARD.md` §5, unmodified.
+
+---
+
+## HOW TO FILL — rules specific to this template
+
+1. **Written from the interview, not copied from another install.** Name, phrase and attributes are this user's.
+2. **The verification phrase, if the user set one, is stored verbatim and never paraphrased at session start.**
+3. **Generic language in the template; filled language in the record.** This file says "assistant" and "user".
+
+---
+
+## §0 RECORD CONTROL
+- Template: `templates/IDENTITY.md` rev __ · Record revision: the store's version governs
+- Session id: __ · Source tag: __ · Written (local): __
+
+## §1 NAME
+The assistant's name, and any expanded title the user gave.
+
+## §2 VERIFICATION PHRASE
+The exact words the user wants spoken at session start after EMET's line — or *"None set."*
+
+## §3 STANDING DESCRIPTION
+Who this assistant is, in the user's words or the interview rendering of them. Not how it speaks — that belongs in the character document.

package/templates/INDEX.md

@@ -0,0 +1,82 @@
+# EMET CONTROLLED DOCUMENT LIBRARY — REGISTER
+
+**Status:** **ADOPTED by the user 2026-09-11** (*"Yes I do"*; a decision record). **IN FORCE with the repository commit**, because the shipped copy governs (`templates/STANDARD.md` §9a L1; `CHARTER.md` §9). Revision: the store's version governs. Decision records (kept in the owner's store): scope, latitude, validation not optional (mark for audit and review); review of 2026-09-11: validation v1 and shipping, locks, close order, charter lock, seed statuses and triggers.
+**Written:** 2026-09-10. **Brought current** 2026-09-11, session `2026-09-11_morning-mobile-init`, source `mobile`, after the user's full review of the set. **This revision also removes install-specific names** — the reference install's orchestrator, private documents, named employers, machine paths and seed names — under the scope rule that shipped forms are generic. The reference install's own records keep them.
+
+---
+
+## RULES FOR THIS LIBRARY
+
+1. **A template earns its place by naming the recorded failure it prevents.** No named failure, no template. (Over-engineering is an acceptance criterion.)
+2. **State a rule once.** Rules already held in server code (the floor, the layer charter, the write-path door) are pointed to, never copied into a document.
+3. **Templates are controlled documents; filled documents are records.** A template changes by revision (versioned, prior copy archived, never deleted). A record is corrected by a later record, never by rewriting history.
+4. **No implied conformity** (a decision record). This library puts document control into practice; it does not claim certification against any standard.
+5. **Revision numbers are the store's.** A control line says "the store's version governs" rather than carrying its own number — a hand-kept number drifts (it did: one template's line said v1 at store v6).
+
+---
+
+## DOCUMENT HIERARCHY — four tiers
+
+| Tier | Role | Holds |
+|---|---|---|
+| **1 — Charter** | What EMET is, what it is for, how it is structured, how information flows, how documents are controlled | `CHARTER.md` — DRAFT; locked like the base templates: ships with the release, a store copy is not authoritative, and it is present before any first-run interview |
+| **2 — Procedures** | How a session runs, start to close | The floor, layer charter, startup instructions and close protocol — in server code, pointed to. The close order is stated once, in `CHARTER.md` §6. An install may add its own orchestrator; it points here and restates nothing |
+| **3 — Work instructions and reference** | How to do a specific thing | `procedures/*` (PROCEDURE template) · an install's own reference and debug documents |
+| **4 — Forms and records** | Templates (forms) and the documents filled from them (records) | `templates/*` → `HANDOFF.md`, `STATE.md`, `threads/*`, `seeds/*`, `staging/*`, `procedures/*` · layer entries and transcripts (structure enforced by code) |
+
+---
+
+## REGISTER
+
+Every document listed under **Fills** is validated against its template by its id (`templates/STANDARD.md` §9 map); leaving out the control block does not exempt it (§9a L4).
+
+| Template | Fills | Failure it prevents (recorded) | Status |
+|---|---|---|---|
+| `templates/STANDARD.md` | Governs every template | Anything added beyond the base built without a common control; a validator that an install could configure, remap or edit into weakness | DRAFT — reviewed 2026-09-11. Validation §9, locks L1–L6 §9a |
+| `templates/HANDOFF.md` | `HANDOFF.md` | An unscoped "nothing pending" relayed as board-wide; items dropped from the chain with no decision; stale priorities from a handoff written from memory; a handoff whose first action was "open by asking"; a handoff attesting to saves not yet made | DRAFT — reviewed 2026-09-11 (written last, in one write). In trial use since 2026-09-10 |
+| `templates/BOARD.md` | `STATE.md` | Stacked addenda with superseded lines above current ones; two open actions dropped with no disposition; counts restated instead of items named; a dated section migrated instead of rebuilt, missing three calendar items; a passed date closed on an assumed outcome | DRAFT — reviewed 2026-09-11 (rule 5). In trial use since 2026-09-10 |
+| `templates/SEED.md` | `seeds/*` | A met trigger unsurfaced for weeks; triggers naming an event nobody scheduled; executed seeds still read as live; a paused seed indistinguishable from one that never fired | DRAFT — reviewed 2026-09-11. Triggers `DATE` · `ROW` · `SIGNAL` · `TOPIC`; statuses `DORMANT` · `MET` · `SHELVED` · `ACTED ON` |
+| `templates/THREAD.md` | `threads/*` | Threads grown past 140 KB with the current state buried under history; a priority list still telling the user to submit an application already submitted | DRAFT — reviewed 2026-09-11. §1 replaced, not appended; 64 KB log split (a chosen limit, not measured) |
+| `templates/STAGING.md` | `staging/*` | An assistant-authored proposal read as a decision; drafts with no visible status; a staging document escaping validation by omission | DRAFT — reviewed 2026-09-11. Status line says who decided; `IN USE` for documents the user works from |
+| `templates/PROCEDURE.md` | `procedures/*` | Recorded paths and commands going stale unverified — an interpreter path that no longer existed; a deploy command naming the project instead of the service | DRAFT — reviewed 2026-09-11. Every step dated and machine-named |
+| `templates/IDENTITY.md` | `bootstrap/IDENTITY.md` | No standing form for the assistant's name and phrase; each install invented a different shape | IN FORCE 2026-09-26 · a decision record |
+| `templates/CHARACTER.md` | `bootstrap/CHARACTER.md` (also SOUL, PERSONALITY) | A store that boots flattened, or a personality document with no standing sections | IN FORCE 2026-09-26 · a decision record |
+| `templates/USER.md` | `bootstrap/USER.md` | A store that relearns the person's name and preferences every session | IN FORCE 2026-09-26 · a decision record |
+| `templates/INSTALL.md` | `bootstrap/INSTALL.md` | A paste-block start that cannot check a machine or tag a write | IN FORCE 2026-09-26 · a decision record |
+| `templates/BOTHANDOFF.md` | `bots/<tag>/HANDOFF.md` (unmapped while DRAFT) | A bot that could close only by writing the user's own handoff and board; scheduled bot runs citing sessions never opened (episodic records); bot handoffs marked nonconforming against a template that demands a board | DRAFT — requested by the user 2026-10-01; approval and decision record pending. Supersede-only after revision 1 (`EMET_RECORD_DOCS`) |
+| `templates/ROSTER.md` | `bots/ROSTER.md` (unmapped while DRAFT) | A bot tag the server did not treat as a bot because its handoff id was never listed (a live check of per-bot close records, 2026-10-01); the hub's tag at risk of being listed with the bots | DRAFT — requested by the user 2026-10-01; approval and decision record pending. The hub is listed apart and never in `EMET_RECORD_DOCS` |
+
+**Deliberately NOT templated:** an install's own orchestrator (a single document, not a type) · layer entries and transcripts (structure already enforced by the write-path door) · an install's private reference documents that have their own convention and no recorded failure.
+
+**Bootstrap templates (2026-09-26):** `templates/IDENTITY.md`, `templates/CHARACTER.md`, `templates/USER.md`, `templates/INSTALL.md` — IN FORCE (user: "Go ahead"). They are the empty structure the interview fills. An install's existing bootstrap *records* are revised only to meet the template's form, with no loss of original content (user, 2026-09-11 and 2026-09-26).
+
+---
+
+## BUILD ORDER
+
+0. ~~STANDARD~~ — written 2026-09-10.
+1. ~~HANDOFF + BOARD~~ — written 2026-09-10; in trial use.
+2. ~~CHARTER~~ — written 2026-09-10; §1 intended use awaits the user's words.
+3. ~~SEED + THREAD~~ — written 2026-09-10 evening.
+4. ~~STAGING + PROCEDURE~~ — written 2026-09-10 evening.
+5. ~~Migrate the position document into the BOARD form~~ — done 2026-09-10.
+6. ~~Review of the full set with the user~~ — done 2026-09-11.
+7. **Validation v1** — DECIDED 2026-09-11: the priced scope plus locks L1–L6. Not built — bridged session.
+8. **Repository commit** — the charter and templates ship in the release; the set becomes IN FORCE with it.
+
+## LATITUDE — DECIDED (user, 2026-09-10; a decision record)
+*"They must be followed but can be expanded and there can be a generic template standard guidlines for anything added above and beyond will be created within those guidelines."* Base templates: required sections fixed; installs may expand, never loosen. Anything beyond the base is built to `templates/STANDARD.md`.
+
+## SCOPE — DECIDED (user, 2026-09-10; a decision record)
+**Product-level.** *"This will be built and baked into the EMET repo as the standard base form/floor state to move forward to public use by others."*
+- The charter and every template ship in the EMET repo as the base every install starts from. **The reference install is the first user, not the scope.**
+- **Shipped forms are generic:** "user" and "assistant", never a named person or assistant. Install-specific content lives in the install's own records, never in a template or this register.
+- **Shipping — DECIDED 2026-09-11:** the repository carries the base templates and the setup interview writes them into each new store.
+- Repo-facing text states current state only while the repo is private (a decision record).
+- ⚠ **The charter and this register become public, so the undrawn disclosure line (a decision record) bears on how much architecture they state.**
+
+## OPEN — the user's
+- **Adoption — DECIDED 2026-09-11** (a decision record). IN FORCE with the repository commit.
+- **Where local templates live** in an install's store.
+- **Intended-use statement** for the charter.
+- **The disclosure line** — before the repository goes public.

package/templates/INSTALL.md

@@ -0,0 +1,29 @@
+# TEMPLATE — INSTALL
+
+**Template control:** id `templates/INSTALL.md` · revision: the store's version governs · status: IN FORCE · approved: user · 2026-09-26 · a decision record · owner: EMET (base) · built to `templates/STANDARD.md` · supersedes: none
+**Fills:** `bootstrap/INSTALL.md` — this install's hosts, machines, source tags, and the checks a session runs before the startup list. Optional; absence is not an error.
+**Failure it prevents:** a paste-block-only start that cannot check a machine, mint a session id, or tag a write, because those notes lived only in one install's head (proof of concept 2026-09-26; `install_notes` served from this document when present).
+**Completion rules:** `templates/STANDARD.md` §5, unmodified.
+
+---
+
+## HOW TO FILL — rules specific to this template
+
+1. **Optional.** A new store may have none until the user adds hosts.
+2. **Checks are ordered and owned.** A session runs them in the order written and states what this document asks it to state.
+3. **No secrets.** Tags and host names only. Credentials never live here.
+
+---
+
+## §0 RECORD CONTROL
+- Template: `templates/INSTALL.md` rev __ · Record revision: the store's version governs
+- Session id: __ · Source tag: __ · Written (local): __
+
+## §1 HOSTS AND TAGS
+Each host this user uses, and the source tag writes from that host carry.
+
+## §2 SESSION START CHECKS
+The checks to run before the startup list, in order — or *"None."*
+
+## §3 SESSION ID FORM
+The form of the session id, default `YYYY-MM-DD_short-name` from the user's local date — or *"Default."*

package/templates/PROCEDURE.md

@@ -0,0 +1,39 @@
+# TEMPLATE — PROCEDURE
+
+**Template control:** id `templates/PROCEDURE.md` · revision: the store's version governs · status: IN FORCE · approved: user · 2026-09-11 · a decision record · owner: EMET (base) · built to `templates/STANDARD.md` · supersedes: none
+**Fills:** `procedures/<name>.md` — reference procedures and work instructions: how to do one specific thing on one specific system (Tier 3). **Every `procedures/*` document is validated against this template by its id** (`templates/STANDARD.md` §9 map); leaving out the control block does not exempt it (§9a L4). Work instructions that exist outside the store come in when they are next rewritten, not before.
+**Failure it prevents:** recorded paths and commands that went stale unverified and failed silently when followed — an interpreter path that no longer existed carried in two bootstrap documents for months; a deploy command naming the project instead of the service (reference install, August–September 2026).
+**Completion rules:** `templates/STANDARD.md` §5, unmodified.
+
+---
+
+## HOW TO FILL — rules specific to this template
+
+1. **Every path, command and version carries the date it was last seen working, and on which machine.** An entry with no verification date is a nonconformance.
+2. **A step that has failed is corrected by revision, with the failure recorded in §5** — never edited out silently.
+3. **Machine-specific steps say which machine.** A procedure that is true on one machine and not another states both, or states which one it was checked on.
+
+---
+
+## §0 RECORD CONTROL
+- Template: `templates/PROCEDURE.md` rev __ · Procedure revision: the store's version governs
+- Applies to: system / machine · Last verified end to end: __ (date, machine, session id)
+
+## §1 PURPOSE
+What this procedure does and when to use it, one or two lines.
+
+## §2 PRECONDITIONS
+What must be true before starting, each with how to check it.
+
+## §3 STEPS
+| # | Step | Exact command or action | Expected result | Last verified (date, machine) |
+|---|---|---|---|---|
+
+## §4 VERIFY
+How to confirm the procedure worked — the check, not the claim.
+
+## §5 KNOWN FAILURES
+| Date | What failed | Cause, or "undetermined" | Correction |
+|---|---|---|---|
+
+Or *"None recorded."*

package/templates/ROSTER.md

@@ -0,0 +1,43 @@
+# TEMPLATE — BOT ROSTER
+
+**Template control:** id `templates/ROSTER.md` · revision: the store's version governs · status: DRAFT, not in force · approved: pending — the user asked for it 2026-10-01; IN FORCE only once the user approves this text and the decision record is filed · owner: EMET (base) · built to `templates/STANDARD.md` · supersedes: none
+**Fills:** `bots/ROSTER.md` — the one list of the bots that write to this install: each bot's source tag, name, role, host, machine, record, tool profile and owner, and the hub that is not a bot. It is a controlled document, revised under control (each revision archived), and kept by the hub. It is the user's register; the server's switch is `EMET_RECORD_DOCS`, and §3 records that the two agree.
+**Failure it prevents:** a bot tag the server did not treat as a bot because its handoff id was never listed in `EMET_RECORD_DOCS`, found only when a live check's refusal came from the wrong rule (a live check of per-bot close records, 2026-10-01: a bot's test write refused by the records rule, not the bot rule); and the hub's own tag at risk of being listed with the bots, which would make the server refuse the hub's writes to the user's handoff and board (found on review of that check, 2026-10-01; `docs/DEPLOY.md`). Until this list existed, which tags were bots lived only in a deploy variable nobody could read back from inside a session.
+**Completion rules:** `templates/STANDARD.md` §5, unmodified.
+
+---
+
+## HOW TO FILL — rules specific to this template
+
+1. **One bot, one tag, one row.** The tag has the form `<prefix>-<bot name>`, lower case, letters, digits and hyphens, no `/` (`docs/BOTS.md` §2). A tag is never shared or reused; a retired bot's row stays, marked RETIRED.
+2. **The hub is not a bot.** It is listed in §2 only. Its tag never appears in `EMET_RECORD_DOCS`, because a listed tag can no longer write the user's handoff and board.
+3. **§3 is read back, not remembered.** It quotes the bot entries of `EMET_RECORD_DOCS` and `EMET_SOURCE_TAGS` as read from the deployment, with the date and deployment id. A row whose handoff id is missing there is not yet a bot, whatever this list says.
+4. **Tool profiles are named, not enforced.** The server has no profile mechanism; the profile column records what the bot's host is configured to offer, and is marked provisional until the user adopts the profiles.
+5. **Personal details stay in the store.** This template ships generic; an install's filled roster can name machines and people, so it is never copied into a public repository.
+
+---
+
+## §0 RECORD CONTROL
+- Template: `templates/ROSTER.md` rev __ · Roster revision: the store's version governs
+- Owner (the user): __ · Kept by (the hub): __ · Last updated: __ (local) · Session id: __ · Source tag: __
+- **What changed in this revision, one line:** __
+
+## §1 BOTS
+| Tag | Name | Role | Host | Machine | Handoff doc | Tool profile | Owner | Status | Registered (SOURCE_TAGS · RECORD_DOCS) |
+|---|---|---|---|---|---|---|---|---|---|
+| __ | __ | __ | __ | __ | `bots/__/HANDOFF.md` | __ | __ | __ (ACTIVE · PILOT · PLANNED · RETIRED) | __ · __ |
+
+## §2 HUB — host-level, never a bot
+| Tag | Name | Host | Machine | Records it writes | Listed in RECORD_DOCS |
+|---|---|---|---|---|---|
+| __ | __ | __ | __ | `HANDOFF.md`, `STATE.md` | No — never |
+
+## §3 CONFIGURATION READ-BACK
+- Read (local): __ · Deployment: __ · Read by: __
+- `EMET_RECORD_DOCS` bot entries: __
+- `EMET_SOURCE_TAGS` bot and hub entries: __
+- **Agreement:** every ACTIVE or PILOT row in §1 has its handoff id in `EMET_RECORD_DOCS` and its tag in `EMET_SOURCE_TAGS`; no hub tag is in `EMET_RECORD_DOCS` — __ (Y, or the rows that disagree)
+
+## §4 CHANGE LOG
+| Date (local) | Change (added · retired · role · profile) | User's words, verbatim | Decision record |
+|---|---|---|---|

package/templates/SEED.md

@@ -0,0 +1,65 @@
+# TEMPLATE — SEED
+
+**Template control:** id `templates/SEED.md` · revision: the store's version governs · status: IN FORCE · approved: user · 2026-09-13 (record control stated once, as front matter — the user's instruction; prior approval 2026-09-11 · a decision record) · owner: EMET (base) · built to `templates/STANDARD.md` · supersedes: none
+**Fills:** `seeds/<name>.md` — an idea that is valid but wrongly timed, parked with the condition that brings it back.
+**Failure it prevents:** a met trigger that sat unsurfaced for weeks because nothing at startup could tell it had fired (reference install, 2026-09-10); triggers that name an event nobody scheduled, so they could never fire (three seeds waiting on a "post-certification review" that was never put on a calendar, same date); a seed that had already been executed still sitting as a seed, read at every startup as live (reference install, supersession work, August 2026).
+**Completion rules:** `templates/STANDARD.md` §5, unmodified.
+
+⚠ **CHANGED 2026-09-13 — record control is the YAML front matter, and it is stated in exactly one place.** This template previously carried a `## §0 RECORD CONTROL` heading *and* told the author to put that same record control in YAML front matter. Front matter cannot sit underneath a markdown heading and still be front matter, so no seed could ever satisfy both — and because the conformance checker reads a template's required sections from its own `## §N` headings, it demanded a `## §0` heading that every correctly-written seed necessarily lacked. Every seed in the store was marked nonconforming for obeying the template. The requirement has moved to rule 4 below, where it is stated once and is satisfiable. **Nothing was relaxed: the front matter is still required, and a seed without it is still wrong.** The remaining half of this fix belongs in the product — see the note at the foot of this template.
+
+---
+
+## HOW TO FILL — rules specific to this template
+
+1. **Every trigger is testable without asking the user.** It is one of four kinds, and nothing else:
+   - `DATE` — a calendar date. Fires on or after it.
+   - `ROW` — a board row id and the change that fires it (`B-001 opens`, `B-002 closes`). The board row must exist when the seed is planted; if it does not, open one.
+   - `SIGNAL` — something a startup can observe by name: a named document reaching a named state, a named external item closing. **Name where it is checked.**
+   - `TOPIC` — the user raises a named subject. **Checked during the session, not at startup:** list the subject words in the trigger so any session that has scanned the seed recognises them when they come up. *Prevents:* outlawing a trigger that works — the reference install's first-run-experience seed fired correctly this way on 2026-09-11.
+   A trigger that names an event with no date and no board row ("after the review", "when there is time") is a nonconformance: plant it as `ROW` against a row that schedules the event, or as `DATE`.
+2. **A seed changes status, it does not linger.** `DORMANT` → `MET` (date, and whether it was surfaced to the user) → either `ACTED ON` with a disposition, or `SHELVED`. An acted-on seed is retired (`retire_doc`), never left in the working view. Its content is retained.
+   - **`SHELVED`** — the trigger was met and the user paused it. Record the user's words, the date, and **resumes when:** the trigger that brings it back. Not raised as work, and named in the startup list's parked section with its resume trigger, like a parked board row (charter §3 commitment 8, 2026-09-23). When the resume trigger is met it returns to `MET`. **The status log keeps the earlier `MET` row, so a shelved seed always shows it has fired before** — returning it to `DORMANT` would erase that (the user, 2026-09-11: *"it will mark it as MET but waiting which returning to DORMANT has no indication that it was previously MET"*). *Prevents:* a seed the user paused mid-work being indistinguishable from one that never fired.
+3. **The user's words are carried verbatim and dated, or the section says the seed is assistant-authored.** An assistant-authored idea is not a decision until the user says so.
+4. **RECORD CONTROL IS THE YAML FRONT MATTER, AT THE TOP OF THE FILE, BEFORE ANY HEADING.** It is required, and it is where a startup reads the trigger without parsing the body. It carries nothing that is also stated in the body.
+```
+---
+template: templates/SEED.md rev __
+trigger:
+  - kind: DATE | ROW | SIGNAL | TOPIC
+    test: __            # the date · the row id and the change · the observable, and where it is checked · the subject words
+status: DORMANT | MET | SHELVED | ACTED ON
+resumes_when: __        # SHELVED only — the trigger that brings it back
+planted: __             # local date
+planted_by: __          # source tag
+session: __             # session id
+---
+```
+⚠ **Put the trigger in the front matter itself, never in a fenced ```yaml block inside the body.** A fenced block is body text; a startup scan cannot read it. Four seeds in the reference install do this and are invisible to an automated scan.
+
+---
+
+## §1 THE IDEA
+What it is, in two or three sentences, and **why now is the wrong time** — the reason it is a seed and not a board row.
+
+## §2 WHOSE IDEA
+The user's words, verbatim, with the date — or *"Assistant-authored; not decided by the user."*
+
+## §3 WHEN IT FIRES — WHAT TO DO FIRST
+The first concrete action when a trigger is met, so the session that finds it does not have to re-derive it. One or two lines.
+
+## §4 OPEN QUESTIONS
+Questions for the user, not answered by the assistant — or *"None."*
+
+## §5 STATUS LOG
+| Date | Status | Evidence (board row, document revision, record id, user's words) |
+|---|---|---|
+| __ | DORMANT — planted | this revision |
+
+**Disposition when ACTED ON is one of:** `MOVED TO BOARD <row id>` · `EXECUTED` (evidence required) · `DROPPED BY USER` (their words and date). Then retire the seed.
+
+## §6 RELATED
+Board rows, threads, records — or *"None."*
+
+---
+
+**PRODUCT NOTE, not a rule for authors.** The conformance checker derives a template's required sections from that template's own `## §N` headings. That is correct for every other template and wrong for this one, because this template's record control is front matter by design. Removing the heading fixes it from the template side with no code change and no loss of the requirement. The complete fix is in the checker: for a template whose record control is declared as front matter, read the front matter as the record-control section rather than looking for a heading. Built 2026-09-26: `checkSeedFrontMatter` in `src/conformance.js` checks trigger kind (DATE, ROW, SIGNAL, TOPIC), status, test, planted fields, and `resumes_when` on SHELVED. A seed can now fail for a bad trigger, not only for a missing heading.

package/templates/STAGING.md

@@ -0,0 +1,37 @@
+# TEMPLATE — STAGING
+
+**Template control:** id `templates/STAGING.md` · revision: the store's version governs · status: IN FORCE · approved: user · 2026-09-11 · a decision record · owner: EMET (base) · built to `templates/STANDARD.md` · supersedes: none
+**Fills:** `staging/<name>-<yyyy-mm>.md` — work lists, proposals, pricings, research notes: anything that is worked on before it is decided.
+**Failure it prevents:** an instance-authored proposal read later as a decision — a delete tool was specified from a staging note nobody had approved, and the note contradicted itself (reference install, a decision record); drafts with no visible status, so a reader could not tell a priced option from an adopted one.
+**Completion rules:** `templates/STANDARD.md` §5, unmodified.
+
+---
+
+## HOW TO FILL — rules specific to this template
+
+1. **The status line is the first thing a reader sees, and it says who decided.** A staging document is never a decision. When the user decides, the decision is recorded where decisions live (a layer entry, the board, the thread) and this document's status line points to it.
+2. **Every claim says where it came from:** read from code or a document (name it and its revision), measured (how), or inferred (marked as inference).
+3. **When the work is finished or abandoned, or an `IN USE` document is no longer used, the document is retired** with a one-line reason — never left in the working view as if current.
+4. **Every `staging/*` document is validated against this template by its id** (`templates/STANDARD.md` §9 map) — leaving out the control block does not exempt it (§9a L4). *Prevents:* a staging document escaping validation by omission (found at review, 2026-09-11).
+
+---
+
+## §0 RECORD CONTROL
+- **Status:** one of `DRAFT` · `PRICED, NOT APPROVED` · `PROPOSED TO THE USER <date>` · `DECIDED — see <record>` · `IN USE — <what uses it>` (a schedule or work list the user works from — not a proposal, not a decision) · `ABANDONED — <reason>`
+- **Authored by:** user / assistant (from what) · Session id: __ · Source tag: __ · Written (local): __
+- **Board row:** __ — or *"None — this is not tracked work."*
+
+## §1 QUESTION
+What this document exists to answer, in one or two sentences.
+
+## §2 WHAT WAS FOUND
+The substance. Sources named per rule 2.
+
+## §3 OPTIONS OR PROPOSAL
+Options in ascending order of cost and invasiveness, each with what it prevents and what it costs — or the single proposal and its price. Or *"None — findings only."*
+
+## §4 WHAT IS THE USER'S TO DECIDE
+One line each — or *"Nothing; this is reference."*
+
+## §5 LIMITS
+What this does not establish, and what could make it wrong.