@dreamforgestudiollc/emet 0.0.0-stage → 0.2.6

package/docs/SETUP.md

@@ -0,0 +1,265 @@
+# Setting up EMET
+
+From nothing to a working memory your assistant can use, on every device you own.
+
+There are three stages and they must happen in order: **a database**, **a server**, **an
+identity**. The first two are plumbing. The third is the one people skip, and it is the one
+that decides whether the thing is useful.
+
+**If you would rather not do the plumbing yourself,** [GUIDED-SETUP.md](GUIDED-SETUP.md) is
+the same three stages carried out by your assistant, with you signing in when asked. This
+page is the manual walkthrough and the reference the guided path points back to.
+
+---
+
+## Stage 1 — MongoDB Atlas
+
+EMET stores everything in MongoDB. The Atlas free tier is enough to start.
+
+**Trying it on one machine first?** A local MongoDB (version 6 or later) works for everything
+except `semantic_recall`, which needs an Atlas vector index (step 7). Set
+`MONGODB_URI=mongodb://127.0.0.1:27017/`, skip steps 1–4 and 7, and go to Stage 2. The
+`emetRecordKeeper` role (step 2) is still worth creating on a local server that has users
+enabled, by hand with `db.createRole`; `scripts/atlas-role.mjs` is for Atlas only. Use Atlas
+when you want a second device to reach the same memory.
+
+1. **Create a cluster.** <https://cloud.mongodb.com> → new project → **Create** a cluster.
+   Any region near you. Note the cluster name.
+
+2. **Create a database user for EMET, and give it EMET's own role.** Database Access →
+   Add New Database User. Authentication: password. Username e.g. `emet_app`.
+
+   EMET keeps its record — it never deletes a memory, a document or a transcript. Give the
+   server a login that *cannot* delete them either, so the rule holds at the database and
+   not only in the code. The role is **`emetRecordKeeper`**, defined once in
+   `src/atlas-role.js`:
+
+   | On | Allowed |
+   |---|---|
+   | your whole EMET database | find, insert, update, create collection, create index, list collections, list indexes, list search indexes, collection and database stats |
+   | `<prefix>oauth_tokens` | remove — revoking a sign-in token |
+   | `_emet_verify` | remove — the status check deletes its probe document and does not drop the collection |
+
+   Nothing else may be removed or dropped. `tests/atlas-role.test.js` fails if the code ever
+   starts deleting from a collection this role does not allow.
+
+   **The quick way (Atlas CLI).** Install it (`winget install MongoDB.MongoDBAtlasCLI`, or
+   see mongodb.com/docs/atlas/cli), sign in with `atlas auth login` in your own terminal —
+   it asks you to pick options, so it needs a real keyboard — then from the EMET folder:
+
+   ```
+   node scripts/atlas-role.mjs --project <projectId> --db <database> --user emet_app
+   ```
+
+   That is a dry run: it prints the commands. Add `--apply` to create the role and move the
+   user onto it; `--rollback` puts the user back on `readWrite@<database>`. Find the project id
+   with `atlas projects list`. A non-default `EMET_COLLECTION_PREFIX` is picked up, or pass
+   `--prefix`.
+
+   **The click way.** Database Access → Custom Roles → Add New Custom Role, name
+   `emetRecordKeeper`, add the actions in the table above against your database and the two
+   collections; then edit the user and set its role to `emetRecordKeeper`.
+
+   **Prove it.** From any EMET host, run `emet_status` with `probe: true`. It writes, reads
+   back and removes a test document, so a role missing something fails there, loudly, instead
+   of in the middle of a session.
+
+   - Do *not* grant cluster-wide admin, and do not use this login for maintenance. A one-off
+     job that must delete (a migration, a corpus rebuild) gets its own login, used and then
+     removed.
+
+3. **Network access.** Network Access → Add IP Address.
+   - Local use only: add your own IP.
+   - Deploying to Railway or similar: the egress IP is dynamic, so `0.0.0.0/0` is the
+     practical option. Security then rests on the scoped user and the OAuth passphrase —
+     both are required, and neither is optional.
+
+4. **Get the connection string.** Connect → Drivers → copy the `mongodb+srv://...` URI and
+   substitute your user and password. This goes in `MONGODB_URI` and **never** into git.
+
+5. **Pick a database name** and set `MONGODB_DB`. It defaults to `emet`. Collections (`emet_episodic`, `emet_semantic`, …) are
+   created on first write — there is nothing to pre-create.
+
+6. **One database per EMET instance.** The document store (`documents`,
+   `documents_history`) is deliberately *not* prefixed, so two instances pointed at the same
+   database will share their identity and continuity documents even if their memory
+   collections use different prefixes. If you want two separate memories, give them separate
+   databases - not just separate prefixes.
+
+7. **Vector index — only if you want `semantic_recall`.** Keyword search works without it.
+   For meaning-based search, create an Atlas Vector Search index named
+   `emet_content_auto` on the `emet_semantic` collection, path `content`, using
+   Atlas Automated Embedding. Repeat per layer collection you want searchable.
+   ⚠ **Atlas tier migrations can silently drop search indexes created mid-migration.**
+   After any tier change, re-check that the index still exists.
+
+---
+
+## Stage 2 — run the server
+
+EMET runs two ways from one codebase. Most people want both eventually: local for speed,
+remote so the phone can reach it.
+
+### Local (stdio) — desktop and CLI
+
+```
+npm install
+npm test                    # optional: no database or credentials needed
+cp .env.example .env        # fill in MONGODB_URI at minimum
+npm start
+```
+
+`.env` is read automatically from the repo root. Real environment variables win over it,
+so a hosted deployment that sets them directly is unaffected by a stray local file.
+
+`npm start` prints its startup log and then waits, silently, for an MCP client on standard
+input; that is normal. Stop it with Ctrl-C. Day to day you do not run it by hand: your MCP
+client starts it from the entry below.
+
+Then point your MCP client at it:
+
+```json
+{ "mcpServers": { "emet": {
+    "command": "node",
+    "args": ["/absolute/path/to/emet/src/index.js"],
+    "env": { "MONGODB_URI": "mongodb+srv://...", "MONGODB_DB": "emet", "EMET_SOURCE_TAG": "laptop" }
+} } }
+```
+
+### Remote (HTTP + OAuth) — phone, tablet, anything else
+
+See **[DEPLOY.md](DEPLOY.md)** for the Railway walkthrough. Short version: deploy
+`src/http-remote.js`, set the environment variables, and add the resulting
+`https://<host>/mcp` URL as a custom connector in your client.
+
+### Set a distinct source tag on every host
+
+Every write records which host produced it. A local entry, which serves one host, sets that
+host's tag with `EMET_SOURCE_TAG`, as in the example above. A remote server several hosts
+share leaves `EMET_SOURCE_TAG` unset, and each host passes its own tag as `source` on its
+writes: a shared default makes every host look the same, and you will have entries you cannot
+attribute. `laptop`, `phone`, `cli`, `work-desktop`. One each.
+
+---
+
+## Stage 3 — the setup interview
+
+This is the part that turns a database into a memory.
+
+**Say "initialize".** There is no setup command to memorize.
+
+Your assistant calls `emet_initialize`, which branches on the state of the store so you do not
+have to. A new store returns a short interview; an established one returns the assistant's
+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 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, 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`.
+
+Three behaviours worth knowing:
+
+- **It refuses to finish on partial answers** rather than filling in the gaps itself. An
+  invented identity is worse than no identity.
+- **Re-running is safe.** Documents are versioned and the previous copy is archived to
+  `documents_history`. Nothing is overwritten in place, ever.
+- **If the store is unreachable, initialize says so** instead of continuing as though memory
+  were available. A confident assistant with no memory and no warning is the worst outcome.
+
+What gets written: `bootstrap/IDENTITY.md` and `bootstrap/USER.md` in the document store, plus
+an entry in the `identity` layer. All three are read-back verified before setup reports
+success. Edit any of them later with `write_doc` — same versioning applies.
+
+**The supporting tools**, which you should not normally need:
+
+| Tool | What it does |
+|---|---|
+| `emet_status` | Diagnostic: environment, database, collections, vector index, whether identity and user documents exist, per-layer counts and health. With `probe: true` it also connects, pings, **writes a probe and reads the same value back**, then removes it — a read alone will not reveal a broken write path. |
+| `emet_setup_complete` | Records the answers, read-back verified, and creates the owner person. The owner's only: refused under a bot tag, and refused on a store that is already set up unless `reissue: true` is passed. |
+
+## Migrating an existing CASCADE deployment
+
+If you are already running upstream CASCADE against a MongoDB store, EMET reads it in
+place. **Nothing needs to be renamed, copied, or migrated** - point the new build at your
+existing names and every memory, document, transcript and OAuth token stays exactly where
+it is.
+
+| Variable | Set it to | Why |
+|---|---|---|
+| `MONGODB_DB` | your existing database | EMET defaults to `emet`; yours is probably something else |
+| `EMET_COLLECTION_PREFIX` | `cascade_` | your layer collections are `cascade_episodic`, etc. |
+| `EMET_VECTOR_INDEX` | `cascade_content_auto` | the Atlas Vector Search index `semantic_recall` uses |
+| `EMET_CORPORA` | your corpus names, comma-separated | only if you use `corpus_recall`; leave unset otherwise |
+
+`EMET_COLLECTION_PREFIX` also governs the counters collection and the three OAuth
+collections, so **devices you have already authorized stay authorized** - there is no
+re-consent step.
+
+Your old `CASCADE_SOURCE_TAG` and `CASCADE_OAUTH_PASSPHRASE` continue to work; the `EMET_`
+forms take precedence if both are set. New installs should use the `EMET_` names only.
+
+**The server guards against getting this wrong.** If it is configured for a prefix that sees
+zero memories while the same database holds populated collections under a different one,
+`emet_initialize` returns `state: "misconfigured"` instead of `ready` or `setup_required`, and
+refuses to offer the setup interview. This matters because the failure is otherwise silent:
+the document store is unprefixed, so a mismatched server still finds your identity and comes
+up looking healthy - correct name, correct profile, and an empty memory. It reports the
+prefixes it found and how many entries are under them.
+
+**Verify before trusting it.** Run `emet_status` and confirm the layer counts match
+what you had, and that `vector_index` reports the index you expect. Then `emet_initialize` -
+it should come back `ready` with your existing identity, not `setup_required`. If it says
+`setup_required`, one of the four variables above is wrong; **do not run the setup interview,
+which would write a new identity over your existing one.**
+
+## Stage 4 — tell your assistant to use it
+
+Setup gives the store an identity. It does not tell your assistant to consult it. See
+**[BOOTSTRAP.md](BOOTSTRAP.md)** for the short instruction block to paste into your project,
+and for what to expect on hosts that offer no instructions field.
+
+## Verifying it worked
+
+```
+emet_status              → initialized: true (false until the setup interview is done)
+emet_status probe:true   → every probe check passed
+emet_session_open        → a session_id
+save_to_layer            → with that session_id, then recall it from a different device
+```
+
+Ask your assistant to remember something and it makes these calls. A `semantic` or
+`procedural` save without a `session_id` (or a `derived_from`) is refused by design: those
+layers must name the conversation they came from.
+
+That last one is the real test. Write from your laptop, read from your phone. If both see it,
+the thing is doing its job.
+
+---
+
+## When it does not work
+
+| Symptom | Cause |
+|---|---|
+| `MONGODB_URI is not set` | No `.env`, or the process was started without it. |
+| `source tag "..." is not registered` | The tag is missing from `EMET_SOURCE_TAGS`. Add it, then restart. |
+| `a source tag is required` on `emet_transcript_append` | Transcript appends always name their host: pass `source` (a registered tag) on the call. |
+| `semantic entries must carry their source` | Open a session with `emet_session_open` and pass its `session_id` on the save. |
+| `vector_index: not queryable on this deployment tier` | Normal on a local MongoDB or before the Atlas index exists; only `semantic_recall` needs it. |
+| Connect times out | Your IP is not in Atlas Network Access, or the cluster is paused. |
+| Auth fails | The password in the URI needs percent-encoding if it contains `@ : / ?` etc. |
+| `semantic_recall` returns nothing, keyword search works | The vector index is missing or was dropped by a tier migration. |
+| Writes land but another device cannot see them | The two hosts point at different `MONGODB_DB` values. |
+| Entries all carry the same source | A server several hosts share has `EMET_SOURCE_TAG` set, so every write that passes no `source` gets that default, or two local entries use the same tag. Unset it on the shared server and have each host pass its own `source`. |

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

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

@@ -0,0 +1,92 @@
+DMAIC and DMADV guidance, blank templates, and formulas with worked examples for hand calculation. Capability calculator. DPMO and yield calculator. Control limit calculator. Sample size calculator. Basic statistics calculator. Off unless the user asks.
+
+DMAIC and DMADV guidance, blank templates, and formulas with worked examples for hand calculation.
+Define phase steps
+Measure phase steps
+Analyze phase steps
+Improve phase steps
+Control phase steps
+Define tollgate
+Measure tollgate
+Analyze tollgate
+Improve tollgate
+Control tollgate
+DMADV and DFSS note for a new design
+DMADV Define tollgate
+DMADV Measure tollgate
+DMADV Analyze tollgate
+DMADV Design tollgate
+DMADV Verify tollgate
+Wastes walk
+5S
+Value stream map
+Flow
+Pull
+Kaizen
+SMED
+Poka-yoke
+Project charter template
+SIPOC template
+VOC and CTQ tree template
+Data collection plan template
+MSA and Gage R&R plan template
+Fishbone template
+Five Whys template
+FMEA template
+Hypothesis test selection guide
+DOE planning template
+Control plan template
+Response plan template
+A3 template
+Tollgate checklists
+Financial benefits worksheet
+DPMO and DPO worked example
+Opportunity yield worked example
+First pass yield worked example
+Rolled throughput yield worked example
+Sigma level convention and the hand DPMO path
+Cp worked example
+Cpu worked example
+Cpl worked example
+Cpk worked example
+Pp worked example
+Ppk worked example
+Sigma from average range worked example
+X-bar and R limits worked example
+Individuals and moving range limits worked example
+p chart limits worked example
+np chart limits worked example
+c chart limits worked example
+u chart limits worked example
+Sample size for a proportion worked example
+Sample size for a mean worked example
+Known-sigma confidence interval worked example
+Confidence interval with a caller-supplied t worked example
+One-sample t statistic worked example
+Chi-square goodness of fit worked example
+One-way ANOVA worked example
+Simple linear regression worked example
+Takt time worked example
+OEE worked example
+Little's Law worked example
+FMEA RPN worked example
+Yellow Belt scope
+Green Belt scope
+Black Belt scope
+Coaching questions
+Statistical assumption flags
+Work one DMAIC phase at a time
+Keep an unanswered tollgate item open
+Ask for data and leave a blank field blank
+Report a number the user supplied and leave every other numeric claim unstated
+Name statistical assumptions that were not checked
+Ask the belt for this project and do not certify one
+Open the DMADV note when the work is a new design
+Keep project data in this install
+Write a project document only when the user asks to save it
+Leave the memory layers unread and unwritten for this project
+Capability calculator
+DPMO and yield calculator
+Control limit calculator
+Sample size calculator
+Basic statistics calculator