fix(statements): republish the 2026-07-28 weekly, and render the denominator - #60
Merged
Conversation
…minator `resolved_count` landed in #59, so an unresolved window is expressible: adding `resolved_count: 0` clears `findHitRateInconsistencies`, which is what held this file at `draft: true`. The numbers are unchanged from #58 — regenerated from the warehouse at auditmos/ogsfrompoly@554f537 over the identical window — and its summary's "0 of 263 resolved" is the count itself, so the field states what the prose already did. Publishing it would otherwise have put `Hit rate 0%` back on the live page beside this stat's own caption, "0.50 ≈ a coin flip; above 0.50 is signal" — the exact misreading auditmos/ogsfrompoly#236 exists to stop, on the most-skimmed surface. So the stat now reads `pending` when the denominator is known-empty, with wording that replaces the standing caption rather than appending a caveat to it. `formatHitRate` / `describeHitRate` key off the denominator, never the rate, so a genuine 0-in-favour-of-240 week still reads as a real 0%. Absent stays unknown, never zero: every statement published before the field existed renders exactly as before, verified across all twelve. A known non-zero denominator is now named too ("Measured over the 240 of 263 alerts that have resolved") — publishing a rate without one is what let the 0.00 pass unnoticed for a week. Refs auditmos/ogsfrompoly#236
github-actions Bot
pushed a commit
that referenced
this pull request
Jul 30, 2026
## [1.18.1](v1.18.0...v1.18.1) (2026-07-30) ### Bug Fixes * **statements:** republish the 2026-07-28 weekly, and render the denominator ([#60](#60)) ([792ecdd](792ecdd)), closes [#58](#58) [auditmos/ogsfrompoly#236](https://github.com/auditmos/ogsfrompoly/issues/236) [auditmos/ogsfrompoly#236](https://github.com/auditmos/ogsfrompoly/issues/236)
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
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.
Closes the last open item on auditmos/ogsfrompoly#236 —
2026-07-28-weekly.mdhasbeen off the live site at
draft: truesince #58.Republishing
resolved_countlanded in #59, so an unresolved window is finally expressible.Adding
resolved_count: 0clearsfindHitRateInconsistencies, which is the guardthat held this file as a draft:
No number changed. The frontmatter is exactly what #58 landed — regenerated by
poly-track report public weeklyat auditmos/ogsfrompoly@554f537 over the identicalwindow. Its summary already read "0 of 263 resolved", and that sentence is the
count, summed over every category; the LP-mapped subset it bounds can only be 0 too.
So the new field states what the prose already claimed, rather than asserting
anything new.
Why this PR also touches the render
Flipping
draft: falsealone would have putHit rate 0%back on the homepage,the statements index, the statement page and the social card — beside this stat's own
caption:
That is the precise misreading ogsfrompoly#236 exists to stop, sitting on the most-skimmed
surface, while the correction lives only in the summary paragraph. Republishing without
this would have re-shipped the bug in a quieter place.
resolved_count: 0pendingresolved_count: 24047%47%Three properties the tests pin:
still reads as a real
0%, not "pending".Verified across all twelve statements, not just the changed one.
as a verdict on the number beside it, so it must not survive next to a vacuous rate.
A known non-zero denominator is now shown as well. Publishing a rate without one is
what let the original 0.00 pass unnoticed for a week.
Verification
Full
Verifygate run locally:pnpm test— 416 passed (408 before; 7 new + 1 content case the now-published statement adds)pnpm lint— clean, 115 filespnpm knip— cleanpnpm types— 0 errors, 0 warnings (1 pre-existing hint inDisplayHeading.astro, untouched)Rendered value for every statement in the collection:
Producer half is auditmos/ogsfrompoly@6c6328f; no address leak (all wallet references
remain truncated ids).
Refs auditmos/ogsfrompoly#236