1. H1's OCX acts on R1 because both the repository's server-code and default user match its own. H2's OCX ignores R1 as the run's repository information does not match.
2. No, OCX on H3 does not act on R1 because although it has a clone with the same server-code, the default user differs from the one in R1.
3. No, the ended message counts because it meets all three rules: it is received by lab-1, the repository matches, and lab-1 did not send the run.
4. OCX on H1 does not act on R2 as the process.user field is "zed" instead of "lab-1". Mallory's started message for R2 does not count because the sender is not allowed to send a start command for another user's run.
5. A run cannot name `"process": {"user": "lab-1"}` and be run because it would violate rule 4, as lab-1 holds admin or setup capabilities.
6. The most that OCX on H1 can do is limited by the default user of the repository (lab-1), who chose these capabilities using their own Fossil command line.
7. `$$clone$$` is the path within the workspace where a new clone of the server's repository is made, and it is not the same as the repository named in the run's `repository`.
8. When H1's clone is deleted and made again with `fossil clone`, a new run naming the old server-code aaaa…a arrives but OCX on H1 does nothing because it does not match its own repository information.
9. A run names `default_user` instead of OCX finding the user from the server-code to ensure that only the owner of the repository (lab-1 in this case) can write reports associated with that run, preventing impersonation and maintaining data integrity.
10. Only a user holding admin or setup, or the user who sent R1 (stone), can send a `stop` for R1. A `stop` message for R1 holds only `ocx`, `kind`, and `run` keys.