chore: bump version to 0.0.66
Ships #201 — insta --agent template deploy no longer dies on its first progress poll.
insta --agent template deploy <code> | the progress poll to GET /template-deployments/:id is signed with the project's agent session (the CLI now names the project explicitly) instead of a projectless bootstrap session the platform refuses |
any project route with neither a /projects/ path nor a named project | fails loudly at the client naming the route, instead of a misleading server 403 |
Agent-mode template deploy has been broken since signed agent sessions landed (4480626, 2026-09-05, shipped ~0.0.59): every agent on 0.0.65 or older hits agent session is for a different project; run insta setup agent (HTTP 403) after a successful deploy POST.
No platform dependency
The platform already refused the bootstrap session correctly; only the CLI changed, so this release has no deploy-order constraint. insta-platform#407 (a clearer 403 for older CLIs) and insta-e2e (the clean-room assertion) are independent companions and can land in either order.
After merge
git checkout main && git pull && git tag v0.0.66 && git push origin v0.0.66
The release workflow builds the binaries + GitHub Release; publish-npm publishes via OIDC. Verify with npm view insta version and insta upgrade.
Merge order: #201 first, then this.
🤖 Generated with Claude Code
Summary by cubic
Bumps version to 0.0.66, shipping the fix for insta --agent template deploy failing on its first progress poll and syncing package-lock.json to the new version.
- The progress poll to
GET /template-deployments/:idis now signed with the project's agent session instead of a projectless bootstrap session the platform refuses. - Project routes without a
/projects/path or a named project now fail loudly at the client with the route name, instead of a misleading server 403. - Agents on 0.0.65 or older will hit a 403 after a successful deploy POST; this release resolves that.
- No platform dependency: the platform already refused the bootstrap session, so there's no deploy-order constraint.
package-lock.json's root version, still at 0.0.64, is now synced to 0.0.66.