fix(run): the PR body's imported exec text is cut at 4,000 characters with no marker — #1577 and #1578 both ended mid-word and read as complete
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 86/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- typescript
- Domain
- backend-api-design, testing
Research direction
Read capImportedText in src/lib/workflow/worktree-manager.ts and the related cases in src/lib/workflow/worktree-manager.build-pr-body.test.ts. Run npx vitest run src/lib/workflow/worktree-manager.build-pr-body.test.ts to see the current behavior. Add a visible cut marker for both callers while preserving under-cap text, comment guards, and the stated length bound; update the changelog entry.
Written by the indexing model from the issue text.
Description
Problem
capImportedText (src/lib/workflow/worktree-manager.ts:2342, added in #1297) limits the exec text imported into a PR body to EXEC_SUMMARY_MAX_LENGTH (4,000 characters). Both callers use it: the ## Summary section (extractExecSummary, :2333) and the AC table (:2405). When the cap applies, the text stops at character 4,000 with no sign that anything was cut, often in the middle of a word. A cut-off body reads as complete.
This happened twice on 2026-10-21. #1577's body ended at "most of the 41 converted files have no test that ex", and #1578's at "`qa-markdown-on". Both were found only because the runner read each body to the end, and both were fixed by hand. A reviewer who stops at a clean-looking end won't know the rest is missing, for example the pre-PR confidence check or the coverage-gap notes.
The cap itself stays. It exists so a runaway section can't bloat the body (#1297). This issue adds only the signal.
Acceptance Criteria
- AC-1: A capped text ends with a visible marker that says it was cut, e.g.
… (exec text cut at 4,000 characters). The marker applies to both callers, since both go throughcapImportedText. Evidence:npx vitest run src/lib/workflow/worktree-manager.build-pr-body.test.ts -t "cut marker"→≥ 1 passed, 0 failed(new case; today it matches no test) - AC-1 is classified as a gate test by
isGateTestEvidence; the PR body carries itsSEQUANT_MUTATIONrecord (remove the marker fromcapImportedText→ the new test fails; restore). - AC-2: Text under the cap is unchanged, and the #1297 comment guard still holds: a cut inside
<!--drops the partial comment, and the markers are re-appended whole after the cut marker. Evidence:npx vitest run src/lib/workflow/worktree-manager.build-pr-body.test.ts→0 failed(59 pass today) - AC-3: The cap still bounds the body: the capped text plus the marker is at most
EXEC_SUMMARY_MAX_LENGTHplus the marker's length. Evidence: the existing "caps a runaway summary to ~4KB" case (worktree-manager.build-pr-body.test.ts:245, which today assertslengthis exactly 4000) is updated to assert the new bound and that the text ends with the marker;npx vitest run src/lib/workflow/worktree-manager.build-pr-body.test.ts -t "caps a runaway summary"→1 passed, 0 failed
May touch
src/lib/workflow/worktree-manager.ts (capImportedText only), src/lib/workflow/worktree-manager.build-pr-body.test.ts, CHANGELOG entry.
Non-Goals
- Changing the 4,000-character cap or which sections are imported.
- Cutting at a word or sentence boundary. Nice to have, but the marker is what tells a reader text is missing.
- No edits under
plugin/,.claude/skills/,templates/skills/(plugin freeze).
- Dominant language
- TypeScript
- Stars
- 1
- Forks
- 1
- Avg merge
- 11h 3m
- Merged PRs (30d)
- 84
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from sequant-io/sequant
-
graph-2026-11-simplify
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
sequant-io/sequant#1650 ·
Maintainers usually reply within 1 day
-
run: --phases does not suppress the UI-label test phase (determinePhasesForIssue adds it to an explicit list)Possibly taken @admarble claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
sequant-io/sequant#1631 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
sequant-io/sequant#1601 ·
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 76/100
sequant-io/sequant#1381 ·
Maintainers usually reply within 1 day
-
improve(skills): /loop and /fullsolve run affected tests, not the full npm test (#1349 follow-up)Openenhancement
Difficulty 2/5 1-3 hours Newbie friendliness 83/100
sequant-io/sequant#1360 ·
Maintainers usually reply within 1 day
All issues in sequant-io/sequant
Similar issues
-
content triage
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
tensorflow/tfjs#8754 ·
-
tool-submission
Difficulty 1/5 Under an hour Newbie friendliness 83/100
BraveOPotato/NoSignups#2348 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
code-yeongyu/oh-my-openagent#12784 ·
Maintainers usually reply within 1 day
-
external-issue to-triage
Difficulty 2/5 1-3 hours Newbie friendliness 71/100
Maintainers usually reply within 1 day