Board hygiene for merged #938 — W5 v2 results + the 3 same-day codex fixes - #939
Conversation
…es, arc entry + shipped row + STATUS_BOARD D-W5 brought current STATUS_BOARD's D-W5 row previously stopped at the pre-fix v2 numbers (B3 family-A-only, no B4 caveat) -- brought current with the family-B confirmation and the B4 incomplete/descriptive-only status, matching the plan and arc entry. LATEST_STATE gets the #938 shipped row. PR_ARC_INVENTORY gets a short MERGED entry recording the 3 same-day fixes (the RUN results themselves already had their own entry, written before merge -- this one covers only what changed after that, per the append-only convention of not re-editing an entry already pushed to the branch). Co-Authored-By: Claude <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CcpLeEC3XK8Eye53GKBVvi
Bugbot couldn't run - usage limit reachedBugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit. A user or team admin can review and increase usage limits in the Cursor dashboard. (requestId: serverGenReqId_a83d45b2-4292-4df6-bae3-f630a1514afb) |
|
Warning Review limit reached
Next review available in: 3 minutes You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (3)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 9acb3cbf3e
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| | PR | Merged | Title | What it added | | ||
| |---|---|---|---| | ||
| | *gap note* | — | **#781–#925 are NOT in this table** — carried by the dated sections above + `PR_ARC_INVENTORY.md`. Recorded 2026-08-12 (codex P2 on #930) rather than silently reconstructed; the table had stalled at #780. | — | | ||
| | **#938** | 2026-08-12 | W5 v2 RUN lands — B2 REVERSES to genuine FAIL, B3's VOID CONFIRMED at full headline scale, both link families now verified | B2: real diffusion resolved (raw rel-L2 vs unsmoothed input = 0.190), operator's own anisotropy = **1.5251 vs the 1.25 bar** (baseline through the clean 3.35σ mask = 1.0046 — the operator alone contributes ~0.52). `domino.rs` gather-design claim REFUTED at this test point. B3: 99.68 % (family A) / 99.56 % (family B) of the qualifying population's control links land on a pure Fibonacci offset, at the real N=4 782 017 (not a 62k sub-sample) — dominated by the two discovered strides 2584=F(18) / 4181=F(19) respectively. Same-PR fixes for 3 more codex findings: family-B histogram was previously uncomputed (now measured + JSON patched); "four orders of magnitude" corrected to ~1.9 (76.9×); B4 downgraded from verdict to explicit descriptive reading (n=19 was dropped without pre-authorization — B4 stays open). | |
There was a problem hiding this comment.
The committed artifact records headline.N = 7,651,227 and n_qualifying = 4,782,017, but this new row calls the latter the “real N”; the same mislabel is repeated in STATUS_BOARD.md. This corrupts the reported experiment scale and conflicts with the new inventory entry, so describe 4,782,017 as the qualifying population or use the actual headline N.
Useful? React with 👍 / 👎.
… subpopulation) conflated as "the real N"
Real error: LATEST_STATE and STATUS_BOARD both called 4,782,017 "the real
N=4.78M" when the actual headline lattice is N=7,651,227 -- 4,782,017 is
n_qualifying, the qualifying-band SUBPOPULATION the B3 histogram fractions
are computed over. PR_ARC_INVENTORY's own entry already had this right
("n_qualifying=4 782 017"); only the two summary rows conflated the two
numbers. Fixed both to name N and n_qualifying separately rather than
calling the subset "the real N". Swept EPIPHANIES.md and
weather-w-probes-v1.md for the same pattern -- no other site had it.
Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CcpLeEC3XK8Eye53GKBVvi
…lifier on the 25%/9% contribution figures The source RUN entry and the committed JSON's fitted_contribution_Pa_per_km keys report MEANS over the 19 storms (mean |c_geo*P_geo| / mean |c_bow*P_bow| vs mean |D|); the #940 summary rows dropped the qualifier. PR_ARC's merged entry gets an appended dated correction line (append-only rule -- the entry merged via #941 before the finding landed, not edited in place); LATEST_STATE's living shipped-table row is fixed in place (precedent: the N-vs-n_qualifying fix on #939). Fourth instance of the same summarization defect class this week: a qualifier or operand pairing true in the source, lost in the summary. The figure itself was never wrong -- its aggregation scope went unstated. Co-Authored-By: Claude <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CcpLeEC3XK8Eye53GKBVvi
Post-merge hygiene for #938
Pure board hygiene — this PR is entirely board files, no code, no plan changes. Per the termination clause, a hygiene-only PR generates no further arc-entry obligation once merged.
PR_ARC_INVENTORY.md— short MERGED entry for W5 v2 RUN — B2 genuinely FAILS once real diffusion is resolved, B3's VOID confirmed at the full headline scale #938, covering only what changed after the RUN-results entry (written pre-merge) was already committed: the three same-day codex fixes (family-B histogram, the ~1.9-vs-4-orders arithmetic correction, B4's downgrade to descriptive-only). The earlier entry's "awaiting a PR" line is left as-is per the append-only convention (already pushed to the branch before W5 v2 RUN — B2 genuinely FAILS once real diffusion is resolved, B3's VOID confirmed at the full headline scale #938 merged) — this new entry supersedes its framing rather than editing it.LATEST_STATE.md— shipped-table row for W5 v2 RUN — B2 genuinely FAILS once real diffusion is resolved, B3's VOID confirmed at the full headline scale #938: B2 reverses to genuine FAIL (real diffusion resolved, operator's own anisotropy 1.5251 vs the 1.25 bar), B3's VOID confirmed on both link families at the real headline N.STATUS_BOARD.md—D-W5row was stale (still reflected the pre-fix v2 numbers: family-A-only B3 evidence, no B4 caveat). Brought current: family-B confirmation added, B4 explicitly marked incomplete/descriptive-only (n=19 was dropped without pre-authorization against its own pre-registered bar) rather than reading as a satisfied verdict.Doc/board only — zero Rust, zero product code, no probe run.
🤖 Generated with Claude Code
https://claude.ai/code/session_01CcpLeEC3XK8Eye53GKBVvi
Generated by Claude Code