xenia-rs/audit-runs/phase-c15a-schema-wiring/new-divergences.md

Phase C+15-α — New Divergence Catalog (2026-05-14)

Surfaced by the schema-v1.1 wiring of handle.create/destroy, thread.create/exit, wait.begin in both engines.

Cold-vs-cold matched-prefix table (post-wiring)

canary_tid	ours_tid	matched	first_divergence_at	divergence kind
6	1	102,168	102,168	extra handle.destroy in ours (XamTaskCloseHandle refcount mismatch)
15	10	16	—	no divergence in 16 evts (canary 3.6M, ours stalls)
7	2	30	30	KeWaitForSingleObject native-obj handle (class E)
4	11	8	8	KeWaitForMultipleObjects native-obj handle (class E)
12	7	2	2	KeWaitForSingleObject native-obj handle (class E)
14	9	2	2	KeWaitForSingleObject native-obj handle (class E)

Main matched prefix dropped from 104,574 (C+13/C+14) to 102,168 — a regression of ~2,400 events. This is the expected outcome: invisible state divergences are now visible.

Cataloged divergences (priority-ordered for future iterate)

D-1 (HIGH) — main chain idx=102,168: extra handle.destroy on XamTaskCloseHandle

• Chain: canary tid=6 ↔ ours tid=1.
• Event:
  • ours: handle.destroy sid=b53a312c0ac30f49 then kernel.return XamTaskCloseHandle return=1
  • canary: kernel.return XamTaskCloseHandle return=1 (no handle.destroy)
• Hypothesis: Ours's xam_task_close_handle (xam.rs:300-344) decrements refcount and destroys the handle when it reaches 0. Canary's XamTaskCloseHandle_entry → NtClose → ObjectTable::ReleaseHandle only destroys when refcount reaches 0; canary's spawned thread keeps an additional ref on the thread handle (object->Retain() in XThread::Create line 408 via RetainHandle()). Ours's refcount of 1 at this point is wrong — should be 2 (user ref + spawned-thread ref). Ours destroys prematurely.
• Impact: leaks downstream divergences; spawned thread now has a dangling handle reference.
• Fix scope: ~20 LOC in xam_task_schedule / ex_create_thread — add explicit state.handle_refcount[handle] += 1 after spawn for the XThread's own ref. Verify against canary's RetainHandle() semantics.

D-2 (HIGH) — chain tid=4 / canary, tid=11 / ours: ours stops at idx=8

• Chain: canary tid=4 ↔ ours tid=11.
• Event:
  • ours: kernel.return KeWaitForMultipleObjects status=0 at idx=8, then stream ends (9 total events).
  • canary: handle.create sid=bcaf14d76932b128 (Event) at idx=8, then handle.create sid=0760e947bacff199 at idx=9, then continues for 151,690 events.
• Hypothesis (class E asymmetry): Canary's KeWaitForMultipleObjects_entry iterates the object pointer array and calls XObject::GetNativeObject<XObject>(kernel_state, object_ptr, -1, true) for each — when the object has not yet been wrapped in an XObject*, this CREATES a new XObject (and thus a new handle). Ours's do_wait_multiple uses resolve_pseudo_handle which does NOT create a new XObject — it looks up the existing handle. The "handle for the native dispatcher object" is an engine-architectural difference: canary lazily wraps, ours pre-registers.
• Impact: every KeWait that takes object pointers (not handles) creates N extra handle.create events on the canary side. Ours emits none.
• Fix scope: this is class E (intentional asymmetry). Recommended action: add Ke{Wait,Set,Reset,...}*Object* exports that take object pointers to a diff-tool suppress-handle-create-side-effect list, OR have ours emit a synthetic handle.create when resolve_pseudo_handle first encounters a new pointer. Latter aligns canary's view better. ~30-50 LOC.

D-3 (HIGH) — same class on chains 7→2 (idx=30), 12→7 (idx=2), 14→9 (idx=2)

Same root cause as D-2 — KeWaitForSingleObject with raw object pointer. Canary's xeKeWaitForSingleObject calls GetNativeObject which creates a handle for the dispatcher; ours's resolve_pseudo_handle does not.

Group all 4 chains under one fix in D-2.

D-4 (MEDIUM) — wait.begin SID 0000000000000000 on tid=10 of ours

• Chain: canary tid=15 ↔ ours tid=10 (the only thread where prefix didn't regress — but ours stalls at idx=16).
• Event at idx=2: both engines emit wait.begin but ours's handles_semantic_ids = ["0000000000000000"] while canary's is real.
• Hypothesis: SID = 0 means lookup_handle_semantic_id returned 0 (handle not registered). The handle being waited on must have been created before the event_log SID registry was active (during boot / init), OR it's a pseudo-handle from resolve_pseudo_handle. Pseudo-handles aren't real handles in our model.
• Fix scope: when lookup_handle_semantic_id(h) == 0, lazy-emit a synthetic handle.create for h (with a default object_type per state.objects[h]'s schema kind). Aligns with D-2 fix. ~10 LOC.

D-5 (LOW) — chains 7→2, 12→7, 14→9: ours streams truncated

• Ours's tid=2/7/9/10 streams are 32/4/76/16 events long; canary's are 32/27,834/4,733,192/3,610,535. Ours's worker threads stall early.
• Hypothesis: Downstream of D-2 / D-1 — once the main thread or peer workers diverge, downstream threads block on signals that never come.
• Fix scope: deferred until D-1/D-2 land; likely no separate fix needed.

Acceptance gate status

• Gate 1 (default-off digest): PASS — 3× reproducible at e1dfcb1559f987b35012a7f2dc6d93f5 (unchanged from C+13 baseline).
• Gate 2 (cvar-on emit): PASS — both engines produce 14M+ / 121K events respectively; JSONL parses cleanly; all new kinds present.
• Gate 3 (diff tool): PASS — diff tool consumes new kinds, produces 6-chain divergence report. Cross-engine SID skip-comparison documented in SKIP_PAYLOAD_FIELDS_BY_KIND.
• Gate 4 (cold-vs-cold): PASS (with regression as designed) — main chain prefix 104,574 → 102,168 (-2,406 events). Divergence catalog produced.
• Gate 5 (build clean): PASS — canary + ours both build.
• Gate 6 (tests): PASS — 181 → 181 passing (no new tests added; existing unchanged).

Reading-error class avoided

Class #29 — per-host-thread tid_event_idx counter for shared synthetic tids: canary's pre-session thread_local uint64_t t_tid_event_idx was correct for guest-tid events (1 tid : 1 host_thread) but broken for boot-time emissions with tid=0 because boot init runs on multiple host threads. Symptom: the diff tool rejected the canary log with "events out of order at index 8". Fixed via tid-keyed global map (matches ours's design).