[mariojgt]

No ticket.

What changed

setup now finishes in projects that only accept package versions older than a day. That is the default in pnpm 11 and later, and v0 projects use pnpm 12.

• The exact version is refused: setup lets the package manager add the newest version it allows. Then it hands over to that version's own setup, with the same arguments. The person sees one line: "This project accepts @patchstack/connect 0.5.72, not 0.5.75, so setup continues with 0.5.72."
• That fails too: the output now ends on a plain line, "Setup did not finish, so Patchstack is not set up and there is no link to connect it yet." The assistant can't then tell the person it worked.

Projects that accept the running version behave exactly as before.

Why

npx @patchstack/connect setup runs the newest release. Setup then adds that exact version to the project, so the files it writes match the package the app imports. pnpm 11+ refuses any version published in the last day (ERR_PNPM_NO_MATURE_MATCHING_VERSION), and we often release more than once a day. So in a pnpm 11+ project, setup usually failed at its very first step.

When it failed, setup stopped before writing anything: no dependency, no config, no widget, no guard, no summary and no link to connect the account. The error could scroll past in the install log. In a v0 chat, the assistant then told the person "setup completed successfully". The person was left with no widget and no claim link.

Earlier v0 installs only worked because the assistant improvised: it added @patchstack/connect@<version> to minimumReleaseAgeExclude in pnpm-workspace.yaml. Setup doesn't do that itself. It would switch off a safety setting the person chose, for our package, and agents treat that kind of change as a warning sign.

Fix

• src/cli.ts, setup's install step:
  • Try the running version first, as before. Its failure output is held back, because the next attempt settles it.
  • If that fails, install with no version (installSelf(..., null)), so the package manager picks the newest version it allows.
  • If that gives a different version, run its CLI (installedCli, runInstalledSetup in src/bootstrap.ts) with process.argv.slice(2) and return its exit code. The running setup stops there, so only one version writes files.
  • If it gives the same version, carry on as normal.
  • If both fail, print the reason (the last lines of the second attempt) and end on SETUP_NOT_FINISHED (src/report.ts) when an assistant is reading.
• Disclosure:
  • The new process (the installed version's own CLI) is in the inventory in tests/execution-disclosure.test.ts (src/bootstrap.ts spawnSync, 1 → 2).
  • README.md and AGENT-INSTALL.md say when setup does this, in the paragraph that already discloses the install, and in AGENT-INSTALL's setup row.

Verified

• Real pnpm 12.16.1 and the real registry, with minimumReleaseAge: 1440 in pnpm-workspace.yaml, and Patchstack pointed at a dead local address so nothing was sent:
  • pnpm add @patchstack/connect@0.5.75 fails with ERR_PNPM_NO_MATURE_MATCHING_VERSION. That is the old behaviour, and what happened in v0.
  • The new setup prints one line, installs 0.5.72 ("^0.5.72" in package.json), and 0.5.72's setup takes over.
  • Without the age setting, setup installs 0.5.75 as before.
• tests/bin-invocation.test.ts, two new tests with a stand-in pnpm. Both fail on the previous code.
  • A pnpm that refuses @patchstack/connect@<version> but installs an older stand-in: setup says which version it continues with, the stand-in's CLI receives setup --widget, and the newer setup writes nothing.
  • A pnpm that fails every time: exit code 1, stderr says setup did not finish, and the last line of stdout is the "Setup did not finish" line.
  • The existing "standalone HTML page" test still passes.
• Gates:
  • npm run typecheck, npm run build and capabilities:check are green.
  • Full npm test: 4662 passed, 7 skipped. One test failed: "stays a small multiple of the same rewrite on text that is not JSON" is a timing test, and passes on its own (12/12).

Out of scope, worth a follow-up

• Today's fallback lacks the closing reminder. Until 0.5.74 is a day old (14:43 UTC today), the fallback version is 0.5.72. That version still prints the summary with the claim link, but not the closing line "your reply must include… this link" (added in 0.5.74). From then on, the fallback is never more than about a day behind.
• Fixes reach pnpm 11+ projects a day late. That stays true with this change; setup now works with the older version instead of failing.
• The terminal report doesn't end on the link. When stdout is a terminal, the claim link sits in the next-step box and there is no closing line. If v0's assistant runs commands in a terminal (not yet confirmed), it could still miss the link even when setup finishes.

Docs: README.md and AGENT-INSTALL.md disclose the fallback. Agents audit these, so the hostile field test is owed after the release that carries this, plus standard/lovable for doc accuracy.

🤖 Generated with Claude Code

[mariojgt]

/review

[coderbuds]

🎯 Elite quality (98%) — Adds a pnpm-maturity fallback that installs the newest allowed version and hands setup over to it.

📦 Medium

_{See how your team is trending →}