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 | OCX on the run's repository acts on it, from these senders alone; others are ignored |
| `started`, `ended` | OCX on the run's repository, as its default user | where its run is | the three rules below hold |

OCX on a repository acts on a run only if both are its own:
1. the run's `repository.server_code` is its repository's server-code, and
2. the run's `repository.default_user` is the default user it acts as.
If either differs, it does nothing with the run.

A `started` or `ended` counts only if all three hold:
1. the server received it from the user named in the run's
   `repository.default_user` (or OCX wrote it into that repository itself).
   A report received from any other user never counts, whatever it says;
2. its `repository` is the run's;
3. that user did not send the run.

The third rule is new. Version 1 counted a report received from the run's
`node`, and its text does not rule out a sender naming itself there: any user
who may post could send a run naming itself as `node`, write its own
`started`, and then have its `ci` verdicts against that run count (version 1,
section 3, and its verdicts' "Reading verdicts"). 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.

Every message's envelope is `ocx` and `kind`; every kind but `run` adds
`run`, the hash, in full, of the forum post or ticket change holding the run.
An edit of a post holding a message is a new message, named by the edit's
hash; the one edited stands until stopped.

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), and that
refusal counts when received from that default user. 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, and two repositories with one server-code and one default user
would both act.

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` | makes a new clone of the server's repository, the run's own, at `into`, with `fossil clone` signed in as the process user, remembering the password; sets `clone` to its path. It is never the run's repository, the one named in `repository` |
| `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); sent by a user holding admin or setup, or by the user holding `R` that sent the run |
| `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

A run's state is read from the repository (the `started` and `ended` that
count) and from whether OCX has the run in its care: from just before its
workspace is made until its `ended` is written.

| State | What arrives | Next | OCX writes or does |
| --- | --- | --- | --- |
| none | a run a refusal holds for | ended | `ended`, `refused` |
| none | a run, `manual` false | started | takes it into its care, makes its workspace, writes `started`, launches |
| none | a manual run | waiting | nothing |
| none | a run whose process user has another run in OCX's care | waiting | nothing, until that run ends |
| waiting | a user holding admin or setup starts it (`start`) | started | as above; a refusal then ends it `refused` |
| none or waiting | a stop, the run not refused by refusal 1 or 2 | ended | `ended`, `stopped` |
| started | a delivery | started | to its STDIN, or a process of its own (`deliveries` `start`), once the one before exited |
| started | a stop | started | ends the process |
| started | its process exits (not `deliveries` `start`) | ended | kept logs, then `ended`: `exited`, `budget` or `stopped` |
| started | a process exits (`deliveries` `start`) | started | kept logs |
| started | a stop, or past `wall` (`deliveries` `start`) | ended | ends its process, kept logs, `ended` |
| started | OCX on the run's repository finds it not in its care | ended | `ended`, `lost` |
| ended | anything | ended | nothing |

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 the person
with the host's command line asks (`hook --default-user`, `poll --all`), it
reads every open run naming its repository and decides each by the table.
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.

OCX keeps on the host only what a running process needs, in `ROOT/state`:
the runs in its care, what each session has been given, the deliveries
waiting for a process, and, on a clone's host, the passwords file. Nothing a
later reader depends on is kept there.

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, or a default user (named as `repository.default_user` in a run a user holding 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?
