Repository navigation
feat(cli): releases pin their own version, and init names stale CI pins - #509
Conversation
A released build now bakes npx @taskless/cli@<version> into the skill, recipes, and printed commands, as a nightly already did, so an agent runs the version the project installed and a permission rule can name it. The released-build check reads a build-target define instead of comparing the invocation to an unpinned string. Stub recovery lines and the README stay unpinned so they do not churn per release. Pinning means the ci and hooks recipes now write a pinned invocation, so init's stale-pin notice also reads the CI and hook files detect knows, by file and line. Includes the pinned-cli-permissions OpenSpec proposal.
…pins in the info schema
|
@claude /review |
|
Claude finished @theCodeDrift's task in 2m 43s —— View job Review completeReview mode: incremental — read 0 prior review thread(s) before reviewing.
AssessmentThis is a clean, well-scoped change. Spot checks against the proposal/design/spec docs all line up with the implementation:
Two minor, non-blocking nits, neither worth gating on:
No correctness, security, or test-adequacy issues found in the diff. Typecheck/lint/test results are reported by CI directly; not re-run here. |
…stop calling @latest the baked specifier A CI, hook, or script pin is a launcher line with nothing to reinstall, so the stale-pin notice and the init recipe now ask for a dependency reinstall only when a package.json dependency pin is among the stale ones. The package-manager docblock now gives a pinned release as the baked specifier example.
Both nits fixed in 2fac42e. — AI Coding Agent |
Stack (root → tip):
Bottom of a two-PR stack that merges forward, delivering the
pinned-cli-permissionsOpenSpec change. This PR carries the proposal, the release pinning, and stale CI pin detection. The next PR writes harness permission rules and archives the change.Releases pin their own version
prodbuild bakesnpx @taskless/cli@<version>into the installed skill, recipes, and printed commands, the same way a nightly already bakesnpx @taskless/cli-nightly@<version>. An agent runs exactly the version the project installed, and a permission rule has a version to name.isProductionInvocation()now reads a new__TASKLESS_BUILD_TARGET__define. Comparing the invocation to the unpinned string would report every release as unreleased now.assertVersionConsistencychecks prod as well as nightly, so a release whose invocation disagrees with__VERSION__fails the build.package.json, so the baked version is the one being published.npx @taskless/cli init. The standingcli-initrequirement forbids stub content that changes per release..taskless/README.mdkeeps@taskless/cli@latestfor a release. A migration writes it once and upgrades don't rewrite it, so a pinned version there would go stale.initnames stale CI and hook pinsciandhooksrecipes write a pinned invocation, and the next upgrade leaves it behind.detectrecognizes, as text, using the same pattern it applies topackage.jsonscripts. Results are reported by file and line through the same notice andpinnedCliJSON field.Verified against the real build in a scratch repo:
npx @taskless/cli@0.12.0in all 26 places.npx @taskless/cli@0.11.0in a workflow is reported as.github/workflows/t.yml line 1.Typecheck, lint, and all 2305 CLI tests pass.