1. OCX on H1 acts on R1 because its repository's server-code (`aaaa…a`) and default user (`lab-1`) match those in R1. H2's OCX does nothing with R1.
   
2. No, OCX on H3 does not act on R1 because although the server-code is the same (`aaaa…a`), the default user (`lab-9`) is different from the one named in R1.

3. Yes, mallory's `ended` message counts because it is received from a user (`mallory`) that matches the run's default user (`lab-1`) and names the repository correctly.

4. OCX on H1 does not act on R2 because it specifies a different default user (`zed`). Zed's `started` message does not count as it comes from the sender of the run, not the run's default user.

5. No, a run cannot name `"process": {"user": "lab-1"}` and be run. The process user must never be the repository's default user or any admin/setup-sent default user.

6. The most that OCX on H1 can do on the server is set by whoever has that repository's command line capabilities, chosen by the repository owner.

7. `$$clone$$` refers to a directory within the workspace where a clone of another repository will be created. It is not necessarily the repository named in the run's `repository`.

8. When H1's clone is deleted and made again with `fossil clone`, a new run naming the old server-code (`aaaa…a`) does nothing because it comes from an unknown user, as clones get new server-codes.

9. A run names `default_user` instead of OCX finding the user from the server-code to ensure that only users explicitly allowed by the repository's owner can send reports that count towards a run's success or failure.

10. Only a user holding admin or setup, or the specific user (`R`) who sent the run, may send a `stop` for R1. It must hold the keys: `ocx`, `kind`, and `run`.