You are given part of a draft protocol's vocabulary: its vocabulary section and its summary for a reader. Answer from the text alone. Answer each question by number. Where the text does not say, say so.

=== TEXT ===

## 1. Vocabulary

### 1.1 The overloads today, and how each goes

| Word | Senses today | Version 2 |
| --- | --- | --- |
| node | (1) the run key `node`, holding a login; (2) "a node", OCX acting on a repository; (3) the value `$$node$$`, that login; (4) the directory `ROOT/node/`; (5) the sandbox key `ends_with_node`; (6) the options `create --node` and the installed hook's `--node`; (7) "the node's account", a host account; (8) "the node's owner", a person; (9) "works for another node", a login | The word is gone from messages, tools, files and documents. (1) becomes `clone.server_code` with `clone.user`; (2) "OCX on the run's clone", or just "OCX" where one run is in view; (3) `$$clone_user$$`; (4) `ROOT/runs/` and `ROOT/owner/`; (5) `ends_with_parent`; (6) `--clone`, `--clone-user`, `--login`; (7) "OCX's host account"; (8) "the clone's owner"; (9) "works for another clone's user" |
| clone | (1) a repository made by `fossil clone`; (2) the run key `clone`, a server-code prefix; (3) the report key `clone`, a full server-code; (4) the workspace step `clone`; (5) the value `$$clone$$`, a path; (6) "the run's own clone", meaning the process's | One sense, Fossil's: a repository made from another with `fossil clone`. Every use says which clone. "The run's clone" is the one the key `clone` names, and it acts on the run. "The process's clone" is the one the step `clone` makes in the workspace, at the path `$$process_clone$$`. The one exception: the key `clone` may name the server's repository, which `fossil clone` may not have made (section 5, the question) |
| user | (1) a Fossil user; (2) `process.user`, "the run's user", "run user"; (3) `$$user$$`; (4) the sandbox's `uid`, a Linux user; (5) a person ("the user with cli access"); (6) the CLI's `--user` and `create --user`, two meanings on one command line | "User" means only a Fossil user, and always says whose: "the clone's user" (`clone.user`, the user OCX acts as on the run's clone) or "the process's user" (`process.user`). A person is "a person" or a role (an admin, the asker, the clone's owner). An operating system account is "a host account". `create --user` becomes `--process-user`; `$$user$$` becomes `$$process_user$$` |
| login | (1) a user's name; (2) the user itself, "the node's login"; (3) asking for a user, "Ask for a login"; (4) signing in (Fossil's page `/login`) | Only (1), as in Fossil's user table: a user's name. "The node's login" becomes "the clone's user". "Ask for a login" becomes "ask for a user" (Fossil's own self-registration page is `/register`). Signing in is "sign in", and the page keeps its name `/login`. `--login NAME` stays on `register`, `poll` and `hook`, where it names a login |
| layer | (1) a level of a run message; (2) `create`'s "three layers" of fields; (3) "our persistent messaging layer" (the maintainer, of Fossil) | Dropped from the protocol: a run's parts are its keys, read in the order section 2.1 lists. `create`'s three become "three sources, each over the one before". (3) stays as the maintainer's own words |
| check | (1) "the node's check", acting on every open run; (2) `poll --check`; (3) a `ci` verdict, "a program's check"; (4) the gate's checks; (5) check-in | Fossil's check-in keeps its word. (1) and (2) become "acting on every open run", with the option `poll --all`; (3) becomes "a program's test"; (4) "the gate's tests". "Check" stays only as a plain verb |
| server | (1) the maintainer's "a publicly hosted Fossil server providing synchronization"; (2) the repository it serves; (3) its host; (4) the value `$$server$$`, a URL | "The server" is (1) only, as `fossil server` runs one. (2) is "the server's repository", (3) "the server's host", (4) `$$server_url$$` |
| run | (1) the message, and the request it makes; (2) the tool `run`, which starts a manual run; (3) the key `run`, the run's hash; (4) the value `$$run$$`, the same hash; (5) "dry run" | (1), (3) and (4) are one sense: a run, named by its hash. The tool becomes `start`. (5) stays, because `--dry-run` is Fossil's own option |
| session | (1) a run whose `process.session` is true; (2) the sandbox key `own_session`, a Linux session | (1) stays, the maintainer's word. (2) becomes `isolate_terminal` |
| capabilities | (1) Fossil's letters; (2) the sandbox key `capabilities`, Linux's | (1) stays. (2) becomes `linux_capabilities` |
| files | (1) the workspace step `files`; (2) the sandbox key `files`, files made for the process; (3) the limit `files`, a file's size | (1) stays. (2) becomes `created_files`, (3) `file_size` |
| checkout | (1) Fossil's check-out, a directory; (2) the value `$$checkout$$`, a check-in's hash, while `$$tree$$` is the directory | `$$checkout$$` is the directory, as Fossil's word says; `$$checkin$$` is the check-in's hash; `$$tree$$` goes |
| project | (1) Fossil's project (its project-name, project-code); (2) the value `$$project$$`, the last part of the server's URL, which may differ from the project-name | `$$repository_name$$`: the name of the server's repository |
| checkins | the process key holding branch names | `branches` |
| shares | files a build leaves, shared as Fossil unversioned files | `unversioned_files` |
| account | (1) a host account; (2) a Fossil user (the maintainer's "default account permissions") | (1) is always "host account", both words. In OCX's own writing, (2) is "user" |

### 1.2 Every term, version 2

Fossil's terms keep Fossil's meaning. "Plain" means an English phrase that
needs no definition. NEW TERM needs the maintainer's approval. No new word is
coined below, but every renamed key, value, tool, option and directory is
still a name for the maintainer to approve.

| Today | What it means | Version 2 | Source |
| --- | --- | --- | --- |
| repository | a Fossil database file | repository | Fossil |
| clone (Fossil's) | a repository made from another | clone | Fossil, `fossil clone` |
| the served repository, "the server" | the repository the project's Fossil server serves, which every clone syncs with | the server's repository | Fossil, `fossil server REPOSITORY` |
| node | OCX acting on a repository | OCX on the run's clone; "OCX" when one run is in view | plain |
| `node` (key), the node's login, node user | the user whose reports count, and whose OCX may act | `clone.user`, "the clone's user": the Fossil user OCX acts as on that clone | Fossil, user; on a clone that `poll` made, its default user (`fossil user default`) |
| `clone` (key, optional prefix) | which repository acts | `clone.server_code`, required, all 40 digits | Fossil, server-code |
| `clone` (report key) | which repository wrote the report | `clone`, the same object as the run's | Fossil, server-code |
| `process.user`, run user, the run's user | the Fossil user the process acts as | `process.user`, "the process's user" | Fossil, user |
| `$$node$$` | the node's login | `$$clone_user$$` | |
| `$$user$$` | the run's `process.user` | `$$process_user$$` | |
| `$$server$$` | the server's URL | `$$server_url$$` | |
| `$$project$$` | the server's repository's name | `$$repository_name$$` | |
| `$$clone$$` | the path of the clone the step made | `$$process_clone$$` | |
| `$$tree$$` | the directory of the check-in's files | `$$checkout$$` | Fossil, check-out |
| `$$checkout$$` | the check-in's hash | `$$checkin$$` | Fossil, check-in |
| `$$root$$`, `$$run$$`, `$$release$$`, `$$workspace$$`, `$$secret:NAME$$` | as today | unchanged | |
| layer | a level of a run | dropped: "a run's keys" | plain |
| envelope | the keys every message carries | envelope (approved 2026-10-13) | |
| value, step, process, kept logs, manual run, in its care, works for | approved 2026-10-13 | unchanged; "in its care" becomes "in OCX's care" | |
| session, subscription, delivery, objective, pattern, sandbox, limits, workspace, verdict | as defined today | unchanged | |
| watcher | OCX's process for one run | watcher (NEW TERM, still awaiting approval; the maintainer uses it, 2026-10-16) | |
| `R` | Fossil's undefined letter, read as "may send runs" | `R` | Fossil, capability |
| node's owner | whoever may write the node's directory | the clone's owner: whoever may write `ROOT/owner/` on its host (the maintainer: "it makes sense for a clone to have an owner") | plain |
| the node's account | the host account OCX runs as | OCX's host account | plain |
| the node's check, `poll --check` | acting on every open run, not only on what arrived | acting on every open run; `poll --all` | plain |
| `ROOT/node/` | locks, inboxes, the hook's log, `r-senders.json`, `unconfined` | `ROOT/runs/` (a lock per run in OCX's care, and a session's inbox), `ROOT/owner/` (`r-senders.json`, `unconfined`), `ROOT/hook.log` | plain |
| the tool `run` | start a manual run by hand | `start`; MCP `ocx_start` | plain |
| "server's node" | OCX acting through the hook on the server's repository | OCX on the server's repository | plain |
| `ends_with_node` | the process ends when the OCX process that started it ends | `ends_with_parent` | bubblewrap's `--die-with-parent` |
| `own_session` | the process cannot reach a terminal outside | `isolate_terminal` | plain |
| sandbox `capabilities` | the Linux capabilities kept | `linux_capabilities` | Linux |
| sandbox `files` | files made for the process alone | `created_files` | plain |
| limit `files` | the largest file a process may write | `file_size` | plain |
| limits `wall`, `cpu` | time from the launch; CPU seconds | `wall_time`, `cpu_seconds` | plain |
| `process.checkins` | the branches whose check-ins a session is given | `branches` | Fossil, branch |
| `process.shares` | files shared as unversioned files | `unversioned_files` | Fossil, unversioned file |
| file of passwords: `user`, `runs` | the clone's user's login; the process users' passwords | `login`, `process_users` | Fossil, login, user |
| config rows `ocx-node-key-LOGIN` | a pending `register` code | `ocx-register-key-LOGIN` | |

These stay as they are, each with one sense: tool, entry point, input,
output, context, answer, log, operation, list, help, status, dry run
(Fossil's `--dry-run`), working branch, trial, hook (Fossil's after-receive
hook, and OCX's `ocx2-hook`, which is one), register, approve, collect, poll,
gate, verdict, release and its words, receipt, backoffice, after-receive
hook.

## 4. What changes for a reader

A person or a program holding admin or setup, or holding `R` within what a
clone's owner allows, asks for work by posting a run. The run's `clone` names
the one clone that is to act on it, by its server-code, and the Fossil user
OCX acts as on that clone. OCX on that clone runs the process as the user in
`process.user`, a different user that is never a clone's user and never
admin or setup, inside the sandbox and limits the run states. OCX writes
`started` and `ended` as the clone's user, and they count only when the
server's repository received them from that user and they name that clone.
Every other repository ignores the run, and who sent what is never taken from
the message itself.

=== QUESTIONS ===

1. What is the thing that acts on a run, and how does a run name it?
2. Which user's reports count for a run, and why?
3. What is the difference between the user a run's process acts as and the user that writes the reports?
4. What does each of these words mean: `clone.server_code`; `clone.user`; the clone's user; the process's user; OCX on the run's clone; the run's clone; the process's clone; the server's repository; the server's host; the clone's owner; OCX's host account; host account; a person; works for another clone's user; in OCX's care; `$$clone_user$$`; `$$process_user$$`; `$$process_clone$$`; `$$server_url$$`; `$$repository_name$$`; `$$checkout$$`; `$$checkin$$`; `ROOT/runs/`; `ROOT/owner/`; `ROOT/hook.log`; `ends_with_parent`; `isolate_terminal`; `linux_capabilities`; `created_files`; `file_size`; `wall_time`; `cpu_seconds`; `branches`; `unversioned_files`; `start` (MCP `ocx_start`); acting on every open run (`poll --all`); a program's test; the gate's tests; three sources, each over the one before; sign in; `--clone`; `--clone-user`; `--process-user`; passwords file keys `login`, `process_users`; `ocx-register-key-LOGIN`.
5. Is any word used in two senses?
