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

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

3. No, it does not count because a report only counts if the server receives it from the user named in the run's `repository.default_user`, and mallory is not `lab-1`.

4. OCX on H1 does not act on R2 because the run's default user (`zed`) does not match H1's default user (`lab-1`). Zed's `started` message does not count because a report cannot be sent by the user who sent the run.

5. No, it would be refused under refusal 4 because the `process.user` cannot be the run's default user.

6. The capabilities of the default user (`lab-1`) on the server determine the most OCX can do. This user was chosen by the repository's owner.

7. `$$clone$$` is the path to a new clone of the server's repository created by the `clone` step. This clone is never the repository named in the run's `repository` section.

8. The run is answered by no one because a repository made again via `fossil clone` gets a new server-code, making the old server-code (`aaaa…a`) invalid.

9. A server-code alone cannot vouch for anything because the server only records the user an artifact came from. The `default_user` is named because only a user can sign a repository's reports.

10. A user holding admin or setup may send a `stop` for R1. The message holds the keys `ocx`, `kind`, and `run`.