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: the Fossil server at the project's URL. The server's repository: the repository it serves, which every clone syncs with.
- Server-code: 40 random hex digits identifying one repository file; a copy of the file keeps it; 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`).
- 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.2 Who sent a message

Who sent a message is the user the server's receipt names as its sender,
never a name written in the message, and with that user's capabilities on
the server, inherited ones included, when OCX or a reader decides.
- OCX on the server's repository reads the server's receipts.
- OCX on a clone asks the server with OCX's `receipt` tool, signed in as the
  clone's user, about each artifact it decides by. A clone's own receipts
  name only its own pulls. Until the server has received an artifact and
  answers, OCX decides nothing about it.

Only OCX, OCX's tools and the host's administrators write to a repository
file OCX acts on. If the server's repository pulls from anywhere, it pulls
as a user holding no capability this protocol asks for.

### 2.3 The kinds

Every message's envelope is `ocx` and `kind`.

| Kind | Sent by | Written where | Keys | Answered by |
| --- | --- | --- | --- | --- |
| `run` | a user holding admin or setup; or a user holding `R`, within what the clone's owner allows (2.14, refusal 1) | a new thread, a reply, or a ticket change | `ocx`, `kind`, `clone`, `objective`, `workspace`, `sandbox`, `limits`, `process` (2.4 to 2.10) | `started` then `ended`, or `ended` alone |
| `stop` | a user holding admin or setup; or the user holding `R` that sent the run | where its run is | `ocx`, `kind`, `run` | its run's `ended` |
| `started` | OCX on the run's clone, as the clone's user | where its run is | `ocx`, `kind`, `run`, `clone`, `values`, `limits` | none |
| `ended` | OCX on the run's clone, as the clone's user | where its run is | `ocx`, `kind`, `run`, `clone`, `outcome`, `exit`, `note` | none |

| Key | In | Holds | Required |
| --- | --- | --- | --- |
| `ocx` | every kind | `2` | yes |
| `kind` | every kind | `run`, `stop`, `started` or `ended` | yes |
| `run` | `stop`, `started`, `ended` | the run's hash, in full: the hash of the forum post or ticket change holding the run | yes |
| `clone` | `run` | `{"server_code", "user"}` (2.4) | yes |
| `clone` | `started`, `ended` | `{"server_code", "user"}`: the server-code of the repository that wrote it, and the user it wrote as | yes |
| `objective` | `run` | text: what the run is for, and what counts as passing | yes |
| `workspace` | `run` | a list of steps (2.7); absent, the run gets no workspace | no |
| `sandbox` | `run` | every key of 2.8; absent, the process runs unconfined | no |
| `limits` | `run` | the keys of 2.9 it sets; absent, unlimited | no |
| `process` | `run` | the keys of 2.10 | yes |
| `values` | `started` | every value set (2.6), as set, a secret written as `$$secret:NAME$$` | yes |
| `limits` | `started` | the limits applied, as written | yes |
| `outcome`, `exit`, `note` | `ended` | 2.12 | as 2.12 says |

A run's keys are read in the order of this table. OCX never runs a run with
less than it asks: what it cannot provide, it refuses (2.14).

### 2.4 The key `clone`: who acts, and which reports count

`clone` in a run:

| Key | Holds |
| --- | --- |
| `server_code` | the server-code of the run's clone, all 40 lower-case hex digits: a clone on any host, or the server's repository. `status` and `poll` print it |
| `user` | the login of the clone's user: the user OCX acts as on that repository, from whom its reports must be received |

Two clones appear in a run. The run's clone already exists and acts on the
run; the key `clone` names it. The process's clone does not exist until the
workspace step `clone` makes it, new, from the server's repository; its path
is `$$process_clone$$`, and the process works in it. The process's clone is
never the run's clone.

The key's one stretch: the run's clone may be the server's repository, which
no `fossil clone` made.

To decide whether OCX on a repository acts on a run, it answers these questions in order. The first "no" means it does nothing with the run.
1. Is the run's `clone.server_code` this repository's own server-code?
2. Is the run's `clone.user` the user OCX acts as on this repository?
If both are "yes", it acts: it either refuses the run (2.14) or runs it.

Otherwise, and when `clone` is missing or has any other form, OCX does
nothing with the run, writes nothing to Fossil, and says so in its own log
(`ROOT/hook.log`, or `poll`'s answer). It never refuses such a run, since a
refusal it wrote would not be received from the run's clone's user and so
would not count. `create` refuses to write one.

Many clones may share one clone's user, since each run names its clone by
server-code. Make a clone with `fossil clone`, never by copying the file: a
copy keeps the server-code, and two repositories with one server-code and one
clone's user would both act. A clone made again gets a new server-code: no
one acts on runs naming the old one, so send them again naming the new one.

To decide whether a `started` or `ended` counts, answer these questions in order. The first "no" means it does not count.
1. Who sent the report, by the server's receipt? Is that user exactly the run's `clone.user`? A report sent by any other user does not count, even one sent by a user holding admin or setup.
2. Is the report's `clone`, both keys, the same as the run's `clone`?
3. For a `started` only: did the server receive the run itself from a user holding admin, setup or `R`, and is that user someone other than the run's `clone.user`? (An `ended` skips this question, so a refusal of a run from anyone counts.)

A report received from any other user never counts, whatever it says, even
from a user holding admin or setup. OCX on the run's clone also counts its
own report before the server has it. A second `started` or `ended` for one
run, in the server's order, is ignored: the first that counts, counts.

What rule 3 closes: in version 1, any user who may post could send a run
naming itself as `node`, write its own `started`, and have its `ci` verdicts
against that run count (2.16). What it leaves open, exactly: a user holding
`R` who also has the password of a second user can send a run naming that
second user as `clone.user` and write that run's reports as it; they count.
Grant `R` only to users you would trust with that. A user holding admin or
setup can already do anything.

### 2.5 The clone's user, and the process's user

| Who | Is | Holds |
| --- | --- | --- |
| the clone's user, `clone.user` | the Fossil user OCX acts as on the run's clone. On a clone `poll` made, the clone's owner chose it with `poll --login`, and `poll` makes it the clone's default user (`fossil user default`). On the server's repository it is the user the hook was installed with (`hook --login`); OCX names it with `--user` on each write and never changes that repository's default user | neither admin nor setup on the server (`hook` and `poll` refuse one that does). Within the clone `poll` made, it holds setup, as `fossil clone -A` gives. Its capabilities on the server are the most OCX on that clone can do, as for Fossil's own command line: by default `g`, `o` and `i` (clone, pull, push), and `y` to send unversioned files. On the server's host it holds none, since OCX writes into the repository file directly |
| the process's user, `process.user` | the Fossil user the run's process acts as, in the process's clone | neither admin nor setup on the server; never a clone's user: one named as the `clone.user` of a run that a user holding admin or setup sent. It works for one clone (below) |

The clone's user and the process's user are never one user (2.14,
refusal 4).

A process's user works for one clone: the `clone.server_code` of the first
run, in the server's order, that a user holding admin or setup sent naming
it as `process.user`, whatever became of that run. Once stone's run has named
`builder` with `clone.server_code` `aaaa…`, every repository whose server-code
is not `aaaa…` refuses a run whose `process.user` is `builder` (refusal 5).
So OCX's rule of one run at a time for each process's user holds across
hosts, and the server's repository never sets a new password on a user a
clone on another host holds. The cost: a clone made again has a new
server-code, and the process's users that worked for the old one are refused
for good there; name new ones. `create` makes a new process's user for each
run unless told otherwise.

### 2.7 `workspace`: a list of steps

Each step is `{"step": KIND, ...}`. Steps run in order. A step that fails
ends the run `refused`, its note naming the step. The process runs as OCX's
host account, inside its sandbox, in the workspace the steps make.

| Step | Keys | Needs | Does | Sets |
| --- | --- | --- | --- | --- |
| `directory` | `at`, within `$$root$$` | none | makes the directory, removing what was there, readable by OCX's host account alone | `workspace` |
| `password` | none | none | takes the process's user's password. On the server's repository, OCX sets a fresh one. On a clone's host, OCX reads it from the passwords file | none: a password is never a value |
| `clone` | `into`, within `$$workspace$$` | `password` | makes the process's clone: `fossil clone` of `$$server_url$$`, signed in as the process's user, remembering the password, at `into` | `process_clone` |
| `checkout` | `of`, `into` within `$$workspace$$` | `clone` | opens a checkout, from the process's clone, of the check-in `of` names (any name Fossil resolves), resolved once | `tree`, `checkin` |
| `files` | `of`, `into` within `$$workspace$$` | none | writes the files of the check-in `of` names, resolved once in the run's clone, each executable as the check-in marks it, and nothing else: no repository, no password, so the process signs in as no one | `tree`, `checkin` |

"Within" means below that directory, not the directory itself, once links and
`..` are resolved. A `directory` whose `at` is not within `$$root$$`, or is or
holds another run's workspace in OCX's care, and a `clone`, `checkout` or
`files` whose `into` is not within `$$workspace$$`, are refused when the run
arrives, before any step (refusal 9).

The steps most runs take:

```json
"workspace": [
  {"step": "directory", "at": "$$root$$/$$process_user$$/projects/$$repository_name$$/$$run$$"},
  {"step": "password"},
  {"step": "clone", "into": "$$workspace$$/clone"},
  {"step": "checkout", "of": "trunk", "into": "$$workspace$$/tree"}
]
```

A build, which only reads its check-in and holds no password, takes its files
instead:

```json
"workspace": [
  {"step": "directory", "at": "$$root$$/$$process_user$$/projects/$$repository_name$$/$$run$$"},
  {"step": "files", "of": "trunk", "into": "$$workspace$$/tree"}
]
```

### 2.12 `stop`, and the outcomes of `ended`

A stop names no clone: OCX on the run's clone acts on it, from the senders of
2.3 alone; others are ignored.

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

A reader that does not know an `outcome` takes the run as ended.

### 2.14 Refusals

Checked in order when a run arrives, and again when a person starts a manual
run; the first that holds ends the run `refused`, written as the clone's
user, so the refusal counts.

| # | Holds when | Note names |
| --- | --- | --- |
| 1 | its sender holds none of admin, setup and `R` on the server; or the run's `clone.user` 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` whose path does not end in `$$run$$`, or a limit the file caps left out or set above the cap | which |
| 2 | a required key is missing, a key has the wrong type or form, or a key version 2 does not define, such as `node` | the key |
| 3 | a step kind 2.7 does not have, a step whose needs are not met before it, or a value not set by then | which |
| 4 | `process.user` is the run's `clone.user`, or any clone's user (one named as the `clone.user` of a run that a user holding admin or setup sent), or holds admin or setup on the server | which |
| 5 | `process.user` works for another clone (2.5) | that clone's server-code |
| 6 | a `password` step, and OCX on a clone's host holds no password for the process's user | the user |
| 7 | no `sandbox`, and the host has no `ROOT/settings/unconfined` | that |
| 8 | a sandbox key or limit OCX cannot provide | which |
| 9 | a path outside where 2.7 and 2.8 allow | the path |
| 10 | a workspace step fails | the step, and why |

A run written straight into a clone reaches the server as received from that
clone's user, so refusal 1 holds: send runs to the server.

=== QUESTIONS ===

Setting. Hosts H1 and H2 each hold a clone of the project. H1's clone has server-code aaaa…a (40 digits) and its clone's user is lab-1. H2's clone has server-code bbbb…b and its clone's user is also lab-1. On the server's host, the server's repository has server-code cccc…c and its hook acts as ocx-server. stone holds setup on the server; zed holds `R`; mallory holds only check-in (`i`). A run R1, sent by stone, has `"clone": {"server_code": "aaaa…a", "user": "lab-1"}` and `"process": {"user": "builder", ...}`.

1. Which repository's OCX acts on R1, and what does OCX on H2 do with it?
2. A third host, H3, has a repository whose file was copied from H1's, so its server-code is also aaaa…a, but its clone's user is lab-9. Does OCX on H3 act on R1? What if H3's clone's user were lab-1?
3. mallory replies to R1 with an `ended`, outcome `exited`, exit 0, whose `clone` is R1's. Does it count?
4. stone, who holds setup, replies to R1 with a `started` whose `clone` is R1's. Does it count?
5. mallory sends a run R3 with `"clone": {"server_code": "aaaa…a", "user": "mallory"}`, then posts a `started` for R3 herself. Does OCX on H1 act on R3? Does mallory's `started` count?
6. mallory sends a run R4 with `"clone": {"server_code": "aaaa…a", "user": "lab-1"}`. What does OCX on H1 do, and does what it writes count?
7. Could a run sent by stone name `"process": {"user": "lab-1"}` and be run? Why?
8. After R1, stone sends R5 with `"clone": {"server_code": "bbbb…b", "user": "lab-1"}` and `"process": {"user": "builder"}`. What does OCX on H2 do, and why?
9. What sets the most that OCX on H1 can do on the server, and who chose it?
10. R1's workspace has the step `{"step": "clone", "into": "$$workspace$$/clone"}`. What is `$$process_clone$$`, and is it the repository R1's key `clone` names?
11. H1's clone is deleted and made again with `fossil clone`. A new run naming server-code aaaa…a arrives. What happens, and what must the sender do?
12. Who may send a `stop` for R1, and which keys does it hold?
