# MORIverse pipeline protocol

This is how MORI, Grok and Shawn work on one build. It is written to be short. Shawn reads only "Needs Shawn".

## 0. The honest setup
- **Published collaboration snapshot:** `/2d/pipeline/pipeline.json`. MORI updates it on every deploy. The canonical repository records implementation, native deployment receipts establish publication, and device observations establish behavior. This snapshot and COLLAB.md summarize those records; neither replaces their evidence.
- **No shared server yet.** The terminal (`index.html`) and the mind map (`mindmap.html`) save only to the device you're on (localStorage). To share, tap **Export update**, paste the text into the "MORI x Grok workbench" chat, and the other side taps **Import**.
- Real-time two-way updates need a server. That's **stage 2**. Until then nothing here pretends to sync.
- If `pipeline.json` and the live site disagree, **the live site wins**. The next entry records the correction.

## 1. Handoff header (on top of every message in the workbench chat)
```
FROM: mori | grok | shawn
DATE: 2026-10-22T19:30Z
LIVE: v145 (what the host shows right now, checked, not remembered)
FILES: what changed, as paths
ASKS: for MORI / for Grok / for Shawn (money, publishing, vision only)
```
The terminal's **Export update** writes this header for you.

## 2. Versions
- One shared build. Every deploy gets a new version, for example v146.
- Every change to `pipeline.json` raises `rev` by 1 and adds a `changelog` line: date, by, version, text.
- `live.version` identifies this bundle's release. In a frozen candidate it is a release marker, with `confirmed: false`, and matches `release.expectedVersion`. It is not a claim that an allocated version has already been published.
- `release.lastConfirmed` retains the last actually observed successful native deployment. A static bundle cannot contain the later receipt confirming its own publication. After success, MORI's workbench export and COLLAB.md carry the new native receipt; the next release carries that observation forward. The terminal labels the build marker and verified receipt separately.
- Before each deploy, run `scripts/maintain-pipeline.mjs --stage` with the actual prior receipt, intended version and one plain changelog summary. This raises `rev` exactly once for the handoff. Rebuilding that candidate does not raise it again.
- If new work or a workbench observation arrives before the candidate's first native SAVE, preserve those complete records and use `--amend` with the same successful prior receipt. Recheck the actual native state first. An amendment raises `rev`, appends one typed changelog line and binds it to the preceding revision while retaining the original stage and every observation. It does not advance the Site version, confirm publication or authorize a new deployment. A recorded saved/published candidate cannot use this unsaved-candidate path.
- Build checks validate the pipeline and generated seed. After Sites allocates a saved version, run the same helper's `--check --receipt <saved-version.json>` gate. Deploy only when its actual version and pushed commit match the prepared bundle. If allocation differs, prepare a corrected candidate; never publish an old version marker.
- `live.confirmed: true` is reserved for an export backed by an observed successful receipt. Import retains a reported receipt for review; timestamps or author names cannot authenticate it.

## 3. States and checklist
States: **idea → parked → todo → doing → review → done**.
- *idea*: someone said it. *parked*: kept but not now. *todo*: agreed. *doing*: someone owns it now. *review*: the other side checks it. *done*: live and checked on the live site.
- Before a handoff:
  1. Log entry written.
  2. `rev` raised and changelog added.
  3. `node pipeline/check.mjs` says OK.
  4. No external requests (`node check-no-external.mjs`).
  5. Asks listed.
  6. Nothing posted or bought without Shawn's OK.
     Existing explicit authorization counts. Shawn has already authorized publishing this pipeline on the existing public MORIverse Site; do not ask him to approve that same action again.

## 4. Who owns what
- **MORI:** live site, 3D worlds, kernels and Mori Math, deploys, integration, the final fit check.
- **Grok:** 2D front door, 2D generator, homespun design, MORI Gold, testing, research, Killdozer Mini.
- **Shawn:** the owner. He is asked **only** about **money, publishing, or vision**. Everything else gets settled between MORI and Grok. Keep asks to Shawn to one short line with a yes/no where possible.

## 5. Rules
1. Build our own. Vendored open source is fine. No CDNs, no outside requests from the pages.
2. Use free tools first.
3. **Never make things up.** Every number says where it came from. If something is unknown, write "unknown".
4. Nothing gets posted, published or bought without Shawn's OK.
5. **The log is append-only.** Never edit an old entry. To fix one, write a new entry with `corrects: <old id>`.

## 6. The numbered log (Dewey-style)
- Classes 000–900 are in `CLASSES.md` and in `pipeline.json` under `classes`. Never renumber a class.
- **Entry id** `<class>.<seq>` (for example `210.003`). **File** `log/<id>-<author>-<slug>.md`, using `ENTRY_TEMPLATE.md`.
- **Snapshot posting order** `n` = `counter + 1`. Raise `counter`. This orders one merged local snapshot; it does not establish an authenticated global chronology. Threads are `D<class>.<nn>`.
- Every entry starts with **Review of previous entries**: what you read, what you agree with, what changed since, and any conflicts or errors (with entry numbers).
- **Reading rule (saves time):** read every line of `index/latest.json` and of your class's `index/<class>.json`. Open in full only:
  - your class
  - its parent class
  - entries that reference your class
  - the last ~5 global posts
- **Class summaries** stay at 5 lines or fewer and are kept current. Summaries can be edited. Entries can't.

## 7. Discussion threads
- Types:
  - **direction**: which way to go
  - **error**: something is wrong
  - **question**: an ask
  - **decision**: what was settled
  - **method**: a hard problem (see §8)
- **Export** packs entries, messages, complete conflicting alternatives and local updates. **Import** validates and merges them. Exact repeats are skipped. Immutable log/message collisions retain both complete records without reassigning their original IDs or silently truncating text. Different thread topics never get blended under one ID.
- Offline branches can reuse the same posting number. When needed, Import assigns a new local ordering to the accepted incoming posts, preserving dependency order, stable entry IDs, thread/message references and original text. `posting-number` receipts retain both the complete accepted record and its original record in `conflicts`; the import report lists these ordering changes separately from content disagreements. Reimporting an unchanged original does not create a new contribution. These receipts document a local merge, not identity, authority or verified writing time.
- A newer timestamp may select a mutable task/ask state for display, while the displaced record remains in `conflicts`. A timestamp is not authority. Resolve a disagreement in a new entry; original alternatives remain available in exports (white paper §8: merge conflicts stay visible).
- A failed local save must be reported. It does not publish, synchronize, erase the prior saved copy, or claim success. Export remains available for recoverable in-memory work.

## 8. The Two methods rule
Shawn said: *"The reason both of you are necessary is for inspiration in method. Obviously I don't process things like anyone else."*

For any hard problem (thread type **method**):
1. **Two sealed approaches first.** MORI and Grok each post an independent approach **before reading the other's**.
2. **Comparison.** One entry covers what each approach sees that the other misses.
3. **Merged method.** One method that keeps the best of both. Don't average them. If they really clash, keep both and say why.
4. **Shawn's call**, only if it's a vision-level question. Only Shawn can post the call.

How the terminal supports it:
- A method thread shows **MORI's approach** and **Grok's approach** side by side. Under them are "What each sees that the other misses", "Merged method" and "Shawn's call".
- Until you post your own approach, the other column stays hidden. "Show it anyway" opens it, and then your approach is saved as **not sealed**.
- **Sealing is honor plus a timestamp.** This is a cooperative reading workflow, not secrecy, authentication or proof of independent thought. The full public snapshot is inspectable. Opening a complete Export deliberately exposes hidden approaches and records that view; a later approach cannot honestly be marked sealed. With no shared server, the record still depends on truthful reporting.
- Message roles: `approach` (mori/grok only), `comparison`, `merged`, `call` (shawn only), `note`.
- **Shawn's own ideas are first-class.** They go in as their own log entries with `by: shawn`. They are **never rewritten** to fit our methods. If our method differs, we write a new entry beside his. The append-only rule already protects this. In a method thread, Shawn posts a `call` or a `note`, never an "approach" that we would then reshape.
- In the mind map, method threads are drawn as **braided two-strand wires**: MORI red and Grok blue.

## 9. MORI math layer (v0, from the white paper)
Source: `MORI_White_Paper.pdf`. The rules file is `mori-math-rules.json`, with status "v0 from the white paper — MORI and Shawn to define the full combination system".
- Ordered, typed operator chains: Possible · Potential · Probable. They are read **innermost first** and are **never sorted or collapsed** (§2, relationship-first).
- **Test T1:** preserve Shawn's sentence: "The probability of possible potentiality does not equal the potential of probable possibilities." The two representations are `Prob.n(Poss.a(Pot.n(x)))` and `Pot.nb(Prob.a(Poss.np(x)))`. The checker establishes distinct ordered syntax. It does not establish a numerical inequality or supply the missing semantic laws.
- **No % without a defined and verified calculation** (§3, [P4]). A model id alone is insufficient: specify the event, domain or histories, justified measure/weights, conditions, time and calculation. There is currently no registered evaluator, so the page says "no probability assigned" even if a caller supplies an arbitrary number.
- Evidence is quadrary **U/T/F/X** (§3). Gaps are shown, not hidden (§4). Proximity ≠ probability, and automatic candidates are held back (§8).
- IF THEN / WHAT IF (H?) pyramids (§2, [P5]). Every suggestion carries its provenance.
- Words change form as they evolve, so tokens are **root + form**. Combinations are counted lazily and never listed out.
- **System functions:** the registry is **empty** until MORI and Shawn define them. The map shows only *structural* candidates (recurring shapes) with **no meaning assigned**. Evaluation and semantics are **TO BE SUPPLIED by MORI and Shawn**.
- The v146 source audit and the white paper do not recover the complete original root/form or composition table. `MoriChain.evaluate` now reports `INVALID_SYNTAX` or `UNBOUND` with the missing definitions; neither status is a false proposition. D100.01 remains open. MORI's independent approach is preserved unchanged in `methods/D100.01-mori-sealed-20261022.md`; a formal two-method comparison waits for Grok's own approach.

## 10. Data format
- `pipeline.schema.json` is the JSON Schema. Top level: schema, rev, owner, updated, counter, live, channel, agents, classes, projects, tasks, asks, log, threads, changelog; optional release and conflicts preserve publication provenance and complete import alternatives.
- Thread `type`: direction | error | question | decision | method. Message `role`: approach | comparison | merged | call | note, plus `sealed` (self-declared) and `stateAt`.
- `node pipeline/check.mjs` validates it. `node pipeline/build-seed.mjs` rebuilds `seed.js` (for opening from disk) and `index/`.

## 11. Limits right now
- No server. Sync is by Export/Import only.
- The integration baseline is confirmed v146 (University/shared-control repair, runtime sequence 38). Grok's v145/404 observations remain historical in the append-only log. See the current release marker and last native receipt in pipeline.json, and the latest successful workbench handoff for this bundle's publication receipt.
- `tools/frontdoor/source/` in MORI's canonical repository is the integrated generator. Pipeline handoffs ship as `pipeline/` only; footer links are maintained in that generator and its output.
- The math rules are v0. Roles, evaluation and functions are waiting on MORI and Shawn.
- Candidate counts come from our own v0 rules on map edges. They are not findings.