@dreamforgestudiollc/emet 0.2.4 → 0.2.6

package/docs/DEPLOY.md

@@ -22,6 +22,9 @@ passphrase; both are required.
 | `PUBLIC_URL` | yes | The public **https** base URL. This is the OAuth issuer and must match the deployed URL exactly. |
 | `EMET_OAUTH_PASSPHRASE` | yes | Typed once per device to authorize it. Make it strong — it is the only thing between the internet and your memory. |
 | `EMET_SOURCE_TAG` | optional | Default tag for a write that passes no `source`. Leave it unset on a server several hosts share (see below); set it only when one host uses this deployment. |
+| `EMET_SUBKEYS` | when more than one bot shares the owner login | `1` turns on delegated client sub-keys. On this kind of host, set it in the platform's variables. Setup refuses to write a pepper into the container `.env`. Restart or redeploy so the tools and `/owner/approvals` appear together. See [SUBKEYS.md](SUBKEYS.md). |
+| `EMET_SUBKEY_PEPPER` | with that flag | Server secret, at least 32 bytes, generated by the owner on a hosted deploy (`openssl rand -hex 32`). Not stored in the database. |
+| `EMET_SUBKEY_PEPPER_VERSION` | with that flag | `1` until the pepper is rotated. Set it with the other two, then redeploy. |
 | `EMET_TIMEZONE` | optional | IANA time zone that session ids are dated in, e.g. `America/Chicago`. Default `America/New_York`. An unknown name falls back to the default and `emet_session_open` says so. |
 | `EMET_CLOSE_GRACE_MINUTES` | optional | Minutes after a complete close in which a session still takes its one closing exchange (the reply sent after the close). Default `5`; `0` turns the window off; at most `60` (a larger value is capped at 60). A negative or non-numeric value is not used: the server logs a warning and uses `5`. |
 | `EMET_GAP_BASELINE` | optional | ISO date (or Unix seconds) from which the record is held to the current rules. The startup line then reports gaps since that date beside the lifetime figure. |
@@ -33,6 +36,8 @@ passphrase; both are required.
 Read this before you deploy the release that follows 0.2.2. It does not change a version number. It is the list of settings and client habits that will start failing if you leave them as they were.
 
 - **`EMET_SOURCE_TAGS` must list every real host tag**, as an exact member. Tags named in this repository's example env, docs, and live-tag checks are: `cli`, `mobile`, `desktop-host`, `cloud-host`, `project-host`, `hub-bot` (the hub; do not also list it in `EMET_RECORD_DOCS`), `reviewer-bot`, `tester-bot`, `memory-bot`, `intake-bot`, and `research-bot`. Your install may use a shorter list. A tag that is not an exact member is refused, and the refusal does not print the list.
+- When a new bot joins the roster, append its tag to the end of `EMET_SOURCE_TAGS` and keep every existing tag in order, before its first write. The standing rule, including `EMET_RECORD_DOCS` and the `/health` and `emet_status` check after the redeploy, is [BOTS.md](BOTS.md) §4.
+- **`EMET_STRICT_LOGIN_TAG=1`** (off by default) makes a login's bound tag final: a write that declares a different `source` is refused, and so are `emet_setup_complete` and `emet_initialize` with a mismatched tag. Leave it off while bots share one login, because with it on every bot except the login's own would be refused. Turn it on only once each bot has its own login, for example a Member Access code bound to its tag.
 - **A scheduled job that still sends a `cloud-scheduled-` prefix must switch to an exact registered tag.** `cloud-scheduled-intake` was retired on 2026-10-02. A prefix is not a tag. The weekly intake runs under `intake-bot`.
 - **An HTTP client whose stored token has no source tag must sign in again.** Refresh of that token is refused. The new consent binds a registered tag. An empty registry has no members.
 - **Caps already in force.** A client that used to send more is refused, and nothing is written:
@@ -99,8 +104,8 @@ pages each host fetched is kept in the server's memory for 60 minutes after its
 after every deploy or restart, or a longer pause, an open with an older `load_id` is refused once
 and told to call `emet_initialize {}` again.
 
-There is no setting to turn the monorail's refusals off. In an emergency, redeploy the previous
-release, git tag `v0.1.0`, and check EMET_SESSION_GRAPH first: unset or report flags
+There is no setting to turn the monorail's refusals off. In an emergency, redeploy private main
+as it stood before this release (commit-9bf9096) and check EMET_SESSION_GRAPH first: unset or report flags
 skipped steps without blocking them (a closed session still takes no new exchanges, and a
 session-store outage still blocks transcript writes and `emet_session_open`); enforce keeps
 refusing; off stops consulting the graph, including the closed-session lock, so a closed session
@@ -160,7 +165,7 @@ the legacy `CASCADE_...` name as a deprecated fallback (the `EMET_` name wins wh
 `EMET_SOURCE_TAG`, `EMET_SOURCE_TAGS`, `EMET_OAUTH_PASSPHRASE`, `EMET_AUDIT_LOG`, `EMET_HANDOFF_DOC`,
 `EMET_STATE_DOC`, `EMET_INSTALL_DOC`, `EMET_CHARACTER_DOC`, `EMET_TEMPLATE_MAP`, `EMET_RECORD_DOCS`,
 `EMET_READ_DOC_PAGE`, `EMET_SIGNING_KEY`, `EMET_GAP_BASELINE`, `EMET_CIMD`, `EMET_INVITES`,
-`EMET_TIMEZONE` and `EMET_CLOSE_GRACE_MINUTES`. These read `process.env` directly, so **only the
+`EMET_TIMEZONE`, `EMET_CLOSE_GRACE_MINUTES` and `EMET_ACTIVE_GEMS`. These read `process.env` directly, so **only the
 `EMET_` name works** and a `CASCADE_` name is ignored: `EMET_COLLECTION_PREFIX`,
 `EMET_VECTOR_INDEX`, `EMET_CORPUS_INDEX`, `EMET_CORPORA`, `EMET_CORPUS_COLLECTION`,
 `EMET_REQUEST_LOG` and `EMET_CRASH_LOG`. (`MONGODB_URI`, `MONGODB_DB`, `PUBLIC_URL`, `PORT`, `HOST`,
@@ -222,7 +227,7 @@ you saved elsewhere. If the remote host sees what the laptop wrote, the deployme
 
 ## Notes
 
-- **Release note: startup stage 1 (the host-aware startup amendment).** Three behaviour changes take effect
+- **Release note: startup stage 1 (the ref 358 amendment).** Three behaviour changes take effect
   live on deploy:
   - **Re-running setup is refused.** `emet_setup_complete` on a store where both
     `bootstrap/IDENTITY.md` and `bootstrap/USER.md` already exist is refused unless the call passes

package/docs/GUARDRAILS-AND-MONORAILS.md

@@ -79,7 +79,7 @@ The architecture needs flexibility of flow: at some points a session should go o
 - **Like a transistor (an IGBT).** A switch conducts only when its gate condition is met, and it is tripped by that condition, nothing else. The condition is read from what EMET already holds: the session's state, the call being made, and what the record says. The branch it selects is where the session goes next.
 - **Small and local.** A switch is a few lines of logic in the server's code. No hosted model, no outside API, no model call. It gives the same answer for the same inputs, every time, so it can be tested like any other gate. This is the role a fast external decision model (such as JEV) plays in other designs, done here by the track itself.
 - **Designed per junction.** Each switch's design follows the function it serves and how information and tasking flow through that junction. There is no general-purpose router: a junction gets a switch only when a real fork exists, and the switch knows only what that fork needs (commitment 6: over-engineering is a defect).
-- **Bounded on every branch.** Each branch leads to a guardrail space, for example a GEM once the socket exists, or a work instruction for a kind of task. The four gates still apply on every branch, so a switch can change where the session works, never whether its steps are recorded.
+- **Bounded on every branch.** Each branch leads to a guardrail space, for example a GEM (Golem Expertise Module) once the socket exists, or a work instruction for a kind of task. The four gates still apply on every branch, so a switch can change where the session works, never whether its steps are recorded.
 - **Recorded.** Each time a switch trips, the lab results record which way it went and why, so its conditions can be checked against real sessions before anything depends on them.
 
 ### Lab results
@@ -105,3 +105,4 @@ The server sees tool calls, never the reply text. It can confirm that exchange 8
 - `src/tools.js`: `session_id` and `exchange` added to every governed schema from the graph's own tool list.
 - `src/setup.js`: `tools_in_force` and the short instructions tell every host to pass both fields and follow `session_graph.next`.
 - `tests/session-graph.test.js`: the gates, the next stop, and the fail-closed door when a named session cannot be read.
+- Design record: `staging/emet-session-graph.md` in the EMET store. The framing is in semantic memory entry 297, and the decision on switches in procedural ref 402.

package/docs/GUIDED-SETUP.md

@@ -103,7 +103,7 @@ and report plainly. Read all of Part B before running anything.
 ### Stage 0 — check the ground
 
 ```
-node --version        # need 20+ (package.json engines); 22 preferred
+node --version        # need 22+ (package.json engines)
 npm --version
 git --version
 ```
@@ -267,9 +267,14 @@ deployment is real.
 Say nothing about setup. Call `emet_initialize`. On a new store it returns `setup_required` and
 the interview questions. Ask them **conversationally, one at a time** — what the assistant should
 be called and how it should carry itself, the person's name in the form they want used, what the
-memory is for, and optionally how they want to be worked with and this host's tag. Then
+memory is for, whether more than one bot or AI will use this memory (yes or no, in their words),
+whether to turn on bot-team backup (yes or no, in their words; Yes and Yes. count as yes; **yes is the recommended choice**; no, or leaving
+it out, leaves it off and the answer is recorded), and optionally how they want to be worked with
+and this host's tag. Then
 `emet_setup_complete`. It refuses partial answers rather than inventing an identity; that is
-correct behaviour.
+correct behaviour. Bot-team backup does not copy prompts or settings, and secret values are never stored.
+
+If they answer **no**, or they skip it, leave sub-keys off. If they answer **yes** on the local server that reads `.env`, `emet_setup_complete` writes the flag, a generated pepper, and version 1 into that file after the store writes succeed. The result does not contain the pepper. Do not paste it into the chat. Tell them to restart (or redeploy) the server once. If they answer **yes** against the hosted server, the call refuses before it saves anything. No pepper or .env was written. Tell them to run setup again without yes to finish the rest, and to follow the platform-variable steps in [SUBKEYS.md](SUBKEYS.md): set `EMET_SUBKEYS=1`, an `EMET_SUBKEY_PEPPER` they generate (at least 32 bytes), and `EMET_SUBKEY_PEPPER_VERSION=1`, then redeploy. Do not copy a pepper out of the server. Each bot's tag must be listed in `EMET_SOURCE_TAGS`. The rest is [SUBKEYS.md](SUBKEYS.md).
 
 Then hand the person the short instruction block from [BOOTSTRAP.md](BOOTSTRAP.md) to paste
 into their project instructions, so future sessions consult the memory without being told.

package/docs/PERMISSIONS.md

@@ -37,7 +37,7 @@ Every tool carries MCP annotations, declared in one table in `src/annotations.js
 | `idempotentHint` | Calling it again with the same arguments changes nothing further. |
 | `openWorldHint` | It reaches systems outside this server's own store. |
 
-Of the 29 tools:
+Of the 30 tools (`EMET_SUBKEYS=1` adds the four sub-key tools below; with the flag off they are not registered):
 
 - **11 are read-only.** `emet_gaps`, `emet_floor`, `recall`, `semantic_recall`,
   `corpus_recall`, `query_layer`, `query_transcripts`, `read_doc`, `read_doc_history`, `list_docs`,
@@ -47,8 +47,9 @@ Of the 29 tools:
   records blocked attempts), `rename_doc`, `accept_nonconformance`. They add; they do not remove or replace.
   `emet_session_open` still needs the `emet.write` scope, because it stamps the drop list a board edit trusts.
   `emet_initialize` stays a read.
-- **6 can replace what is already there, or hand out access.** `write_doc`, `patch_doc`, `restore_doc`, `emet_setup_complete`,
-  `emet_invite_create`, `emet_member_access_create`. Prior versions of a document are archived to the history
+- **7 can replace what is already there, or hand out access.** `write_doc`, `patch_doc`, `restore_doc`, `emet_setup_complete`,
+  `emet_invite_create`, `emet_member_access_create`, `emet_client_approve` (it admits or refuses a new client).
+  Prior versions of a document are archived to the history
   collection first, but the visible content a person may be relying on is replaced. A code that grants access
   is marked the same way: it is not a harmless add.
 - **1 marks a document obsolete.** `retire_doc`. Neither a removal nor a replacement: the
@@ -61,6 +62,8 @@ Of the 29 tools:
   detect a broken write path. A read-scoped token may call it without `probe`. With `probe: true` it needs
   `emet.write`. The probe deletes only that document. It does not drop the collection.
 
+With `EMET_SUBKEYS=1` the host also receives four tools: `emet_subkey_request`, `emet_subkey_claim`, and `emet_subkey_end_session` (additive), and `emet_subkey_revoke` (it retires a key's authority; the record stays). Write tools gain `session_handle`. `emet_session_open` and `emet_session_close` gain `subkey`. With the flag off those names and fields are absent. First-use setup turns the flag on only when the owner says yes and the server reads `.env`. A hosted server refuses that yes. A single client stays on the flag-off list. See [SUBKEYS.md](SUBKEYS.md).
+
 **`openWorldHint` is false on every tool.** The tools talk to this server's configured database
 and nothing else: no filesystem and no shell. The sign-in server fetches a client's metadata
 document, and only from a public address it has already checked. That is the main reason a memory

package/docs/ROADMAP.md

@@ -1,46 +1,52 @@
 # EMET — Next Steps and Proposed Features
 
-Status as of 2026-10-07. This is a working roadmap, not a commitment: items move when the owner rules on them. Nothing here is built unless it says so.
+Status as of 2026-10-11 (last full report: [status/2026-09-29-state-of-the-system.md](status/2026-09-29-state-of-the-system.md)). This is a working roadmap, not a commitment: items move when the owner rules on them. Nothing here is built unless it says so.
 
 ## Where things stand
 
-- **Live:** 29 tools (11 read-only); layer writes and reads native to MongoDB; server-side checks on session start and close (machine line on the first transcript append, blocked-close cap with scope, pending lessons at startup); receipts required at close; the handoff is a record, superseded and never amended.
+- **Live:** 30 tools (11 read-only); `EMET_SUBKEYS=1` adds four sub-key tools. Layer writes and reads native to MongoDB; server-side checks on session start and close (machine line on the first transcript append, blocked-close cap with scope, pending lessons at startup); receipts required at close; the handoff is a record, superseded and never amended.
 - **The aleph** verifies every write by reading it back before any receipt, and every later read by its digests, signature and place in its layer's hash chain. `emet_gaps` walks the whole chain for any host.
 - **Guardrails & Monorails** ([docs/GUARDRAILS-AND-MONORAILS.md](GUARDRAILS-AND-MONORAILS.md)): the server checks the order of a session's writes. Enforce only since 0.2.1 (deployed 2026-10-03; report mode 2026-09-29 to 2026-10-03): every skipped step is refused with the way to pass, and every check is stored as a timestamped lab result.
 - **The database** login runs under the least-privilege role `emetRecordKeeper`: it can insert and update, never remove the record.
 - **Startup load:** since 0.2.1, `emet_initialize` is served in pages of at most 18,000 bytes as received (on a live-sized store, five pages totalling about 68 KB as received, or about 64 KB whole), so a host that cuts long results short still reads all of it; `page: "all"` returns it whole on a host with no size limit.
+- **GEM standard:** drafted 2026-10-11, revision Draft. The socket seats bundled prompt GEMs. Neurendipity is installed at `gems/neurendipity` and off unless `EMET_ACTIVE_GEMS` names it. The text is in [`gem-library/`](../gem-library/README.md). Canonical home: private repository [EMET-GEMs](https://github.com/dreamforgestudiollc/EMET-GEMs).
 
 ## Next steps, in order
 
 1. **Monorail: enforce only** (decided and deployed 2026-10-03, release 0.2.1). Every skipped step is refused and the refusal says how to pass; there is no report mode or off switch. Every host and scheduled routine must now read its startup, open a session with its `load_id`, and pass the `session_id` on its writes.
 2. **Admission test on the proposed items.** Every proposed feature below answers the four questions of charter commitment 6 before it is built (2026-09-30 read: the compiled-pages pilot passes; the lint pass needs a named measure; hybrid search, graph links and confidence scores do not pass yet).
 3. **Initialize payload trim.** Character document trim; measure the payload again.
-4. ~~**Register or retire the `cloud-scheduled-intake` source tag.**~~ Retired 2026-10-02 (the owner, a decision record, item 7): it is a legacy tag; the weekly intake now runs under `intake-bot`, with no `session_id` on its writes; under enforce-only those writes are refused (`no_session`) until it opens a session with its startup's `load_id` (item 1). The existing rows keep counting as ambiguous in `emet_gaps` rather than being re-attributed, and the count stops growing as long as nothing new is written under the old tag. The prefix `cloud-scheduled-<task>` does not count as registered. Only an exact tag in `EMET_SOURCE_TAGS` is accepted, and a refusal does not publish the list.
-5. **Monorail switches.** Small logic at each junction where a session's flow must fork, routing it to the right guardrail space: tripped only by its condition, like a transistor; no hosted model, no API; each designed from the function it serves and the flow of information and tasking through it ([GUARDRAILS-AND-MONORAILS.md](GUARDRAILS-AND-MONORAILS.md), decided 2026-09-29). First candidate junctions come with the socket, where a switch picks the GEM.
-6. **The socket** — see below.
+4. ~~**Register or retire the `cloud-scheduled-intake` source tag.**~~ Retired 2026-10-02 (Alex, procedural ref 405 item 7): it is a legacy tag; the weekly intake now runs under `intake-bot`, with no `session_id` on its writes; under enforce-only those writes are refused (`no_session`) until it opens a session with its startup's `load_id` (item 1). The existing rows keep counting as ambiguous in `emet_gaps` rather than being re-attributed, and the count stops growing as long as nothing new is written under the old tag. The prefix `cloud-scheduled-<task>` does not count as registered. Only an exact tag in `EMET_SOURCE_TAGS` is accepted, and a refusal does not publish the list.
+5. **Monorail switches.** Small logic at each junction where a session's flow must fork, routing it to the right guardrail space: tripped only by its condition, like a transistor; no hosted model, no API; each designed from the function it serves and the flow of information and tasking through it ([GUARDRAILS-AND-MONORAILS.md](GUARDRAILS-AND-MONORAILS.md), decided 2026-09-29). A switch that picks a GEM waits for its own proposal. It is not one of the socket phases below.
+6. **The socket.** Phased plan under GEM socket, below. The standard is drafted. The socket, Neurendipity, and RUNED execution are in the tree. A RUNED GEM stays off unless the install names it. Activation beyond `EMET_ACTIVE_GEMS` is not.
 
 ## Done since the last revision (2026-09-28)
 
-- SQL translator stage 2: read path native to MongoDB; the translator and the `event` mirror column removed.
-- Test-tree pass: one shared harness; dated suites named by subject.
+- SQL translator stage 2: read path native to MongoDB; the translator and the `event` mirror column removed (commit-017c7f3).
+- Test-tree pass: one shared harness; dated suites named by subject (commit-7980e20).
 - Open questions answered 2026-09-29: the lessons `shadow` block dropped, the lesson key checked at the door; a coverage number published as an input to review; the character document consolidated quarterly (first pass done, SOUL.md v7).
-- Chain verification: one MongoDB connection path with a DNS fallback, then the chain walk moved into `emet_gaps` so no host needs the repo or a shell.
-- Security audit, first pass: two findings fixed; nothing open.
-- Least-privilege Atlas role, scripted and documented for new users.
-- Provenance stamped from the transcript; semantic and procedural writes with no source refused.
-- Guardrails & Monorails and lab results.
-- Charter revised 2026-09-29 (the aleph, the monorail, the database boundary, the per-exchange transcript) and again 2026-09-30 (the admission test in commitment 6).
+- Chain verification: one MongoDB connection path with a DNS fallback (6491586), then the chain walk moved into `emet_gaps` so no host needs the repo or a shell (commit-43a5ef6).
+- Security audit, first pass: two findings fixed; nothing open (commit-c2aa70d).
+- Least-privilege Atlas role, scripted and documented for new users (commit-26134e7).
+- Provenance stamped from the transcript; semantic and procedural writes with no source refused (commit-4f6aba8).
+- Guardrails & Monorails and lab results (commit-e7b4ebe through commit-20c39d3).
+- Charter revised 2026-09-29 (the aleph, the monorail, the database boundary, the per-exchange transcript; commit-d98356e) and again 2026-09-30 (the admission test in commitment 6; procedural ref 404).
 
 ## Proposed features and functions
 
-- **GEM socket (plug-in standard).** A GEM is a nested module inside EMET that modifies engagement; a RUNED GEM also carries tools (RUNEs). The socket must mount several GEMs, switch each on or off, and prioritise the active ones in a running schema that prevents conflicts — with a cap on sockets, a cap on active GEMs, and a priority order, because every active GEM costs the model context. Includes a developer guide for building one.
+- **GEM socket (phased).** GEM means Golem Expertise Module. A RUNED directive (Registered Utility Node Executable Directive) is a declared, registered tool built into a GEM. The 2026-09-08 expansions (Guided Engagement Module, Registered Utility Node Extension) are superseded. The standard, schema, authoring guide, conformance checks, and GEP-0001 are in [`gem-library/`](../gem-library/README.md), which moves to EMET-GEMs after this revision is approved.
+  - PR 2 (in the tree): `src/socket.js` and `gem-check` for a bundled prompt GEM (schema, spec revision, hashes, sizes, path safety, floor-negation lint, secret scan, no code), plus a conformance test. A refused GEM does not stop initialize.
+  - PR 3 (in the tree): `gems/neurendipity`. `reading_people`, the neurodivergent lines, the wellbeing corpus lines, the matching reassertion lines, and the guide (the old id aliases for one release). Default off. Set `EMET_ACTIVE_GEMS=neurendipity` to turn it on. Core floor keeps persistence, general epistemic honesty, the epistemic corpus lines, and the honesty protections. `emet_floor` takes a `gem` argument. The available list shows Neurendipity installed and off unless that setting names it.
+  - PR 4 (proposed): each GEM's byte cost in `emet_status` (`gems`: installed and active counts, active floor bytes, headroom, the enforced caps, and per-GEM id, version, kind, bytes and refusal reason; read-only, no floor text). Caps, priority, consent when `overrides` is non-empty, and the available list in the startup text are already enforced. `EMET_ACTIVE_GEMS` is how an install asks for a GEM.
+  - PR 5 (in the tree): RUNED registration through dispatch, static analysis, and `gems/fieldnote`, bundled and off by default. No GEM from outside the release loads. GEP-0003 supersedes the GEP-0002 sandbox: the sandbox is removed, and the socket serves each RUNE and does not run it.
+  - Later, each by its own GEP: the creator keyring and signature checks, the public submission repository and its CI gate, accepting a library GEM onto the load list, and a monorail switch that picks a GEM.
 - **Claim-status grading.** Extend provenance so every recorded claim carries a status: established, deduced, proposed, still owed, or rejected — and rejected routes stay on the record with the reason they failed. (Idea taken from a physics research corpus that grades its own claims this way.)
 - **Index-first retrieval.** Score candidates against a one-line-per-item index before opening anything, open only the best match, follow one link at most — finding is logic, not a model call. EMET already has the shape (handoff and board as router, document list as index); the work is keeping the startup router small.
 - **Composite retrieval scoring.** Live as of this revision: recall ranks by how many query words match, then by importance. Current entries come first in every order, including time order. Time order is `order: 'latest'`, or a standalone latest, newest, or most recent together with other words. That phrase only reorders rows that already match. Nothing fades or is down-weighted for age. A superseded or expired entry stays in the result, marked with its end date and what replaced it. `history: true` reads the ended entries when current ones fill the limit. A recall or layer query ranks matching rows in the store (current before ended, then keyword hits and importance, or time when you asked for the latest) and then keeps a bounded window (at least 200 rows, or 20 times the page), not the whole layer. A blank sort value comes first when ascending and last when descending.
 - **Export, import, restore-and-compare.** Not built; listed in the README's known gaps.
 - **Organizational use.** Many private EMETs and a document gateway between them. Nothing built before a named customer.
-- **Shared hive memory for AI bots (proposed 2026-09-30).** One EMET as a common memory that several agent bots read and write as users, each keeping its own memories — candidates are Grok Bot, OpenAI dots and Meta Muse, all of which can reach a remote MCP server. A GEM per bot, seated in the socket, if needed. Taken up with the socket; the first design question is each bot's source tag and scope.
-- **Compiled topic pages, pilot (proposed 2026-09-30).** After the LLM-wiki pattern: a document prefix of topic pages compiled from semantic entries. Every claim cites its entry or transcript span; a compiled page never cites another compiled page as evidence; pages are derived, never the source of truth; one compiler role builds pages, others write entries only. No database change — the document store already versions, hashes, signs and checks form. Pilot page: the hive-memory idea. Nothing added beyond what the pilot needs.
+- **Shared hive memory for AI bots.** Closed as a separate item on 2026-10-11. Folded into the GEM socket work above. A bot that shares one EMET still needs its own source tag and scope. That question stays with the socket.
+- **Compiled topic pages, pilot (proposed 2026-09-30).** After the LLM-wiki pattern: a document prefix of topic pages compiled from semantic entries. Every claim cites its entry or transcript span; a compiled page never cites another compiled page as evidence; pages are derived, never the source of truth; one compiler role builds pages, others write entries only. No database change. The document store already versions, hashes, signs and checks form. Pilot page: the hive-memory idea. The hive-memory feature is closed as its own item (2026-10-11) and folded into the socket. If this pilot is built, it needs a different page. Nothing added beyond what the pilot needs.
 - **Lint pass over the semantic layer (proposed 2026-09-30).** A scheduled sweep for contradictions between entries, outdated claims a newer entry supersedes, entries that should link and don't, and subjects mentioned often with no compiled page. Findings are reported, never applied automatically; corrections go through supersession. Built after the pilot page, and only once it names its measure. Design inputs from the LLM Wiki v2 review (typed links, multi-agent sync rules, drift invariants, confidence only on top of provenance) are each weighed against commitment 6 before adoption. Its idea of letting entries fade from what surfaces is not taken: nothing in EMET fades.
 - **Advisory judge for team traffic (parked).** A fast external decision model (TypeSafe's Jev was evaluated) could sort traffic and interactions when many people and hosts share one EMET. Never in the write path — no model decides what EMET stores. Not for single-user installs.
 - **Local open-weight model as a host.** A read-only trial of EMET under a locally run model, once the host machine's GPU and RAM are on record.
@@ -50,10 +56,7 @@ Status as of 2026-10-07. This is a working roadmap, not a commitment: items move
 
 ## Design commitments these must keep
 
-- No model in the write path: EMET stores only what the assistant deliberately chose to write.
-- Controls, not reminders: a rule that matters is checked by the server.
-- Over-engineering is a defect, and the check comes before the build. Nothing is built until it
-  names the failure it fixes, what it replaces, how we will know it worked, and what keeps it
-  working (charter commitment 6). While EMET is in design it follows DMADV (define, measure,
-  analyze, design, verify); once stable, DMAIC (define, measure, analyze, improve, control).
+- No model in the write path: EMET stores what the assistant deliberately chose to write.
+- Controls, not reminders — a rule that matters is checked by the server.
+- Over-engineering is a defect, and the check comes before the build: nothing is built until it names the failure it fixes, what it replaces, how we will know it worked, and what holds it once it works (charter commitment 6). DMADV while EMET is in design; DMAIC once stable.
 - Correct the record by superseding, never by editing.

package/docs/SETUP.md

@@ -153,13 +153,19 @@ have to. A new store returns a short interview; an established one returns the a
 identity, your profile, and recent context. Requiring a command would have been backwards —
 the one session you would need it is the first one, before you have read any of this.
 
-The interview asks six things, four required and two optional:
+The interview asks eight things, four required and four optional:
 
 - **What the assistant should be called**, and **how it should carry itself.** This becomes
   the identity it speaks from in every session on every host.
 - **Your name**, in the form you actually want used.
 - **What you are using this memory for**, which shapes what gets treated as worth saving.
-- Optionally: how you want to be worked with, and this host's source tag.
+- Optionally: how you want to be worked with, this host's source tag, and whether more than
+  one bot or AI will use this memory. Leaving that one out leaves sub-keys off. The
+  walkthrough is [SUBKEYS.md](SUBKEYS.md).
+- Optionally: whether to turn on bot-team backup. **Yes is the recommended choice.** Yes and
+  Yes. count as yes, the same way as the multi-bot question. No, or leaving it out, leaves it
+  off. The answer is recorded. EMET does not copy prompts or
+  settings itself, and secret values are never stored. The recipe is `gems/bot-team-backup/guides/BOT_TEAM_BACKUP.md`.
 
 Your assistant asks these conversationally, one at a time — not as a form — then calls
 `emet_setup_complete`.

package/docs/SUBKEYS.md

@@ -0,0 +1,59 @@
+# When more than one bot uses EMET
+
+One EMET. One owner login. If more than one bot or AI writes through that login, each bot that can keep a key file gets its own key. The server stamps the tag on the key. A bot does not get to name another bot's tag and have that stamp stick.
+
+This is part of EMET. It is the same server, the same owner page, and the same keys. It is not a second product, and it is not a fork.
+
+The Charter and the floor are unchanged. This supports ISO 9001:2015 clause 7.5.3 and ISO 13485:2016 clause 4.2.5 (identification of who changed a record, retention of records, nothing deleted), as the README and the Charter word it. EMET claims no certification. The organization validates EMET for its own use.
+
+## Turn it on
+
+Say **initialize**. Your assistant asks whether more than one bot or AI will use this memory. Answer in your own words. Leaving it out is the same as no.
+
+- **No.** Sub-keys stay off. That one client uses its own source tag. The tool list does not grow.
+- **Yes, and this server reads a `.env` file.** Setup writes three settings into that file after your identity is saved: sub-keys on, a pepper the server generates, and version 1. You do not type the pepper, and it is not repeated. Restart (or redeploy) the server once. The tools and `/owner/approvals` appear together after that restart. They do not turn on in the server that is already running.
+- **Yes, and the server takes its settings from the platform** (Railway or anything else that injects environment variables). Setup refuses before it saves anything. No pepper or .env was written. Run setup again without yes to finish the rest. Then set these in the platform's variables and redeploy:
+  1. `EMET_SUBKEYS=1`
+  2. `EMET_SUBKEY_PEPPER` — generate it yourself, at least 32 bytes, for example with `openssl rand -hex 32`
+  3. `EMET_SUBKEY_PEPPER_VERSION=1`
+
+  Do not paste the pepper into the chat or into any EMET document.
+
+A single client does not get this turned on. The page and the tools ship with EMET. They stay quiet until the answer is yes and the server has restarted with the flag on.
+
+If this memory is already set up and you later add bots, say so. Your assistant turns sub-keys on only after you explicitly agree to run setup again. That writes a new version of your identity documents. The previous version is kept.
+
+## Approve a bot
+
+List each bot's tag in `EMET_SOURCE_TAGS` before it asks for a key. An empty list refuses every request.
+
+1. Open `/owner/approvals` on the same host you already use for this memory. Enter the passphrase you already use when you connect a device. A correct passphrase opens a short session. A wrong one is counted with the other passphrase attempts.
+2. Each bot that can keep a key file asks for a key with its own tag.
+3. On the approvals page, approve that request. Deny applies only to a pending request.
+4. The bot claims the key within 24 hours. It keeps the key where the other bots cannot read it. The key is never written into EMET.
+
+A bot then opens a session with that key and passes the session handle the server gives back on later writes in that session.
+
+## A key lasts 30 days
+
+To renew a key, the bot asks again with the same tag, you approve it on the page, and the bot claims the new key within 24 hours. The previous key works for a few minutes while the bot switches, then it stops. Earlier writes stay as they were written.
+
+## Revoking your login
+
+Revoking the owner login stops every sub-key. The keys hang off that login. They do not keep working after it is gone.
+
+## A phone, or a web project
+
+A host that cannot store a key file does not take a sub-key. A phone, or a web project instance, uses the tag on its own connection.
+
+## Security
+
+The pepper is a server secret. When this server reads `.env`, setup writes that file and does not put the pepper in the database, in a document, or in the answer it gives your assistant. An MCP call is what writes the file, and only on that kind of server. A hosted server does not get a pepper written into its container.
+
+The approvals page uses the same passphrase as connecting a device, and a wrong passphrase counts toward the same lockout.
+
+What a sub-key shows is that a write was made with a key you approved. If several bots can read each other's files, EMET cannot prove which program was holding the key. If you think an active key has leaked, revoke it from your own login (`emet_subkey_revoke`), then the bot requests a new key and you approve it on the page. Deny only applies to a pending request.
+
+## Building a bot team
+
+For designing a team of bots, see Lauren Tan (@poteto, https://x.com/poteto), who works on Grok Bot and describes choosing a bot topology (one generalist, several narrow specialists, or generalists each owning a project) in [this post](https://x.com/poteto/status/2109781899610874002). Her bot designer, [dr eggbot](https://x.ai/bot/93gOz3op1UQdBdbekQFLK) ([source](https://x.com/poteto/status/2106895160298852470)), helped design the EMET author's own bot team.

package/gems/artifact-index.json

@@ -0,0 +1,12 @@
+{
+  "sha256:c9f58a0ef18f7468b9618d0f1e96ddd8c50845243e098e84480908ca8cb0a528": {
+    "gem": "fieldnote",
+    "rune": "fieldnote",
+    "version": "1.0.0"
+  },
+  "sha256:cfb62b669f67c69f53989ed2621a40bfbfa60a744f1b4040e5b8496755598a35": {
+    "gem": "fieldnote",
+    "rune": "fieldnote",
+    "version": "1.0.1"
+  }
+}

package/gems/bot-team-backup/floor.json

@@ -0,0 +1,15 @@
+{
+  "sections": {
+    "bot_team_backup": {
+      "title": "Bot-team backup",
+      "note": "Optional. Off unless the recorded setup answer is yes. This floor does not copy documents by itself.",
+      "lines": {
+        "follow_the_recipe": "When bootstrap/USER.md records bot-team backup as yes, follow guides/BOT_TEAM_BACKUP.md. Write each bot's name, prompt, settings, routines and skills to bot-team/<bot>.md. Revise a document only when it changed. Supersede; do not delete.",
+        "no_secrets": "Never store secret values, tokens, passwords or card data in a bot-team document. Connectors, logins and secrets are reconnected by hand. Name those items in bot-team/RECOVERY.md. Do not write the values."
+      }
+    }
+  },
+  "reassertion": [
+    "Bot-team backup stores no secret values."
+  ]
+}

package/gems/bot-team-backup/gem.json

@@ -0,0 +1,43 @@
+{
+  "spec": "2026-10-12",
+  "id": "bot-team-backup",
+  "name": "Bot-team backup",
+  "description": "Optional recipe for writing each bot's name, prompt, settings, routines and skills as controlled documents. Off unless the recorded setup answer is yes. Does not store tokens, passwords or card data.",
+  "version": "1.0.0",
+  "kind": "gem",
+  "requires": {
+    "emet": ">=0.2.6"
+  },
+  "priority": 10,
+  "defaultOn": false,
+  "released": true,
+  "overrides": [],
+  "distribution": "bundled",
+  "floor": "floor.json",
+  "guides": [
+    "guides/BOT_TEAM_BACKUP.md",
+    "guides/BOT_TEAM_RECOVERY.md"
+  ],
+  "runes": [],
+  "files": [
+    {
+      "path": "floor.json",
+      "digest": "sha256:7182ec1d78bed4234c9a309bd03b4ca4099fa3b031e6b743d554378862230862",
+      "size": 802
+    },
+    {
+      "path": "guides/BOT_TEAM_BACKUP.md",
+      "digest": "sha256:aa912c28c08745e4cde13d156488af94a74745573e7d184a10007ee453de2d12",
+      "size": 1384
+    },
+    {
+      "path": "guides/BOT_TEAM_RECOVERY.md",
+      "digest": "sha256:8fbccbc7985c2e1696c42293c73c1257e2fbf9548717b19a8086306b2ed0db0e",
+      "size": 1305
+    }
+  ],
+  "authors": [
+    "Dreamforge Studio LLC"
+  ],
+  "license": "MIT"
+}

package/gems/bot-team-backup/guides/BOT_TEAM_BACKUP.md

@@ -0,0 +1,27 @@
+# Bot-team backup
+
+Optional. Off unless the first-run answer recorded in `bootstrap/USER.md` under BOT-TEAM BACKUP is `yes`. Yes is the recommended choice. Leaving the question out records `no`.
+
+EMET does not run this recipe. The assistant does, and only after that recorded yes.
+
+## What to write
+
+For each bot the install uses, keep one controlled document at `bot-team/<bot>.md`. Use the bot's own tag as `<bot>`, the same tag its writes already carry. The document holds:
+
+- the bot's name
+- the prompt it runs with
+- the settings that are not secret
+- the routines it follows
+- the skills it uses
+
+Write the document through the normal document tools. A later change is a new revision of the same id. Do not delete the previous copy. If nothing changed since the last revision, do not write again.
+
+Check on a steady cadence the install chooses, such as at session close, and only write when the text would differ.
+
+## What never goes in
+
+Never store secret values, tokens, passwords or card data. Not in `bot-team/<bot>.md`, not in `bot-team/RECOVERY.md`, and not in any other bot-team document. A name of a connector or a login is not a secret. The value behind it is.
+
+## Recovery
+
+Keep the rebuild order in `bot-team/RECOVERY.md`, filled from `guides/BOT_TEAM_RECOVERY.md`. That document lists what a person must reconnect by hand. It does not store the secrets themselves.

package/gems/bot-team-backup/guides/BOT_TEAM_RECOVERY.md

@@ -0,0 +1,23 @@
+# Bot-team recovery
+
+Copy this into the store as `bot-team/RECOVERY.md` when bot-team backup is on. Revise it when the rebuild order changes. Supersede; do not delete.
+
+Never store secret values, tokens, passwords or card data here. Name the item that has to be reconnected. Leave the value out.
+
+## Rebuild order
+
+1. Restore the memory server and its database from the operator's own backup of that service.
+2. Read `bot-team/<bot>.md` for each bot and put back that bot's name, prompt, settings, routines and skills.
+3. Reconnect, by hand, every item in the list below. The documents do not contain what those items need in order to authenticate.
+
+## Reconnect by hand
+
+| Item | Where it lives | What the person does |
+|---|---|---|
+| Connectors | The host's connector settings | Connect each one again. The document may name the connector. It must not hold a key. |
+| Logins | The host account for each bot | Sign in again. The document may name the account. It must not hold a password. |
+| Secrets | The host's secret store | Put each secret back from the place the operator keeps secrets. This document names the slot, not the value. |
+
+## Rule
+
+If a value is a token, a password, a card number, or any other secret, it does not belong in EMET. Record that the item must be reconnected. Stop there.

package/gems/fieldnote/floor.json

@@ -0,0 +1,14 @@
+{
+  "sections": {
+    "field_notes": {
+      "title": "Field notes",
+      "note": "A count of the working layer is a note about what is already stored. It does not add a store.",
+      "lines": {
+        "count_only": "Report the count. The count is not a list, and it is not a new record."
+      }
+    }
+  },
+  "reassertion": [
+    "The working layer is memory, and a count is not a new store."
+  ]
+}

package/gems/fieldnote/gem.json

@@ -0,0 +1,70 @@
+{
+  "spec": "2026-10-12",
+  "id": "fieldnote",
+  "name": "Fieldnote",
+  "description": "A reference RUNED directive. Counts rows the caller passes in. Off unless the install asks for it.",
+  "version": "1.0.1",
+  "kind": "runed-gem",
+  "requires": {
+    "emet": ">=0.2.4"
+  },
+  "priority": 40,
+  "defaultOn": false,
+  "overrides": [],
+  "distribution": "bundled",
+  "floor": "floor.json",
+  "guides": [],
+  "runes": [
+    {
+      "name": "fieldnote",
+      "description": "Count the rows the caller passes in. A call returns this code and does not run it.",
+      "execution": "client",
+      "artifact": "runes/fieldnote.js",
+      "sha256": "sha256:cfb62b669f67c69f53989ed2621a40bfbfa60a744f1b4040e5b8496755598a35",
+      "version": "1.0.1",
+      "runtime": "node",
+      "inputSchema": {
+        "type": "object",
+        "properties": {
+          "rows": {
+            "type": "array",
+            "description": "Working-layer rows the caller already read."
+          }
+        }
+      },
+      "outputSchema": {
+        "type": "object",
+        "properties": {
+          "count": {
+            "type": "integer"
+          }
+        }
+      },
+      "annotations": {
+        "readOnlyHint": true,
+        "destructiveHint": false,
+        "idempotentHint": true,
+        "openWorldHint": false
+      },
+      "reads": [],
+      "writes": [],
+      "network": "none"
+    }
+  ],
+  "files": [
+    {
+      "path": "floor.json",
+      "digest": "sha256:11af3724b165beb3e9a49a681f1f07cb742bcb4535206f714a0dc689067f32d6",
+      "size": 403
+    },
+    {
+      "path": "runes/fieldnote.js",
+      "digest": "sha256:cfb62b669f67c69f53989ed2621a40bfbfa60a744f1b4040e5b8496755598a35",
+      "size": 147
+    }
+  ],
+  "authors": [
+    "Dreamforge Studio LLC"
+  ],
+  "license": "MIT"
+}

package/gems/fieldnote/runes/fieldnote.js

@@ -0,0 +1,4 @@
+export default function fieldnote(input) {
+  const rows = input && Array.isArray(input.rows) ? input.rows : [];
+  return { count: rows.length };
+}

package/gems/lean-six-sigma/CHANGELOG.md

@@ -0,0 +1,10 @@
+# Changelog
+
+## 0.9.0
+date: 2026-10-20
+class: initial
+what changed and why: Pre-release 0.9.0. requires.emet is >=0.2.6. Rune files are unchanged.
+init time: before none, after unmeasured
+test time: before none, after unmeasured
+log noise: before none, after unmeasured
+byte cost: before none, after 1790