fix(cli): wire lint into local and CI checks (reopen of #1247) - #1258
Merged
Conversation
…one attaching Sam (57691) asked to fold "prose overflow goes in a thread, not an attachment" into the cue. The cue already says it, verbatim, since #1176. The behaviour he watched all day continued anyway, and the reason is that the cue was aimed one layer above the thing doing it: agents were not choosing to attach. `deliverChatReply` decides the delivery mode, and its ladder ended at upload: fits in one message -> post splits into <= maxChunks -> post the chunks longer than that -> upload the whole text as a file Every `<agent>-reply-<eventId>.md` card in this pod came from that last rung, including two of mine today. The function predates threads and had no concept of one. So the cue promised a behaviour the wrapper actively contradicted — which is @sprint-review's degrades-open caveat exactly: the cue should promise what the kernel enforces, and here it could not be obeyed at all. Adds the rung Sam specified — post the headline to the channel, continue the rest under it with threadRootId — and keeps attach for the case it was always right for: a single indivisible unit over attachThreshold (a long fence, an unbreakable run). That is a document by construction; prose that outgrew a message is not. Two of this suite's existing tests caught a real bug in the first draft. The attach rung also leads with chunks[0], so falling through after a successful headline post duplicated the opening line in the room. The recovery now tracks whether the headline landed: if it did, post the REMAINDER top-level (thread-fallback) rather than the whole text again; if the headline itself failed, nothing reached the room and attach is free to lead as before. Two existing tests changed meaning rather than being bent to pass, and both say so at their call site. Their fixtures are prose, which is precisely the case this reclassifies — their INTENT (nothing is cut; flood beats truncation or silence) is preserved and now carried by the thread. Probe: reverting the rung reddens the six behavioural tests and leaves the indivisible-oversize control green. Suite 61 passed. Version 0.1.18 -> 0.1.19. Note this collides with #1215's bump if both land — whichever merges second needs a re-bump, since the guard compares against main. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…rom 1 `headlinePosted` was a boolean, so the recovery always resumed at `chunks.slice(1)`. A boolean can only distinguish "nothing posted" from "something posted"; it cannot say how much. Fail a continuation at chunk 3 and chunks 1 and 2 are already in the thread — the fallback then posts them again top-level, and the reader sees them twice. That is the duplicate-opening bug this rung exists to prevent, one index further along. The suite did not catch it because both existing failure tests throw at the root-id step, before any continuation has posted. At that instant "something posted" and "one thing posted" are the same statement, which is exactly when a boolean stands in for a count without looking wrong. Now a counter, incremented after each successful post, with the fallback resuming at `chunks.slice(posted)`. New test fails the 4th post and asserts every chunk arrives exactly once; reverting to `slice(1)` reddens it alone (1 of 62). Found by @sprint-review gating #1217. Pushed onto this branch rather than a second PR — the head had not moved in three hours. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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
1 participant
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.
Re-press of #1247, which was stacked on #1246's branch and auto-closed when that branch merged and deleted (the stacked-PR trap; #1251's retarget guard now exists but cannot resurrect an already-closed PR). Same head commit f95c1be, now based on main so CI runs against the real base for the first time — which is exactly what the stacked-PR memory warns stacked children never get.
🤖 Generated with Claude Code
https://claude.ai/code/session_01TdEJoXUmbHmW5TFk7hfkbK