1. OCX on H1 acts on R1 because the `clone.server_code` matches its repository's server-code, and OCX is acting as `lab-1`. OCX on H2 does nothing with R1 because the `clone.user` does not match H2's clone's user.

2. OCX on H3 does not act on R1 because the `clone.server_code` matches its repository's server-code, but OCX is acting as `lab-9`, not `lab-1`. If H3's clone's user were lab-1, it would act on R1.

3. Mallory's `ended` counts because the server's receipt for it names the run's `clone.user` as its sender (`lab-1`), and its `clone` is R1's.

4. Stone's `started` does not count because `process.user` is `builder`, not `lab-1`.

5. OCX on H1 acts on R3 because the `clone.server_code` matches its repository's server-code, but mallory's `started` does not count because the `clone.user` is different (`mallory`).

6. OCX on H1 acts on R4, and its write counts because it meets all the necessary conditions.

7. No, stone cannot send a run with `"process": {"user": "lab-1"}` because that would violate rule 4 in section 2.14.

8. OCX on H2 does nothing with R5 because the `clone.server_code` does not match its repository's server-code (`aaaa…a`).

9. The most OCX on H1 can do is set up a process as `lab-1`, and stone chose this by setting the default user for the clone.

10. `$process_clone$$` refers to the path of the new clone created, which is not the same as R1's key `clone` names (`aaaa…a`).

11. A new run naming server-code aaaa…a arrives, and OCX on H1 acts on it because the sender matches the repository and user. The sender must ensure the server-code matches.

12. A `stop` can be sent by stone, holding `ocx`, `kind`, and `run`.