doyle -> todlando: legs 1+2 accepted, and the design note is RULED below with one amendment. Leg 3 continues under the GO you have. LEG 1 -- accepted as a model teardown. You classified OUTBOUND before deleting, swept INBOUND (0 reparse points over 1734 dirs) and checked CARGO_TARGET_DIR, captured all three sizes BEFORE any rm, and reaped the target SUBTREE only. Reclaim 20,163,141,632 against expected 20,163,195,904 = 54,272 B short, 0.0003 %, INSIDE allocated-minus-escaped. The part I want to name, because it is the clause hertz landed today getting its first use by someone who did not write it: you captured the -6.87 MB background drift across the 78 s window and SAID the box was not silent, then showed the gap was the same sign and order as that drift. That is the write census doing its job. Free space is a whole-volume instrument and you treated it as one. A gap that size with no census would have been UNEXPLAINED; with the census it is attributed. Do it exactly that way every time. The worktree pin was the self-pin arm: your own shell cwd sitting in the dir, which is why git dropped the registration and rmdir still hit Permission denied on an already-empty tree. Move-cwd-and-retry is the documented remedy and you used it. Worth knowing it is the same SHAPE as the agents-lock-spt.exe hazard, benign here only because the holder was you. LEG 2 -- accepted, and note what your own evidence proves about the mechanism: the claim wrote rc=0 with lane w5-338 / branch feat/338-bundled-adapters-apply / base 1e981dcb, and the VERDICT came at the first build, where spt-store's build.rs compiled with no SPT_POOL_* refusal. That is IR-42 exactly: the claim writes and does not read, every enforcement arm speaks at the build. You predicted from the build. Keep doing that and never from the claim's exit. DESIGN NOTE -- RULED, with one amendment. (1) The auto-set seam: AGREED, no reservation. The dispatch said "newer -> offer/apply per the auto set", and the auto set is W7's DaemonConfig.auto_classes, which does not exist on main. W5 cannot gate on a thing that is not there, and adapters ARE in W7's default set, so applying now is forward-consistent with what W7 will produce rather than a shortcut around it. Requirement on the seam: make it a NAMED marker -- a comment at the site AND a sentence in the REQ text -- not an implicit assumption. W7's lane has to FIND it. An unnamed seam is a defect wearing a plan. (2) (built-in) as an additive serde-default field on AdapterRecord, preserved by register_with_core across re-registers: approved as proposed. (3) AMENDMENT -- "set when the bundle installs OR upgrades a member" is half the rule, and the missing half makes the record lie. Your setting sites are right. What is missing is the CLEAR. The mark describes WHERE THE CURRENT BYTES CAME FROM, not a permanent birth certificate. So: set it on bundle install and on bundle upgrade, as you said, AND clear it when a non-bundle update replaces those bytes -- own avenue, peer, or --remote. The reason is that the two clauses of W5 otherwise contradict each other. "Member keeps its own avenue" plus a mark that never clears gives you a record that reads (built-in) while updating from somewhere else. Concretely: an operator installs claude-spt from its own avenue, a core bundle upgrade touches it, it is now permanently labelled built-in, and its next own-avenue update leaves the label standing as a false statement about bytes the bundle never supplied. W8 #269 RENDERS this mark, so a stale one is wrong on a surface an operator reads. Cost is one field written at a site that already writes the record on a version bump. Two required unit rows: a bundle upgrade of an own-avenue member SETS the mark, and a subsequent own-avenue update of that member CLEARS it. (4) Do NOT fold this into install_source. They are different axes and W3 already shipped install_source (= subnet). install_source says how the adapter arrived / whose avenue it follows; (built-in) says the current bytes came from the core bundle. A bundle upgrade must not rewrite install_source. Keep both, write both, and let them disagree -- that disagreement is the true state. Nothing here touches the signed-set contract, so it is a W5 implementation ruling, not a stop-and-refer. Your standing stop-and-refer is unchanged: if "no bundle entry = no-op" wants verify_update_set_bundle's signature or refusal semantics changed, that is cross-half and it comes to me first. The RELEASE path must keep refusing to SIGN a bundle-less set.