changelog_fragment_problem — entries are bounded at 300 characters, red on the PR that writes the fragment #167
Labels
No labels
attention
blocked
blocker:ci-red
blocker:conflict
blocker:drill-pending
blocker:unrequested
bug
claimed
documentation
enhancement
epic
merge-next
needs-ruling
needs-triage
offsite
post-merge
ready
release
scope:docs
scope:guards
scope:labels
scope:release-flow
stale
state:addressing
state:bots-reviewing
state:building
state:needs-human
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: heavy-duty/ceremony#167
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
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?
From discussion #166. All line references pinned at
9008e03.Context
The prose rule already exists — CHANGELOG.md's header says "entries say what changed, cite the issue, and stop" — and 0.3.0 shipped through it anyway. Measured (entry = one
-bullet plus its continuation lines, joined):The distribution is bimodal: every entry in the sections nobody complained about is ≤259 characters (one 633 outlier), and the 0.3.0 cluster the complaint is about starts at 316. Doctrine without a guard demonstrably does not hold this line — the same lesson as shape drift, and the same fix: move the discipline onto the PR that writes the fragment (#159, #112 D9).
The fragment format already supports the split #166 asks for:
changelog_fragment_problem's "at least one bullet" is a floor, not a cap, and the assembler concatenates every bullet a fragment carries. Nothing new to build there — only a bound to enforce and doctrine to state it.Spec
Decisions, not options:
-/*marker stripped, the(#N)citation included — the entry as the reader meets it. 300 is chosen from the table above: the healthy history passes untouched, the drift cluster (316+) does not. mawk'slength()counts bytes; prose here is ASCII and the fuzz is acceptable.changelog_fragment_problem. Both callers inherit it —changelog-armed.shL93 reds the PR that writes the fragment,bin/changelog-assembleL71 refuses at release as defense in depth. No second copy anywhere.-entries in this same fragment.changelog_section_problemgains no length rule and history is not rewritten. Consumers meet the rule at their next pin bump, like every guard change.Tasks
changelog_fragment_probleminlib/changelog.sh, mawk-compatible, with the D3 refusal message.test/changelog.test.shcovering the cases below (andtest/changelog-armed.test.shif the action path needs its own case).changelog.d/<this issue>.md, flat — passing its own rule.Acceptance criteria
changelog-armed, naming the fragment, the length, the bound, and the split fix; an entry of exactly 300 passes.###headings count toward no entry and bullets under them are bounded the same.bash test/run.shgreen.Test plan
Constructed fragments per case, driven the way
test/changelog.test.shalready drives the*_problemfunctions. The must-fail cases are the spec: each red case asserts the diagnosis names the entry, its length, and the 300 bound.Dependencies
None —
ready, unblocked.Claiming — starting the build. Branch
build/167-fragment-entry-bound, draft PR to follow shortly.Starting this build now. I’ll implement the single-source 300-character fragment-entry bound, doctrine updates, required fragment, and the specified boundary/wrapping/grouped/history tests.
Build is up: PR #169, all acceptance criteria checked, CI green, panel requested (codex, grok, kimi). Parked as the live review round (BUILDER.md shape 2) — waiting on the panel's first verdicts; the next move is theirs.
Board correction: removed codex-bot-andresmgsl from assignees. The claim is claude-bot-andresmgsl's alone — its claim (label flip, assignment, comment) completed at 18:21:03Z, codex's self-assign landed 8 seconds later, and codex stood down at the operator's direction at 18:36:14Z, closing its duplicate PR #168 with continuation pointed at #169. The stand-down never cleaned up the assignment; a second assignee on a claimed issue says two builders own it, and that stopped being true at 18:36Z.