seller_exec::delivery_message caps the delivery commit subject with summary.chars().take(72) and no word-boundary handling, so every delivery whose first task line exceeds the cap is cut mid-word.
Observed on main. #635's merge commit reads:
maxplayer delivery: Implement Phase 0 of maxplayerai issue #599 ("verified contribution deli (#635)
92 bytes of subject — "maxplayer delivery: " is 20, the cap adds 72 — ending mid-word with an unclosed paren and an unclosed quote. A single-commit PR takes its squash subject from the commit, not the PR title, so this reaches main verbatim on every market delivery.
Two defects in one line.
- Mid-word cut.
take(72) cuts at an arbitrary offset. Trimming back to the last word boundary, with an ellipsis or nothing, costs one line.
- The cap counts chars, not bytes.
chars().take(72) bounds characters, so a non-ASCII first line yields up to 288 bytes of subject. The cap is not the bound it appears to be.
The existing test cannot see either defect. delivery_message_summarizes_the_task asserts msg.len() == "maxplayer delivery: ".len() + 72 against "x".repeat(200). A single-word ASCII fixture has no word boundary to cut badly and no multi-byte char to widen, so it pins the current behaviour while being blind to both properties the behaviour gets wrong. Whatever fix lands, that fixture needs a sibling with real words and one with multi-byte characters.
Scope. This is a fix at the generation site. Subjects already merged are not repaired by it, and that is accepted — main's existing #635 subject stays as it is rather than being rewritten.
The merge-bar half of this — whether a squash subject should come from the PR title instead of the commit — belongs with the merge gate and is tracked separately.
seller_exec::delivery_messagecaps the delivery commit subject withsummary.chars().take(72)and no word-boundary handling, so every delivery whose first task line exceeds the cap is cut mid-word.Observed on
main. #635's merge commit reads:92 bytes of subject —
"maxplayer delivery: "is 20, the cap adds 72 — ending mid-word with an unclosed paren and an unclosed quote. A single-commit PR takes its squash subject from the commit, not the PR title, so this reachesmainverbatim on every market delivery.Two defects in one line.
take(72)cuts at an arbitrary offset. Trimming back to the last word boundary, with an ellipsis or nothing, costs one line.chars().take(72)bounds characters, so a non-ASCII first line yields up to 288 bytes of subject. The cap is not the bound it appears to be.The existing test cannot see either defect.
delivery_message_summarizes_the_taskassertsmsg.len() == "maxplayer delivery: ".len() + 72against"x".repeat(200). A single-word ASCII fixture has no word boundary to cut badly and no multi-byte char to widen, so it pins the current behaviour while being blind to both properties the behaviour gets wrong. Whatever fix lands, that fixture needs a sibling with real words and one with multi-byte characters.Scope. This is a fix at the generation site. Subjects already merged are not repaired by it, and that is accepted —
main's existing #635 subject stays as it is rather than being rewritten.The merge-bar half of this — whether a squash subject should come from the PR title instead of the commit — belongs with the merge gate and is tracked separately.