ocx here is the release people and agents still used, read at its tip
(a46d73f5bf) for
slices-parity.md on 2026-10-06, and read again whole, its
216 files, by the parity audit of 2026-10-18 (tech-note
bb2af9185e). ocx2
is to reach what it did, with protocol v1 underneath
(protocol-v1.md), then retire it. On v1 most of what ocx
did as code is a run's data: a pattern, by convention the wiki page
run/NAME, holds how an agent or a check runs, and the protocol starts it,
feeds it and ends it. So each row says whether ocx2 needs a tool, a protocol
piece, or only a pattern.
Status: works (a spec shows it), pattern (works once someone writes the data; nothing to build), missing (what to build is named, by its step in the order below), held (waiting on the maintainer's answer), or not copied (with why). A row whose parts stand differently gives each part its own status, the parts separated by a semicolon, so "works: X; missing: Y" means X works and Y is still to build. What ocx2 does that ocx never did is under Past parity.
People and agents at work
| Trunk | On ocx2 | Status |
|---|---|---|
| The console's Add a workspace and New session forms, from templates, with a preview (src/ocx/cgi_add_workspace.cr, cgi_session_forms.cr) | create --pattern run/NAME, on the web page as at the command line, its dry run, and --title, --to or --ticket for where the run is written |
works |
An agent answers each post on a thread or ticket, one turn at a time (task --write, --wait) |
a session run that hears the thread; each post reaches the agent's standard input. A turn-per-post agent, such as claude -p or codex exec, has each delivery start a process of its own: deliveries: start, after a process for the run itself |
works |
An agent remembers its earlier turns: ocx's Claude runner passed --continue after the first (src/ocx/runners/claude/runner.cr) |
--continue, to be added to run/claude's command: Claude keeps a conversation per working directory, here the run's own $$tree$$, and starts one where there is none |
missing: step 2, a pattern edit |
| An agent in one long session a person can watch and steer (remote control) | a session run whose process.terminal is true, so its program runs on a terminal its node holds, its run and each post typed in as lines and what the terminal showed kept as its STDOUT, its command turning on remote control (HISTORY.md decision 82); a person at the node's host joins it with ocx2 attach RUN, seeing it and typing into it until Ctrl-] leaves it running (decision 83) |
works |
| How Claude or Codex is run: program, arguments, sign-in, environment (src/ocx/runners/) | the patterns run/claude and run/codex, in the layered format |
pattern: both written; Codex ran on a scratch repository as far as its sign-in, which that host lacked (tech-note 821db8ab25); the server's run/codex holds its block between two backticks, which create refuses, mended in step 21's version; neither has yet answered on a thread: step 3 |
| A local model doing a task: ocx's native runner, an Ollama tool loop of five tools and 40 steps that also takes tool calls a model writes as JSON text (src/ocx/native_runner.cr) | ocx2 --mcp-ollama URL --model NAME --steps N --system TEXT, named as a run's command: the battery's conversation, moved into OCX, with the checkout's tools as MCP serves them to the run's user; each reply a line of JSON printed before its calls run, and each answer after it, in the run's standard output, kept always and posted whole when the process ends; the model's last words posted as the run's user (PLAN.md, "Agents on protocol v1") |
works; the pattern run/gemma and its first proof on the server still to write |
An agent reads and changes the checkout's files: ocx's native runner offered list_files, read_file, write_file, run and finish (src/ocx/native_runner.cr); ocx had no MCP server |
eleven tools on the run's own checkout, over MCP, each answer bounded and saying ok: context, find, read, edit (old copied exactly, or empty to add at the end), test, save, wiki_read, wiki_edit, unversioned_list, unversioned_get, unversioned_put (docs/agent-tools-proposal.md) |
works |
| A note when nobody hears a post (src/ocx/unheard.cr) | each running session's watcher replies to a person's post or ticket change it holds back in its thread or ticket, as the node user, beginning Not given to run HASH: and naming that run's filter and whom it hears (protocol v1, section 8.2; HISTORY.md decision 79) |
works |
An agent posts its answer (task --write) |
ocx2 post from the run's clone, as its run user |
works |
Questions put to a person, and what waits on them (the console's For you and Open questions, console --for LOGIN) |
post TO TEXT --for USER writes a question, an OCX message, and post QUESTION TEXT --decision its decision (questions); questions [--for USER] lists, as data, each question for a user that they have not decided as waiting on it, whoever else has and whatever was posted after it, each the user sent, or a run they sent asked, that has a decision as theirs to confirm, and every other open question as open, each with its decisions; console [--for USER], ocx's name restored, shows them to a person, then the runs for every node user an administrator's run names, laid out for each entry point: on the OCX page, /ext/ocx2-cgi/console, a page of its own, at the command line and over MCP as text; anyone where a question is may decide, and only its sender's own decision, or that of whoever sent the run that asked it, closes it; in your own view each question waiting on you has a press of post --decision per option, the first recommended, and one for your own words, and each you may close a press to confirm it answered, drawn as a button on the page and as the exact command at the command line (HISTORY.md decisions 90, 91, 93, 94, 98 and 100) |
works: questions, console; missing: Stone, the maintainer's client, showing them (the maintainer, 2026-10-20: "has to update Stone to use them") |
What waits on an agent, and where a record stands (task --status, task --wait, the console's Needs you) |
a session is given each post as it arrives; a run's started and ended are on its thread; an agent reads its own thread or ticket, each post or change with who sent it, with thread (ocx_thread over MCP), after the post it last read |
works: thread, and status's runs |
| Writing conventions in every prompt: full links, the question shape, one question at a time, the result first, what was verified, times in US Eastern (src/ocx/conventions.cr) | a paragraph in each agent pattern's prompt, its links built from $$server$$, which the node fills with the server's URL, a question to a person written where the run is with ocx2 post POST QUESTION --for USER --options CHOICES --stakes STAKES --references LINKS --run $$run$$, in words, what it refers to in --references, the recommended choice first, the decision acted on by its note, the question confirmed answered with --decision once satisfied, or a clarifying question asked, and several written on a wiki page that one question references, read on the page itself, each pattern hearing ["*"] (HISTORY.md decisions 89, 90 and 91) |
pattern: in run/claude and run/codex, written for an admin to save; not yet tried |
| Only verified work committed, with Intent, Expression and Demonstrates | the agent's own check-in from its clone, as its run user; or save, which commits only once each test the project names has passed with the checkout as it is |
works: save; the agent's instructions otherwise |
| Comparing agents on one task: the native and Claude runners answering one ticket, both reports in one shape (ocx's own plan, phase E and its parity row 1) | runs of two patterns sent as replies in one thread, with one objective and the same checkout, read back from the repository: a spec to write | missing: step 4 |
| Seeing what a running session is doing now: the console's session page showed the end of its launch log (src/ocx/launch.cr) | a terminal run is joined with attach; for any run, live status over server-sent events, with its tool name open (USAGE.md, "See a run live") |
missing: live stream, not in the order below |
A session ending itself once its report is on the record, unless it asked a question (the lifetime completes, docs/design/sessions.json) |
a run whose process is one shot ends when it exits; a turn-per-post session ends by a stop or its wall | answered: both ways stay, chosen per run (HISTORY.md decision 90); step 22 is not built |
Review and CI
| Trunk | On ocx2 | Status |
|---|---|---|
An audited verdict on a check-in (tools/audit.cr) |
ocx2 audit CHECK-IN pass\|fail NOTE AGAINST |
works |
| Verdicts read with who gave them and when (the console's Audits, src/ocx/activity.cr) | Fossil's own pages: /timeline?y=g lists each tag change with its value and user, and /ci_tags/HASH a check-in's tags, raw ones such as audited and ci among them (tried on Fossil 2.27); counting them by the reading rules is unaudited |
works |
The review queue: check-ins nobody but their author has judged (reviewer, the console's Audits) |
a reviewer session given each new check-in on its branches (checkins); the check-ins from before it started, and any still waiting later, listed by unaudited [--branch BRANCH] (ocx_unaudited over MCP): those that change files and that no verdict that counts has judged (verdicts) |
works: unaudited |
| A build of one check-in, tagged green or red, its products kept | a run whose files step writes the check-in's files, holding no credential; verdict has its node write ci, pass or fail, on that check-in, and shares has it share the files the build leaves as unversioned files (HISTORY.md decisions 70 to 72) |
works |
An agent asks for a build or a job and learns how it ended: anyone could post Run: LOGIN at REF, and the result came back as a post from another login (src/ocx/job.cr) |
create --pattern run/build --to RUN --of CHECKIN from the run's clone (HISTORY.md decision 81); a session whose process has ends is given the build's ended in its thread (decision 87) |
works, with an admin's run/build (spec/scenarios/build_spec.cr); the server's run/build, and run/claude's ends, written for an admin to save (step 12) |
| Who may ask for a job or CI: anyone who could post on its record (src/ocx/job.cr) | a user holding admin or setup, or one holding R with the isolation its pattern sets (HISTORY.md decision 132) |
works |
| A session listening to a branch's check-ins (src/ocx/listeners.cr) | process.checkins, the branches whose check-ins a session is given |
works |
| CI on each check-in of a branch, tagged green or red (src/ocx/command_runner.cr) | a session whose checkins names the branch and whose user holds R sends a build of each check-in it is given, create --pattern run/build --to RUN --of CHECKIN, whose node writes ci on it, which alone counts; with ends the session is given each build's ended (HISTORY.md decisions 81, 87 and 88) |
pattern: run/ci and run/build, written for an admin to save, every step past them run by spec/scenarios/ci_spec.cr; not yet tried live |
A job: run a user's job at a ref, its log's end posted (Run: LOGIN at REF) |
a run whose checkout step names the ref, its command the job; the end of what it printed is kept and posted |
works |
Trunk's job and CI templates: the wiki pages session/bq2-build, session/ci and the workspace/ pages |
the patterns run/build, run/ci and run/bq2-build, each holding its sandbox whole |
pattern: written for an admin to save; run/bq2-build builds its data/sysroot afresh each run until a user's cache keeps it, step 9 |
The node and the host
| Trunk | On ocx2 | Status |
|---|---|---|
| The hook that wakes sessions (tools/wake.cr) | ocx2 daemon pulls whole clones after Fossil's chat wakes; watchers give session deliveries |
works |
| The daemon keeping sessions running (tools/ocxd.cr) | one daemon per machine and a watcher per run; later complete pulls reconsider waiting runs and start the next watcher of a run whose lock is free; finding taken, it ends what the old lock names and posts lost |
works |
| The sandbox stated in full on the record: the workspace definition (src/ocx/definitions.cr, sandbox.cr) | the run's sandbox and limits layers (protocol v1, sections 6 and 7) | works |
| Stop a session (console) | ocx2 stop RUN |
works |
| Restart a stopped session (console) | send the run again, or a new run from its pattern | pattern |
Workspaces listed and removed (workspace gc, the console's terminate, src/ocx/collect.cr) |
a run whose directory step has "remove_on": "saved" has its workspace removed by its node once the run has ended, nothing of its sandbox is left and the server holds its work; ended's workspace says removed, or what it kept; other workspaces stay on the node (HISTORY.md decision 80) |
works |
| A workspace kept between runs: one per user and project, cloned once, so a job's build state carried over (src/ocx/launch.cr) | a user's cache on a project, a workspace step {"step": "cache"} to be built |
missing: step 9, lower priority (the maintainer, 2026-10-20: "i don't understand the need", then "lower priority") |
| Sessions and workspaces listed for supervision (the console), and whether a thread's agent is working, idle or stopped, as JSON for Stone (src/ocx/status.cr, host_state.cr) | status reads open runs for every node user an administrator's run names from the record alone; with a clone and its project password file it reads local care, decision notes and, for setup, processes through the last complete pull (USAGE.md) |
works: status, as JSON too; working or idle as a field of its own is step 16, held |
| A tool finds its repository from the checkout it is in (src/ocx/checkout.cr) | every tool's default, which status names "the checkout you are in" |
works |
| Releases: deploy, accept, roll back (tools/deploy.cr) | stage, accept, rollback, status |
works |
| The hook installed from the console | hook, unhook, installing only Fossil's git export; the daemon wakes on chat (above) |
works |
Repositories and OCX itself
| Trunk | On ocx2 | Status |
|---|---|---|
| The git export served for mirrors (src/ocx/git_http.cr) | the program served as git |
works |
| The export kept current | the hook on each check-in, and export |
works |
| One tool, one page (docs/cli-cgi-alignment.md) | one typed definition of each tool serves the command line, the web page and MCP (HISTORY.md decision 32) | works |
The gate, crystal run ci.cr (ci.cr): precepts, guards, the dependency ledger, coverage |
kept whole | works |
| Each project's Crystal docs built and served, and an index of Crystal's standard library to look symbols up in (trunk before the fork, c63c8afd39: src/docs_builder.cr, src/docs_cgi*.cr, src/stdlib_index_builder.cr; ticket fbcaa9a84e) | nothing yet | held: the maintainer's docs decision (ocx-console docs/ollama-planning.md) |
| Semantic search over docs, wiki, tickets, forum and code, from a local model's embeddings (trunk before the fork, c63c8afd39: docs/vector-search.md, src/vec_*.cr) | nothing yet | held: the maintainer chose Fossil's own full-text search first, a setting with no code, and still wants semantic search later (ocx-console docs/ollama-planning.md) |
Past parity
What ocx2 does that ocx at a46d73f5bf never did; rows above once listed some of these as ocx's.
| On ocx2 | Trunk at a46d73f5bf |
|---|---|
Onboard a project: project |
ocx's import-project made one from git |
A remote host running work: ocx2 daemon on the host's clone, as a node user whoever has the agent machine's command line registers for and an admin approves with one press (HISTORY.md decisions 73 and 76) |
nodes were planned in ocx's own plan, not built |
Local models measured on saved tasks: the battery (battery/main.cr), local models doing saved tasks with the tools over MCP, scored from the server, its runs Fossil tech-notes |
model-evals/, and its Ollama loop passing 5 of 8 trials, came before the fork; ocx at a46d73f5bf has neither |
A bounded subtask handed to a local model under its own user (ocx.delegate): once a pattern for the native agent, such as run/gemma, is written, a person holding admin or setup can hand one off with create --to POST in the delegating agent's thread, naming the pattern and a user of its own (not yet tried); an agent sending it itself waits on a run's user holding a password (HISTORY.md decision 75), in docs/backlog.md |
no file of ocx's mentions it; it was a tool the ocx branch planned |
Not copied
| Trunk | Why |
|---|---|
| Password files and logins provisioned from the console | an administrator supplies run users' passwords in the node's credentials file (USAGE.md, "Run a node"); a node user is approved from its asker's link (HISTORY.md decisions 73 and 76) |
| Running unconfined when bubblewrap is missing | a run without a sandbox runs only where the host allows it (ROOT/settings/unconfined) |
The pre-fork ocx's MCP tools, about 90 of them (read_file, search_context, apply_patch, replace_range among them), and those that justified no place in ocx2 (shell, web_fetch, delete_file, revert_to_clean, fossil_sqlite, a model consult, embeddings) |
ocx at a46d73f5bf has none of them; ocx2's eleven checkout tools give what a battery trial asked for, a run's sandbox and its pattern's command the rest (HISTORY.md decision 67), and a line-range edit waits on the battery showing a need |
| Runner code per hosted agent (src/ocx/runners/) | OCX's code knows no hosted agent (HISTORY.md decision 40): how each runs is a pattern. OCX's native agent for local models is OCX's own program, not knowledge of another's |
| The console's views as an HTML page of their own | the page is Markdown in Fossil's skin (HISTORY.md decision 33) |
The question as text headed Question: … For:, ocx's ticket report src/ocx/reports/open-questions.sql and its shared parser cases |
what OCX parses is JSON with a schema (the structure precept, spec/guards/structure_spec.cr), so a question is a typed OCX message; one tool's answer serves the page, Stone and the command line, so no second implementation needs shared cases; no served repository here has the report installed |
| A post that waits on a person because they took part in its thread (ocx's reviewer queue of waiting posts, src/ocx/reviewer.cr) | a question names whom it is for, so only questions wait on a user; an agent's waiting posts are its deliveries, and thread |
The text notations: OCX done: and OCX failed: reports, OCX run: requests, OCX note:, and an OCX stop anyone could post |
JSON messages, started and ended and kept logs replace them, and a stop needs admin, setup or the run's R sender, so authority comes from who sent it |
| The daemon's pipe, lock, re-exec on accept, and its page's start and stop (tools/ocxd.cr, src/ocx/daemon.cr) | ocx's pipe and page start/stop controls are not copied; OCX now has its own daemon with a lock, waiting on chat and returning once another release is served so its service manager starts the new one (HISTORY.md decision 125); each watcher lives for its run |
| Listening to other records: listen and unlisten notes and their index (src/ocx/listeners.cr) | a run per record serves it, and a branch is process.checkins; what a session hears is its run's own fields, never notes elsewhere |
Session definitions naming a kind, a runner, a lifetime and on: request (src/ocx/definitions.cr) |
a run states its command, and manual, session and deliveries say how it lives (HISTORY.md decisions 40 and 42) |
| OCX committing what an agent left in its tree after a turn, and posting what it printed as its turn (src/ocx/cli_runner.cr) | the agent saves and posts for itself; keep.stdout_when: always has the node post what it printed where a pattern wants that |
| The outbox, and workspaces cloned from a repository file (src/ocx/outbox.cr) | clones are over HTTPS |
| Peers, read-only views of the projects a project depends on | ocx used none; an admin's pattern can bind one read-only |
workspace run, workspace show and the thread tool (tools/workspace.cr, tools/thread.cr) |
ocx used none of them; create --title and Fossil's forum page start threads |
reviewer --wait and --every, and task --wait's sync loop |
timers; watchers give what complete pulls bring |
task --cli and --provider, one-shot answers |
ocx itself had replaced them |
| The In work, Done recently, Check-ins on agent branches and Posts in threads views (src/ocx/activity.cr) | Fossil's own timeline and forum pages show these (HISTORY.md decision 3) |
| The script that rewrote times into the viewer's timezone (src/ocx/clock.cr) | Fossil's pages show times, and OCX's messages carry none for people; US Eastern is one of the writing conventions, step 21 |
| Scanning the process table for sessions and terminal sandboxes (src/ocx/processes.cr) | the node knows the runs in its care, and status reads each one's processes from its watcher down |
The release token, deploy --install and --served |
trust on first use, the Referer check and serve (scripts/serve.cr) cover them |
| OCX's own card composer, sync client and delta decoder (src/ocx/compose.cr, sync.cr, delta.cr) | internals: ocx2 runs fossil and reads its SQLite directly, behind operations named for what they do |
| Trunk's alignment of the command line and the web page as a guard (docs/cli-cgi-alignment.md) | one typed definition per tool (HISTORY.md decision 32) leaves nothing to align |
Order to build
The parity audit's order (tech-note
bb2af9185e, its
parity-order.md) has 22 check-ins; check-ins name them "parity step N".
Built: steps 1, 5 and 6 (6d5ac4cf8c and f3138e4316), 7, 8, 10, 11, 13, 14,
15, 17, 19 and 20; step 18's shell became terminal and attach
(decisions 82 and 83). Steps 12 and 21 are written: their pages wait for an
admin to save them, once a release holding ends, and post's questions
and decisions (decision 90), is accepted. What is left, in this order:
| Step | Check-in | Waits on |
|---|---|---|
| 2 | run/claude carries its conversation (--continue) |
– |
| 3 | a live trial of run/claude and run/codex on a thread |
2 |
| 4 | comparing agents on one task | 3 |
| 12 | builds and CI as patterns: run/build, run/ci, run/bq2-build, saved and tried live |
an admin saving them; run/bq2-build's cache on 9 |
| 21 | writing conventions in each agent pattern, saved and tried live | an admin saving them; 3 |
| 9 | a user's cache on a project, lower priority | – |
| 16 | working or idle per run | – |
Not in the order, and still to do: Stone showing the questions, live streaming, and
the pattern run/gemma with its first proof on the server.
The question of steps 16 and 22 is answered: a turn-per-post session ends
only when stopped or at its wall, and A kept one process per post where B
made the session one looping process, so deliveries: start could go. The
maintainer, 33e7f8304e (2026-10-20): "There's no reason to restrict Claude
sessions to one mode or the other. It is more contextual than that." Both
ways stay, chosen per run by deliveries (HISTORY.md
decision 90): step 22, which removed deliveries: start, is not built, and
step 16, which the order tied to keeping it, stays.