1. OCX on H1 acts on R1. OCX on H2 ignores R1.

2. OCX on H3 acts on R1 if H3's clone's user is lab-1; otherwise, it ignores R1.

3. No, mallory's `ended` does not count because her receipt does not name stone as a sender holding admin or setup or `R`.

4. Yes, stone's `started` counts because it names stone as a sender holding admin or setup and OCX checks the server's receipt before counting the report.

5. No, OCX on H1 does not act on R3. Mallory's `started` does not count because her receipt names mallory as the sender, not lab-1.

6. OCX on H1 ignores R4 because it names lab-1 in the clone, but OCX checks the server's receipt and finds that stone sent the run with setup or admin.

7. No, a run cannot name `"process": {"user": "lab-1"}` and be run because it would violate rule 5 in section 2.5, where a process user must work for one clone, not any clone's user.

8. OCX on H2 acts on R5 because it names lab-1 in the clone and stone sent the run with setup or admin.

9. The most OCX on H1 can do on the server is as `g`, `o` (clone, pull), `p` (push), and `y` (send unversioned files); stone chose these capabilities when installing the hook.

10. `$$process_clone$$` is a new repository's path made by `fossil clone`, and it is not the same as R1's key `clone` names.

11. If H1's clone is deleted and made again with `fossil clone`, a new run naming server-code aaaa…a arrives, but OCX on H1 ignores it because it does not count if the sender holds admin or setup.

12. Only a user holding admin or setup may send a `stop` for R1; it holds `ocx`, `kind`, and `run`.