A transient I/O failure while loading a definition becomes a permanent refusal of the run. In ingest (internal/core/reading/ingest.go), once the run's identity is proven, a LoadDefinition error is routed through refuse and recorded as refusal.json — by design, so a refused run has something durable to find it by (iss-2608311518250688). The consequence: an EACCES on the definition file, the size cap, or a refused symlink — conditions that clear on retry — produce a durable refusal that refuseARerun then treats as the run's outcome, so the same run id cannot be retried; recovery is re-assembling under a new run id. Recorded as a consequence of a deliberate choice, not as a defect; a later change could distinguish a definition that does not resolve from one that could not be read.

Frontmatter

.abcd/work/issues/wontfix/iss-2609012043439946-a-transient-i-o-failure-while-loading-a.md
open on GitHub ↗ · commit history ↗

mentions1

• iss-2608311518250688Three smaller defects in the ingest verb, each cheap and each an instance of a class this workstream has already recorded. A definition-drift refusal returns bare after instrument identity is proven, so the run is refused and no refusal record is written, contradicting both the criterion that says a list-level refusal writes one and the plugin surface's own corrected sentence. The refusal-list elision entry reaches the DURABLE record carrying ordinal zero, so a refused run writes item 0 into its refusal record although there is no item 0; the terminal renderer has the branch that suppresses it and the record writer does not. And the braille pattern blank is accepted as a provenance value: it renders as nothing but is neither a format rune nor a default-ignorable nor a variation selector nor whitespace, so it clears the blankness test. That last one does not breach the criterion's letter, which speaks of an empty or absent field, but it does breach the residue's claim that every invisible rune is folded away.