1. When OCX on H1 takes the step `password` for R1, it asks the server's `password` tool, signed in as the clone's user (`lab-1`). Before giving it, it checks if:
   - The server has received the run and its receipt names a sender holding admin or setup.
   - The user signed in is indeed `lab-1`.
   - The run has no `started` and no `ended`.
   - No refusal 4 or 5 holds for the process's user (`builder`).

2. When zed sends run R2 naming H1's clone, OCX on H1 will refuse it because:
   - It holds a run whose `process.user` is already in use by another clone (refusal 5). The server-code of that clone must be provided.

3. When run R3 is sent by stone with the step `{"step": "clone", "into": "$$workspace$$/clone", "password": "hunter2"}`, it will refuse because:
   - The password in the `clone` step is static and not derived from any secure mechanism (refusal 9).

4. In R1's `started`, the value `password` is written as a placeholder, but it will never be used because OCX does not store or use passwords statically; instead, it dynamically retrieves them.

5. Lab-2 signs in to the server and asks the `password` tool for R1's password. It will get it because:
   - The sender (`stone`) has setup capability on the server.
   - The user signing in is indeed `lab-1`.
   - There are no run limits or refusals that would prevent this.

6. After R1's `started` counts, if lab-1 asks the `password` tool for R1's password again, it will fail because:
   - Refusal 4 will hold because the same `process.user` (`builder`) is already working on another run (refusal 5).

7. A person does not press a button, approve a login, or edit a file directly to give builder a password for R1. The process happens automatically through OCX's internal mechanisms.

8. When run R4, sent by stone, names the server's repository as its clone and follows the same steps, builder's password comes from:
   - The server's `password` tool, signed in as the user associated with that repository (if it exists and has setup or admin capabilities).