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.

docs/explanation/security-model.md

@@ -1,8 +1,8 @@
-# GSD Core security model
+# MSD Core security model
 
-> **Explanation** — This document describes *why* GSD Core has the security
+> **Explanation** — This document describes *why* MSD Core has the security
 > posture it does and *how the layers fit together*. It is not a reference for
-> every hook parameter. For the `/gsd-secure-phase` command and its options,
+> every hook parameter. For the `/msd-secure-phase` command and its options,
 > see [Commands](../COMMANDS.md). For the implementation-level hook
 > architecture, see [Architecture § Hook System](../ARCHITECTURE.md#hook-system).
 > For the org-wide security baseline (scanner controls, incident checklists,
@@ -13,13 +13,13 @@
 ## Why AI-driven development needs a dedicated security posture
 
 A conventional code editor does not execute arbitrary packages on your behalf.
-GSD Core does. The research → plan → execute pipeline automates the full path
+MSD Core does. The research → plan → execute pipeline automates the full path
 from "name a package" to "run `npm install <package>`", from "write a
 planning artifact" to "use that artifact as an LLM system prompt". Each
 automation step removes a human from the loop — and each removal is a
 potential attack surface.
 
-GSD Core's security model is built around one organising principle:
+MSD Core's security model is built around one organising principle:
 **defence in depth**. No single control is assumed to be perfect. Several
 overlapping layers each reduce a distinct class of risk, and together they
 make the attack surface substantially harder to exploit without eliminating
@@ -45,7 +45,7 @@ The insidious quality of slopsquatting is that a hallucinated name that passes
 `npm view` *looks legitimate*. The registry entry proves only that someone
 registered the name — not that the package does what the AI said it does, not
 that it has any legitimate users, and not that its install scripts are safe.
-Without a gate, a hallucinated name would flow undetected through GSD's
+Without a gate, a hallucinated name would flow undetected through MSD's
 researcher → planner → executor pipeline and eventually run as
 `npm install <attacker-package>` on your machine.
 
@@ -53,8 +53,8 @@ researcher → planner → executor pipeline and eventually run as
 
 The gate operates across three pipeline stages:
 
-**Research stage.** When `gsd-phase-researcher` recommends external packages,
-it runs `gsd-tools query package-legitimacy check --ecosystem <npm|pypi|crates>
+**Research stage.** When `msd-phase-researcher` recommends external packages,
+it runs `msd-tools query package-legitimacy check --ecosystem <npm|pypi|crates>
 <pkgs>` against each one. Verdicts (`OK|SUS|SLOP`) are computed from live
 registry APIs against thresholds `{ minAgeDays: 30, minWeeklyDownloads: 1000,
 requireRepo: true }`, plus terminal short-circuits for non-existence and
@@ -64,7 +64,7 @@ Legitimacy Audit` table in `RESEARCH.md`. Packages tagged `[SLOP]`
 `RESEARCH.md` entirely** before the file is saved. They never reach the
 planner.
 
-**Planning stage.** `gsd-planner` reads the Audit table. For any package
+**Planning stage.** `msd-planner` reads the Audit table. For any package
 tagged `[SUS]` (suspicious: newly registered, low download count, no source
 repository, or naming pattern close to a popular package) or `[ASSUMED]`
 (sourced from WebSearch rather than direct registry verification), the planner
@@ -73,7 +73,7 @@ checkpoint includes a direct link to the registry page and specific things to
 look for: maintainer history, issue-tracker activity, absence of suspicious
 install scripts.
 
-**Execution stage.** If an install fails, `gsd-executor` **surfaces a
+**Execution stage.** If an install fails, `msd-executor` **surfaces a
 checkpoint and stops**. It does not silently try an alternative package name —
 which could itself be malicious. This is an explicit rule in the executor's
 behaviour (RULE 3 in the executor agent definition).
@@ -122,7 +122,7 @@ downgrading everything to `[ASSUMED]`.
 
 ### The threat
 
-GSD Core generates Markdown files that become LLM system prompts. The
+MSD Core generates Markdown files that become LLM system prompts. The
 research pipeline reads external web content; the planning pipeline
 incorporates user-supplied text (`--text-file`, `--prd`); the execution
 pipeline writes planning artifacts that are later re-read as agent context.
@@ -133,9 +133,9 @@ exfiltrate information.
 
 ### How the defences work
 
-GSD Core addresses prompt injection at three levels.
+MSD Core addresses prompt injection at three levels.
 
-**Input validation (`security.cjs`).** The `gsd-core/bin/lib/security.cjs`
+**Input validation (`security.cjs`).** The `msd-core/bin/lib/security.cjs`
 module is the central security utility. It provides:
 
 - Path containment: user-supplied file paths and directories are validated to
@@ -176,7 +176,7 @@ legitimately does not exist yet. A lexical check **cannot see a symlink**, so a
 caller relying on one for a write-confinement guarantee must pair it with its
 own symlink refusal. Three call sites use it, each for a stated reason.
 
-The backup-restore gate in `gsd-core/bin/gsd-tools.cjs` rejects symlinks outright:
+The backup-restore gate in `msd-core/bin/msd-tools.cjs` rejects symlinks outright:
 the canonical predicate accepts a link whose target resolves inside the root, but
 for a restore that is still wrong, because writing through the link overwrites
 whatever it points at instead of materializing a regular file at the backed-up
@@ -225,9 +225,9 @@ file is still linted), leaving their hand-rolled comparisons permanently
 un-ratcheted; the only remedy is a fix-forward migration, never an edit to a
 shipped body.
 
-**Runtime hook: `gsd-prompt-guard.js`.** This hook fires on every Write or
+**Runtime hook: `msd-prompt-guard.js`.** This hook fires on every Write or
 Edit call that targets `.planning/` files. It scans the content being written
-for injection patterns shared with `gsd-read-injection-scanner.js` through
+for injection patterns shared with `msd-read-injection-scanner.js` through
 `hooks/lib/injection-patterns.js` — one module both hooks `require()`, so the
 two surfaces cannot drift apart (#3504). The set is deliberately a subset of
 `security.cjs`'s patterns: the hooks stay loadable standalone, without the
@@ -236,24 +236,24 @@ but does not block the write. The rationale is that a false-positive block on
 a legitimate planning write would be more disruptive than a missed injection
 in a secondary scan layer.
 
-**Runtime hook: `gsd-read-injection-scanner.js`.** This hook fires on the
+**Runtime hook: `msd-read-injection-scanner.js`.** This hook fires on the
 output of every Read, WebFetch, and WebSearch tool call. It scans the *content
 that was just read or fetched* for injected instructions in untrusted content —
 catching cases where an attacker has embedded instructions in a file or remote
-resource that GSD is about to incorporate into an agent's context. The 10
+resource that MSD is about to incorporate into an agent's context. The 10
 research and doc-ingest agents additionally carry a shared `<security_context>`
 data/instruction boundary (defined in
-`gsd-core/references/untrusted-input-boundary.md`): `gsd-project-researcher`,
-`gsd-phase-researcher`, `gsd-ui-researcher`, `gsd-assumptions-analyzer`,
-`gsd-advisor-researcher`, `gsd-doc-classifier`, `gsd-doc-synthesizer`,
-`gsd-research-synthesizer`, `gsd-ai-researcher`, and `gsd-domain-researcher`.
+`msd-core/references/untrusted-input-boundary.md`): `msd-project-researcher`,
+`msd-phase-researcher`, `msd-ui-researcher`, `msd-assumptions-analyzer`,
+`msd-advisor-researcher`, `msd-doc-classifier`, `msd-doc-synthesizer`,
+`msd-research-synthesizer`, `msd-ai-researcher`, and `msd-domain-researcher`.
 Any content fetched or read by those agents is treated as data, never as
 instructions, regardless of what the content claims to be.
 
 **Opt-in blocking (`security.injection_blocking`).** By default all injection
 detections are advisory-only (logged, not blocked). Setting
 `security.injection_blocking = true` in `.planning/config.json` (a registered
-config key — `gsd config-set security.injection_blocking true`) upgrades
+config key — `msd config-set security.injection_blocking true`) upgrades
 HIGH-confidence detections to **blocking**. Be precise about what this does: the
 scanner is a **PostToolUse** hook, so it runs *after* the Read/WebFetch/WebSearch
 has already executed and the fetched content is already in the model's transcript.
@@ -269,15 +269,15 @@ not a redactor.
 
 **CI scanner.** `prompt-injection-scan.security.test.cjs` scans all agent, workflow,
 and command files for embedded injection vectors as part of the test suite.
-This catches injection attempts in the GSD source itself — for example, a
+This catches injection attempts in the MSD source itself — for example, a
 supply-chain attack that modified a workflow file to add a role-override
 instruction.
 
 ### Read Injection Scanner vs Prompt Guard
 
-The two hooks cover complementary surfaces. `gsd-prompt-guard.js` watches
+The two hooks cover complementary surfaces. `msd-prompt-guard.js` watches
 *writes to planning artifacts* — it catches injection being planted.
-`gsd-read-injection-scanner.js` watches *reads and remote fetches* — it catches
+`msd-read-injection-scanner.js` watches *reads and remote fetches* — it catches
 injection being ingested from external content (a dependency's README, a
 third-party config file, a user-provided document, or any URL fetched via
 WebFetch or WebSearch). The in-prompt `<security_context>` boundary in research
@@ -285,10 +285,10 @@ agents provides an additional containment layer: even if an injected string
 reaches an agent, it is structurally separated from the instruction region.
 Together these controls bracket the ingest → store → re-read lifecycle.
 
-**Runtime hook: `gsd-workflow-guard.js` — advisory vs. blocking posture.**
+**Runtime hook: `msd-workflow-guard.js` — advisory vs. blocking posture.**
 This hook has two legs with two deliberately different failure postures. The
 edit leg is **advisory**: when `hooks.workflow_guard` is enabled it warns on
-edits made outside a GSD workflow, and on any internal error it fails open
+edits made outside a MSD workflow, and on any internal error it fails open
 (exit 0) — a broken advisory must never wedge a session's tool calls. The
 Bash leg carries the hook's one **hard block**: `git add -f` / `git add
 --force` on an `agent-*` or `worktree-agent-*` branch is blocked outright
@@ -308,7 +308,7 @@ one hard block this hook owns.
 
 ## Layer 3 — Repository and dependency integrity
 
-Upstream of GSD's runtime behaviour, the `open-gsd` organisation enforces
+Upstream of MSD's runtime behaviour, the `open-gsd` organisation enforces
 controls at the repository and package level. These are documented in full in
 [`docs/security/baseline.md`](../security/baseline.md) and are summarised
 here for completeness.
@@ -317,7 +317,7 @@ here for completeness.
 `package-lock.json` and verified against published checksums before install.
 A `scripts/check-npm-integrity.cjs` gate detects invalid versions, missing
 packages, and extraneous packages at CI time. This mitigates dependency
-confusion and typosquatting attacks against GSD's own dependencies.
+confusion and typosquatting attacks against MSD's own dependencies.
 
 **Secret scanning.** Every commit and PR is scanned for hardcoded secrets.
 Intentional test fixtures must be annotated with the project-standard
@@ -333,7 +333,7 @@ hide malicious content in diffs.
 
 ## Layer 4 — Subprocess execution
 
-GSD starts external programs constantly: git, npm, reviewer CLIs declared by
+MSD starts external programs constantly: git, npm, reviewer CLIs declared by
 capabilities, and whatever a gate predicate names. Every one of those is a
 place where an argument could become a command. One module owns the whole
 question — `src/shell-command-projection.cts`, the single platform seam.
@@ -342,7 +342,7 @@ question — `src/shell-command-projection.cts`, the single platform seam.
 the mechanism behind CVE-2024-27980: the shell re-parses the argument list, so
 a value containing `&` or `|` stops being data and becomes a second command.
 Node 26 additionally deprecates `shell: true` alongside an argument array
-(DEP0190), because arguments are concatenated rather than escaped. GSD resolves
+(DEP0190), because arguments are concatenated rather than escaped. MSD resolves
 binaries explicitly instead.
 
 **Explicit resolution, not shell lookup.** `resolveExecutableBinary` scans
@@ -407,21 +407,21 @@ creative injection that does not match known patterns, or an injection that
 arrives through a channel the hooks do not cover. The previously uncovered
 channel of content injected into a dependency's published README and read by a
 subagent browsing documentation is now scanned at ingress by
-`gsd-read-injection-scanner.js` (which covers WebFetch and WebSearch output)
+`msd-read-injection-scanner.js` (which covers WebFetch and WebSearch output)
 and structurally isolated in-prompt by the `<security_context>` boundary in
 research agents — but novel jailbreaks and low-signal injections may still pass
 undetected. Defence in depth means each layer makes the attack harder, not that
 any single layer makes it impossible.
 
-**What the UI-SPEC provenance rule does not eliminate:** `gsd-ui-checker`
+**What the UI-SPEC provenance rule does not eliminate:** `msd-ui-checker`
 Dimension 7 requires a component inventory to record the command that
 enumerated it, and instructs the checker never to run that command — it is
 text from a document, not an instruction to the agent. **That barrier is
 prompt-level only.** The checker holds a `Bash` grant it genuinely needs (the
-agent-skills bootstrap shells out through `gsd_run`), and tool grants here are
+agent-skills bootstrap shells out through `msd_run`), and tool grants here are
 not command-scoped, so nothing structurally prevents execution of a command
 string lifted out of a UI-SPEC. No shipped instruction does so, and the spec is
-written by `gsd-ui-researcher`, which carries the `<security_context>`
+written by `msd-ui-researcher`, which carries the `<security_context>`
 untrusted-input boundary for its web and MCP ingress — but this is defense by
 instruction, not by capability. The same shape is older and wider in Dimension 6,
 where the *researcher* is told to run `npx shadcn view {block} --registry {url}`
@@ -452,8 +452,8 @@ and disclosure policy.
 
 ## Related
 
-- [Commands](../COMMANDS.md) — includes `/gsd-secure-phase` and
-  `/gsd-code-review` with security-relevant flags
+- [Commands](../COMMANDS.md) — includes `/msd-secure-phase` and
+  `/msd-code-review` with security-relevant flags
 - [Architecture § Hook System](../ARCHITECTURE.md#hook-system) —
   implementation detail on every hook, its event trigger, and safety properties
 - [SECURITY.md](../../SECURITY.md) — vulnerability reporting, org-wide