Repository navigation
plan-phase, execute-phase and two other workflows exceed OpenCode's 50 KB Read window, and the gsd_run resolver line exceeds its 2000-character line cap #5257
Description
- Found: 2026-10-07, Plan 01-06 smoke (plan-phase F3, execute-phase F2), generalised in Plan 01-09
- Environment: GSD Core 1.16.0 (
npx @opengsd/gsd-core --opencode --global), OpenCode 1.18.35,
Linux
Summary
On OpenCode, the gsd-plan-phase, gsd-execute-phase and gsd-review commands and skills
@-include their workflow file. OpenCode delivers every @ include through its Read tool, which
returns at most 51,200 bytes and 2000 lines and cuts every line over 2000 characters (see U-03).
Four GSD Core 1.16.0 workflow files are larger than that window:
| File | Size |
|---|---|
gsd-core/workflows/plan-phase.md |
97,462 B, 1,594 lines |
gsd-core/workflows/execute-phase.md |
88,481 B, 1,376 lines |
gsd-core/workflows/execute-phase/steps/code-review-disposition.md |
79,643 B |
gsd-core/workflows/review.md |
51,742 B (under the cap only because its long line is cut) |
The model receives the first half of plan-phase and execute-phase. The plan-checker spawn (step 10
of plan-phase, line 985) and verify_phase_goal in execute-phase never reach it. Independently of
size, the one-line gsd_run resolver is about 2600 characters long and sits in 115 installed corpus
files. It embeds install paths, so the exact length varies: 2586 in the OpenCode install and 2573 in
the Claude Code install on the reporting machine. OpenCode cuts it at 2000 characters, so a workflow delivered through Read cannot define
gsd_run, and every later gsd_run query ... fails.
Minimal repro
npx @opengsd/gsd-core@1.16.0 --opencode --globalwc -c ~/.config/opencode/gsd-core/workflows/plan-phase.mdprints 97462.awk '{ if (length($0) > m) m = length($0) } END { print m }' ~/.config/opencode/gsd-core/workflows/quick.md
prints a value over 2000 (2586 on the reporting machine).- In any project, run
/gsd-plan-phase <n>in OpenCode and inspect the session's synthetic Read
part for plan-phase.md. It ends with
"(Output capped at 50 KB. Showing lines 1-812. Use offset=813 to continue.)", and the resolver
line ends with "... (line truncated to 2000 chars)".
Expected
Each workflow that a command or skill includes eagerly arrives in full on every supported runtime,
and the resolver defines gsd_run.
Actual
The workflow arrives cut at line 812 (plan-phase) or 737 (execute-phase). In both 01-06 attempts
the brain model (mistral-large) ignored the "Use offset" hint and improvised. One attempt spawned
a general subagent with a self-written prompt instead of gsd-planner and gsd-plan-checker.
In execute-phase attempt 2 it ran gsd_run query init.execute-phase with no definition.
Suggested fix
- Keep every file that commands or skills
@-include under 50 KB and 2000 lines. For example,
split plan-phase and execute-phase into a spine plus step files that are included explicitly. - Emit the resolver as several lines of at most a few hundred characters each. The one-line form
has no functional advantage. - Add a size check to the release pipeline for OpenCode-delivered files.
Cowright workaround
scripts/patches/read-window.cjs, run by scripts/apply.cjs after every install (D-16). It wraps
lines over 2000 characters (115 resolver lines in bash fences plus 2 prose lines), splits the
over-window files in place into parts of at most 45 KB, and adds one @ include per part to the
commands and skills. Every part ends with a directive naming the next part. Check C14 in
scripts/verify-mechanical.cjs verifies all of it, including OpenCode's own view of the commands
and skills. Applied to the real HOME as C-01.
Evidence
docs/smoke/runs/2026-10-07/headless.json(plan-phase and execute-phase diagnosis, root_cause)docs/smoke/runs/2026-10-07/read-window-rehearsal.json(real HOME before: C14 the only failure;
ext4 rehearsal: C01..C14 pass)docs/smoke/runs/2026-10-07/mechanical-read-window.json(real HOME after C-01: C14 pass)- tests
scripts/test/read-window.test.cjs,scripts/test/read-window-install.test.cjs
Activity
trek-e commentedon Oct 9, 2026
Diagnosis
Reproduced: partially, by measurement. Source tree at ed0f3fd: plan-phase.md 97,857 B / 1,606 lines; execute-phase.md 88,394 B / 1,382 lines; execute-phase/steps/code-review-disposition.md 79,630 B; review.md 51,937 B (over 51,200 before any line cut); quick.md 43,446 B; the resolver snippet is one line of 2,573 chars and appears as the longest line in plan-phase, code-review-disposition, review and quick. OpenCode's caps are confirmed from its official source (Read tool: MAX_READ_BYTES 50 KiB, MAX_READ_LINES 2000, MAX_LINE_LENGTH 2000; a
file:prompt part is loaded through the Read tool insession/prompt.ts). A live OpenCode run was not performed here; the command-template@to file-part step was not directly seen in the retrieved source.Root cause: the one-line
gsd_runresolver is the pinned canonical form ingsd-core/workflows/_runtime-launcher.snippet.sh:1(tests/runtime-launcher-parity.test.cjs:2071), and whole workflows are eagerly@-included (commands/gsd/plan-phase.md:39); the only size gates (tests/workflow-size-budget.test.cjs:120-121, XL 98,304 / LARGE 61,440) are sized for Claude, with no OpenCode delivery cap or line-length gate. No recorded decision weighs OpenCode's Read window (Cortex check could not run; CONTEXT.md, docs/adr, closed issues searched, none found).Introduced by: long-standing.
Blast radius: High. All OpenCode (and shared-writer Kilo) installs: plan-phase and execute-phase arrive truncated;
gsd_runis undefined in any workflow delivered through Read.Coupled (must not miss): runtime-launcher parity test, workflow size-budget and emitted-diff ratchet, docs/INVENTORY.md plus manifest regen, install goldens, generated
bin/install.js. Extraction must go to lazily loaded step files (CONTEXT.md RULESET.WORKFLOW_SIZE_BUDGET: eager@-imports do not reduce loaded context).Regression test: for the OpenCode installed tree, every file reachable by an eager
@include is at most 51,200 B and 2,000 lines, and no line in it exceeds 2,000 characters.trek-e commentedon Oct 9, 2026
Agent Brief
Category: bug
Summary: Workflows delivered to OpenCode through its Read tool are cut off, and the
gsd_runresolver is truncated so it cannot define itself.Current behavior: On OpenCode, plan-phase, execute-phase, review and code-review-disposition exceed the 50 KB / 2000-line Read window and arrive partial; the single-line resolver exceeds 2000 characters and is cut, leaving
gsd_runundefined.Desired behavior: Every workflow content that a command or skill loads eagerly arrives complete on OpenCode, and the resolver defines
gsd_runthere, with identical resolution behavior on all other runtimes.Key interfaces: the
gsd_runruntime launcher resolver; the eager workflow includes in commands and skills; the OpenCode (and OpenCode-family) install conversion; the workflow size gates.Acceptance criteria:
Out of scope: raising the existing workflow size tier caps; changing behavior on runtimes without a Read window.