chore: bump to 0.0.23-rc.1 for the first prerelease

[tonychang04]

Version bump only — needed to cut the first prerelease.

Why this is required. install.sh --staging (#66) resolves the newest prerelease, and none has ever been published for this repo — every release is a plain version with v0.0.22 as Latest. So --staging currently falls back to stable v0.0.22, which predates insta env and therefore hard-fails by design:

error: could not select environment 'staging' — this install is still pointed at PRODUCTION.
  The installed CLI (0.0.22) may predate `insta env` (needs >= 0.0.23).

Why package.json and not just the tag. Release binaries bake their version from the tag (INSTA_CLI_VERSION), so they'd be fine. But publish-npm runs a bare npm publish, which takes the version from package.json — tagging v0.0.23-rc.1 without this bump would attempt to republish 0.0.22 and fail that job.

Production is unaffected. The version is hyphenated, so per the rules added in #66 it publishes with --prerelease on the GitHub release and under npm's next dist-tag — staying off /releases/latest and off npm latest. Production installers keep getting v0.0.22 until a stable v0.0.23 is cut.

After this merges, tagging v0.0.23-rc.1 makes curl -fsSL agents.staging.instacloud.com | sh work end to end (that hostname is now live and serving agents-staging.sh).

🤖 Generated with Claude Code

https://claude.ai/code/session_01DhegxHSDCTRVC3izhkvwyF

---

Summary by cubic

Bump CLI to 0.0.23-rc.1 to cut the first prerelease and unblock install.sh --staging. Update package.json so npm publish uses 0.0.23-rc.1 and goes to npm next; production stays on v0.0.22.

^{Written for commit d0427e0. Summary will update on new commits.}

[cursor]

Bugbot is not enabled for your account, so this pull request was not reviewed.

Enable Bugbot in the Cursor dashboard to get automatic reviews on future PRs.

[jwfing]

Review: chore: bump to 0.0.23-rc.1 for the first prerelease

Summary. A clean, minimal version bump (package.json 0.0.22 → 0.0.23-rc.1, plus lockfile sync) that correctly enables the first prerelease so install.sh --staging can resolve it — every claim in the PR body checks out against the release workflow.

Requirements context. No matching spec/plan found — insta-cli has no docs/superpowers/ (and docs/ contains no spec directory). Assessed against the PR description, the referenced #66 behavior, and .github/workflows/release.yml.

Verification of the PR's claims

I confirmed each rationale in the PR body directly against .github/workflows/release.yml:

• Binaries bake version from the tag, not package.json — build job resolves version=${GITHUB_REF_NAME#v} and injects it via --define process.env.INSTA_CLI_VERSION=... (release.yml, "Build" step). ✅
• npm publish takes version from package.json — publish-npm runs a bare npm ci + npm publish with no explicit version, so package.json is authoritative. Without this bump it would try to republish 0.0.22. ✅
• Hyphenated version stays off latest — case "$TAG" in *-*) PRERELEASE="--prerelease" (GitHub release) and case "${GITHUB_REF_NAME}" in *-*) TAG_ARG="--tag next" (npm). v0.0.23-rc.1 matches, so it publishes as a GitHub prerelease under npm's next dist-tag — production /releases/latest and npm latest keep serving v0.0.22. ✅
• insta --version stays consistent — src/index.ts:48-50 returns INSTA_CLI_VERSION (baked, for compiled binaries) else package.json.version (for npm installs); both now report 0.0.23-rc.1. ✅

Findings

Critical

• (none)

Suggestion

• (none)

Information

• Software engineering — package-lock.json:3,9 was corrected from a stale "version": "0.0.0" to 0.0.23-rc.1, bringing the lockfile in line with package.json. This is an incidental improvement; the prior 0.0.0/0.0.22 mismatch was tolerated by npm ci in past releases (v0.0.22 shipped), so no risk either way.
• Software engineering — package.json:5 re-encodes the description's escaped — to a literal —. Cosmetic byproduct of the version tooling; harmless.
• Functionality — Pre-existing and out of scope for this PR: package.json name is "insta" while package-lock.json name is "insta-cli". Not introduced or worsened here; flagging only for awareness.

Dimension coverage

• Software engineering — No tests expected or needed for a version-only bump; CI (npm ci) validates lockfile↔package.json sync, which this PR actually improves.
• Functionality — Implementation matches intent exactly; the four workflow claims verified above.
• Security — No security-relevant changes (no new deps, no code, no auth/input surface).
• Performance — No performance-relevant changes.

Verdict

approved — zero Critical findings. Metadata-only change, correct and complete for cutting the first prerelease. (Informational; the green-check approval remains a separate human action.)

[jwfing]

LGTM - approved.

[jwfing]

Review: chore: bump to 0.0.23-rc.1 for the first prerelease

Summary: A correct, well-justified metadata-only version bump to 0.0.23-rc.1 that unblocks the first staging prerelease; I verified the mechanism and the "production is unaffected" claim against the release workflow and installer, and both hold.

Requirements context

No matching spec/plan found — this repo has no docs/superpowers/ (or docs/specs/) directory, so I assessed against the PR description, the referenced #66 behavior, and the surrounding code (install.sh, .github/workflows/release.yml, src/commands/upgrade.ts).

Findings

Critical

(none)

Suggestion

(none)

Information

• Functionality — the version string is safe with this repo's non-standard comparison paths (verified). The quoted hard-fail (… needs >= 0.0.23) in install.sh:215 is only hint text — the actual gate at install.sh:206-218 runs insta env use and branches on its exit code, i.e. it checks whether the env subcommand exists, not a numeric version. So a 0.0.23-rc.1 binary built from a commit containing src/commands/env.ts passes. Worth flagging only because in strict SemVer 0.0.23-rc.1 sorts below 0.0.23; nothing here uses strict SemVer. The one numeric comparator, cmpSemver (src/commands/upgrade.ts:33-41), does parseInt per dotted segment, yielding [0,0,23,1] for 0.0.23-rc.1 — so it treats the rc as greater than 0.0.23. Combined with the auto-update path reading npm's latest dist-tag (still 0.0.22), decideAction returns none for an rc user, so there's no spurious "upgrade"/downgrade nudge. No action needed — just documenting that the format was checked against all three paths.

• Security — "production is unaffected" is verified, not just asserted. release.yml:94 (case "$TAG" in *-*) PRERELEASE="--prerelease") marks any hyphenated tag as a GitHub prerelease, keeping it off /releases/latest (the default/production installer channel), and release.yml:140 publishes hyphenated versions under npm's next dist-tag instead of latest. v0.0.23-rc.1 contains a hyphen, so both rules fire. Production installers keep resolving v0.0.22. No secrets or tokens touched.

• Software engineering — no tests, appropriately. This is a pure metadata bump with no behavior change, so there is nothing to test; no test in test/ asserts the package version, so nothing regresses. Correctly scoped otherwise.

• Software engineering — lockfile now in sync (minor improvement). package-lock.json moved from a stale 0.0.0 to 0.0.23-rc.1 in both canonical lockfileVersion-3 locations (root version and packages[""].version), matching package.json. Validated as in-sync and valid JSON. This is a latent-inconsistency cleanup and is fine to carry in this PR.

• Software engineering (scope nit) — unrelated description edit. package.json also changes the description's escaped em-dash — → literal —. Semantically identical JSON and harmless (likely an editor normalization), but strictly it's outside the version-bump concern. Not worth a separate PR for one character — noting only for scope-discipline awareness.

Verdict

approved (informational — a human still gives the explicit GitHub approval). Zero Critical findings; the change is correct, minimal, and its safety claims are verified against the release workflow and installer.