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

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

3. No. The report does not count because it was received from mallory, but reports must be received from the run's default user (lab-1).

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

5. No. This would result in refusal 4, as the `process.user` may never be the run's default user.

6. The capabilities of the default user (lab-1) on the server determine the most OCX can do. The owner of the repository chose this user.

7. `$$clone$$` is a `fossil clone` of the server made as the process user. Yes, it is the server's repository named in the run.

8. The run is answered by no one. A clone made again gets a new server-code, so runs naming the old server-code are no longer valid.

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

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