Files
msd-core/docs
Tom Boucher aad04f4e9a docs(#4400): ADR-4139 — the compact-content seam (#4410)
* docs(#4400): ADR-4139 — the compact-content seam

Phase 0 of epic #4139. Locks the design before any code lands.

#4139's stated mechanism cannot reach the stream it exists for: 58 of 72
shipped commands deliver their whole workflow file through an eager
@-include, which the host expands before any project config is in context.
An in-content gate is evaluated after those bytes are already paid.

The ADR declines the obvious fix (convert the 58 execution_context blocks
to runtime Reads) because that removes the host guarantee for every user,
not only opted-in ones — a global install shares one skill tree, so an
@-include cannot be conditional. It instead keeps every @-include exactly
where it is and splits what sits behind them: the canonical path becomes a
runnable spine, elaborations move to a sibling detail file read at runtime.
A missed Read then degrades to "runs correctly with fewer tokens", never to
"runs with no instructions".

Also records: the rename to workflow.compact_content, the re-pitch onto
ADR-1610's context-rot argument rather than the cost argument ADR-1610
discounts, partition-not-duplication (which dissolves the dual-maintenance
cost the Feature Review called disqualifying), the guard-scope and
NEW_FILE_CAP mapping for the new subtree, and an argued reconciliation of
the acceptance criteria this design does not meet literally.

Corrects ADR-3646 §Context: it cites #3647 as open; #3647 closed
2026-09-01 as a duplicate of #3606. ADR-3646's Decision is unaffected —
it explicitly disclaimed any dependence on #3647's state. The residual
prose-dispatch variance named in #3647's own closure thread is unresolved,
and this ADR routes around it rather than assuming it away.

Refs #4139
Closes #4400

* docs(#4400): fold the two orthogonal review findings into ADR-4139

Code review (isolated context) and security review (isolated context) both
returned findings. Fixed here rather than carried.

Critical, from code review: the ADR repeated earlier research's claim that
discuss-phase, manager and pause-work all reach a workflow by runtime Read.
manager and pause-work carry plain eager @-includes and are inside the 58,
not outside. discuss-phase is the only precedent, and it is one file. The
Open Questions section is corrected with it.

The NEW_FILE_CAP mapping was wrong in a way that changes the layout. It
lives at tests/helpers/emitted-diff.cjs:96, not in workflow-size-budget,
and its own doc comment records that it is a hard cap, not ack-able, and
NOT tier-exemptible -- the pre-#2724 test-file version was. So a single
detail.md holding plan-phase.md's elaborations is blocked outright with no
exemption path. Detail content is now one or more parts under
workflows/<name>/detail/, each below the cap, named by the spine in the
dispatch-table shape discuss-phase.md already uses.

commit-files-pathspec is in scope and earlier research called it
irrelevant. Per CONTRIBUTING.md:1164-1170 it sweeps every .md under
gsd-core/workflows/ for unscoped commit-seam invocations. Added to the
guard table.

Two byte figures were inherited rather than measured, against this ADR's
own evidence note. Templates and agents re-measured; the table now carries
the method and the exact numbers.

From security review: "a spine that has shed a protected-content marker
fails" never defined what a marker was, leaving the strongest check in the
set resting on a prose-category judgment. Protection is now a literal
greppable sentinel in the existing gsd: comment namespace, and the guard
rule has no discretion in it. Also added: an explicit statement that the
detail path is never user- or project-supplied and cannot be shadowed by a
project-local file, and an exact-version pin commitment for gpt-tokenizer.

Code review also found a real hole in the central fail-safe argument:
spine sufficiency is verified once at split time and never again, so
load-bearing procedural text carrying no sentinel could later drift into a
detail part with every check green. Sufficiency is not machine-decidable,
so a fifth ongoing check is added -- a spine that loses lines which
reappear in its parts fails unless the PR declares the boundary move. The
ADR now states plainly that this is authoring discipline with a forced
checkpoint, not a structural invariant, and that the partition relocates
the Feature Review's cost rather than fully eliminating it.

Refs #4139
Refs #4400

---------

Co-authored-by: sim <sim@local>
2026-09-06 12:24:33 -04:00
..

GSD Core documentation

Documentation is organised into four quadrants: tutorials help you learn by doing, how-to guides solve specific tasks, reference states authoritative facts, and explanation explores concepts and design decisions.

Language versions: English · Português (pt-BR) · 日本語 · 简体中文


Tutorials


How-to guides


Reference

  • Commands — every command with flags and examples
  • Configuration — full config schema, model profiles, git branching strategies
  • CLI tools — gsd-tools.cjs programmatic API for workflows and agents
  • JSON error mode — gsd-tools failure channels: faults (stderr, exit 1) vs degraded results (stdout, exit 0), and the reason-code taxonomy
  • Features — complete feature index
  • Inventory — installed skills and surface map
  • STATE.md schema — field-by-field reference for .planning/STATE.md
  • CONTEXT.md schema — field-by-field reference for .planning/phases/<N>/CONTEXT.md
  • PLAN.md schema — field-by-field reference for .planning/phases/<N>/PLAN.md
  • Planning artifacts — all .planning/ files and their roles
  • Review and verification capabilities — code review, security, and Nyquist capability ownership and hook contracts
  • Gate predicates — canonical specification of the phase-gate predicate vocabulary
  • Capability matrix — generated catalogue of every capability's role, tier, extension points, hook kinds, and engines.gsd
  • Exit code reference — generated catalogue of every registered process exit code, its name, meaning, and owning module, plus the reserved bands and the v1/v2 exit contract
  • Capability manifest — the full capability.json schema and validation rules
  • gsd capability command — install / update / remove / list reference for third-party capabilities
  • Workflow fragments — in-file <!-- gsd:section --> marker grammar for fragmentizing workflow markdown at emission time
  • Reviewer Lane Registry — generated catalogue of third-party reviewer lanes, with their flags, transport, and install commands

Explanation