chore: bump version to 0.2.2

[CarmenDou]

Bumps @insforge/cli from 0.2.1 to 0.2.2.

0.2.1 is already released (git tag, GitHub Release, and on npm), and 23 non-merge commits have landed on main since — most notably self-hosted Apify connect (#217), several deploy-polling fixes around transient 5xx/429/408, the legacy OSS sentinel project/org ID heal, and redacting the privileged api_key from current --json.

Also syncs package-lock.json, which was still reporting 0.2.0 — earlier bump commits touched only package.json, so the lock had drifted a version behind. Regenerated with npm install --package-lock-only; the diff is the two version fields and nothing else, no dependency churn.

Verified: npm ci installs from the updated lock, npm run build succeeds, npm test passes 677/13 skipped, and the built dist/index.js reports 0.2.2.

Note this only prepares the version — per 67a6478, publishing triggers on creating a GitHub Release, not on a tag push.

---

Summary by cubic

Update @insforge/cli to 0.2.2 and align package-lock.json (was 0.2.0) with package.json. No dependency changes; publishing happens when a GitHub Release is created.

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

Note

Bump version to 0.2.2

Updates the version field in package.json from 0.2.1 to 0.2.2 and regenerates the lockfile.

^{Macroscope summarized dc01d8b.}

[coderabbitai]

Warning

Review limit reached

@CarmenDou, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 24 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 35023e98-765e-4c05-893c-1770afee9c14

📥 Commits

Reviewing files that changed from the base of the PR and between 245197d and dc01d8b.

⛔ Files ignored due to path filters (1)

• package-lock.json is excluded by !**/package-lock.json

📒 Files selected for processing (1)

• package.json

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[greptile-apps]

Greptile Summary

Aligns the CLI package version metadata at 0.2.2.

• Updates package.json from version 0.2.1 to 0.2.2.
• Synchronizes both root-package version fields in package-lock.json from 0.2.0 to 0.2.2.

Confidence Score: 5/5

The PR appears safe to merge because it consistently updates package version metadata without changing dependencies or runtime behavior.

The package manifest and lockfile now consistently identify the root package as version 0.2.2, and the diff introduces no executable-code or dependency changes.

Important Files Changed

Filename	Overview
package.json	Bumps the published package version from 0.2.1 to 0.2.2 without changing runtime configuration or dependencies.
package-lock.json	Synchronizes the lockfile’s two root-package version fields with package.json without dependency churn.

_{Reviews (1): Last reviewed commit: "chore: bump version to 0.2.2" | Re-trigger Greptile}

[jwfing]

Review: chore: bump version to 0.2.2

Summary: A clean, minimal version bump — package.json 0.2.1 → 0.2.2 and package-lock.json re-synced from a drifted 0.2.0 → 0.2.2, with no dependency changes.

Requirements context

No matching spec/plan — this repo keeps design docs under docs/specs/ (diagnose command, db-migrations), none of which cover release/version chores. Assessed against the PR description alone, which is accurate and well-documented.

Findings

Critical — (none)

Suggestion — (none)

Information

Software engineering

• Diff scope is exactly what's claimed: package.json:3 (1 line) and package-lock.json:3,9 (the top-level and root-package version fields only). git diff --stat against base confirms 2 files / 3 insertions / 3 deletions with zero dependency churn.
• No tests are warranted or missing here — there is no behavior change. The CLI derives its version dynamically at runtime from package.json (src/index.ts:97 → .version(pkg.version) at src/index.ts:114, and the intro banner at src/index.ts:337), so no hardcoded version constant needs updating. A repo-wide grep for 0.2.0/0.2.1 in src/ returns no matches, confirming nothing else is out of sync.

Functionality

• The bump is correct and the lockfile realignment is meaningfully load-bearing, not cosmetic: .github/workflows/publish.yml triggers on release: published and runs npm ci, which requires package-lock.json to be in sync with package.json. Leaving the lock drifted at 0.2.0 risked a publish-time npm ci failure. The PR body's note that publishing triggers on GitHub Release creation (not tag push) matches publish.yml.

Security

• No security-relevant changes: no new/updated dependencies, no source changes, no secrets or credentials touched.

Performance

• No performance-relevant changes.

Verdict

approved (informational — no Critical findings). Straightforward release-prep chore; verified accurate and in-scope. Human approval still required via the normal GitHub approve flow.

[jwfing]

LGTM - approved.

[cubic-dev-ai]

No issues found across 2 files

_{Re-trigger cubic}