docs(board): post-merge hygiene for #920, and correct #917's falsified helix claims - #921
Merged
Merged
Conversation
…d claims #920 merged with neither board file updated (0 references to it in either). This is the retroactive-hygiene pattern CLAUDE.md names as an anti-pattern — unavoidable once the PR is merged, and leaving the board stale is the worse outcome (the rule exists because #223/#224/#225 merged with no entries). PR_ARC_INVENTORY: prepends the #920 entry (Added / Locked / Deferred+WITHDRAWN / Docs / Confidence), and applies the file's own rules 3-4 to #917 — an appended Correction line plus an updated Confidence line, never an edit to its immutable Locked text. #917 had locked two claims #920 falsifies: that "helix360" names something (it does not — the type is Signed360, 12 blobs all from that session, zero deletions) and that the HelixResidue lane reads as 2x24 hemispheres = wind in/out (it does not — one Signed360 is already a complete full-sphere direction; rim is the metric carrier, (polar, azimuth) the render carrier). LATEST_STATE: prepends the #920 entry with the same correction as a leading supersession note. Also records a measurement made after the merge, in answer to an operator question about polar vs equatorial error rates. Signed360 angular error by latitude, N=65536: equator 0.112 deg mean / 0.226 max; pole 3.332 / 4.998 — a ~30x spread, best at the rim. And a correction to the premise: there is NO resolution gain from the sign split at equal bit budget — 7-bit |y| + sign vs 8-bit over [-1,1] measures 0.99-1.02x in every band (step 1/127 vs 2/255 = 0.996x). The 256-sample codebook figures that imply a sqrt(2) gain (full sphere cap 7.17 deg vs hemisphere 5.07) spend an EXTRA bit; at equal budget 128-on-hemisphere is 7.17, identical. What the partition buys at the rim is sign EXACTNESS, not precision — and that is exactly where weather lives, since a wind bearing is near-horizontal (y = 0), the regime where a centred-at-128 round loses the hemisphere (#498). Per the termination clause, this hygiene-only commit generates no further board obligations of its own. Co-Authored-By: Claude Opus 5 <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_a07d6074-eb1a-47d8-bba0-2ee163c686f3) |
📝 WalkthroughWalkthroughThis change adds a bearing-encoding measurement test and documents its results. It corrects ChangesWind-bearing evaluation
Estimated code review effort: 3 (Moderate) | ~20 minutes Possibly related PRs
Suggested reviewers: Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
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 |
…ne does not fit Operator: "the reuse of the above for the wind was always part of the process (what you call invention)." Correct, and §12.12 drew the line wrong in both directions. INVENTION is asserting structure the code already answers (the 48-bit budget, the 2x24 reading, Pair48, a round-trip API the crate disclaims). REUSE is applying the shipped codec to a new domain — which is what a normalized substrate is FOR. Filing the missing bearing-encode under "invention" and declining to build it was an over-correction: a missing entry point for a designed reuse is a plumbing gap, not a design refusal. And the reuse earned its keep immediately. encode_signed derives all three direction-bearing fields from n alone (residue.rs:182-204). The knowledge doc prescribes nearest spherical-Fibonacci (n, sign) for encoding a direction. Measured at N=65536, that prescription does NOT fit weather: horizontal bearing nearest-n direct (polar, azimuth) 0 / 90 / 270 deg 1.933 / 2.706 / 1.897 0.000 each mean, 24 cases 0.972 deg 0.097 deg (10x) Mechanism: the golden spiral couples latitude and azimuth through ONE index. Reaching y ~ 0 needs n ~ N-1, and those few n have azimuth already fixed at n*phi — a bearing at the horizon cannot be chosen independently. The lattice is equal-area on the DISK, so latitude density is ~ sin(2*lat): sparsest exactly at the equator. Surface normals spread over the sphere and never hit this; wind clusters at the horizon and always does. Rule extracted: a doctrine written for one domain is not automatically right for the next one that reuses it. Deliberately does NOT mint a public from_bearing — the API shape is an operator call. This lands the measurement and the tradeoff. Note: this makes the branch's PR mixed rather than hygiene-only, so the termination clause no longer applies to it and the arc entry is warranted. Co-Authored-By: Claude Opus 5 <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_813cefeb-64a3-4a06-9a15-bae421242258) |
AdaWorldAPI
marked this pull request as ready for review
August 11, 2026 09:10
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: f4fc6912fb
ℹ️ 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".
Comment on lines
+66
to
+67
| let mut s = enc.encode_signed(0x1234, rim_n, if y>=0.0 {Sign::Pos} else {Sign::Neg}); | ||
| s.polar = polar; s.azimuth = azimuth; s |
There was a problem hiding this comment.
For horizontal bearings at the fixed place and N used here, the nearest indices all fall in the saturated tail: the sampled 0°, 90°, and 270° cases each produce ResidueEdge { start_idx: 21, end_idx: 255, ... }. Consequently distance_adaptive reports zero between these distinct bearings even though the overwritten (polar, azimuth) fields render differently. Because the codec's stated purpose is metric-safe comparison of orientations, checking only ang(decode(...)) does not establish that Path B fits weather; the metric behavior must be preserved and measured before recommending this encoding.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Actionable comments posted: 4
🧹 Nitpick comments (2)
crates/helix/tests/bearing_encode_paths.rs (2)
34-38: 🗄️ Data Integrity & Integration | 🔵 Trivial | ⚡ Quick winRound-trip
Signed360before decoding it.
decodereadspolarandazimuthdirectly. It bypasses the six-byte serialization path. A byte-order or field-layout regression can therefore leave this test green. UseSigned360::to_bytesandSigned360::from_bytesbefore applying the local direction math, as the existingcrates/helix/examples/hevc_headtohead.rs, Lines [398-454], does for representation checks.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@crates/helix/tests/bearing_encode_paths.rs` around lines 34 - 38, Update the decode helper around Signed360 to serialize the input with Signed360::to_bytes and reconstruct it with Signed360::from_bytes before reading polar and azimuth. Apply the existing direction-math calculations to the reconstructed value, preserving the current return behavior.
64-65: 🎯 Functional Correctness | 🔵 Trivial | ⚡ Quick winUse one azimuth quantization policy.
encode_signedtruncates the scaled azimuth incrates/helix/src/residue.rs, Lines [182-204]. Path B rounds before conversion. The reported comparison therefore changes both field independence and quantization policy. Use the canonical truncation for a like-for-like measurement, or record rounding as a separate variable.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@crates/helix/tests/bearing_encode_paths.rs` around lines 64 - 65, Update the azimuth calculation in the path-B test around target.0.atan2 so it uses the same truncation policy as encode_signed in residue.rs instead of rounding before conversion. Keep the comparison focused on field independence by matching the canonical quantization behavior.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.claude/board/PR_ARC_INVENTORY.md:
- Around line 53-54: Remove the appended Correction block from the merged `#917`
record in the board ledger, leaving its original text intact except for
permitted Confidence or Status updates. Preserve the correction in the prepended
`#920` entry and ensure the historical `#917` content matches the unchanged record
in LATEST_STATE.md.
In @.claude/knowledge/weather-normalized-substrate.md:
- Around line 1106-1109: The architectural record in
.claude/knowledge/weather-normalized-substrate.md at lines 1106-1109 must state
that encode_signed derives rim from (place, n), polar from (n, sign), and
azimuth from n; update the discussion of both candidate bearing encodes
accordingly. Align the module documentation in
crates/helix/tests/bearing_encode_paths.rs at lines 4-5 with the same corrected
dependencies.
In `@crates/helix/tests/bearing_encode_paths.rs`:
- Around line 74-76: Add negative elevation coverage to the bearing test loop
around dir, exercising the Sign::Neg and 127 - mag branches; if expanding the
grid, update the documented case count and expected means accordingly.
- Around line 84-85: Update the measurement test around the mean-reporting
println to compute the Path A and Path B means once, reuse those values for
output, and add assertions enforcing broad documented upper bounds for both
paths. Keep the existing ratio reporting while making regressions that worsen
either path fail the test.
---
Nitpick comments:
In `@crates/helix/tests/bearing_encode_paths.rs`:
- Around line 34-38: Update the decode helper around Signed360 to serialize the
input with Signed360::to_bytes and reconstruct it with Signed360::from_bytes
before reading polar and azimuth. Apply the existing direction-math calculations
to the reconstructed value, preserving the current return behavior.
- Around line 64-65: Update the azimuth calculation in the path-B test around
target.0.atan2 so it uses the same truncation policy as encode_signed in
residue.rs instead of rounding before conversion. Keep the comparison focused on
field independence by matching the canonical quantization behavior.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: 9e50b629-0a0f-42b4-a29d-e19927367b27
📒 Files selected for processing (5)
.claude/board/EPIPHANIES.md.claude/board/LATEST_STATE.md.claude/board/PR_ARC_INVENTORY.md.claude/knowledge/weather-normalized-substrate.mdcrates/helix/tests/bearing_encode_paths.rs
Comment on lines
+53
to
+54
| **Confidence (2026-08-11, updated post-#920):** merged, and **two Locked claims are now FALSIFIED by #920** — read that entry first. The floor policy remains `[S]`. | ||
| **Correction (2026-08-11 from PR #920):** the Locked line *"helix360 is … the shipped 6-byte `HelixResidue` lane read as 2 × 24-bit hemispheres = wind in/out"* is **wrong on both halves.** (a) **"helix360" is not a symbol** — pickaxe over full history returns 12 blobs, all authored by that session, zero deletions `[G-absence]`; the type is **`Signed360`**. (b) **The 2×24 in/out reading is not a sanctioned reading of the lane.** Per `.claude/knowledge/helix-cartesian-vs-fisher2z.md` (the doctrine doc that arc never opened), one 6-byte `Signed360` is a **complete full-sphere direction** — the `polar` sign-partition completes the sphere, so there is no second hemisphere to pair. `ResidueEdge`/`rim` is the **METRIC** carrier (`DistanceLut`, L1), `(polar, azimuth)` the **render** carrier; the in/out framing conflated the two. The `Pair48` successor shape this entry's Deferred list implied is **WITHDRAWN, not deferred**. The `[G-absence]` "no pair-writer exists" observation stands as a fact and is simply no longer a gap. What ALSO survives unchanged: the `Signed360` polar sign-partition being load-bearing (codex P2 #498) — #920 added the sweep test that proves the partitions fill `[128,255]`/`[0,127]` exactly. |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win
Keep the merged #917 record immutable.
Line 54 appends a correction inside the merged #917 entry. This violates the board ledger rule and creates an audit mismatch with .claude/board/LATEST_STATE.md, which keeps the historical #917 text unchanged.
Remove the appended correction from the #917 entry. Keep the correction in the prepended #920 entry. Retain only the permitted Confidence or Status update in the historical entry.
As per coding guidelines: “Board files are append-only except status/confidence lines.” The retrieved board-hygiene learning also requires merged entries to remain unchanged and new information to be prepended.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.claude/board/PR_ARC_INVENTORY.md around lines 53 - 54, Remove the appended
Correction block from the merged `#917` record in the board ledger, leaving its
original text intact except for permitted Confidence or Status updates. Preserve
the correction in the prepended `#920` entry and ensure the historical `#917`
content matches the unchanged record in LATEST_STATE.md.
Sources: Coding guidelines, Learnings
Comment on lines
+1106
to
+1109
| **What the reuse then surfaced (the actually-new finding) `[G]`.** | ||
| `encode_signed` derives **all three** direction-bearing fields from `n` alone | ||
| (`residue.rs:182-204`): `rim` from `(place, n)`, `polar` from | ||
| `signed_lift(n, …)`, `azimuth` from `n·φ`. Two candidate bearing encodes exist, |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
Use the actual encode_signed input dependencies in both records.
rim depends on (place, n), polar depends on (n, sign), and azimuth depends on n.
.claude/knowledge/weather-normalized-substrate.md#L1106-L1109: rewrite the architectural record with these dependencies.crates/helix/tests/bearing_encode_paths.rs#L4-L5: align the module documentation with the corrected record.
📍 Affects 2 files
.claude/knowledge/weather-normalized-substrate.md#L1106-L1109(this comment)crates/helix/tests/bearing_encode_paths.rs#L4-L5
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.claude/knowledge/weather-normalized-substrate.md around lines 1106 - 1109,
The architectural record in .claude/knowledge/weather-normalized-substrate.md at
lines 1106-1109 must state that encode_signed derives rim from (place, n), polar
from (n, sign), and azimuth from n; update the discussion of both candidate
bearing encodes accordingly. Align the module documentation in
crates/helix/tests/bearing_encode_paths.rs at lines 4-5 with the same corrected
dependencies.
Comment on lines
+74
to
+76
| for bear in [0.0, 22.5, 45.0, 90.0, 137.5, 180.0, 270.0, 315.0] { | ||
| for elev in [0.0, 5.0, 30.0] { | ||
| let t = dir(bear, elev); |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
Add a lower-hemisphere case.
All test elevations are non-negative. The Sign::Neg path and 127 - mag branch are not exercised. Add negative elevations or a focused lower-hemisphere test. Update the documented case count and means if the grid changes.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@crates/helix/tests/bearing_encode_paths.rs` around lines 74 - 76, Add
negative elevation coverage to the bearing test loop around dir, exercising the
Sign::Neg and 127 - mag branches; if expanding the grid, update the documented
case count and expected means accordingly.
Comment on lines
+84
to
+85
| println!("\n MEAN over {c} (bearing x elevation) cases: PathA {:.4}° PathB {:.4}° ratio {:.2}x", | ||
| sa/c as f64, sb/c as f64, (sa/c as f64)/(sb/c as f64)); |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
Make the measurement enforceable.
The test only prints values. A regression can make Path A or Path B worse while the test still passes. Compute the means once and assert broad bounds for the documented result.
Proposed regression checks
- println!("\n MEAN over {c} (bearing x elevation) cases: PathA {:.4}° PathB {:.4}° ratio {:.2}x",
- sa/c as f64, sb/c as f64, (sa/c as f64)/(sb/c as f64));
+ let mean_a = sa / c as f64;
+ let mean_b = sb / c as f64;
+ let ratio = mean_a / mean_b;
+ println!("\n MEAN over {c} (bearing x elevation) cases: PathA {:.4}° PathB {:.4}° ratio {:.2}x",
+ mean_a, mean_b, ratio);
+ assert!(mean_a > 0.5);
+ assert!(mean_b < 0.2);
+ assert!(ratio > 5.0);📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| println!("\n MEAN over {c} (bearing x elevation) cases: PathA {:.4}° PathB {:.4}° ratio {:.2}x", | |
| sa/c as f64, sb/c as f64, (sa/c as f64)/(sb/c as f64)); | |
| let mean_a = sa / c as f64; | |
| let mean_b = sb / c as f64; | |
| let ratio = mean_a / mean_b; | |
| println!("\n MEAN over {c} (bearing x elevation) cases: PathA {:.4}° PathB {:.4}° ratio {:.2}x", | |
| mean_a, mean_b, ratio); | |
| assert!(mean_a > 0.5); | |
| assert!(mean_b < 0.2); | |
| assert!(ratio > 5.0); |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@crates/helix/tests/bearing_encode_paths.rs` around lines 84 - 85, Update the
measurement test around the mean-reporting println to compute the Path A and
Path B means once, reuse those values for output, and add assertions enforcing
broad documented upper bounds for both paths. Keep the existing ratio reporting
while making regressions that worsen either path fail the test.
AdaWorldAPI
pushed a commit
that referenced
this pull request
Aug 11, 2026
…not fit it #921 merged with neither board file updated. It was a MIXED PR (board hygiene for #920 plus the wind bearing-encode finding), so the termination clause does not apply — per the rule, the non-hygiene half is what the entry is for. The entry records what #921 actually settled: - The invention/reuse line. Invention = asserting structure the code already answers. Reuse = applying the shipped codec to a new domain, which is what a normalized substrate is for. A missing entry point for a designed reuse is a plumbing gap, not a design refusal — correcting #920 §12.12, which declined to build the bearing-encode on the wrong grounds. - The finding the reuse surfaced: the knowledge doc prescribes nearest spherical-Fibonacci (n, sign) for encoding a direction, and it does NOT fit weather. Horizontal bearings measure 1.9-2.7 deg via nearest-n vs 0.000 deg via a direct (polar, azimuth) write; mean over 24 cases 0.972 vs 0.097 — 10x. The golden spiral couples latitude and azimuth through ONE index, so a bearing at the horizon cannot be chosen independently; and the lattice is equal-area on the DISK, so latitude density ~ sin(2*lat) is sparsest exactly at the equator. Normals spread over the sphere and never hit this. - The rule: a doctrine written for one domain is not automatically right for the next one that reuses it. Deferrals carried forward, including that no public from_bearing was minted — the API shape is an operator call and must not be built on before it is made. This commit is hygiene-only, so per the termination clause it generates no further board obligations of its own. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CcpLeEC3XK8Eye53GKBVvi
AdaWorldAPI
added a commit
that referenced
this pull request
Aug 11, 2026
…arvest-rfii13 docs(board): record #921 — the wind reuse and the doctrine that does not fit it
AdaWorldAPI
pushed a commit
that referenced
this pull request
Aug 11, 2026
Operator: "you didn't factor in that due to normalized values the field has
different ergonomics than the single value — meaning AMX matmul, tile ops etc."
Correct, and it reverses the recommendation. §12.13 ranked the two bearing
encodes by angular RECONSTRUCTION error — the operation §12.10 rules out and
the substrate exists to avoid. Third instance of that error in one arc, and
this one landed three sections after writing the rule down.
At field scale the ergonomics run the other way:
- nearest-n collapses direction to ONE index in the 256-palette domain, so
comparison is rim.distance_adaptive = two DistanceLut u8 lookups: an L1
metric with the triangle inequality, CAKES/CLAM-safe, U8x64-friendly
(distance.rs:12), and a &[u8] plane that feeds ndarray's
int8_gemm_amx_tiled(a_u8, b_i8, ...) -> [i32] directly.
- direct (polar, azimuth) has a 16-bit CIRCULAR azimuth, which distance.rs:8-10
names explicitly as NOT a metric ("the 2pi wrap ... must never feed CAKES
bounds"). No 256x256 LUT, no tile plane, and comparing would require decoding.
Resolution is a split by OPERATION, not a winner: single-index for
compare/search/correlate over a field (what "pay the inbound tax once" actually
buys, and why palette256 is the same pattern one rank down); direct write only
where one bearing must genuinely be materialized.
Rule extracted: a per-element accuracy number is the round-trip metric wearing
a different hat. A representation can win it while destroying the index-domain
comparison, the metric guarantee, and the tile shape that made the substrate
worth building.
The 10% measurement stands and is kept; only its verdict is corrected. Applied
as an append-only Correction line on the #921 arc entry plus its Confidence,
never an edit to the Locked text.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CcpLeEC3XK8Eye53GKBVvi
AdaWorldAPI
pushed a commit
that referenced
this pull request
Aug 11, 2026
Operator: "you didn't factor in that due to normalized values the field has
different ergonomics than the single value — meaning AMX matmul, tile ops etc."
Correct, and it reverses the recommendation. §12.13 ranked the two bearing
encodes by angular RECONSTRUCTION error — the operation §12.10 rules out and
the substrate exists to avoid. Third instance of that error in one arc, and
this one landed three sections after writing the rule down.
At field scale the ergonomics run the other way:
- nearest-n collapses direction to ONE index in the 256-palette domain, so
comparison is rim.distance_adaptive = two DistanceLut u8 lookups: an L1
metric with the triangle inequality, CAKES/CLAM-safe, U8x64-friendly
(distance.rs:12), and a &[u8] plane that feeds ndarray's
int8_gemm_amx_tiled(a_u8, b_i8, ...) -> [i32] directly.
- direct (polar, azimuth) has a 16-bit CIRCULAR azimuth, which distance.rs:8-10
names explicitly as NOT a metric ("the 2pi wrap ... must never feed CAKES
bounds"). No 256x256 LUT, no tile plane, and comparing would require decoding.
Resolution is a split by OPERATION, not a winner: single-index for
compare/search/correlate over a field (what "pay the inbound tax once" actually
buys, and why palette256 is the same pattern one rank down); direct write only
where one bearing must genuinely be materialized.
Rule extracted: a per-element accuracy number is the round-trip metric wearing
a different hat. A representation can win it while destroying the index-domain
comparison, the metric guarantee, and the tile shape that made the substrate
worth building.
The 10% measurement stands and is kept; only its verdict is corrected. Applied
as an append-only Correction line on the #921 arc entry plus its Confidence,
never an edit to the Locked text.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CcpLeEC3XK8Eye53GKBVvi
AdaWorldAPI
pushed a commit
that referenced
this pull request
Aug 12, 2026
#927 was MIXED, not hygiene-only -- it landed board hygiene for #926 AND a correction to COMET_TAIL_REPORT.md AND an append-only revert. The termination clause exempts only the pure case, so its non-hygiene half owes this entry. (#927's own description called itself "hygiene-only"; that was written before the correction landed and was wrong by the time it merged.) The entry records two things a future session needs: * The Fisher-z ring-mean ratio is 4.7x, not 5x -- caught by verifying the entry's own figures against the committed JSONs before landing. 9 of 10 matched exactly; this was the tenth, a 6% overstatement in the favourable direction, one commit from being frozen into an append-only record. * LIVING DOCUMENTS and APPEND-ONLY LEDGERS take OPPOSITE correction discipline. A living document (report, code, JSON, PR description) is landed on directly, so a stale claim is a trap -> correct every copy. An append-only ledger is read newest-first and its value IS the audit trail -> freeze the merged entry, correct in a new one. I applied the first rule to the second kind of file while citing that very rule. The failure mode is a correct rule generalized past its domain -- the same shape as #921's doctrine-vs-domain finding and this arc's own Fisher-z result. Also banks the falsifier that closed "where else did I do this": a pure prepend cannot delete, so `git diff origin/main..HEAD -- .claude/board/` showing zero removed lines is a structural append-only audit. Measured +13/-0, +10/-0, +0/-0. THIS PR IS PURE HYGIENE -- no type, plan, deliverable, epiphany or code. Per the termination clause it generates no further obligations and the chain stops here. The living-vs-ledger lesson is deliberately recorded in the arc entry rather than minted as an EPIPHANIES entry, which would make this PR mixed and restart the chain; promote it on request. Co-Authored-By: Claude <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CcpLeEC3XK8Eye53GKBVvi
AdaWorldAPI
pushed a commit
that referenced
this pull request
Aug 12, 2026
…ng, and the append-only audit could not fail Operator: "930 has comments / check also previous 5 / if you want go back another 5." All 68 review comments on #920-#930 enumerated and checked against the TREE, not the merge. Depth is non-uniform and said so: #922-#930 finding-by-finding; #920 (27) and #921 (5) spot-checked on P1/governance only (both clean), ~30 older findings there left explicitly UNVERIFIED. Clean: #922/#924/#925/#929 zero comments; all 27 of #926's findings fixed in the tree (equal-budget grid_pts + regenerated E2 JSON, seam-wrapping subgrid_min, find_center->None, F7d 35->40, CT_F12 NO-VERDICT, persisted storm metadata, np.roll longitude, __file__-relative write, net-decay E6, the 93-97%->90.9-94.3% headline); #923's plan-status P2 resolved. Three open, all frozen in append-only ledgers, all corrected in NEW entries: 1. "+92.76 Pa moves R2 in the 5th decimal" is refuted by the report's own carve table 15 lines above it: carve A's +92.76 Pa moved R2 0.9212->0.9129 (0.0083, THIRD decimal); carve D's +1.59 Pa moved it 2.4e-06 (SIXTH). The var() BUG was blind at every magnitude; the STATISTIC is near-blind only in the single-digit-Pa regime -- which is exactly where "lossless" was claimed. 2. "10 probe scripts with committed JSON" undercounts: 15 .py added, 11 with a committed .json. 3. "+13/-0, +10/-0, +0/-0": measured +13/-0, +17/-0, and EPIPHANIES absent from the net diff -- it was +1/-1 at 0f9e6bc (the in-place edit), zeroed by the revert. The +0/-0 was a revert artefact, not evidence of purity. And the audit METHOD is replaced: zero-deletions proves ADDITIVE, not PREPEND. The suffix check (new.endswith(old)) proves it. Both halves measured before banking: a constructed end-append scores zero-del=True/suffix=False; a true prepend True/True. It also fires on THIS PR (LATEST_STATE suffix=False at +15/-0) -- correctly, since #930 inserts table rows mid-file and composes an unmerged entry in place. A False is a demand for justification, not a verdict. Same defect shape as #930's relation error, twice in three days: two individually-true numbers asserted of one pair when each belongs to a different one. A figure-by-figure check cannot catch it; the relation must be evaluated as a claim. Already standing in report SS10.1 and the worker preamble of weather-w-probes-v1 (both verified present, not assumed). Co-Authored-By: Claude <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CcpLeEC3XK8Eye53GKBVvi
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Post-merge board hygiene for #920, which merged with neither board file updated — zero references to it in
PR_ARC_INVENTORY.mdorLATEST_STATE.md.This is the retroactive-hygiene pattern
CLAUDE.mdnames as an anti-pattern. It is unavoidable once the PR is merged, and leaving the board stale is the worse outcome — the rule exists precisely because #223/#224/#225 merged with no entries at all.What this does
PR_ARC_INVENTORY.md— prepends the probe(weather): P1/P2/gate-1 RUN — and the evaluation frame itself was wrong #920 entry (Added / Locked / Deferred+WITHDRAWN / Docs / Confidence), and applies the file's own rules 3–4 to the docs(weather): normalized-substrate reference — palette256 × helix360 #917 entry: an appended**Correction**line plus an updated**Confidence**line, never an edit to its immutable Locked text.LATEST_STATE.md— prepends the probe(weather): P1/P2/gate-1 RUN — and the evaluation frame itself was wrong #920 entry carrying the same correction as a leading⊘supersession note.Why #917 needed correcting
It locked two claims #920 falsified, and left unannotated they are exactly the rediscovery tax the arc file exists to prevent:
Signed360; pickaxe over full history returns 12 blobs, all authored by that session, zero deletions[G-absence].HelixResiduelane does not read as "2 × 24-bit hemispheres = wind in/out". One 6-byteSigned360is already a complete full-sphere direction — thepolarsign-partition completes the sphere.ResidueEdge/rimis the metric carrier;(polar, azimuth)is the render carrier. ThePair48mint is WITHDRAWN, not deferred.What survives from #917 unchanged: the
Signed360polar sign-partition being load-bearing (codex P2 #498) — #920 added the sweep test proving the partitions fill[128,255]/[0,127]exactly.Also recorded — a measurement made after the merge
In answer to an operator question about polar vs equatorial error rates.
Signed360angular error by latitude, N=65536:~30× spread, best at the rim — the equatorial ordering is confirmed. But the premise that signing buys accuracy does not survive: there is no resolution gain at equal bit budget. 7-bit
|y|+ sign vs 8-bit over[-1,1]measures 0.99–1.02× in every band (step 1/127 vs 2/255 = 0.996×). The 256-sample codebook figures implying a √2 gain (full-sphere cap 7.17° vs hemisphere 5.07°) spend an extra bit; at equal budget 128-on-hemisphere is 7.17°, identical.What the partition buys at the rim is sign EXACTNESS, not precision — and that is exactly where weather lives, since a wind bearing is near-horizontal (
y ≈ 0), the regime where a centred-at-128 round loses the hemisphere (#498).Scope
Two board files, 26 insertions, 1 deletion (the updated Confidence line). No code, no types, no plans. Per the termination clause, this hygiene-only PR generates no further board obligations of its own.
🤖 Generated with Claude Code
https://claude.ai/code/session_01CcpLeEC3XK8Eye53GKBVvi
Summary by CodeRabbit
Documentation
Tests