1. OCX on H1 acts on R1 as lab-1 is listed as clone's user. OCX on H2 ignores R1 because its server_code differs from the run's.
2. OCX on H3 does not act on R1 due to a different server-code, even if H3's clone's user were lab-1.
3. Yes, it counts because the sender of the `ended` report is exactly the run's clone.user.
4. No, it does not count as stone sends it but tries to assign process.user builder which conflicts with step 2.5.
5. OCX on H1 acts on R3 since lab-1 and mallory share a user but mallory's started does not count because she sent the run.
6. OCX on H1 ignores R4 due to different server_code, even though it shares the clone's user with H1.
7. No, stone cannot name builder as process.user because he holds check-in only, not setup or admin.
8. OCX on H2 acts on R5 since lab-1 is a valid clone's user for that host and does not conflict with the process user.
9. The most OCX can do is set by server settings (refusal 6), and it is chosen when creating a new process’s user in stone's run.
10. $$process_clone$$ is $$workspace$$/clone, and it is not named by R1 but by H2’s repository acting on the run.
11. OCX ignores the new run due to server-code mismatch, and sender must ensure the server_code matches their clone.
12. Only a user holding setup or admin may send a `stop` for any run; it holds only 'ocx' and 'kind'.