# Phase 0–2 — XAM hallucination audit (Phase C+6½ XAM)

## Method

For every xam.xex ord ours registers in `crates/xenia-kernel/src/xam.rs::register_exports()`,
cross-reference against canary's `xam_table.inc` (1736 entries; authoritative
Xbox 360 ord→name mapping). Three classes of mismatch are possible:

1. **MATCH** — ours's name == canary's name. Most exports.
2. **HALLUCINATION** — ours's name ≠ canary's name at the same ord.
   The hallucinated name may be a real NT/Xam function that exists at a
   *different* ord on Xbox 360, making it look plausible.
3. **GHOST ORD** — ours registers an ord canary's table doesn't have.

For each HALLUCINATION, additional severity classification (per C+6½ taxonomy):

* **CRITICAL** — ours's stub body performs different semantics than
  canary's named function. Game gets wrong data on every call.
* **HIGH** — ours's stub body is harmless (e.g. `stub_success`) but
  registered under wrong name (Phase A name divergence; no behavior
  risk at runtime).
* **LOW** — ours's stub body has correct semantics but name is wrong
  (rename-only fix).

## Headline

| count | category |
|------:|---|
| 52 | total xam ords ours registers |
| **52** | **MATCH** (name agrees with canary table) |
| **0** | **HALLUCINATION** |
| **0** | **GHOST ORD** (no ord registered in ours that canary's table lacks) |

**Outcome: clean. The XAM table has zero name mismatches.**

This is in contrast to the xboxkrnl table audited in C+6½, which had 2
CRITICAL hallucinations (ord 0x82 `KeQueryIdealProcessor` →
`KeQueryInterruptTime`; ord 0x98 `KeSetIdealProcessor` →
`KeSetBackgroundProcessors`). Whoever populated ours's XAM
registrations evidently used canary's `xam_table.inc` as the
authoritative source from the start.

## XamTaskCloseHandle (Phase C+7 target) — explicit verification

Phase C+7's pending main-chain first divergence at idx 102158 is
`XamTaskCloseHandle return_value=1 vs 0`. Audit confirms:

* Ord **0x000001B1** in ours's `xam.rs:33` ↔ canary's
  `xam_table.inc:230` are BOTH `XamTaskCloseHandle`.
* **NOT a name hallucination.** Both engines call the same function
  by name.
* The divergence is a **body-semantic issue**:
  * canary's `XamTaskCloseHandle_entry` (`xam_task.cc:83-93`) calls
    `NtClose(obj_handle)`, returns `true` (= 1) on success.
  * ours registers `stub_success` (`xam.rs:33`) which returns 0.
* The fix is therefore in xam_task body semantics, NOT in this
  hallucination-audit scope. **Deferred to a dedicated C+7 session**
  per directive "don't widen scope to fix non-hallucinated XAM
  functions".

## Class-E sister-sweep candidate (Phase 1 — applied)

While auditing 52 ours-registered XAM ords, cross-referenced which
have NO `DECLARE_XAM_EXPORT` shim in canary (analogous to C+6½'s
class-E sister sweep on xboxkrnl).

Canary's XAM `DECLARE_XAM_EXPORT*` count: **331 shims** declared
across all `src/xenia/kernel/xam/*.cc` files.

Of ours's 52 ords, exactly **one** has a matching name but NO shim
in canary, and is currently registered via the noisy
`register_export` path:

| ord | canary name | ours kind (pre) | canary has shim? |
|---|---|---|---|
| 0x02D5 | XamShowGamerCardUIForXUID | register_export → stub_success | NO (table-only) |

Wait, isn't `XamShowDirtyDiscErrorUI` also class-E? It IS class-E in
canary (table-only), but the audit reviewed and it's already
correctly named and the directive constrains us to bug-class-aware
scope: the 1 candidate flagged is the only one ours is currently
registering through the loud (event-emitting) path under a class-E
name that we have evidence (from C+6 / C+6½) would alter Phase A
matched-prefix if hit.

(Note: ALL other ours `register_export(..., stub_*)` entries with no
canary `DECLARE_XAM_EXPORT` shim were spot-checked. None are
currently live in the 50M Phase A window — confirmed by grep of the
C+6½ ours.jsonl. So even if any others are technically class-E,
they're inert at the current matched-prefix horizon. Per directive
"don't widen scope", only the 1 flagged candidate is touched.)

**Phase 1 action**: rewire ord 0x02D5 to
`register_unimplemented_export`. Mirrors C+6½'s
`StfsCreateDevice`/`DbgPrint`/etc rewires.

## No CRITICAL/HIGH/LOW hallucinations to fix

Per the audit headline. The session's primary deliverable
(hallucination fixes) is **empty by construction** — the XAM table
in ours was already clean.

## Files

* `canary-xam-table.csv` — 1736 raw entries from
  `xam_table.inc`.
* `canary-xam-table-classified.csv` — same, with
  `has_shim` column (yes/no per `DECLARE_XAM_EXPORT*` grep).
* `canary-xam-declared-shims.txt` — 331 names.
* `ours-vs-canary.csv` — 52-row cross-check with verdict per ord.