CB-WP-0013-T02/T03: retire SH-3 as a gate; correct AM-4a and its target

ADR-0008, tier M (survey and ADR merged).

D1 — SH-3 retired as a gate, kept as a diagnostic. Investigating it
found a third defect, deeper than the two this pass was declared on.
Re-deriving batching from the raw transcripts, independently of cb-cost:

  CB-WP-0011 pass      54 with tools    0 batched    0.0%
    gap -> next decl   16 with tools    6 batched   37.5%
  CB-WP-0012 pass      86 with tools    0 batched    0.0%
    gap -> next decl   10 with tools    1 batched   10.0%
  CB-WP-0013 so far    10 with tools    0 batched    0.0%

Zero batched turns in 150 in-pass responses; 37.5% in one gap, above the
20% floor. Batching needs two calls whose inputs are known at once —
orientation work. Implementation consumes each step's result before the
next. SH-3's window is since the last commit, which during a pass is
always implementation. The metric could not read above ~0% in the window
it was gated on. A floor the window structurally excludes is not a
target.

This pass's own declaration was also wrong: it claimed batching "has got
worse" (7.8-8.6% vs 1.1-6.3%). Differently-placed windows, not different
behaviour. Withdrawn — the same class of error, in the pass written to
correct it.

Not retargeting to match the measurement: the floor was not moved to 6%,
the gate was removed on an argument about what the quantity is worth.
The number is still reported; only the verdict is gone.

D2/D3 — AM-4a counts --edges normal,no-proc-macro: 157,202, not 246,250.
The target moves down with it, 250,000 -> 161,000, so the correction
hands back essentially nothing (headroom 3,750 -> 3,798). Three controls:
the exclusion drops exactly the five expected crates, only removes and
never adds, and is not a no-op.

The DFD gate then caught the follow-on it exists for — three historical
documents carrying live fact tags for a number that had changed. Not
rewritten; untagged, with a supersession banner.

AM-4b is deliberately not corrected: its proc-macro share is unmeasured.

gate-review now reads 0 due, 0 silent, 0 drifted — GATE-REVIEW earns its
first caught entry by forcing SH-3's re-justification, and the registry
has no silent gates left.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

workplans/CB-WP-0013-instrument-corrections.md

@@ -125,7 +125,7 @@ eighth instance, with the real per-pass figures.
 
 ```task
 id: CB-WP-0013-T02
-status: todo
+status: done
 priority: high
 ```
 
@@ -151,11 +151,43 @@ already forbids exactly that, and CB-WP-0003 T07 exists to prevent it. If
 the floor moves, it moves on an argument about what batching is worth, and
 the argument is written down before the number changes.
 
+**Done 2026-08-02.** [ADR-0008](../decisions/ADR-0008-instrument-corrections.md)
+D1 — **SH-3 is retired as a gate and kept as a diagnostic.**
+
+Investigating it turned up a third defect, deeper than the two this
+workplan was declared on. Measured by re-deriving batching from the raw
+transcripts, independently of `cb-cost`:
+
+| window | with tools | batched | rate |
+|---|---:|---:|---:|
+| CB-WP-0011 pass | 54 | 0 | **0.0%** |
+| gap → next declaration | 16 | 6 | **37.5%** |
+| CB-WP-0012 pass | 86 | 0 | **0.0%** |
+| gap → next declaration | 10 | 1 | **10.0%** |
+| CB-WP-0013 so far | 10 | 0 | **0.0%** |
+
+**Zero batched turns in 150 in-pass responses; 37.5% in one gap.**
+Batching needs two calls whose inputs are known at once — orientation
+work. Implementation consumes each step's result before the next. And
+SH-3's window is *since the last commit*, which during a pass is always
+implementation. **The metric could not read above ~0% in the window it was
+gated on.**
+
+**And this workplan's own Purpose was wrong.** It stated batching *"has
+got worse"* (7.8–8.6% historical against 1.1–6.3% per-pass). Those come
+from differently-placed windows, not different behaviour. Withdrawn — the
+same class of error, in the pass written to correct it.
+
+The retirement is *not* retargeting to match the measurement: the floor
+was not moved to 6%, the gate was removed on an argument about what the
+quantity is worth, established before the disposition. The number is still
+reported; only the verdict is gone.
+
 ## Task: correct AM-4a to count what ships
 
 ```task
 id: CB-WP-0013-T03
-status: todo
+status: done
 priority: high
 ```
 
@@ -175,6 +207,30 @@ be able to drop crates it should have counted: assert that the proc-macro
 set is exactly the five expected crates and that removing the flag
 restores the old figure.
 
+**Done 2026-08-02.** ADR-0008 D2/D3.
+
+```
+shipped-runtime   18 crates   157,202 lines   [ok  target 161,000]
+```
+
+**The target moved down with the instrument**, 250,000 → 161,000, so the
+correction hands back essentially nothing: headroom goes from 3,750 to
+3,798. 161,000 keeps ~2.4% of room where 250,000 kept ~1.5%; that small
+rounding up is the only thing given back, because a target with 1.5% of
+room fails on a dependency's patch release.
+
+Three controls, all green: the exclusion drops **exactly** the five
+expected crates, only ever removes and never adds, and is not a no-op.
+
+**The DFD gate then caught the follow-on**, which is what it is for: three
+historical documents carried live `fact:am4a_loc` tags for a number that
+had changed. They are history and were not rewritten — the tags were
+removed and both documents carry a supersession banner instead.
+
+**AM-4b is deliberately not corrected.** Its proc-macro share is
+unmeasured, and correcting a second instrument on the strength of the
+first one's ratio is the error this task exists to fix. Filed as owed.
+
 ## Task: evidence
 
 ```task