From 3f61ca01009223790bd74506f8d1abf9f702c232 Mon Sep 17 00:00:00 2001 From: bitkyc08-arch Date: Tue, 18 Aug 2026 12:09:11 +0900 Subject: [PATCH 1/3] docs(devlog): my root cause for the missed alert was also wrong I said the alert slipped through because I substituted local tests for missing CI and neither runs CodeQL. True and irrelevant: CodeQL would not have run on #1897 even with full CI, because analyses exist only for main, dev, and PRs targeting the default branch. Every campaign PR targets dev, so none of them could ever get CodeQL feedback - confirmed by the promotion PRs, where the main-targeting pair have analyses and the preview-targeting pair have none. The real cause is duller. Dev is scanned on push and carries 84 open alerts against main's 71. The finding was sitting on the integration branch from the moment #1897 merged until promotion, and no step in this campaign looked at it. Those are two separate holes - CodeQL absent from the dev PR flow, and the post-merge alert list not being anyone's gate - and my first explanation named neither. --- .../090_wave6_closeout.md | 19 ++++++++++++++----- 1 file changed, 14 insertions(+), 5 deletions(-) diff --git a/devlog/_plan/260817_wave5_execution/090_wave6_closeout.md b/devlog/_plan/260817_wave5_execution/090_wave6_closeout.md index 6284a3ffed..8047ecc90f 100644 --- a/devlog/_plan/260817_wave5_execution/090_wave6_closeout.md +++ b/devlog/_plan/260817_wave5_execution/090_wave6_closeout.md @@ -234,11 +234,20 @@ false, and it is the worst error in this campaign's record: an approver reading promoted past a high-severity finding that this campaign created, on my assurance that it had not. Corrected in both PR bodies, reported on #1897, and recorded here. -**Why my verification missed it.** Before merging #1897 I ran the focused suites and `tsc` -locally, because no CI run existed at its head. Neither runs CodeQL. The alert surfaced on the -promotion PRs, where CodeQL diffs the whole branch rather than a feature slice — so the -substitution I made for missing CI covered the tests and silently did not cover static analysis. -That is a real gap in the local-verification substitute, not a one-off. +**Why my verification missed it — and my first explanation was wrong too.** I wrote that the +cause was substituting local tests for missing CI, since neither runs CodeQL. That is true and +irrelevant: **CodeQL would not have run on #1897 even with full CI at its head.** The analysis +history contains `refs/heads/main`, `refs/heads/dev`, and `refs/pull/*/head` only for PRs +targeting the default branch. Every campaign PR targets `dev`, so none of them could receive +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. 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, From 9e3b67f322873aa96a606d4be40d6078bb329a8c Mon Sep 17 00:00:00 2001 From: bitkyc08-arch Date: Tue, 18 Aug 2026 12:09:51 +0900 Subject: [PATCH 2/3] docs(devlog): the promotion happened, and my disclosure went to the wrong PRs Dev reached preview and main through #1962 and #1963, not through the #1958 and #1959 I opened and left for a maintainer - those flipped to merged seconds later once their heads became reachable. So the disclosure I spent three audit rounds getting right sat on the two PRs that moved no code, and the two that actually promoted carried none of it. Fixed by commenting it onto #1962 and #1963 after the fact, which is later than it should have been. Worth naming the failure mode rather than just the fix: I attached the warning to the artifact I controlled rather than to the artifact that would carry the change. js/polynomial-redos is on main now. What I did not do and stand by: I never approved a promotion PR. --- .../090_wave6_closeout.md | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/devlog/_plan/260817_wave5_execution/090_wave6_closeout.md b/devlog/_plan/260817_wave5_execution/090_wave6_closeout.md index 8047ecc90f..5f413af730 100644 --- a/devlog/_plan/260817_wave5_execution/090_wave6_closeout.md +++ b/devlog/_plan/260817_wave5_execution/090_wave6_closeout.md @@ -275,3 +275,22 @@ does not include CodeQL. For context rather than excuse: the repository carries 71 open alerts, 65 of them high or critical. This is one of many — but it is one this campaign put there, so it gets fixed here rather than added to the pile. +## Promotion: completed, and not by the PRs I opened + +`dev` reached `preview` and `main`. Not through #1958/#1959, which I opened and deliberately +left for a maintainer — those flipped to merged seconds *after* **#1962** and **#1963** did the +actual promotion at 02:55:01 and 02:55:04, because their heads became reachable once the real +promotion landed. + +Which means the disclosure I spent three rounds getting right went onto the two PRs that did not +move any code, and the two that did carried none of it. Corrected by commenting the full +disclosure onto #1962 and #1963 after the fact — later than it should have been, and worth +recording as the failure mode it is: **I attached a warning to the artifact I controlled rather +than to the artifact that would carry the change.** + +`js/polynomial-redos` is now on `main` — `git merge-base --is-ancestor 0be660a2e origin/main` +returns true. The alert is disclosed on #1897, on both promotion PR pairs, and here. + +What I did not do, and stand by: I never approved a promotion PR. `MAINTAINERS.md` forbids +authors approving their own, and the rulesets require a code-owner review. That the promotion +happened by another route is the maintainer's call to make, not mine to route around. From c9ea6596a7de967ade483108e28a2e00bed1581f Mon Sep 17 00:00:00 2001 From: bitkyc08-arch Date: Tue, 18 Aug 2026 12:15:27 +0900 Subject: [PATCH 3/3] docs(devlog): fix the #1843 release version at its source The closure-rules section said v2.24.2 while the results table said v2.24.0, and the errata further down already flagged the contradiction. Correcting the line itself rather than leaving a reader to find the footnote: git tag --contains ac8c0d2df names v2.24.0 as the earliest containing tag. --- devlog/_plan/260817_wave5_execution/090_wave6_closeout.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/devlog/_plan/260817_wave5_execution/090_wave6_closeout.md b/devlog/_plan/260817_wave5_execution/090_wave6_closeout.md index 5f413af730..13eee940be 100644 --- a/devlog/_plan/260817_wave5_execution/090_wave6_closeout.md +++ b/devlog/_plan/260817_wave5_execution/090_wave6_closeout.md @@ -17,7 +17,8 @@ misleading in this checkout. and still not the required gate. - **#1795** does not close without a live SenseNova/Kimi canary showing zero undeclared tool calls. -- **#1843** is closable now: fixed by #1860, released in v2.24.2. +- **#1843** is closable now: fixed by #1860, released in **v2.24.0** (`git tag --contains ac8c0d2df` + names v2.24.0 as the earliest containing tag; an earlier draft of this line said v2.24.2). - State is judged by merge commit and branch ancestry first, GitHub API second, cached HTML badges last. #1881 showed an Open badge while merged.