golem15/msd-core
3
0
Fork 0
Code Issues Pull Requests Actions 1 Packages Projects Releases Wiki Activity

refactor: hard-fork GSD -> MSD (Make Software Done)

Browse Source 
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
2026-10-06 01:47:40 +02:00
parent fe069b2a56
commit a9a7a328e6
2763 changed files with 78465 additions and 78434 deletions
Download Patch File Download Diff File Expand all files Collapse all files

26
docs/how-to/act-on-a-refactor-proposal.md
View File

@@ -2,7 +2,7 @@
**Goal:** Turn on the complexity-triggered refactor hook, understand the proposals it surfaces after a phase, and dispose of each one — so a function that grew a branch per phase gets refactored while it is still one function, instead of becoming a rewrite nobody noticed accumulating.
**Prerequisites:** A GSD project on v1.10.0 or later. Nothing else — the hook has no external dependency and needs no indexer. It is **off by default**; a project that never enables it is completely unaffected.
**Prerequisites:** A MSD project on v1.10.0 or later. Nothing else — the hook has no external dependency and needs no indexer. It is **off by default**; a project that never enables it is completely unaffected.
For what the metric measures, why the anchor moves only on disposition, and the metric's known biases, see [Complexity-Triggered Refactor](../FEATURES.md#159-complexity-triggered-refactor) and [ADR-1953](../adr/1953-complexity-triggered-refactor.md). This guide covers only how to *use* it.
@@ -11,15 +11,15 @@ For what the metric measures, why the anchor moves only on disposition, and the
## Turn it on
```bash
gsd config-set refactor.trigger_enabled true
msd config-set refactor.trigger_enabled true
```
That is the whole setup. From the next `/gsd-execute-phase`, an `execute:post` step measures the files that phase touched and writes a proposal only if something crosses a line. Nothing else about the loop changes: the hook never edits code, never picks a refactor, and never blocks.
That is the whole setup. From the next `/msd-execute-phase`, an `execute:post` step measures the files that phase touched and writes a proposal only if something crosses a line. Nothing else about the loop changes: the hook never edits code, never picks a refactor, and never blocks.
To check it without running a phase:
```bash
node gsd-tools.cjs refactor evaluate --phase 3 --raw
node msd-tools.cjs refactor evaluate --phase 3 --raw
```
---
@@ -44,8 +44,8 @@ Both thresholds are **strictly greater** — a score of exactly 15 against a thr
A proposal stays untriaged until you disposition it. There are exactly two ways, and **both** clear it:
```bash
node gsd-tools.cjs refactor accept --phase 3
node gsd-tools.cjs refactor decline --phase 3 --reason "flat dispatch table — branchy by construction, not a hotspot"
node msd-tools.cjs refactor accept --phase 3
node msd-tools.cjs refactor decline --phase 3 --reason "flat dispatch table — branchy by construction, not a hotspot"
```
**Accept** when you intend to refactor. The anchor re-anchors to the function's current score, so after you do the work the next evaluation measures growth from the new, lower baseline.
@@ -57,7 +57,7 @@ node gsd-tools.cjs refactor decline --phase 3 --reason "flat dispatch table —
To see what is outstanding across the project:
```bash
node gsd-tools.cjs refactor status
node msd-tools.cjs refactor status
```
---
@@ -67,8 +67,8 @@ node gsd-tools.cjs refactor status
If proposals feel like noise, raise the threshold rather than turning the hook off:
```bash
gsd config-set refactor.complexity_threshold 20 # ESLint's own default
gsd config-set refactor.complexity_jump_delta 8
msd config-set refactor.complexity_threshold 20 # ESLint's own default
msd config-set refactor.complexity_jump_delta 8
```
Defaults are 15 (SonarSource's default) and 5. For reference, radon's rank C — "moderate, slightly complex" — begins at 11, and ESLint's `complexity` rule defaults to 20. There is no universally correct number; start at the default and raise it once you have seen a few proposals you disagreed with.
@@ -80,8 +80,8 @@ Defaults are 15 (SonarSource's default) and 5. For reference, radon's rank C —
Advisory mode surfaces proposals and tracks nothing. To make an untriaged proposal a task that must be resolved before shipping, you need **two** settings, not one:
```bash
gsd config-set refactor.trigger_strict true # 1. record proposals in the ledger
gsd config-set workflow.windows_enforce true # 2. make the ledger block /gsd-ship
msd config-set refactor.trigger_strict true # 1. record proposals in the ledger
msd config-set workflow.windows_enforce true # 2. make the ledger block /msd-ship
```
Why two: `refactor.trigger_strict` records an untriaged proposal as an open `deviation` entry in the [broken-windows ledger](../FEATURES.md#158-broken-windows-ledger). The *blocking* is that capability's existing `ship:pre` gate, which is separately opt-in. Setting only the first gives you tracking without enforcement — which is a reasonable place to stop, but it will not stop a ship.
@@ -92,7 +92,7 @@ If you enable only `refactor.trigger_strict`, every `refactor evaluate` that tri
"warnings": [
{
"reason": "refactor_strict_not_enforcing",
"message": "refactor.trigger_strict is on, but workflow.windows_enforce is off, so ship will not actually be blocked. Run: gsd config-set workflow.windows_enforce true"
"message": "refactor.trigger_strict is on, but workflow.windows_enforce is off, so ship will not actually be blocked. Run: msd config-set workflow.windows_enforce true"
}
]
```
@@ -110,7 +110,7 @@ The hook is deliberately silent in several situations. If you expected a proposa
| You see | What happened |
|---|---|
| `refactor_no_touched_files` | The phase changed nothing the analyzer looks at. |
| `refactor_analyzer_unsupported` | The file's language or path is out of scope. Only `.js .cjs .mjs .ts .cts .mts` are analyzed; `tests/` and generated `gsd-core/bin/lib/` paths are excluded by design. |
| `refactor_analyzer_unsupported` | The file's language or path is out of scope. Only `.js .cjs .mjs .ts .cts .mts` are analyzed; `tests/` and generated `msd-core/bin/lib/` paths are excluded by design. |
| `refactor_analyzer_unparseable` | An unterminated string, template, or block comment. The analyzer **refuses to emit a score** it cannot defend rather than guessing — a silently wrong number is worse than none. |
| `refactor_git_unavailable` | Not a git repository, `git` missing, the call timed out, or the phase has no committed `PLAN.md` to anchor against. Degrades quietly, exit 0. |
| `refactor_file_unreadable` | One file could not be read, or resolved outside the project root. That file is skipped; the rest of the run continues. |