TWO DEFECTS, ONE INCIDENT. ov_SC03_105's own SUCCESSFUL gate committed an isolation's new TUs
(src/ov_SC03_105/ov_SC03_105_jr_801813BC.c, _jr_80181C84.c) whose `INCLUDE_ASM` lines name .s files
that do not exist until a re-extract. corpus.stubs then refused — correctly, "the tree and the
source disagree" — so the NEXT gate on that binary died before doing any work, and a matched body
(func_801818E8) sat unbankable behind it.
1. THE REASON NOW TRAVELS WITH THE REFUSAL. stubs_of() returned a bare None and the caller printed
"corpus refused in worktree": true, and naming nothing. It took a hand-built worktree to see that
corpus had said exactly what was wrong all along. It now returns the message and the result JSON
carries it. Verified against a TRUE reproduction (delete one .s in a scratch worktree):
verdict REFUSED + "1 stub(s) have NO .s on disk ... src/...:4214: asm/.../func_8017F018.s".
2. THE MERGE STEP REPAIRS WHAT IT BROKE. For every binary whose carve created a new source file,
assert corpus.stubs is satisfiable in the MAIN tree; if not, `make extract BINARY=<b>` and
re-assert; if it is STILL unreadable, say so loudly rather than leaving a tree no tool can read
(R32/R43). This is the R22 corollary — a config change needs a make extract, not just a make
check — firing inside a tool's own commit.
Repaired the live instance by hand first: rm -rf asm/ov_SC03_105 + extract + build -j + check ->
BYTE-IDENTICAL d305ff6d, corpus readable again, and func_801818E8 then banked (commit:3718).
Cookbook §436-D; wave-playbook §6 carries the hand-gating version of the same warning.
Drew T
e9220d2d8a