1. OCX on H1 acts on R1 because its `clone.server_code` matches and its `clone.user` is the same as the server's user ocx-server.
   - OCX on H2 ignores R1 because it doesn't match the clone details for H2.

2. OCX on H3 does not act on R1 because its clone's user lab-9 is different from the run's clone's user lab-1.
   - If H3's clone's user were lab-1, OCX on H3 would act on R1.

3. No, mallory's `ended` does not count because it comes from a user (mallory) who doesn't match the reported clone.user of R1.

4. Yes, stone's `started` counts because stone holds setup and its reported clone matches R1's clone details.

5. OCX on H1 does not act on R3 because mallory's clone.user lab-9 is different.
   - Mallory's `started` does not count for the same reason.

6. OCX on H1 acts on R4, but the process's user builder would be refused since builder works for another clone (lab-1).

7. No, stone cannot name "process": {"user": "lab-1"} because it doesn't hold setup or `R`.

8. OCX on H2 acts on R5 and refuses it because stone's process.user builder is the same as R5's clone.user lab-1.

9. OCX on H1 can act as user ocx-server, chosen with hook --login on H1's server repository.

10. `$$process_clone$$` is $$workspace$$/clone, and it is not the same repository as in R1's key.

11. If H1's clone is deleted and made again, a new run naming server-code aaaa…a arrives.
    - The sender must ensure the new clone details match exactly for OCX to act on the run.

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