1. The password comes from the server's `password` tool, which OCX on H1 asks for while signed in as `lab-1`. The server checks that the run's sender holds admin or setup, the signed-in user is the run's `clone.user`, the run has no counting `started` or `ended` records, and no refusal 4 or 5 holds for the `process.user`.

2. The run is refused under refusal 1. This is because `zed` holds capability `R`, and runs sent by users with that capability are refused if they include a `password` step.

3. The run is refused under refusal 2. The `password` key of the `clone` step must be exactly `$$password$$`, and any other text is refused.

4. The value is written as `$$password$$`. This is because the password is a secret.

5. No, `lab-2` does not get the password. The server only provides the password if the user signed in is the run's `clone.user`, which for R1 is `lab-1`.

6. The request fails (refusal 9). The server's `password` tool only answers if the run has no `started` and no `ended` that counts.

7. No. The password is generated by the server and provided to OCX automatically via the `password` tool when the `password` step is taken.

8. OCX sets the password directly on the server's repository. For runs acting on the server's repository, OCX sets the password there rather than asking the `password` tool.