chore(release): 0.1.20

[tonychang04]

Release 0.1.20. Ships #353: domain check shows the edge's reason for a stuck custom domain, a serving domain with a warning still reads serving, and the cf-custom-origin hint only appears when it applies.

🤖 Generated with Claude Code

---

Summary by cubic

Bumps the CLI to 0.1.20, which ships the domain check improvements from #353. domain check now reports the edge's reason for a stuck custom domain, a serving domain with a warning still reads as serving, and the cf-custom-origin hint only renders when it applies.

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

[jwfing]

Summary

This is a correct, internally consistent metadata-only release bump for CLI 0.1.20.

Requirements context

The review used the PR description’s stated intent to release the already-merged #353 domain-check improvements. The repository release guide specifies a version-bump PR followed by tagging, binary publication, and npm publication (.claude/skills/developing-insta-cli/SKILL.md:97-110); no separate release-note or CLI-reference change is required for this metadata-only PR.

Findings

Critical

(none)

Suggestion

(none)

Information

• Software engineering / functionality: package.json and both package-lock version fields consistently identify 0.1.20 (package.json:1-4, package-lock.json:1-10). The claimed #353 behavior is already in the base commit and has focused tests for edge reasons, active-domain warnings, legacy behavior, and conditional cf-custom-origin guidance (test/compute-domain-region.test.ts:353-422).
• Security: No runtime code, dependencies, integrity hashes, authentication, input handling, or secret-handling paths change; this PR only updates package version metadata (package-lock.json:1-16). No security-relevant concerns found.
• Performance: No executable code or dependency graph changes, so the PR introduces no additional I/O, allocations, loops, or hot-path work (package.json:1-4, package-lock.json:1-16).
• Verification: git diff --check passed, the JSON manifests parsed successfully, and their versions were programmatically confirmed equal. npm run typecheck and npm test could not execute in this checkout because tsc and vitest are not installed; the documented CI runs both checks on Linux and Windows (.claude/skills/developing-insta-cli/SKILL.md:90-95).

Verdict

Approved — no Critical findings.

[cubic-dev-ai]

No issues found across 2 files

_{Turn on auto-fix | Re-trigger cubic}

[jwfing]

Summary

A clean, internally consistent 0.1.20 version bump (package.json:3, package-lock.json:3,9) that matches this repo's established release-PR shape exactly — but the test check is red at this head, and that has to be cleared before the merge + tag that publishes to npm.

Requirements context

No docs/superpowers/ directory exists in this repo (and no docs/ at all) — no matching spec/plan found; assessed against the PR description, AGENTS.md, and .claude/skills/developing-insta-cli/SKILL.md (its "Shipping a release" section: step 1 is a bump-only PR, step 2 the vX.Y.Z tag, steps 3–4 the automatic binary + OIDC npm publish). This PR is step 1 and nothing more, which is correct.

Verified claims:

• The PR body says it ships #353. Confirmed: the base commit is c0a12f7 fix(domain check): show the edge's reason … (#353), and #353 is the only commit between the 0.1.19 release (0576fa6) and this base. The body's scope statement is accurate — nothing unannounced rides along.
• Diff shape matches precedent byte-for-byte in spirit: 0.1.19 (0576fa6) and 0.1.18 (4e31c8e) each touched exactly package.json (+1/-1) and package-lock.json (+2/-2). No changelog, release-note, or skills/insta/cli-reference.md update is owed (no command/flag surface changed).
• 0.1.19 → 0.1.20 is the right semver step for a patch-level renderer fix.
• Lockfile is genuinely in sync, not just textually edited: npm ci on this head succeeds (59 packages) — npm ci hard-fails on a package.json/lock version divergence, so this is a real check, not a visual one.
• The publish path works at this head: npm run build (= prepublishOnly) exits 0 with no tsc errors, and node dist/index.js --version prints 0.1.20 (src/version.ts:4-11 reads the shipped package.json; files: ["dist/**/*.js"] still ships the bin).
• Local full suite on this head: 101 files, 2041 passed, 1 skipped — see the Suggestion below for why CI disagrees.

Findings

Critical

(none) — nothing in this diff is wrong, and I could not attribute the red CI check to it (evidence below).

Suggestion

• Functionality / release safety — the test check is failure at head 52abf1b; re-run it and confirm green before merging and tagging. The failure is test/ssh-orchestration.test.ts > simultaneous stale-lock recovery still admits one holder > never lets two contenders break the same stale lock — AssertionError: two contenders were inside the lock at once: expected [ 'a saw d' ] to deeply equal [] (job 112601061133). I did not raise this to Critical because it is demonstrably not caused by this diff:

  • the base commit c0a12f7 — identical source, only the version strings differ — has test = success;
  • the same test failed on an unrelated PR two commits earlier (33457c7 / #351, job 112512661788, expected [ 'f saw c' ]);
  • it passes here 4/4 (full suite once + the single test three times) on a quiet machine, and test-windows is green at this head.

  The mechanism is a timing margin, not a product bug: the test's holder is alive and holds for HOLD_MS = 10 against STALE_MS = 300 (test/ssh-orchestration.test.ts:1151-1152), and isAbandoned (src/commands/compute.ts:1876-1881) permits an age-based takeover of a live holder once now - mtimeMs >= staleMs. Eight tsx child processes on a loaded 2-core runner only need one 300 ms stall inside a 10 ms section for a legitimate takeover to be recorded as an "overlap". Production callers are not exposed to this shape — the file locks pass FILE_LOCK_STALE_MS = Infinity (src/commands/compute.ts:1320) and the renewal lock 60 s (:1761). Worth a separate issue to widen the margin (raise STALE_MS, or gate the overlap assertion on observed holder wall-time) so release PRs stop inheriting a coin-flip gate — but it does need a green re-run here, since merging this PR is what unblocks the tag that publishes binaries and npm.

• Software engineering — no tests, correctly. A version bump has no behavior to test and this repo has never added one for a release PR. The meaningful guard would be a release-time assertion that package.json.version and the lockfile's two fields agree; npm ci in CI already provides it implicitly, so I would not add a test here.

Information

• Release mechanics (pre-existing, not this PR): publish-npm publishes package.json's version while the job is gated only on the ref being a tag (.github/workflows/release.yml:131-157) — nothing asserts v${package.json.version} == $GITHUB_REF_NAME. The workflow header already documents the dispatch half of this hazard; a one-line guard in the publish job would close the tag/bump-skew half too. Irrelevant as long as the tag pushed after this merge is exactly v0.1.20.
• Security: no security-relevant changes. No source, dependency, integrity-hash, auth, input-handling, or logging change — the diff is six lines of version metadata. The dependency graph is untouched (npm ci installed the same 59 packages), so no new or unpinned dependency is introduced.
• Performance: no performance-relevant changes. No executable code, no new I/O, queries, loops, or allocations; the published artifact is byte-identical to the base except the version string.
• Sibling reviews at this head: jwfing's review (COMMENTED, same commit) and cubic's both clear the diff, which I agree with. jwfing's review explicitly could not run typecheck/test locally and deferred to CI — that deferral is the one gap: CI's test job is red at that same commit. I ran both locally (green) and diagnosed the CI red above.

Verdict

approved — zero Critical findings; the diff is correct and complete for a release bump. Informational only: the GitHub green check is a separate human action. Please re-run the test job to green before merging and pushing v0.1.20.

[jwfing]

LGTM - approved.

[jwfing]

Summary

This is a correct, internally consistent release-only version bump to 0.1.20.

Requirements context

Intent was derived from the PR description, the linked #353 commit immediately preceding this release, its regression tests, and the repository’s release guide, which requires a PR updating package.json before tagging and publishing (.claude/skills/developing-insta-cli/SKILL.md:97-109). No separate release specification was found.

Findings

Critical

(none)

Suggestion

(none)

Information

• Software engineering / functionality: package.json and both root version fields in package-lock.json consistently identify 0.1.20, with no dependency or command-surface changes (package.json:1-4, package-lock.json:1-9). The behavior shipped from #353 has focused regression coverage for edge reasons, serving-with-warning behavior, and conditional cf-custom-origin guidance (test/compute-domain-region.test.ts:353-420).
• Verification: Static manifest parsing and diff checks passed. The prescribed typecheck and test suite could not execute because this checkout has no installed tsc or vitest; these are the configured project checks (package.json:31-38).
• Security: No security-relevant code, dependency, authentication, input-handling, or secret-handling changes are present (package.json:1-3, package-lock.json:1-9).
• Performance: No runtime code paths, queries, loops, allocations, or I/O behavior are changed (package.json:1-3, package-lock.json:1-9).

Verdict

Approved — no critical findings.