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
@@ -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.
|
||||
|
||||
Reference in New Issue
Block a user