Skip to content

chore(master): release 0.2.3 - #70

Open
scrollDynasty wants to merge 2 commits into
masterfrom
release-please--branches--master--components--browsermesh
Open

scrollDynasty wants to merge 2 commits into
masterfrom
release-please--branches--master--components--browsermesh

Conversation

@scrollDynasty

@scrollDynasty scrollDynasty commented Sep 10, 2026 •

Copy link
Copy Markdown
Owner

🤖 I have created a release beep boop

0.2.3 (2026-09-30)

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

claude Bot commented Sep 10, 2026

Copy link
Copy Markdown
Contributor

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.

@scrollDynasty
scrollDynasty force-pushed the release-please--branches--master--components--browsermesh branch from 539290b to 719c98e Compare September 30, 2026 10:22
@claude

claude Bot commented Sep 30, 2026

Copy link
Copy Markdown
Contributor

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

claude Bot commented Sep 30, 2026

Copy link
Copy Markdown
Contributor

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.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant