Commit Graph

2 Commits

Author SHA1 Message Date
884a2c3944 fix(canary): point the launchers at a binary that exists and is instrumented
Some checks failed
CI / Native — linux (pull_request) Failing after 1h3m36s
CI / WASM — Web (pull_request) Successful in 24m29s
CI / Formatting (pull_request) Successful in 27s
`/sylph-canary` was dead at both ends, measured rather than assumed:

  * `run-canary-safe.sh` runs the Wine build and defaults to
    `xenia_canary_i2d.exe`, which DOES NOT EXIST. The `xenia_canary.exe` that
    does (2026-06-19) has ZERO strings for `audit_61_branch_probe_pcs` and zero
    for `RE-INPUT`/`RE-DRAW` -- it predates all our instrumentation, and
    refreshing it needs the clang-cl + xwin toolchain on `cross-build-wine`.
  * both native launchers defaulted to
    `xenia-canary-native/build/bin/Linux/Release/xenia_canary`. That directory
    does not exist on this workspace -- the checkout is `xenia-canary/` -- and
    Release is not even a target in that build tree (`ninja -n` lists 0 steps),
    so its binary is frozen at 2026-08-28, before the probe.

Native launchers now default to
`xenia-canary/build/bin/Linux/Checked/xenia_canary`: the config this tree can
actually build, rebuilt today with the audit_61 probe (Canary PR #2), verified
by `strings` -- audit_61 8 hits, RE-INPUT/RE-DRAW 4. `Checked` is optimised WITH
assertions, which is what a behavioural reference should be: a bad state stops
loudly rather than being sampled.

The Wine launcher now ABORTS with the reason and points at the native one,
instead of failing somewhere downstream on a missing file.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-20 21:00:13 +02:00
sim
e45a56ad83 chore: hand the workspace over — the gated launchers, and the state of play
Resuming happens on the other machine, so anything that lived only in this
workspace either comes into the repo or gets named as something to carry.

**The launchers come in.** `run-canary-safe.sh` (Wine) and
`run-canary-native-safe.sh` (native) are the ONLY sanctioned way to start Canary
from the editor — they force software Vulkan and refuse to launch while a
hardware Vulkan device is visible, because Canary on the AMD GPU takes VS Code
with it. They sat in the workspace root, outside git, hardcoding one machine's
absolute paths, which is exactly why they could not be checked in. They now
derive the workspace from their own location and honour `$SYLPHEED_ISO` and
`$CANARY_BIN`, so the layout is a default rather than a requirement. Same for
`run-canary-native.sh` (interactive, hardware Vulkan — not from the IDE),
`diagnose-freeze.sh`, `live-guest-state.sh`, `heaptrack-wrap.sh` and the
`asound-null.conf` the native launcher needs beside it.

Both safe launchers were run from `tools/` before this commit: the native one
reached content in 20 s (`VERDICT: HEALTHY`, title + 25,398 XMA lines, no
faults), the Wine one ran 25 s and logged 4 `ADV.wmv` hits.

**`docs/agents/HANDOFF-2026-09-18.md`** records what changed since 2026-09-16,
what is on the server, what cannot travel through git, and the traps this machine
paid for — chiefly that the guest-PC branch probe exists only on the fork's
snapshot branch, so a rebuild from `sylpheed-re` silently loses it.

**`HANDOFF-2026-09-06.md`** gets a correction note rather than an edit: a plain
clone works again now that the 545 MB branch is gone, and its baselines are two
baselines old.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-18 07:17:36 +02:00