Questions, scenarios and what to deliver

10. Questions the model must answer

These are not requirements.

• When a branch’s stepper stops, how long before another may advance it, and what tells a peer the stepper has stopped rather than gone quiet?
• How does a peer decide which candidates to run, and how many?
• Does the shared branch’s gate trust a container on a host that also runs sessions, or only hosts that run none?
• How does a branch’s policy name the executors it trusts, and how does a run prove which executor made it, when under peers every host writes the records?
• Under a central server, is a state readable only on the server readable “whether or not sluice is running”?
• Who releases the candidate places of a host that has stopped for good?
• Who sets how long a host may hold a branch, or a claim on a candidate’s checks: the policy, the deployment or the operator?

11. Scenarios the model must satisfy

• S1. Two sessions submit heads to one bolt branch. Both candidates pass. Both land, in order, and neither session ran a merge.
• S2. The second head conflicts with the first. Its session is told the paths before any check runs; the first lands.
• S3. The first candidate passes and the second fails. The second’s session is told the failing checks; the first has landed; no other session hears of it.
• S4. The first candidate fails. Its session is told; the second head is formed again on the branch without it, passes, and lands first.
• S6. Two bolts whose work touches unrelated parts are submitted to the shared branch. The second is tested on top of the first and lands after it, and is not tested again when the first lands.
• S7. One key holds a pass and a fail from trusted executors. The bolt branch’s policy reads it passed; the shared branch’s reads it missing until a confined run settles it.
• S8. The branch is moved by hand between a candidate’s verdict and its landing. The landing is refused and the chain is formed again on the new revision.
• S9. The shared branch tests deepest first. Three bolts are tested as one candidate, which fails; the two skipped candidates are tested, and the culprit is the one entry the rule names.
• S10. sluice is stopped. Every entry’s state is still readable. Started again, it continues without running a check for any candidate that already has a verdict.
• S11. An entry lands. The branch holds a commit whose second parent is the session’s head and which names the verdict; sluice leaves the session’s place alone, and the session’s driver releases it.
• S12. A submission changes the branch’s policy to drop a check its candidate fails. The candidate is judged by the policy on the branch, fails, and the change to the policy lands only with a candidate that passes the gate as it stood.
• S13. Sessions on two hosts submit to one bolt’s branch. Their entries are tested in one order, and each session reads its entry’s state and is told its outcome on its own host.
• S14. The host advancing a branch stops mid-chain. Under peers another host continues from the records; under a central server nothing lands until it is back. In both, no entry is lost and no check that has a verdict is run again.
• S15. An executor stops while running a candidate’s checks. The run has no outcome; the checks run again on another executor, and the candidate’s verdict is read from that run.
• S16. Two sessions build heads that edit one file. The second asks for a forecast before it has finished; it is told the file and the first entry’s work, settles it, and both candidates form without conflict.
• S36. A planner asks for bolt/x from main at M. sluice makes bolt/x at M. A second ask is refused because bolt/x is present. On another host, an ask made at the same time finds the remote’s branch present and is refused (46).
• S37. A planner asks to remove bolt/x into main while an entry is under test on it. The removal is refused, naming the entry. Once the bolt’s revision is landed on main, the removal succeeds and the branch’s records still read.
• S38. A removal reads bolt/x at R. Another host lands on bolt/x before the removal reaches the remote. The removal is refused because the branch is elsewhere, and the landing stands.
• S39. A planner asks to remove bolt/x into main, but bolt/x’s revision was never landed on main. The removal is refused, saying so.

12. What to deliver

A model of sluice that satisfies Parts A and B: its components, the record of an entry and of a verdict, the chain and the window, the attribution rule, and the landing. A conformance suite whose scenarios cite the clauses they exercise. The profiles of Part C, each passing the suite.