fix: editor-sanitizer CI job actually used clang, not gcc as documented

An external review of tonight's work caught a real discrepancy: plan.md's
SYS-W11-09 writeup claims "the new sanitizer job [uses gcc/g++] too,
matching" the plain editor job, but `git log -S"editor-sanitizer"`
shows the job used clang/clang++ since its very first commit
(6e356c3) -- that claim was never actually applied to ci.yml. The
job has never had a fully green CI run: first blocked by unrelated
environment gaps (fixed separately tonight), now by SYS-W8-08's
sharp-runtime API mismatch, unrelated to compiler choice.

Fixed for real, not just in prose: switched the editor-sanitizer job's
CC/CXX to gcc-14/g++-14 (matching the plain editor job and the local
build-asan/ verification, which was already GCC-based, confirmed via
its CMakeCache.txt) and swapped clang for g++-14 in its apt-get install
list.

Downgraded SYS-W11-09 from [DONE] to [IN_PROGRESS] in plan.md: the code
fixes (heap-use-after-free, 4 leak fixtures, meshcraft_apply_sanitize()
wiring) are real and independently verified locally, but the CI job
itself was never actually verified green and had this real
misconfiguration. Also corrected NEXT.md's "Current priorities"
section, which had gone stale mid-session (still claiming "no Wine in
this sandbox" and "awaiting Windows run" hours after both were
resolved and documented further down the same file) -- exactly the
kind of internal contradiction the same review flagged.

Author: robertvokac

.github/workflows/ci.yml

@@ -367,8 +367,17 @@ jobs:
     name: Editor (EASYGL) ASan+UBSan
     runs-on: ubuntu-24.04
     env:
-      CC: clang
-      CXX: clang++
+      # Corrected 2026-07-27: this job used clang/clang++ since its very
+      # first commit, contradicting this file's own SYS-W11-09 writeup in
+      # plan.md ("the new sanitizer job [uses gcc/g++] too, matching" the
+      # plain `editor` job below) -- that claim described intent that was
+      # never actually applied here. GCC's ASan+UBSan support is equally
+      # complete; switching removes the untested risk of hitting the
+      # documented Clang/CNA::Internal::JsonValue incompatibility, and keeps
+      # this job on the same toolchain as the plain `editor` job for a
+      # sanitizer finding that can't be blamed on a compiler difference.
+      CC: gcc-14
+      CXX: g++-14
       ASAN_OPTIONS: detect_leaks=1:halt_on_error=1
       UBSAN_OPTIONS: halt_on_error=1:print_stacktrace=1
     steps:
@@ -414,7 +423,7 @@ jobs:
         run: |
           sudo apt-get update
           sudo apt-get install -y --no-install-recommends \
-            clang cmake ninja-build python3 pkg-config \
+            g++-14 cmake ninja-build python3 pkg-config \
             libgl1-mesa-dev libegl1-mesa-dev libglvnd-dev \
             libx11-dev libxext-dev libxrandr-dev libxcursor-dev \
             libxi-dev libxfixes-dev libxss-dev libxtst-dev \

NEXT.md

@@ -30,24 +30,36 @@ distribution rather than missing editor breadth.
 
 ## Current priorities
 
-1. Obtain native standalone Windows qualification (`SYS-W11-06`). The
-   release-readiness changes are published on `develop`; await the next
-   remote `windows-2022` CTest/artifact evidence run — the first real run
-   found 6 concrete regressions (see "Session log" below), all 6 now fixed
-   and pushed, but none re-verified on an actual Windows runner yet (no
-   Wine in this sandbox).
-2. The freshly-added `[PROPOSED]` backlog (`SYS-W9-06/07`, `SYS-W1-08`,
-   `SYS-W2-06`, `SYS-W11-08/09/10`, `SYS-W13-03`, `SYS-W3-05`) is
-   **all 9 DONE**. `SYS-W11-09` found a real heap-use-after-free bug in
-   `EventPreviewRunner::execute()`'s RunScript step (`ff62004`) — a stale
-   `working.scripts` iterator read again after `LuaScriptRunner::run()`
-   already replaced `working` via move-assignment. Fixed. See `plan.md` for
-   full evidence on everything done.
-3. All 6 of the deferred CI-red regressions from that first Windows run are
-   now fixed and pushed (see "Session log" below for each one's root cause
-   and evidence) — still awaiting real Windows re-verification for the 3
-   Windows-specific fixes (`mc3_roundtrip`, `mcb_load_policy`, `mc3togltf`
-   DLL staging).
+_(This section is a summary snapshot — it was left stale for several hours
+during the 2026-07-27 session while only the "Session log" further down got
+updated. Corrected once, after an external review caught the contradiction;
+if you're reading this much later, re-check `plan.md`'s own status markers
+before trusting anything below.)_
+
+1. **`SYS-W11-06` (standalone Windows qualification) is `[DONE]`**, verified
+   for real against the actual published `windows-2022` CI artifact
+   (downloaded via `gh run download`, run through Wine in this sandbox —
+   Wine is NOT blocked here for console binaries, only the full GUI editor
+   hits `SIGSYS`). See `plan.md`'s own entry for the full evidence trail,
+   including a genuine first-attempt failure (`STATUS_DLL_NOT_FOUND`) that
+   led to statically linking the whole standalone-Windows build.
+2. The `[PROPOSED]` backlog from the 2026-07-26 review (`SYS-W9-06/07`,
+   `SYS-W1-08`, `SYS-W2-06`, `SYS-W11-08/10`, `SYS-W13-03`, `SYS-W3-05`) is
+   done. **`SYS-W11-09` is `[IN_PROGRESS]`, not done** — its code fixes (a
+   real heap-use-after-free in `EventPreviewRunner::execute()`, 4 leak
+   fixtures, `meshcraft_apply_sanitize()` wiring) are real and locally
+   verified, but the new `editor-sanitizer` CI job itself has never had a
+   fully green run: it used `clang`/`clang++` despite `plan.md` claiming
+   otherwise (corrected 2026-07-27, now `gcc-14`/`g++-14`), and currently
+   fails on `SYS-W8-08`'s unrelated `sharp-runtime` API mismatch.
+3. All 6 originally-deferred CI-red regressions, plus 10 more layers
+   cascading from fixing them, are fixed and confirmed on real CI (see
+   "Session log" below) — `Clang ASan+UBSan and bounded fuzz` and
+   `Standalone Windows qualification` are fully green. The 3 Editor CI jobs
+   now get all the way through CMake configure and fail only at build, on
+   2 real `sharp-runtime` bugs tracked as `SYS-W8-07`/`SYS-W8-08` —
+   deliberately not fixed (sibling repository, outside authorized scope;
+   user chose to report and defer).
 4. `SYS-W11-11` (the first-release version-number decision) is deliberately
    left `[BLOCKED]` per the user's explicit choice not to decide yet.
 

plan.md

@@ -375,7 +375,7 @@ report and defer rather than fix).
   linking the standalone Windows build. See `SYS-W11-06` for the full
   verification.
 
-- **SYS-W11-09** `[DONE]` `P1` — Added first-party editor sanitizer CI, and it
+- **SYS-W11-09** `[IN_PROGRESS]` `P1` — Added first-party editor sanitizer CI, and it
   immediately found a real bug, confirming the whole point of doing this.
   Root `CMakeLists.txt` already had `-DMESHCRAFT_SANITIZE=ON` wired up, but
   `meshcraft_apply_sanitize()` was only ever called on the main `MeshCraft`
@@ -444,13 +444,30 @@ report and defer rather than fix).
   these fixes regressed the normal configuration.
   New `editor-sanitizer` CI job (`.github/workflows/ci.yml`): checks out the
   same pinned CNA/sharp-runtime revisions as the plain `editor` job, builds
-  with `gcc`/`g++` + `MESHCRAFT_SANITIZE=ON` + EASYGL, runs `ctest -LE
-  render`, then the one render smoke test with leak detection scoped off.
+  with `MESHCRAFT_SANITIZE=ON` + EASYGL, runs `ctest -LE render`, then the
+  one render smoke test with leak detection scoped off.
   **Note for a future session:** `build-asan/` (a stable, reusable directory
   per the top-level build-rules convention) is ~5.7 GB on disk after this
   verification; left in place for incremental reuse rather than deleted,
   since another session may want to re-verify against it.
 
+  **Correction (2026-07-27, external review caught this):** the paragraph
+  above originally claimed the new CI job builds with `gcc`/`g++` "matching"
+  the plain `editor` job — false. The job used `clang`/`clang++` from its
+  very first commit; only the *local* verification (`build-asan/`, the
+  181/181 result above) actually used GCC. This is now fixed for real
+  (`CC: gcc-14`/`CXX: g++-14` in `ci.yml`, not just corrected prose), but
+  **downgrading this task's status to `[IN_PROGRESS]`**: the `editor-
+  sanitizer` CI job itself has never had a fully green run on real CI —
+  every run through 2026-07-27 failed, first on unrelated environment gaps
+  (fixed separately, see the CI-red session log in `NEXT.md`), now on
+  `SYS-W8-08`'s `sharp-runtime` API mismatch (unrelated to compiler choice,
+  will likely still block after the GCC switch). The code fixes described
+  above (heap-use-after-free, 4 leak fixtures, `package_consumer_smoke`
+  guard, `meshcraft_apply_sanitize()` wiring) are real and independently
+  verified locally; only the CI-job-itself claim was wrong. Re-promote to
+  `[DONE]` once a real `editor-sanitizer` run is green.
+
 - **SYS-W11-10** `[DONE]` `P2` — Wired one authoritative version source: a
   new root-level `VERSION` file (currently `0.1.0`, the existing value —
   deliberately not changed; deciding the actual first-release version number