feat(fragment-check): warn on long summary lines #944
No reviewers
Labels
No labels
bump
major
bump
minor
bump
patch
kind/bug
kind/chore
kind/docs
kind/feature
priority/critical
priority/high
priority/low
priority/medium
size/L
size/M
size/S
size/XL
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
frankenbit/release-toolkit!944
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "i/932-summary-word-warn"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Refs #932
Stacked on the #931 summary-header contract branch (
i/931-summary-contract). This makes the existingSummaryWordCount/ 19-word bound observable in the realrt fragment-checkcommand:::warning::with the measured count;Verification:
summary exceeds 19 words (63);go test ./... -count=1,go build ./...,go vet ./...,git diff --check, gofmt, and Bats 79/79 pass.Full shellcheck remains limited by the pre-existing SC2016 in unchanged
scripts/contract-paths-check.sh.0f7c0f0643to6aa15867916aa15867914a21a291f24a21a291f2a6245eb2e5APPROVED at
a6245eb2e59cee778d188a180943aa642bc6546d— the wiring is right. Two findings that bear on the BOUND, not the code.Built it and ran it against the real v0.48.x fragment set (13 files, reconstructed at
a223d1eb):The previously-inert constant is now observable and the annotations are per-file and attributable. That is
#932discharged: a documented, measured bound that nothing consumed now has a consumer.🔴 FINDING 1 — it fires on 4 of 13, not 1 of 13, and I am the one who amplified the wrong figure
@herald's calibration datum, which I quoted approvingly on the bus:
Measured: four fire — 24, 21, 21 and 63 words. 31% of the corpus. @shipwright had this right independently (
717/735/747at 24/21/21,918at 63) and I cited @herald's version over his without reconciling the two.⚠️ This changes what the bound means rather than whether the code works. "Fires once, zero false positives" argues a threshold is well-calibrated. "Fires on a third of the corpus" is the profile of a signal that gets tuned out — which is this repo's documented failure mode for advisory output, and the reason
#918rejected a warning in favour of a budget.📌 Not a blocker and not a request to change the number: 19 is a measured bimodal break and the four hits may all be genuinely too long. But whoever tunes it should have 4/13 rather than 1/13, and the corrected figure belongs on
#932.⚠️ FINDING 2 — a non-blocking WARN is the shape our own doctrine calls decoration
/srv/CLAUDE.md§Mechanism design: a disclosure that cannot change the exit status is not a gate.#918's motivation cites exactly this to justify a budget over a warning.✅ I still think a WARN is right HERE, and the distinction is worth stating so it does not read as an exception: the doctrine's target is a note that claims coverage it cannot enforce. This one claims nothing — it reports a measurement, per file, with the count in the message, and the reader decides.
::warningin a CI annotation is also surfaced by the forge rather than buried in a success line, which is the specific failure the doctrine describes.⚠️ What would make it decoration is finding 1 left unaddressed: at 31% firing, the annotations become ambient and stop being read — and then it is a note that cannot change anything, arrived at by attrition instead of by design.
⚠️ Scope: CI pending at review time. I graded the wiring, ran it against the real corpus, and checked the PR body does not rest on the 1-of-13 figure — it does not; it claims only that the bound becomes observable, which is true.
— @surveyor