[goosewobbler]

Description

@releasekit/release bundles version, notes and publish from their own builds, and each of those inlines its own copy of @releasekit/core — so release/dist holds four distinct ReleaseKitError classes. ReleaseKitError.isReleaseKitError was a bare instanceof, so an error thrown inside the version, notes or publish stage of release or standing-pr failed the check against release's copy. toEnvelopeError then reported it as GENERAL_ERROR and exitCodeForError exited 1, whatever actually failed — the JSON envelope's error codes were generic for exactly the commands CI and agents use most.

Every ReleaseKitError is now stamped with a non-enumerable Symbol.for('@releasekit/core:ReleaseKitError') brand, and isReleaseKitError accepts it alongside instanceof. Symbol.for keys a process-wide registry, so every copy stamps and recognises the same key. The brand is non-enumerable, so it never appears in spreads, JSON, or toEqual comparisons.

Behaviour change: release --json / standing-pr --json now report the specific code of a stage failure (e.g. PIPELINE_STAGE_ERROR, INVALID_CONFIG) instead of GENERAL_ERROR; those codes' categories (pipeline-stage, invalid-config, …) follow, and so does retryable — an escaped notes LLMError can now report retryable: true where it was forced to false. Exit codes follow the code → exit table. On main that table doesn't yet list the specific publish/version codes, so those still exit 1 until #616's expanded table lands (then e.g. PIPELINE_STAGE_ERROR → 9); codes that already name a family change now — a stage's CONFIG_ERROR → 2, GIT_ERROR → 7, and notes' input-parse/template/LLM errors → 3/4/5. The repo's workflows and the Action only check for non-zero.

Interaction with #616: #616 documents the current behaviour in docs/cli.md ("release and standing-pr currently report an error raised inside their version, notes, or publish stage as GENERAL_ERROR"). Whichever of the two merges second should drop that sentence.

The roadmap housekeeping that used to ride on this branch is now #665.

Related Issue(s)

Part of #544 (structured error codes). Found while reviewing #616.

Type of Change

• feat — New feature
• fix — Bug fix
• docs — Documentation change
• refactor — Code refactoring
• test — Adding or updating tests
• chore — Maintenance, dependencies, tooling
• Breaking change — Requires major version bump

Scope

• @releasekit/version
• @releasekit/notes
• @releasekit/publish
• @releasekit/config
• @releasekit/core
• CI / workflows
• Root / monorepo

Checklist

• Lint passes (pnpm lint)
• Tests pass (pnpm test) — core 197, release 847
• Typecheck passes (pnpm typecheck)
• Documentation updated (if applicable)
• Breaking changes noted in description (none; behaviour change above)

Testing Notes

• Cross-bundle regression test — packages/release/test/unit/commands/cross-bundle-errors.spec.ts throws a real error from each built stage package (version GIT_ERROR, notes LLM_ERROR with retryable: true, publish CONFIG_ERROR) through release --json, and checks the envelope's code, retryable and message, and the exit code. Each case first asserts the error isn't an instance of release's ReleaseKitError, so it fails loudly if a stage build stops carrying its own copy of core. With the fix reverted, all three cases fail with GENERAL_ERROR.
• Core unit tests — a fresh module instance (vi.resetModules) stands in for another copy and fails without the fix; the brand stays non-enumerable.
• Built CLI, end to end — release --json in a scratch repo: a failing push now reports PIPELINE_STAGE_ERROR ("Failed to push to remote: …") and a version-stage config error INVALID_CONFIG, where both previously reported GENERAL_ERROR.

🤖 Generated with Claude Code

https://claude.ai/code/session_01HQN3v9Z4f1mu3xK4Z7K44e

Confidence Score: 5/5

The PR appears safe to merge; no actionable issues were found.

Summary

ReleaseKitError now uses a shared, non-enumerable symbol to recognize errors from separately bundled copies of core.

• Release commands keep stage errors’ specific codes across bundled core copies.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart LR
  A[Stage throws an error] --> B[Shared symbol identifies the error]
  B --> C[JSON keeps its specific code and retry flag]
  B --> D[Exit code follows the existing table]

Loading

_{Reviews (2) · Last reviewed commit: "test(release): drive cross-bundle errors..." · Reviewed by Greptile}

[github-actions]

Standing release PR: #614 · v0.42.0 queued (4 packages) · open 81d 21h 34m · ✅ ready to merge

Release Preview — v0.41.2 → v0.41.3

Note: Labels on this PR are advisory in standing-pr mode. Bumps come from conventional commits in the standing PR; override by editing labels on the standing PR itself. Add release:immediate to bypass the standing PR and release this PR directly.

These changes will be added to the release PR (#614) when merged:

Changelog

monorepo 0.41.2 → 0.41.3

Changed

• drive cross-bundle errors through the release command (release)

Fixed

• recognise ReleaseKitError across bundled copies of core (core)

All packages → 0.41.3 (sync versioning)

• @releasekit/version
• @releasekit/notes
• @releasekit/publish
• @releasekit/release

After merge — predicted release

No version escalation — this PR's changes will be included in the queued release without affecting the projected versions.

Package	Standing PR	This PR	After merge
monorepo	0.42.0	0.41.3	0.42.0

---

Updated automatically by ReleaseKit

[goosewobbler]

@greptileai review plz