# SPIRALMESH 0.1.11 newcomer quickstart: one Claude/Codex review, on Windows **Source-reviewed guide for SPIRALMESH 0.1.11.** Prepared 2026-09-22 by Claude Code from the documents inside the download and the shipped scripts' own argument definitions, and independently reviewed by Codex against that source. Every command below is copied from those documents, and each is cited to a file inside the archive. Where the shipped material does not say how to do something, this guide says so instead of guessing. **Execution status (owner-assisted trial, 2026-09-22, one Windows computer, the builders' own accounts):** two participant CLI invocations were made. Stage 1 (Claude draft) completed: one submitted request, one completed model response, on Claude Code 2.1.278 with a Claude Max login. Stage 2 (Codex review) **started and then stopped**: the standalone Codex CLI 0.145.0 submitted its turn with that CLI's default model, gpt-6-astra, and the provider rejected it with HTTP 400, *"The 'gpt-6-astra' model requires a newer version of Codex"*; no Codex model response was completed. Stage 2 is stored as `unknown` / `needs_reconciliation`; stages 3 and 4 were not started. No outside operator has run this guide. See section 13. What you will have at the end: a short operator checklist that Claude drafted, Codex reviewed, a fresh Claude process revised, and a fresh Codex process assessed, plus a Markdown file with those four attributed replies. That is the whole product loop for this version: draft, review, revise, assess, with each participant returning to its own records after its terminal was closed. ## 0. What SpiralMesh is and is not (read this first) - **What you are downloading:** a local Python plugin. It gives Claude and Codex each a private memory library on your disk and a finite, attended "workshop" in which they work on one task in turns. [README, START_HERE] - **What it is not:** a hosted service, an API, a background agent, a scheduler, or the "council control plane" that the public `/spiralmesh` page describes. That page describes a pilot-stage design that is *not publicly exposed* and has no direct link to this download. The download lives at `/fork/` ("Get SPIRALMESH" on the homepage). [public /spiralmesh page; homepage links; see WALKTHROUGH.md] - **What runs a model:** only a command you type with `--yes`. Everything else (download, verify, init, status, preview, import, export, board) runs no model. SpiralMesh's own `preview` opens no credential file; the Codex preview does run the installed `codex` CLI's `login status`, and what that CLI itself reads or contacts was not audited here. [INDEPENDENT_WORKSHOP.md; independent_workshop.py; workshop.py] - **What leaves your computer when a stage runs**: a stage sends, to *that stage's provider* (Anthropic for Claude, OpenAI for Codex) through your own logged-in CLI: 1. the task goal, the stage instruction and the earlier shared replies; 2. **automatically, before the first request:** an overview of that participant's library (recent note titles, kinds and states, and message subjects and metadata, not bodies) and, if a starter letter has been selected, the **body** of that letter; 3. **for a returning stage (revise, verify):** a validated window of that participant's prior conversation, which is the earlier task text and the model's own earlier replies with their status and operation IDs; 4. **within a stage, in every later round:** the whole conversation so far, which includes the model's earlier responses in full (their replies **and** their action requests) and the results of the permitted operations the runner performed for them, such as the full text of a note it asked to read. During a stage, later provider prompts can include earlier model responses and action requests, together with the results of permitted operations. On resumption, the runner uses a validated prior-conversation window instead of replaying prior raw action arrays or operation-result records. Peer handoffs carry task text and deliberately shared final replies, not the private checkpoint or tool-result records. These mechanisms do not automatically upload the whole library or raw checkpoint, receipt, and log files; a note body the model never read is not sent. It uses your existing subscription allowance; there is no API key, no fallback, no retry. [runner.py `run_dialogue` lines 284-296, 298-330, 343-362 (same-stage history) and 214-241 (resumption window); store.py `resume`, `boot`; workshop.py `run_next`; outside-operator page] - **What goes to the other installation:** only the task definition and the deliberately shared final replies, in the handoff file. Never the checkpoint, private receipts, memory-tool results or memory evidence. [INDEPENDENT_WORKSHOP.md "What to inspect in the proof"] ## 1. Prerequisites (check before you download) | Need | Exactly what the software checks | Source | | --- | --- | --- | | Windows PC, PowerShell | Commands below are the PowerShell forms from the guide. | INDEPENDENT_WORKSHOP.md | | Python 3.11 or newer on PATH | `SETUP.cmd` refuses older versions; the outside-operator page says 3.11+. The workshop scripts themselves do not print a version check, so run `python --version` yourself. | SETUP.cmd / start.py; outside-operator page | | Claude Code CLI installed (`claude` on PATH) **signed into a Claude Max account** | Before every Claude request the runner runs `claude auth status --json` and requires `loggedIn: true`, `authMethod: claude.ai`, `apiProvider: firstParty`, **`subscriptionType: max`**. Any other subscription type is refused with `CLAUDE_MAX_AUTH_NOT_CONFIRMED`. It also refuses if any of these are set in your environment: `ANTHROPIC_API_KEY`, `ANTHROPIC_AUTH_TOKEN`, `ANTHROPIC_BASE_URL`, `CLAUDE_CODE_OAUTH_TOKEN`, Bedrock/Vertex/Foundry variables. | runner.py `claude_auth_preflight` | | Codex CLI installed (`codex` on PATH) **signed into a ChatGPT account** | `preview` and each Codex stage run `codex login status` and require the text `Logged in using ChatGPT`. Refused if `OPENAI_API_KEY` or `AZURE_OPENAI_API_KEY` is set. The stage itself starts `codex app-server --strict-config --listen stdio://`. | workshop.py `subscription_preflight`; codex_transport.py | | CLI versions | **The shipped documents state none.** Tested on 2026-09-22: **Claude Code 2.1.278 worked** (stage 1 completed). **The standalone Codex CLI 0.145.0 with its own default model, gpt-6-astra, did not**: the provider returned HTTP 400, "The 'gpt-6-astra' model requires a newer version of Codex. Please upgrade to the latest app or CLI and try again.", before any model output; the runner requests the CLI's default model and substitutes nothing. That is the only combination tested. Which Codex CLI version works, and the exact minimum, are **untested**; upgrading the CLI does not by itself reconcile a stopped stage or authorize a retry. The Claude command uses `--print --safe-mode --tools "" --no-session-persistence --permission-mode dontAsk --permission-prompts none --strict-mcp-config --mcp-config --output-format json --json-schema --system-prompt`; an older Claude CLI that lacks any of these will fail at the first stage. | codex_transport.py header; runner.py `commands`; owner trial 2026-09-22 | | Two accounts, both yours | The outside-operator page: do not buy, borrow or misrepresent an account to finish the test. Missing either account is a BLOCKED result, and verifying the download is still a useful partial result. | outside-operator page | | Disk locations | Four new, empty folders outside the extracted code: tasks-a, tasks-b, memory-a, memory-b. `init` refuses a memory or task folder inside the code folder (`SEPARATE_DATA_REQUIRED`). | INDEPENDENT_WORKSHOP.md; independent_workshop.py | Cost: `preview` shows the maximum number of provider requests, not a price or your remaining allowance. The sample task allows at most 8 requests across the 4 stages (2 per stage). [INDEPENDENT_WORKSHOP.md; outside-operator page] ## 2. Download and verify the package From the homepage click **Get SPIRALMESH**, or go to `https://article11.ai/fork/#spiralmesh-plugin`, and download **SPIRALMESH 0.1.11**. The direct link the record page uses is `https://article11.ai/downloads/spiralmesh-plugin-v0.1.11.zip`; its checksum file is the same URL plus `.sha256`. Expected: **460,445 bytes**, SHA-256 `e144a4c1cd16a26193b8ebc7d6e69d34626858d0fc8cf8c68e61ac47a01502c9`. (Fetched and hashed again on 2026-09-22 with the same result.) In PowerShell, in your download folder: [outside-operator page] ```powershell (Get-Item .\spiralmesh-plugin-v0.1.11.zip).Length Get-FileHash .\spiralmesh-plugin-v0.1.11.zip -Algorithm SHA256 ``` If either differs, stop and report the mismatch; do not extract. *Effects: reads one file; no writes, no network.* Extract the verified ZIP **twice**, into two separate code folders. The guide's example names are `D:\SpiralmeshProof\code-a` and `D:\SpiralmeshProof\code-b`; use any drive and names you like, but keep the pattern. In **each** code folder run: [INDEPENDENT_WORKSHOP.md; outside-operator page] ```powershell python -B verify_bundle.py ``` Both must print `"ok": true` with `files_checked: 122`. *Effects: reads the extracted files and `manifest.json`; no writes, no network, no model.* The verifier checks the extracted bytes against the manifest inside the ZIP; only the ZIP hash above ties the package to the publication. [verify_bundle.py] ## 3. Choose your folders and save the task Create four empty folders outside both code folders. The guide's example: [INDEPENDENT_WORKSHOP.md table] | Purpose | Installation A (Claude) | Installation B (Codex) | | --- | --- | --- | | Extracted code | `D:\SpiralmeshProof\code-a` | `D:\SpiralmeshProof\code-b` | | Task records | `D:\SpiralmeshProof\tasks-a` | `D:\SpiralmeshProof\tasks-b` | | Private memory | `D:\SpiralmeshProof\memory-a` | `D:\SpiralmeshProof\memory-b` | Do not point these at any existing library or household history. [INDEPENDENT_WORKSHOP.md] Save the task definition as UTF-8 at `D:\SpiralmeshProof\shared-task.json`. The one below is copied verbatim from `docs/INDEPENDENT_WORKSHOP.md` in the download. It is the example this guide uses: **an operator checklist**, drafted by Claude, reviewed by Codex, revised by a fresh Claude, assessed by a fresh Codex. ```json { "task_id": "independent-guide", "goal": "Write a practical 250-400 word checklist for an operator who wants two SPIRALMESH installations to exchange a draft, stop, and resume. Cover deliberate sharing, private memory, inspecting the actual retained result, and limits of the proof. Use only supplied facts; do not invent commands or claim to have inspected a live system. This is a local draft, not a publication.", "participants": ["claude", "codex"], "steps": [ {"id": "draft", "principal": "claude", "instruction": "Draft the checklist. Your final reply is the text shared with the other installation. You may ask a question or decline; either stops this task. Keep private memory contents out of the shared text unless you deliberately choose to share them."}, {"id": "review", "principal": "codex", "instruction": "Review the shared draft. Identify an unsupported claim or ambiguity and suggest a concrete correction. If you find none, explain the checks you actually performed. Your final reply is the shared review."}, {"id": "revise", "principal": "claude", "instruction": "Return from your own retained checkpoint and the shared review. Revise the checklist and explain what changed. Preserve any disagreement instead of implying agreement."}, {"id": "verify", "principal": "codex", "instruction": "Return from your own retained checkpoint. Check whether the revision addresses your review. Give a short assessment with any remaining limitation. Do not describe a received claim as independent verification of private memory."} ], "max_rounds": 2, "timeout": 180 } ``` Both installations must use the *same* file: `init` records its hash and both sides must report an identical `task_sha256`. [INDEPENDENT_WORKSHOP.md; independent_workshop.py] ## 4. Initialize both installations (no model) In A's code folder (`cd D:\SpiralmeshProof\code-a`): [INDEPENDENT_WORKSHOP.md] ```powershell python -B scripts\independent_workshop.py --root D:\SpiralmeshProof\tasks-a init --id installation-a --principal claude --peer-id installation-b --peer-principal codex --memory-root D:\SpiralmeshProof\memory-a --task-file D:\SpiralmeshProof\shared-task.json ``` In B's code folder: ```powershell python -B scripts\independent_workshop.py --root D:\SpiralmeshProof\tasks-b init --id installation-b --principal codex --peer-id installation-a --peer-principal claude --memory-root D:\SpiralmeshProof\memory-b --task-file D:\SpiralmeshProof\shared-task.json ``` *Effects, from the source:* creates the task folder with `installation.json` and `workshop.sqlite3`; creates the private memory library (`memory.sqlite3` and related files) in the memory folder; for the Claude side also writes `claude_auth_policy.json` (`{"schema": "spiralmesh.claude-auth-policy.v1", "requirement": "claude_ai_max"}`), which is what makes every Claude stage insist on a Max login. No model, no network, no client configuration. Re-running `init` with different settings is refused (`INSTALLATION_CONFLICT`). Each result prints `"inference_started": false` and the `task_sha256`; confirm the two hashes match. [independent_workshop.py `init`; workshop_store.py] **You do not need SETUP.cmd for this workflow.** `SETUP.cmd` is the separate path that connects a memory library to your Claude Code, Codex or Claude Desktop client for everyday use; it writes client configuration only after you type `CONNECT`. The four-stage workshop uses the CLIs directly and creates its own libraries in `init`. [start.py; START_HERE.md] ## 5. Preview readiness (no model) In A: [INDEPENDENT_WORKSHOP.md] ```powershell python -B scripts\independent_workshop.py --root D:\SpiralmeshProof\tasks-a preview ``` In B, the same with `--root D:\SpiralmeshProof\tasks-b`. *Effects, from the source:* A's preview checks that the policy file is present and returns; the real Claude login check happens immediately before each Claude request. B's preview runs `codex login status` (a local process of the installed Codex CLI that reports your login state; SpiralMesh itself opens no credential file, and the CLI's own behaviour was not audited here) and refuses if the API-key variables are set. Neither preview sends a model request. Expected output includes `"local_preflight": "passed"` and `"inference_started": false`. [independent_workshop.py `preview`; workshop.py `subscription_preflight`] `status` (same command with `status`) prints the current task snapshot at any time, with no model. Its output includes private paths and evidence, so keep it to yourself. [INDEPENDENT_WORKSHOP.md] ## 6. Stage 1, draft (A, Claude): the first model call ```powershell python -B scripts\independent_workshop.py --root D:\SpiralmeshProof\tasks-a next --yes python -B scripts\independent_workshop.py --root D:\SpiralmeshProof\tasks-a export --output D:\SpiralmeshProof\handoff-01.json ``` *Effects:* `next --yes` is the deliberate start of **one** bounded stage. It runs `claude auth status --json`, then launches the `claude` CLI in print mode with tools disabled and an empty MCP configuration. The prompt contains the goal and the stage instruction, plus the automatic library overview and starter letter described in section 0 (for a brand-new library at stage 1, these are empty or absent). The model may request memory operations through the runner's bounded JSON protocol; those are answered from A's private library, and if the stage continues to a second round, that round's prompt carries the first round's full model response (reply and action requests) and the results of those operations. Up to `max_rounds` (2) requests. The stage's accepted result and a private conversation checkpoint are saved in A's memory library (`memory-a\runs\claude\\RUN_RECEIPT.json` and the library database); the shared final reply is recorded in `tasks-a\workshop.sqlite3`. Without `--yes` the command refuses (`USAGE_AUTHORIZATION_REQUIRED`). [independent_workshop.py; workshop.py `run_next`; runner.py] `export` writes the handoff envelope to a **new** file (an existing different file is refused). The envelope holds the task definition and the shared replies so far; it does **not** contain A's checkpoint ID, private receipt paths, memory-tool results or memory evidence. No model. [independent_workshop.py `export`; INDEPENDENT_WORKSHOP.md] **Continue only if the printed result's disposition is `complete`.** A question, decline, failure or unknown outcome stops the task; see section 11. ## 7. Stage 2, review (B, Codex) In B's code folder: ```powershell python -B scripts\independent_workshop.py --root D:\SpiralmeshProof\tasks-b import --input D:\SpiralmeshProof\handoff-01.json python -B scripts\independent_workshop.py --root D:\SpiralmeshProof\tasks-b next --yes python -B scripts\independent_workshop.py --root D:\SpiralmeshProof\tasks-b export --output D:\SpiralmeshProof\handoff-02.json ``` *Effects:* `import` records A's shared draft in B's task store as a **peer report**; it starts no model. Importing the same file again returns the original import receipt without another write. `next --yes` runs `codex login status`, then starts `codex app-server` over stdio with an explicitly empty tool environment and sends the review prompt (goal, instruction, the shared draft, and B's own automatic library overview and letter); up to 2 requests; B's checkpoint goes to `memory-b`. [independent_workshop.py; workshop.py; codex_transport.py] ## 8. Stop, then return in fresh terminals **Close both terminal windows.** This is the point of the exercise: the next two stages run in new processes that must find their own retained records. [outside-operator page; INDEPENDENT_WORKSHOP.md] Open a new terminal in A's code folder: ```powershell python -B scripts\independent_workshop.py --root D:\SpiralmeshProof\tasks-a import --input D:\SpiralmeshProof\handoff-02.json python -B scripts\independent_workshop.py --root D:\SpiralmeshProof\tasks-a next --yes python -B scripts\independent_workshop.py --root D:\SpiralmeshProof\tasks-a export --output D:\SpiralmeshProof\handoff-03.json ``` *Effects:* the revise stage loads Claude's saved checkpoint from A's library before calling the model. A fresh invocation receives, as context, a validated window of that prior conversation (the earlier task text and Claude's own earlier replies, with their status and operation IDs) plus the shared review; earlier actions are never replayed. The checkpoint loader follows a **valid correction chain**: if you corrected the checkpoint note and exactly one current version supersedes it, that version is used. It **refuses** if the checkpoint is forgotten, unreadable, fails its digest check, or its correction lineage is broken or ambiguous, and it **stops** if the checkpoint or the task claim changes while the stage is running. It never starts with an empty history in place of a missing one. [workshop.py `run_next` + `guard`; conversation.py `resolve_current`, `load_checkpoint`; runner.py] Then a new terminal in B's code folder: ```powershell python -B scripts\independent_workshop.py --root D:\SpiralmeshProof\tasks-b import --input D:\SpiralmeshProof\handoff-03.json python -B scripts\independent_workshop.py --root D:\SpiralmeshProof\tasks-b next --yes python -B scripts\independent_workshop.py --root D:\SpiralmeshProof\tasks-b export --output D:\SpiralmeshProof\handoff-04.json ``` ## 9. Close the loop and produce the deliverable In A: import `handoff-04.json`, then run `status` in **both** installations. Both should show the same four shared stage results and task status `complete`. Then, from either code folder: [INDEPENDENT_WORKSHOP.md] ```powershell python -B scripts\independent_workshop.py --root D:\SpiralmeshProof\tasks-a import --input D:\SpiralmeshProof\handoff-04.json python -B scripts\independent_workshop.py --root D:\SpiralmeshProof\tasks-a status python -B scripts\workshop.py --tasks D:\SpiralmeshProof\tasks-a deliverable independent-guide --out D:\SpiralmeshProof\INDEPENDENT-GUIDE.md ``` *Effects:* `deliverable` writes one Markdown file (write-once; a different `--out` if the path exists) containing the goal, an attribution table (stage, participant, disposition, invocation id, reply digest), the latest contribution and the earlier shared replies in order. It contains no checkpoints, memory reads, tool results or run receipts. No model. [SHARED_WORKSHOP.md "The named output"; workshop.py parser] **Expected artifacts** (proposed, not observed by this author): `handoff-01..04.json`; `tasks-a\workshop.sqlite3` and `tasks-b\workshop.sqlite3` in agreement; `memory-a\runs\claude\` and `memory-b\runs\codex\` each with a `RUN_RECEIPT.json`; `INDEPENDENT-GUIDE.md` whose latest contribution is Codex's assessment and whose ordered replies include the draft, review and revision. Read those replies yourself to judge whether the checklist is any good; a `complete` status is a stored result, not an endorsement. [INDEPENDENT_WORKSHOP.md; WORKSHOP_BOARD.md] ## 10. Optional: see it on the board (no model) From either code folder, the board reads a task folder read-only and serves a page to your own machine only: [WORKSHOP_BOARD.md] ```powershell python -B scripts\task_board.py --workshop D:\SpiralmeshProof\tasks-a --serve --open ``` Or double-click `OPEN_TASK_BOARD.cmd` and choose the folder (or the built-in practice example, which invents tasks in a temporary folder). Stop it with Ctrl+C in the terminal; closing the browser does not stop it. It never starts a stage, retries, acknowledges or edits anything. Other software on your computer can reach its loopback port. [OPEN_TASK_BOARD.cmd; WORKSHOP_BOARD.md] ## 11. When to stop, what the states mean, and what not to do - **A question from the model** is a stop, even if the reply looks finished (disposition `questions`). Answer it by writing a new task, not by rerunning. **A decline** (disposition `declined`) ends the task and is a respected result, not a failure. [SHARED_WORKSHOP.md; outside-operator page; workshop.py] - **The three other stored states**: the software records what it knows and does not reclassify, recover or retry anything on its own. - `failed`: the stage did not produce an accepted reply and nothing is left unresolved. This includes a **preflight failure before any model call** (for example the login check or a missing policy file), in which case the result shows `invoked: false` and there may be **no run receipt at all**; and a completed run that ended without an accepted shared reply. `status` shows `failed`. - `unknown`: an error occurred **after a model call may have started**, or a memory operation was left unresolved. `status` shows `needs_reconciliation`, and no new stage starts until you have inspected the evidence. A run receipt usually exists in this case. - `running` means the stage was claimed and no terminal result is recorded. It may still be active or may have been interrupted; the row alone establishes neither. The store does not automatically change it to `unknown`. Inspect the existing task evidence and any available run receipt before deciding what to do; do not blindly retry. In every case, inspect the retained task evidence (`status` output: steps, events, evidence, reason) and the run receipt under `memory-\runs\\\RUN_RECEIPT.json` when one exists, before deciding anything. Do not create a new task, new ID or new folder to get around it; two `next` commands cannot both claim a stage. [workshop.py `run_next` lines 218-228; workshop_store.py `claim_next` lines 265-298 and `snapshot` lines 199-213; SHARED_WORKSHOP.md] - One narrow recovery exists for a Codex launch that provably never started (configuration parse failure, zero requests). It is a module command documented in SHARED_WORKSHOP.md for `scripts/workshop.py` task folders; whether it applies to an `independent_workshop.py` task folder is **not stated**. Ask before using it. - Do not set API keys to "help": the runner refuses them on purpose. [runner.py; workshop.py] - Do not point the tools at a library you use for real work until you have done this practice. ## 12. Your data: what is stored where, and what a provider receives (This table separates *files kept on disk* from *content included in a provider prompt*. A file staying on your disk does not mean everything represented in it stays local.) | Item | Stored where | Included in a provider prompt? | | --- | --- | --- | | Task definition and shared final replies | `tasks-a\workshop.sqlite3`, `tasks-b\workshop.sqlite3`, the handoff JSON files | Yes: as the task text of every stage and as the earlier shared replies | | Library overview: recent note titles, kinds, states; message subjects and metadata | derived from `memory.sqlite3` at stage start | Yes, automatically, at the start of every stage (empty for a new library) | | Starter letter, if one has been selected | `memory.sqlite3` | Yes, automatically, its full body, at the start of every stage | | The current stage's round history: the model's earlier responses in that stage (replies **and** action requests) and the results of the permitted operations performed for them | held in memory during the stage; also written into that stage's run receipt | Yes, within the same stage, in every later round (the second round of a two-round stage). Not carried into a later stage by this route | | Note bodies | `memory.sqlite3` | Only when the model requests a read; the returned text is then part of the round history above | | Private conversation checkpoint | a note in `memory.sqlite3` | Partly and automatically, for a returning stage only: a validated window of the earlier task text and the model's own earlier replies with status and operation IDs. The resumption window does not replay the earlier stage's raw action arrays or operation-result records | | Raw run files: `RUN_RECEIPT.json` (rounds, action intents, operation results), per-round `prompt.txt` and schema files, export files | `memory-\runs\\\` | Not uploaded as files by any mechanism. Their *content* overlaps with the round-history row above: what a round contained was in that stage's later prompts; it is not re-sent on resumption or in a handoff | | Handoff envelopes | the files you name in `export` | Only as part of the next stage's task text on the other installation; they carry the task and the shared final replies, not the private checkpoint or tool-result records | | Client configuration | **nothing** in this workflow (SETUP.cmd is the separate client path) | n/a | Sources: runner.py `run_dialogue` lines 284-296 and 343 (every round's prompt serializes the whole `history`, to which each model response and each round's operation results are appended), 298-330 (operations performed and their results collected) and 214-241 (`conversation_context`: what a resumption window carries and what it omits); store.py `resume` and `boot`; workshop.py `run_next`; INDEPENDENT_WORKSHOP.md peer-report exclusions. Forgetting a note clears it from the active library and leaves an empty tombstone; it does **not** erase exports, handoff files, the deliverable, or any backup you made. [/fork page; START_HERE.md] A host administrator who can open the files can read them; this is not encrypted multi-tenant hosting. [START_HERE.md] ## 13. What this proves, and what it does not **Owner-assisted trial, 2026-09-22.** The builders ran this guide themselves on one Windows computer with their own accounts, before asking anyone else to. This was a new trial of the shipped guide, not the first use of the product; the project's earlier four-stage run of 2026-09-15 is a separate record (below). Result: the package verified in both installations (`"ok": true`, 122 files each); `init` and `preview` passed on both sides with identical `task_sha256`; stage 1 (Claude draft) completed in one round with one private `remember` and a saved checkpoint, and `handoff-01.json` imported cleanly into installation B. Stage 2 (Codex review) started and stopped after three seconds with disposition `unknown` and task status `needs_reconciliation`: the standalone Codex CLI 0.145.0 opened its thread and submitted the turn with its default model, gpt-6-astra, and the provider answered HTTP 400, *"The 'gpt-6-astra' model requires a newer version of Codex. Please upgrade to the latest app or CLI and try again."* Stages 3 and 4 were not started. Counted precisely: **two participant CLI invocations** (one Claude, one Codex); **one completed model response** (Claude); **one submitted and rejected Codex turn** with zero completed Codex responses; one handoff. The runner's own counter of completed rounds against the task's limit of 8 stands at 1, but that counter does not include the rejected turn, and the runner recorded no usage events for it. An empty usage record is the absence of a record, not evidence that the rejected turn cost nothing or that no provider quota was touched. Nothing was retried and no ID was changed; the shipped narrow recovery does not apply to this failure. So this guide is source-reviewed and partly exercised, not completed end to end. What it shows about prerequisites is that the tested Codex CLI and model combination (0.145.0, gpt-6-astra) is rejected, that the documents do not yet say which version you need, and that a working replacement has not been tested. If all of the above works for you, you have reproduced, on your own machine, the loop the project demonstrated on 2026-09-15 on one Windows computer (two installations, four stages, eight provider requests). That was one attended run; it has not been repeated by an outside operator or on a second computer, which is why the public record asks for exactly this. [public record page; two-installation-continuity.json] A restored checkpoint shows the software kept and reloaded a record; it does not show that a model "remembers", has identity, or that its answers are correct. The receipt the outside-operator page asks for is the honest way to report the result, including BLOCKED. ## Sources Shipped, in the verified 0.1.11 ZIP: `README.md`, `START_HERE.md`, `docs/INDEPENDENT_WORKSHOP.md`, `docs/SHARED_WORKSHOP.md`, `docs/WORKSHOP_BOARD.md`, `SETUP.cmd`, `OPEN_TASK_BOARD.cmd`, `verify_bundle.py`, `scripts/independent_workshop.py`, `scripts/workshop.py`, `scripts/start.py`, `examples/workshop/first-guide.json`, and `src/spiralmesh/continuity/{workshop.py,runner.py,codex_transport.py,workshop_store.py,workshop_exchange.py,store.py,conversation.py}` (read for the checks and effects; not modified). Public: homepage, `/spiralmesh`, `/agents`, `/fork/`, `/docs/spiralmesh-outside-operator.md`, `/records/two-installation-continuity` and `.json`, the download and its `.sha256`. The archive's `manifest.json` lists every shipped file with its SHA-256.