1. OCX on H1 acts on R1 because its repository's server-code (`aaaa…a`) matches R1's clone's server-code, and R1's clone's user (`lab-1`) is the user OCX acts as there. OCX on H2 does nothing with R1 since it has a different server-code (`bbbb…b`).

2. OCX on H3 does not act on R1 because its repository's server-code (`aaaa…a`) matches R1's clone's server-code, but its clone's user (`lab-9`) is different from R1's clone's user (`lab-1`). If H3's clone's user were `lab-1`, OCX would still not act on R1 because the run's clone's user must be the user OCX acts as there.

3. Mallory's `ended` counts if the server's receipt for it names the run's `clone.user` (`mallory`) as its sender, which it does, and if its `clone` is the run's `clone`, which it is. It counts because the first three rules are satisfied.

4. Stone's `started` does not count because the user holding admin or setup on the server (stone) cannot send a `started` for another run unless the run's clone's user (`lab-1`) is stone, which it is not. Only OCX on H1 acts on R1 in this case.

5. OCX on H1 does not act on R3 because its repository's server-code (`aaaa…a`) matches R3's clone's server-code, but R3's clone's user (`mallory`) is different from H1's clone's user (`lab-1`). Mallory's `started` counts if the sender holds admin or setup (zed) or R and the run asks more than it allows. Since mallory holds R and the run does not ask for anything beyond what she has, her `started` counts.

6. OCX on H1 acts on R4 because its repository's server-code (`aaaa…a`) matches R4's clone's server-code. Mallory's `started` counts if it meets all the criteria for a valid `started`. Since it does not violate any rules, mallory's `started` counts.

7. OCX cannot run a run sent by stone named `"process": {"user": "lab-1"}` because the process's user (`builder`) must work for one clone, and since lab-1 is already working for another clone (H2), this would violate rule 5.

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

9. The most that OCX on H1 can do on the server is set by stone, who holds setup. The choice was made when stone created the run.

10. `$$process_clone$$` is set to `clone/clone`, which refers to the directory in H1's workspace where the process's clone will be created. It is not the repository R1's key `clone` names (H2's clone).

11. OCX on H1 does not act on the new run because its repository's server-code (`aaaa…a`) matches the new run's clone's server-code, but the new run's clone's user (`lab-9`) is different from H1's clone's user (`lab-1`). The sender must ensure that the server-code and user match H1's repository to have OCX act on it.

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