fix(init): keep release and nightly permissions independent

[theCodeDrift]

Testing a nightly next to the release was awkward because each build undid the other's permissions.

Project allow rules. syncPermissions() treated every Taskless rule that was not the running build's as stale, regardless of package. A nightly init removed the release's Bash(npx @taskless/cli@… *) rule; the release removed the nightly's. Removal is now scoped to the installing package (@taskless/cli or @taskless/cli-nightly). The manifest record keeps the other package's rules, so a file Taskless created is still deleted once the last package's rules leave it. A self build, whose invocation names neither package, removes no package rules.

Global autoMode.allow entry. Both builds found their entry by the one Taskless CLI: label and treated any other labelled text as stale. The text is identical in 0.13.1 and main today, but the next rewording would have had each build offering to replace the other's entry on every run. Each package now has its own entry: the release keeps Taskless CLI: and names only @taskless/cli; a nightly uses Taskless CLI nightly: and names only @taskless/cli-nightly. A build only reads, offers, replaces, and warns about its own. The installed skill renders the installing build's entry and label from placeholders.

One-time effect: on the first release carrying this, an existing Taskless CLI: entry that names both packages reads as stale, and the wizard offers a single REPLACE (global):.

OpenSpec change independent-nightly-permissions modifies cli-init, agent-global-trust, and skill-taskless, and is archived here. The pre-archive scenario check lost nothing and added five scenarios.

Tests: side-by-side release and nightly installs, a nightly upgrade swapping only its own rule, record carry-over and created-file deletion, a self invocation, both global entries leaving each other alone, and a nightly-project test for the nightly's entry and installed skill.

[theCodeDrift]

@claude /review

[github-actions]

Claude finished @theCodeDrift's task in 5m 40s —— View job

---

Review complete

Review mode: incremental — read 0 prior review thread(s) before reviewing. This PR has no prior reviews, review threads, or top-level comments, so this is the first full review; there is nothing previously-raised to carry forward.

Todo list

• Read .prior-review.json (0 threads/reviews/comments found)
• Fetch PR diff via gh pr diff
• Read changed source files in full context (global-trust.ts, permissions.ts, canonical.ts, init.md)
• Read changed spec files and changeset
• Read changed test files
• Trace the package-scoping logic (isOwn/isOther/tasklessPackage) against the test scenarios by hand
• Post final top-level summary

Assessment

I traced syncPermissions()'s new package-scoping logic (tasklessPackage, isOwn, isOther in packages/cli/src/install/permissions.ts) by hand against each new test scenario — side-by-side install, nightly-only upgrade, record carry-over/created-file deletion, the unrecorded-other-package-rule case, and the self-invocation case — and it checks out in every case I traced, including the subtle one: a self build now correctly removes no package rules (previously, before this fix, a self build's invocation never matched any existing npx-based rule as "wanted," so the old code would have stripped the release's/nightly's rule out from under it — this PR's own === undefined → isOwn always false fixes exactly that). I also checked global-trust.ts's per-build label/entry selection (isProductionInvocation() ? RELEASE_TRUST : NIGHTLY_TRUST), the placeholder rendering in canonical.ts/SKILL.md, and that buildInvocation() (used for permission-rule scoping) and isProductionInvocation() (used for trust-entry selection) are consistently derived from the same build-time identity, so the two mechanisms can't disagree about which package a given build is.

I also checked the OpenSpec archiving: the ## MODIFIED Requirements blocks in openspec/changes/archive/2026-10-17-independent-nightly-permissions/specs/*/spec.md fully restate every prior scenario (per the repo's "a spec delta replaces a requirement" rule), and diffing them against the updated openspec/specs/*/spec.md files confirms all pre-existing scenarios survive and exactly 5 new ones were added, matching the PR description's claim.

No concrete bugs found. One minor, non-blocking observation:

• Test coverage: The new "release and nightly side by side" tests in packages/cli/test/permissions.test.ts only exercise the Claude Code harness (.claude/settings.json). The package-scoping logic (isOwn/isOther) lives in the harness-agnostic syncPermissions(), and I traced through the Cursor CLI, OpenCode, and Codex harnesses' found()/edit() implementations by hand and they appear to compose correctly with the new scoping (e.g. Codex's full-file rewrite only drops rules named in remove, which is already own-package-filtered). This is very likely fine given the shared code path, but there's no test pinning that behavior for those three harnesses specifically — worth a follow-up if you want belt-and-suspenders coverage, not a blocker for this PR.

Everything else — the changeset bump (patch, correctly justified by the repo's 0.y.z-is-still-patch rule even though the spec change is marked BREAKING), the one-time migration behavior for an existing dual-package Taskless CLI: entry, and the skill placeholder rendering — looks correct and well-tested.

[theCodeDrift]

Re: @github-actions — "Claude finished @theCodeDrift's task in 5m 40s …"
#530 (comment)

Addressed the test-coverage note in bf2b8ab: the side-by-side case now runs for Cursor (editor and CLI), OpenCode in both object and array form, and Codex, each asserting the release rule and the newest nightly rule survive and repeat runs are no-ops. Verified the four new cases fail with the package scoping removed.

— AI Coding Agent