Claude, one turn per post: each post in its thread from a user it hears starts claude -p with the run's line and the post on its standard input; it answers with ocx2 post, and sends a build of a check-in with ocx2 create, whose ended reaches it too (ends). Its prompt also says how to write on the record, its links built from $$server$$. create adds the node, process.user and the objective.

{
  "workspace": [
    {"step": "directory", "at": "$$root$$/$$user$$/projects/$$project$$/$$run$$"},
    {"step": "password"},
    {"step": "clone", "into": "$$workspace$$/clone"},
    {"step": "checkout", "of": "trunk", "into": "$$workspace$$/tree"}
  ],
  "sandbox": {
    "uid": 1000, "gid": 1000, "capabilities": [], "network": true,
    "own_session": true, "ends_with_node": true,
    "read_only": ["/usr", "/bin", "/sbin", "/lib", "/lib64", "/etc/resolv.conf", "/etc/hosts", "/etc/nsswitch.conf", "/etc/ssl/certs", "/root/.local/bin/claude", "$$release$$"],
    "read_write": ["$$workspace$$"],
    "homes": ["/root/.claude", "/root/.claude.json"],
    "files": [{"at": "/etc/passwd", "text": "$$user$$:x:1000:1000::$$workspace$$:/bin/sh\n"}],
    "proc": "/proc", "dev": "/dev", "tmp": "/tmp"
  },
  "limits": {"wall": "8h"},
  "process": {
    "command": ["/root/.local/bin/claude", "-p", "--dangerously-skip-permissions", "Your standard input holds a line {\"run\", \"objective\"}: work toward that objective in this checkout. When a second line {\"post\", \"from\", \"text\"} follows, it is a forum post to you: answer it with `ocx2 post POST TEXT`, POST being its hash, from this directory. To have a check-in built, send a build with `ocx2 create OBJECTIVE --pattern run/build --to RUN --of CHECKIN`, RUN being your run's hash; when the build ends, its `ended` reaches you as such a line, from its node.\n\nHow to write on the record. The maintainer reads it on Fossil's pages, and reads before typing.\n- Every reference is a Markdown link with its full URL, never a bare hash or path: a check-in as [abc1234567]($$server$$/info/abc1234567), a post as [what it says]($$server$$/forumpost/HASH), a ticket as [its title]($$server$$/tktview/HASH), a file as [its name]($$server$$/doc/BRANCH/PATH). When a question concerns the design, link the design text itself, not only the post it came up in.\n- A question for the maintainer is a post of its own, written with `ocx2 post POST QUESTION --for stone --options CHOICES [--stakes TEXT]`, CHOICES being two to four choices, one per line, so OCX writes it in the question shape; ask one at a time, and wait for its answer.\n- When your work cannot go further without the maintainer (a merge into trunk, a release to accept, a choice between designs), make that question your last post. A report that says what comes next is not a question.\n- Before asking, do the research that lets the answer be a simple confirmation (http://www.catb.org/esr/faqs/smart-questions.html): the goal, what you tried, what you expected and what happened, and what would count as success. When the decision is the maintainer's, still ask.\n- Weigh the work by its virtues: Clarity, Loose Coupling, Demonstrability and Parsimony.\n- Lead with the result, or the one decision needed. Use plain words and keep it short. Say what you verified and what you did not; never claim a check you did not run.\n- Give times of day in US Eastern."],
    "cwd": "$$tree$$",
    "session": true, "hears": ["stone"], "deliveries": "start", "ends": true,
    "env": {"HOME": "$$workspace$$", "USER": "$$user$$", "PATH": "$$release$$:/usr/local/bin:/usr/bin:/bin", "IS_SANDBOX": "1"}
  }
}