Protocol version 2 defines the artifacts; the tools are conveniences. The same messages written by other means count the same. USAGE holds the inputs and answers of every tool.

The tools

• release reads the release root found as accept and rollback find it, on the command line, MCP and the served repository's HTTPS page /ext/ocx2-cgi/release. It reports current and previous, each null or its name and every inventory file's SHA-256. With a release name and file name it gives a listed file's bytes as base64 in the ordinary answer. Only current and previous may supply files; unlisted files and names holding .. or / are refused. Only signed-in setup logins or builders in the root owner's settings/builders.json may read either. It writes nothing, including on dry runs or refusal. USAGE gives the fields and limits. Client follow is not built here.
• create writes a version 2 envelope holding run. --login supplies its to; --to still names a post to reply to. --clone supplies the full server-code, and --process-user names the process's user. The retired create --user is refused with that replacement; the caller's --user goes before create. A pattern holds content alone, never an envelope or version 1's keys. Fields merge over the pattern, object by object. --of sets each files step's check-in, or the run's of if it has no such step. The address comes from the one local daemon clone or the published clone files. On the server it refuses that repository's code where no daemon acts. On the served repository admin or setup may have a process's user made and its password approved for the clone's user, only after all checks that read, including resolving --to or --ticket. --reset-password resets an existing process's user's password only when explicitly asked. From a checkout it pulls, writes a reply or ticket change and pushes as the caller; its default clone is that checkout's own. It makes no user and starts no new thread.
• run RUN --repository CLONE starts a manual run on the clone's host. This tool is still named run; the proposed start is not built. It needs local setup, the project credentials and a completed pull. It checks the address and state, then hands it to watch --by-hand. The watcher locks and decides again. Duplicate handoffs never launch twice. A run already started, ended or in care is refused. A run from R alone still waits if another such run is in care; there is no wait for another run of the same process's user.
• watch RUN SERVER CREDENTIALS --repository CLONE [--by-hand] holds one run's lock, checks its state, prepares the workspace, posts started, launches, gives deliveries and acts on stops. It publishes ended before logs, files and verdicts, keeping durable publication state. The daemon or run normally starts it.
• daemon serves the host's project clones. It reads ROOT/settings/credentials/NAME.json and uses ROOT/state/clones/NAME.fossil. At start and each minute it collects approved logins and makes missing clones, checks capabilities, prepares the default user and named remote, and publishes clone addresses when allowed. It pulls whole, publishes completion numbers and hands unsettled runs to watchers, then waits on Fossil's chat. Nothing restarts it after failure: a person does, as failures, item 20 says. There is no poll tool.
• attach joins a process whose terminal is true. Leaving it does not stop the process.
• stop writes {"ocx":2,"re":"RUN-HASH","stop":{}}. The watcher acts after a completed pull; writing it starts no process on the server. A stop written elsewhere gets a refusal there naming the run's thread or ticket; it never counts as a stop on the run.
• post writes plain text in a thread or ticket, refusing text holding an OCX message. Its question and decision options write those kinds under the same version 2 envelope. The separate question guide holds their rules.
• thread reads a thread or ticket in server receipt order, including messages. From a checkout it pulls and asks the server for receipts.
• questions reads questions and their decisions from the tag index; console shows them and readable runs; console --state adds the runs in local care through the last completed pull. Neither writes anything.
• audit writes and reads back an audited verdict, refusing the caller's own check-in. unaudited lists public check-ins changing files without any counted audited verdict, pass or fail alike. Verdicts gives the reading rules.
• receipt answers who the server received each requested artifact from, their capabilities, receipt number and row number, or that it has not received it; it can also answer capabilities and moderation for a user. Clones ask through a POST to /ext/ocx2-cgi/receipt, signed in through Fossil's login page. Requests put hashes or logins in the body. Any login holding Read (o) may ask about any artifact, x too for a private one; the asker refuses an answer about other artifacts or another user than it asked.
• register asks for a login, retaining a code and printing the approval link. approve lets admin make it without admin or setup capabilities. collect returns the approved password to the holder of the code, or to a signed-in login the approval allows; it never prints one in a normal page or command answer.
• status reads the caller, release, export hook, chat setting and open runs. --state adds the local daemon view through its last completed pull, clone server-code and enforced limits. Setup may see processes.
• hook installs Fossil's own git export hook; unhook removes it and older OCX hooks. Neither schedules runs, needs a clone user, or starts a process on an incoming run.

• tag_messages repairs missing or wrong ocx-message tags, in one control artifact as the caller. It needs i; it decides no run.

• import RUN --root ROOT needs setup and the stage run's full hash. It counts the run and its first reports by the server's receipts using the root owner's settings/builders.json, compares its execution fields with the named stage pattern, and checks the three shared files and inventory. It copies and smokes the release before offering next, removes the shared files. It is offered on the web page as a POST under its existing rules, never as a change on GET or dry run; CLI and MCP offer it too. All release tools share one root lock. USAGE gives the settings and file names.

The publish content reader is built; send its empty object as a message addressed to the clone's login with re naming the run. There is no separate command for it. See completion and republication.

Entry points and answers

The command line offers every tool. run, watch, daemon, register and attach are command line only. The web page withholds checkout tools and staging; MCP also withholds login approval and collection, secrets, hooks, export and project setup. USAGE names each tool's entry points and requirements.

Every tool takes dry_run: perform its checks and list its changes, writing nothing. Unknown input fields and text that is not UTF-8 or holds NUL are refused. Run content is checked for unknown keys too. The answer is {"ok", "tool", "dry_run", "log", "result", "stopped", "next_step", "took_ms"}. result is its output after completion; stopped says why it stopped, naming the field at fault.

A client passes over extra server answer fields, including nested fields added to results. It still checks required fields and that a receipt answers the artifacts or user actually requested. This tolerance does not relax run restrictions: an unknown run key is refused.