# A task that survives the session

The shared workshop connects the existing Claude and Codex memory runners with
a durable shared task record. `next` runs one stage; `run` runs up to two
assigned stages and stops. Another process can continue the next stage later. No schedule, daemon, hosted
memory service or public agent account is created.

The first working pattern is **draft, review, then resume and revise**. Claude
and Codex each keep access to their complete authorized libraries. A later
Claude session loads its own verified conversation checkpoint and the shared
review; nobody has to paste the draft back into that session.

## What is shared

The goal, the stage instructions and each participant's final reply are
deliberately shared with the participants assigned to that task. Say in the
instruction what belongs in the final reply. Memory reads, private tool results
and the owner's continuation checkpoint stay in the owner's library and private
run receipts. A checkpoint is labeled as a host-retained conversation record,
not a model-authored recollection or proof of personal identity. Local
filesystem access is a host trust boundary; this is not isolation from an
administrator who can open the files.

The same participant can browse, read, correct or forget authorized memories
while working. Declining the task does not revoke unrelated memory access. A
forgotten or unreadable checkpoint refuses continuation rather than silently
substituting an empty history. Corrections are resolved and checked again before
each model round. Earlier actions are never replayed from the checkpoint.

## Before you start

Tasks and the owner memory library live outside the extracted package. You need:

- An existing initialized SPIRALMESH library: the folder `SETUP.cmd` connected
  or created for your project. The launcher never creates, replaces or guesses
  a library. (`scripts/try_memory.py` only exercises a temporary practice
  library that is removed afterwards.)
- For Claude stages, the policy file `claude_auth_policy.json` in that library
  root with exactly this content, so every Claude request first checks the
  existing Claude Max login:

```json
{"schema": "spiralmesh.claude-auth-policy.v1", "requirement": "claude_ai_max"}
```

- For Codex stages, `codex login status` must report a ChatGPT login.
- No API-key or routing variables in the environment. There is no API-key
  fallback: only the existing subscription logins are used, and nothing retries.

## Create and inspect a task (no model call)

From the extracted folder, in PowerShell. Paths with spaces need quotes.

```powershell
python -B scripts\workshop.py --tasks "D:\Workshop Tasks" create examples\workshop\first-guide.json
python -B scripts\workshop.py --tasks "D:\Workshop Tasks" status first-guide
```

`create` accepts a task file saved as UTF-8 or as UTF-16 (the Windows
PowerShell 5.1 `Out-File` default), so a task built with `ConvertTo-Json | Out-File`
works. A changed definition under an existing task id is refused; nothing is
overwritten. Both commands print one JSON object and make no model call.

The example task, `examples/workshop/first-guide.json`, asks Claude to draft a
practical guide to messages and memory, Codex to check one unsupported claim and
suggest one improvement, and a fresh Claude session to revise while keeping any
disagreement visible.

## Preview account usage, then run at most two stages

```powershell
python -B scripts\workshop.py --tasks "D:\Workshop Tasks" --memory "D:\My Library" preview first-guide --stages 2
python -B scripts\workshop.py --tasks "D:\Workshop Tasks" --memory "D:\My Library" run first-guide --stages 2 --yes
```

`preview` lists the stages that would run, which account each one uses, the
maximum number of model requests (`max_rounds` per stage; the model may finish
sooner) and the per-request timeout. It checks that the library is initialized
for each participant, that the Claude policy file is present and that no
API-key variables are set. It makes no model call and reads no credential.
`run` checks the same conditions and starts only with `--yes`; it prints the
result after running. Preview gives request limits, not a price or remaining
subscription balance. It runs at most two
stages, then stops. It also stops at the first question, decline, pause,
failure or unknown outcome; it never creates new tasks or retries a stage.

## Pause, and resume the remaining stage from a new process

```powershell
python -B scripts\workshop.py --tasks "D:\Workshop Tasks" pause first-guide
python -B scripts\workshop.py --tasks "D:\Workshop Tasks" resume first-guide
python -B scripts\workshop.py --tasks "D:\Workshop Tasks" --memory "D:\My Library" next first-guide --yes
```

Pause prevents another stage or model round from starting. A request already
in progress may finish, and its permitted memory operations may finish; pause
does not promise cancellation of an already dispatched operation. Resume only
removes the pause. It does not retry a running, declined, failed or uncertain
stage. `next` runs exactly one stage in whatever process you open, today or
tomorrow. For a resumed Claude stage, the launcher restores that participant's
retained checkpoint; if the checkpoint is missing, changed or forgotten, the
stage refuses instead of starting with an empty history.

## The named output

When the task completes, the launcher writes `<task_id>-DELIVERABLE.md` inside
the tasks directory and reports its path and SHA-256. Use `deliverable` to write
it earlier or to a chosen file:

```powershell
python -B scripts\workshop.py --tasks "D:\Workshop Tasks" deliverable first-guide --out "D:\Workshop Tasks\first-guide-today.md"
```

The file holds the goal, an attribution table (stage, participant, disposition,
invocation id, reply digest), the current useful output and the earlier shared
replies in order. A decline or question is kept verbatim. Private checkpoints,
memory reads, tool results and run receipts are not included. The file is
write-once: different content for the same path is refused; pick `--out`.

## Uncertain outcomes and recovery

A question is a question, even if the model marks its reply done. A decline
stops the chain. An interrupted or timed-out invocation stays unknown until its
retained receipt is reconciled explicitly; `status` shows
`needs_reconciliation`, and no new stage starts. Never start the task again
under a new name as a way to replay an uncertain write. Two simultaneous `next`
commands cannot both claim the same stage. Process age is never a reason to
reclaim it.

One narrowly supported recovery exists for a Codex launch that provably never
started (the retained MCP configuration parse failure, with zero model
requests, protocol events or memory actions). It uses the module entry point:

```powershell
$env:PYTHONPATH = "$PWD\src"
python -B -m spiralmesh.continuity.workshop --tasks "D:\Workshop Tasks" --memory "D:\My Library" reconcile-unstarted-codex first-guide
```

It makes no model call, keeps the failed attempt in history, and requeues only
that unstarted stage. It cannot recover a timeout, an answer, a decline or a
partially executed memory operation.

The task definition is hash-bound and its events are retained locally. Hashes
help detect accidental changes; a local database is not a signature, an
external witness or proof against an administrator replacing all history.

## How to tell whether memory helped

Inspect the actual run receipts under the library's `runs` folder: successful
memory `read` operations, committed mutations and checkpoint readback. Check
that the resumed stage has a distinct invocation and received a prior
conversation turn. Compare the draft, review and revision. A fluent statement
that the model remembered is not evidence of a memory read. One designed
demonstration is not a general benchmark or proof of subjective continuity.