chore(main): release 0.3.7

[github-actions]

🤖 I have created a release beep boop

0.3.7 (2026-05-20)

Features

• auto-heal: LLM-in-the-loop selector recovery on probe failure (#19) (07ee9af)
• browser: add tabs() and activateTab() primitives (0fb8093)
• ci: add daily-health cron, release-please, dependabot auto-loop (c83ac9a)
• cli: accept stdin (-) and --prompt-file for prompt/ask (7ade62d)
• cli: grouped help + per-verb --help + stop advertising legacy aliases (1c9a229)
• designer doctor + designer-chrome.sh launcher (3aec9d8)
• designer health — enumerate + probe every UI anchor we depend on (e0420c0)
• dx: bin/designer wrappers + npm-script shortcuts (3fbc2fd)
• health: add file-list scrape probe (5482800)
• health: probe a canary project for session-state anchor coverage (ad5afd1)
• health: two-phase home+session probe with adaptive wait (#18) (700f3d1)
• iterate: raise default timeout 10m -> 20m for hi-fi runs (42783fd)
• listFiles: detect folders, report honestly, point at handoff (66fb654)
• pod: merge feat/pod-support — ccrotate-designer lease wiring (#2) (2ea6939)
• prompt: add --decisive suffix and awaitingClarification status signal (8beb648)
• prompt: auto-append flat-layout suffix to every designer_prompt (03421b9)
• setup: one-call onboarding (designer setup) (2ba6701)

Bug Fixes

• anchors: replace chatTurnPrefix text-prefix check with data-index API (#24) (e7781ef)
• auto-heal: security + silent-failure hardening from second-opinion review (#21) (f959d7b)
• browser: default DESIGNER_CDP to 9222 so shell callers attach to the live Chrome (6db4052)
• ci: capture tar output to file to avoid pipefail SIGPIPE (d877046)
• ci: gate dependabot-automerge on completed CI run (bbc4375)
• ci: grouped-PR automerge + auto-close stale drift PRs on green (1af0494)
• ci: tighten the auto-loop after second-opinion review (b98a91f)
• ci: use prepack hook so npm pack rebuilds dist/ (658b78a)
• doctor,health: split misleading labels; gate iframe probes on file-open (c974572)
• ensure_ready: pick the live project tab among multiple matches (3097af0)
• handoff: Export moved under Share dropdown; try Share first (e944e21)
• listFiles: authoritative=false when rail is empty under visible 'Design Files' label (268c2fb)
• listFiles: tree-walk text nodes (claude moved filenames from <span> to styled <div>) (023d7c5)
• postinstall: move to standalone file; fix shell quoting bug (d79269f)
• setup,doctor: trust installed-mode (npx/bunx/pnpm don't put node_modules in pkg dir) (4ae41b4)
• setup: handle installed-mode (no package-lock in shipped tarball) (dd46b40)
• setup: register MCP at user scope so it's available in every project, not just this repo (1459ab2)
• setup: verify signed-in via DOM marker, not URL substring (#22) (f7a27ec)
• tasting: keyboard 1/2/3 work when focus is inside the iframe (640640c)
• types: eliminate two /casting findings (e9a341a)
• workflows: add /opt/homebrew/bin to PATH on self-hosted runner (#25) (e8f492f)

---

This PR was generated with Release Please. See documentation.

[allyblockcast]

Retaining this PR because it is the clean, bot-managed release-please artifact for 0.3.7 (autorelease: pending). It is unblocked by a release owner merging it; otherwise release-please may supersede it when the release train advances. It does not require Ally review.

Disposition tracked in https://paperclip.blockcast.net/BLO/issues/BLO-20376.

[allyblockcast]

Review — chore(main): release 0.3.7 @ bc0ef1fc7b

The diff itself is mechanically correct, but I don't think this release should be cut. Two blocking issues, both about the fork's release wiring rather than the diff.

---

🔴 Critical — 0.3.7 is already released; this publish cannot succeed

Blockcast/designer is a fork of pro-vi/designer, currently 1 ahead / 79 behind upstream main. Upstream has already shipped this version:

Fact	Value
Upstream tag v0.3.7	commit a67be0d4134885e5f44093b280568fea872e5a06
@pro-vi/designer@0.3.7 on npm	published 2026-05-25, gitHead a67be0d4… (same commit)
npm dist-tags.latest	0.3.24
Upstream latest tag	v0.3.24

Merging this cuts a fork-local v0.3.7 tag pointing at a different commit than the 0.3.7 that was actually released, for a version number that is 17 releases stale.

Then release-publish.yml runs npm publish --provenance --access public against @pro-vi/designer@0.3.7. npm does not allow republishing an existing version, so that step fails with a 403 — leaving a tag and a GitHub release behind with no artifact, and a red workflow. Note also that the package name belongs to the upstream @pro-vi scope, not to this fork.

The Verify version matches tag step in release-publish.yml won't catch this: it only compares package.json to the tag, and those agree. Nothing checks the version against what's already on the registry.

🟠 Important — this release PR has no CI signal at all

Verified against the API:

• actions/runs?branch=release-please--branches--main--components--designer → total_count: 0
• runs with head_sha == bc0ef1fc7b… → 0
• for contrast, PR #4's branch (chore/lockfile-refresh) does produce ci and Docker runs

ci.yml triggers on pull_request: branches: [main], which this PR matches, so the trigger config isn't the problem. The most likely cause is GitHub's recursion prevention: events produced by secrets.GITHUB_TOKEN — which release-please.yml passes to release-please-action@v4 — do not start new workflow runs.

That matters because release-please.yml's own comment makes the human merge the gate ("the PR is the human's 'yes, this is worth a version'"). Right now that gate has zero automated verification behind it: nothing typechecks, builds, or runs the clean-room install smoke on the commit being released.

Probable knock-on (flagging as likely, not confirmed): the same rule should also stop a GITHUB_TOKEN-created release from firing release-publish.yml's on: release: [published]. Consistent with that, this fork has 5 tags but zero GitHub releases. So merging may quietly no-op rather than publish — which is a different failure than the 403 above, but not a better one. I haven't observed a release being created here, so treat this one as inference.

The standard fix for both is to give release-please-action a PAT or GitHub App token instead of GITHUB_TOKEN.

🟡 Minor — the changelog is misattributed and its links are dead

• The 0.3.7 section aggregates ~40 commits spanning the entire pre-fork history — work already shipped upstream in v0.3.0–v0.3.5 — because the fork has no prior CHANGELOG.md or matching tag to use as a baseline. Self-correcting on later runs, but this entry claims credit for three releases' worth of work.
• The compare link compare/v0.3.6...v0.3.7 404s: no v0.3.6 tag exists in this fork. Present tags are v0.3.0, v0.3.2, v0.3.3, v0.3.4, v0.3.5 — both v0.3.1 and v0.3.6 are absent, though .release-please-manifest.json claimed 0.3.6.
• Issue links #18–#25 were rewritten to Blockcast/designer URLs, but those are upstream numbers. This fork's highest issue/PR number is 4, so every one of those links 404s.

---

✅ What is correct

The version bump is internally consistent across all four files: .release-please-manifest.json, package.json, and both the root and packages[""] entries in package-lock.json (lockfileVersion 3). The patch bump — rather than a minor, despite the feat: entries — correctly reflects bump-patch-for-minor-pre-major: true in release-please-config.json.

Suggested path

The underlying question is whether this fork should be running release automation at all. Either:

1. Disable release-please.yml and release-publish.yml in the fork — most likely correct if Blockcast/designer tracks upstream and isn't meant to publish to npm; or
2. Re-sync with upstream (79 commits behind) and version forward from 0.3.24 under a package name this fork owns, so releases can't collide with @pro-vi.

Happy to re-review once the direction is picked.