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.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 a process's user's password is set only for the one clone it
works for (2.7), never by two hosts at once. 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.6 Values

A string names something OCX knows as `$$name$$`: `$$`, a name of letters,
digits or `_` (or `secret:` and a secret's name), then `$$`. Everything else is itself, `$` and `{`
included, so a shell's `${HOME}` reaches the process as written. Values are
read in every string of `workspace`, `sandbox` and `process`, at any depth,
except `process.user`, `process.deliveries`, `process.hears` and
`process.checkins`, and never in `clone` or in any object's keys. OCX checks
every value a run names when the run arrives, before any step: a run naming a
value that nothing sets before it is refused then (refusal 3), and nothing
is made. A default (2.10) that names a value not set is left out instead.

| Value | Set by | Holds |
| --- | --- | --- |
| `root` | OCX | the directory under which OCX makes runs' workspaces |
| `repository_name` NEW TERM | OCX | the server's repository's name: the last part of the server's URL |
| `server_url` NEW TERM | OCX | the server's URL, from which the process's clone is made |
| `run` | OCX | the run's hash, in full |
| `clone_user` NEW TERM | OCX | the run's `clone.user` |
| `process_user` NEW TERM | OCX | the run's `process.user` |
| `release` | OCX | the directory of the OCX release that acts, which a process may read and run |
| `secret:NAME` | OCX, on the server's repository only | the server's repository's secret NAME, which an admin sets with OCX's `secret`; filled in `process.env` alone; written in `started` and the kept logs as `$$secret:NAME$$` |
| `workspace` | step `directory` | the workspace's directory |
| `password` | step `password` | the process's user's password, fresh for this run. A secret, as `secret:NAME` is: written in `started` and the kept logs as `$$password$$`, and named only as the `clone` step's `password` |
| `process_clone` NEW TERM | step `clone` | the path of the process's clone |
| `tree` | step `checkout` or `files` | the directory holding the check-in's files |
| `checkin` NEW TERM | step `checkout` or `files` | the check-in's hash, in full, resolved once |

### 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 | sets a fresh password on the process's user. On the server's repository, OCX sets it itself and asks no tool. On a clone's host, OCX asks the server's `password` tool for it, signed in as the clone's user (below). A run from a user holding `R` never takes this step (refusal 1) | `password` |
| `clone` | `into`, within `$$workspace$$`; `password`, exactly `$$password$$` | `password` | makes the process's clone: `fossil clone` of `$$server_url$$`, signed in as the process's user with `$$password$$`, remembering it, 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` |

The `password` key of `clone` holds only the name `$$password$$`, so a run
never holds a password; any other text there is refused (refusal 2).

On a clone's host, the step `password` asks the server's `password` tool,
naming the run, signed in as the clone's user. The server sets a fresh
password on the run's `process.user` and answers with it only if all hold:
1. the server has received the run, and its receipt names a sender holding
   admin or setup;
2. the user signed in is the run's `clone.user`;
3. the run has no `started` and no `ended` that counts (2.4);
4. no refusal 4 or 5 holds for the run's `process.user`.

Otherwise it answers which does not hold, and the step fails (refusal 9).
The answer is the only place the password goes; OCX keeps it as
`$$password$$`, and the `clone` step saves it in the process's clone, where
the process signs in with it. A run sent by a user holding `R` takes no
`password` step (refusal 1), so its process holds no password at all.

"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 8).

The steps most runs take:

```json
"workspace": [
  {"step": "directory", "at": "$$root$$/$$process_user$$/projects/$$repository_name$$/$$run$$"},
  {"step": "password"},
  {"step": "clone", "into": "$$workspace$$/clone", "password": "$$password$$"},
  {"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.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 | no `sandbox`, and the host has no `ROOT/settings/unconfined` | that |
| 7 | a sandbox key or limit OCX cannot provide | which |
| 8 | a path outside where 2.7 and 2.8 allow | the path |
| 9 | a workspace step fails, including the server's `password` tool refusing | 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.

### 2.15 What OCX keeps on a host

The repository holds every message. OCX keeps on the host only what a
running process needs, and nothing a later reader depends on.

| Kept | Where | For |
| --- | --- | --- |
| the runs in its care | `ROOT/care/RUN.lock`, held by the run's watcher | so it acts on each run once, and finds what its going down left |
| what each session has been given, and the deliveries waiting for it | `ROOT/care/RUN.inbox` | each artifact at most once |
| the run's workspace path and watcher log | `ROOT/care/RUN.workspace`, `ROOT/care/RUN.log` | for the watcher and `status` |
| one call of the hook or `poll` deciding at a time | `ROOT/care/round.lock` | so two calls never decide one run |
| a process's user with a run in its care | `ROOT/care/process-users/LOGIN.lock` | one run at a time for each process's user |
| the passwords file, on a clone's host | a path the clone's owner gives `poll`, readable by OCX's host account alone | the clone's user's password; a process's user's password is asked of the server for each run (2.7) and kept only in that run's process's clone |

=== QUESTIONS ===

Setting. Host H1 holds a clone of the project, whose clone's user is lab-1; host H2 holds another clone, whose clone's user is lab-2. The server's repository's hook acts as ocx-server. stone holds setup on the server; zed holds `R`. Run R1, sent by stone, has `"clone": {"server_code": H1's server-code, "user": "lab-1"}`, `"process": {"user": "builder", ...}`, and the workspace steps directory, `{"step": "password"}`, `{"step": "clone", "into": "$$workspace$$/clone", "password": "$$password$$"}`, then checkout. No earlier run named builder.

1. When OCX on H1 takes the step `password` for R1, where does builder's password come from, and what is checked before it is given?
2. zed sends a run R2 naming H1's clone, with the same steps as R1. What happens, and why?
3. A run R3, sent by stone, has the step `{"step": "clone", "into": "$$workspace$$/clone", "password": "hunter2"}`. What happens?
4. In R1's `started`, what is written for the value `password`?
5. lab-2 signs in to the server and asks the `password` tool for R1's password. Does it get it? Why?
6. After R1's `started` counts, lab-1 asks the `password` tool for R1's password again. What happens?
7. Does a person press a button, approve a login, or edit a file on H1 so that builder has a password for R1?
8. A run R4, sent by stone, names the server's repository as its clone, with the same steps. Where does builder's password come from then? (Assume builder works for that repository.)
