1. OCX on H1 acts on R1 because H1's server-code and default user match those named in the run. OCX on H2 does nothing because its server-code does not match.

2. No, OCX on H3 does not act on R1 because the run's named default user (lab-1) does not match H3's default user (lab-9).

3. No, it does not count because reports only count if the server received them from the run's default user (lab-1), and this was sent by mallory.

4. OCX on H1 does not act on R2 because the run's named default user (zed) does not match H1's default user (lab-1). Zed's `started` report does not count because reports from the user who sent the run are ignored.

5. No, it cannot be run if lab-1 is the run's default user (triggering refusal 4) or if lab-1 holds admin or setup capabilities.

6. The most OCX can do is limited by the capabilities of the default user (`lab-1`) on the server. This user was chosen by whoever has that repository's command line.

7. `$$clone$$` is the repository created by the `fossil clone` command. It is not the repository named in the run's `repository` field, which identifies the repository that acts on the run.

8. The run is answered by no one because a repository made again with `fossil clone` gets a new server-code, and runs naming the old one are ignored.

9. A server-code alone cannot vouch for anything because the server only records the user who sent an artifact. Therefore, a user must be named to sign the repository's reports.

10. A user holding admin or setup, or the user holding `R` that sent the run, may send a stop. It holds the keys `ocx`, `kind`, and `run`.