Part A

Part A. What must hold of sluice

A.1 Submission

1. A session submits a head to a branch and does nothing more: it never merges, never lands and never moves a branch, and an attempt to is refused and reported.
2. A head is submitted only from a place whose tree is exactly its commits. The driver refuses a place holding anything more, and names what it holds; sluice is only ever given a head.
3. A submission names what it lands after, its priority and who submitted it. It never names a position.
4. An entry leaves sluice only by landing, by withdrawal by its submitter, its planner or the operator, or by a bound the branch’s policy states in advance. sluice never drops an entry on its own.
5. A submission from a place that has an entry on the same branch withdraws that entry, which stays readable as withdrawn.
6. sluice never bounds how often a session submits again after its entry was removed as culprit or conflict. An entry’s state shows how many times its place’s work was submitted before it, and acting on that count is the driver’s or the planner’s.

A.2 Order

6. Entries of one branch are ordered by priority, then by the order of submission. Priority orders only entries in no candidate under test: an entry under test is never displaced by one submitted after it. An entry never lands before an entry it names as after.
7. An entry whose after-entries are neither landed nor ahead of it in its branch’s chain waits, and its waiting holds no other entry.
8. Every entry of a branch is in its one chain. No entry is tested apart from the entries ahead of it, and entries land in chain order.

A.3 Candidates and chains

10. Every candidate equals the branch’s current revision extended, in order, by exactly the entries ahead of it and itself. A candidate never contains an entry behind it or an entry removed from the chain.
11. An entry is judged only as a candidate: never alone against a revision the branch has left, and never in a combination it would not land in.
12. A conflict is found when the candidate is formed, before any check runs. It removes the entry from the chain and nothing else: the chain continues without it.
13. sluice forms, for a head not yet submitted, the candidate it would form were the head submitted now, against the branch and the entries ahead of it, and reports a conflict so found to the head’s session. A forecast creates no entry, changes no order and moves no branch, and its result is never read as a verdict.
14. A conflict reported to a session, forecast or found at forming, names the content contested and every entry it is contested with, with what each of those entries submitted: each entry ahead the head conflicts with alone, or, when none does, every entry ahead up to the one at which the conflict appeared.
15. A branch is tested up to its window. The window never falls below one, grows while candidates pass and shrinks when one fails, within bounds the branch’s policy states.
16. An instance of sluice starts no more checks at once than its own bound, whatever the windows of the branches it serves. A host whose checks are all started by one instance runs no more than that instance’s bound.
17. A branch’s policy says whether every candidate of a chain is tested or the deepest first. Under deepest first, a failure is attributed only after the candidates that were skipped have verdicts.

A.4 Verdicts and attribution

15. A candidate’s verdict is its branch’s gate read over the checks the candidate affects. A required check whose key already holds a pass from an executor the gate trusts is read from that pass and not run again.
16. Every check run on a candidate is recorded with its key, its outcome, pass and fail alike, and its executor, before the verdict is read. A result a tool answered from an earlier run is not a run and is never recorded as one.
17. A failed candidate is attributed to exactly one entry: the newest entry of the first failed candidate in its chain.
18. No entry is attributed or landed before every candidate ahead of it in its chain has a verdict. A conflict removes its entry when it is found (12).
19. A check’s result belongs to its key, not to a branch: a pass recorded under a key satisfies every branch whose gate trusts the executor that recorded it.
20. When the branch’s revision is covered by no verdict, every check its gate requires is affected by the next candidate.
21. A key holding both a pass and a fail from executors the gate trusts, each held to the same limits, reads as the branch’s policy says: passed or not passed. It never reads differently for two candidates of one branch. A result under other limits says nothing of a run under these (83).
22. The culprit’s session is told the failing checks and the candidate they failed on. No other session is told of that failure.
23. An entry removed as culprit or as conflict leaves the chain, and every candidate behind it is formed again without it.

A.5 Landing

22. A branch moves only to a candidate whose verdict is satisfied, only in chain order, never past an entry without a verdict, and never to a candidate containing a culprit or a conflict.
23. A landing writes one commit per entry, with the revision before it as its first parent and the entry’s head as its second, naming the entry’s work and the verdict it landed on; entries landed together on the deepest candidate’s verdict each name that verdict. The history of a branch is never rewritten, and a session’s commits stay reachable from the branch they landed on.
24. A landing moves the branch from exactly the revision its candidate was formed on. A landing that finds the branch elsewhere is refused, and the chain is formed again on the revision found.
25. sluice releases every place it made for a candidate once that candidate’s verdict is read, and never releases a session’s place. A session learns its entry landed (50), and releasing its place is its driver’s.
26. Every state an entry is in, and every verdict read for it, is readable by its session, its planner and the operator, from every host that submits to its branch, whether or not sluice is running.

A.6 Gates and trust

27. A branch’s gate is its policy’s: the checks it requires, the executors it trusts, how a flaky key reads, whether every candidate or the deepest first is tested, the window’s bounds, and how long a candidate’s checks may run. sluice gives no gate a meaning of its own, and admits every submission a driver makes: whether work may be submitted at all is decided before it reaches sluice.
28. A result from an executor the branch’s gate does not trust never satisfies that gate, whatever its outcome.
29. A gate that trusts only confined executors is satisfied by no open run.
30. sluice never runs a check of its own and never changes what a gate requires.
31. A check’s cost never changes how it gates: every check a branch’s gate requires has a verdict before the branch moves, and none is deferred past a landing.
32. A branch’s gate is read from the branch’s current revision, never from a candidate or a place. No submission changes the gate it is judged by.

A.7 Places

31. sluice starts no service. What a candidate’s checks need, the checks bring up themselves, in the candidate’s place. sluice gives the place a port for each name its branch’s policy lists. Each stays the same for the place’s whole life, belongs to no other place alive on the host, and is free when the checks receive it.
32. A candidate’s place belongs to the candidate: nothing started in it outlives it, what its checks hand to another process to keep included, and two places on one host never collide.
33. A candidate’s checks run under the time limit its branch’s policy states. A run that exceeds it is ended with everything it started, recorded as timed out, and read as failed.

A.8 Hosts

57. Every entry of one branch is ordered with every other entry of that branch, whichever host submitted it.
58. At most one instance of sluice advances a branch at any moment, whichever host it runs on, and one that has stopped advancing a branch writes nothing more for it.
59. An instance that stops advancing a branch loses nothing: every entry submitted meanwhile is held, and whatever next advances the branch resumes from the records as last written.
60. A candidate’s checks may run on any host. A run whose executor stopped before reporting has no outcome: it is never read as a pass or a fail, and the check is run again.

A.9 Branches

104. The operator or a planner may ask sluice to make a branch it will land on, from another branch it lands on. sluice makes it at the other branch’s current revision, by a move from absent (45), when the policy at that revision gives the new branch a gate (56) and the new branch’s records hold no entry still waiting, under test or landing. A branch already present is refused, and so is one that policy does not name.
105. The operator or a planner may ask sluice to remove a branch it lands on, naming the branch the removed branch’s work landed into. sluice removes it by a move to absent (45) from the revision it read, only when no entry on it is waiting, under test or landing, no landing on it is left unrecorded (S9), and that revision is contained in the named branch’s current revision. Its records stay.
106. Making and removing a branch is not landing: neither writes a commit, records a verdict or reads a gate’s checks, and 22 to 24 bind neither. A refused one is reported, never retried blind. A branch sluice lands on is made and removed only as 104 and 105 say, and the branch’s protection (1) refuses anyone else’s.