1. OCX on H1 acts on R1 because the run's `clone` server-code and user match H1's repository and user. OCX on H2 does nothing and writes nothing to Fossil because the run's server-code does not match H2's.

2. OCX on H3 does not act on R1 because the run's `clone.user` (`lab-1`) does not match H3's clone's user (`lab-9`). If H3's user were `lab-1`, OCX would act on R1 because both the server-code and user would match.

3. No, it does not count because the server's receipt for the report must name the run's `clone.user` (`lab-1`) as the sender, not mallory.

4. No, it does not count because the server's receipt for a `started` report must name the run's `clone.user` (`lab-1`) as the sender.

5. OCX on H1 does not act on R3 because the run's `clone.user` (`mallory`) does not match H1's clone's user (`lab-1`). Mallory's `started` does not count because she does not hold admin, setup, or `R`, and she is the run's `clone.user`.

6. OCX on H1 refuses the run because mallory does not hold admin, setup, or `R` on the server. This refusal counts because it is written as the run's `clone.user` (`lab-1`).

7. No, because the `process.user` cannot be any clone's user, and `lab-1` is the clone's user for H1 and H2.

8. OCX on H2 refuses the run because the process's user (`builder`) already works for another clone (server-code `aaaa...a`) from run R1.

9. The capabilities of the clone's user (`lab-1`) on the server set the limit, and these were chosen by the clone's owner using `poll --login`.

10. `$$process_clone$$` is a new repository made from the server's repository via `fossil clone`. It is never the same repository as the one named in the run's `clone` key.

11. OCX on H1 does nothing because the new clone has a different server-code than `aaaa...a`. The sender must send the run again using the new server-code.

12. A user holding admin or setup (such as stone) may send a `stop` for R1. It holds the keys `ocx`, `kind`, and `run`.