story-128: One item's Status is read by its own id, so filing survives a board of any size

[jerodw]

Story

One item's Status is read by its own id, so filing survives a board of any size.

To learn what the board already said about the item it had just added, the sync script listed the whole project and picked one object out of the listing. Two things followed, and both have now been paid for.

The bound, and the failure that is worse than it sounds

The listing is capped at 5000 items, and a newly added item sits at the end of the board's order. So once a board grows past that cap, the item this invocation just added is exactly the one the listing cannot report.

The script then exits transiently — correctly, on the reading that a listing which did not mention the item is a failure to know rather than an empty Status. But the entry it leaves pending is retried on every sweep and can never succeed, because the next sweep reads the same bound against the same board.

The comment describing that cost as "a pending entry and never an overwritten value" reads as bounded. The real cost is that the deployment stops filing anything, permanently, with nothing in its state to tell that apart from a board that is briefly unreachable.

The bound was not the first way it failed

On 2026-09-07 a brief's issue was created and added to project 1, and the listing that followed did not contain the item — on a board of 49. The add had been accepted; the listing had not caught up.

The entry deferred saying the item "was not in the first 5000 items", naming a bound that had nothing to do with it. A re-run moments later found the item and set every field on the first attempt.

Both are answered by asking for the item rather than for the board

The item's node id is already in hand, so reading that node's field values answers the same question in one request: consistent by id rather than against an index that lags, and with no size to outgrow.

Evidence

• Suite: 5595 passed, 1 skipped (exit 0)
• Clean clone with the story committed: exit 0
• Verification passed, no blocking issues
• 0 retries, 0 self-routes, 1 correction pass, $16.42
• 8 files changed, +621 / −119

Notes for review

This is not a wall this deployment was near. The board holds about 66 open items against a cap of 5000. What it had met is the second failure — the lagging listing on a 49-item board — which the old shape reported as a size problem it was not.

Two unverified notes. A documentation claim about how one particular error shape reduces is not driven by any test. And the account of the 2026-09-07 filing is traced to the story artifact rather than to independent evidence — the run directories that would show it are gitignored.

Planned from the brief filed under key 118, one of the board-mechanics findings from story-105's inspection.

🤖 Generated with Claude Code

https://claude.ai/code/session_019WkxmJ5ArLEaC2RDPGkbRU