chore: release 0.0.32

[CarmenDou]

What

Version bump only: 0.0.31 → 0.0.32 in package.json + package-lock.json. No code changes — same two-file shape as #88 (chore: release 0.0.31).

How

npm version 0.0.32 --no-git-tag-version, off main. The tag itself is pushed after this merges, per AGENTS.md's release flow.

Verify

git diff --stat is exactly package-lock.json | 4 ++-- and package.json | 2 +-, matching the previous release commit.

---

Merge #91 first. This release is meant to carry services add's Add Service kinds, --json, and the local image/port validation; tagging before #91 lands would ship 0.0.32 without them.

---

Summary by cubic

Bumps the CLI version from 0.0.31 to 0.0.32 in package.json and package-lock.json. No code changes; behavior is unchanged.

• Merge feat(services): answer a bare services add with the kinds, and give it --json #91 first so 0.0.32 includes services add’s Add Service kinds, --json, and local image/port validation.
• Push the tag after this merges, following the release flow.

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

[cubic-dev-ai]

No issues found across 2 files

_{Re-trigger cubic}

[jwfing]

Review: chore: release 0.0.32

Summary: A mechanically clean patch version bump (0.0.31 → 0.0.32) touching only package.json and package-lock.json, exactly as the PR claims.

Requirements context: No /docs/superpowers/ spec directory exists in this repo — assessing against the PR description and the documented release flow in .claude/skills/developing-insta-cli/SKILL.md ("Shipping a release", step 1: "PR changing package.json version… main is protected — never commit the bump directly"). This PR conforms to that convention.

Verification performed

• Diff is exactly three lines: package.json:3 and package-lock.json:3,9, all 0.0.31 → 0.0.32. Matches the git diff --stat shape the author claims and the prior release commit (abd742b chore: release 0.0.31).
• grep for 0.0.31/0.0.32 across the tree confirms there are no other stray version references left at the old value — the three bumped spots are the only ones.
• Patch increment is sequential and correct (…0.0.29 → 0.0.30 → 0.0.31 → 0.0.32).
• lockfileVersion: 3; the sole dependency (commander ^12.1.0) is unchanged, so no lockfile tree churn is expected — consistent with the 2-line lockfile delta.

Findings

Critical: (none)

Suggestion

• Functionality / release sequencing — The PR body correctly notes "Merge #91 first." I confirmed #91 (feat(services): … services add … --json) is still OPEN, and its base is the same commit as this PR (bfb70ae, still 0.0.31). If #93 is merged and v0.0.32 is tagged before #91 lands, the release ships without the services add guided kinds, --json, and the image/port validation it is meant to carry. Nothing in this CLI breaks — the bump itself is correct — but the tag would be a hollow release. Recommend gating the merge/tag of this PR on #91 landing first, as the author already flagged. Note also that #91 adds a new runtime dep (@clack/prompts) to package.json/package-lock.json; whichever of #91/#93 merges second will need a trivial rebase (the version field and the dependency block don't overlap, so no real conflict).

Information

• Software engineering — No tests accompany this PR, which is correct: there is no behavior change to cover, and the release convention is a pure metadata bump. Per SKILL.md the tag push + binary/npm publish are separate manual/CI steps after merge — out of scope for this diff.

Review dimensions

• Software engineering: Conforms to the documented release convention; no tests warranted for a metadata-only bump.
• Functionality: Bump is correct and complete; only consideration is the merge-ordering dependency on #91 above.
• Security: No security-relevant changes.
• Performance: No performance-relevant changes.

Verdict

approved (informational — a human still gives the explicit GitHub approval). No Critical findings. The one Suggestion is a release-sequencing gate the author already documented, not a defect in this diff.

[jwfing]

LGTM - approved.