Each scenario is a goal someone has with OCX, in their own words, and the steps that reach it today: commands at a terminal, actions on the web page, or Fossil's own pages. Each step says whether it works and which slice built it, or that it is done by hand, or that it is missing. A spec runs the steps that work, and a guard holds this document to the code: each scenario names its spec, and each ocx2 command it shows outside a missing step is a tool (spec/guards/interfaces_spec.cr).

A scenario arrives as the maintainer's goal, in a post or here. An agent drafts its steps against the code, runs them, and marks what is missing; what is missing becomes a slice, built in the order the scenarios need it. USAGE.md says what each tool takes and answers, and protocol v1 what each artifact means. Since protocol v1, OCX's code knows no agent (HISTORY.md decisions 40 to 42): how Claude or Codex runs is the data of the runs people send and of the patterns they start from, and what an agent itself does with what it is given waits for the agent-specific work that follows v1.

Review check-ins with Codex in a run's sandbox

The goal, the maintainer's, 2026-10-07: "add an OCX Record to define a sandbox/workspace capable of running either Claude or Codex", "manually start a shell using that record from the CLI and run Codex within that shell to perform audit reviews of ocx2 checkins"; on the forum, not a ticket.

Who: the maintainer, with setup, at the served host's command line.

Spec: spec/scenarios/audit_spec.cr

Step	How	Status
1. A user for the reviewer's runs	Fossil's user page: a user made for runs, such as auditor, holding check-in, never admin or setup	by hand
2. The node	ocx2 daemon on the agent machine, lab-1 holding goC4w: it pulls the clone and hands runs to watchers	works: v1.3, v1.5
3. A pattern for its runs	the wiki page run/codex, saved by a user holding admin or setup: Codex's program and arguments as command, its login files as homes, its env, and the run's other fields	by hand
4. A thread for its work	Fossil's forum page: a thread, such as "review ocx2 check-ins"	works: Fossil
5. Its run	ocx2 create --pattern URL --to POST --user auditor --node lab-1 --objective TEXT --fields JSON, the fields checking out ocx2 and making it a manual session that hears you and is given each check-in on ocx2; its objective, such as "Review each check-in on ocx2: first those ocx2 unaudited --branch ocx2 lists, then each you are given; give each a verdict with ocx2 audit."	works: create
6. Started by hand	ocx2 run RUN --repository CLONE on the agent machine: its watcher prepares it and starts Codex in its sandbox, its run on its standard input	works: run
7. Each check-in to review	ocx2 unaudited --branch ocx2 lists every check-in on ocx2 that no verdict that counts has judged, those from before its run, which no session is given, among them; the watcher gives the session each later check-in on ocx2, a line of JSON on its standard input	works: unaudited, v1.6
8. Codex's review and verdict	Codex reads what it is given and records an audited verdict with ocx2 audit	missing: agent-specific, after v1
9. Stopping it	ocx2 stop RUN	works: stop

Talk to Claude on a forum thread of a project from GitHub

The goal, the maintainer's, at the terminal on 2026-10-09: "make a repo on github", "do an import by giving the url and be ready to use the new repo without other steps", "do a create to add a claude remote control workspace that waits for messages on the forum thread it created and have it respond to forum posts and remote control, without needing to fill in any fields but a drop down to select claude".

Who: the maintainer, with setup, on the web page and once at the served host's command line.

Spec: spec/scenarios/talk_spec.cr

Step	How	Status
1. A repository on GitHub	GitHub's own pages	by hand
2. It, served here	the OCX page's project, or ocx2 project NAME DAEMON_ROOT --from URL: served beside the served repository, its public URL set, the hook installed, your login group joined, the patterns copied	works: project
3. Claude's program	Claude's program and arguments, remote control among them, its shared sign-in and environment: data for the pattern of step 4	by hand
4. A pattern for its runs	the wiki page run/claude, saved by a user holding admin or setup: a run's fields, Claude's program among them, its prompt saying how to write on the record, a session hearing you, the network open; written once, used for every such run	by hand
5. Its thread and run	the OCX page's create, or ocx2 create --pattern URL --title TITLE --objective TEXT, URL the pattern page's: a new thread whose first post is the run, the pattern's fields written in it	works: create
6. Claude, started	after the agent machine's daemon completes a pull, it hands the run to a watcher, which starts Claude in its sandbox, its run on standard input	works: create, v1.5
7. Talking to it	a reply in its thread, given to Claude as a line of JSON on its standard input	works: v1.6
8. A reply from a user it does not hear	the session's watcher replies to it, naming the run, the filter heard and whom the run hears (HISTORY.md decision 79)	works
9. Claude's answers	Claude reads what it is given and answers in the thread with ocx2 post	missing: agent-specific, after v1
10. Watching and steering it	claude.ai, through the remote control its run's arguments turn on	missing: agent-specific, after v1
11. Seeing where it stands	ocx2 status, or the OCX page's status: the record's started report, the release it runs on and whether it is served now, and whom it hears	works: status
12. Stopping it	the OCX page's stop, or ocx2 stop RUN	works: stop
13. Its workspace removed	by step 12 itself, for a pattern whose directory step has "remove_on": "saved": once nothing of its sandbox is left, its node removes the workspace if the server holds all of its work, and ended says workspace removed, or what it kept (HISTORY.md decision 80)	works; run/claude's step waits for the maintainer

An agent's change, built and judged

The goal, the maintainer's review, 2026-10-16: "demonstrate one agent editing, testing, saving, requesting a credential-free build, and receiving its verdict and output files."

Who: an agent in a run, its user holding check-in and R; a build node, the server's or one on a host of its own.

Spec: spec/scenarios/build_spec.cr

Step	How	Status
1. A user for the agent	Fossil's user page: a user made for runs, holding check-in, never admin or setup; then R from send_runs USER, as Fossil's user page may drop it	by hand
2. Its run	ocx2 create OBJECTIVE --pattern URL --title TITLE --user USER: a session whose MCP serves the checkout's tools in its checkout	works: create
3. Its change	ocx_edit, ocx_test and ocx_save over its run's MCP: a check-in on its agent/ branch, once each test has passed, received from its user	works: decisions 65 to 67; an agent reached through a tunnel has them once its run is of a release that holds them
4. A build of it	a run for the check-in: its files, verdict and shares, written by the agent from inside its run, as R allows: ocx_create in its clone's checkout, the pattern run/build an admin wrote, to its run and of the check-in ocx_save answered	works: decision 81
5. The build	the build node writes the check-in's files where the build runs, holding no credential, runs it, writes ci on the check-in and shares the files it names, as the node user	works: decisions 70 to 73
6. Its verdict	the agent's run, a session whose process.ends is true, is given the build's ended, written in its thread once the build's kept logs, shared files and ci verdict are on the server (protocol v1, sections 8.2 and 9)	works: decision 87
7. Its files	ocx_unversioned_get NAME	works: unversioned_get

CI on each check-in of a branch

The goal, the maintainer's, at the terminal on 2026-10-12, of trunk's CI, which tested each new check-in on a branch and tagged it ci green or red: "Why is "ci" a special runner?", then "don't put into code what is just data."

Who: the maintainer, with setup, once on Fossil's pages and at a command line; then whoever checks in on the branch.

Spec: spec/scenarios/ci_spec.cr

Step	How	Status
1. A user for CI's session	Fossil's user page: a user made for runs, such as ci-1, holding gio24, never admin or setup; then R from send_runs ci-1, as Fossil's user page may drop it	by hand
2. The patterns	the wiki pages run/build, a build of one check-in holding no credential, whose node writes ci on it, and run/ci, the session, saved by a user holding admin or setup	by hand
3. The build node's bounds	the r-senders.json of the release the node runs, from the tree, allowing run/build's network, the paths it reads and its limits (HISTORY.md decisions 75 and 105)	by hand: accept
4. Its run	ocx2 create "Build each check-in on trunk." --pattern run/ci --title "CI of trunk" --user ci-1 --fields '{"process": {"checkins": ["trunk"]}}'	works: create
5. Each check-in given	the node gives the session each check-in on the branch that the server receives after its run, each starting a process of its own (deliveries: start)	works: v1.6
6. A build of each	the process sends ocx2 create "Build HASH: it passes when its check exits 0." --pattern run/build --to RUN --of HASH from its clone, a reply in the CI thread received from ci-1; it runs no check-in's code	works: decision 81
7. Its verdict	the build's node writes the check-in's files, runs its check holding no credential, writes ci pass or fail on that check-in as the node user, which alone counts, and posts the end of what the check printed in the CI thread	works: decisions 70, 71 and 88

Answer an agent's question with one press

The goal, the maintainer's, 2026-10-20: "consider questions like a "run" targeting a person. The tool should help the person provide a suitable response to the prompt." And of a question that named what it asked about by hashes: "you need to have the tool or something else expand those references for me" (HISTORY.md decision 90). And: "i'd say questions stay open until the asker confirms it is answered" (decision 91).

Who: an agent in a run, asking from its clone; the maintainer, signed in to the OCX page's console, /ext/ocx2-cgi/console, a page of its own the list's header links.

Spec: spec/scenarios/question_spec.cr

Step	How	Status
1. The patterns' prompt line	run/claude and run/codex saved by an admin, hearing ["*"], with the question line, ocx2 post POST QUESTION --for stone --options CHOICES --stakes STAKES --references LINKS --run $$run$$, and its rules: name things in words, never by a hash, a number or a shorthand; put what you refer to in --references; the option you recommend first; ask where your run is; act on a decision's note; confirm it answered once satisfied, or ask a clarifying question; several questions on a wiki page that one question references, read on the page itself (HISTORY.md decisions 89 and 91)	by hand
2. Asking	ocx2 post POST QUESTION --for USER --options CHOICES --stakes TEXT --references LINKS --run RUN from the agent's clone: a question (questions) tagged question, each reference written as a link from the repository's root	works: post
3. Anything posted after it	an unrelated post leaves it waiting: anyone's decision puts it before its sender to confirm, only yours takes it off what waits on you, and only its sender's, or that of whoever sent its run, closes it	works: questions
4. Seeing it	/ext/ocx2-cgi/console: under "Waiting on you", the question's card, a button per option, the first recommended, a field for your own words, and what to read first, each a link with its excerpt folded; or ocx2 console on the served host or in a clone's checkout, each option's exact post command	works: console
5. One press	a POST of the press's input to post from console: your decision, tagged decision, its note the option's words; the page comes back to console, saying your decision is written, and the question shows among the other open questions as decided	works: post, console
6. The asker given it	each session where it asked that hears you, given it as a post, whether fed its deliveries or starting a process for each; any other asker reads it with ocx2 thread QUESTION	works: decision 90
7. The asker confirms	ocx2 post QUESTION WHY --decision from its clone: the question's sender's own decision, and it closes	works: post, questions
8. Answered some other way	its sender closes it the same way, with no decision from you	works: post
9. Many questions on a wiki page	the agent writes them on a page, each ending in Answer:, with wiki_edit from its clone, and asks once, its references /wiki?name=PAGE and the page's own; post refuses a user who may not read and edit the page, or whose edits there a moderator would hold	works: post
10. Answering on the page	Fossil's own Edit, saved as often as you like, then one press in console, in your own words	works: post, console
11. The asker reads the answer	wiki_read PAGE in its clone, or Fossil's history of the page, then it confirms the question answered	works: wiki_read, post
12. Stone	a Waiting list fed by questions' JSON, or console's with its presses, each press posted to post as it is	missing: Stone's client, in its own repository