You are given a protocol's definitions and then questions. Answer from the text alone. Answer each question by number, in one to three sentences, saying what happens and why.

=== DEFINITIONS ===

Words, as Fossil uses them:
- Repository: one Fossil database file holding a project's whole history.
- Clone: a repository made from another with `fossil clone`.
- Server-code: 40 random hex digits identifying one repository file; a repository made again by `fossil clone` gets a new one.
- User: Fossil's account; its name is its login. Capability: a letter on a user, such as `a` (admin), `s` (setup), `i` (check in), `y` (write unversioned files).
- Default user: the user Fossil's command line acts as on a repository (`fossil user default`, `-U`).
- Receipt: the server's record of the user it received each artifact from.
- `R`: a capability letter Fossil does not define, which OCX reads as "may send runs".

## 2. Protocol version 2

Every message is a JSON object in a fenced block of a forum post or a ticket
change, carrying `"ocx": 2`. OCX version 2 reads no block carrying
`"ocx": 1`: before switching, stop every open version 1 run.

### 2.1 Who sends what, and what counts

The sender of any message is the user the server's receipt says it came
from, never a name written in it (Fossil: `/rcvfromlist`). OCX on a clone
asks the server with OCX's `receipt`, since a clone's receipts name only its
own pulls.

| Kind | May be sent by | Written where | Counts only when |
| --- | --- | --- | --- |
| `run` | a user holding admin or setup; or one holding `R`, within `ROOT/settings/capability-R.json` on the host of the repository it names (refusal 1) | a new thread, a reply, or a ticket change | OCX acts on it only on the repository whose server-code is `repository.server_code` and whose default user is `repository.default_user` |
| `stop` | a user holding admin or setup; or the user holding `R` that sent the run | where its run is | its run's OCX acts on it |
| `started`, `ended` | OCX on the run's repository, as its default user | where its run is | the server received it from the run's `repository.default_user` (or OCX wrote it into that repository itself); its `repository` equals the run's; and that user is not the run's sender |

The last rule is new. Version 1 counted a report received from the run's
`node`, and its text does not say who may be named there: a user holding `R`
could name itself, write its own `started`, and have its `ci` verdicts count.
In version 2, no report counts from the user that sent the run, so a run's
reports always come from an OCX other than its sender.

Why the run names the default user, and does not leave it to be found: the
server records, for each artifact, only the user it came from; Fossil's sync
sends the repository ID but does not use it ("The servercode argument is
currently unused", sync.wiki 3.4). So a server-code alone can vouch for
nothing, and only a user can sign a repository's reports. Who that user is
must be fixed before any report arrives, by someone allowed to send runs.
Three other places were weighed: the first report to arrive (anyone could
write it first), a capability letter for writing reports (its holders could
write any repository's reports), and a record binding server-codes to users
(a second store, with its own rule for who may write it). The run's sender
already decides what runs and as whom, so the sender also names whose reports
count, in full, in the message, as "Let the OCX message dictate" asks. The
repository's owner keeps their choice: OCX acts only when the run names the
default user its owner chose, so the sender and the owner must agree, and many
repositories may share one default user, since each run names its repository
by server-code. That is a clone with an owner, without the 1:1.

### 2.2 The run

A run's keys, in the order OCX reads them:

| Key | Holds | Required |
| --- | --- | --- |
| `ocx` | `2` | yes |
| `kind` | `run` | yes |
| `repository` | `{"server_code", "default_user"}`, below | yes |
| `objective` | text: what the run is for, and what counts as passing | yes |
| `workspace` | a list of steps (2.4); absent, the run gets none | no |
| `sandbox` | every key of 2.5; absent, it runs unconfined | no |
| `limits` | the keys of 2.6 it sets; absent, unlimited | no |
| `process` | the keys of 2.7 | yes |

`repository`:

| Key | Holds |
| --- | --- |
| `server_code` | the server-code of the repository that is to act on the run, in full: 40 lower-case hex digits. The server's repository, or a clone on any host. `status` and `poll` print it |
| `default_user` | the login of the default user OCX acts as on that repository: the user its reports must be received from. Never a user holding admin or setup (`hook` and `poll` refuse one) |

OCX on a repository whose server-code or default user is not the run's does
nothing with the run. A run whose `repository` has another form is refused by
OCX on any repository whose default user it names (refusal 2). A clone made
again gets a new server-code: runs naming the old one are answered by no one,
so send them again. Clone a repository, never copy its file: a copy keeps the
server-code.

A run's process, and every artifact it writes, act as `process.user`; every
report, kept log, verdict and unversioned file OCX writes for it acts as
`repository.default_user`. On a clone, that user's capabilities on the
server are the most OCX can do there, as with Fossil's own command line; on
the server's repository, OCX writes into the repository file directly, and
its default user holds no capability.

### 2.4 Workspace steps

Each step is `{"step": KIND, ...}`; a step that fails ends the run
`refused`, naming the step.

| Step | Arguments | Needs | Does |
| --- | --- | --- | --- |
| `directory` | `at`, within `$$root$$` | none | makes the directory, emptying what was there, readable by OCX's host account alone; sets `workspace` |
| `password` | none | none | takes the process user's password: on the server's repository OCX sets a fresh one; on a clone's host it reads it from the passwords file |
| `clone` | `into`, within `$$workspace$$` | `password` | `fossil clone` of the server, as the process user, remembering the password; sets `clone` |
| `checkout` | `of`, `into` | `clone` | opens a checkout of the check-in `of` names, resolved once; sets `tree`, `checkout` |
| `files` | `of`, `into` | none | writes that check-in's files, resolved in the run's repository, and nothing else: no clone, no password; sets `tree`, `checkout` |

A path is refused before any step (refusal 9) when it is not within the
place the table names, once links and `..` are resolved, or when a
`directory` is or holds another run's workspace in OCX's care.

### Process user (from 2.7)

`process.user`: the process user: the Fossil user the process acts as; never the run's default user, nor any run's default user an admin or setup sent, nor one holding admin or setup.

### 2.8 Stop, started, ended

| Kind | Keys |
| --- | --- |
| `stop` | `ocx`, `kind`, `run` (the run's hash in full) |
| `started` | `ocx`, `kind`, `run`, `repository` (the writer's `server_code` and `default_user`), `values`, `limits` (as applied) |
| `ended` | `ocx`, `kind`, `run`, `repository` (the same), `outcome`, `exit`, `note` |

| `outcome` | When | `exit` | `note` |
| --- | --- | --- | --- |
| `refused` | a refusal holds | absent | which, in plain text |
| `stopped` | a stop ended it, or came first | absent | absent |
| `exited` | its process exited | its code; 128 plus N for signal N | absent |
| `budget` | past a limit | absent | which limit |
| `lost` | OCX found its `started` but not the run in its care | absent | why |

A stop names no repository: OCX on the run's repository acts on it. A
second `started` or `ended` for a run is ignored: the first, in the server's
order, counts.

### 2.9 A run's life, and refusals

OCX writes `started` before it launches, so it launches at most once; on a
clone's host, only once the server has the `started`. Every run it acts on
gets one `ended`. When OCX starts on a repository, and whenever its owner
asks (`hook --default-user`, `poll --all`), it reads every open run naming its
repository: one with a `started` it does not hold in its care it answers
`lost`; one with a stop it ends; one with no `started` it decides as if it had
just arrived. A process user works for one repository: the
`repository.server_code` of the first run, in the server's order, that a user
holding admin or setup sent naming it. OCX runs one run at a time for each
process user; another waits, unstarted.

Refusals, in order; the first that holds ends the run `refused`:

| # | Holds when |
| --- | --- |
| 1 | no user holding admin or setup sent it; or a user holding `R` sent it, and `ROOT/settings/capability-R.json` allows no such run, or the run asks more than it allows: no sandbox, the network or a Linux capability not allowed, a path to read outside its own `$$workspace$$` and the paths listed, a path to write outside its own `$$workspace$$`, a home, a secret, a `password` step, a path with `..`, a `directory` not ending in `$$run$$`, or a limit the file caps left out or set above the cap |
| 2 | a required key is missing, a key has the wrong type or form, or a key version 2 does not define |
| 3 | a step kind 2.4 does not have, a step whose needs are not met before it, or a value not set by then |
| 4 | `process.user` is the run's default user, any run's default user that an admin or setup sent, or holds admin or setup |
| 5 | `process.user` works for another repository |
| 6 | a `password` step, and OCX on a clone's host holds no password for the process user |
| 7 | no `sandbox`, and the host has no `ROOT/settings/unconfined` |
| 8 | a sandbox key or a limit OCX cannot provide |
| 9 | a path outside where 2.4 and 2.5 allow |
| 10 | a workspace step fails |

A run its own default user sent gets nothing from OCX: no report of its could
count. A run written straight into a clone reaches the server as received
from that clone's default user, so it is such a run: send runs to the server.

## 4. What changes for a reader

1. A person or a program asks for work by posting a run, a JSON block in a
   forum post or ticket change, as a Fossil user holding admin or setup, or
   holding `R` within what the acting host's owner allows.
2. The run names one repository of the project by its server-code, and the
   default user OCX acts as there; only OCX on that repository, the server's
   through its hook or a clone through `poll`, acts on it, and only if both
   match its own.
3. The run's process acts as its own Fossil user, `process.user`, never a
   default user and never one holding admin or setup, inside the workspace,
   sandbox and limits the run states in full.
4. OCX writes the run's `started` and `ended` as the repository's default
   user, whose capabilities on the server, chosen by whoever has that
   repository's command line, are the most OCX can do there.
5. Who sent anything is the user the server received it from, and a report
   counts only if the server received it from the run's default user, it
   names the run's repository, and that user did not send the run.

=== QUESTIONS ===

Setting: hosts H1 and H2 each hold a clone of the project. H1's clone has server-code aaaa…a (40 digits) and default user lab-1. H2's clone has server-code bbbb…b and default user lab-1. A run R1, sent by stone (who holds setup), names `"repository": {"server_code": "aaaa…a", "default_user": "lab-1"}` and `"process": {"user": "builder", ...}`.

1. Which host's OCX acts on R1, and what does the other host's OCX do with it?
2. A third host, H3, has a clone whose server-code is also aaaa…a (its file was copied from H1's) but whose default user is lab-9. Does OCX on H3 act on R1?
3. mallory, who holds only check-in (`i`), replies to R1 with an `ended`, `exited`, `exit` 0, naming R1 and repository aaaa…a, lab-1. Does it count?
4. zed holds `R`. zed sends a run R2 naming `"repository": {"server_code": "aaaa…a", "default_user": "zed"}`, then posts a `started` for R2 itself. Does OCX on H1 act on R2? Does zed's `started` count?
5. Could a run name `"process": {"user": "lab-1"}` and be run? Why?
6. What sets the most that OCX on H1 can do on the server, and who chose it?
7. A run's workspace has the step `{"step": "clone", "into": "$$workspace$$/clone"}`. What is `$$clone$$`, and is it the repository named in the run's `repository`?
8. H1's clone is deleted and made again with `fossil clone`. A new run naming the old server-code aaaa…a arrives. What happens?
9. Why does a run name `default_user` instead of OCX finding the user from the server-code?
10. Who may send a `stop` for R1, and which keys does it hold?
