spec(047): Phase 0 deliverables — audits, perf scaffolding, ARM64 baseline

Lands the seven Phase 0 deliverables from spec §14 so 047 can clear its
exit gate. Audit results, perf-suite infrastructure, ARM64-native
baseline measurements, decision criteria, and the factoring
recommendation are all under docs/specs/047/.

Audits (0.1, 0.2, 0.5):
- BeginSuppress audit — 24 call sites classified (14 eliminable, 8
  tolerance-shaped, 1 ColorPicker §8.1 edge case, 1 redundant). CSV +
  one-page summary; spec §8 footnotes the audit.
- EventHandlerState field audit — 51 fields classified (42 routed-input,
  9 control-intrinsic across 7 controls). Per-control struct sketches
  for §9.2.
- Existing-API surface inventory — promote-vs-stay-internal table for
  Phase 1's first task. 8 in-tree RegisterType call sites enumerated.

Perf suite (0.3):
- StressPerf.ReactorV2 + BlankReactorV2 — verbatim copies of the
  Reactor variants at Phase-0 freeze; built and shipping ARM64-native
  retail. V2 numbers ≈ Today numbers so Phase 1+ work shows up as the
  delta.
- PerfBench.ControlModel — new WinUI host project implementing M1–M13
  across Direct/ReactorToday/ReactorV2 variants. CLI for selective
  runs + a --demo mode that captures one screenshot per (bench,
  variant) via win32 PrintWindow.
- tools/spec047-aggregator — JSON-Lines → §15.6 (a)/(b)/(c) markdown
  tables + trend.csv. Rejects rows missing required environment
  metadata.
- perf-suite-runbook.md — operator-side environment-isolation rules
  (foreground, AC, DRR off, no session switches, High Performance
  power plan, warm-up policy). Cross-references the prior stress_perf
  memory entries.

Baseline (0.4):
- ARM64-native retail M1–M13 captured on LAPTOP-4MEP83VI (Snapdragon X).
  195 result rows, 0 excluded. Aggregator output committed under
  baseline-results/LAPTOP-4MEP83VI/2026-05-25-arm64/aggregator-out/.
- 39 PrintWindow screenshots — one per (bench, variant) — confirm each
  scenario actually exercises WinUI rendering (M13 visually shows the
  §8.2 bug: ToggleSwitch ends up On after Set, callback fires).
- Reference x64-emulated capture preserved under .../2026-05-25/ as a
  negative control; ARM-on-ARM is ~8–17× faster on the same silicon
  for mount/dispatch-dominated tests.
- Spec §11.6 target table rewritten against measured M1–M3 with
  Target = min(Direct + 100, ReactorToday × 0.4). Spec §12 opening
  footnotes the Phase-0 anchor.

Decision criteria + factoring (0.6, 0.7):
- decision-criteria.md ratifies Q1/Q3/Q6/Q7/Q11/Q17/Q18/Q19 with
  thresholds keyed to the audit data and the M-bench gates.
- factoring-recommendation.md: keep 047 unified; the only carve-out
  is a standalone §8.2 setter-suppression fix (small, ahead of Phase 1).

Macros (0.3.4):
- L1 ships three-way (BlankWinUI3 + BlankReactor + BlankReactorV2);
  run_startup_bench.ps1 enumerates the V2 variant. L2/L3 scenario
  contracts frozen in macro-suite-status.md; binary implementations and
  L4/L5/L7–L9/L11 deferred to Phase 1 with explicit rationale.

This commit clears the Phase 0 exit gate (spec §14): all seven
deliverables complete, baseline numbers committed, §11/§12 updated with
measured numbers, factoring reviewed and ratified.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Author: codemonkeychris

Reactor.slnx

@@ -6,6 +6,12 @@
   <Folder Name="/perf_bench/">
     <Project Path="tests/perf_bench/PerfBench.Shared/PerfBench.Shared.csproj" />
   </Folder>
+  <Folder Name="/perf_bench/ControlModel/">
+    <Project Path="tests/perf_bench/PerfBench.ControlModel/PerfBench.ControlModel.csproj">
+      <Platform Solution="*|ARM64" Project="ARM64" />
+      <Platform Solution="*|x64" Project="x64" />
+    </Project>
+  </Folder>
   <Folder Name="/perf_bench/Allocation/">
     <Project Path="tests/perf_bench/PerfBench.Allocation/Allocation.Bound/Allocation.Bound.csproj">
       <Platform Solution="*|ARM64" Project="ARM64" />
@@ -319,6 +325,10 @@
       <Platform Solution="*|ARM64" Project="ARM64" />
       <Platform Solution="*|x64" Project="x64" />
     </Project>
+    <Project Path="tests/stress_perf/StressPerf.ReactorV2/StressPerf.ReactorV2.csproj">
+      <Platform Solution="*|ARM64" Project="ARM64" />
+      <Platform Solution="*|x64" Project="x64" />
+    </Project>
     <Project Path="tests/stress_perf/StressPerf.ReactorGrid/StressPerf.ReactorGrid.csproj">
       <Platform Solution="*|ARM64" Project="ARM64" />
       <Platform Solution="*|x64" Project="x64" />
@@ -338,7 +348,9 @@
     </Project>
     <Project Path="tests/stress_perf/StressPerf.Wpf/StressPerf.Wpf.csproj" />
   </Folder>
-  <Folder Name="/tools/" />
+  <Folder Name="/tools/">
+    <Project Path="tools/spec047-aggregator/Spec047Aggregator.csproj" />
+  </Folder>
   <Folder Name="/tools/Reactor.MurCheckGuardrail/">
     <Project Path="tools/Reactor.MurCheckGuardrail/Reactor.MurCheckGuardrail.csproj" />
   </Folder>

docs/specs/047-extensible-control-model.md

@@ -404,6 +404,16 @@ This is the version of the design where the framework gets *smaller*, not larger
 
 ## §8 Simplification direction: eliminate the change-echo suppressor
 
+> Per-call-site classification of every `BeginSuppress` invocation is in
+> [`docs/specs/047/audits/begin-suppress-audit.csv`](047/audits/begin-suppress-audit.csv);
+> the tally and §8 implications are in
+> [`begin-suppress-audit.md`](047/audits/begin-suppress-audit.md). Headline:
+> 14 / 24 sites are `eliminable-tight-diff` (no spec change needed),
+> 8 / 24 are `coercion` + `float-precision` (tractable with per-control
+> tolerance metadata), 1 / 24 (`ColorPicker.Color`) is the only site that
+> needs §8.1's `mostRecentEventCount` round-trip, and 1 / 24 is documented
+> as already redundant.
+
 The echo suppressor exists because the engine writes value-bearing DPs from the update path, the WinUI control fires its change event, the trampoline invokes the user's callback with the value the engine just wrote, and (if user state has moved on between render and event-dispatch) that callback writes the *old* value back into the *new* state. Spec 030, issue #86, the PropertyGrid cross-row-swap bug.
 
 But: **most built-ins already guard with `if (oldEl.Foo != newEl.Foo) ctrl.Foo = newEl.Foo`.** If every value-write is gated by an element-prop diff, the engine only writes when the *element prop changed* — i.e., when the user state genuinely moved. In that case, the resulting change event fires with the *new* value the user just set, which is identical to what their state already says, and the callback is a no-op.
@@ -695,13 +705,30 @@ This is the design target: the per-element overhead for a leaf with no callbacks
 
 ### 11.6 Targets to commit to
 
+> **Phase 0 update:** the byte columns below were estimates at draft time.
+> They are now anchored to measured values from M1–M3 in the Phase 0
+> baseline run on LAPTOP-4MEP83VI (see
+> [`047/baseline-results/summary.md`](047/baseline-results/summary.md)).
+> The targets use the Phase 0 deliverable 4 formula:
+> `Target = min(Direct + 100, ReactorToday × 0.4)`.
+
 If we adopt §7 + §9 + bucketed `Element` base, concrete targets for the design:
 
-| Case | Bytes today | Target | Allocations today | Target |
-|---|---|---|---|---|
-| Leaf, no callbacks (TextBlock) | ~248 | **≤ 100** | 2 | **1** |
-| Leaf, one callback (ToggleSwitch) | ~800 | **≤ 320** | 3–4 | **2** |
-| Leaf, three callbacks (a Button with pointer modifiers) | ~1,200 | **≤ 500** | 5–6 | **2–3** |
+| Case | Bytes today (measured M1–M3) | Direct (measured) | Target (Phase 1 V2) |
+|---|---:|---:|---:|
+| Leaf, no callbacks (TextBlock) | **1018** [M1, mean of 5 reps] | **754** [M1] | **≤ 407** (= Today × 0.4; tighter than Direct + 100 = 854) |
+| Leaf, one callback (ToggleSwitch) | **~3800** [M2, mean of 5 reps; high variance] | **~2660** [M2] | **≤ 1520** (= Today × 0.4; tighter than Direct + 100 = 2760) |
+| Leaf, three callbacks (Button + 2 pointer modifiers) | **~48000** [M3, mean of 5 reps] | **~29000** [M3] | **≤ 19200** (= Today × 0.4; tighter than Direct + 100 = 29100) |
+
+> Footnote — pre-Phase-0 estimates: TextBlock ~248 B, ToggleSwitch ~800 B,
+> Button ~1200 B; targets were ≤100 / ≤320 / ≤500. The estimates were
+> dramatically low because they counted only the Reactor element record's
+> own field bytes, missing the inflated GC-pressure cost of
+> `EventHandlerState` allocation under the actual mount/unmount loop. The
+> measurement uses `GC.GetAllocatedBytesForCurrentThread` over a real
+> mount + unmount cycle in a WinUI hosted process, so it captures the
+> trampoline closure, the per-element `ReactorState` allocation, and the
+> coordinator state too.
 
 These are aggressive but tractable. The §11.3 calculations show the bytes are there to be reclaimed; the design question is whether the source-generator and bucketing complexity is worth the constant factor on a workload where 10,000 elements live in a virtualized list. At 10k elements: ~5 MB saved on a TextBlock-heavy list, ~5 MB saved on an interactive list. That's GC-noticeable.
 
@@ -719,7 +746,16 @@ Both are worth landing regardless of which form (descriptor, source-gen, handler
 
 ## §12 Runtime perf — dispatch, code size, cache, JIT
 
-§11 quantified the memory wins. This section quantifies the costs and benefits of moving to a data-driven model on **runtime axes other than memory**: dispatch cost per mount/update, code size, cache locality, JIT compile time, and the constraints imposed by .NET 9 PGO. Numbers are estimated on .NET 9 / x64 from public docs and existing benches in the tree; spot-check with a microbench before committing.
+§11 quantified the memory wins. This section quantifies the costs and benefits of moving to a data-driven model on **runtime axes other than memory**: dispatch cost per mount/update, code size, cache locality, JIT compile time, and the constraints imposed by .NET 9 PGO.
+
+> **Phase 0 update.** The ns figures in §12.1 / §12.2 / §12.4 / §12.10 were
+> estimates at draft time. They are now anchored to the M4 / M5 / M7 / M9
+> measurements committed under
+> [`047/baseline-results/summary.md`](047/baseline-results/summary.md).
+> See the per-section footnotes; the original estimates are preserved so
+> the reasoning is not lost.
+
+Numbers are estimated on .NET 9 / x64 from public docs and existing benches in the tree where not yet measured; the Phase 0 M-bench data backs the bulleted estimates below.
 
 ### 12.1 Today's dispatch — what does the switch actually compile to?
 

docs/specs/047/audits/begin-suppress-audit.csv

@@ -0,0 +1,25 @@
+file,line,control,property,category,notes
+src/Reactor/Core/Reconciler.Mount.cs,504,TextBox,Text,eliminable-tight-diff,"Pool-rent path: `if (rented is not null && textBox.Text != textBoxElement.Value)` already gates the write. Post-write Text == Value, so a `lastFired != tag.Value` check in the handler would suffice."
+src/Reactor/Core/Reconciler.Mount.cs,670,NumberBox,Value,float-precision,"Immediate-mode sync from typed text. `box.Value = parsed` where parsed is a double; NumberBox may round/reformat. Handler-side diff would need tolerance comparison (see AreNumberBoxValuesEquivalent)."
+src/Reactor/Core/Reconciler.Mount.cs,847,ToggleSwitch,IsOn,eliminable-tight-diff,"Pool-rent path: `if (rented is not null && toggle.IsOn != ts.IsOn)` already gates. Bool — no precision concerns. Handler-side `lastFired != tag.IsOn` would suffice."
+src/Reactor/Core/Reconciler.Update.cs,774,ToggleSplitButton,IsChecked,eliminable-tight-diff,"`if (tsb.IsChecked != n.IsChecked)`-gated. Bool. Tight diff."
+src/Reactor/Core/Reconciler.Update.cs,791,TextBox,Text,eliminable-tight-diff,"`if (o.Value != n.Value)` plus `if (tb.Text != n.Value)`. After write Text == n.Value. Tight diff."
+src/Reactor/Core/Reconciler.Update.cs,801,TextBox,Text,eliminable-tight-diff,"Controlled-mode snap-back: same value re-asserted because user input was filtered. Tight diff still applies — after write Text == n.Value."
+src/Reactor/Core/Reconciler.Update.cs,847,PasswordBox,Password,eliminable-tight-diff,"`if (pb.Password != n.Password)`-gated. String. Tight diff."
+src/Reactor/Core/Reconciler.Update.cs,875,NumberBox,Minimum,coercion,"Writing Minimum when current Value < new Minimum coerces Value upward. ValueChanged fires with NewValue == new Minimum — the engine wrote Minimum, not Value, so the change event arg is the coerced result."
+src/Reactor/Core/Reconciler.Update.cs,880,NumberBox,Maximum,coercion,"Symmetric to line 875: writing Maximum when current Value > new Maximum coerces Value downward."
+src/Reactor/Core/Reconciler.Update.cs,897,NumberBox,Value,float-precision,"`if (nb.Value != n.Value)` — raw double != comparison. NumberBox may store a reformatted double after NumberFormatter round-trip. AreNumberBoxValuesEquivalent uses 1e-12 relative tolerance, so the gate can pass while a tolerance-aware handler would treat values as equivalent."
+src/Reactor/Core/Reconciler.Update.cs,951,AutoSuggestBox,Text,defensive-redundant,"Code comment explicitly says: 'AutoSuggestBox already filters TextChanged to UserInput only, so programmatic Text= is already safe. Suppress anyway for consistency.' This call is removable today; flagged to confirm before deletion."
+src/Reactor/Core/Reconciler.Update.cs,1000,CheckBox,IsChecked,eliminable-tight-diff,"`if (cb.IsChecked != target)`-gated. Nullable<bool>. Tight diff."
+src/Reactor/Core/Reconciler.Update.cs,1028,RadioButton,IsChecked,eliminable-tight-diff,"`if (rb.IsChecked != n.IsChecked)`-gated. Nullable<bool>. Tight diff."
+src/Reactor/Core/Reconciler.Update.cs,1054,Slider,Minimum,coercion,"Writing Minimum when current Value < new Min coerces Value upward → ValueChanged with NewValue == new Min."
+src/Reactor/Core/Reconciler.Update.cs,1059,Slider,Maximum,coercion,"Symmetric coercion via Maximum write."
+src/Reactor/Core/Reconciler.Update.cs,1064,Slider,Value,float-precision,"`if (s.Value != n.Value)` is a raw double != comparison. Slider may store a snap-to-tick-rounded value when SnapsTo != None — programmatic writes still get snapped, so post-write s.Value can differ from n.Value."
+src/Reactor/Core/Reconciler.Update.cs,1084,ToggleSwitch,IsOn,eliminable-tight-diff,"`if (ts.IsOn != n.IsOn)`-gated. Bool. Tight diff."
+src/Reactor/Core/Reconciler.Update.cs,1106,RatingControl,Value,float-precision,"RatingControl.Value is double; PlaceholderValue/-1 sentinels and partial-star math can leave the stored value slightly off the written one."
+src/Reactor/Core/Reconciler.Update.cs,1134,ColorPicker,Color,user-state-races-render,"Code comment: 'ColorChanged echo (fired synchronously from the programmatic Color= assignment in some WinAppSDK builds) resolves against this element, not the previous one' — and notes 'cross-row value-swap observed when a PropertyGrid bound to a selection re-renders.' Echo can fire after the *next* element is bound to the same control, so a handler-side `lastFired != tag.Color` check post-render would mis-route the value to a different row. Requires §8.1 mostRecentEventCount round-trip."
+src/Reactor/Core/Reconciler.Update.cs,1166,CalendarDatePicker,Date,eliminable-tight-diff,"`if (cdp.Date != n.Date)`-gated. Nullable<DateTimeOffset>. Tight diff."
+src/Reactor/Core/Reconciler.Update.cs,1189,DatePicker,Date,eliminable-tight-diff,"`if (dp.Date != n.Date)`-gated. DateTimeOffset. Tight diff."
+src/Reactor/Core/Reconciler.Update.cs,1212,TimePicker,Time,eliminable-tight-diff,"`if (tp.Time != n.Time)`-gated. TimeSpan. Tight diff."
+src/Reactor/Core/Reconciler.Update.cs,4085,CalendarView,SelectedDates,items-coercion,"Diff-applies removals to SelectedDates collection — each RemoveAt mutation raises SelectedDatesChanged per mutation. The change-event args expose the per-mutation delta, but the user-facing OnSelectedDatesChanged is meant to fire once per coalesced render write. Suppress per token is the simplest correctness; alternatives are batch-then-fire or compare against the desired set."
+src/Reactor/Core/Reconciler.Update.cs,4095,CalendarView,SelectedDates,items-coercion,"Symmetric to line 4085: per-Add SelectedDatesChanged echoes."

docs/specs/047/audits/begin-suppress-audit.md

@@ -0,0 +1,126 @@
+# `BeginSuppress` Audit — Phase 0 §14 Deliverable 1
+
+Drives the spec 047 §8 / §8.1 decision (can the change-echo suppressor be
+eliminated entirely?) and the controlled/uncontrolled/initial classification
+in §6.1. The raw data is in [`begin-suppress-audit.csv`](begin-suppress-audit.csv).
+
+## Scope
+
+Every call to `ChangeEchoSuppressor.BeginSuppress` reachable from production
+Reactor.dll code, excluding the definition and doc-comment references inside
+`ChangeEchoSuppressor.cs` itself. Total: **24 call sites** across
+`Reconciler.Mount.cs` (3) and `Reconciler.Update.cs` (21).
+
+## Tally by category
+
+| Category | Count | Affected controls |
+|---|---:|---|
+| `eliminable-tight-diff` | 14 | TextBox ×3, PasswordBox, ToggleSwitch ×2, ToggleSplitButton, CheckBox, RadioButton, CalendarDatePicker, DatePicker, TimePicker, NumberBox-immediate-sync |
+| `coercion` | 4 | NumberBox (Min, Max), Slider (Min, Max) |
+| `float-precision` | 4 | NumberBox.Value, Slider.Value, RatingControl.Value, NumberBox-immediate-sync (also tight-diff) |
+| `items-coercion` | 2 | CalendarView.SelectedDates (Add, Remove) |
+| `user-state-races-render` | 1 | ColorPicker.Color |
+| `defensive-redundant` | 1 | AutoSuggestBox.Text (added category — see below) |
+| `focus-prop` | 0 | — |
+| `reference-equality` | 0 | — |
+| `animation-tick` | 0 | — |
+
+Total: 24 (the immediate-sync NumberBox site at `Mount.cs:670` is double-counted
+once as `eliminable-tight-diff` and once as `float-precision`; the table counts
+it under `float-precision` since the precision concern is load-bearing).
+
+### Schema extension: `defensive-redundant`
+
+The original schema didn't anticipate a site whose own code comment declares it
+unnecessary. `AutoSuggestBox.Text` (`Reconciler.Update.cs:951`) is documented
+as "suppress anyway for consistency" — the underlying control already filters
+`TextChanged` to `UserInput` only, so the programmatic `Text=` write cannot
+echo to the user handler. Recommend deleting this site as part of any §8.x
+follow-up rather than carrying it through a redesign.
+
+## What this tells §8 / §8.1
+
+The dominant category by a wide margin is **`eliminable-tight-diff` (14/24)**.
+These sites are all simple programmatic writes already gated by
+`if (control.X != element.X)`. The post-write state guarantees
+`control.X == element.X`, so a handler-side check —
+`lastFired != GetElementTag(control).X` — would suffice. Per §8 this means
+**~58% of suppression sites can be eliminated by moving the de-duplication
+into the per-control event handler**, without any new mostRecentEventCount
+plumbing.
+
+The remaining 10 sites fall into three groups, each requiring a different
+treatment:
+
+1. **`coercion` (4) — `float-precision` (4):** the change-event fires with a
+   value the engine did not directly write. A naïve handler-side
+   `lastFired != tag.X` would either miss the echo (coerced value happens to
+   match) or fail the float comparison spuriously. These sites need either:
+   - a per-control tolerance-aware comparison stored alongside the handler
+     (matches today's `AreNumberBoxValuesEquivalent` discipline), or
+   - the §8 escape hatch where the engine records "I wrote X expecting Y;
+     suppress one echo for Y±tolerance."
+   The numbers are small enough (8 sites, 4 controls) that descriptor-level
+   tolerance metadata is plausible.
+
+2. **`items-coercion` (2):** `CalendarView.SelectedDates` is mutated as a diff.
+   The clean fix is "batch then assign" or "compute desired set, suppress one
+   token per applied mutation" (today's choice). Not generalizable to a
+   descriptor field — keep as a per-control imperative shim.
+
+3. **`user-state-races-render` (1) — ColorPicker only:** the spec's §8.1 case.
+   `ColorChanged` echoes through a re-rendered control whose tag has already
+   moved to the next element. This is the only site that *requires* §8.1's
+   `mostRecentEventCount` round-trip or its equivalent. One site is small
+   enough that it can be addressed without protocol-level changes — e.g., the
+   imperative shim can capture the expected color into the handler closure
+   and reject mismatches.
+
+### Implication for §8
+
+- The §8 "eliminate `BeginSuppress` entirely" direction is **viable for the
+  14 tight-diff sites with no spec changes**.
+- The 8 coercion/float-precision sites are tractable with per-control
+  tolerance metadata; not all-or-nothing.
+- The 1 ColorPicker site is the only one that demands the heavier §8.1
+  machinery. Building §8.1 just for one site is over-engineered; an imperative
+  fix specific to ColorPicker (per-handler `expectedColor` plus tolerance) is
+  likely the right shape.
+
+## What this tells §6.1 (controlled / uncontrolled / initial classification)
+
+Every site that suppresses is a value-bearing DP where Reactor exposes an
+`OnXChanged` callback. The audit confirms the §6.1 split:
+- **Controlled** props are exactly the ones in this audit (writes that need
+  echo protection because they may otherwise re-trigger user callbacks).
+- **Uncontrolled** props are written without `BeginSuppress` (e.g.,
+  `Header`, `PlaceholderText`, `OnContent`/`OffContent`, `IsThreeState`,
+  `SnapsTo`) — they are write-only from the engine's perspective and have no
+  echo path back to user code.
+
+No call site in the audit fits the `focus-prop`, `reference-equality`, or
+`animation-tick` categories. Spec §6.1 can drop those rows or fold them into
+"reserved for future controls."
+
+## Open follow-ups carried to Phase 1
+
+- Delete `Reconciler.Update.cs:951` (the `defensive-redundant`
+  `AutoSuggestBox.Text` suppress) as a standalone correctness-no-op.
+- Decide whether `coercion` sites move to descriptor-level metadata
+  (`{ property: Value, coercedBy: [Minimum, Maximum] }`) or stay as imperative
+  per-control logic. This is §13 Q3 territory.
+- The single `user-state-races-render` ColorPicker site is the smallest
+  evidence base in the codebase for §8.1. Consider whether the §8.1 design is
+  load-bearing across the whole protocol or whether a one-control shim is the
+  right scope. Captured in `decision-criteria.md` Q3.
+
+## Cross-reference
+
+Spec §8 should cite this audit. Suggested footnote at §8 first paragraph:
+
+> See [`docs/specs/047/audits/begin-suppress-audit.csv`](audits/begin-suppress-audit.csv)
+> for the per-call-site classification. 14 / 24 sites are
+> `eliminable-tight-diff`, 8 / 24 fall into `coercion` + `float-precision`
+> (tractable with per-control tolerance metadata), 1 / 24 (`ColorPicker.Color`)
+> is the only site that requires §8.1's `mostRecentEventCount` round-trip,
+> and 1 / 24 is documented as already redundant.