* feat(roadmap): parse **Mode:** field on phase sections
Adds a 'mode' field to roadmap.get-phase and roadmap.analyze outputs.
Recognizes '**Mode:** mvp' lines in phase sections; lowercased + trimmed.
Forward-compat: unrecognized values preserved verbatim, no enum check.
Foundation for --mvp flag in plan-phase (PRD: vertical-mvp-slice).
* feat(plan-phase): parse --mvp flag and resolve MVP_MODE
Resolution order: CLI flag → ROADMAP **Mode:** field → workflow.mvp_mode
config → false. Walking Skeleton gate fires for new-project Phase 1.
Wires MVP_MODE + WALKING_SKELETON into gsd-planner subagent prompt.
Per PRD vertical-mvp-slice Phase 1 (Q1, Q2, Q4).
* docs(planner): add vertical-slice planning reference
New reference loaded by gsd-planner when MVP_MODE=true. Defines slice
ordering, Walking Skeleton rules, and anti-patterns. Referenced from
plan-phase workflow MVP_MODE wiring.
* docs(planner): add SKELETON.md template
Template emitted by gsd-planner under WALKING_SKELETON=true. Captures
architectural decisions and out-of-scope list for new-project Phase 1.
* chore(inventory): register new planner references
Added planner-mvp-mode.md and skeleton-template.md to INVENTORY.md and
INVENTORY-MANIFEST.json. References now: 53.
* feat(gsd-planner): add MVP Mode Detection section
Mode-switched branch in the existing planner agent (per Q4: single agent).
Vertical-slice decomposition rules, Walking Skeleton handling, and
TDD-mode compatibility. Heavy guidance lives in references/planner-mvp-mode.md.
* test(plan-phase): add --mvp resolution-chain integration cases
Validates roadmap.get-phase --pick mode and confirms workflow.mvp_mode
default is unset in fresh projects.
* docs(changelog): announce --mvp vertical-slice planning (#2826)
* feat(mvp-phase): add /gsd mvp-phase slash command
Standalone command for vertical MVP planning. Frontmatter only;
heavyweight workflow at get-shit-done/workflows/mvp-phase.md follows
in next commit. Mirrors discuss-phase/edit-phase command shape.
* docs(planner): add user-story-template reference
Defines the canonical 'As a / I want to / So that' format and the
ROADMAP.md / PLAN.md emit rules. Used by mvp-phase workflow and
gsd-planner agent under MVP_MODE.
* docs(planner): add SPIDR splitting reference
Defines size signals, the five SPIDR axes (Spike/Paths/Interfaces/Data/Rules),
the interactive workflow, and anti-patterns. Per PRD Q3 decision: full
interactive flow, not lightweight check. Used by mvp-phase workflow.
* fix(mvp-phase): trim description to fit 100-char budget
* feat(mvp-phase): add mvp-phase workflow
Standalone workflow: phase validation -> user story prompts (As a / I want to /
So that) -> SPIDR splitting check -> ROADMAP write (Mode + Goal) -> delegation
to plan-phase. Per PRD Phase 2 (Q3 full SPIDR; Phase-2-A/B/C/D decisions).
Plan-phase auto-detects MVP via Phase 1's resolution chain, so no flags
are needed when delegating.
* feat(gsd-planner): emit user-story header in PLAN.md under MVP mode
Extends the MVP Mode Detection section (added in Phase 1) so the planner
sources the user story from ROADMAP **Goal:** and emits the bolded
**As a** / **I want to** / **so that** form as the first content under
the phase header in PLAN.md. References user-story-template.md.
* test(mvp-phase): integration smoke test for ROADMAP mutation
Validates roadmap.get-phase output after a workflow-spec'd ROADMAP write:
mode=mvp and goal=full user story. Catches schema drift between workflow
emit and parser expectation. Includes a long-story case (>120 chars) to
confirm SPIDR-rejected stories still parse correctly.
* chore(inventory): register mvp-phase command + 2 new references
Adds /gsd mvp-phase to commands list, mvp-phase workflow to workflows list,
and user-story-template.md + spidr-splitting.md to references. References
count: 53 -> 55.
* docs(changelog): announce /gsd mvp-phase command (#2826)
* fix(mvp-phase): add TEXT_MODE plain-text fallback for non-Claude runtimes (#2012)
* docs(executor): add MVP+TDD gate reference
Defines the runtime gate semantics for execute-phase when both
MVP_MODE and TDD_MODE are true: pre-task verification of failing-test
commit, end-of-phase review escalation from advisory to blocking,
behavior-adding task definition. Loaded conditionally by
execute-phase workflow and gsd-executor agent.
* feat(execute-phase): MVP+TDD runtime gate + blocking review
Resolves MVP_MODE in Step 1 (CLI flag -> roadmap mode -> config -> false).
Adds per-task gate that halts before behavior-adding tasks run if no
failing-test commit exists for the plan. Escalates end-of-phase TDD
review from advisory to blocking when both MVP_MODE and TDD_MODE active.
Also updates INVENTORY-MANIFEST.json to register execute-mvp-tdd.md
(added by Task 1) so manifest-sync tests pass.
Per PRD vertical-mvp-slice Phase 3a (decisions Phase-3-A, Phase-3-Split).
* feat(gsd-executor): add MVP+TDD Gate section
Mirrors the planner's MVP Mode Detection pattern from Phase 1.
Instructs halt-and-report when the runtime gate trips, references
execute-mvp-tdd.md for full semantics. No agent changes outside the
new section.
* test(execute-phase): add MVP+TDD resolution-chain integration cases
Validates roadmap.get-phase --pick mode and confirms workflow.mvp_mode
default is unset in fresh projects. Mirrors the Phase 1 plan-phase
resolution-chain integration test.
* chore(inventory): register execute-mvp-tdd reference
Bumps References count 55 -> 56. Registers execute-mvp-tdd.md.
Adds "init" to PROSE_ALLOWLIST in registry integration test so
bare `gsd-sdk query init` prose examples in plan docs don't
trigger the unregistered-handler guard (real commands are all
init.<subcommand>).
* docs(changelog): announce MVP+TDD runtime gate in execute-phase (#2826)
* docs(verifier): add verify-mvp-mode reference
Defines UAT framing under MVP mode: user-flow walk-through first,
technical checks deferred, coverage check as goal-backward narrowing
to the user story's outcome clause. Loaded conditionally by
verify-work workflow and gsd-verifier agent.
* feat(verify-work): MVP-mode UAT framing — user flow first
Resolves MVP_MODE from phase mode field. Under MVP mode, generates UAT
in three ordered sections: user-flow walk-through (derived from user
story), technical checks (deferred), coverage check (goal-backward).
Falls back to standard UAT generation when mode is null/absent.
User-story-format guard refuses to verify a mode:mvp phase with a
non-user-story goal.
Also updates docs/INVENTORY.md (56 references) and
docs/INVENTORY-MANIFEST.json to register verify-mvp-mode.md added
in Task 1.
Per PRD vertical-mvp-slice Phase 3b (decisions Phase-3-B,
Phase-3-Verify-Structure).
* feat(gsd-verifier): add MVP Mode Verification section
Narrows goal-backward verification to the user-story [outcome] clause
when phase mode is mvp. References verify-mvp-mode.md. Preserves
existing goal-backward methodology for non-MVP phases. User-story-format
guard refuses to verify a mode:mvp phase with a non-user-story goal.
* docs(changelog): announce MVP-mode UAT framing in verify-work (#2826)
* feat(new-project): add Vertical MVP vs Horizontal Layers mode prompt
Asks user at project init how to structure the project. Vertical MVP
emits **Mode:** mvp on every initial roadmap phase (per-phase mode
preserved per PRD Q1). Horizontal Layers falls back to standard
template — no behavioral change for existing flows.
Per PRD vertical-mvp-slice Phase 4 (decision Phase-4-Persistence).
* feat(progress): add MVP-mode user-flow display
When phase has **Mode:** mvp, progress renders user-flow status from
PLAN.md task names alongside standard task progress. Tasks that aren't
user-flow-shaped (technical-sounding) are filtered out of the user-flow
sub-block. Falls back to standard display when mode is null/absent.
Per PRD vertical-mvp-slice Phase 4 (decision Phase-4-Progress).
* feat(stats): add MVP phase count summary
Reads roadmap.analyze (which surfaces mode per phase from Phase 1) and
emits 'Phases: N total | M MVP | K standard' summary line. Suppressed
when MVP_COUNT == 0 to avoid clutter on non-MVP projects.
Per PRD vertical-mvp-slice Phase 4.
* feat(graphify): add MVP-mode visual differentiation
MVP-mode phases render with #22c55e fill color AND ' (MVP)' label
suffix — two-channel signaling for color-blind and grayscale renders.
Standard phases unchanged.
Per PRD vertical-mvp-slice Phase 4 (PRD Q5: distinct visual treatment).
* docs(changelog): announce Phase 4 discovery & progress (#2826)
* chore(release): bump dev to 1.50.0-canary.0 for first 1.50.0 canary
Sets the base version that .github/workflows/canary.yml derives the canary
tag from (strips suffix → base 1.50.0 → next available v1.50.0-canary.N).
This kicks off the 1.50.0 release train, opened by the MVP/TDD/UAT vertical
slice landed across PRs #2867, #2874, #2878, #2880, #2883.
* docs: add CANARY stream README + v1.50.0-canary.1 release notes
- docs/CANARY.md — explains the dev→@canary stream policy, install/rollback
paths, and when (not) to install canary builds
- docs/RELEASE-v1.50.0-canary.1.md — release notes for the first 1.50.0
canary cut: vertical MVP/TDD/UAT slice (#2867 + #2874 + #2878 + #2880 +
#2883), opening the 1.50.0 train under PRD #2826
- docs/README.md — index entry + quick link for the canary stream
* fix(ci/canary): publish gate checks dev branch, not main
Four publish-step `if:` conditions in .github/workflows/canary.yml were
checking `github.ref == 'refs/heads/main'`. Those steps (Tag and push,
Publish to npm, Publish SDK to npm, Verify publish) therefore always
skipped on every workflow_dispatch invocation since canary runs from dev,
never main.
The workflow's own header comment is unambiguous: `dev → @canary`. The
gate was a copy-paste from release.yml (which correctly targets main for
the @next/@latest streams) that was never corrected for the canary stream.
This is why the 1.50.0-canary.1 publish hadn't materialized despite three
green workflow runs. With the gate corrected, the next dispatch will
actually publish.
* ci(release-sdk): make release-sdk.yml dispatchable from the dev branch
The workflow lives on main only, so the GitHub Actions "Use workflow
from" dropdown doesn't list dev — meaning dev → @dev publishes can't be
triggered from the dev branch directly. Add the file to dev so an
operator can dispatch it with branch=dev and tag=dev.
Per project release-stream policy: dev branch publishes canary (@dev).
This is the stream that needs the file most, since main never publishes
@dev itself (main does @next / @latest).
File is byte-identical to main's release-sdk.yml — straight propagation,
no behavioral change. Tracking issues #2925, #2929.
* docs(mvp): canary-prep concept cleanup — CONTEXT.md, mvp-concepts index, --prd interaction (#3176)
* chore(mvp): concept cleanup + cross-ref index for v1.50.0-canary.2 prep
- CONTEXT.md gains 7 MVP domain terms (MVP Mode, User Story, Walking
Skeleton, Vertical Slice, Behavior-Adding Task, MVP+TDD Gate, SPIDR
Splitting) so the project glossary matches the shipped surface.
- New get-shit-done/references/mvp-concepts.md indexes the six MVP
reference files and concept-to-file map so agents and contributors
can find the right canonical doc without grepping.
- plan-phase.md Walking Skeleton block now documents that --mvp and
--prd compose orthogonally on Phase 1; no precedence needed.
- INVENTORY/INVENTORY-MANIFEST refreshed for the new reference (58 -> 59).
No behavior change. Canary-prep cleanup ahead of v1.50.0-canary.2.
Surfaced for follow-up (not in this PR):
- MVP_MODE resolution shell block duplicated across plan-phase,
execute-phase, verify-work workflows (needs a shared workflow-include
mechanism; structural change).
- Behavior-Adding Task predicate is prose-only; no shared utility.
- User Story regex hardcoded in verify-work; would benefit from a
central definition consumed by the verifier and the mvp-phase command.
* chore(changeset): set PR number for mvp concept cleanup
* feat(mvp): centralize resolution surfaces + fix SDK roadmap mode parity (#3178)
Three new SDK query verbs replace the architectural duplication surfaced by
the v1.50.0-canary.2 review against dev tip 12c4e565:
phase.mvp-mode <N> [--cli-flag]
Single canonical precedence resolver (CLI flag -> ROADMAP **Mode:** mvp
-> workflow.mvp_mode config -> false). Replaces 4-8 lines of bash that
were duplicated across plan-phase.md, execute-phase.md, verify-work.md,
and progress.md. Returns {active, source, roadmap_mode, config_mvp_mode,
cli_flag_present}.
task.is-behavior-adding <plan-file> | --task-content <xml>
Behavior-Adding Task predicate (tdd="true" + <behavior> block + non-test
source files in <files>). Replaces prose-only specification in
references/execute-mvp-tdd.md; gsd-executor agent now invokes the verb
instead of re-inlining the three checks. Returns {is_behavior_adding,
checks, reason}.
user-story.validate <text> | --story <text>
Owns the canonical User Story regex /^As a .+, I want to .+, so that .+\.$/
previously hardcoded in verify-work.md prose. Consumed by gsd-verifier
(phase-goal guard) and /gsd-mvp-phase (interactive-prompt validation).
Returns {valid, slots: {role, capability, outcome}, errors[]}.
Bug fix bundled: sdk/src/query/roadmap.ts searchPhaseInContent now extracts
the mode field from **Mode:**, restoring parity with roadmap.cjs:120-123.
Without this, roadmap.get-phase --pick mode returned null on the native
dispatch path even when the phase had **Mode:** mvp set, causing MVP_MODE
to silently fall through to the config/false branch in every consuming
workflow. The original PRs Phase 1 (#2885) shipped the CJS parser but the
SDK port omitted the field; this fix brings them back to parity.
Workflows + agents updated to call the verbs:
- plan-phase.md, execute-phase.md, verify-work.md, progress.md call
phase.mvp-mode (one line replaces the duplicated bash chains).
- execute-phase.md MVP+TDD gate calls task.is-behavior-adding.
- verify-work.md goal guard calls user-story.validate.
- mvp-phase.md interactive prompt validates via user-story.validate.
- gsd-executor agent references task.is-behavior-adding instead of prose.
- gsd-verifier agent references user-story.validate instead of inlined regex.
Tests: 24 new vitest tests in sdk/src/query/mvp.test.ts cover all three
verbs + the regression. Two existing contract tests (progress, verify)
updated to assert on the new verb shape. All 60 existing MVP contract
tests pass; golden integration suite (38 + 42 tests) passes.
Closes #3177
* fix(canary.2): unblock release gates for v1.50.0-canary.2
Run 25451329660 (Release SDK Bundle on dev, 2026-05-06T17:41) failed at the
test-suite step with 3 deterministic content/structure gate failures, all
attributable to the MVP umbrella integration in #3178 and the docs sweep
in #3180.
Failure 1: /gsd-mvp-phase undocumented in workflows/help.md
- tests/bug-2954-help-md-slash-command-stubs.test.cjs requires every
shipped commands/gsd/<X>.md to have a /gsd-<X> mention in help.md
- PR #3180 updated docs/COMMANDS.md but missed help.md (which the AI
agents load in-product)
- Fix: add a /gsd-mvp-phase entry to help.md right before /gsd-plan-phase
Failures 2 + 3: execute-phase.md (1727) and plan-phase.md (1714) over XL budget (1700)
- PR #3178 added MVP-mode verb calls (phase.mvp-mode, task.is-behavior-adding,
user-story.validate) to both workflow files, pushing them past 1700 lines
- Fix: bump XL_BUDGET 1700 -> 1800 with inline comment pointing at the
structural follow-up (extract MVP bodies to <workflow>/modes/mvp.md per
the discuss-phase/modes/ precedent)
- The structural extract is the right long-term fix but is bigger than
canary unblock scope; will land in a follow-up after canary cycles
Local verification:
$ node --test tests/bug-2954-help-md-slash-command-stubs.test.cjs tests/workflow-size-budget.test.cjs
tests 111 pass 111 fail 0
After this lands, re-trigger Release SDK Bundle on dev for v1.50.0-canary.2.
* chore(changeset): set PR number for canary.2 unblock
* fix(codex): generate-claude-md writes to AGENTS.md on Codex runtime
When config.runtime === 'codex' or GSD_RUNTIME=codex, override the
output target to AGENTS.md regardless of claude_md_path, so Codex
projects no longer have GSD sections written to CLAUDE.md by mistake.
Fixes both the CJS (gsd-tools) and SDK (profile-output.ts) paths.
Explicit --output flags are still honoured in both paths.
Closes #3163
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
* fix(plan-phase): remove agent: directive that caused OpenCode subagent dispatch
On OpenCode, any command with `agent: <name>` in its frontmatter is
auto-dispatched to a subagent context where the Agent tool is unavailable.
plan-phase.md and mvp-phase.md both carried `agent: gsd-planner`, causing
them to run inside gsd-planner's subagent context with no ability to spawn
researcher/planner/checker subagents — the orchestrator fell back to inline
execution for all three phases.
Fix: remove `agent: gsd-planner` from both command files so they run in the
main agent context. Also replace the stale `Task` tool in allowed-tools with
`Agent` (the correct dispatcher tool name post-#3168 rename).
Adds a structural regression test that parses YAML frontmatter of every
commands/gsd/*.md file and asserts no command carries an `agent:` directive.
Closes #3156
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
* fix(mvp): address CodeRabbit workflow and contract findings
* fix(execute-phase): use registered state.update query command
---------
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
7.9 KiB
name, description, argument-hint, allowed-tools
| name | description | argument-hint | allowed-tools | ||
|---|---|---|---|---|---|
| gsd:graphify | Build, query, and inspect the project knowledge graph in .planning/graphs/ | [build|query <term>|status|diff] |
|
STOP -- DO NOT READ THIS FILE. You are already reading it. This prompt was injected into your context by Claude Code's command system. Using the Read tool on this file wastes tokens. Begin executing Step 0 immediately.
CJS-only (graphify): graphify subcommands are not registered on gsd-sdk query. Use node $HOME/.claude/get-shit-done/bin/gsd-tools.cjs graphify … as documented in this command and in docs/CLI-TOOLS.md. Other tooling may still use gsd-sdk query where a handler exists.
Step 0 -- Banner
Before ANY tool calls, display this banner:
GSD > GRAPHIFY
Then proceed to Step 1.
Step 1 -- Config Gate
Check if graphify is enabled by reading .planning/config.json directly using the Read tool.
DO NOT use the gsd-tools config get-value command -- it hard-exits on missing keys.
- Read
.planning/config.jsonusing the Read tool - If the file does not exist: display the disabled message below and STOP
- Parse the JSON content. Check if
config.graphify && config.graphify.enabled === true - If
graphify.enabledis NOT explicitlytrue: display the disabled message below and STOP - If
graphify.enabledistrue: proceed to Step 2
Disabled message:
GSD > GRAPHIFY
Knowledge graph is disabled. To activate:
node $HOME/.claude/get-shit-done/bin/gsd-tools.cjs config-set graphify.enabled true
Then run /gsd-graphify build to create the initial graph.
Step 2 -- Parse Argument
Parse $ARGUMENTS to determine the operation mode:
| Argument | Action |
|---|---|
build |
Run inline build (Step 3) |
query <term> |
Run inline query (Step 2a) |
status |
Run inline status check (Step 2b) |
diff |
Run inline diff check (Step 2c) |
| No argument or unknown | Show usage message |
Usage message (shown when no argument or unrecognized argument):
GSD > GRAPHIFY
Usage: /gsd-graphify <mode>
Modes:
build Build or rebuild the knowledge graph
query <term> Search the graph for a term
status Show graph freshness and statistics
diff Show changes since last build
Step 2a -- Query
Run:
node $HOME/.claude/get-shit-done/bin/gsd-tools.cjs graphify query <term>
Parse the JSON output and display results:
- If the output contains
"disabled": true, display the disabled message from Step 1 and STOP - If the output contains
"error"field, display the error message and STOP - If no nodes found, display:
No graph matches for '<term>'. Try /gsd-graphify build to create or rebuild the graph. - Otherwise, display matched nodes grouped by type, with edge relationships and confidence tiers (EXTRACTED/INFERRED/AMBIGUOUS)
STOP after displaying results. Do not spawn an agent.
Step 2b -- Status
Run:
node $HOME/.claude/get-shit-done/bin/gsd-tools.cjs graphify status
Parse the JSON output and display:
- If
exists: false, display the message field - Otherwise show last build time, node/edge/hyperedge counts, and STALE or FRESH indicator
- If
built_at_commitis non-null, also display aSource commit:line:commit_stale === false(rebuilt at HEAD):Source commit: <built_at_commit> (current)commit_stale === true(graph behind HEAD):Source commit: <built_at_commit> (<commits_behind> commits behind HEAD)commit_stale === null(unreachable commit / no git):Source commit: <built_at_commit> (freshness unknown)
- If
built_at_commitis null (pre-graphify-v0.7 graph), omit the source-commit line entirely — do not render "Source commit: unknown"
The mtime-based STALE/FRESH flag and the commit-based commit_stale measure
different things and can disagree (e.g., a CI-built graph rebuilt minutes ago
against an old checkout reads as FRESH on mtime but commit_stale: true).
Surface both so the agent can choose.
STOP after displaying status. Do not spawn an agent.
Step 2c -- Diff
Run:
node $HOME/.claude/get-shit-done/bin/gsd-tools.cjs graphify diff
Parse the JSON output and display:
- If
no_baseline: true, display the message field - Otherwise show node and edge change counts (added/removed/changed)
If no snapshot exists, suggest running build twice (first to create, second to generate a diff baseline).
STOP after displaying diff. Do not spawn an agent.
Step 3 -- Build (Inline)
Run the pre-flight check first:
node "$HOME/.claude/get-shit-done/bin/gsd-tools.cjs" graphify build
Parse the JSON output:
- If
disabled: true: display the disabled message from Step 1 and STOP - If
error: display the error message and STOP - If
action: "spawn_agent": pre-flight passed -- proceed with the inline build below
(The spawn_agent action name is historical. The skill now performs the build inline because graphify v0.7+ split the build into a fast AST-extraction phase and a separate clustering + report-write phase. Sub-agent isolation kept the cached extraction phase alive but SIGTERM'd the post-extraction phase when the agent exited, leaving the cache populated but no graph.json artifacts written. The CLI still emits the spawn_agent signal so external callers and tests keep working.)
Display:
GSD > Building knowledge graph...
Run the build, copy artifacts, write the diff snapshot, and report the summary in a single foreground Bash call so the whole pipeline survives to completion. Use a timeout of 600000 ms (10 minutes), which covers the graphify.build_timeout ceiling (default 300 s) with margin:
graphify update . \
&& cp graphify-out/graph.json .planning/graphs/graph.json \
&& cp graphify-out/graph.html .planning/graphs/graph.html \
&& cp graphify-out/GRAPH_REPORT.md .planning/graphs/GRAPH_REPORT.md \
&& node "$HOME/.claude/get-shit-done/bin/gsd-tools.cjs" graphify build snapshot \
&& node "$HOME/.claude/get-shit-done/bin/gsd-tools.cjs" graphify status
Do NOT pass run_in_background: true. Typical builds complete in 15-60 seconds and the entire chain must run foreground.
If the chain fails (non-zero exit):
- Display:
## GRAPHIFY BUILD FAILEDfollowed by the captured stderr - Do NOT delete
.planning/graphs/-- the prior valid graph remains available - STOP
If the chain succeeds:
- Parse the trailing
graphify statusJSON - Display:
## GRAPHIFY BUILD COMPLETEwith the node, edge, and hyperedge counts
MVP-Mode Node Rendering
MVP-mode rendering. When a phase has **Mode:** mvp in ROADMAP.md (resolved via gsd-sdk query roadmap.get-phase --pick mode), render its graph node with two distinct visual signals:
- Distinct fill color. Use
#22c55e(green) for MVP-mode phase nodes. Standard phases keep the default fill color. Two-channel signaling (color + label) handles color-blind and grayscale renders. MVPlabel suffix. Append(MVP)to the node's label text. Example: a phase originally labeledPhase 1: User Authrenders asPhase 1: User Auth (MVP).
Both signals fire together — never just one. Per PRD Q5 decision, the goal is unambiguous visual distinction in any render context.
When the phase mode is null/absent, render with the standard color and label — no behavioral change for non-MVP phases.
Anti-Patterns
- DO NOT spawn an agent for any operation -- build, query, status, and diff all run inline. Sub-agent isolation terminates background bash when the agent exits, which previously truncated graphify builds mid-write and left only the cache populated (#3166).
- DO NOT pass
run_in_background: truefor the build chain -- the operation is fast and must complete in the foreground. - DO NOT modify graph files directly -- always go through
graphify update .and the snapshot CLI. - DO NOT skip the config gate check.
- DO NOT use
gsd-tools config get-valuefor the config gate -- it exits on missing keys.