Fossil's words keep Fossil's meanings. These are version 2's words, from the proposal, with the maintainer's 2026-11-02 meaning of node. The protocol holds the rules, not this glossary. The refresher checks a reading.

• Repository: one Fossil database file holding a project's history.
• Clone: a repository made from another with fossil clone.
• Server: the Fossil server at the project's URL; in the maintainer's words, “a publicly hosted Fossil server providing synchronization”.
• The server's repository: the repository the server serves, which every clone syncs with; Fossil's parent repository.
• Server-code: 40 random hex digits Fossil gives a repository file when fossil new or a clone over HTTP makes it. Copying the file keeps it.
• Project code: 40 hex digits every repository of one project shares.
• User: a Fossil account (fossil user). A person or program acts as one.
• Login: a user's name.
• Default user: the user Fossil's command line acts as on a repository (fossil user default, -U).
• Capability: Fossil's letters on a user, the outer limit of what it may do. Admin (a) and setup (s) name Fossil's capabilities.
• Receipt: the server's record of the user it received an artifact from, with the time. A clone's receipt records its own pull, not the original sender.
• Artifact: one immutable Fossil record, named by its hash. An edit makes another artifact.
• Hash: the SHA1 or SHA3-256 of an artifact's content, in hex. A unique prefix can name it in Fossil.
• Check-in: Fossil's record of a commit: files, comment, author and parents.
• Checkout: a directory of files opened from a repository at a check-in.
• Branch: Fossil's named line of check-ins, as its branch tag and timeline show it.
• Tag: a Fossil name or value attached to an artifact; raw tags never become symbolic names, and non-propagating tags apply to one artifact.
• Wiki page: Fossil's named page, with each edit kept as an artifact.
• Forum post, thread: a post is a Fossil artifact; a thread is its root post and replies.
• Ticket, ticket change: a ticket is the changes sharing its ticket-id; a change is an artifact setting its fields, including a comment.
• Unversioned file: a named file Fossil syncs outside check-ins; it can be replaced.
• Sync, push, pull: moving artifacts between repositories.
• Backoffice: Fossil's work after a page answers, in a process of its own.
• After-receive hook: the command Fossil's backoffice runs for received artifacts. OCX installs Fossil's git export; it schedules no runs.
• R: a capability letter Fossil does not define, which OCX reads as “may send runs” with the isolation its pattern sets.
• Host: a computer holding a repository OCX acts on.
• Node: a host where OCX's daemon acts on runs, named by its hostname, as x86-1 and aarch64-1 are. Never a login, key, value or directory. This is the maintainer's meaning of 2026-11-02.
• The server's host: the host the server runs on.
• Host account: a Linux account on a host.
• Person: a human.
• OCX message: a JSON block in a forum post or ticket change, carrying one kind of content in an envelope. Protocol version 2 defines it.
• Stop: a message asking OCX to end the run its envelope's re names.
• Publish: a message asking OCX to retry a completed run's unfinished publications without launching its process.
• Started, ended: reports answering a run by re: that it is about to launch, and that it is over, with its outcome.
• Run: an OCX message whose content is run; the artifact's hash names it. It asks for one process toward an objective.
• The run's clone: the existing repository the run's clone names, which acts on it. In this tree it is a daemon's clone, not the server's repository.
• OCX on the run's clone: the daemon and watcher acting on that repository's runs.
• The clone's user: the Fossil user OCX acts as on the run's clone, named by the envelope's to. Its reports must be received from it.
• The process's user: the Fossil user a run's process acts as, named in process.user.
• The process's clone: the new repository the workspace step clone makes for the process, signed in as the process's user. It is not the run's clone.
• The clone's owner: whoever may write ROOT/settings/ on its host; that person chooses the clone's user. “Owner” here means only this.
• Envelope: the part holding ocx, to, re and one key naming the content's kind; it carries the content unread.
• Content: what the message holds under its one kind key.
• to: the envelope's key naming the user asked to act.
• re: the envelope's key naming the message answered, by hash.
• Layer: one of the protocol's four layers: Fossil, envelope, content, patterns. A run's workspace, sandbox, limits and process are its parts.
• Value: something OCX knows, named $$name$$ in a run string and put in its place before use. A password is not a value in this code.
• Step: one action of the workspace, such as making a clone; never a tool, which names an OCX command.
• Process: the program running for a run, with the command and whole environment it names.
• Kept logs: the ends of the process's STDERR and STDOUT OCX keeps and posts where the run is.
• Manual run: a run whose process.manual is true, waiting for a person to start it with ocx2 run on its clone's host.
• In OCX's care: a run OCX is preparing, running or publishing, from just before workspace preparation until its final publication is confirmed.
• Session: a run with process.session true, given the posts, changes and check-ins it subscribes to.
• Objective: what a run is for and what counts as passing; also what a verdict is judged against.
• Pattern: text at a URL, conventionally the wiki page run/NAME, holding run content create copies. Of the project's wiki, the newest version received from admin or setup counts.
• Subscription: what a session asks to hear, filtered by place, sender and branch; with ends, counted ended reports too.
• Delivery: one artifact given to a session as a JSON line, in server order, at most once while its watcher lives.
• Workspace: the directory its steps make for a run's process's clone, checkout and files.
• Sandbox: what the process sees and may do on the host.
• Limits: how much the process may use.
• Verdict: a raw tag judging a check-in against a named objective: audited for a person or agent, ci for a program. Verdicts defines writing and reading.
• Daemon: the one program on a node that waits on chat, pulls each project clone whole, publishes completion numbers and hands runs to watchers. A service manager restarts it.
• Watcher: a detached ocx2 watch process holding one run's lock, preparing and launching it, giving deliveries and publishing its results. It ends only its own run.
• Hook: Fossil's after-receive command. OCX's installed hook keeps the git mirror current; it is not the daemon.
• Run state: the durable per-run file: taken prevents relaunch, ending holds the report to retry and done settles it.
• Completion number: a clone's highest receipt after a whole pull, published by rename for watchers to read through. Completion and republication after ended are built; see the protocol.
• Saved: of a run's work, held by the server: no checkout change, extra file or stash, and no artifact in its clone left unsent. Removal once saved uses this meaning.
• Question, decision: a question asks a Fossil user; decisions record answers, and a confirmer's decision closes it. See questions.

Tools

• Card: a card/NAME wiki page in any repository, named by that repository's project name and NAME, whose JSON says what indexed repository records to find, which columns to show, and what sentence to say. The card tools answer it across named repositories; each front end reads the same data.

• Receipt service: the receipt reader, scripts/receipt-reader.cr, the maintainer's small read-only program that answers who sent an artifact from the served repositories.

• Launcher: scripts/confine.cr (confine), which serve starts and which starts the ocx2 daemon, the receipt reader and the web page's /receipt path, each in a fixed sandbox.

• Tool: one thing OCX does, defined once: what it does, who may do it, and what it leaves in Fossil. A convenience: the same artifacts written by other means count the same. USAGE.md lists them; protocol version 2's tools, those protocol version 2 needs. In the code each is a command.

• Entry point: how a caller reaches the tools: the CLI (ocx2), the CGI (ocx2-cgi, the OCX page, at /ext/ocx2-cgi under the repository's address in Fossil, its header linking console) and MCP (ocx2-mcp, for an agent). The CLI reaches every tool; the CGI and MCP each withhold some, saying why. Each turns its caller's input into the tool's, and lays out the answer its own way; status names it.

• Working branch: the branch OCX's tools commit an agent's work on, never trunk. save uses a checkout's branch named agent/…, or else one named for the caller and the checkout, the same each time, shown by context before any save. No run or started names it. With its user's password, an agent may commit anywhere with Fossil (PLAN.md, "Branch contributions").

• Trial: performing a run's definition by hand with run --trial, writing nothing to Fossil. Not built: run takes no --trial.

• Register: what register does on the asker's own machine, asking for a login like Fossil's self-registration, but the user is made only when an admin approves (USAGE.md, "Ask for a login").

• Approve: what approve does with an admin's one press on the asker's link: make that user holding exactly the capabilities asked, never admin or setup, and never change a user it did not make. If an admin opens only a link the asker itself printed, only the asker's code can collect the password.

• Collect: what collect does: give the asker an approved login's password, for the code whose SHA-256 its link named.

• Input, output, context: a tool's input is what its caller gives it, its output what it found or made, and its context who calls and from where (not the context tool), which the entry point resolves; each is a type, its schema derived from it.

• Answer: what a tool returns, the same in every entry point: its log, its output (the result) when it ran to the end, and why it stopped.

• Log, operation: the operations a tool performed, in order, each typed with its operands, such as take_release with its root and name. Each either reads what the tool needs or changes something.

• List, help, status: list (what runs with no tool named, and what MCP's tools/list gives) shows every tool: what it does, who may run it and its input's schema. help adds the schemas of each output, the context and every answer, and where releases live. status shows who calls and from where, each setting with its source, and each run that has not ended and where it stands, as the record or the clone's completed pull says.

• Console: what console shows: a person's view, in the order of HISTORY.md decision 18: the questions waiting on them, those they may confirm answered, every other open question, then the runs of every clone's user an administrator's run names: those not ended and the five that ended last; each option a press of post. Each entry point lays it out its own way, a page of its own on the web, from questions, which answers the questions as data (decision 100). The maintainer's word, and trunk's (decision 98).

• Dry run: dry_run, which every tool's input takes (--dry-run on a command line): the same tool and answer, changing nothing. Its checks are performed, so it stops where the tool would stop now; its changes are only listed in its log.

• Project: a served repository made by project, empty or from git, with its git export, hook, ticket fields, clone's user and run users ready. See USAGE.md.

Judging check-ins

• Gate: the checks a check-in must pass, crystal run ci.cr: the guards, the specs and the coverage ratchet (no file may lose coverage). Green means it passed.
• Verdict: a tag on a check-in recording a judgement of it, pass or fail with a reason and the objective it was judged against: audited for a person's or an agent's, ci for a program's. Anyone may write one, but a verdict on your own check-in never counts (protocol version 2's verdicts).

Releases

• Release: a copy of the built programs of one check-in, named for its first twelve hex digits, with the gate's result (gate.txt), the source (source.txt). In a run, $$release$$ names the release OCX used when the run started, even after a later accept (section 2).
• Release root: the directory holding releases, the links to them and OCX's own directory: /var/lib/ocx/agents-daemon on the staging server's host; daemon, watch and run need one on the agent machine.
• Staged area: staged/ in the release root. A release is written there once; whoever stages owns it.
• Stage: what stage does: check, build, write the release into the staged area, smoke it, and offer it as next. Staging never changes what is served.
• Next: the link next in the staged area, naming the release offered for acceptance.
• Pre-release candidate: the release offered as next, which Fossil's page ocx2-cgi-next runs, for review before it is accepted.
• Active release candidate: the release served (current), which Fossil's page ocx2-cgi runs.
• Staging server: the host ollama.openbeagle.org and the servers on it: low stakes, public data, an isolated and untrusted host, its work recoverable from Fossil's records on other clones (HISTORY.md decision 31).
• Accept: copy the next release into the root and serve it as current, keeping what was current as previous. Only a user holding setup accepts, so whoever stages cannot choose what runs. Through ocx2-cgi-next, it accepts only a first release, while none is served, trusted on first use.
• Current, previous: the links naming the release served at ocx2-cgi and the one served before it.
• Rollback: serve the previous release again. A second rollback undoes the first.
• Smoke: run a program of the release with no arguments and an empty environment, and require it to answer with its usage.

Building OCX

• Slice: a check-in that implements one specific, justifiable function, passes the gate, and has coverage demonstrating that function. docs/slices.md sets out each slice.