refactor: hard-fork GSD -> MSD (Make Software Done)
Mechanical rename produced by scripts/msd-rename.cjs: gsd/Gsd/GSD -> msd/Msd/MSD across contents and paths, upstream package/repo coordinates -> @golem15/msd-core and golem15com/msd-core. Deep links into upstream history, sibling upstream packages, the GSD-2 import feature, CHANGELOG.md and .changeset/ are kept as-is. Hand edits on top: MSD block-letter banner and logos, LICENSE copyright line, package/plugin identity, regenerated lockfile, install-tree fixtures, derived registries and benchmark baseline; migration checksum baseline re-locked (MSD keeps its own install state, so no install had applied the old sums); sort-order and regex-escaped expectations in tests adjusted.
This commit is contained in:
Jakub Zych
@@ -6,7 +6,7 @@ group: Context Engineering Features
|
||||
|
||||
**Config:** `workflow.compact_content: false`
|
||||
|
||||
**Purpose:** Per-project opt-in to token-minimized variants of GSD's own shipped prompt
|
||||
**Purpose:** Per-project opt-in to token-minimized variants of MSD's own shipped prompt
|
||||
content — workflow instructions, planning-artifact templates, and non-Claude agent-persona
|
||||
payloads — so the always-loaded instruction window leaves more of the model's attention on
|
||||
the developer's own code (ADR-4139 Decision 2: finite attention, not per-invocation price,
|
||||
@@ -30,8 +30,8 @@ it did before this feature existed.
|
||||
- REQ-COMPACT-05: An agent with no compact persona variant registered MUST fall back to its
|
||||
canonical persona and disclose the fallback inside the served payload, never fail or serve
|
||||
nothing
|
||||
- REQ-COMPACT-06: `/gsd-new-project` MUST ask the question and persist the answer;
|
||||
`/gsd-settings` and `/gsd-config` MUST toggle it on an already-initialized project
|
||||
- REQ-COMPACT-06: `/msd-new-project` MUST ask the question and persist the answer;
|
||||
`/msd-settings` and `/msd-config` MUST toggle it on an already-initialized project
|
||||
|
||||
**Config:**
|
||||
| Setting | Type | Default | Description |
|
||||
|
||||
@@ -2,4 +2,4 @@
|
||||
group: Infrastructure Features
|
||||
---
|
||||
|
||||
> **Looking for a third-party add-on instead?** See the [GSD Community Capability Registry & EoS Registry](registries/README.md) — non-endorsing discoverability catalogs for community-contributed Capabilities and EoS host integrations.
|
||||
> **Looking for a third-party add-on instead?** See the [MSD Community Capability Registry & EoS Registry](registries/README.md) — non-endorsing discoverability catalogs for community-contributed Capabilities and EoS host integrations.
|
||||
|
||||
@@ -2,4 +2,4 @@
|
||||
group: v1.7.0 Features
|
||||
---
|
||||
|
||||
> These are features new to **@opengsd/gsd-core 1.7.0** (the current release line: 1.0.0 → 1.2.0 → … → 1.6.1 → 1.7.0). The preceding `v1.27`–`v1.43.0` sections use the retired get-shit-done-cc / get-shit-done-redux feature numbering and are not gsd-core releases — see [Legacy Release Notes](RELEASE-NOTES-LEGACY.md).
|
||||
> These are features new to **@golem15/msd-core 1.7.0** (the current release line: 1.0.0 → 1.2.0 → … → 1.6.1 → 1.7.0). The preceding `v1.27`–`v1.43.0` sections use the retired get-shit-done-cc / get-shit-done-redux feature numbering and are not msd-core releases — see [Legacy Release Notes](RELEASE-NOTES-LEGACY.md).
|
||||
|
||||
@@ -10,4 +10,4 @@ group: v1.34.0 Features
|
||||
|
||||
**Requirements:**
|
||||
- REQ-ADAPTIVE-01: `adaptive` preset MUST assign model tiers based on agent role (planner → quality tier, executor → balanced tier, etc.)
|
||||
- REQ-ADAPTIVE-02: `adaptive` MUST be selectable via `/gsd-config --profile adaptive`
|
||||
- REQ-ADAPTIVE-02: `adaptive` MUST be selectable via `/msd-config --profile adaptive`
|
||||
|
||||
@@ -7,7 +7,7 @@ group: v1.37.0 Features
|
||||
**Purpose:** Keep agent prompt files lean with tiered line-count limits enforced in CI. Oversized agents are caught before they bloat context windows in production.
|
||||
|
||||
**Requirements:**
|
||||
- REQ-BUDGET-01: `agents/gsd-*.md` files are classified into three tiers: XL (≤ 1 600 lines), Large (≤ 1 000 lines), Default (≤ 500 lines)
|
||||
- REQ-BUDGET-01: `agents/msd-*.md` files are classified into three tiers: XL (≤ 1 600 lines), Large (≤ 1 000 lines), Default (≤ 500 lines)
|
||||
- REQ-BUDGET-02: Tier assignment is declared in the file's YAML frontmatter (`size: xl | large | default`)
|
||||
- REQ-BUDGET-03: `tests/agent-size-budget.test.cjs` enforces limits and fails CI on violation
|
||||
- REQ-BUDGET-04: Files without a `size` frontmatter key default to the Default (500-line) limit
|
||||
|
||||
@@ -4,7 +4,7 @@ title: AI Eval Review
|
||||
group: v1.35.0 Features
|
||||
---
|
||||
|
||||
**Command:** `/gsd-eval-review [N]`
|
||||
**Command:** `/msd-eval-review [N]`
|
||||
|
||||
**Purpose:** Retroactively audit an executed AI phase's evaluation coverage against the `AI-SPEC.md` plan. Identifies gaps between planned and implemented evaluation before the phase is closed.
|
||||
|
||||
|
||||
@@ -4,7 +4,7 @@ title: AI Integration Phase Wizard
|
||||
group: v1.35.0 Features
|
||||
---
|
||||
|
||||
**Command:** `/gsd-ai-integration-phase [N]`
|
||||
**Command:** `/msd-ai-integration-phase [N]`
|
||||
|
||||
**Purpose:** Guide developers through selecting, integrating, and planning evaluation for AI/LLM capabilities in a project phase. Produces a structured `AI-SPEC.md` that feeds into planning and verification.
|
||||
|
||||
|
||||
@@ -4,7 +4,7 @@ title: Anti-Pattern Severity Levels
|
||||
group: v1.32 Features
|
||||
---
|
||||
|
||||
**Part of:** `/gsd-resume-work`
|
||||
**Part of:** `/msd-resume-work`
|
||||
|
||||
**Purpose:** Mandatory understanding checks at resume with severity-based anti-pattern enforcement.
|
||||
|
||||
|
||||
@@ -4,7 +4,7 @@ title: API-Coverage Gate
|
||||
group: v1.7.0 Features
|
||||
---
|
||||
|
||||
**Command:** `/gsd-verify-work`
|
||||
**Command:** `/msd-verify-work`
|
||||
|
||||
**Purpose:** A phase that integrates an external API, SDK, or service can no longer seal verification without a decided coverage matrix (#1562).
|
||||
|
||||
|
||||
@@ -4,7 +4,7 @@ title: Architectural Responsibility Mapping
|
||||
group: v1.36.0 Features
|
||||
---
|
||||
|
||||
**Command:** `/gsd-plan-phase` (enhanced research step)
|
||||
**Command:** `/msd-plan-phase` (enhanced research step)
|
||||
|
||||
**Purpose:** During phase research, the phase-researcher now maps each capability to its architectural tier owner (browser, frontend server, API, CDN/static, database). The planner cross-references tasks against this map, and the plan-checker enforces tier compliance as Dimension 7c.
|
||||
|
||||
|
||||
@@ -4,9 +4,9 @@ title: Archive Quick Tasks at Milestone Close
|
||||
group: v1.7.0 Features
|
||||
---
|
||||
|
||||
**Command:** `/gsd-complete-milestone` (forward path), `/gsd-cleanup` (retroactive path), `gsd-tools milestone complete --archive-quick` / `gsd-tools milestone archive-quick <version>` (#2142)
|
||||
**Command:** `/msd-complete-milestone` (forward path), `/msd-cleanup` (retroactive path), `msd-tools milestone complete --archive-quick` / `msd-tools milestone archive-quick <version>` (#2142)
|
||||
|
||||
**Behavior:** `.planning/quick/` otherwise accumulates one directory per `/gsd-quick` task forever. `/gsd-complete-milestone` now offers a Yes/Skip prompt — when accepted, it moves every directory under `.planning/quick/` into `.planning/milestones/<version>-quick/`, (re)writes that archive directory's `README.md` (an index built by scanning the archive directory, one entry per task, linked to its `SUMMARY.md` when one exists), and clears the data rows of `STATE.md`'s `### Quick Tasks Completed` table while preserving its header and detected column variant. `/gsd-cleanup` offers the same archival retroactively, for milestones that were already closed before their quick tasks were swept, via the narrower `milestone archive-quick <version>` command — identical move/index/reset behavior, but without touching `ROADMAP.md`, `REQUIREMENTS.md`, `MILESTONES.md`, or milestone-completion guards, so it can be re-run safely against an already-completed milestone.
|
||||
**Behavior:** `.planning/quick/` otherwise accumulates one directory per `/msd-quick` task forever. `/msd-complete-milestone` now offers a Yes/Skip prompt — when accepted, it moves every directory under `.planning/quick/` into `.planning/milestones/<version>-quick/`, (re)writes that archive directory's `README.md` (an index built by scanning the archive directory, one entry per task, linked to its `SUMMARY.md` when one exists), and clears the data rows of `STATE.md`'s `### Quick Tasks Completed` table while preserving its header and detected column variant. `/msd-cleanup` offers the same archival retroactively, for milestones that were already closed before their quick tasks were swept, via the narrower `milestone archive-quick <version>` command — identical move/index/reset behavior, but without touching `ROADMAP.md`, `REQUIREMENTS.md`, `MILESTONES.md`, or milestone-completion guards, so it can be re-run safely against an already-completed milestone.
|
||||
|
||||
**Why opt-in.** Phase-directory archival is default-ON (#1871) — omitting a phase directory from an archive would silently leave stale execution history in the way of the next milestone's roadmap. Quick tasks carry no such downstream conflict, so archival here defaults OFF: a user who never passes `--archive-quick` sees zero behavior change. This is a deliberate asymmetry with phase archival, not an oversight.
|
||||
|
||||
@@ -16,7 +16,7 @@ group: v1.7.0 Features
|
||||
|
||||
**Known limits:**
|
||||
- No per-milestone provenance — bucket-all is the only option (see above).
|
||||
- A `### Quick Tasks Completed` table whose columns match neither registered variant (with/without a Status column) is left untouched with a warning rather than reset, since clearing it would risk destroying rows under a schema GSD doesn't recognize.
|
||||
- A `STATE.md` with no `### Quick Tasks Completed` section at all is a normal, silent no-op for the reset step — the section is created lazily by `/gsd-quick`, not present in the project template.
|
||||
- A `### Quick Tasks Completed` table whose columns match neither registered variant (with/without a Status column) is left untouched with a warning rather than reset, since clearing it would risk destroying rows under a schema MSD doesn't recognize.
|
||||
- A `STATE.md` with no `### Quick Tasks Completed` section at all is a normal, silent no-op for the reset step — the section is created lazily by `/msd-quick`, not present in the project template.
|
||||
|
||||
See [Archiving quick tasks](how-to/handle-quick-and-fast-tasks.md#archiving-quick-tasks) for the full walkthrough.
|
||||
|
||||
@@ -4,7 +4,7 @@ title: Assumptions Discussion Mode
|
||||
group: v1.28 Features
|
||||
---
|
||||
|
||||
**Command:** `/gsd-discuss-phase` with `workflow.discuss_mode: 'assumptions'`
|
||||
**Command:** `/msd-discuss-phase` with `workflow.discuss_mode: 'assumptions'`
|
||||
|
||||
**Purpose:** Replace interview-style questioning with codebase-first assumption analysis.
|
||||
|
||||
|
||||
@@ -4,7 +4,7 @@ title: Auto-Advance (Next)
|
||||
group: Planning Features
|
||||
---
|
||||
|
||||
**Command:** `/gsd-progress --next`
|
||||
**Command:** `/msd-progress --next`
|
||||
|
||||
**Purpose:** Automatically detect current project state and advance to the next logical workflow step, eliminating the need to remember which phase/step you're on.
|
||||
|
||||
@@ -12,15 +12,15 @@ group: Planning Features
|
||||
- REQ-NEXT-01: System MUST read STATE.md, ROADMAP.md, and phase directories to determine current position
|
||||
- REQ-NEXT-02: System MUST detect whether discuss, plan, execute, or verify is needed
|
||||
- REQ-NEXT-03: System MUST invoke the correct command automatically
|
||||
- REQ-NEXT-04: System MUST suggest `/gsd-new-project` if no project exists
|
||||
- REQ-NEXT-05: System MUST suggest `/gsd-complete-milestone` when all phases are complete
|
||||
- REQ-NEXT-04: System MUST suggest `/msd-new-project` if no project exists
|
||||
- REQ-NEXT-05: System MUST suggest `/msd-complete-milestone` when all phases are complete
|
||||
|
||||
**State Detection Logic:**
|
||||
| State | Action |
|
||||
|-------|--------|
|
||||
| No `.planning/` directory | Suggest `/gsd-new-project` |
|
||||
| Phase has no CONTEXT.md | Run `/gsd-discuss-phase` |
|
||||
| Phase has no PLAN.md files | Run `/gsd-plan-phase` |
|
||||
| Phase has plans but no SUMMARY.md | Run `/gsd-execute-phase` |
|
||||
| Phase executed but no VERIFICATION.md | Run `/gsd-verify-work` |
|
||||
| All phases complete | Suggest `/gsd-complete-milestone` |
|
||||
| No `.planning/` directory | Suggest `/msd-new-project` |
|
||||
| Phase has no CONTEXT.md | Run `/msd-discuss-phase` |
|
||||
| Phase has no PLAN.md files | Run `/msd-plan-phase` |
|
||||
| Phase has plans but no SUMMARY.md | Run `/msd-execute-phase` |
|
||||
| Phase executed but no VERIFICATION.md | Run `/msd-verify-work` |
|
||||
| All phases complete | Suggest `/msd-complete-milestone` |
|
||||
|
||||
@@ -4,7 +4,7 @@ title: Autonomous Audit-to-Fix
|
||||
group: v1.34.0 Features
|
||||
---
|
||||
|
||||
**Command:** `/gsd-audit-fix [--source <audit>] [--severity high|medium|all] [--max N] [--dry-run]`
|
||||
**Command:** `/msd-audit-fix [--source <audit>] [--severity high|medium|all] [--max N] [--dry-run]`
|
||||
|
||||
**Purpose:** End-to-end pipeline that runs an audit, classifies findings as auto-fixable vs. manual-only, then autonomously fixes auto-fixable issues with test verification and atomic commits.
|
||||
|
||||
|
||||
@@ -4,7 +4,7 @@ title: Autonomous `--interactive` Flag
|
||||
group: v1.32 Features
|
||||
---
|
||||
|
||||
**Flag:** `/gsd-autonomous --interactive`
|
||||
**Flag:** `/msd-autonomous --interactive`
|
||||
|
||||
**Purpose:** Lean-context autonomous mode that keeps discuss-phase interactive (user answers questions) while dispatching plan and execute as background agents on runtimes that support nested background dispatch; on Claude Code, plan and execute run inline to preserve worktree isolation and independent verification.
|
||||
|
||||
|
||||
@@ -4,7 +4,7 @@ title: Autonomous Mode
|
||||
group: Planning Features
|
||||
---
|
||||
|
||||
**Command:** `/gsd-autonomous [--from N]`
|
||||
**Command:** `/msd-autonomous [--from N]`
|
||||
|
||||
**Purpose:** Run all remaining phases autonomously — discuss → plan → execute per phase.
|
||||
|
||||
|
||||
@@ -4,7 +4,7 @@ title: Autonomous `--to N` Flag
|
||||
group: v1.32 Features
|
||||
---
|
||||
|
||||
**Flag:** `/gsd-autonomous --to N`
|
||||
**Flag:** `/msd-autonomous --to N`
|
||||
|
||||
**Purpose:** Stop autonomous execution after completing a specific phase, allowing partial autonomous runs.
|
||||
|
||||
|
||||
@@ -4,18 +4,18 @@ title: Backlog Parking Lot
|
||||
group: v1.27 Features
|
||||
---
|
||||
|
||||
**Commands:** `/gsd-capture --backlog <description>`, `/gsd-review-backlog`, `/gsd-capture --seed <idea>`, `/gsd-capture --list-seeds [status]`
|
||||
**Commands:** `/msd-capture --backlog <description>`, `/msd-review-backlog`, `/msd-capture --seed <idea>`, `/msd-capture --list-seeds [status]`
|
||||
|
||||
**Purpose:** Capture ideas that aren't ready for active planning. Backlog items use 999.x numbering to stay outside the active phase sequence. Seeds are forward-looking ideas with trigger conditions that surface automatically at the right milestone. `--list-seeds` provides a read-only audit of all parked seeds (with optional status filter) without waiting for the next milestone.
|
||||
|
||||
**Requirements:**
|
||||
- REQ-BACKLOG-01: Backlog items MUST use 999.x numbering to stay outside active phase sequence
|
||||
- REQ-BACKLOG-02: Phase directories MUST be created immediately so `/gsd-discuss-phase` and `/gsd-plan-phase` work on them
|
||||
- REQ-BACKLOG-03: `/gsd-review-backlog` MUST support promote, keep, and remove actions per item
|
||||
- REQ-BACKLOG-02: Phase directories MUST be created immediately so `/msd-discuss-phase` and `/msd-plan-phase` work on them
|
||||
- REQ-BACKLOG-03: `/msd-review-backlog` MUST support promote, keep, and remove actions per item
|
||||
- REQ-BACKLOG-04: Promoted items MUST be renumbered into the active milestone sequence
|
||||
- REQ-SEED-01: Seeds MUST capture the full WHY and WHEN to surface conditions
|
||||
- REQ-SEED-02: `/gsd-new-milestone` MUST scan seeds and present matches
|
||||
- REQ-SEED-03: `/gsd-capture --list-seeds` MUST list seeds with status, scope, and trigger for audit, with optional status filtering
|
||||
- REQ-SEED-02: `/msd-new-milestone` MUST scan seeds and present matches
|
||||
- REQ-SEED-03: `/msd-capture --list-seeds` MUST list seeds with status, scope, and trigger for audit, with optional status filtering
|
||||
|
||||
**Produces:**
|
||||
| Artifact | Description |
|
||||
|
||||
@@ -4,11 +4,11 @@ title: Broken-Windows Ledger
|
||||
group: v1.7.0 Features
|
||||
---
|
||||
|
||||
**Behavior:** A cross-phase defect register at `.planning/WINDOWS.md` accumulates stubs, TODOs, skipped tests, unrun verifies, and unmet truths (#1950). `/gsd-ship` blocks while any entry is `open`; an entry can be `waived` only with a recorded reason (auditable) or marked `fixed` (removed from the blocking set). `/gsd-progress` surfaces the open + waived counts.
|
||||
**Behavior:** A cross-phase defect register at `.planning/WINDOWS.md` accumulates stubs, TODOs, skipped tests, unrun verifies, and unmet truths (#1950). `/msd-ship` blocks while any entry is `open`; an entry can be `waived` only with a recorded reason (auditable) or marked `fixed` (removed from the blocking set). `/msd-progress` surfaces the open + waived counts.
|
||||
|
||||
**Commands:** `gsd-tools windows status | append | waive | fixed`.
|
||||
**Commands:** `msd-tools windows status | append | waive | fixed`.
|
||||
|
||||
**Config:** `workflow.windows_enforce` (gate active, default `false` — opt-in enforcement). Enable with `gsd config-set workflow.windows_enforce true`. Tracking (the ledger itself, populated by the executor) is always on; only the ship gate is opt-in.
|
||||
**Config:** `workflow.windows_enforce` (gate active, default `false` — opt-in enforcement). Enable with `msd config-set workflow.windows_enforce true`. Tracking (the ledger itself, populated by the executor) is always on; only the ship gate is opt-in.
|
||||
|
||||
**Backward compatibility:** A project with no `.planning/WINDOWS.md` reports `open_count: 0` and ships cleanly; the gate only activates once windows are recorded.
|
||||
|
||||
|
||||
@@ -4,18 +4,18 @@ title: Capability Management Command
|
||||
group: v1.43.0 Features
|
||||
---
|
||||
|
||||
**Command:** `gsd capability install | update | remove | list | outdated | disable | enable`
|
||||
**Command:** `msd capability install | update | remove | list | outdated | disable | enable`
|
||||
|
||||
**Purpose:** The user-facing CLI for the ADR-1244 capability ecosystem — install, upgrade, remove, list, check for updates, and toggle GSD capabilities (first-party and third-party overlays) from a registry / git / npm / tarball / local source. Wires the Phase-3/4 lifecycle library (source resolver, install ledger, trust gate) to a command users actually run.
|
||||
**Purpose:** The user-facing CLI for the ADR-1244 capability ecosystem — install, upgrade, remove, list, check for updates, and toggle MSD capabilities (first-party and third-party overlays) from a registry / git / npm / tarball / local source. Wires the Phase-3/4 lifecycle library (source resolver, install ledger, trust gate) to a command users actually run.
|
||||
|
||||
**Behavior:**
|
||||
- `install <spec> [--integrity sha512-…] [--scope global|project] [--yes] [--shared-file <rel>]…` — resolve (copy-only) → verify integrity / SHA pin → `engines.gsd` gate → disclose executable surfaces → consent (`--yes` grants; without it an executable install aborts after printing the disclosure and writes nothing) → validate → extract → record the ledger.
|
||||
- `install <spec> [--integrity sha512-…] [--scope global|project] [--yes] [--shared-file <rel>]…` — resolve (copy-only) → verify integrity / SHA pin → `engines.msd` gate → disclose executable surfaces → consent (`--yes` grants; without it an executable install aborts after printing the disclosure and writes nothing) → validate → extract → record the ledger.
|
||||
- `update [<id> | --all] [--scope] [--yes]` — re-resolve the capability's recorded source and upgrade via atomic stage-then-swap; re-consent when the executable set changed; `--all` reports a per-capability outcome and exits non-zero on any partial failure.
|
||||
- `remove <id> [--purge-data] [--scope]` — strip the ledger-recorded files + marker-isolated shared edits; first-party capabilities are rejected (use the product uninstaller).
|
||||
- `list [--json]` — first-party + installed overlay capabilities (both scopes) as a JSON array.
|
||||
- `outdated [--json] [--scope]` — light remote peek of each installed overlay's recorded source (ADR-1244 D6 per-source matrix: git `ls-remote --tags`, npm `view … version` resolving the highest version matching the recorded range, local re-read; tarball → `manual`, registry → `unknown`) reporting `outdated` / `current` / `pinned` / `manual` / `unknown` per capability. A source pinned to an immutable ref (git `#sha:` or `#tag:`, or an exact npm version) is reported `pinned`. A bare git `#<ref>` is classified at the remote: if it resolves exclusively under `refs/tags/` it is an immutable tag → `pinned`; if it resolves to a mutable branch (or is ambiguous) it is `unknown`. Bounded subprocesses (git ≤30s, npm ≤60s) and a failing peek degrades that row to `unknown` without crashing the command. `--json` for machine output, default for a table.
|
||||
- `disable | enable <id>` — toggle activation state (equivalent to `gsd capability set <id> --off` / `--on`).
|
||||
- `disable | enable <id>` — toggle activation state (equivalent to `msd capability set <id> --off` / `--on`).
|
||||
|
||||
**Trust boundary:** install never executes capability code (copy-only staging); executable surfaces require explicit consent; sources are gated by the **project-scoped** `capabilities.strict_known_registries` policy (fail-closed on a malformed/unparseable value); every shared-config write/delete is realpath-confined to the scope root, and a name collision with a user's `mcpServers` entry is never clobbered.
|
||||
|
||||
**Reference:** [`gsd capability` command reference](reference/gsd-capability-command.md) · [ADR-1244](adr/1244-capability-ecosystem.md)
|
||||
**Reference:** [`msd capability` command reference](reference/msd-capability-command.md) · [ADR-1244](adr/1244-capability-ecosystem.md)
|
||||
|
||||
@@ -4,7 +4,7 @@ title: Claim Provenance Tagging
|
||||
group: v1.31 Features
|
||||
---
|
||||
|
||||
**Part of:** `/gsd-plan-phase --research-phase <N>`
|
||||
**Part of:** `/msd-plan-phase --research-phase <N>`
|
||||
|
||||
**Purpose:** Ensure research claims are tagged with source evidence and assumptions are logged separately.
|
||||
|
||||
|
||||
@@ -4,17 +4,17 @@ title: Claude Code Skills Migration
|
||||
group: v1.31 Features
|
||||
---
|
||||
|
||||
**Part of:** `npx @opengsd/gsd-core`
|
||||
**Part of:** `npx @golem15/msd-core`
|
||||
|
||||
**Purpose:** Migrate GSD commands to Claude Code 2.1.88+ skills format with backward compatibility.
|
||||
**Purpose:** Migrate MSD commands to Claude Code 2.1.88+ skills format with backward compatibility.
|
||||
|
||||
**Requirements:**
|
||||
- REQ-SKILLS-01: Installer MUST write `skills/gsd-*/SKILL.md` for Claude Code 2.1.88+
|
||||
- REQ-SKILLS-02: Installer MUST auto-clean legacy `commands/gsd/` directory
|
||||
- REQ-SKILLS-03: Installer MUST maintain backward compatibility with older Claude Code versions via the legacy `commands/gsd/` path
|
||||
- REQ-SKILLS-01: Installer MUST write `skills/msd-*/SKILL.md` for Claude Code 2.1.88+
|
||||
- REQ-SKILLS-02: Installer MUST auto-clean legacy `commands/msd/` directory
|
||||
- REQ-SKILLS-03: Installer MUST maintain backward compatibility with older Claude Code versions via the legacy `commands/msd/` path
|
||||
|
||||
**Process:**
|
||||
1. **Detect** — Check Claude Code version to determine skills support
|
||||
2. **Migrate** — Write `skills/gsd-*/SKILL.md` files for each GSD command
|
||||
3. **Clean** — Remove legacy `commands/gsd/` directory if skills are installed
|
||||
4. **Fallback** — Maintain legacy `commands/gsd/` path compatibility for older Claude Code versions
|
||||
2. **Migrate** — Write `skills/msd-*/SKILL.md` files for each MSD command
|
||||
3. **Clean** — Remove legacy `commands/msd/` directory if skills are installed
|
||||
4. **Fallback** — Maintain legacy `commands/msd/` path compatibility for older Claude Code versions
|
||||
|
||||
@@ -4,19 +4,19 @@ title: Code Review Pipeline
|
||||
group: v1.34.0 Features
|
||||
---
|
||||
|
||||
**Commands:** `/gsd-code-review`, `/gsd-code-review --fix`
|
||||
**Commands:** `/msd-code-review`, `/msd-code-review --fix`
|
||||
|
||||
**Purpose:** Structured review of source files changed during a phase, with a separate auto-fix pass that commits each fix atomically.
|
||||
|
||||
**Requirements:**
|
||||
- REQ-REVIEW-01: `gsd-code-review` MUST scope files to the phase using SUMMARY.md and git diff fallback
|
||||
- REQ-REVIEW-01: `msd-code-review` MUST scope files to the phase using SUMMARY.md and git diff fallback
|
||||
- REQ-REVIEW-02: Review MUST support three depth levels: `quick`, `standard`, `deep`
|
||||
- REQ-REVIEW-03: Findings MUST be severity-classified: Critical, Warning, Info
|
||||
- REQ-REVIEW-04: `gsd-code-review --fix` MUST read REVIEW.md and fix Critical + Warning findings by default
|
||||
- REQ-REVIEW-04: `msd-code-review --fix` MUST read REVIEW.md and fix Critical + Warning findings by default
|
||||
- REQ-REVIEW-05: Each fix MUST be committed atomically with a descriptive message
|
||||
- REQ-REVIEW-06: `--auto` flag MUST enable fix + re-review iteration loop, capped at 3 iterations
|
||||
- REQ-REVIEW-07: Feature MUST be gated by `workflow.code_review` config flag
|
||||
- REQ-REVIEW-08: `workflow.code_review_point` MUST select which loop point the automatic review step registers at (`execute:post` default, or `execute:wave:post`), independent of the `workflow.code_review` on/off gate and of manual `/gsd-code-review` invocation (#3661)
|
||||
- REQ-REVIEW-08: `workflow.code_review_point` MUST select which loop point the automatic review step registers at (`execute:post` default, or `execute:wave:post`), independent of the `workflow.code_review` on/off gate and of manual `/msd-code-review` invocation (#3661)
|
||||
- REQ-REVIEW-09: The in-phase `code_review_gate` MUST report the per-severity counts it parses from REVIEW.md, so a review with one `info` finding is distinguishable from a review with a Critical
|
||||
- REQ-REVIEW-10: Each finding MUST carry a recorded disposition, so a triaged finding is distinguishable from a forgotten one
|
||||
|
||||
@@ -38,8 +38,8 @@ stay small instead of growing with the phase. A finding introduced early is caug
|
||||
wave that introduced it, not after the last wave of the phase.
|
||||
|
||||
This only affects the *automatic* dispatch inside a wave-based phase execution. Manual
|
||||
`/gsd-code-review <phase>` runs are gated by `workflow.code_review` alone and are unaffected
|
||||
by this key. `/gsd-autonomous` and `/gsd-quick` have no wave granularity of their own, so
|
||||
`/msd-code-review <phase>` runs are gated by `workflow.code_review` alone and are unaffected
|
||||
by this key. `/msd-autonomous` and `/msd-quick` have no wave granularity of their own, so
|
||||
setting this to `execute:wave:post` means automatic review does not run inside those two
|
||||
flows — the same way every other wave-scoped capability step already behaves for them.
|
||||
|
||||
@@ -51,14 +51,14 @@ Escalation is **whole-review, not per-file**: depth is a single scalar handed to
|
||||
|
||||
v1 supports **directory-prefix matching only, not glob syntax**: no glob engine (`minimatch`, `picomatch`, `fast-glob`) exists in this project and none was added for this feature. A path containing `*` or `?` (e.g. `src/auth/**`) is a configuration error rather than a silent near-miss, because accepting it as sugar for a prefix would make unsupported patterns look armed when they match nothing. Every use case in the issue is expressible as a directory prefix. See [Scope code review depth by path](how-to/scope-code-review-depth-by-path.md) for the resolution order, error table, and a worked example.
|
||||
|
||||
**Optional external reviewer lanes (#4209):** `/gsd-code-review` accepts the same reviewer-lane flags as `/gsd-review` — any flag the roster declares (run `gsd_run review-lane flags` to list them for your installation, e.g. `--codex`, `--agy`). No reviewer-lane flag is the default and is byte-for-byte unchanged from before #4209: zero lane selection, plan, or invoke calls, and only the internal `gsd-code-reviewer` agent runs. Passing one or more flags asks those lanes to independently review the same already-resolved file scope alongside the internal agent, through the same shared capability-trait interpreter and `review-lane plan`/`invoke` machinery `/gsd-review` uses — no second implementation. Each lane's prompt carries only the repository root, canonical file paths, review depth, and base SHA, never source file contents, under four fixed prohibitions (no source mutation, no test execution, no background processes, no polling). External findings are unverified corroborating evidence: `gsd-code-reviewer` independently re-verifies every claim against the actual source before writing it to `REVIEW.md`, so there remains exactly one `REVIEW.md` schema regardless of how many lanes ran. An explicitly requested lane that is unavailable or fails is reported as a warning, never silently dropped and never a raw-CLI fallback. This is separate from `/gsd-review`, which reviews `PLAN.md` files before execution, not source code.
|
||||
**Optional external reviewer lanes (#4209):** `/msd-code-review` accepts the same reviewer-lane flags as `/msd-review` — any flag the roster declares (run `msd_run review-lane flags` to list them for your installation, e.g. `--codex`, `--agy`). No reviewer-lane flag is the default and is byte-for-byte unchanged from before #4209: zero lane selection, plan, or invoke calls, and only the internal `msd-code-reviewer` agent runs. Passing one or more flags asks those lanes to independently review the same already-resolved file scope alongside the internal agent, through the same shared capability-trait interpreter and `review-lane plan`/`invoke` machinery `/msd-review` uses — no second implementation. Each lane's prompt carries only the repository root, canonical file paths, review depth, and base SHA, never source file contents, under four fixed prohibitions (no source mutation, no test execution, no background processes, no polling). External findings are unverified corroborating evidence: `msd-code-reviewer` independently re-verifies every claim against the actual source before writing it to `REVIEW.md`, so there remains exactly one `REVIEW.md` schema regardless of how many lanes ran. An explicitly requested lane that is unavailable or fails is reported as a warning, never silently dropped and never a raw-CLI fallback. This is separate from `/msd-review`, which reviews `PLAN.md` files before execution, not source code.
|
||||
**In-phase review reporting and disposition**
|
||||
|
||||
`/gsd-execute-phase`'s `code_review_gate` runs code review, then reports what it found:
|
||||
`/msd-execute-phase`'s `code_review_gate` runs code review, then reports what it found:
|
||||
|
||||
```
|
||||
Code review: 23 findings — 1 critical, 9 warning, 8 info.
|
||||
Consider running: /gsd-code-review 1 --fix
|
||||
Consider running: /msd-code-review 1 --fix
|
||||
```
|
||||
|
||||
Both `critical:` and its documented tier-equivalent `blocker:` are accepted. A REVIEW.md written
|
||||
@@ -78,7 +78,7 @@ defaulting to `open`:
|
||||
**Where the reconciliation happens, which is not where you might expect.** The in-phase gate runs
|
||||
immediately after review, and at that moment `<NN>-REVIEW-FIX.md` does not exist — the gate invokes
|
||||
review with neither `--fix` nor `--auto` — so every row it writes is `open`. The `fixed` and
|
||||
`skipped` outcomes are reconciled by `/gsd-code-review <N> --fix`, which records them once the fix
|
||||
`skipped` outcomes are reconciled by `/msd-code-review <N> --fix`, which records them once the fix
|
||||
report is on disk. Running the gate alone therefore tells you what was found; running `--fix` is
|
||||
what records what happened to it.
|
||||
|
||||
@@ -94,7 +94,7 @@ decided but the current review no longer reports gets a row of its own, carrying
|
||||
marked *(not in the current review)*.
|
||||
|
||||
A converged `--auto` run also reaches the gate with a clean review and, on a direct
|
||||
`/gsd-code-review` invocation, no ledger from the in-phase gate. A fix report on disk is reason
|
||||
`/msd-code-review` invocation, no ledger from the in-phase gate. A fix report on disk is reason
|
||||
enough to record: without that, a run in which every finding was fixed and committed produced no
|
||||
disposition record at all.
|
||||
|
||||
@@ -186,6 +186,6 @@ the other.
|
||||
|
||||
The record is a sibling artifact rather than a section inside REVIEW.md because `--auto`'s
|
||||
re-review loop rewrites REVIEW.md on every iteration — a ledger kept inside it would not survive
|
||||
the next pass — and because REVIEW.md has a single writer (`gsd-code-reviewer`) that the gate is
|
||||
the next pass — and because REVIEW.md has a single writer (`msd-code-reviewer`) that the gate is
|
||||
not. The gate remains advisory throughout: it reports and records, and never blocks phase
|
||||
completion.
|
||||
|
||||
@@ -4,15 +4,15 @@ title: Codebase Mapping
|
||||
group: Brownfield Features
|
||||
---
|
||||
|
||||
**Command:** `/gsd-map-codebase [area]`
|
||||
**Command:** `/msd-map-codebase [area]`
|
||||
|
||||
**Purpose:** Analyze an existing codebase before starting a new project or as the mapping handoff from `/gsd-onboard`, so GSD understands what exists.
|
||||
**Purpose:** Analyze an existing codebase before starting a new project or as the mapping handoff from `/msd-onboard`, so MSD understands what exists.
|
||||
|
||||
**Requirements:**
|
||||
- REQ-MAP-01: System MUST spawn parallel mapper agents for each analysis area
|
||||
- REQ-MAP-02: System MUST produce structured documents in `.planning/codebase/`
|
||||
- REQ-MAP-03: System MUST detect: tech stack, architecture patterns, coding conventions, concerns
|
||||
- REQ-MAP-04: Subsequent `/gsd-new-project` MUST load codebase mapping and focus questions on what's being added
|
||||
- REQ-MAP-04: Subsequent `/msd-new-project` MUST load codebase mapping and focus questions on what's being added
|
||||
- REQ-MAP-05: Optional `[area]` argument MUST scope mapping to a specific area
|
||||
|
||||
**Produces:**
|
||||
|
||||
@@ -4,7 +4,7 @@ title: Commit-Docs Guard Hook
|
||||
group: v1.32 Features
|
||||
---
|
||||
|
||||
**Hook:** `gsd-commit-docs.js`
|
||||
**Hook:** `msd-commit-docs.js`
|
||||
|
||||
**Purpose:** PreToolUse hook that enforces the `commit_docs` configuration, preventing `.planning/` files from being committed when `planning.commit_docs` is `false`.
|
||||
|
||||
|
||||
@@ -4,18 +4,18 @@ title: Community Hooks Opt-In
|
||||
group: v1.32 Features
|
||||
---
|
||||
|
||||
**Hooks:** `gsd-validate-commit.sh`, `gsd-session-state.sh`, `gsd-phase-boundary.sh`
|
||||
**Hooks:** `msd-validate-commit.sh`, `msd-session-state.sh`, `msd-phase-boundary.sh`
|
||||
|
||||
**Purpose:** Optional git and session hooks for GSD projects, gated behind `hooks.community: true` in config.
|
||||
**Purpose:** Optional git and session hooks for MSD projects, gated behind `hooks.community: true` in config.
|
||||
|
||||
**Requirements:**
|
||||
- REQ-COMMUNITY-01: All community hooks MUST be no-ops unless `hooks.community` is `true` in `.planning/config.json`
|
||||
- REQ-COMMUNITY-02: `gsd-validate-commit.sh` MUST enforce Conventional Commits format on git commit messages
|
||||
- REQ-COMMUNITY-03: `gsd-session-state.sh` MUST track session state transitions
|
||||
- REQ-COMMUNITY-04: `gsd-phase-boundary.sh` MUST enforce phase boundary checks
|
||||
- REQ-COMMUNITY-02: `msd-validate-commit.sh` MUST enforce Conventional Commits format on git commit messages
|
||||
- REQ-COMMUNITY-03: `msd-session-state.sh` MUST track session state transitions
|
||||
- REQ-COMMUNITY-04: `msd-phase-boundary.sh` MUST enforce phase boundary checks
|
||||
|
||||
**Config:**
|
||||
| Setting | Type | Default | Description |
|
||||
|---------|------|---------|-------------|
|
||||
| `hooks.community` | boolean | `false` | Enable optional community hooks for commit validation, session state, and phase boundaries |
|
||||
| `hooks.commit_types` | array of strings | `[]` | Extra Conventional Commits types `gsd-validate-commit.sh` accepts, in addition to the built-in `feat, fix, docs, style, refactor, perf, test, build, ci, chore` — never replaces them. Each entry must match `^[a-z][a-z0-9-]*$` (lowercase letters, digits, hyphens); non-conforming or non-string entries are dropped. Example: `{ "hooks": { "community": true, "commit_types": ["enhance", "enh", "revert"] } }`. |
|
||||
| `hooks.commit_types` | array of strings | `[]` | Extra Conventional Commits types `msd-validate-commit.sh` accepts, in addition to the built-in `feat, fix, docs, style, refactor, perf, test, build, ci, chore` — never replaces them. Each entry must match `^[a-z][a-z0-9-]*$` (lowercase letters, digits, hyphens); non-conforming or non-string entries are dropped. Example: `{ "hooks": { "community": true, "commit_types": ["enhance", "enh", "revert"] } }`. |
|
||||
|
||||
@@ -4,8 +4,8 @@ title: Companion MCP Server
|
||||
group: v1.7.0 Features
|
||||
---
|
||||
|
||||
**Command:** `gsd-mcp-server`
|
||||
**Command:** `msd-mcp-server`
|
||||
|
||||
**Purpose:** A companion MCP server exposing GSD over stdio JSON-RPC 2.0, covering interface points 1 and 5 (#1681).
|
||||
**Purpose:** A companion MCP server exposing MSD over stdio JSON-RPC 2.0, covering interface points 1 and 5 (#1681).
|
||||
|
||||
**Behavior:** OpenCode installs auto-register it as `mcp.gsd` (#1682). OpenCode also gained the `opencode-subset` hook dialect plus `session.idle` handling (#1682) and now runs GSD's lifecycle safety hooks — prompt-injection guard, read-before-edit guard, and injection scanner (#1923).
|
||||
**Behavior:** OpenCode installs auto-register it as `mcp.msd` (#1682). OpenCode also gained the `opencode-subset` hook dialect plus `session.idle` handling (#1682) and now runs MSD's lifecycle safety hooks — prompt-injection guard, read-before-edit guard, and injection scanner (#1923).
|
||||
|
||||
@@ -6,7 +6,7 @@ group: v1.7.0 Features
|
||||
|
||||
**Behavior:** An `execute:post` step measures the complexity of the files a phase touched (decision-point counting over comment- and literal-stripped source, no external dependency) and surfaces a scoped refactor proposal at `.planning/phases/<N>/<NN>-REFACTOR.md` when a function's score exceeds `refactor.complexity_threshold` or its growth over its recorded anchor exceeds `refactor.complexity_jump_delta` — whichever trips first, both reported. Trigger semantics are strictly greater (ESLint's `complexity: {max: N}` convention), so a score exactly equal to the threshold does not trigger. The anchor is set the first time a function is observed and moves only when the proposal is dispositioned via `refactor accept` or `refactor decline` — never when the score alone improves — so the jump delta is cumulative growth since the last conscious decision about that function, not the change made in a single phase. Advisory by default: the proposal is informational only, never edits code, and never blocks. Opt-in `refactor.trigger_strict` records an untriaged proposal as an open `deviation` entry in the broken-windows ledger (#1950) instead — it does not block on its own; ship-blocking is broken-windows' existing `ship:pre` gate, enabled separately with `workflow.windows_enforce`. Without broken-windows installed, strict mode still records the proposal locally and says so. Enabling `refactor.trigger_strict` without `workflow.windows_enforce` also on (or with broken-windows absent) surfaces a typed `refactor_strict_not_enforcing` warning on every triggering evaluate, naming the exact remediation, so this enforcement gap is never silent. A declined proposal resolves its ledger entry as `waived` with the recorded reason; an accepted one resolves as `fixed`. The metric is approximate by construction: biased against a flat `switch`, blind to nesting depth, JS/TS-family only, and a renamed function loses its anchor (issue #1953).
|
||||
|
||||
**Commands:** `gsd-tools refactor evaluate | status | accept | decline`.
|
||||
**Commands:** `msd-tools refactor evaluate | status | accept | decline`.
|
||||
|
||||
**Config:** `refactor.trigger_enabled` (master gate, default `false`), `refactor.complexity_threshold` (default `15`), `refactor.complexity_jump_delta` (default `5`), `refactor.trigger_strict` (default `false`). See [Configuration Reference](CONFIGURATION.md#refactor-trigger-settings).
|
||||
|
||||
|
||||
@@ -4,12 +4,12 @@ title: Configurable CLAUDE.md Path
|
||||
group: v1.36.0 Features
|
||||
---
|
||||
|
||||
**Purpose:** Allow projects to store their CLAUDE.md in a non-root location. The `claude_md_path` config key controls where `/gsd-profile-user` and related commands write the generated CLAUDE.md file.
|
||||
**Purpose:** Allow projects to store their CLAUDE.md in a non-root location. The `claude_md_path` config key controls where `/msd-profile-user` and related commands write the generated CLAUDE.md file.
|
||||
|
||||
**Requirements:**
|
||||
- REQ-CMDPATH-01: `claude_md_path` defaults to `./.claude/CLAUDE.md` (a valid project-scoped memory location; changed from `./CLAUDE.md` in v1.5 per [#1098](https://github.com/open-gsd/gsd-core/issues/1098) so generated content does not pollute a hand-crafted repo-root `CLAUDE.md`)
|
||||
- REQ-CMDPATH-02: Profile generation commands read the path from config and write to the specified location
|
||||
- REQ-CMDPATH-03: Relative paths are resolved from the project root
|
||||
- REQ-CMDPATH-04: `generate-claude-md` never overwrites an existing instruction file that lacks GSD section markers (a hand-crafted file) unless `--force` is passed
|
||||
- REQ-CMDPATH-04: `generate-claude-md` never overwrites an existing instruction file that lacks MSD section markers (a hand-crafted file) unless `--force` is passed
|
||||
|
||||
**Configuration:** `claude_md_path`
|
||||
|
||||
@@ -4,7 +4,7 @@ title: Context Drift Gate
|
||||
group: v1.7.0 Features
|
||||
---
|
||||
|
||||
**Purpose:** Warns (or optionally blocks) before `/gsd-plan-phase` reuses an existing
|
||||
**Purpose:** Warns (or optionally blocks) before `/msd-plan-phase` reuses an existing
|
||||
`RESEARCH.md`, `PATTERNS.md`, `VALIDATION.md`, or `SPEC.md` that predates a decision added to the
|
||||
phase's `CONTEXT.md` after that artifact was derived from it. Deterministic — compares git commit
|
||||
time (falling back to mtime for uncommitted edits), no model call. Sibling to the existing
|
||||
|
||||
@@ -12,7 +12,7 @@ group: Context Engineering Features
|
||||
- REQ-CTX-03: Context monitor MUST inject agent-facing warnings at the CRITICAL fire-point — ≤25% remaining by default, overridable per project via `hooks.context_critical_threshold`
|
||||
- REQ-CTX-04: Warnings MUST debounce (5 tool uses between repeated warnings)
|
||||
- REQ-CTX-05: Severity escalation (WARNING→CRITICAL) MUST bypass debounce
|
||||
- REQ-CTX-06: Context monitor MUST differentiate GSD-active vs non-GSD-active projects
|
||||
- REQ-CTX-06: Context monitor MUST differentiate MSD-active vs non-MSD-active projects
|
||||
- REQ-CTX-07: Warnings MUST be advisory, never imperative commands that override user preferences
|
||||
- REQ-CTX-08: All hooks MUST fail silently and never block tool execution
|
||||
|
||||
|
||||
@@ -4,13 +4,13 @@ title: Context-Window Utilization Guard
|
||||
group: v1.40.0 Features
|
||||
---
|
||||
|
||||
**Command:** `/gsd-health --context`
|
||||
**Command:** `/msd-health --context`
|
||||
|
||||
**Purpose:** Quality guard against context-window saturation. Two thresholds: 60 % utilization warns ("consider `/gsd-thread`"), 70 % is critical ("reasoning quality may degrade"; matches the fracture-point per recent context-attention research).
|
||||
**Purpose:** Quality guard against context-window saturation. Two thresholds: 60 % utilization warns ("consider `/msd-thread`"), 70 % is critical ("reasoning quality may degrade"; matches the fracture-point per recent context-attention research).
|
||||
|
||||
**Requirements:**
|
||||
- REQ-CTX-GUARD-01: `/gsd-health --context` prints a structured status line with current utilization, threshold tier (`ok` / `warn` / `critical`), and a remediation suggestion.
|
||||
- REQ-CTX-GUARD-02: The same triage is exposed as `gsd-tools.cjs validate context --tokens-used <int> --context-window <int>` — a structured envelope for status-line and hook callers (#125). Both flags are required; the handler returns the same `{ percent, state }` envelope as the pure classifier in REQ-CTX-GUARD-03.
|
||||
- REQ-CTX-GUARD-01: `/msd-health --context` prints a structured status line with current utilization, threshold tier (`ok` / `warn` / `critical`), and a remediation suggestion.
|
||||
- REQ-CTX-GUARD-02: The same triage is exposed as `msd-tools.cjs validate context --tokens-used <int> --context-window <int>` — a structured envelope for status-line and hook callers (#125). Both flags are required; the handler returns the same `{ percent, state }` envelope as the pure classifier in REQ-CTX-GUARD-03.
|
||||
- REQ-CTX-GUARD-03: The classifier (`bin/lib/context-utilization.cjs`) is pure: input `(tokensUsed, contextWindow)`, output `{ percent, state }`. Easy to unit-test, easy to reuse from any caller.
|
||||
|
||||
**Reference issue:** [#2792](https://github.com/open-gsd/gsd-core/issues/2792)
|
||||
|
||||
@@ -4,7 +4,7 @@ title: Cross-AI Execution Delegation
|
||||
group: v1.36.0 Features
|
||||
---
|
||||
|
||||
**Command:** `/gsd-execute-phase N --cross-ai`
|
||||
**Command:** `/msd-execute-phase N --cross-ai`
|
||||
|
||||
**Purpose:** Delegate individual plans to an external AI runtime for execution. Plans with `cross_ai: true` in their frontmatter (or all plans when `--cross-ai` is used) are sent to the configured command via stdin. Successfully handled plans are removed from the normal executor queue.
|
||||
|
||||
|
||||
@@ -4,7 +4,7 @@ title: Cross-AI Peer Review
|
||||
group: v1.27 Features
|
||||
---
|
||||
|
||||
**Command:** `/gsd-review --phase N [--claude] [--codex] [--coderabbit] [--opencode] [--qwen] [--cursor] [--agy] [--antigravity] [--ollama] [--lm-studio] [--llama-cpp] [--kimi-code] [--all]`
|
||||
**Command:** `/msd-review --phase N [--claude] [--codex] [--coderabbit] [--opencode] [--qwen] [--cursor] [--agy] [--antigravity] [--ollama] [--lm-studio] [--llama-cpp] [--kimi-code] [--all]`
|
||||
|
||||
**Purpose:** Invoke external AI CLIs (Claude, Codex, CodeRabbit, OpenCode, Qwen Code, Cursor, Antigravity, Kimi Code) and local OpenAI-compatible servers (Ollama, LM Studio, llama.cpp) to independently review phase plans. Produces structured REVIEWS.md with per-reviewer feedback.
|
||||
|
||||
@@ -15,14 +15,14 @@ Each reviewer is a **declared lane**: its binary, prompt and output channels, ti
|
||||
- REQ-REVIEW-02: System MUST build a structured review prompt from phase plans
|
||||
- REQ-REVIEW-03: System MUST invoke each selected CLI independently
|
||||
- REQ-REVIEW-04: System MUST collect responses and produce `REVIEWS.md`
|
||||
- REQ-REVIEW-05: Reviews MUST be consumable by `/gsd-plan-phase --reviews`
|
||||
- REQ-REVIEW-05: Reviews MUST be consumable by `/msd-plan-phase --reviews`
|
||||
- REQ-REVIEW-06: System MUST support project-level no-flag defaults via `review.default_reviewers`
|
||||
- REQ-REVIEW-07: Reviewer precedence MUST be explicit flags > `--all` > `review.default_reviewers` > all detected reviewers
|
||||
|
||||
**Produces:** `{phase}-REVIEWS.md` — Per-reviewer structured feedback
|
||||
|
||||
**User configuration note:**
|
||||
- Set `review.default_reviewers` in `.planning/config.json` (or via `gsd config-set`) to control no-flag `/gsd-review` fan-out.
|
||||
- Set `review.default_reviewers` in `.planning/config.json` (or via `msd config-set`) to control no-flag `/msd-review` fan-out.
|
||||
- `review.default_reviewers` may include configured `review.reviewer_instances` names; each instance runs as an independent reviewer identity backed by its configured adapter/model. Instance names are not CLI flags.
|
||||
- Use `--all` for a full pre-merge sweep without changing project defaults.
|
||||
- For local model servers with small context windows, set `review.max_prompt_tokens_per_reviewer` to auto-trim prompts per reviewer — see [Prompt budgets for small-context reviewers](../docs/CONFIGURATION.md#prompt-budgets-for-small-context-reviewers) in CONFIGURATION.md.
|
||||
@@ -31,4 +31,4 @@ Each reviewer is a **declared lane**: its binary, prompt and output channels, ti
|
||||
|
||||
The fix records the model *and its provenance*. Provenance is what makes the value trustworthy: `pinned` (from `review.models.<slug>`) is certain, while `banner` and `transcript` are recovered from third-party CLI output this project does not own — a startup banner or an undocumented session log.
|
||||
|
||||
That third-party dependence is a real trade-off, held honestly rather than papered over: the `banner` and `transcript` arms read formats GSD does not control, so they are best-effort by design and degrade to `unknown` rather than guessing or failing the run. A recorded `unknown` is a real answer — a wrong model name attributed to a review would be worse than none.
|
||||
That third-party dependence is a real trade-off, held honestly rather than papered over: the `banner` and `transcript` arms read formats MSD does not control, so they are best-effort by design and degrade to `unknown` rather than guessing or failing the run. A recorded `unknown` is a real answer — a wrong model name attributed to a review would be worse than none.
|
||||
|
||||
@@ -12,4 +12,4 @@ group: Quality Assurance Features
|
||||
- REQ-REGR-03: Regressions MUST be surfaced before post-execution verification
|
||||
- REQ-REGR-04: System MUST identify which prior phase's tests were broken
|
||||
|
||||
**When:** Runs automatically during `/gsd-execute-phase` before the verifier step.
|
||||
**When:** Runs automatically during `/msd-execute-phase` before the verifier step.
|
||||
|
||||
@@ -4,11 +4,11 @@ title: Custom Ship PR Body Sections
|
||||
group: v1.42.1 Features
|
||||
---
|
||||
|
||||
**Command:** `/gsd-ship`
|
||||
**Command:** `/msd-ship`
|
||||
|
||||
**Config key:** `ship.pr_body_sections`
|
||||
|
||||
**Purpose:** Add project-specific PRD-style sections to generated PR bodies without editing GSD workflow files.
|
||||
**Purpose:** Add project-specific PRD-style sections to generated PR bodies without editing MSD workflow files.
|
||||
|
||||
**Behavior:** Configured sections append after the required `Summary`, `Changes`, `Requirements Addressed`, `Verification`, and `Key Decisions` sections. They can copy from artifact headings, render templates, or fall back to static text.
|
||||
|
||||
|
||||
@@ -4,7 +4,7 @@ title: Debug `--diagnose` Flag
|
||||
group: v1.32 Features
|
||||
---
|
||||
|
||||
**Flag:** `/gsd-debug --diagnose`
|
||||
**Flag:** `/msd-debug --diagnose`
|
||||
|
||||
**Purpose:** Diagnosis-only mode that investigates without attempting fixes.
|
||||
|
||||
|
||||
@@ -4,7 +4,7 @@ title: Debug System
|
||||
group: Utility Features
|
||||
---
|
||||
|
||||
**Command:** `/gsd-debug [description]`
|
||||
**Command:** `/msd-debug [description]`
|
||||
|
||||
**Purpose:** Systematic debugging with persistent state across context resets.
|
||||
|
||||
|
||||
@@ -4,7 +4,7 @@ title: Developer Profiling
|
||||
group: Infrastructure Features
|
||||
---
|
||||
|
||||
**Command:** `/gsd-profile-user [--questionnaire] [--refresh]`
|
||||
**Command:** `/msd-profile-user [--questionnaire] [--refresh]`
|
||||
|
||||
**Purpose:** Analyze Claude Code session history to build behavioral profiles across 8 dimensions, generating artifacts that personalize Claude's responses to the developer's style.
|
||||
|
||||
@@ -29,7 +29,7 @@ group: Infrastructure Features
|
||||
**Pipeline Modules:**
|
||||
- `profile-pipeline.cjs` — Session scanning, message extraction, sampling
|
||||
- `profile-output.cjs` — Profile rendering, questionnaire, artifact generation
|
||||
- `gsd-user-profiler` agent — Behavioral analysis from session data
|
||||
- `msd-user-profiler` agent — Behavioral analysis from session data
|
||||
|
||||
**Requirements:**
|
||||
- REQ-PROF-01: Session analysis MUST cover at least 8 behavioral dimensions
|
||||
|
||||
@@ -6,6 +6,6 @@ group: v1.7.0 Features
|
||||
|
||||
**Purpose:** Two non-endorsing catalogs for third-party extensions (#2182).
|
||||
|
||||
**Behavior:** The **Community Capability Registry** (#2188) lists third-party Feature Capabilities installed with `gsd capability install`; the **EoS Registry** (#2193) lists third-party host integrations built on the ADR-1239 interface. Every entry embeds a live release badge and links to a GitHub Discussion. Registration is a documentation PR, regenerated with `npm run gen:registry`.
|
||||
**Behavior:** The **Community Capability Registry** (#2188) lists third-party Feature Capabilities installed with `msd capability install`; the **EoS Registry** (#2193) lists third-party host integrations built on the ADR-1239 interface. Every entry embeds a live release badge and links to a GitHub Discussion. Registration is a documentation PR, regenerated with `npm run gen:registry`.
|
||||
|
||||
**Reference:** [GSD Registries](registries/README.md)
|
||||
**Reference:** [MSD Registries](registries/README.md)
|
||||
|
||||
@@ -4,7 +4,7 @@ title: Discuss Chain Mode
|
||||
group: v1.31 Features
|
||||
---
|
||||
|
||||
**Flag:** `/gsd-discuss-phase <N> --chain`
|
||||
**Flag:** `/msd-discuss-phase <N> --chain`
|
||||
|
||||
**Purpose:** Auto-chain discuss, plan, and execute phases in one flow to reduce manual command sequencing.
|
||||
|
||||
|
||||
@@ -4,7 +4,7 @@ title: Discuss-Phase `--power` Flag
|
||||
group: v1.32 Features
|
||||
---
|
||||
|
||||
**Flag:** `/gsd-discuss-phase --power`
|
||||
**Flag:** `/msd-discuss-phase --power`
|
||||
|
||||
**Purpose:** File-based bulk question answering for discuss-phase, enabling batch input from a prepared answers file.
|
||||
|
||||
|
||||
@@ -4,7 +4,7 @@ title: Discussion Audit Trail
|
||||
group: v1.27 Features
|
||||
---
|
||||
|
||||
**Purpose:** Auto-generate `DISCUSSION-LOG.md` during `/gsd-discuss-phase` for full audit trail of decisions made during discussion.
|
||||
**Purpose:** Auto-generate `DISCUSSION-LOG.md` during `/msd-discuss-phase` for full audit trail of decisions made during discussion.
|
||||
|
||||
**Requirements:**
|
||||
- REQ-DISCLOG-01: System MUST auto-generate DISCUSSION-LOG.md during discuss-phase
|
||||
|
||||
@@ -4,13 +4,13 @@ title: Documentation Generation
|
||||
group: v1.31 Features
|
||||
---
|
||||
|
||||
**Command:** `/gsd-docs-update`
|
||||
**Command:** `/msd-docs-update`
|
||||
|
||||
**Purpose:** Generate and verify project documentation with accuracy checks.
|
||||
|
||||
**Requirements:**
|
||||
- REQ-DOCS-01: System MUST spawn `gsd-doc-writer` agent to generate documentation
|
||||
- REQ-DOCS-02: System MUST spawn `gsd-doc-verifier` agent to check accuracy
|
||||
- REQ-DOCS-01: System MUST spawn `msd-doc-writer` agent to generate documentation
|
||||
- REQ-DOCS-02: System MUST spawn `msd-doc-verifier` agent to check accuracy
|
||||
- REQ-DOCS-03: System MUST verify generated documentation against actual implementation
|
||||
|
||||
**Produces:**
|
||||
@@ -19,6 +19,6 @@ group: v1.31 Features
|
||||
| Updated project documentation | Generated and verified documentation files |
|
||||
|
||||
**Process:**
|
||||
1. **Generate** — Spawn `gsd-doc-writer` to create or update documentation from implementation
|
||||
2. **Verify** — Spawn `gsd-doc-verifier` to check documentation accuracy against codebase
|
||||
1. **Generate** — Spawn `msd-doc-writer` to create or update documentation from implementation
|
||||
2. **Verify** — Spawn `msd-doc-verifier` to check documentation accuracy against codebase
|
||||
3. **Output** — Produce verified documentation with accuracy annotations
|
||||
|
||||
@@ -6,8 +6,8 @@ group: v1.7.0 Features
|
||||
|
||||
**Purpose:** Express every host integration against one public, versioned contract (ADR-1239 Phase A, #1690) instead of bespoke per-host wiring, so onboarding a new host becomes additive descriptor work.
|
||||
|
||||
**Behavior:** The interface exposes six interface points (`command`, `dispatch`, `model`, `hooks`, `state`, `artifact`), eight negotiated axes, and a `PROTOCOL_VERSION` handshake that negotiates down to `min(host, engine)`. In 1.7.0, 14 runtimes were migrated onto the interface via imperative adapters (OpenCode #2087, Cursor #2089, Cline #2090, Hermes #2091, Qwen #2092, Kilo #2093, Trae #2094, Kimi #2095, Antigravity #2096, Augment #2097), a declarative adapter (Codex #2088), plus full lifecycle-hook wiring for CodeBuddy (#2098), GitHub Copilot (#2099), and Windsurf (#2100). Descriptors gained an `extensionEvents` vocabulary (#1946), and `/gsd-surface` now reproduces a runtime's agent output byte-for-byte from the installer's descriptors (#1575).
|
||||
**Behavior:** The interface exposes six interface points (`command`, `dispatch`, `model`, `hooks`, `state`, `artifact`), eight negotiated axes, and a `PROTOCOL_VERSION` handshake that negotiates down to `min(host, engine)`. In 1.7.0, 14 runtimes were migrated onto the interface via imperative adapters (OpenCode #2087, Cursor #2089, Cline #2090, Hermes #2091, Qwen #2092, Kilo #2093, Trae #2094, Kimi #2095, Antigravity #2096, Augment #2097), a declarative adapter (Codex #2088), plus full lifecycle-hook wiring for CodeBuddy (#2098), GitHub Copilot (#2099), and Windsurf (#2100). Descriptors gained an `extensionEvents` vocabulary (#1946), and `/msd-surface` now reproduces a runtime's agent output byte-for-byte from the installer's descriptors (#1575).
|
||||
|
||||
**New runtimes:** ZCode (Z.ai — Agentic Development Environment for GLM-5.2, #1925), pi (`npx @opengsd/gsd-core --pi`, #2102), and a repo-local VS Code extension driven through the adapter (#2103). The retired Gemini CLI now redirects to Antigravity CLI, its official successor (#1928).
|
||||
**New runtimes:** ZCode (Z.ai — Agentic Development Environment for GLM-5.2, #1925), pi (`npx @golem15/msd-core --pi`, #2102), and a repo-local VS Code extension driven through the adapter (#2103). The retired Gemini CLI now redirects to Antigravity CLI, its official successor (#1928).
|
||||
|
||||
**Reference:** [The Embeddable Orchestration System](explanation/embeddable-orchestration-system.md) · [Host-Integration Interface](reference/host-integration-interface.md) · [Interface versioning policy](explanation/interface-versioning-policy.md)
|
||||
|
||||
@@ -15,4 +15,4 @@ group: v1.42.1 Features
|
||||
- REQ-HUMAN-VERIFY-02: Human-needed verification MUST remain pending until the end-of-phase review resolves it.
|
||||
- REQ-HUMAN-VERIFY-03: Configs without the key MUST use `"end-of-phase"`.
|
||||
|
||||
**Reference:** [Checkpoints Reference](../gsd-core/references/checkpoints.md)
|
||||
**Reference:** [Checkpoints Reference](../msd-core/references/checkpoints.md)
|
||||
|
||||
@@ -5,14 +5,14 @@ group: Brownfield Features
|
||||
order: 27.1
|
||||
---
|
||||
|
||||
**Command:** `/gsd-onboard [--fast] [--text]`
|
||||
**Command:** `/msd-onboard [--fast] [--text]`
|
||||
|
||||
**Purpose:** Guide first-time setup for an existing repository by checking brownfield state, routing through codebase mapping and docs ingest, then handing off to project initialization without silently overwriting planning artifacts.
|
||||
|
||||
**Requirements:**
|
||||
- REQ-ONBOARD-01: System MUST detect existing code, package manifests, planning documents, partial `.planning/` state, and complete or missing codebase-map files.
|
||||
- REQ-ONBOARD-02: System MUST hand off to `/gsd-map-codebase` or `/gsd-map-codebase --fast` when brownfield code lacks the required `.planning/codebase/` map files; fast-map readiness is partial and MUST NOT be treated as sufficient for `/gsd-new-project`.
|
||||
- REQ-ONBOARD-03: System MUST offer `/gsd-ingest-docs` before `/gsd-new-project` when ADR/PRD/SPEC/RFC candidates exist and no project exists.
|
||||
- REQ-ONBOARD-02: System MUST hand off to `/msd-map-codebase` or `/msd-map-codebase --fast` when brownfield code lacks the required `.planning/codebase/` map files; fast-map readiness is partial and MUST NOT be treated as sufficient for `/msd-new-project`.
|
||||
- REQ-ONBOARD-03: System MUST offer `/msd-ingest-docs` before `/msd-new-project` when ADR/PRD/SPEC/RFC candidates exist and no project exists.
|
||||
- REQ-ONBOARD-04: System MUST refuse to report onboarding complete until `PROJECT.md`, `REQUIREMENTS.md`, `ROADMAP.md`, and `STATE.md` all exist.
|
||||
- REQ-ONBOARD-05: System MUST create or confirm `.planning/onboarding/SUMMARY.md` only after project setup exists.
|
||||
- REQ-ONBOARD-06: System MUST support `--text` for numbered plain-text gates on runtimes without interactive menus.
|
||||
@@ -20,6 +20,6 @@ order: 27.1
|
||||
**Produces:**
|
||||
| Artifact | Description |
|
||||
|----------|-------------|
|
||||
| `.planning/codebase/` | Codebase map produced by the `/gsd-map-codebase` handoff |
|
||||
| `.planning/PROJECT.md`, `REQUIREMENTS.md`, `ROADMAP.md`, `STATE.md` | Planning setup produced by `/gsd-new-project` or `/gsd-ingest-docs` |
|
||||
| `.planning/codebase/` | Codebase map produced by the `/msd-map-codebase` handoff |
|
||||
| `.planning/PROJECT.md`, `REQUIREMENTS.md`, `ROADMAP.md`, `STATE.md` | Planning setup produced by `/msd-new-project` or `/msd-ingest-docs` |
|
||||
| `.planning/onboarding/SUMMARY.md` | Onboarding status, artifact index, and next-command summary |
|
||||
|
||||
@@ -4,9 +4,9 @@ title: External Code Review Command
|
||||
group: v1.36.0 Features
|
||||
---
|
||||
|
||||
**Command:** `/gsd-ship` (enhanced)
|
||||
**Command:** `/msd-ship` (enhanced)
|
||||
|
||||
**Purpose:** Before the manual review step in `/gsd-ship`, automatically run an external code review command if configured. The command receives the diff and phase context via stdin and returns a JSON verdict (`APPROVED` or `REVISE`). Falls through to the existing manual review flow regardless of outcome.
|
||||
**Purpose:** Before the manual review step in `/msd-ship`, automatically run an external code review command if configured. The command receives the diff and phase context via stdin and returns a JSON verdict (`APPROVED` or `REVISE`). Falls through to the existing manual review flow regardless of outcome.
|
||||
|
||||
**Requirements:**
|
||||
- REQ-EXTREVIEW-01: `workflow.code_review_command` must be set to a command string; null means skip
|
||||
|
||||
@@ -4,7 +4,7 @@ title: Extract Learnings
|
||||
group: v1.36.0 Features
|
||||
---
|
||||
|
||||
**Command:** `/gsd-extract-learnings N`
|
||||
**Command:** `/msd-extract-learnings N`
|
||||
|
||||
**Purpose:** Extract structured knowledge from completed phase artifacts. Reads PLAN.md and SUMMARY.md (required) plus VERIFICATION.md, UAT.md, and STATE.md (optional) to produce four categories of learnings: decisions, lessons, patterns, and surprises. Optionally captures each item to an external knowledge base via `capture_thought` tool.
|
||||
|
||||
@@ -17,7 +17,7 @@ group: v1.36.0 Features
|
||||
|
||||
**Produces:** `{phase}-LEARNINGS.md` with YAML frontmatter (phase, project, counts per category, missing_artifacts)
|
||||
|
||||
**Optional integration — `capture_thought`:** `capture_thought` is a **convention, not a bundled tool**. GSD does not ship one and does not require one. The workflow checks whether any MCP server in the current session exposes a tool named `capture_thought` and, if so, calls it once per extracted learning with the signature below. If no such tool is present, the step is skipped silently and `LEARNINGS.md` remains the primary output.
|
||||
**Optional integration — `capture_thought`:** `capture_thought` is a **convention, not a bundled tool**. MSD does not ship one and does not require one. The workflow checks whether any MCP server in the current session exposes a tool named `capture_thought` and, if so, calls it once per extracted learning with the signature below. If no such tool is present, the step is skipped silently and `LEARNINGS.md` remains the primary output.
|
||||
|
||||
Expected tool signature:
|
||||
```javascript
|
||||
@@ -29,6 +29,6 @@ capture_thought({
|
||||
})
|
||||
```
|
||||
|
||||
Users who run a memory / knowledge-base MCP server (for example, ExoCortex-style servers, `claude-mem`, or `mem0`-style servers) can implement this tool name to have learnings routed into their knowledge base automatically with `project`, `phase`, and `source` metadata. Everyone else can use `/gsd-extract-learnings` without any extra setup — the `LEARNINGS.md` artifact is the feature.
|
||||
Users who run a memory / knowledge-base MCP server (for example, ExoCortex-style servers, `claude-mem`, or `mem0`-style servers) can implement this tool name to have learnings routed into their knowledge base automatically with `project`, `phase`, and `source` metadata. Everyone else can use `/msd-extract-learnings` without any extra setup — the `LEARNINGS.md` artifact is the feature.
|
||||
|
||||
With `features.global_learnings: true`, phase completion runs the extraction for the just-completed phase automatically and copies the artifact to the global store at `~/.gsd/knowledge/` (#3683) — extraction and copy failures never block completion. With the gate off (the default), extraction stays fully manual.
|
||||
With `features.global_learnings: true`, phase completion runs the extraction for the just-completed phase automatically and copies the artifact to the global store at `~/.msd/knowledge/` (#3683) — extraction and copy failures never block completion. With the gate off (the default), extraction stays fully manual.
|
||||
|
||||
@@ -6,7 +6,7 @@ group: v1.7.0 Features
|
||||
|
||||
**Purpose:** ADR-3473 §8.4 states the rule directly: absence, emptiness, and
|
||||
failure are three different things, and a routine that cannot tell them
|
||||
apart eventually reports the wrong one. Before this change, `gsd-tools` had
|
||||
apart eventually reports the wrong one. Before this change, `msd-tools` had
|
||||
two silent instances of exactly that collapse.
|
||||
|
||||
**Half one — a stray positional corrupted state, silently (#3358).**
|
||||
@@ -68,10 +68,10 @@ nullglob hazard) is untouched. See
|
||||
escape was added.
|
||||
- `--pick` still cannot distinguish an absent field from a `null` one *on
|
||||
stdout alone* — the distinction is carried entirely by exit code.
|
||||
- The ~10 `gsd-tools.cjs` call sites of `parseNamedArgs` get no
|
||||
- The ~10 `msd-tools.cjs` call sites of `parseNamedArgs` get no
|
||||
compile-time check (that file is hand-written JavaScript, not `.cts`);
|
||||
enforcement there is the runtime throw on a stale legacy call shape plus
|
||||
behavioral tests.
|
||||
- This phase does not sweep every routine in `gsd-core` for `Result`
|
||||
- This phase does not sweep every routine in `msd-core` for `Result`
|
||||
conformance — it applies the rule to the argument-projection seam and the
|
||||
`--pick` extractor it names, not the whole codebase.
|
||||
|
||||
@@ -4,13 +4,13 @@ title: Fallow Structural Review Pre-Pass
|
||||
group: v1.42.1 Features
|
||||
---
|
||||
|
||||
**Command:** `/gsd-code-review`
|
||||
**Command:** `/msd-code-review`
|
||||
|
||||
**Config keys:** `code_quality.fallow.*`
|
||||
|
||||
**Purpose:** Add an optional structural analysis pass before the agent review.
|
||||
|
||||
**Behavior:** When enabled, GSD resolves a `fallow` binary, runs a bounded audit, writes `FALLOW.json`, and embeds structural findings in `REVIEW.md`.
|
||||
**Behavior:** When enabled, MSD resolves a `fallow` binary, runs a bounded audit, writes `FALLOW.json`, and embeds structural findings in `REVIEW.md`.
|
||||
|
||||
**Requirements:**
|
||||
- REQ-FALLOW-01: Fallow MUST be opt-in and disabled by default.
|
||||
|
||||
@@ -4,7 +4,7 @@ title: Fast Mode
|
||||
group: v1.27 Features
|
||||
---
|
||||
|
||||
**Command:** `/gsd-fast [task description]`
|
||||
**Command:** `/msd-fast [task description]`
|
||||
|
||||
**Purpose:** Execute trivial tasks inline without spawning subagents or generating PLAN.md files. For tasks too small to justify planning overhead: typo fixes, config changes, small refactors, forgotten commits, simple additions.
|
||||
|
||||
@@ -14,6 +14,6 @@ group: v1.27 Features
|
||||
- REQ-FAST-03: System MUST track the task in `.planning/quick/` for state consistency
|
||||
- REQ-FAST-04: System MUST NOT be used for tasks requiring research, multi-step planning, or verification
|
||||
|
||||
**When to use vs `/gsd-quick`:**
|
||||
- `/gsd-fast` — One-sentence tasks executable in under 2 minutes (typo, config change, small addition)
|
||||
- `/gsd-quick` — Anything needing research, multi-step planning, or verification
|
||||
**When to use vs `/msd-quick`:**
|
||||
- `/msd-fast` — One-sentence tasks executable in under 2 minutes (typo, config change, small addition)
|
||||
- `/msd-quick` — Anything needing research, multi-step planning, or verification
|
||||
|
||||
@@ -4,9 +4,9 @@ title: Forensics
|
||||
group: v1.28 Features
|
||||
---
|
||||
|
||||
**Command:** `/gsd-forensics [description]`
|
||||
**Command:** `/msd-forensics [description]`
|
||||
|
||||
**Purpose:** Post-mortem investigation of failed or stuck GSD workflows.
|
||||
**Purpose:** Post-mortem investigation of failed or stuck MSD workflows.
|
||||
|
||||
**Requirements:**
|
||||
- REQ-FORENSICS-01: System MUST analyze git history for anomalies (stuck loops, long gaps, repeated commits)
|
||||
|
||||
@@ -4,13 +4,13 @@ title: Freeform Routing
|
||||
group: Planning Features
|
||||
---
|
||||
|
||||
**Command:** `/gsd-progress --do` (see also `/gsd-manager` for interactive routing)
|
||||
**Command:** `/msd-progress --do` (see also `/msd-manager` for interactive routing)
|
||||
|
||||
**Purpose:** Analyze freeform text and route to the appropriate GSD command.
|
||||
**Purpose:** Analyze freeform text and route to the appropriate MSD command.
|
||||
|
||||
**Requirements:**
|
||||
- REQ-DO-01: System MUST parse user intent from natural language input
|
||||
- REQ-DO-02: System MUST map intent to the best matching GSD command
|
||||
- REQ-DO-02: System MUST map intent to the best matching MSD command
|
||||
- REQ-DO-03: System MUST confirm the routing with the user before executing
|
||||
- REQ-DO-04: System MUST handle project-exists vs no-project contexts differently
|
||||
- REQ-DO-05: Routing rules MUST order specific operations before the generic keyword rules they shadow (specific-before-generic)
|
||||
|
||||
@@ -4,7 +4,7 @@ title: Gates Taxonomy
|
||||
group: v1.34.0 Features
|
||||
---
|
||||
|
||||
**References:** `gsd-core/references/gates.md`
|
||||
**References:** `msd-core/references/gates.md`
|
||||
**Agents:** plan-checker, verifier
|
||||
|
||||
**Purpose:** Define 4 canonical gate types that structure all workflow decision points, enabling plan-checker and verifier agents to apply consistent gate logic.
|
||||
|
||||
@@ -4,15 +4,15 @@ title: Graphify CLI Preferred for Planner and Researcher Graph Queries
|
||||
group: v1.7.0 Features
|
||||
---
|
||||
|
||||
**Purpose:** `gsd-planner` gets **one** knowledge-graph query per phase and
|
||||
`gsd-phase-researcher` gets two or three. That single shot decides which modules
|
||||
**Purpose:** `msd-planner` gets **one** knowledge-graph query per phase and
|
||||
`msd-phase-researcher` gets two or three. That single shot decides which modules
|
||||
the plan treats as related, and therefore how tasks are ordered into waves. It
|
||||
was spent on the built-in reader, which seeds by case-insensitive **substring**
|
||||
match over a node's label and description and then expands a hardcoded two hops
|
||||
— so the phase "User Authentication" seeds on `author`, `authoring`, and
|
||||
`unauthorized` with exactly the same weight as `authenticate`, and when the
|
||||
inflated result exceeds `--budget` the trimmer drops edges by confidence tier.
|
||||
The `graphify` CLI, already a hard dependency of `/gsd-graphify build`, ranks
|
||||
The `graphify` CLI, already a hard dependency of `/msd-graphify build`, ranks
|
||||
seeds (IDF weighting, trigram fuzzy matching) and applies context filters before
|
||||
traversal.
|
||||
|
||||
@@ -31,7 +31,7 @@ literally reverse traversal by relation. The built-in reader only approximates i
|
||||
with undirected two-hop expansion, and has no equivalent verb, so `affected` is
|
||||
skipped on the fallback path.
|
||||
|
||||
**`gsd-tools graphify status` now returns `graph_path`.** The CLI takes the graph
|
||||
**`msd-tools graphify status` now returns `graph_path`.** The CLI takes the graph
|
||||
location as `--graph`, and the prompts must not re-derive
|
||||
`.planning/graphs/graph.json` for it — that would point the CLI at a
|
||||
non-existent local mirror in exactly the umbrella multi-repo setup
|
||||
@@ -43,7 +43,7 @@ default location.
|
||||
|
||||
**Known limits:**
|
||||
- **The two paths return different shapes.** `graphify query` emits prose and has
|
||||
no `--json` flag; `gsd-tools graphify query` emits JSON with per-edge
|
||||
no `--json` flag; `msd-tools graphify query` emits JSON with per-edge
|
||||
confidence tiers and `budget_met`/`budget_estimate`. Both are consumed by a
|
||||
model, and nothing machine-parses this block, but the prompts now say so
|
||||
explicitly instead of implying a stable shape.
|
||||
|
||||
@@ -6,7 +6,7 @@ group: v1.41.0 Features
|
||||
|
||||
**Purpose:** Surface whether the architecture graph was built from the current commit or an older one, complementing the existing mtime-based stale signal.
|
||||
|
||||
**Command:** `/gsd-graphify status`
|
||||
**Command:** `/msd-graphify status`
|
||||
|
||||
**New fields returned (graphify v0.7+ graphs):**
|
||||
|
||||
|
||||
@@ -4,16 +4,16 @@ title: GSD-2 Reverse Migration
|
||||
group: v1.35.0 Features
|
||||
---
|
||||
|
||||
**Command:** `/gsd-import --from-gsd2 [--dry-run] [--force] [--path <dir>]`
|
||||
**Command:** `/msd-import --from-gsd2 [--dry-run] [--force] [--path <dir>]`
|
||||
|
||||
**Purpose:** Migrate a project from GSD-2 format (`.gsd/` directory with Milestone→Slice→Task hierarchy) back to the v1 `.planning/` format, restoring full compatibility with all GSD v1 commands.
|
||||
**Purpose:** Migrate a project from GSD-2 format (`.gsd/` directory with Milestone→Slice→Task hierarchy) back to the v1 `.planning/` format, restoring full compatibility with all MSD v1 commands.
|
||||
|
||||
**Requirements:**
|
||||
- REQ-FROM-GSD2-01: Importer MUST read `.gsd/` from the specified or current directory
|
||||
- REQ-FROM-GSD2-02: Milestone→Slice hierarchy MUST be flattened to sequential phase numbers (M001/S01→phase 01, M001/S02→phase 02, M002/S01→phase 03, etc.)
|
||||
- REQ-FROM-GSD2-03: System MUST guard against overwriting an existing `.planning/` directory without `--force`
|
||||
- REQ-FROM-GSD2-04: `--dry-run` MUST preview all changes without writing any files
|
||||
- REQ-FROM-GSD2-05: Migration MUST produce `PROJECT.md`, `REQUIREMENTS.md`, `ROADMAP.md`, `STATE.md`, and sequential phase directories
|
||||
- REQ-FROM-MSD2-01: Importer MUST read `.gsd/` from the specified or current directory
|
||||
- REQ-FROM-MSD2-02: Milestone→Slice hierarchy MUST be flattened to sequential phase numbers (M001/S01→phase 01, M001/S02→phase 02, M002/S01→phase 03, etc.)
|
||||
- REQ-FROM-MSD2-03: System MUST guard against overwriting an existing `.planning/` directory without `--force`
|
||||
- REQ-FROM-MSD2-04: `--dry-run` MUST preview all changes without writing any files
|
||||
- REQ-FROM-MSD2-05: Migration MUST produce `PROJECT.md`, `REQUIREMENTS.md`, `ROADMAP.md`, `STATE.md`, and sequential phase directories
|
||||
|
||||
**Flags:**
|
||||
|
||||
|
||||
@@ -1,14 +1,14 @@
|
||||
---
|
||||
id: 101
|
||||
title: Hard Stop Safety Gates in /gsd-progress --next
|
||||
title: Hard Stop Safety Gates in /msd-progress --next
|
||||
group: v1.34.0 Features
|
||||
---
|
||||
|
||||
**Command:** `/gsd-progress --next`
|
||||
**Command:** `/msd-progress --next`
|
||||
|
||||
**Purpose:** Prevent `/gsd-progress --next` from entering runaway loops by adding hard stop safety gates and a consecutive-call guard that interrupts autonomous chaining when repeated identical steps are detected.
|
||||
**Purpose:** Prevent `/msd-progress --next` from entering runaway loops by adding hard stop safety gates and a consecutive-call guard that interrupts autonomous chaining when repeated identical steps are detected.
|
||||
|
||||
**Requirements:**
|
||||
- REQ-NEXT-GATE-01: `/gsd-progress --next` MUST track consecutive same-step calls
|
||||
- REQ-NEXT-GATE-01: `/msd-progress --next` MUST track consecutive same-step calls
|
||||
- REQ-NEXT-GATE-02: On repeated same-step, system MUST present a hard stop gate to the user
|
||||
- REQ-NEXT-GATE-03: User MUST explicitly confirm to continue past a hard stop gate
|
||||
@@ -4,7 +4,7 @@ title: Health Validation
|
||||
group: Quality Assurance Features
|
||||
---
|
||||
|
||||
**Command:** `/gsd-health [--repair] [--backfill]`
|
||||
**Command:** `/msd-health [--repair] [--backfill]`
|
||||
|
||||
**Purpose:** Validate `.planning/` directory integrity and auto-repair issues.
|
||||
|
||||
|
||||
@@ -18,17 +18,17 @@ group: Infrastructure Features
|
||||
|
||||
**Statusline Display:**
|
||||
```text
|
||||
[⬆ /gsd-update │] model │ [current task │] directory [█████░░░░░ 50%]
|
||||
[⬆ /msd-update │] model │ [current task │] directory [█████░░░░░ 50%]
|
||||
```
|
||||
|
||||
Color coding: <50% green, <65% yellow, <80% orange, ≥80% red with skull emoji
|
||||
|
||||
**Update Banner (opt-in, when GSD statusline isn't used):**
|
||||
**Update Banner (opt-in, when MSD statusline isn't used):**
|
||||
|
||||
When the user declines (or keeps a non-GSD) statusline, the installer offers a SessionStart banner that surfaces update availability without occupying statusline real estate. The banner reads `~/.cache/gsd/gsd-update-check.json` (written by `gsd-check-update-worker.js`) and emits one line only when an update is available:
|
||||
When the user declines (or keeps a non-MSD) statusline, the installer offers a SessionStart banner that surfaces update availability without occupying statusline real estate. The banner reads `~/.cache/msd/msd-update-check.json` (written by `msd-check-update-worker.js`) and emits one line only when an update is available:
|
||||
|
||||
```text
|
||||
GSD update available: 1.39.0 → 1.40.0. Run /gsd-update.
|
||||
MSD update available: 1.39.0 → 1.40.0. Run /msd-update.
|
||||
```
|
||||
|
||||
The banner is silent when up-to-date and rate-limits "check failed" diagnostics to once per 24 hours. Removed cleanly by `npx @opengsd/gsd-core --uninstall` or by deleting the SessionStart entry that references `gsd-update-banner.js`.
|
||||
The banner is silent when up-to-date and rate-limits "check failed" diagnostics to once per 24 hours. Removed cleanly by `npx @golem15/msd-core --uninstall` or by deleting the SessionStart entry that references `msd-update-banner.js`.
|
||||
|
||||
@@ -25,27 +25,27 @@ integer follows `process.exit(` in its outer `catch`.
|
||||
migration, not a behavior change.
|
||||
- `hooks/lib/cli-exit.js` and `hooks/lib/exit-code-registry.js` are new,
|
||||
generated, git-tracked copies of the exit-code seam (`src/cli-exit.cts` /
|
||||
`gsd-core/bin/shared/exit-codes.json`), so a shipped hook can terminate
|
||||
correctly on a raw, unbuilt clone without depending on `gsd-core/bin/lib/`
|
||||
`msd-core/bin/shared/exit-codes.json`), so a shipped hook can terminate
|
||||
correctly on a raw, unbuilt clone without depending on `msd-core/bin/lib/`
|
||||
tsc output. Generated by `scripts/gen-hooks-cli-exit.cjs` and
|
||||
`scripts/gen-exit-code-registry.cjs`, both `--check`ed by
|
||||
`npm run lint:generated-sync`.
|
||||
- `terminateNow` gained an optional third argument, `stderrPayload`, so a
|
||||
deny can send a full JSON body to stdout and a distinct plain-text reason
|
||||
to stderr — needed because `gsd-write-guard.js` (Kimi's native hook bus
|
||||
to stderr — needed because `msd-write-guard.js` (Kimi's native hook bus
|
||||
reads stderr verbatim back to the model) always sent only the bare reason
|
||||
string on fd 2. The two streams are now written in independent try/catch
|
||||
blocks: previously a payload that failed to serialize on fd 1 aborted
|
||||
before fd 2 ever wrote, producing a deny with an empty stderr reason.
|
||||
- Two hooks are deliberately **not** migrated to `deny()`:
|
||||
`gsd-read-injection-scanner.js` (PostToolUse — its harness reads the block
|
||||
`msd-read-injection-scanner.js` (PostToolUse — its harness reads the block
|
||||
decision from the JSON response body, not the exit code) and
|
||||
`gsd-cursor-subagent-start.js` (follows Cursor's own `subagentStart`
|
||||
`msd-cursor-subagent-start.js` (follows Cursor's own `subagentStart`
|
||||
protocol, which reads `permission: "deny"` from the JSON body at exit 0).
|
||||
Both still use `allow()`/`crash()` for their no-op and crash paths.
|
||||
- `gsd-phase-boundary.sh`, `gsd-session-state.sh`, and
|
||||
`gsd-validate-commit.sh` gained `set -euo pipefail`, and
|
||||
`gsd-validate-commit.sh`'s three swallow-and-pass sites (the opt-in config
|
||||
- `msd-phase-boundary.sh`, `msd-session-state.sh`, and
|
||||
`msd-validate-commit.sh` gained `set -euo pipefail`, and
|
||||
`msd-validate-commit.sh`'s three swallow-and-pass sites (the opt-in config
|
||||
read, JSON command extraction, and the `isGitSubcommand` classifier) now
|
||||
distinguish a genuine negative from "could not run" — on the latter they
|
||||
emit a stderr diagnostic and exit 0 instead of silently allowing every
|
||||
|
||||
@@ -4,7 +4,7 @@ title: Improved Prompt Injection Scanner
|
||||
group: v1.34.0 Features
|
||||
---
|
||||
|
||||
**Hook:** `gsd-prompt-guard.js`, `gsd-read-injection-scanner.js`
|
||||
**Hook:** `msd-prompt-guard.js`, `msd-read-injection-scanner.js`
|
||||
**Script:** `scripts/prompt-injection-scan.sh`, `scripts/base64-scan.sh`
|
||||
|
||||
**Purpose:** Defense-in-depth detection of prompt injection attempts in planning artifacts and ingested content. Live hooks inline their own pattern subsets for hook independence (they do not import from `security.cts`). The CI scanner (`scanForInjection` in `security.cts`) provides a centralized engine for codebase-wide scanning in tests.
|
||||
@@ -23,4 +23,4 @@ group: v1.34.0 Features
|
||||
| nothing in scope | `NO_INPUT` | the diff resolved and was genuinely empty — e.g. a docs-only PR |
|
||||
| could not scan | `UNAVAILABLE` | the file list was never established: a bad ref, no repository, or a repository with no commits |
|
||||
|
||||
Codes come from the exit-code registry ([ADR-3889](adr/3889-process-exit-contract.md)), sourced from `gsd-core/bin/shared/exit-codes.sh`, never written into the scripts. Every one is non-zero, so a caller written `if ! scanner; then` behaves identically for a clean scan and trips for everything else — this can turn a false green red, never a red green. `.github/workflows/security-scan.yml` treats *nothing in scope* as a pass and *could not scan* as a failure; previously the latter passed silently, having scanned nothing.
|
||||
Codes come from the exit-code registry ([ADR-3889](adr/3889-process-exit-contract.md)), sourced from `msd-core/bin/shared/exit-codes.sh`, never written into the scripts. Every one is non-zero, so a caller written `if ! scanner; then` behaves identically for a clean scan and trips for everything else — this can turn a false green red, never a red green. `.github/workflows/security-scan.yml` treats *nothing in scope* as a pass and *could not scan* as a failure; previously the latter passed silently, having scanned nothing.
|
||||
|
||||
@@ -10,7 +10,7 @@ group: v1.42.1 Features
|
||||
- First-time baseline migration records managed files.
|
||||
- Legacy stale-file cleanup uses ownership evidence before deleting or rewriting.
|
||||
- User-owned artifacts are preserved.
|
||||
- Ambiguous GSD-looking files block with a clear report instead of being silently overwritten.
|
||||
- Ambiguous MSD-looking files block with a clear report instead of being silently overwritten.
|
||||
- Migration plans support dry-run reporting and rollback protection.
|
||||
|
||||
**Requirements:**
|
||||
|
||||
@@ -6,7 +6,7 @@ group: v1.29 Features
|
||||
|
||||
**Part of:** `docs/`
|
||||
|
||||
**Purpose:** Provide GSD documentation in Portuguese, Korean, and Japanese.
|
||||
**Purpose:** Provide MSD documentation in Portuguese, Korean, and Japanese.
|
||||
|
||||
**Requirements:**
|
||||
- REQ-I18N-01: Documentation MUST be available in Portuguese (pt), Korean (ko), and Japanese (ja)
|
||||
|
||||
@@ -4,16 +4,16 @@ title: Issue-Driven Orchestration Guide
|
||||
group: v1.41.0 Features
|
||||
---
|
||||
|
||||
**Purpose:** Document a recipe for driving the full GSD workflow from a GitHub / Linear / Jira issue, mapping tracker-centric concepts onto existing GSD primitives.
|
||||
**Purpose:** Document a recipe for driving the full MSD workflow from a GitHub / Linear / Jira issue, mapping tracker-centric concepts onto existing MSD primitives.
|
||||
|
||||
**Document:** [`docs/issue-driven-orchestration.md`](issue-driven-orchestration.md)
|
||||
|
||||
**Covered workflow:**
|
||||
1. Create an isolated workspace per issue (`/gsd-workspace --new`)
|
||||
2. Run the manager dashboard to get oriented (`/gsd-manager`)
|
||||
3. Execute autonomously (`/gsd-autonomous`)
|
||||
4. Verify and review (`/gsd-verify-work`, `/gsd-review`)
|
||||
5. Ship and close the issue (`/gsd-ship`)
|
||||
1. Create an isolated workspace per issue (`/msd-workspace --new`)
|
||||
2. Run the manager dashboard to get oriented (`/msd-manager`)
|
||||
3. Execute autonomously (`/msd-autonomous`)
|
||||
4. Verify and review (`/msd-verify-work`, `/msd-review`)
|
||||
5. Ship and close the issue (`/msd-ship`)
|
||||
|
||||
No new commands or daemon process — purely a documentation artifact that maps existing primitives onto a tracker-driven workflow.
|
||||
|
||||
|
||||
@@ -4,16 +4,16 @@ title: Knowledge Graph Integration
|
||||
group: v1.37.0 Features
|
||||
---
|
||||
|
||||
**Purpose:** Build, query, and inspect a lightweight knowledge graph of the project in `.planning/graphs/`. Opt-in per project. Exposed as the `/gsd-graphify` user-facing command and the `gsd-tools.cjs graphify …` programmatic verb family. Complements `/gsd-map-codebase --query` (snapshot-oriented) with a graph-oriented view of nodes and edges across commands, agents, workflows, and phases.
|
||||
**Purpose:** Build, query, and inspect a lightweight knowledge graph of the project in `.planning/graphs/`. Opt-in per project. Exposed as the `/msd-graphify` user-facing command and the `msd-tools.cjs graphify …` programmatic verb family. Complements `/msd-map-codebase --query` (snapshot-oriented) with a graph-oriented view of nodes and edges across commands, agents, workflows, and phases.
|
||||
|
||||
**Requirements:**
|
||||
- REQ-GRAPH-01: Opt-in via `graphify.enabled: true` in `.planning/config.json`. When disabled, `/gsd-graphify` prints an activation hint and stops without writing.
|
||||
- REQ-GRAPH-02: Slash-command `/gsd-graphify` exposes subcommands `build`, `query <term>`, `status`, `diff`. The programmatic CLI `node gsd-tools.cjs graphify …` additionally exposes `snapshot`, which is also invoked automatically as the final step of `graphify build`.
|
||||
- REQ-GRAPH-01: Opt-in via `graphify.enabled: true` in `.planning/config.json`. When disabled, `/msd-graphify` prints an activation hint and stops without writing.
|
||||
- REQ-GRAPH-02: Slash-command `/msd-graphify` exposes subcommands `build`, `query <term>`, `status`, `diff`. The programmatic CLI `node msd-tools.cjs graphify …` additionally exposes `snapshot`, which is also invoked automatically as the final step of `graphify build`.
|
||||
- REQ-GRAPH-03: Build runs within the configurable `graphify.build_timeout` (seconds); exceeding the timeout aborts cleanly without leaving a partial graph.
|
||||
- REQ-GRAPH-04: `graphify.cjs` falls back to `graph.links` when `graph.edges` is absent so older graph artifacts keep rendering.
|
||||
- REQ-GRAPH-05: Graphify is invoked through `gsd-tools.cjs graphify ...` command handlers.
|
||||
- REQ-GRAPH-05: Graphify is invoked through `msd-tools.cjs graphify ...` command handlers.
|
||||
- REQ-GRAPH-06: The knowledge-graph location is configurable via `graphify.graph_path` (issue #1825) so one umbrella-level cross-repo graph can serve multiple sibling projects; `query`/`status`/`diff` read the configured graph (relative to project root), with a byte-identical `.planning/graphs/` default when unset.
|
||||
- REQ-GRAPH-07: `status` reports the resolved graph location as `graph_path` — the same absolute path `query`/`diff` read, after the `graphify.graph_path` override is applied — so a caller shelling out to the `graphify` CLI passes it as `--graph` instead of re-deriving the default location (issue #4836).
|
||||
|
||||
**Configuration:** `graphify.enabled`, `graphify.build_timeout`, `graphify.graph_path`
|
||||
**Reference files:** `commands/gsd/graphify.md`, `bin/lib/graphify.cjs`
|
||||
**Reference files:** `commands/msd/graphify.md`, `bin/lib/graphify.cjs`
|
||||
|
||||
@@ -6,9 +6,9 @@ group: v1.7.0 Features
|
||||
|
||||
**Config key:** `workflow.live_dom_uat` (default `false`)
|
||||
|
||||
**Purpose:** A phase with a live-UI acceptance criterion could not be finished by the agent that executed it. `gsd-executor` carries no browser tools, so it correctly returned a `checkpoint:human-action` — even though the work was not human-only, just tool-less. Every such phase quietly degraded from *executed by the executor* to *executed, then finished by hand in the orchestrator*, and the plan's `autonomous: false` marker could not distinguish "a human must judge this" from "the executor lacks the tool" (#2856).
|
||||
**Purpose:** A phase with a live-UI acceptance criterion could not be finished by the agent that executed it. `msd-executor` carries no browser tools, so it correctly returned a `checkpoint:human-action` — even though the work was not human-only, just tool-less. Every such phase quietly degraded from *executed by the executor* to *executed, then finished by hand in the orchestrator*, and the plan's `autonomous: false` marker could not distinguish "a human must judge this" from "the executor lacks the tool" (#2856).
|
||||
|
||||
**Behavior:** A default-off capability owns one boolean key, one agent, and one additive step. When the key is on, `gsd-dom-verifier` runs at `execute:wave:post` and writes `{phase}-DOM-VERIFY.md`; the orchestrator's `automated_ui_verification` step additionally considers `mcp__chrome-devtools__*` / `mcp__claude-in-chrome__*` when present.
|
||||
**Behavior:** A default-off capability owns one boolean key, one agent, and one additive step. When the key is on, `msd-dom-verifier` runs at `execute:wave:post` and writes `{phase}-DOM-VERIFY.md`; the orchestrator's `automated_ui_verification` step additionally considers `mcp__chrome-devtools__*` / `mcp__claude-in-chrome__*` when present.
|
||||
|
||||
**The executor's tool surface is unchanged in every configuration.** Widening it was the reported proposal and was refused: for a first-party agent the static `tools:` list is the only control that exists — no capability can grant tools to one ([ADR-1244](adr/1244-capability-ecosystem.md) D2), no hook kind grants tool permissions ([ADR-857](adr/857-capability-system.md) D4), and there is no per-dispatch override. Browser reach lives in one purpose-built agent that carries no `Bash`.
|
||||
|
||||
@@ -16,7 +16,7 @@ group: v1.7.0 Features
|
||||
|
||||
**The pre-existing Playwright path is untouched.** `mcp__playwright__*` keeps the gating it already had (presence plus an active UI phase). Pulling it behind a new default-off key would have silently removed working behavior from current users on upgrade; the key gates only the newly added families.
|
||||
|
||||
**It tolerates the browser-profile lock rather than coordinating it.** `chrome-devtools-mcp` holds an exclusive lock on its profile, so parallel waves collide. `--isolated` is a flag on the operator's own MCP server registration — GSD neither launches that server nor passes its arguments — so the verifier reports `could_not_look` / `profile_locked`, names the flag, and stops. No retry, no held-up wave.
|
||||
**It tolerates the browser-profile lock rather than coordinating it.** `chrome-devtools-mcp` holds an exclusive lock on its profile, so parallel waves collide. `--isolated` is a flag on the operator's own MCP server registration — MSD neither launches that server nor passes its arguments — so the verifier reports `could_not_look` / `profile_locked`, names the flag, and stops. No retry, no held-up wave.
|
||||
|
||||
**`nothing_to_report` is never conflated with `could_not_look`.** A report claiming no issues when it never opened a browser is worse than no report; the artifact carries a closed reason enum so the two are always distinguishable.
|
||||
|
||||
|
||||
@@ -4,18 +4,18 @@ title: Machine-Readable State Contract (`.planning/state.json`)
|
||||
group: v1.7.0 Features
|
||||
---
|
||||
|
||||
**Purpose:** External tools that display GSD project state — a workbench, a dashboard, an editor extension — had to parse `STATE.md` and `ROADMAP.md` heuristically. Those are human surfaces: their shape drifts as the templates evolve, and every consumer ends up carrying a brittle second parser that silently reports wrong numbers after an upgrade. GSD now publishes a small, versioned JSON snapshot instead, so the reader binds to a contract rather than to markdown (#3227).
|
||||
**Purpose:** External tools that display MSD project state — a workbench, a dashboard, an editor extension — had to parse `STATE.md` and `ROADMAP.md` heuristically. Those are human surfaces: their shape drifts as the templates evolve, and every consumer ends up carrying a brittle second parser that silently reports wrong numbers after an upgrade. MSD now publishes a small, versioned JSON snapshot instead, so the reader binds to a contract rather than to markdown (#3227).
|
||||
|
||||
**Behavior:** At every step boundary, GSD writes `.planning/state.json` — `contract`, `flavor`, `milestone`, `phases[]`, `next`, `updated_at`. The boundaries are `state begin-phase` / `planned-phase` / `advance-plan` / `complete-phase` / `milestone-switch`, `phase add` / `add-batch` / `insert` / `remove` / `complete`, and `milestone complete`. The write is best-effort and completely invisible to the command that triggered it: it cannot change an exit code, cannot change stdout, and cannot fail a workflow. Readers prefer the file when it is present and fall back to markdown when it is not.
|
||||
**Behavior:** At every step boundary, MSD writes `.planning/state.json` — `contract`, `flavor`, `milestone`, `phases[]`, `next`, `updated_at`. The boundaries are `state begin-phase` / `planned-phase` / `advance-plan` / `complete-phase` / `milestone-switch`, `phase add` / `add-batch` / `insert` / `remove` / `complete`, and `milestone complete`. The write is best-effort and completely invisible to the command that triggered it: it cannot change an exit code, cannot change stdout, and cannot fail a workflow. Readers prefer the file when it is present and fall back to markdown when it is not.
|
||||
|
||||
**Requirements:**
|
||||
- REQ-SC-01: `contract` is semver, `1.0.0` at introduction. Consumers gate on the MAJOR version; `1.x` changes are additive only. Every key is ALWAYS present — an unknown value is `null`, never an omitted key, because an omitted key is itself an observable a consumer would bind to.
|
||||
- REQ-SC-02: `phases[]` carries `{number, name, status}` per phase, `status` drawn from exactly `complete | in_progress | pending`. `number` is a string (`"01"` and `"2.1"` are both real ids and neither survives a number cast); `name` is `null` when the roadmap gives a phase no name, never a fabricated placeholder.
|
||||
- REQ-SC-03: `next` is the same recommended action the `/gsd` front door routes, derived from the smart-entry classifier itself rather than from a second copy of its routing table.
|
||||
- REQ-SC-04: A missing `ROADMAP.md`, a missing or unreadable `.planning/`, an unwritable target, or any other failure NEVER errors the parent command. A directory that is not a GSD project stays untouched — the publisher will not create `.planning/` in order to publish into it.
|
||||
- REQ-SC-03: `next` is the same recommended action the `/msd` front door routes, derived from the smart-entry classifier itself rather than from a second copy of its routing table.
|
||||
- REQ-SC-04: A missing `ROADMAP.md`, a missing or unreadable `.planning/`, an unwritable target, or any other failure NEVER errors the parent command. A directory that is not a MSD project stays untouched — the publisher will not create `.planning/` in order to publish into it.
|
||||
- REQ-SC-05: The skills own the file; readers never write it. It is a derived cache — safe to delete, regenerated at the next boundary.
|
||||
|
||||
**Composed, never re-derived.** Milestone identity comes from `getMilestoneInfo`; phase rows from `locateProgressTable`, the same `## Progress` locator the progress counters use, so `state.json` can never disagree with the rest of GSD about which phases are complete; the recommended action from `classifyProject`. This module introduces no second answer to any question GSD already answers.
|
||||
**Composed, never re-derived.** Milestone identity comes from `getMilestoneInfo`; phase rows from `locateProgressTable`, the same `## Progress` locator the progress counters use, so `state.json` can never disagree with the rest of MSD about which phases are complete; the recommended action from `classifyProject`. This module introduces no second answer to any question MSD already answers.
|
||||
|
||||
**Why it does not reuse `planning inspect`'s schema.** The two surfaces answer different questions and have opposite shapes. `planning inspect` is a rich, diagnostic-carrying **pull** query a consumer runs; this is a small **push** artifact a consumer watches. Publishing `planning inspect`'s payload at every `phase add` would mean opening every plan, summary and requirements document on a hot path, and freezing a much larger surface as a contract.
|
||||
|
||||
|
||||
@@ -4,7 +4,7 @@ title: Manager Dashboard
|
||||
group: v1.28 Features
|
||||
---
|
||||
|
||||
**Command:** `/gsd-manager`
|
||||
**Command:** `/msd-manager`
|
||||
|
||||
**Purpose:** Interactive command center for managing multiple phases from one terminal.
|
||||
|
||||
|
||||
@@ -6,14 +6,14 @@ group: v1.43.0 Features
|
||||
|
||||
**Purpose:** Opt-in cross-session and cross-project memory via the [MemPalace](https://github.com/MemPalace/mempalace) external service (local-first, MCP + CLI). Wires deliberate recall before discuss/plan and verbatim capture + temporal-KG sync at phase boundaries through the ADR-857 capability mechanism. Default-resilient: disabled by default, every hook is `onError: skip`, and an absent MemPalace installation leaves the loop unchanged.
|
||||
|
||||
**Commands:** `/gsd-mempalace-recall`, `/gsd-mempalace-capture`
|
||||
**Commands:** `/msd-mempalace-recall`, `/msd-mempalace-capture`
|
||||
|
||||
**Requirements:**
|
||||
- REQ-MP-01: Opt-in via `mempalace.enabled: true`. Default `false` — the loop is unchanged when unset.
|
||||
- REQ-MP-02: At `plan:pre`, skill `mempalace-recall` produces `MEMORY-RECALL.md` from prior decisions, patterns, and surprises retrieved via wake-up + semantic search + KG timeline. When MemPalace is unreachable, writes an "unavailable" stub and continues.
|
||||
- REQ-MP-03: At `discuss:post`, `plan:post`, and `verify:post`, skill `mempalace-capture` files the phase artifact verbatim into the appropriate MemPalace room (`decisions`, `planning`, `milestones`). Capture is idempotent via `mempalace_check_duplicate`.
|
||||
- REQ-MP-04: At `ship:post`, agent `gsd-mempalace-curator` writes a diary entry, proposes cross-project tunnels (when `mempalace.cross_project_tunnels: true`), and runs wing-scoped sync pruning.
|
||||
- REQ-MP-05: `mempalace.memory_mode` has three wired values: `augment` (default — palace is an additive recall layer alongside GSD native memory, which stays authoritative), `kg_backend` (knowledge-graph queries resolve against the palace's temporal KG as the primary source, `.planning/graphs/` as fallback; non-KG drawer recall stays additive), `replace` (recall resolves through the palace as the source of truth, native memory as fallback). Every mode is `onError:skip` and default-resilient — an unreachable palace degrades to native memory and GSD keeps writing `.planning/graphs/`, so no mode loses memory. Cross-mode migration of existing `.planning/graphs/` into the palace is out of scope (not yet implemented).
|
||||
- REQ-MP-04: At `ship:post`, agent `msd-mempalace-curator` writes a diary entry, proposes cross-project tunnels (when `mempalace.cross_project_tunnels: true`), and runs wing-scoped sync pruning.
|
||||
- REQ-MP-05: `mempalace.memory_mode` has three wired values: `augment` (default — palace is an additive recall layer alongside MSD native memory, which stays authoritative), `kg_backend` (knowledge-graph queries resolve against the palace's temporal KG as the primary source, `.planning/graphs/` as fallback; non-KG drawer recall stays additive), `replace` (recall resolves through the palace as the source of truth, native memory as fallback). Every mode is `onError:skip` and default-resilient — an unreachable palace degrades to native memory and MSD keeps writing `.planning/graphs/`, so no mode loses memory. Cross-mode migration of existing `.planning/graphs/` into the palace is out of scope (not yet implemented).
|
||||
- REQ-MP-06: Every hook is `onError: skip`. No hook carries `blocking: true`. Memory never halts or fails a phase.
|
||||
- REQ-MP-07: Interactive runs prefer MCP tools; headless/cron runs prefer the MemPalace CLI (`mempalace wake-up`, `mempalace search`, `mempalace mine`, `mempalace sync`).
|
||||
- REQ-MP-08: `mempalace.auto_capture_hooks` is **forward-declared and not yet functional**. No native Claude Code hooks (`stop`, `precompact`, `session-start`) are installed by this key; the capability's hooks array is empty. This key is reserved for the future "Connected Capability" phase. Default `false`.
|
||||
|
||||
@@ -4,7 +4,7 @@ title: Milestone Management
|
||||
group: Core Features
|
||||
---
|
||||
|
||||
**Commands:** `/gsd-audit-milestone`, `/gsd-complete-milestone`, `/gsd-new-milestone [name]`
|
||||
**Commands:** `/msd-audit-milestone`, `/msd-complete-milestone`, `/msd-new-milestone [name]`
|
||||
|
||||
**Purpose:** Verify milestone completion, archive, tag release, and start the next development cycle.
|
||||
|
||||
|
||||
@@ -4,7 +4,7 @@ title: Milestone Summary
|
||||
group: v1.28 Features
|
||||
---
|
||||
|
||||
**Command:** `/gsd-milestone-summary [version]`
|
||||
**Command:** `/msd-milestone-summary [version]`
|
||||
|
||||
**Purpose:** Generate comprehensive project summary from milestone artifacts for team onboarding.
|
||||
|
||||
|
||||
@@ -4,7 +4,7 @@ title: Milestone Tag Creation Toggle
|
||||
group: v1.42.1 Features
|
||||
---
|
||||
|
||||
**Command:** `/gsd-complete-milestone`
|
||||
**Command:** `/msd-complete-milestone`
|
||||
|
||||
**Config key:** `git.create_tag`
|
||||
|
||||
|
||||
@@ -6,6 +6,6 @@ group: v1.7.0 Features
|
||||
|
||||
**Purpose:** Refresh the default model tiers and how models are surfaced.
|
||||
|
||||
**Behavior:** Codex/OpenAI defaults advance to the **GPT-5.6 family (Sol / Terra / Luna)** (#2122); the verbose `(1M context)` model suffix collapses to a compact `(1M)` badge (#2160). GSD warns when model config changes without re-running the installer on static-frontmatter runtimes such as Codex and OpenCode (#1688).
|
||||
**Behavior:** Codex/OpenAI defaults advance to the **GPT-5.6 family (Sol / Terra / Luna)** (#2122); the verbose `(1M context)` model suffix collapses to a compact `(1M)` badge (#2160). MSD warns when model config changes without re-running the installer on static-frontmatter runtimes such as Codex and OpenCode (#1688).
|
||||
|
||||
**Reference:** [Configuration](CONFIGURATION.md) · [Configure model profiles](how-to/configure-model-profiles.md)
|
||||
|
||||
@@ -4,7 +4,7 @@ title: Model Profiles
|
||||
group: Context Engineering Features
|
||||
---
|
||||
|
||||
**Command:** `/gsd-config --profile <quality|balanced|budget|adaptive|inherit>`
|
||||
**Command:** `/msd-config --profile <quality|balanced|budget|adaptive|inherit>`
|
||||
|
||||
**Purpose:** Control which AI model each agent uses, balancing quality vs cost.
|
||||
|
||||
@@ -21,15 +21,15 @@ group: Context Engineering Features
|
||||
|
||||
| Agent | `quality` | `balanced` | `budget` | `inherit` |
|
||||
|-------|-----------|------------|----------|-----------|
|
||||
| gsd-planner | Opus | Opus | Sonnet | Inherit |
|
||||
| gsd-roadmapper | Opus | Sonnet | Sonnet | Inherit |
|
||||
| gsd-executor | Opus | Sonnet | Sonnet | Inherit |
|
||||
| gsd-phase-researcher | Opus | Sonnet | Haiku | Inherit |
|
||||
| gsd-project-researcher | Opus | Sonnet | Haiku | Inherit |
|
||||
| gsd-research-synthesizer | Sonnet | Sonnet | Haiku | Inherit |
|
||||
| gsd-debugger | Opus | Sonnet | Sonnet | Inherit |
|
||||
| gsd-codebase-mapper | Sonnet | Haiku | Haiku | Inherit |
|
||||
| gsd-verifier | Sonnet | Sonnet | Haiku | Inherit |
|
||||
| gsd-plan-checker | Sonnet | Sonnet | Haiku | Inherit |
|
||||
| gsd-integration-checker | Sonnet | Sonnet | Haiku | Inherit |
|
||||
| gsd-nyquist-auditor | Sonnet | Sonnet | Haiku | Inherit |
|
||||
| msd-planner | Opus | Opus | Sonnet | Inherit |
|
||||
| msd-roadmapper | Opus | Sonnet | Sonnet | Inherit |
|
||||
| msd-executor | Opus | Sonnet | Sonnet | Inherit |
|
||||
| msd-phase-researcher | Opus | Sonnet | Haiku | Inherit |
|
||||
| msd-project-researcher | Opus | Sonnet | Haiku | Inherit |
|
||||
| msd-research-synthesizer | Sonnet | Sonnet | Haiku | Inherit |
|
||||
| msd-debugger | Opus | Sonnet | Sonnet | Inherit |
|
||||
| msd-codebase-mapper | Sonnet | Haiku | Haiku | Inherit |
|
||||
| msd-verifier | Sonnet | Sonnet | Haiku | Inherit |
|
||||
| msd-plan-checker | Sonnet | Sonnet | Haiku | Inherit |
|
||||
| msd-integration-checker | Sonnet | Sonnet | Haiku | Inherit |
|
||||
| msd-nyquist-auditor | Sonnet | Sonnet | Haiku | Inherit |
|
||||
|
||||
@@ -1,10 +1,10 @@
|
||||
---
|
||||
id: 3912
|
||||
title: gsd-tools Declares Outcomes, Pinned at v1
|
||||
title: msd-tools Declares Outcomes, Pinned at v1
|
||||
group: v1.7.0 Features
|
||||
---
|
||||
|
||||
**Purpose:** Give every `gsd-tools` terminating path a declared outcome name, and project that
|
||||
**Purpose:** Give every `msd-tools` terminating path a declared outcome name, and project that
|
||||
declaration through the versioned exit contract ([ADR-3889](../adr/3889-process-exit-contract.md)
|
||||
§4) — without changing a single exit code for a caller that has not opted in.
|
||||
|
||||
@@ -15,7 +15,7 @@ declaration through the versioned exit contract ([ADR-3889](../adr/3889-process-
|
||||
`ERROR_REASON` members (`src/io.cts`'s `REASON_TO_OUTCOME`). Under the default contract version
|
||||
`v1`, the declaration is recorded but `error()` still throws `ExitError(1)` unconditionally,
|
||||
byte-identical to every prior release. Under `v2` (`--exit-contract=v2` /
|
||||
`GSD_EXIT_CONTRACT=v2`), it throws `ExitError(projectOutcome(outcome, 'v2'))` instead — e.g.
|
||||
`MSD_EXIT_CONTRACT=v2`), it throws `ExitError(projectOutcome(outcome, 'v2'))` instead — e.g.
|
||||
`SDK_MISSING_ARG`/`SDK_UNKNOWN_COMMAND` project to `64` (`USAGE`), `CONFIG_KEY_NOT_FOUND` to `66`
|
||||
(`NO_INPUT`). All 278 call sites are untouched; 226 pass no reason and default to `UNKNOWN` ->
|
||||
`FAIL` -> exit `1` under both versions.
|
||||
@@ -44,7 +44,7 @@ declaration through the versioned exit contract ([ADR-3889](../adr/3889-process-
|
||||
ADR-2980 ratified `output({error})`'s exit-0 population on measured blast radius (`output` has 170
|
||||
direct callers) and Hyrum's Law grounds — a CLI exit code has no `/v2/` of its own, so normalizing
|
||||
it in place would have broken every caller already treating exit `0` as a soft signal. Its own
|
||||
"Revisit if" clause named the missing piece: *"a future `gsd-tools` major version provides a
|
||||
"Revisit if" clause named the missing piece: *"a future `msd-tools` major version provides a
|
||||
compatibility boundary that a CLI exit code otherwise lacks."* ADR-3889 §4 built exactly that
|
||||
boundary — a versioned projection selected by flag or env var, defaulting to today's behavior — and
|
||||
this phase is what wires `error()` and `output()` onto it. Declaring an outcome is unconditional and
|
||||
@@ -4,7 +4,7 @@ title: Multi-Runtime Installer Selection
|
||||
group: v1.28 Features
|
||||
---
|
||||
|
||||
**Part of:** `npx @opengsd/gsd-core`
|
||||
**Part of:** `npx @golem15/msd-core`
|
||||
|
||||
**Purpose:** Select multiple runtimes in a single interactive install session.
|
||||
|
||||
@@ -15,4 +15,4 @@ group: v1.28 Features
|
||||
**Process:**
|
||||
1. **Detect** — Identify available AI CLI runtimes on the system
|
||||
2. **Prompt** — Present multi-select interface for runtime selection
|
||||
3. **Install** — Configure GSD for all selected runtimes in a single session
|
||||
3. **Install** — Configure MSD for all selected runtimes in a single session
|
||||
|
||||
@@ -4,14 +4,14 @@ title: Multi-Runtime Support
|
||||
group: Infrastructure Features
|
||||
---
|
||||
|
||||
**Purpose:** Run GSD across multiple AI coding agent runtimes.
|
||||
**Purpose:** Run MSD across multiple AI coding agent runtimes.
|
||||
|
||||
**Requirements:**
|
||||
- REQ-RUNTIME-01: System MUST support Claude Code, OpenCode, Kilo, Codex, Copilot, Antigravity, Trae, Cline, Augment Code, CodeBuddy, Qwen Code
|
||||
- REQ-RUNTIME-02: Installer MUST transform content per runtime (tool names, paths, frontmatter)
|
||||
- REQ-RUNTIME-03: Installer MUST support interactive and non-interactive (`--claude --global`) modes
|
||||
- REQ-RUNTIME-04: Installer MUST support both global and local installation
|
||||
- REQ-RUNTIME-05: Uninstall MUST cleanly remove all GSD files without affecting other configurations
|
||||
- REQ-RUNTIME-05: Uninstall MUST cleanly remove all MSD files without affecting other configurations
|
||||
- REQ-RUNTIME-06: Installer MUST handle platform differences (Windows, macOS, Linux, WSL, Docker)
|
||||
- REQ-RUNTIME-07: Runtimes with lifecycle hook support MUST register per-turn context-headroom tracking events at install time
|
||||
- REQ-RUNTIME-08: Native packaging manifests MUST be version-stamped and enable runtime-native install/update/uninstall flows
|
||||
@@ -26,19 +26,19 @@ group: Infrastructure Features
|
||||
| Hook events | `SessionStart`, `PreToolUse`, `PostToolUse`, `SubagentStop`, `Stop`, `PreCompact`, `FileChanged` | N/A | N/A | `SessionStart`, `SubagentStart`, `Stop`, `PostToolUse` | `sessionStart` | N/A | `sessionStart`, `postToolUse` | N/A | `PreToolUse` | N/A | N/A | `SessionStart`, `PreToolUse`, `PostToolUse`, `SubagentStop`, `Stop`, `PreCompact` |
|
||||
| Config | `settings.json` | `opencode.json(c)` | `kilo.json(c)` | TOML | Instructions | Config | Config | Config | `.clinerules` | Config | Config | Config |
|
||||
|
||||
**Cursor artifact surfaces:** `gsd install --cursor` writes two artifact kinds:
|
||||
- `~/.cursor/skills/gsd-<name>/SKILL.md` — rich skills with YAML frontmatter, Cursor tool-name mapping, and adapter context header (existing surface)
|
||||
- `~/.cursor/commands/gsd-<name>.md` — plain markdown slash commands (no frontmatter) invocable via `/` in the Agent input (Cursor 1.6+)
|
||||
**Cursor artifact surfaces:** `msd install --cursor` writes two artifact kinds:
|
||||
- `~/.cursor/skills/msd-<name>/SKILL.md` — rich skills with YAML frontmatter, Cursor tool-name mapping, and adapter context header (existing surface)
|
||||
- `~/.cursor/commands/msd-<name>.md` — plain markdown slash commands (no frontmatter) invocable via `/` in the Agent input (Cursor 1.6+)
|
||||
|
||||
**Native skills emission (1.4.0):** Three runtimes now emit GSD as on-demand native skills (`skills/<name>/SKILL.md`) at install time, in addition to their existing command and agent surfaces. Skills respect the active install profile and are removed on uninstall.
|
||||
**Native skills emission (1.4.0):** Three runtimes now emit MSD as on-demand native skills (`skills/<name>/SKILL.md`) at install time, in addition to their existing command and agent surfaces. Skills respect the active install profile and are removed on uninstall.
|
||||
- **Cline** (global installs, Cline >= v3.48.0) — emits skills alongside the existing `.clinerules/` directory
|
||||
- **Kilo** — emits skills alongside `command/` and `agents/`
|
||||
- **OpenCode** — emits skills alongside its existing surfaces
|
||||
|
||||
**New slash-command surfaces (1.4.0):**
|
||||
- **CodeBuddy** — `/gsd-*` slash commands written to `~/.codebuddy/commands/`
|
||||
- **Augment** — `commands/gsd-<name>.md` written to `~/.augment/commands/`
|
||||
- **Cursor** (Cursor >= 1.6) — `.cursor/commands/gsd-<name>.md` so GSD appears in the `/` command menu
|
||||
- **CodeBuddy** — `/msd-*` slash commands written to `~/.codebuddy/commands/`
|
||||
- **Augment** — `commands/msd-<name>.md` written to `~/.augment/commands/`
|
||||
- **Cursor** (Cursor >= 1.6) — `.cursor/commands/msd-<name>.md` so MSD appears in the `/` command menu
|
||||
|
||||
**Cross-runtime lifecycle hooks (1.4.0):** Each supported runtime registers lifecycle hook events for per-turn context-headroom tracking and workflow state management. Notable registrations:
|
||||
- **Claude Code:** `SubagentStop`, `Stop`, `PreCompact` (context-headroom warnings), `FileChanged` (hot-reloads `.planning/config.json` mid-session)
|
||||
@@ -49,7 +49,7 @@ group: Infrastructure Features
|
||||
- **Copilot:** `sessionStart`
|
||||
|
||||
**Runtime-specific enrichments (1.4.0):**
|
||||
- Codex emits `service_tier: flex` for light-tier agents; GSD skills appear in the Codex `/skills` picker via `SKILL.md` (no `agents/openai.yaml` sidecar is emitted — doing so caused duplicate autocomplete entries, #1326)
|
||||
- Codex emits `service_tier: flex` for light-tier agents; MSD skills appear in the Codex `/skills` picker via `SKILL.md` (no `agents/openai.yaml` sidecar is emitted — doing so caused duplicate autocomplete entries, #1326)
|
||||
|
||||
**Native packaging:**
|
||||
- **Claude Code:** GSD Core ships a `.claude-plugin/plugin.json` manifest, enabling installation and lifecycle management via `claude plugin install|enable|disable|update gsd-core`. Commands load under the `/gsd-core:` namespace (e.g. `/gsd-core:plan-phase`), avoiding slash-command collisions with the classic npm installer which uses `/gsd:`. Always-on guard and update hooks are wired automatically via `hooks/hooks.json`. The plugin path is additive — the npm installer (`npx @opengsd/gsd-core`) remains fully supported.
|
||||
- **Claude Code:** MSD Core ships a `.claude-plugin/plugin.json` manifest, enabling installation and lifecycle management via `claude plugin install|enable|disable|update msd-core`. Commands load under the `/msd-core:` namespace (e.g. `/msd-core:plan-phase`), avoiding slash-command collisions with the classic npm installer which uses `/msd:`. Always-on guard and update hooks are wired automatically via `hooks/hooks.json`. The plugin path is additive — the npm installer (`npx @golem15/msd-core`) remains fully supported.
|
||||
|
||||
@@ -7,12 +7,12 @@ group: v1.40.0 Features
|
||||
**Purpose:** Replace the flat eager skill listing with a two-stage hierarchical routing layer. The model sees 6 namespace routers instead of 86 entries, selects a namespace, then routes to the sub-skill. Descriptions use pipe-separated keyword tags (≤ 60 chars) for routing density.
|
||||
|
||||
**Commands:**
|
||||
- `/gsd-workflow` — phase pipeline router (discuss / plan / execute / verify / phase / progress / next)
|
||||
- `/gsd-project` — project lifecycle (milestones, audits, summary)
|
||||
- `/gsd-quality` — quality gates (code review, debug, audit, security, eval, ui)
|
||||
- `/gsd-context` — codebase intelligence (map, graphify, docs, learnings)
|
||||
- `/gsd-manage` — config / workspace / workstreams / thread / update / ship / inbox
|
||||
- `/gsd-ideate` — exploration & capture (explore, sketch, spike, spec, capture)
|
||||
- `/msd-workflow` — phase pipeline router (discuss / plan / execute / verify / phase / progress / next)
|
||||
- `/msd-project` — project lifecycle (milestones, audits, summary)
|
||||
- `/msd-quality` — quality gates (code review, debug, audit, security, eval, ui)
|
||||
- `/msd-context` — codebase intelligence (map, graphify, docs, learnings)
|
||||
- `/msd-manage` — config / workspace / workstreams / thread / update / ship / inbox
|
||||
- `/msd-ideate` — exploration & capture (explore, sketch, spike, spec, capture)
|
||||
|
||||
**Token cost:**
|
||||
|
||||
@@ -22,7 +22,7 @@ group: v1.40.0 Features
|
||||
| Namespace meta-skills | 6 | ~120 |
|
||||
|
||||
**Requirements:**
|
||||
- REQ-NS-01: Six `commands/gsd/ns-*.md` namespace routers ship with pipe-separated keyword-tag descriptions (≤ 60 chars).
|
||||
- REQ-NS-01: Six `commands/msd/ns-*.md` namespace routers ship with pipe-separated keyword-tag descriptions (≤ 60 chars).
|
||||
- REQ-NS-02: Existing sub-skills are unchanged and still invocable directly — namespace skills are additive, not a replacement for direct slash forms.
|
||||
- REQ-NS-03: The body of each namespace router contains a routing table that maps user intent to the correct concrete sub-skill on the post-#2790 consolidated surface.
|
||||
- REQ-NS-04: Tests validate namespace files exist, include matching command `requires`, and reference only existing sub-skill files.
|
||||
|
||||
@@ -4,14 +4,14 @@ title: New Runtime Support (Cline, CodeBuddy, Qwen Code)
|
||||
group: v1.35.0 Features
|
||||
---
|
||||
|
||||
**Part of:** `npx @opengsd/gsd-core`
|
||||
**Part of:** `npx @golem15/msd-core`
|
||||
|
||||
**Purpose:** Extend GSD installation to Cline, CodeBuddy, and Qwen Code runtimes.
|
||||
**Purpose:** Extend MSD installation to Cline, CodeBuddy, and Qwen Code runtimes.
|
||||
|
||||
**Requirements:**
|
||||
- REQ-CLINE-02: Cline install MUST write `.clinerules` to `~/.cline/` (global) or `./.cline/` (local). No custom slash commands — rules-based integration only. Flag: `--cline`.
|
||||
- REQ-CODEBUDDY-01: CodeBuddy install MUST deploy skills to `~/.codebuddy/skills/gsd-*/SKILL.md` (emitted `user-invocable: false`), `/gsd-*` slash commands to `~/.codebuddy/commands/gsd-*.md`, and subagents to `~/.codebuddy/agents/gsd-*.md`. The commands surface is the sole `/` menu entry point. No `mcp.json` is written (gsd ships no MCP server). Flag: `--codebuddy`.
|
||||
- REQ-QWEN-01: Qwen Code install MUST deploy skills to `~/.qwen/skills/gsd-*/SKILL.md`, following the open standard used by Claude Code 2.1.88+. `QWEN_CONFIG_DIR` env var overrides the default path. Flag: `--qwen`.
|
||||
- REQ-CODEBUDDY-01: CodeBuddy install MUST deploy skills to `~/.codebuddy/skills/msd-*/SKILL.md` (emitted `user-invocable: false`), `/msd-*` slash commands to `~/.codebuddy/commands/msd-*.md`, and subagents to `~/.codebuddy/agents/msd-*.md`. The commands surface is the sole `/` menu entry point. No `mcp.json` is written (msd ships no MCP server). Flag: `--codebuddy`.
|
||||
- REQ-QWEN-01: Qwen Code install MUST deploy skills to `~/.qwen/skills/msd-*/SKILL.md`, following the open standard used by Claude Code 2.1.88+. `QWEN_CONFIG_DIR` env var overrides the default path. Flag: `--qwen`.
|
||||
|
||||
**Runtime summary:**
|
||||
|
||||
|
||||
@@ -4,9 +4,9 @@ title: New Runtime Support (Trae, Cline, Augment Code)
|
||||
group: v1.32 Features
|
||||
---
|
||||
|
||||
**Part of:** `npx @opengsd/gsd-core`
|
||||
**Part of:** `npx @golem15/msd-core`
|
||||
|
||||
**Purpose:** Extend GSD installation to Trae IDE, Cline, and Augment Code runtimes.
|
||||
**Purpose:** Extend MSD installation to Trae IDE, Cline, and Augment Code runtimes.
|
||||
|
||||
**Requirements:**
|
||||
- REQ-TRAE-01: Installer MUST support `--trae` flag for Trae IDE installation
|
||||
|
||||
@@ -9,7 +9,7 @@ input must not be absorbed into an output that reads as authoritative. A
|
||||
routine that drops data it could not read or could not resolve, and then
|
||||
reports a clean result anyway, turns a diagnosable gap into a confidently
|
||||
wrong answer. This closes four instances of that collapse found across
|
||||
`gsd-tools`.
|
||||
`msd-tools`.
|
||||
|
||||
**`intel query` no longer crashes past ~12000 levels of nesting (#3427).**
|
||||
`searchJsonEntries` / `matchesInValue` recursed with no depth bound at all —
|
||||
|
||||
@@ -4,7 +4,7 @@ title: Note Capture
|
||||
group: Planning Features
|
||||
---
|
||||
|
||||
**Command:** `/gsd-capture`
|
||||
**Command:** `/msd-capture`
|
||||
|
||||
**Purpose:** Zero-friction idea capture without interrupting workflow. Append timestamped notes, list all notes, or promote notes to structured todos.
|
||||
|
||||
|
||||
@@ -11,12 +11,12 @@ group: Quality Assurance Features
|
||||
- REQ-NYQ-02: System MUST map each requirement to a specific test command
|
||||
- REQ-NYQ-03: System MUST identify Wave 0 tasks (test scaffolding needed before implementation)
|
||||
- REQ-NYQ-04: Plan checker MUST enforce Nyquist compliance as 8th verification dimension
|
||||
- REQ-NYQ-05: System MUST support retroactive validation via `/gsd-validate-phase`
|
||||
- REQ-NYQ-05: System MUST support retroactive validation via `/msd-validate-phase`
|
||||
- REQ-NYQ-06: System MUST be disableable via `workflow.nyquist_validation: false`
|
||||
|
||||
**Produces:** `{phase}-VALIDATION.md` — Test coverage contract
|
||||
|
||||
**Retroactive Validation (`/gsd-validate-phase [N]`):**
|
||||
**Retroactive Validation (`/msd-validate-phase [N]`):**
|
||||
- Scans implementation and maps requirements to tests
|
||||
- Identifies gaps where requirements lack automated verification
|
||||
- Spawns auditor to generate tests (max 3 attempts)
|
||||
|
||||
@@ -4,7 +4,7 @@ title: Opt-In Parallel Reviewer Lanes
|
||||
group: v1.7.0 Features
|
||||
---
|
||||
|
||||
**Command:** `/gsd-review`, `/gsd-plan-review-convergence`
|
||||
**Command:** `/msd-review`, `/msd-plan-review-convergence`
|
||||
|
||||
**Config key:** `review.parallel_lanes` (default `false`)
|
||||
|
||||
@@ -14,10 +14,10 @@ group: v1.7.0 Features
|
||||
|
||||
**The guard is strict equality, and it fails safe.** Only the exact value `true` opts in — `"1"`, `"yes"` and `"TRUE"` all stay sequential, so a mistyped config gets the conservative behavior rather than concurrent requests at a rate-limited provider. A failure to read the config falls back to sequential too. This polarity is deliberately the opposite of the `commit_docs` guard, which fails open: there, failing open preserves user intent; here it would fire the very requests the default exists to prevent.
|
||||
|
||||
**Result ordering is unchanged in both modes.** Per-lane results are written to slug-scoped files and concatenated in reviewer-selection order after the join, so `gsd-review-lane-results.jsonl` reads identically whether lanes ran sequentially or concurrently. Completion order never reaches the artifact. This also means concurrent lanes never share an append handle — a lane result larger than the pipe-atomicity bound cannot interleave and corrupt the `models:` / `model_sources:` frontmatter that `write_reviews` renders from that file.
|
||||
**Result ordering is unchanged in both modes.** Per-lane results are written to slug-scoped files and concatenated in reviewer-selection order after the join, so `msd-review-lane-results.jsonl` reads identically whether lanes ran sequentially or concurrently. Completion order never reaches the artifact. This also means concurrent lanes never share an append handle — a lane result larger than the pipe-atomicity bound cannot interleave and corrupt the `models:` / `model_sources:` frontmatter that `write_reviews` renders from that file.
|
||||
|
||||
**Per-lane semantics are untouched.** Timeouts, prompt budgets, the diagnostic stub for an empty or failed lane, explicit-lane failure ([ADR-2782](adr/2782-reviewer-lane-capability-surface.md) D4), trust/egress checks and result-file layout all behave exactly as they do sequentially. A failing lane does not abort its siblings.
|
||||
|
||||
**Known limits:** convergence cycles stay sequential by design (`review → replan → re-review` has a genuine data dependency), so this speeds up each pass rather than reducing the number of passes; there is no concurrency bound, so every selected lane dispatches at once; and reviewer instances sharing one adapter dispatch concurrently against that single provider, which is the most likely way to hit a limit.
|
||||
|
||||
**Reference:** [Configuration](CONFIGURATION.md#parallel-reviewer-lanes-for-gsd-review-3034) · [Enable parallel reviewer lanes](how-to/enable-parallel-reviewer-lanes.md) · [Commands](COMMANDS.md)
|
||||
**Reference:** [Configuration](CONFIGURATION.md#parallel-reviewer-lanes-for-msd-review-3034) · [Enable parallel reviewer lanes](how-to/enable-parallel-reviewer-lanes.md) · [Commands](COMMANDS.md)
|
||||
|
||||
@@ -4,7 +4,7 @@ title: Pause-Work Expansion
|
||||
group: v1.32 Features
|
||||
---
|
||||
|
||||
**Part of:** `/gsd-pause-work`
|
||||
**Part of:** `/msd-pause-work`
|
||||
|
||||
**Purpose:** Support non-phase contexts with richer handoff data for broader pause-work applicability.
|
||||
|
||||
|
||||
@@ -12,11 +12,11 @@ group: v1.41.0 Features
|
||||
|
||||
| Slot | Agents assigned |
|
||||
|------|-----------------|
|
||||
| `planning` | `gsd-planner`, `gsd-roadmapper`, `gsd-pattern-mapper` |
|
||||
| `discuss` | `gsd-assumptions-analyzer` |
|
||||
| `research` | `gsd-phase-researcher`, `gsd-project-researcher`, `gsd-research-synthesizer`, `gsd-codebase-mapper`, `gsd-ui-researcher` |
|
||||
| `execution` | `gsd-executor`, `gsd-debugger`, `gsd-doc-writer` |
|
||||
| `verification` | `gsd-verifier`, `gsd-plan-checker`, `gsd-integration-checker`, `gsd-nyquist-auditor`, `gsd-ui-checker`, `gsd-ui-auditor`, `gsd-doc-verifier`, `gsd-code-reviewer` |
|
||||
| `planning` | `msd-planner`, `msd-roadmapper`, `msd-pattern-mapper` |
|
||||
| `discuss` | `msd-assumptions-analyzer` |
|
||||
| `research` | `msd-phase-researcher`, `msd-project-researcher`, `msd-research-synthesizer`, `msd-codebase-mapper`, `msd-ui-researcher` |
|
||||
| `execution` | `msd-executor`, `msd-debugger`, `msd-doc-writer` |
|
||||
| `verification` | `msd-verifier`, `msd-plan-checker`, `msd-integration-checker`, `msd-nyquist-auditor`, `msd-ui-checker`, `msd-ui-auditor`, `msd-doc-verifier`, `msd-code-reviewer` |
|
||||
| `completion` | (reserved for future subagent) |
|
||||
|
||||
**Accepted values:** `"opus"` / `"sonnet"` / `"haiku"` / `"inherit"`
|
||||
|
||||
@@ -4,9 +4,9 @@ title: Persistent Context Threads
|
||||
group: v1.27 Features
|
||||
---
|
||||
|
||||
**Command:** `/gsd-thread [name | description]`
|
||||
**Command:** `/msd-thread [name | description]`
|
||||
|
||||
**Purpose:** Lightweight cross-session knowledge stores for work that spans multiple sessions but doesn't belong to any specific phase. Lighter weight than `/gsd-pause-work` — no phase state, no plan context.
|
||||
**Purpose:** Lightweight cross-session knowledge stores for work that spans multiple sessions but doesn't belong to any specific phase. Lighter weight than `/msd-pause-work` — no phase state, no plan context.
|
||||
|
||||
**Requirements:**
|
||||
- REQ-THREAD-01: System MUST support create, list, and resume modes
|
||||
|
||||
@@ -4,9 +4,9 @@ title: Phase Dependency Analysis
|
||||
group: v1.32 Features
|
||||
---
|
||||
|
||||
**Command:** `/gsd-manager --analyze-deps`
|
||||
**Command:** `/msd-manager --analyze-deps`
|
||||
|
||||
**Purpose:** Detect phase dependencies and suggest `Depends on` entries for ROADMAP.md before running `/gsd-manager`.
|
||||
**Purpose:** Detect phase dependencies and suggest `Depends on` entries for ROADMAP.md before running `/msd-manager`.
|
||||
|
||||
**Requirements:**
|
||||
- REQ-DEP-01: System MUST detect file overlap between phases
|
||||
|
||||
@@ -4,7 +4,7 @@ title: Phase Discussion
|
||||
group: Core Features
|
||||
---
|
||||
|
||||
**Command:** `/gsd-discuss-phase [N] [--auto] [--batch]`
|
||||
**Command:** `/msd-discuss-phase [N] [--auto] [--batch]`
|
||||
|
||||
**Purpose:** Capture user's implementation preferences and decisions before research and planning begin. Eliminates the gray areas that cause AI to guess.
|
||||
|
||||
|
||||
@@ -4,7 +4,7 @@ title: Phase Execution
|
||||
group: Core Features
|
||||
---
|
||||
|
||||
**Command:** `/gsd-execute-phase <N>`
|
||||
**Command:** `/msd-execute-phase <N>`
|
||||
|
||||
**Purpose:** Execute all plans in a phase using wave-based parallelization with fresh context windows per executor.
|
||||
|
||||
|
||||
@@ -4,7 +4,7 @@ title: Phase-Lifecycle Status-Line Read-Side
|
||||
group: v1.40.0 Features
|
||||
---
|
||||
|
||||
**Purpose:** Surface phase orchestration state on the status-line. `parseStateMd()` reads four new STATE.md frontmatter fields and `formatGsdState()` renders in-flight, idle, and progress scenes. Write-side wiring follows in a later RC.
|
||||
**Purpose:** Surface phase orchestration state on the status-line. `parseStateMd()` reads four new STATE.md frontmatter fields and `formatMsdState()` renders in-flight, idle, and progress scenes. Write-side wiring follows in a later RC.
|
||||
|
||||
**Requirements:**
|
||||
- REQ-LIFECYCLE-01: `parseStateMd()` reads four optional fields:
|
||||
@@ -12,7 +12,7 @@ group: v1.40.0 Features
|
||||
- `next_action` — recommended next command when idle
|
||||
- `next_phases` — YAML flow array of next phase numbers
|
||||
- `progress` — nested `total_phases` / `completed_phases` / `percent` block
|
||||
- REQ-LIFECYCLE-02: `formatGsdState()` checks the lifecycle fields in priority order and emits the first matching scene (Phase active → Idle next-recommended → Milestone complete → Default fallback).
|
||||
- REQ-LIFECYCLE-02: `formatMsdState()` checks the lifecycle fields in priority order and emits the first matching scene (Phase active → Idle next-recommended → Milestone complete → Default fallback).
|
||||
- REQ-LIFECYCLE-03: All four fields default to undefined; existing STATE.md files render byte-for-byte identically.
|
||||
|
||||
**Reference issue:** [#2833](https://github.com/open-gsd/gsd-core/issues/2833) — see [`docs/STATE-MD-LIFECYCLE.md`](reference/state-md.md) for the full field reference and rendering rules.
|
||||
|
||||
@@ -4,7 +4,7 @@ title: Phase Management
|
||||
group: Planning Features
|
||||
---
|
||||
|
||||
**Commands:** `/gsd-phase`, `/gsd-phase --insert [N]`, `/gsd-phase --remove [N]`
|
||||
**Commands:** `/msd-phase`, `/msd-phase --insert [N]`, `/msd-phase --remove [N]`
|
||||
|
||||
**Purpose:** Dynamic roadmap modification during development.
|
||||
|
||||
|
||||
@@ -4,7 +4,7 @@ title: Phase Planning
|
||||
group: Core Features
|
||||
---
|
||||
|
||||
**Command:** `/gsd-plan-phase [N] [--auto] [--skip-research] [--skip-verify]`
|
||||
**Command:** `/msd-plan-phase [N] [--auto] [--skip-research] [--skip-verify]`
|
||||
|
||||
**Purpose:** Research the implementation domain and produce verified, atomic execution plans.
|
||||
|
||||
@@ -15,7 +15,7 @@ group: Core Features
|
||||
- REQ-PLAN-04: System MUST include `read_first` and `acceptance_criteria` sections in every plan
|
||||
- REQ-PLAN-05: System MUST run plan checker verification loop (up to 3 iterations) unless `--skip-verify` is set
|
||||
- REQ-PLAN-06: System MUST support `--skip-research` flag to bypass research phase
|
||||
- REQ-PLAN-07: System MUST prompt user to run `/gsd-ui-phase` if frontend phase detected and no UI-SPEC.md exists (UI safety gate)
|
||||
- REQ-PLAN-07: System MUST prompt user to run `/msd-ui-phase` if frontend phase detected and no UI-SPEC.md exists (UI safety gate)
|
||||
- REQ-PLAN-08: System MUST include Nyquist validation mapping when `workflow.nyquist_validation` is enabled
|
||||
- REQ-PLAN-09: System MUST verify all phase requirements are covered by at least one plan before planning completes (requirements coverage gate)
|
||||
- REQ-PLAN-10: System MUST support an optional `<reversibility rating="reversible|costly|one-way">` element recording how costly a decision would be to undo, and MUST insert a `checkpoint:decision` before the task implementing a `one-way` decision unless `--no-reversibility-gates` is set (`costly` is flagged without blocking; `reversible` and unrated flow normally)
|
||||
|
||||
@@ -4,7 +4,7 @@ title: Plan Bounce
|
||||
group: v1.36.0 Features
|
||||
---
|
||||
|
||||
**Command:** `/gsd-plan-phase N --bounce`
|
||||
**Command:** `/msd-plan-phase N --bounce`
|
||||
|
||||
**Purpose:** After plans pass the checker, optionally refine them through an external script (a second AI, a linter, a custom validator). The bounce step backs up each plan, runs the script, validates YAML frontmatter integrity on the result, re-runs the plan checker, and restores the original if anything fails.
|
||||
|
||||
|
||||
@@ -4,12 +4,12 @@ title: Plan Import
|
||||
group: v1.34.0 Features
|
||||
---
|
||||
|
||||
**Command:** `/gsd-import --from <filepath>`
|
||||
**Command:** `/msd-import --from <filepath>`
|
||||
|
||||
**Purpose:** Ingest an external plan file into the GSD planning system with conflict detection against `PROJECT.md` decisions, converting it to a valid GSD PLAN.md and validating it through the plan-checker.
|
||||
**Purpose:** Ingest an external plan file into the MSD planning system with conflict detection against `PROJECT.md` decisions, converting it to a valid MSD PLAN.md and validating it through the plan-checker.
|
||||
|
||||
**Requirements:**
|
||||
- REQ-IMPORT-01: Importer MUST detect conflicts between the external plan and existing PROJECT.md decisions
|
||||
- REQ-IMPORT-02: All detected conflicts MUST be presented to the user for resolution before writing
|
||||
- REQ-IMPORT-03: Imported plan MUST be written as a valid GSD PLAN.md format
|
||||
- REQ-IMPORT-04: Written plan MUST pass `gsd-plan-checker` validation
|
||||
- REQ-IMPORT-03: Imported plan MUST be written as a valid MSD PLAN.md format
|
||||
- REQ-IMPORT-04: Written plan MUST pass `msd-plan-checker` validation
|
||||
|
||||
@@ -4,7 +4,7 @@ title: Planner Reachability Check
|
||||
group: v1.32 Features
|
||||
---
|
||||
|
||||
**Part of:** `/gsd-plan-phase`
|
||||
**Part of:** `/msd-plan-phase`
|
||||
|
||||
**Purpose:** Validate that plan steps are achievable before committing to execution.
|
||||
|
||||
|
||||
@@ -4,7 +4,7 @@ title: Playwright-MCP UI Verification
|
||||
group: v1.32 Features
|
||||
---
|
||||
|
||||
**Part of:** `/gsd-verify-work` (optional)
|
||||
**Part of:** `/msd-verify-work` (optional)
|
||||
|
||||
**Purpose:** Automated visual verification using Playwright-MCP during verify-phase.
|
||||
|
||||
|
||||
@@ -6,12 +6,12 @@ order: 27.2
|
||||
---
|
||||
|
||||
**Introduced by:** #2003
|
||||
**Trigger:** Runs automatically at the end of every `/gsd-execute-phase`
|
||||
**Trigger:** Runs automatically at the end of every `/msd-execute-phase`
|
||||
**Configuration:**
|
||||
- `workflow.drift_threshold` (integer, default `3`) — minimum new
|
||||
structural elements before the gate acts.
|
||||
- `workflow.drift_action` (`warn` | `auto-remap`, default `warn`) —
|
||||
warn-only or spawn `gsd-codebase-mapper` with `--paths` scoped to
|
||||
warn-only or spawn `msd-codebase-mapper` with `--paths` scoped to
|
||||
affected subtrees.
|
||||
|
||||
**What counts as drift:**
|
||||
@@ -30,6 +30,6 @@ continues. Drift detection cannot fail verification.
|
||||
- REQ-DRIFT-02: Action fires only when element count ≥ `workflow.drift_threshold`
|
||||
- REQ-DRIFT-03: `warn` action MUST NOT spawn any agent
|
||||
- REQ-DRIFT-04: `auto-remap` action MUST pass sanitized `--paths` to the mapper
|
||||
- REQ-DRIFT-05: Detection/remap failure MUST be non-blocking for `/gsd-execute-phase`
|
||||
- REQ-DRIFT-05: Detection/remap failure MUST be non-blocking for `/msd-execute-phase`
|
||||
- REQ-DRIFT-06: `last_mapped_commit` round-trip through YAML frontmatter
|
||||
on each `.planning/codebase/*.md` file
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user