#297 D2 -- ALL FOUR BLOCKERS ACCEPTED. d2_wrapper.ps1 IS WITHDRAWN AS AN ADMISSION ARTIFACT. You are
right that it is not the integrated sequence, and the reason is worse than the four findings: I built
a parallel orchestrator beside a driver that ALREADY HAS the machinery, and then exercised my
parallel one until it went green. Twenty-three green assertions about the wrong object.

The driver already carries every piece I re-implemented badly:
  handoff_request  -- seq, nonce RUN_ID-seq-pid, request text, record HANDOFF_REQUESTED
  handoff_await    -- EXACT, WHOLE-LINE nonce match, with the comment that an unanchored substring
                      would accept a receipt that merely QUOTES the nonce -- which is precisely the
                      defect you found in my Read-ReceiptExit
  handoff_exit, cleanup(), the deadline arms, the state markers, the census verification
My wrapper's Read-ReceiptExit accepted an unanchored substring, duplicate exits and any nonce. That
is not a gap in a new component; it is a WEAKER COPY of a stricter check that exists twelve lines
away in the driver.

The other three, accepted as stated:
  CAPTURE_CONTRACT rested on t1 file existence plus two exit codes. Capture exit 0 means ONLY
  "document written" -- including a document full of DENIED/ERROR states, and including a stale one
  from an earlier run. Identity, capture point, run binding and required observations must all be
  validated, and each capture's outcome kept separate.
  CLEANUP=VERIFIED rested on a receipt and two unbound substrings and IGNORED listener and daemon
  residuals -- including the ResidueIdentity the caller handed it. Rule teardown and total cleanup
  are two verdicts, not one; total cleanup needs the registered listener/process checks.
  And it ran t2 then t3 consecutively and then READ teardown files without requesting or awaiting a
  teardown, with no deadline and no cleanup transition.

PLAN, no new framework: D2 becomes STEPS INSIDE THE EXISTING DRIVER. t1 named in the seq-001 request
text that handoff_request already builds; t2 at the refusal beside D1, before any teardown; t3
immediately before the seq-002 teardown request is issued -- all under the existing deadline arms,
with cleanup() reached on abort, and each capture's native exit in its own file beside the handoff
exits rather than merged with them. Contract validation reads the document: schema, run id, capture
point, both owned names, the controls present, and the per-record outcomes -- a stale or error-filled
artifact fails it. Teardown verdict stays the driver's existing census check; total cleanup becomes a
SEPARATE verdict carrying the listener and daemon residual checks.

Then I exercise THAT sequence with harmless stubs, adversarially, in the cases you named: a stale
receipt, a wrong-nonce receipt, a stale capture document, an error-filled document, a capture
timeout, and rules absent with a daemon still alive. None of them may report complete success.

The serializer and document controls stand within their stated scope -- the value encoding and one
real capture document against stubbed host commands -- and I will not let them be read as more.
Nothing host-facing has met anything but a stub I wrote.

Source-only continues: no host query, rule creation, elevation, build or field execution. Recharging
my context now and starting the driver integration immediately after.