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
2026-10-06 01:47:40 +02:00
parent fe069b2a56
commit a9a7a328e6
2763 changed files with 78465 additions and 78434 deletions

View File

@@ -12,11 +12,11 @@ from the tracker at execution time instead of reading it inline out of `PLAN.md`
**What changed (ADR-3646, #3970):**
- A new optional feature-body manifest field, `taskContentResolver`, declares a `trackerPrefix`
(matched against a task's `<task tracker-id="beads:GSD-42">` attribute — everything before the
(matched against a task's `<task tracker-id="beads:MSD-42">` attribute — everything before the
first `:`) and a bounded `invoke` (`binary`, `args` carrying the `{{id}}` placeholder,
`timeoutMs`).
- `execute-plan.md`'s per-task loop gains one new, unconditional call before that task's
`read_first` gate: `gsd_run task resolve-content --plan <path> --task-id <tracker-id> --raw`.
`read_first` gate: `msd_run task resolve-content --plan <path> --task-id <tracker-id> --raw`.
A task with no `tracker-id` attribute is unaffected — the call is only made when the attribute
is present, and resolves instantly to a no-op for every project that declares none.
- **The safety property is a real process exit code, not a prose dispatch.** No capability
@@ -30,7 +30,7 @@ from the tracker at execution time instead of reading it inline out of `PLAN.md`
`PLAN.md` content.
- `execute:task` is a new dispatch shape below wave granularity, deliberately **not** one of the
12 existing loop extension points (`discuss:pre` … `ship:post`) and not routed through
`gsd_run loop render-hooks <point>` / `activeHooks`. It exists because the existing
`msd_run loop render-hooks <point>` / `activeHooks`. It exists because the existing
`step`/`gate` prose-dispatch mechanism cannot deliver a hard-halt guarantee while dispatch
reliability at that layer is an open concern (#3647) — see ADR-3646's Context and Rejected
Alternatives for the full reasoning.
@@ -38,5 +38,5 @@ from the tracker at execution time instead of reading it inline out of `PLAN.md`
See [Develop a task-content resolver capability](../how-to/develop-a-task-content-resolver-capability.md)
for the authoring walkthrough, [Capability manifest → `taskContentResolver`](../reference/capability-manifest.md#taskcontentresolver)
for the field reference, and
[`loop-hook-dispatch.md`](../../gsd-core/references/loop-hook-dispatch.md#the-executetask-point-a-different-shape)
[`loop-hook-dispatch.md`](../../msd-core/references/loop-hook-dispatch.md#the-executetask-point-a-different-shape)
for how `execute:task` differs from the twelve prose-dispatched points.