"one list > an issue assigned to you is a row that says so, and every door counts it" passes every time on a loaded check machine #5467

I pinned the free disk in test/asks-one-list.test.ts. That is my best explanation for the flake, not a reproduced one.

What I found. I could not make the test fail here. It passed --rerun-each 150, six runs at a time, with ten CPU hogs running. The likely cause is the admin's own ask for the forge's disk:

• The test's user, alice, is the admin, so the forge's own needs count as asks. One of them is "Disk is nearly full", raised when free space on the data volume drops below 10% (DISK_FREE_MIN in src/kernel/vitals.ts).
• counts() reads the MCP tool, /live/on-you and the header count at slightly different moments, each from a live statfs of the real disk.
• This sandbox's volume is 89% used, so about 10.8% is free. On a check machine where parallel runs write to disk, free space can cross the 10% line between two of those reads. The doors then disagree, or before and after differ by more than the one assigned row.
• Nothing else I checked is time-driven. Roughly 3 ms for vitals and counts, versus a 5 s test timeout, rules out slowness.

What changed. createApp in that test now gets disk: () => ({ freeBytes: 95, totalBytes: 100 }), the same pin forge-degraded.test.ts and red-main.test.ts use. No assertion, timeout or retry was touched, and the test stays about assigned rows. The product was not changed: counting a full disk as an ask is correct, and the three doors count the same way.

Not done. The same test file still reads the real disk if it gets a new admin-count assertion elsewhere, so any other admin-viewer test that compares door counts has the same exposure; I did not audit them. Because the fix is unconfirmed, a failure of this test on the forge's check would mean the cause is something else.

Checked. bun test --rerun-each 30 on the named test passes (30/30), the whole file passes (5/5), and tsc --noEmit is clean.

Closes #5446

I pinned the free disk in test/asks-one-list.test.ts. That is my best explanation for the flake, not a reproduced one.

What I found. I could not make the test fail here. It passed --rerun-each 150, six runs at a time, with ten CPU hogs running. The likely cause is the admin's own ask for the forge's disk:

• The test's user, alice, is the admin, so the forge's own needs count as asks. One of them is "Disk is nearly full", raised when free space on the data volume drops below 10% (DISK_FREE_MIN in src/kernel/vitals.ts).
• counts() reads the MCP tool, /live/on-you and the header count at slightly different moments, each from a live statfs of the real disk.
• This sandbox's volume is 89% used, so about 10.8% is free. On a check machine where parallel runs write to disk, free space can cross the 10% line between two of those reads. The doors then disagree, or before and after differ by more than the one assigned row.
• Nothing else I checked is time-driven. Roughly 3 ms for vitals and counts, versus a 5 s test timeout, rules out slowness.

What changed. createApp in that test now gets disk: () => ({ freeBytes: 95, totalBytes: 100 }), the same pin forge-degraded.test.ts and red-main.test.ts use. No assertion, timeout or retry was touched, and the test stays about assigned rows. The product was not changed: counting a full disk as an ask is correct, and the three doors count the same way.

Not done. The same test file still reads the real disk if it gets a new admin-count assertion elsewhere, so any other admin-viewer test that compares door counts has the same exposure; I did not audit them. Because the fix is unconfirmed, a failure of this test on the forge's check would mean the cause is something else.

Checked. bun test --rerun-each 30 on the named test passes (30/30), the whole file passes (5/5), and tsc --noEmit is clean.