Potential issues that may need addressing.

[ijbranch]

See attached doc created by Claude Code.

StaticCodeAnalyser-upstream-report-2026-08-23.md

[nrodear]

Thank you — and thank you for using SCA in the first place. A report this
carefully verified is rare, and the reproduction commands saved me a lot of
time. All three checked out.

Issue 1 — the 0x08 byte. Correct, and it was exactly as inert as you
describe. It is gone: the check was removed the day after the commit you
looked at, in c63331a. Same two causes you found (missing word boundary,
nested and anonymous routines) — but after fixing both, our tree still had
121 findings in code that provably compiles, so we concluded a regex cannot
decide this and took the check out rather than ship a silent one. Your tree
reaching 0 after the same fixes is genuinely interesting; the difference is
presumably shape, not luck.

Issue 2 — EDITOR_ACCENT over a subrange. Confirmed and fixed in
6984620. It now indexes the whole enum with one dead ecsDefault row, so
the guarantee the commit message claimed actually holds on both axes. There
is a test on the dead row too — leaving clNone sitting there is its own
trap.

Issue 3 — the three silent places. All three confirmed and fixed in
2eb2f29: one EDITOR_COLOR_SCHEME_INFO table over the whole enum,
ToStr a lookup, Parse a loop, the combo filled from the table.

One thing your patch would have hit: that combo has a fourth entry which
is not a colour scheme at all — it toggles [UI] OverlayTextOnly — and
SCHEME_IDX_TEXTONLY = 3 was sitting literally in two different methods of
the options dialog. Filling the list from EDITOR_COLOR_SCHEME_ORDER alone
would have swallowed it. The constant is now derived from the table and
exists once.

Not asking for anything back, but if you ever hit something else in your
fork, it is welcome here.