Red scheduled night: Runtime proof

[github-actions]

The scheduled run of 2026-08-27 is red: https://github.com/stephrobert/feint/actions/runs/33039017046

What failed — the first failing step of a job carries the cause; later
failures run under if: always() and are downstream of it:

• step Dataplane witness gate — job incus-ovn

Consecutive red scheduled nights, this one included: 6.
The green streak before this series was 1; it is now 0 (target: 14).

[github-actions]

The scheduled run of 2026-08-28 is red: https://github.com/stephrobert/feint/actions/runs/33144268303

What failed — the first failing step of a job carries the cause; later
failures run under if: always() and are downstream of it:

• step Build the machine images the suites boot — job incus
• step Build the machine images the suites boot — job incus-ovn

Consecutive red scheduled nights, this one included: 7.
The green streak before this series was 1; it is now 0 (target: 14).

[github-actions]

The scheduled run of 2026-08-28 is red: https://github.com/stephrobert/feint/actions/runs/33144268303

What failed — the first failing step of a job carries the cause; later
failures run under if: always() and are downstream of it:

• step Build the machine images the suites boot — job incus-ovn
• step Build the machine images the suites boot — job incus

Consecutive red scheduled nights, this one included: 7.
The green streak before this series was 1; it is now 0 (target: 14).

[github-actions]

The scheduled run of 2026-08-29 is red: https://github.com/stephrobert/feint/actions/runs/33229486194

What failed — the first failing step of a job carries the cause; later
failures run under if: always() and are downstream of it:

• step The example stacks, applied and probed — job stacks (incus-ovn)

Consecutive red scheduled nights, this one included: 8.
The green streak before this series was 1; it is now 0 (target: 14).

[stephrobert]

Nine red nights, five causes — read 2026-08-29

Last green: 2026-08-21 (32441329459). Every night since is red, and this issue
holds all of them under one title. They are not one defect:

night	run	cause	now tracked by
08-26	32924409224	the peering is active and i-219d7119 still cannot reach 10.184.1.4	—
08-27	33039017046	this host still holds what an earlier run left	#601
08-28 05:16	33144268303	the emulator did not answer /_feint/conformance	—
08-28 14:49	33182105527	this host still holds what an earlier run left	#601
08-29	33229486194	platform-web-0 is not listening on 443, 310 ms after up confirmed its ready conditions	#600

Rows 22 through 25 August were not read past ##[error]; their causes are
unknown, not absent.

Why the aggregation is itself the problem

An issue that reopens every night for a different reason converges on nothing.
Nobody can close it, because closing it would mean fixing five unrelated things
at once, and nobody can work it, because its title names a symptom that changes
meaning daily. Two of the five now have their own issue and can be finished
independently.

The suggestion, and it is a change to this gate rather than to the product:
a red night should name its cause in the issue it opens, and open a distinct
one per cause. The failure lines are already precise enough to key on — each of
the five above is a distinct, quotable sentence emitted by a named guard. What is
missing is that the "A red night opens the issue" job treats them as one.

Until that exists, this issue is best read as an index, not as a defect.

[stephrobert]

Correction to the table above: rows 08-27 and 08-28 14:49 are not open work. Both predate #586 (committed 2026-08-28T16:37 UTC), which is the fix for them, and the 08-29 night passes the leftovers gate. #601 was opened on that stale reading and is closed. The live rows are 08-26 (peering) and 08-29 (#600); 08-22 through 08-25 remain unread.

[stephrobert]

The 08-29 row of the table above is now tracked and closed: #600, delivered in #602 (bded1b3). The wait it adds cannot be proved by this station — a first boot answers here in under a tenth of a second, which is why the defect was invisible locally — so tonight's scheduled run is the measurement, not the local passes. Live rows remaining: 08-26 (the peering), and 08-22 through 08-25 whose causes were never read past ##[error].