### Question 1:
When OCX on H1 takes the step `password` for R1, where does builder's password come from, and what is checked before it is given?
- **Answer:** The password comes from the server. Before being given to builder, OCX checks if stone (the sender of run R1) holds setup or admin capabilities on the server. Since stone has setup, the check passes, and the server's `password` tool sets a fresh password for the process's user "builder".

### Question 2:
zed sends a run R2 naming H1's clone, with the same steps as R1. What happens, and why?
- **Answer:** Zed's run R2 is refused because it violates refusal 4: The `process.user` is not allowed to work for another clone. Since builder is named as the `clone.user` of a run sent by stone (who holds setup), this prevents zed from using builder's password.

### Question 3:
A run R3, sent by stone, has the step `{"step": "clone", "into": "$$workspace$$/clone", "password": "hunter2"}`. What happens?
- **Answer:** This run is refused because refusal 1 holds. The step specifies a password directly in the JSON, which OCX does not allow (refusal 2). Additionally, using a hard-coded password instead of signing into the server's `password` tool would also be against policy.

### Question 4:
In R1's `started`, what is written for the value `password`?
- **Answer:** In R1's `started`, the value `$$password$$` is written. This placeholder will be replaced with the actual password that OCX receives from the server when it sets a fresh password for builder.

### Question 5:
lab-2 signs in to the server and asks the `password` tool for R1's password. Does it get it? Why?
- **Answer:** Lab-2 does not get the password. Refusal 9 holds because lab-2 is not allowed to use the password step. Even though lab-2 has admin or setup capabilities, they are working on a different clone (lab-1), and thus cannot access the password for builder's run.

### Question 6:
After R1's `started` counts, lab-1 asks the `password` tool for R1's password again. What happens?
- **Answer:** This request is refused. Refusal 5 holds because a process's user can only work for one clone at a time. Since lab-2 was working with builder's run on H1, and lab-1 now wants to use the same process's user, the request fails.

### Question 7:
Does a person press a button, approve a login, or edit a file on H1 so that builder has a password for R1?
- **Answer:** No, a person does not need to interact with H1 to set builder's password. The server's `password` tool automatically sets a fresh password for the process's user "builder" when the run is received by OCX.

### Question 8:
A run R4, sent by stone, names the server's repository as its clone, with the same steps. Where does builder's password come from then? (Assume builder works for that repository.)
- **Answer:** The password comes directly from the server's `password` tool. Since builder is a user on the server and R4 names the server's repository as its clone, OCX asks the server's `password` tool to set a fresh password for builder, which will be written into the process's clone.