@dreamforgestudiollc/emet 0.2.4 → 0.2.6

package/src/transcript-session.js

@@ -7,7 +7,7 @@ export const EXCHANGES_PER_PART = 8;
 /**
  * The zone a session id is dated in (2026-10-01, the owner's approval; dev team plan
  * Part B, fix 1). Ids were dated from UTC, so an evening session in New York
- * carried the next day's date (an incident record: `2026-10-01_grok-init` minted on
+ * carried the next day's date (episodic ref 600: `2026-10-01_grok-init` minted on
  * the night of 9/30). The day is now the user's local day: EMET_TIMEZONE, an
  * IANA zone name, default America/New_York. A name the runtime does not know
  * falls back to the default and says so - marked, never guessed at.

package/src/validation.js

@@ -107,6 +107,17 @@ export const VALID_METADATA_FIELDS = Object.freeze([
   'importance_degree',        // low|mid|high — only when degree inside the bucket matters
   'provenance_missing',       // boolean: no derived_from on a layer whose charter wants one
   'assertion_origin_missing', // boolean: assertion_origin was not supplied at all
+  // Kept RUNE results (GEP-0003). The server sets these on a real seal.
+  // `version` alone is an ordinary key. `rune_attested` marks a server seal.
+  'gem',
+  'version',
+  'rune',
+  'served_sha256',
+  'client_sha256',
+  'input_sha256',
+  'input_ref',
+  'principal',
+  'rune_attested',
   'custom'  // Allow a 'custom' object for extensibility
 ]);
 
@@ -139,7 +150,7 @@ export const CONTENT_ORIGINS = Object.freeze(['self', 'assistant', 'external']);
  */
 export class ValidationError extends Error {
   constructor(field, message, value = undefined) {
-    // One-argument calls pass the whole message as `field` (the second reader's fix (b), 2026-10-02): that used to
+    // One-argument calls pass the whole message as `field` (the reviewer's fix (b), 2026-10-02): that used to
     // render "Validation failed for '<message>': undefined".
     if (message === undefined) { message = field; field = null; }
     super(field === null ? message : `Validation failed for '${field}': ${message}`);
@@ -603,6 +614,7 @@ export function validateMetadata(metadata) {
       case 'importance_defaulted':
       case 'provenance_missing':
       case 'assertion_origin_missing':
+      case 'rune_attested':
         if (typeof value !== 'boolean') {
           throw new ValidationError(key, 'Value must be a boolean', typeof value);
         }
@@ -622,6 +634,18 @@ export function validateMetadata(metadata) {
         }
         break;
 
+      case 'gem':
+      case 'version':
+      case 'rune':
+      case 'served_sha256':
+      case 'client_sha256':
+      case 'input_sha256':
+      case 'input_ref':
+      case 'principal':
+        if (typeof value !== 'string') throw new ValidationError(key, 'Value must be a string', typeof value);
+        sanitized[key] = value;
+        break;
+
       case 'custom':
         // Allow custom object but validate its size
         if (isPlainObject(value)) {
@@ -808,7 +832,7 @@ export function validateStringField(value, fieldName) {
  * object is discarded silently by design - the validator is a whitelist - so a
  * caller who passes an unrecognised key gets a full UNFILTERED page back and no
  * error, which is indistinguishable from "the filter did not work". That
- * symptom cost a bug hunt on 2026-09-08 (a recorded lesson). The list is exported
+ * symptom cost a bug hunt on 2026-09-08 (semantic ref 259). The list is exported
  * so callers can NAME the dropped keys instead of swallowing them.
  */
 export const RECOGNISED_FILTER_KEYS = Object.freeze([

package/src/version.js

@@ -1,2 +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';
+export const EMET_VERSION = '0.2.6';

package/templates/BOARD.md

@@ -1,6 +1,6 @@
 # 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
+**Template control:** id `templates/BOARD.md` · revision: the store's version governs · status: IN FORCE · approved: user · 2026-09-11 · procedural ref 311 · owner: EMET (base) · built to `templates/STANDARD.md` · decision record: procedural ref 304
 **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.
@@ -13,7 +13,7 @@
 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).
+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, meta ref 16: support-structure confabulation; live instance 2026-09-11, an episode publish date resting on a shoot no one had recorded).
 
 ---
 

package/templates/BOTHANDOFF.md

@@ -1,8 +1,8 @@
 # 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
+**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 the recorded time; 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).
+**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 (C1 review note §1a, 2026-10-01); scheduled bot runs citing sessions that were never opened, leaving permanent holes in the record (`emet_gaps` pointer disagreements, episodic ref 558 and ref 592); 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 (the review note's second read of the C1 live check, 2026-10-01).
 **Completion rules:** `templates/STANDARD.md` §5, unmodified.
 
 ---

package/templates/CHARACTER.md

@@ -1,6 +1,6 @@
 # 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
+**Template control:** id `templates/CHARACTER.md` · revision: the store's version governs · status: IN FORCE · approved: user · 2026-09-26 · procedural ref 361 · 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.

package/templates/HANDOFF.md

@@ -1,6 +1,6 @@
 # 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
+**Template control:** id `templates/HANDOFF.md` · revision: the store's version governs · status: IN FORCE · approved: user · 2026-09-11 · procedural ref 311 · owner: EMET (base) · built to `templates/STANDARD.md` · decision record: procedural ref 304
 **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.

package/templates/IDENTITY.md

@@ -1,6 +1,6 @@
 # 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
+**Template control:** id `templates/IDENTITY.md` · revision: the store's version governs · status: IN FORCE · approved: user · 2026-09-26 · procedural ref 361 · 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.

package/templates/INDEX.md

@@ -1,7 +1,7 @@
 # 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.
+**Status:** **ADOPTED by the user 2026-09-11** (*"Yes I do"*; procedural ref 311). **IN FORCE with the repository commit** (board 014), because the shipped copy governs (`templates/STANDARD.md` §9a L1; `CHARTER.md` §9). Revision: the store's version governs. Decision records: procedural ref 300 → ref 301 (scope), ref 302 (latitude), ref 303 → ref 304 (validation not optional; mark for audit and review); review of 2026-09-11: ref 306 (validation v1, shipping), ref 307 (locks), ref 308 (close order), ref 309 (charter lock), ref 310 (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 (ref 301). The reference install's own records keep them.
 
 ---
 
@@ -10,7 +10,7 @@
 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.
+4. **No implied conformity** (procedural ref 293). 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).
 
 ---
@@ -39,11 +39,11 @@ Every document listed under **Fills** is validated against its template by its i
 | `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/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 · procedural ref 361 |
+| `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 · procedural ref 361 |
+| `templates/USER.md` | `bootstrap/USER.md` | A store that relearns the person's name and preferences every session | IN FORCE 2026-09-26 · procedural ref 361 |
+| `templates/INSTALL.md` | `bootstrap/INSTALL.md` | A paste-block start that cannot check a machine or tag a write | IN FORCE 2026-09-26 · procedural ref 361 |
+| `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 ref 558, ref 592); 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.
@@ -56,27 +56,27 @@ Every document listed under **Fills** is validated against its template by its i
 
 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.
+2. ~~CHARTER~~ — written 2026-09-10; §1 intended use awaits the user's words (board 010).
 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.
+7. **Validation v1** — DECIDED 2026-09-11 (ref 306, ref 307): the priced scope plus locks L1–L6. Not built — bridged session.
+8. **Repository commit** (board 014) — the charter and templates ship in the release; the set becomes IN FORCE with it.
 
-## LATITUDE — DECIDED (user, 2026-09-10; a decision record)
+## LATITUDE — DECIDED (user, 2026-09-10; procedural ref 302)
 *"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)
+## SCOPE — DECIDED (user, 2026-09-10; procedural ref 301, superseding ref 300)
 **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.**
+- **Shipping — DECIDED 2026-09-11 (ref 306):** 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 (procedural ref 299).
+- ⚠ **The charter and this register become public, so the undrawn disclosure line (procedural ref 292) 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.
+- **Adoption — DECIDED 2026-09-11** (procedural ref 311). 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.
+- **Intended-use statement** for the charter (board 010).
+- **The disclosure line** (board 016) — before the repository goes public.

package/templates/INSTALL.md

@@ -1,6 +1,6 @@
 # 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
+**Template control:** id `templates/INSTALL.md` · revision: the store's version governs · status: IN FORCE · approved: user · 2026-09-26 · procedural ref 361 · 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.

package/templates/PROCEDURE.md

@@ -1,6 +1,6 @@
 # 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
+**Template control:** id `templates/PROCEDURE.md` · revision: the store's version governs · status: IN FORCE · approved: user · 2026-09-11 · procedural ref 311 (board 011) · 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.

package/templates/ROSTER.md

@@ -1,8 +1,8 @@
 # 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
+**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 the recorded time; 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.
+**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 (the review note's second read 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.
 
 ---

package/templates/SEED.md

@@ -1,6 +1,6 @@
 # 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
+**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 · procedural ref 311 (board 011)) · 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.
@@ -13,7 +13,7 @@
 
 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.
+   - `ROW` — a board row id and the change that fires it (`board 018 opens`, `board 011 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`.

package/templates/STAGING.md

@@ -1,8 +1,8 @@
 # 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
+**Template control:** id `templates/STAGING.md` · revision: the store's version governs · status: IN FORCE · approved: user · 2026-09-11 · procedural ref 311 (board 011) · 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.
+**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, procedural ref 296); 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.
 
 ---

package/templates/STANDARD.md

@@ -1,6 +1,6 @@
 # EMET TEMPLATE STANDARD
 
-**Template control:** id `templates/STANDARD.md` · revision: the store's version governs · status: IN FORCE · approved: user · 2026-09-11 · a decision record · owner: EMET (base) · decision record: the owner's
+**Template control:** id `templates/STANDARD.md` · revision: the store's version governs · status: IN FORCE · approved: user · 2026-09-11 · procedural ref 311 · owner: EMET (base) · decision record: procedural ref 304
 **Governs:** every base template shipped with EMET, every extension an install adds to one, and every new template an install creates.
 
 ---
@@ -64,23 +64,23 @@ template id and revision used · record revision · session id · source tag ·
 
 ---
 
-## 9. VALIDATION — NOT OPTIONAL (the user, 2026-09-10)
+## 9. VALIDATION — NOT OPTIONAL (the user, 2026-09-10; procedural ref 304)
 
 *"There needs to be a document template validation tool that isn't optional either freestanding or incorporated into established regular processes."*
 
 **Every record from a templated document type is validated against its template. No caller can skip it.**
 
-**Design — priced 2026-09-10; v1 scope APPROVED by the user 2026-09-11; not yet built. Build detail and limits are kept in the owner's store.**
+**Design — priced 2026-09-10; v1 scope APPROVED by the user 2026-09-11; not yet built. Build detail and limits: `staging/template-validation-v1-pricing.md`.**
 - **Where it cannot be skipped:** the write path. Every document write already passes one door (redaction, digests, read-back, receipt). Validation runs there on every write to a templated type.
 - **Which documents are templated:** by the record control block's template id, **and** by a document-id map (`HANDOFF.md` → HANDOFF, `STATE.md` → BOARD, `seeds/*` → SEED, `threads/*` → THREAD, `staging/*` → STAGING, `procedures/*` → PROCEDURE …). The map means leaving out the control block cannot evade validation.
 - **Where it is also visible:** the write receipt carries the verdict; reads carry it per document (as integrity is carried today); session start counts nonconforming documents (as record gaps are counted today).
 - **Freestanding use:** the same check callable on demand — to audit existing records, migrate old ones, and check a new local template against this standard.
 
-**What v1 checks (approved scope):** control block present · a template set IN FORCE carries its approval (who · date · record) · every required section present and in order · no empty required section · no unfilled template placeholder left in the record · `NOT COMPLETED` carries a reason · a template's own checks where it names them (the BOARD's counts must match its rows) · **carry-forward — every item on the previous revision's list is still present or carries a disposition row.** The prior revision is already archived, so this is a comparison, not a judgment. (This check alone would have caught the two board items that were dropped.)
+**What v1 checks (approved scope):** control block present · a template set IN FORCE carries its approval (who · date · record) · every required section present and in order · no empty required section · no unfilled template placeholder left in the record · `NOT COMPLETED` carries a reason · a template's own checks where it names them (the BOARD's counts must match its rows) · **carry-forward — every item on the previous revision's list is still present or carries a disposition row.** The prior revision is already archived, so this is a comparison, not a judgment. (This check alone would have caught the dropped Noctrix and Elbit items.)
 
 **What a machine cannot fully check:** whether a "none" states its scope honestly, or whether an answer is true. Those remain the author's and the reader's. The tool checks form and continuity, not truth.
 
-**DECIDED — the user, 2026-09-10 (a decision record): *"Mark for audit and review."*** A nonconforming write is **not rejected.** It lands, carries a visible nonconformance marker listing what failed, and stays counted and surfaced at session start until it is **reviewed and dispositioned** — either **corrected** by a later revision (which clears the marker by passing), or **accepted** with a written reason recorded on the document. A marker is never cleared silently.
+**DECIDED — the user, 2026-09-10 (procedural ref 304): *"Mark for audit and review."*** A nonconforming write is **not rejected.** It lands, carries a visible nonconformance marker listing what failed, and stays counted and surfaced at session start until it is **reviewed and dispositioned** — either **corrected** by a later revision (which clears the marker by passing), or **accepted** with a written reason recorded on the document. A marker is never cleared silently.
 
 ### 9a. LOCKS — nothing may weaken a template's function (the user, 2026-09-11: *"lock it down and reduce opportunities to weaken it's function as a template"*)
 

package/templates/THREAD.md

@@ -1,6 +1,6 @@
 # TEMPLATE — THREAD
 
-**Template control:** id `templates/THREAD.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
+**Template control:** id `templates/THREAD.md` · revision: the store's version governs · status: IN FORCE · approved: user · 2026-09-11 · procedural ref 311 (board 011) · owner: EMET (base) · built to `templates/STANDARD.md` · supersedes: none
 **Fills:** `threads/<name>.md` — the working document for one project or line of work: its current position, its decisions and their reasons, and a dated log.
 **Failure it prevents:** threads grown by appended sections until the current state sat under hundreds of kilobytes of history (reference install: two threads at 147 KB and 328 KB). A phone session did not read one — the mobile startup skips threads by rule — so the board marked its career rows `NOT COMPLETED` (2026-09-10); whether a phone session could read a thread that size was never tested. When it was read, its priority list still told the user to submit an application that had been submitted two weeks earlier — the current state was never rewritten, only appended to.
 **Completion rules:** `templates/STANDARD.md` §5, unmodified.

package/templates/USER.md

@@ -1,6 +1,6 @@
 # TEMPLATE — USER
 
-**Template control:** id `templates/USER.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
+**Template control:** id `templates/USER.md` · revision: the store's version governs · status: IN FORCE · approved: user · 2026-09-26 · procedural ref 361 · owner: EMET (base) · built to `templates/STANDARD.md` · supersedes: none
 **Fills:** `bootstrap/USER.md` — who the install serves. Written at the first-run interview from the user's answers.
 **Failure it prevents:** a store that knows an assistant name and not the person, or that relearns spelling and working preferences every session because they had no standing home (interview keys `user_name`, `user_context`, `user_preferences`; user 2026-09-26: structure ships, personal data does not).
 **Completion rules:** `templates/STANDARD.md` §5, unmodified.
@@ -27,3 +27,6 @@ The use they named at interview — work, a project, personal continuity, or the
 
 ## §3 PREFERENCES
 How they want to be worked with: length, directness, being asked before changes — or *"None stated."*
+
+## §4 BOT-TEAM BACKUP
+`yes` or `no`. Recorded at the first-run interview. Yes and Yes. are recorded as yes. Yes is the recommended choice and means follow `gems/bot-team-backup/guides/BOT_TEAM_BACKUP.md`. No, or leaving the question out, records `no` and leaves the practice off. EMET does not copy prompts or settings itself. Never store secret values in a bot-team document.