From cca48ad927bf18c91458207aaf94babb8eca7b9d Mon Sep 17 00:00:00 2001 From: bitkyc08-arch Date: Tue, 18 Aug 2026 12:16:01 +0900 Subject: [PATCH] docs(devlog): third root cause, and this one is not the infrastructure's fault My second explanation was also wrong. Dev is not scanned on push - its last analysis is from 8/15, default setup runs weekly, and 0be660a2e is not an ancestor of that commit, so the code was never in a dev scan. Dev's 84 alerts are stale rather than current, which is the opposite of what I said they showed. The real answer: github-advanced-security posted the finding as an inline review comment on #1959 at 02:38:08Z, and #1963 promoted at 02:55:04Z. It sat in the review thread of a promotion PR for seventeen minutes - while I was editing that same PR's description. Not a coverage gap. I did not read the review comments on a PR I was actively rewriting. Three explanations for one mistake. The first two blamed infrastructure; the third is true and the least comfortable, which is roughly how that tends to go. --- .../090_wave6_closeout.md | 24 +++++++++++++------ 1 file changed, 17 insertions(+), 7 deletions(-) diff --git a/devlog/_plan/260817_wave5_execution/090_wave6_closeout.md b/devlog/_plan/260817_wave5_execution/090_wave6_closeout.md index 13eee940be..9f3f27b85f 100644 --- a/devlog/_plan/260817_wave5_execution/090_wave6_closeout.md +++ b/devlog/_plan/260817_wave5_execution/090_wave6_closeout.md @@ -243,12 +243,22 @@ targeting the default branch. Every campaign PR targets `dev`, so none of them c CodeQL feedback at all — verified: `refs/pull/1959/head` and `refs/pull/1963/head` have analyses because they target `main`, while the `preview`-targeting pair have zero. -The actual root cause is duller and more useful: **`dev` is scanned on push, and nobody read -the result.** It carries 84 open alerts against `main`'s 71. The finding was observable on the -integration branch from the moment #1897 merged until promotion, and no step in this campaign -ever looked. CodeQL is structurally absent from the `dev` PR flow *and* the post-merge alert -list is not part of anyone's gate — those are two different holes, and I named neither the -first time. +**Second attempt, also wrong.** I then wrote that `dev` is scanned on push and nobody read the +result. Both halves are false: `dev`'s most recent analysis is `02abe0afa` from 2026-08-15, +default setup runs on a *weekly* schedule, and `0be660a2e` is not an ancestor of that commit — +so the code was never in a `dev` scan at all. Its 84 alerts are stale, not current, which is the +opposite of what I claimed they showed. Alert #87's only instances are `refs/heads/main` and +`refs/pull/1959/head`. "Nobody read it" described a page that never displayed it. + +**The actual missed signal, third time.** `github-advanced-security[bot]` posted the finding as +an inline review comment on **#1959** at `src/providers/antigravity-models.ts:273` at +**02:38:08Z**. #1963 promoted at **02:55:04Z**. It was sitting on a promotion PR, in the review +thread, for **17 minutes** before the code reached `main` — and I was actively editing that PR's +description during the window. Not a coverage gap. I did not look at the review comments on a +PR I was in the middle of rewriting. + +Three explanations for one mistake, the first two of which blamed infrastructure. The third is +the one that is true and the least comfortable. Severity in context: the input is a configured `baseUrl`, so exploitation needs a hostile or careless config rather than attacker-controlled traffic. Worth fixing, not urgent. Separately, @@ -267,7 +277,7 @@ edge cases (empty string, all-slashes, no trailing slash, interior slashes). **The root cause is a process one and belongs in the record.** #1897 merged on local focused tests plus `tsc`. That substitutes for CI on the axis it covers — behavior — and silently skips -the axis it does not: static analysis. Waiting for full CI would have surfaced this before it +the axis it does not: static analysis. ~~Waiting for full CI would have surfaced this before it~~ reached `main`. The instruction for this run was to stop waiting on per-PR CI and gate once at the end, which is a reasonable trade for speed; the honest accounting is that it traded away exactly this class of finding, and the end-gate I ran (`bun test`, `typecheck`, `privacy:scan`)