chore: bump version to 0.0.59

[tonychang04]

Release 0.0.59: insta project create|link and insta observe install gitignore the local state they write (.insta/observe/, .insta/audit.jsonl, skills-lock.json), print a git rm -r --cached hint for paths that were committed before the CLI ignored them, and write a shell-neutral, portable .codex/hooks.json entry that works in nested monorepo projects and on Windows (#178).

Merge after #178. Tag v0.0.59 on main afterwards triggers the release workflow (binaries + npm via OIDC).

🤖 Generated with Claude Code

https://claude.ai/code/session_0144rBPvDXaGgoje2QnmfxzY

---

Summary by cubic

Bumps the CLI version from 0.0.58 to 0.0.59 for release. This version carries the #178 changes: insta project create|link and insta observe install now gitignore the local state they write (.insta/observe/, .insta/audit.jsonl, skills-lock.json), print a git rm -r --cached hint for previously committed paths, and write a shell-neutral .codex/hooks.json entry that works in nested monorepos and on Windows.

Merge this after #178, then tag v0.0.59 on main to trigger the release workflow (binaries + npm via OIDC).

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

[cubic-dev-ai]

No issues found across 2 files

_{Re-trigger cubic}

[jwfing]

Summary
No blocking issues found in the 0.0.59 version bump.

Requirements context
I based intent on the PR #179 description, which says this bump releases the behavior from linked PR #178 and should merge after it, then be tagged as v0.0.59 (PR #179, PR #178). The repo release docs describe this exact shape: open a PR bumping package.json, merge it, then tag vX.Y.Z on main to trigger binaries and npm publishing (.claude/skills/developing-insta-cli/SKILL.md:47-60, CONTRIBUTING.md:75-87, .github/workflows/release.yml:38-52).

Findings

Critical
(none)

Suggestion
(none)

Information

• Software engineering: the changed release metadata is consistent: package.json is 0.0.59, and both root version fields in package-lock.json match (package.json:1-3, package-lock.json:1-9).
• Functionality: this PR correctly performs the release-bump portion only; the actual user-facing behavior described in the PR depends on #178 landing before this is merged and tagged (CONTRIBUTING.md:75-87, .github/workflows/release.yml:38-52).
• Security: no security-relevant code, auth, dependency, or logging surface changes in this diff (package.json:44-53, package-lock.json:11-24).
• Performance: no runtime or hot-path changes; this is package metadata only (package.json:1-3, package-lock.json:1-9).
• Verification: git diff --check main...HEAD passed. I did not run npm run typecheck && npm test because this read-only checkout has no node_modules, and installing dependencies would mutate the workspace (package.json:35-42, CONTRIBUTING.md:48-53).

Verdict
Approved per the severity rule: no critical findings. Post as a comment rather than a GitHub green-check approval.

[jwfing]

LGTM - approved.

[jwfing]

Summary

A mechanically correct 3-line version bump (0.0.58 → 0.0.59) — but it merged before #178, the PR whose changes this release is named after, so v0.0.59 cannot be tagged yet without shipping an empty release.

Requirements context

This repo has no docs/superpowers/ tree — in fact no docs/ directory at all. No matching spec/plan found; assessed against the PR body, the repo's own release procedure in .claude/skills/developing-insta-cli/SKILL.md §"Shipping a release" (bump PR → merge → tag → automatic binaries + npm), AGENTS.md, and .github/workflows/release.yml.

The bump itself follows that procedure exactly: step 1 is "PR changing package.json version (main is protected — never commit the bump directly)", which is precisely this PR.

State verified at review time

Re-checked immediately before posting:

Check	Result
origin/main	bd22dff chore: bump version to 0.0.59 (#179) — tree identical to PR head a2b8640, nothing smuggled in
git diff 208d3c5..bd22dff	the 3 version lines only
git cat-file -e origin/main:src/gitignore.ts	does not exist — #178 is not on main
PR #178	still open (head 38743c3, review round 3)
git ls-remote --tags origin refs/tags/v0.0.59	0 matches — highest tag is v0.0.58 → 208d3c5
npm dist-tags.latest	0.0.58
Gates in a clean clone at a2b8640 (npm ci → tsc --noEmit → vitest run)	typecheck clean, 702/702 pass

---

Findings

Critical

1. Functionality / release correctness — the merge order stated in this PR was inverted, so tagging v0.0.59 on current main would publish a release that contains none of what it claims (package.json:3, package-lock.json:3,9)

The PR body states two explicit instructions: "Merge after #178" and "Tag v0.0.59 on main afterwards triggers the release workflow (binaries + npm via OIDC)." The first was not honored — this landed as bd22dff while #178 is still open — which makes the second instruction actively harmful right now:

• main reads version: "0.0.59" but is byte-for-byte 0.0.58 in behavior. git diff v0.0.58..main is only the three version lines; src/gitignore.ts (the file #178 adds) is absent.
• Pushing v0.0.59 today fires .github/workflows/release.yml: five binaries + a GitHub Release, then publish-npm (release.yml:129-146) publishes insta@0.0.59 to the registry under the latest dist-tag. An npm publish cannot be cleanly unpublished — the version-release skill calls this out as the reason for its tag_exists idempotency check.
• Every installed CLI would then auto-upgrade into it: decideAction(cache, '0.0.58', true, 'binary'|'npm') → 'auto' (test/upgrade.test.ts:38-40). That is a forced fleet-wide upgrade to a build identical to what users already run.
• It also burns the number. Once #178 lands it can't reuse 0.0.59 (npm publish publishes package.json's version, and the tag would already exist), so it needs a second bump PR to 0.0.60 — with 0.0.59 permanently on npm as a phantom release whose announcement text describes the gitignore + portable-Codex-hook work.
• The auto-generated GitHub release notes are the tell: gh release create … --generate-notes (release.yml:117-122) would emit a single line — chore: bump version to 0.0.59 (#179) — with nothing else between v0.0.58 and the tag.

Remedy (the merge can't be undone, so this is a gate on the tag, not the merge): do not push v0.0.59 until #178 is on main. Before tagging, assert it mechanically —

git fetch origin && git rev-parse origin/main
git cat-file -e origin/main:src/gitignore.ts   # must succeed
node -p "require('./package.json').version"    # must print 0.0.59

If #178 changes shape in round 4+ or does not land, this bump's identity is wrong and the body needs correcting before any release is cut.

Suggestion

2. Software engineering / CI — release.yml never asserts the tag matches package.json's version (.github/workflows/release.yml:38-44 vs 129-146)

The binaries take their version from the tag ref (version=${GITHUB_REF_NAME#v}, baked in via --define), while publish-npm publishes whatever package.json says. Nothing checks the two agree. The workflow's own header comment already documents this exact divergence for the workflow_dispatch path ("a dispatch release would ship binaries at one version and leave npm on the previous one") — but the tag path has the same hole whenever a tag is pushed at a commit whose package.json hasn't caught up. Finding #1 is the manual-discipline version of this same risk. A one-line guard in the build job would make it mechanical:

test "v$(node -p 'require("./package.json").version')" = "$GITHUB_REF_NAME"

Out of scope for a bump PR — raising it as a follow-up, since the ordering slip here is exactly what it would have caught.

Information

3. Functionality — the bump is complete; nothing else hardcodes the version. All three occurrences were updated (package.json:3, package-lock.json:3,9) and grep -rn '0\.0\.5[89]' over the head tree returns only those. src/version.ts:5-7 resolves the version from INSTA_CLI_VERSION (baked into binaries) else by reading package.json at runtime, so package.json is the single source of truth and no code change is needed. README.md:57's INSTA_VERSION=v0.0.22 is illustrative, not a pin.

4. Software engineering — no tests are needed or missing. No test hardcodes the current version; test/user-agent.test.ts:3 imports cliVersion rather than asserting a literal, which is the right call (a test pinning the version would need editing every release). AGENTS.md rule 4 (mirror command/flag changes into skills/insta/cli-reference.md) does not apply — no command or flag changed. This is also the first bump merged as a squash per AGENTS.md non-negotiable 1; the 0.0.58 bump came in as a merge commit.

5. Security — no security-relevant changes in this PR. The package-lock.json diff contains zero dependency changes: the only +/- lines are the two self-version fields. No new packages, no version ranges moved, no supply-chain surface. No secrets, tokens, auth paths, or user input touched. (npm ci in the clone reports 7 advisories, but npm audit --omit=dev returns 0 — all of them are dev-only and none reach a published artifact. Pre-existing, not this PR's doing.)

6. Performance — no performance-relevant changes in this PR. No runtime code paths, queries, or loops are touched.

---

Verdict

request_changes — one Critical. The diff itself is correct and I'd have no objection to it on its own; the blocking item is the release action it authorizes. Hold the v0.0.59 tag until src/gitignore.ts is on main, then this bump is good to ship as-is.