chore(release): v0.4.0 — ratify ADR-0021 and cut the inbound-marker release

[mbeacom]

Cuts v0.4.0, the release that ships #97.

The only change to a published package since v0.3.0 is the inbound @adr marker feature. Everything else on main since then is the unpublished catalog adapter (@adrkit/catalog-backstage is at 0.0.0 and is not in release-pack.ts's package list), specs, docs, or dependency bumps. Minor rather than patch: @adrkit/core gains exports and adr explain gains output, nothing is removed.

What's in it

Version bump to 0.4.0 across the four lockstep manifests, the root manifest, packages/mcp/server.json (both the registry version and packages[0].version that the MCP registry validates as a pair), and the two hardcoded constants CLI_VERSION and SERVER_INFO. Each constant is guarded by its own test, so both were caught by bun test rather than by reading.

ADR-0021 moves from proposed to accepted. It shipped in #97 while still proposed, which meant the tool reported this about the code that record authorizes:

$ adr explain packages/core/src/markers/scan.ts
No accepted decision governs packages/core/src/markers/scan.ts.
Active proposals (not yet binding):
  0021  [proposed] Resolve inbound source annotations without changing the schema

A decision-memory tool should not publish a feature its own corpus reports as ungoverned. It now reads 0021 [accepted] ... via path: packages/core/src/markers/**. The record also gains the review: block every other non-template ADR carries; tier: async follows ADR-0018, the only other component-scoped record. adr lint is clean at 21 records, 0 errors, 0 warnings.

The changelog gets adapter sections. @adrkit/spec-kit 0.1.0, 0.1.1 and 0.1.2 shipped on their own spec-kit-v* tags per ADR-0007, so rolling them into [0.4.0] would file already-released adapter work under a lockstep version that never carried it. Their entries move verbatim into [spec-kit-0.1.0], [spec-kit-0.1.1] and [spec-kit-0.1.2], dated from the tags. The release-pipeline and documentation work that shipped with the lockstep surface stays in [0.4.0], alongside the new markers entry.

bun.lock carries four workspace version fields and nothing else. release-pack validates that a packed dependency resolves to the dependency's own version, and it caught the stale lockfile: @adrkit/evaluator must resolve @adrkit/core to 0.4.0, got 0.3.0. Neither bun install nor bun install --force refreshes those fields. Regenerating the lockfile does, but it also pulls transitive drift (jose 6.2.3 → 6.2.8, undici 6.27.0 → 6.28.0, @octokit/types 16 → 17, @types/node 26.1.1 → 26.1.2) into a release commit that has no business carrying it, so the four lines are edited directly and bun install --frozen-lockfile confirms the result is self-consistent.

Verification

Step	Result
bun test	1840 pass, 0 fail
bun run typecheck / lint / build	clean
bun run check:deps	core-has-no-adapter-deps: ok
bun run schema:emit	no diff
bun run release:pack -- --tag v0.4.0	prepared 5 packages
node .release/smoke/smoke.mjs	passes on 22.22.2 and 24.16.0
packages/ci/dist vs v0.3.0	byte-identical

packages/ci/dist being byte-identical means mbeacom/adrkit/packages/ci@v0 needs no move for content; the workflow's force-update of the major tag is a no-op relocation to the release commit.

One thing the simulation gets wrong, and it is not this release

bun run release:publish -- --dry-run passes all four lockstep packages at 0.4.0 and then fails:

npm error You cannot publish over the previously published versions: 0.1.2.
error: Publishing @adrkit/spec-kit@0.1.2 failed with exit 1

The registry idempotency check that skips an already-published artifact lives inside if (!dryRun) in release-publish.ts:135, so the dry run never consults the registry and asks npm to republish a version that exists. The real path does check, and the packed tarball is byte-identical to what is published:

packed now:  sha512-63jDIb5zYogVOb9Z4nDU+jgyL28UBUs0GPvHhz1Ec1eCvGClXhxSAz2La6hzBprccnHISeHRqbVFR9N+yH0LVA==
registry:    sha512-63jDIb5zYogVOb9Z4nDU+jgyL28UBUs0GPvHhz1Ec1eCvGClXhxSAz2La6hzBprccnHISeHRqbVFR9N+yH0LVA==

So the real run logs already matches; skipping. This is the first lockstep release since an independently versioned adapter existed, which is why nobody has hit it before, and it will now fail the documented local simulation on every lockstep release. Filed separately rather than fixed here, because changing release-publish.ts needs a test observed failing (ADR-0016) and that does not belong in a release cut.

Follow-ups, deliberately not in this PR

• The dry-run gap above (The publish dry-run skips the idempotency check, so it tries to republish a released adapter #104).
• Post-release docs sync. README.md, CLAUDE.md, and docs/DISTRIBUTION.md still say v0.3.0. They are left alone on purpose: the v0.3.0 cutover synced docs in docs: sync the docs to v0.3.0 and document the Spec Kit extension #81, which is a descendant of the v0.3.0 tag. Claiming "v0.4.0 on npm" before it is published would be briefly false.
• @adrkit/mcp registry re-publication at 0.4.0, as was done for 0.3.0.

[Copilot]

Pull request overview

Prepares the v0.4.0 lockstep release containing inbound @adr marker support.

Changes:

• Bumps lockstep package, CLI, MCP, root, and lockfile versions.
• Ratifies ADR-0021.
• Adds v0.4.0 notes and separates Spec Kit release history.

Reviewed changes

Copilot reviewed 10 out of 11 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
package.json	Bumps repository version.
bun.lock	Updates lockstep workspace versions.
CHANGELOG.md	Adds and reorganizes release notes.
docs/adr/0021-resolve-inbound-source-annotations-without-changing-the-schema.md	Ratifies ADR-0021.
packages/core/package.json	Bumps core version.
packages/evaluator/package.json	Bumps evaluator version.
packages/cli/package.json	Bumps CLI package version.
packages/cli/src/index.ts	Updates CLI runtime version.
packages/mcp/package.json	Bumps MCP package version.
packages/mcp/server.json	Updates MCP registry versions.
packages/mcp/src/server.ts	Updates MCP server identity.

---

💡 Add a code-review agent skill for context-aware, tailored reviews. Learn more in the docs.