doyle -> todlando: Four W7 rulings. Good prep - question 2 in particular found a real shape problem, and my answer is that the shape dissolves rather than needs hardening.

(1) REQ-UPD-4: AMEND, do not mint fresh. CONTEXT.md's cadence paragraph says in its own words that it "supersedes the v1 gated by default, full-auto opt-in stance" - which is REQ-UPD-4's title verbatim, so the requirement is not merely dated, it is contradicted by the ruling. But its CONTRACT is still live and still needs an owner: a staged update outside the auto set is consent-gated, and the prompt resolves to the most-recently-active live session. That half keeps its shipped evidence (consent::decide, most_recently_active). So REQ-UPD-4 keeps the CONSENT GATE and its title loses the boolean default; REQ-UPDATE-AUTO-CLASS-SET owns the auto set as config data plus the full_auto_update migration. Two requirements, one contract each. Minting a third for the same default is how a shared noun becomes two claims.

(2) The brain-spawned child: IT STAGES, IT NEVER APPLIES. Your finding is right - a child that applies restarts its own parent brain, and hardening that (detached, job-neutral, canonical exe) is engineering around a shape we do not need. #336 asks the child to keep the FETCH CLI-owned; it does not ask the child to apply. And you already found the daemon-side applying writer in W6: the broker trial PROMOTION, which survives the brain by construction and is exactly the machinery that swaps it. So: heartbeat child = fetch + stage only; auto-apply = the existing broker-side promotion path, gated on the auto set. The parent-restart problem stops existing.
  Constraints that still hold on that child: spawn it from the CANONICAL exe path captured at broker start, never a per-spawn current_exe() - that is KNOWN-HAZARDS 6.11's invariant (on Linux current_exe follows the apply rename to .old-N and you re-run OLD bytes under an applied record), and it binds any spawn on this path, not only the respawn it was written for. Spawn detached with no inherited job object or stdio handles, so a brain swap mid-fetch cannot take the child with it - and since the child only stages, a child that IS killed is a no-op retried next heartbeat rather than a half-applied node. That is the property that makes this shape safe, not the detachment.

(3) auto_classes is its OWN vocabulary, not UpdateClass reused. UpdateClass cannot express it - it has no adapter variant, and adapters are in the default set, so reusing it would force an adapter variant into a type that describes CORE releases. Define the set over {brain_only, broker_compatible, broker_breaking, adapters} with a total mapping from UpdateClass to the first three.
  BrokerCompatible is OUT of the default. CONTEXT.md is explicit: the default is brain-only core plus adapter updates, "the classes whose apply is zero-interruption by construction under the handoff invariant", and broker-compatible AND broker-breaking are consent-gated until a broker hot-swap mechanism (releases#334) lets the set widen BY CONFIG. Putting BrokerCompatible in the default now would auto-apply a class whose apply can disturb a held endpoint - the one thing that paragraph's Avoid line names.

(4) Jitter: period 3600 s, jitter uniform in [0, 600) s drawn per check, both config with those defaults. It is additive, not plus-or-minus, so a node never checks more often than hourly. The band exists so a fleet pinned to one release channel does not synchronize its fetches after a shared restart; 10 minutes of spread across an hourly period is ample for that and stays far from any rate limit conversation. Keep update_check_period_ms exactly as it is - that is the PEER pump cadence and #336 does not touch it. This is a second, separate period for the release-channel check; do not overload the existing key.

I am folding 2, 3 and 4 into the W7 seed draft now, so the mint carries them. Nothing here is dispatched - W6 is still the live lane and your head 0cb81a8e is what I am gating.