0.14 release acceptance: the local cloud has one executable semantics, and the gate that says so is itself falsified

[stephrobert]

#735 is the umbrella: it says what the milestone contains and closes when its table is full. This issue is a different thing, and confusing the two is how a milestone ships on a feeling. It asks one question, once, at the end:

Has the dependency on the order of operations actually been eliminated, or has it only been described?

The release claim this gate defends:

The local cloud has one stable and executable semantics. For every runtime-backed effect, the desired topology, the provider mapping, the supported runtime modes, the observable witness and the lifecycle behaviour are explicit. Two accepted API histories that reach the same desired topology converge to the same normalised observable runtime.

A row that is described but not executed does not satisfy it.

The gate

1. Runtime Contract v1 is complete. Every row of Runtime Contract v1: every runtime-backed effect has one normative definition, one accepted decision where needed, and one executable witness, and no provider path or operation order defines runtime semantics alone #735's table carries all seven cells. A cell filled by intent rather than by a named file or test is not filled.
2. The observed side exists. The contract defines the desired topology and never the observed one: what the permutation suite compares, and when it has looked long enough, are undefined #754 is written and cited by ADR-0004, and the suite compares by it rather than by whatever the first scenario happened to read.
3. RT-001 to RT-015 run on the runtime mode each one claims, and the modes a scenario does not claim are stated, not silently skipped.
4. The chosen permutations converge, compared on the normalised witness. At minimum the triple No suite drives the same desired topology in two orders, so an order-dependent runtime is green everywhere: tools/runtime-conformance/ and the permutation property #728 names, S → G → M, S → M → G, G(push=false) → M → PATCH push=true, and one permutation per contract row that has more than one accepted order.
5. The lifecycle is re-proved, not proved once. create, stop/start, reboot, a Day-2 gesture, destroy and cleanup each re-take the witness. A property proved at Day-0 and never re-proved is not in the contract.
6. The measured divergences are resolved or the claim is withdrawn. A server holding a public address reaches nothing outbound, and on Scaleway a flexible IP does #695 and An Exoscale machine on a bare interface wears opn-fnt while its plan claims no rule set, and the verification guard reds the runtime leg on it #741 are fixed under the contract, or the capability is removed, or the limitation is measured and written. A green claim over a broken witness is the one outcome this milestone exists to make impossible. (Under incus-ovn, platform-web-0 carries its public address on both eth0 and eth1 until the reboot verb takes it off eth0, and the stack gate reds on the difference #742 was closed on 2026-09-07; it stays in this list as the shape to re-run, not as outstanding work.)
7. The instruments answer. The falsify suite has not been green for twenty nights: cancelled by its own timeout, and it reports to nobody #737: the falsify suite concludes. The runtime job of runtime-proof.yml never runs guard.sh verification, so a claim the emulator reported broken has never reddened a night #740: the runtime job consumes guard.sh verification, so a runtime feint itself reported broken cannot pass.
8. The ADR checks pass, and no ADR cited by a contract row is missing its named proof.
9. No published capability maps to an unclassified runtime behaviour. The rule of FirewallPublicOnly, FirewallPublicWhenJoined and Balancing are shapes wearing the name of claims: each is bounded by a paragraph, and the next shape gets a fourth field (ADR-0009, 0010) #727, generalised: a capability points at a contract effect and an executable witness, or it is not published.
10. The three providers each exercise at least one representative topology under incus-ovn, and the bridge mode is judged only on what it declares. A mode that does not claim an effect is not red for lacking it.
11. Nothing foreign is touched. During creation, permutation and cleanup, no runtime object outside feint's ownership is modified. This is a witness, not a review.

The gate is falsified before it is trusted

A release gate that has never been red is a gate nobody has tested. Before this issue closes, each of these must turn it red, and the run is recorded:

remove one route after create                 → red
reorder gateway and machine on a tree
  reproducing #678                            → red
blank one contract cell                       → red
make one witness unreadable and report deny   → red

The fourth is the one that matters most: it proves the gate distinguishes "observed to block" from "we could not look", which is exactly what #754 defines and what four red nights were made of.

What this gate is not

• Not a second umbrella. Runtime Contract v1: every runtime-backed effect has one normative definition, one accepted decision where needed, and one executable witness, and no provider path or operation order defines runtime semantics alone #735 owns the content and the order; this owns the question asked at the end. If they disagree, Runtime Contract v1: every runtime-backed effect has one normative definition, one accepted decision where needed, and one executable witness, and no provider path or operation order defines runtime semantics alone #735 is wrong or this is, and one of them gets fixed rather than both being read.
• Not a date. It closes on its list.
• Not a promise about modes nobody measured. An unsupported, not applicable or control-plane only verdict is a valid answer here, and an unmeasured one is not.

Not established

• The cost of running the whole gate once. The incus-ovn leg alone took 32 minutes on 2026-09-07 (Runtime Contract v1: every runtime-backed effect has one normative definition, one accepted decision where needed, and one executable witness, and no provider path or operation order defines runtime semantics alone #735), and this gate is broader. Whether it runs in one workflow or in several is decided by the first measurement, not here.
• Which permutations are worth their minutes. No suite drives the same desired topology in two orders, so an order-dependent runtime is green everywhere: tools/runtime-conformance/ and the permutation property #728 chooses them from the first runs; this issue records the set that was actually run, not a set imagined in advance.