<!-- agent-pmo:f481f8d -->
## TLDR
Pre-release sanity pass after PR #5 — fixes every stale `deploy-stamp` /
`@shipwright/*` / `DeployToolkit` / `DTK-` / wrong-PackageId reference
that would have shipped a broken v0.1.0.

## Details

Per [SWR-REL-PRERELEASE-PR](docs/plans/release-pipeline.md), this is the
changelog/release-metadata PR that must merge before the `v0.1.0` tag is
pushed. No source version bumps — versions in `Cargo.toml`,
`package.json`, `*.csproj`, `pubspec.yaml`, and `build.gradle.kts` are
unchanged at `0.1.0` so the tag-triggered workflow ships exactly what
reviewers see.

### Real bugs fixed

- **`tools/shipwright-version-stamp/src/main.rs`** — the CLI introduced
itself as `deploy-stamp` in 7 places (module doc, help text, stderr
prefix). Anyone running `--help` got a name that doesn't match the
binary path, crate name, README, or the spec in
[SWR-VERSION-BUILD-STAMPING].
- **`.github/workflows/release.reusable.yml`** — three `if:
hashFiles('tools/deploy-stamp/Cargo.toml')` guards plus a `cargo run
--manifest-path tools/deploy-stamp/Cargo.toml ...` invocation. That path
has never existed in this repo; downstream products consuming this
reusable workflow would have skipped the stamp step entirely and shipped
unstamped versions.
- **`CHANGELOG.md` [0.1.0] package list** — every line was wrong:
- `shipwright-cli` (crate doesn't exist; the Rust CLI crate is
`shipwright`)
  - `deploy-stamp` (real crate: `shipwright-version-stamp`)
- `@shipwright/core`, `@shipwright/vscode`, `@shipwright/node`,
`@shipwright/validate-manifest` (real scope: `@nimblesite`; the MCP
package is `shipwright-mcp` not `node`)
- `Shipwright.Tool` (not part of the v0.1.0 NuGet release per
[release-pipeline.md §5](docs/plans/release-pipeline.md); only
`Shipwright` ships)
- Repo URLs case-corrected from `nimblesite/Shipwright` to
`Nimblesite/Shipwright`
- Maven Central removed from the release-target list (Phase 4 still has
unchecked TODOs)
  - Release date set to today (2026-05-20)
- **Root `package.json`** — `test:ts-*` scripts filtered for
`@shipwright/core`, `@shipwright/vscode`, `@shipwright/node`. No package
in the workspace matches that scope, so `pnpm --filter` matched nothing
and the scripts silently no-op'd. Filters now point at the real
`@nimblesite/shipwright-*` names; renamed `test:ts-node` → `test:ts-mcp`
to match the actual package.
- **`templates/vscode-extension/src/extension.ts`** — imported
`activateShipwright` from `@shipwright/vscode`. A consumer following the
template would get an `ERR_MODULE_NOT_FOUND` at activation. Switched to
`@nimblesite/shipwright-vscode`.
- **`templates/vscode-extension/README.md`** — same scope wrong in the
prose.
- **`clients/ts/packages/shipwright-mcp/test/version.test.ts`** —
`describe("@shipwright/node", ...)` doesn't match the package being
tested. Aligned with `@nimblesite/shipwright-mcp`.
- **`docs/plans/release-pipeline.md`** — `NPM_TOKEN` description and the
`.npmrc` checklist item both said `@shipwright` scope. Fixed to
`@nimblesite`.
- **`examples/dotnet-tool/Shipwright.Cli.csproj`** —
`<PackageId>Shipwright</PackageId>` collided with the published
`Shipwright` library nupkg. `dotnet pack` in the examples tree would
have produced a same-named, lower-fidelity package — a footgun. Renamed
to `Shipwright.Cli.Example` and added `<IsPackable>false</IsPackable>`
so the example can't be accidentally pushed to NuGet.
- **`scripts/verify-versions.sh`** — `DTK-REL-VERSION-VERIFY` spec
prefix is from the pre-rename era. Updated to `SWR-REL-VERSION-VERIFY`
(matches the spec id used in `docs/plans/release-pipeline.md §1.3`).
- **`tests/fixtures.test.mjs`** — test name `"tracked DTK ids do not use
numeric suffixes"` still mentioned the old prefix even though the regex
it enforces (`/\bSWR-[A-Z]+-\d+\b/g`) only matches `SWR-`. Renamed to
`"tracked SWR ids do not use numeric suffixes"` to remove the
contradiction.

### Out of scope (follow-up tickets)

These were noticed during the sanity pass but are not consistency bugs —
they're real implementation gaps documented in [release-pipeline.md
§13](docs/plans/release-pipeline.md):

- `release.yml` has no crates.io, pub.dev, Maven, or
GitHub-Release-binary jobs yet (release-pipeline.md Phase 2/3/4
unchecked).
- Source-controlled versions are not yet on the `0.0.0-dev` placeholder
mandated by [SWR-VERSION-BUILD-STAMPING] (release-pipeline.md §1.1). The
release pipeline currently relies on source already carrying `0.1.0`,
which works for v0.1.0 but will break the policy from v0.1.1 onward.

## How Do The Automated Tests Prove It Works?
`make ci` passes end-to-end on this branch:

- Compiled `./target/release/shipwright-version-stamp --help` and
confirmed the help banner now begins with `shipwright-version-stamp —
stamp a release tag into every language's version field` (was
`deploy-stamp — ...`).
- Renamed test `tracked SWR ids do not use numeric suffixes` passes —
the regex `/\bSWR-[A-Z]+-\d+\b/g` finds zero matches in `docs/specs/`,
`docs/plans/`, and `fixtures/spec-coverage.json`.
- `manifest schema accepts valid fixtures`, `all invalid manifests fail
schema validation`, `plain and JSON version fixtures match the
contract`, and `each spec file has fixture coverage or a tracked ticket
id` all green — proving the CHANGELOG, csproj `<IsPackable>`, scope
renames, and template TS import did not regress validation.
- Coverage gate enforces 100.0% lines/functions on every crate
(`shipwright-manifest`, `shipwright-host`, `shipwright`,
`shipwright-zed`, `shipwright-version-stamp`) and workspace — confirms
the version-stamp string edits did not knock out a branch.
- `cargo build --release --workspace` builds every crate clean,
confirming the workspace still compiles with the renamed help/error
strings.
- Final repo-wide grep for
`deploy[_-]toolkit|deploytoolkit|DeployToolkit|deployment[_-]toolkit|deploy-stamp|@shipwright/|\bDTK-`
returns zero results.