chore(master): release 0.2.3

[scrollDynasty]

🤖 I have created a release beep boop

0.2.3 (2026-10-08)

Features

• return actionable next steps with every error and add two workflow prompts (#68) (53a5c0d)

---

This PR was generated with Release Please. See documentation.

[claude]

Review: release-please version bump — sound

This is a mechanical Release Please PR (0.2.2 → 0.2.3) with no runtime code change, so the correctness / security / isolation-contract axes have no surface here. What I did check:

Version consistency (the four places the release skill says must agree, plus the manifest and lockfile):

• package.json → 0.2.3
• server.json $.version and $.packages[0].version → both 0.2.3
• src/infrastructure/generated/version.ts → 0.2.3, PLAYWRIGHT_VERSION still 1.62.1, matching the exact playwright pin in dependencies
• .release-please-manifest.json and both root version fields in package-lock.json

I byte-checked version.ts against what scripts/generate-version.ts emits (header, x-release-please-start-version markers, LF endings, trailing newline) — it matches exactly, so check:version / pretypecheck will not go red. The assertions in tests/unit/publish-workflow.test.ts (BROWSERMESH_VERSION === packageJson.version, serverJson.version, serverJson.packages[0], lockfile playwright pin) all hold.

Bump level: release-please-config.json sets bump-minor-pre-major + bump-patch-for-minor-pre-major, so the feat in #68 correctly yields a patch (0.2.3), not 0.3.0. chore(deps) (#69) is correctly absent from the changelog.

No stale 0.2.2 strings anywhere outside CHANGELOG.md and AUDIT.md (the latter is a dated audit snapshot referencing the historical version — correct as-is).

One non-blocking note before merge, not a defect in this diff: merging this PR cuts the v0.2.3 tag and runs .github/workflows/publish.yml, where the MCP Registry steps run after npm publish --access public in the same job. AUDIT.md §2.7 and the release skill both record that the 0.2.2 run failed at "Publish to npm with OIDC" (npm error code ENEEDAUTH), which skipped all three registry steps and left the registry a version behind. If npm Trusted Publishing still isn't configured for the browsermesh package, this release will fail the same way and burn 0.2.3 without correcting the registry. Worth confirming the trusted publisher (this repo, publish.yml, npm environment) is in place first.

[claude]

Review: release-please version bump 0.2.2 → 0.2.3

No findings. This is a pure automated release PR — no source, test, or workflow code changes — so none of the correctness, resource-lifecycle, or session/page-isolation surfaces are touched. Nothing in the diff logs, returns, or persists page content, tokens, saved browser state, or filesystem paths.

What I verified against the release contract:

Bump level is correct. release-please-config.json sets both bump-minor-pre-major and bump-patch-for-minor-pre-major, so pre-1.0 a feat produces a patch. #68 was a feat, and 0.2.2 → 0.2.3 matches.

All four version carriers agree, plus the manifest and lockfile:

• package.json:3 → 0.2.3
• server.json:11 and server.json:16 (both fields release-please tracks via extra-files) → 0.2.3
• src/infrastructure/generated/version.ts:3 → 0.2.3, regenerated rather than hand-edited (the x-release-please-start-version markers and the generator banner are intact, and PLAYWRIGHT_VERSION is untouched at 1.62.1)
• .release-please-manifest.json and both lockfile version fields (top-level and packages[""]) → 0.2.3

That satisfies every assertion in tests/unit/publish-workflow.test.ts (BROWSERMESH_VERSION === packageJson.version, serverJson.version, serverJson.packages[0].version) and check:version, which runs as pretypecheck.

Playwright pin is undisturbed. package.json still carries the exact "playwright": "1.62.1", matching packages[""].dependencies.playwright and node_modules/playwright in the lockfile — no ^ range drift.

The branch is current with master. Diffing the merge result against ba4ca53 (chore(deps): bump ip-address, #74) yields only the version lines, and node_modules/ip-address is still 10.7.2 — the release branch does not revert the dependency bump merged after it. Since release-please regenerated the PR on top of #74 and still emits only the #68 entry, the changelog isn't missing a releasable commit; #69–#74 were non-releasing types.

Formatting is safe. CHANGELOG.md is in .prettierignore; the JSON files changed only existing values at existing indentation, so format:check stays green.

---

One pre-existing operational note for whoever merges this, not a defect in the diff: docs/IMPLEMENTATION_STATUS.md:41-47 and the release skill both still record that npm Trusted Publishing is not configured for browsermesh, and AUDIT.md item 2.7 records the 0.2.2 publish.yml run failing at the OIDC step with ENEEDAUTH, which skipped MCP Registry publication. I could not verify from this branch whether that has since been fixed on npmjs.com. If it hasn't, merging this will tag 0.2.3 and fail the same way. Worth confirming the trusted publisher before merging so the registry entry catches up on its own.

[claude]

Reviewed as a release-please version bump. No source behaviour changes, so the correctness / security / isolation axes have no surface here — the only thing worth checking is whether the six version artifacts stay mutually consistent, and they do.

Verified against the invariants the repo actually enforces (tests/unit/publish-workflow.test.ts, check:version via pretypecheck):

• BROWSERMESH_VERSION (src/infrastructure/generated/version.ts) == package.json == server.json $.version == server.json $.packages[0].version == .release-please-manifest.json — all 0.2.3.
• package-lock.json updated in both required places (root version and packages[""].version), so the lockfile-consistency assertion holds.
• PLAYWRIGHT_VERSION left at 1.63.0, matching the exact (non-range) playwright pin in package.json. The generated file was regenerated rather than hand-edited: the surrounding bytes and the x-release-please-start-version markers are untouched, so check:version will not flag drift.
• 0.2.2 -> 0.2.3 is the correct bump. release-please-config.json sets bump-patch-for-minor-pre-major: true, so a feat below 1.0.0 is a patch — the Features heading in the changelog next to a patch version is expected here, not a misconfiguration.
• The changelog entry is prepended above 0.2.2 with the right compare link and a date matching the release day. CHANGELOG.md is in .prettierignore, so its formatting will not trip format:check.

Two things I checked and am deliberately not raising as findings:

• AUDIT.md still cites 0.2.2 and is not in release-please extra-files. That is correct — it is a point-in-time audit pinned to a specific commit, not a living version reference.
• That same audit recorded a P0 that the 0.2.2 npm publish died at ENEEDAUTH. .github/workflows/publish.yml now carries an explicit "Verify npm supports trusted publishing" gate (npm >= 11.5.1) ahead of npm publish, which is the usual cause, so that looks addressed on master already. Out of scope for this diff either way — flagging only so nobody re-litigates it from the stale audit.

No findings. Sound to merge; the tag push is what exercises the publish path.

[claude]

Review: mechanical release PR — no findings

This is a release-please bump with no runtime code in the diff, so the correctness / security / isolation axes have nothing to attach to: no browser contexts, pages, listeners, timers, logging, or MCP result paths are touched, and the session/page addressing and per-session serialization contracts are untouched.

I verified the one thing a release PR can actually get wrong — version consistency across every file that carries it:

File	Value
.release-please-manifest.json	0.2.3
package.json	0.2.3
package-lock.json (.name, .version, packages[""].version)	0.2.3
server.json (.version and .packages[0].version)	0.2.3
src/infrastructure/generated/version.ts	0.2.3

All five agree, which is exactly what tests/unit/publish-workflow.test.ts ('keeps the server identity and package versions consistent') asserts. The generated module is byte-identical to what scripts/generate-version.ts emits for version 0.2.3 plus resolved playwright 1.63.0, so check:version / pretypecheck will not go red on stale generated output. The Playwright pin is still the exact 1.63.0 in package.json, in packages[""].dependencies.playwright, and in node_modules/playwright in the lockfile — no ^ drift, so the release-contract assertions at tests/unit/publish-workflow.test.ts:59-65 hold.

The feat to patch bump (0.2.2 → 0.2.3) rather than a minor is the configured pre-1.0 behaviour (bump-minor-pre-major plus bump-patch-for-minor-pre-major in release-please-config.json), not a mistake. CHANGELOG.md and package-lock.json are both in .prettierignore, so release-please's changelog spacing won't trip format:check; the three JSON files that are format-checked only changed version string values, with indentation intact. No doc, README.md, or .mcp.json pins the current version, so nothing else needed bumping.

No new behaviour is introduced, so no new tests are warranted — the existing release-contract test already covers this diff's entire surface.

One pre-merge caveat (repo state, not the diff). .claude/skills/release/SKILL.md and docs/IMPLEMENTATION_STATUS.md both still record npm Trusted Publishing as unconfigured for browsermesh, and AUDIT.md:122 records the 0.2.2 run failing at 'Publish to npm with OIDC' with ENEEDAUTH, which skipped all three MCP Registry steps. Since registry publication runs after npm publish in the same job, merging this will likely reproduce that failure and leave the registry behind again — and per the skill's own rule, a failed publication can only be fixed by cutting another patch, never by retagging. Worth confirming the trusted publisher exists on npmjs.com before merging; nothing in this diff can address it.

Looks good to me on the code-review axes.

🤖 Generated with Claude Code