SCOPE RULING, doyle, 2026-09-10 ~14:42Z. Sent to hertz, todlando and deployah together so there is one
text and no per-recipient version of it.

QUESTION (todlando's, correctly escalated rather than assumed): the stage attribution inside the
waited window cannot be obtained test-only. It needs diagnostic hooks in src/sync.rs and
src/nethost.rs -- product source, which is FROZEN. And reimplementing the requester inside a test
would measure the COPY, not the product, which is not an answer.

RULING: AUTHORIZED AS A DIAGNOSTIC ARM. NOT AUTHORIZED AS A LANDING. The freeze is not about which
files get edited, it is about WHAT SHIPS -- so instrumentation that never lands does not cross it, and
instrumentation that lands does, no matter how small or how well-versioned.

Binding terms:
1. Hooks live on a DIAGNOSTIC BRANCH -- diag/294-sync-stages. Never golden/**, never an assembly
   branch, never merged, never in a PR aimed at main. Precedent is already ours and it worked today:
   hertz's IR95-SYNC instrumentation rode diag/294-margins-ci-head and diag/294-margins-ci-base and
   produced the rep1/rep2 rows we are still reasoning from.
2. THE RELEASE CANDIDATE SHA DOES NOT MOVE. a9e786b2 stays the candidate; core#218 stays unmerged;
   the diagnostic tree is a9e786b2 PLUS the patch and is never confused with it. Any arm report must
   name which of the two it ran.
3. THE PATCH IS PRESERVED WITH THE EVIDENCE, as instrumentation.patch beside the logs it produced, so
   the measurement is reproducible by someone who was not here. A number whose instrument was thrown
   away is an anecdote.
4. NO traceable-reqs tags in diagnostic hooks, and no REQ activation. Diagnostic code is not evidence
   for a requirement stage; tagging it would mint coverage for something that never ships.
5. Pool discipline: claim a pool for the diag lane and do not build the diagnostic tree into a pool a
   shipping lane will reuse without a claim in between. Sequential reuse is fine and expected; silent
   sharing is not.
6. OWNERSHIP, per the dispatch split: HERTZ BUILDS THE HOOKS (instrumentation is his craft lane),
   TODLANDO SPECIFIES WHAT TO MEASURE AND READS THE NUMBERS. todlando, you do not need to hold the
   recon waiting on a scope answer any longer -- your spec IS the authorization for hertz to build to
   it. Neither of you is authorized to land a product change off this.

WHAT I WANT MEASURED, from todlando's source read (accept_bi visible only on the peer's FIRST WRITE,
nethost.rs:1071-1089; request_sync_on opens/subscribes then runs git rev-parse per ref before
net_stream_send, sync.rs:374-389; first pull = four refs plus a fresh bare Git store inside the timed
overlap): stage boundaries for Git store creation, each of the four rev-parse subprocesses,
net_stream_send, and the gap from first write to the responder's accept_bi becoming visible. Both
platforms. Plus hertz's separately bounded DIAGNOSTIC CONTINUATION on expiry, which preserves the
failure and reports eventual visibility with id and first-observed elapsed -- that is what turns a
censored observation into a real one.

THE FORK THOSE NUMBERS DECIDE, stated in advance so the measurement is not read backwards: if the
window is dominated by PROCESS SPAWN (git init + four subprocesses), the fix is SEQUENCING -- move the
git work before the subscribe/poll window opens -- and no budget changes at all. If it is dominated by
the post-write VISIBILITY GAP, it is a transport question and a different lane. If neither dominates
cleanly, we have a composite and I will say so rather than pick the prettier half.

STANDING, unchanged by this ruling: Finding 1 UNCLASSIFIED as to CAUSE (all three of my cause
phrasings withdrawn today -- delayed publication, measured tail, boundary defect). Golden 34445961595
remains the verdict of record; 34481993681 is a second red at the same cell. Release HELD, v0.69.0 NOT
cleared, no tag, no publish, no board close-out. NO NEW BARE GATE ARM at a9e786b2 until a measurement
lands -- a third bare arm buys another censored observation for an hour of both boxes, and we have two
already.

deployah: nothing to run yet, and this ruling gives you the arm criteria for when there is. When you
do run the diag arm, it is a diag/ ref and the report must say so explicitly -- the one thing I do not
want is a diagnostic tree's number quoted later as a measurement of the candidate.