j4k-oss/worktree-remove
Watch
2
0
Fork
You've already forked worktree-remove
 0
Code Issues Pull requests Releases 2 Packages 1 Activity Actions

chore: remove the npm mirror leftovers after align 9.0.0 #2

Merged
jercik merged 3 commits from chore/remove-npm-mirror into main 2026-10-22 17:49:45 +00:00
Conversation 5 Commits 3 Files changed 8 +56 -834
jercik commented 2026-10-22 17:20:23 +00:00
Owner

This removes the npm-mirror leftovers after align 9.0.0: the npm-mirror job, its integrity step and the OIDC gating in release.yml (465 lines removed, 10 added), .github/workflows/release-npm.yml, and the .npm-mirror marker. release.yml still publishes @j4k-oss/worktree-remove to the Forge registry.

The README now points at the scoped Forge package. Every npm command carries --@j4k-oss:registry=https://code.j4k.dev/api/packages/j4k-oss/npm/, the ~/.npmrc line that maps the scope is shown once, and the unscoped npm package is described as frozen. I ran each documented command form against the registry with an empty npm userconfig.

align also refreshed AGENTS.md, two check-dts script comments and a comment in commit-msg.yml.

🤖 Generated with Claude Code

This removes the npm-mirror leftovers after align 9.0.0: the `npm-mirror` job, its integrity step and the OIDC gating in `release.yml` (465 lines removed, 10 added), `.github/workflows/release-npm.yml`, and the `.npm-mirror` marker. `release.yml` still publishes `@j4k-oss/worktree-remove` to the Forge registry. The README now points at the scoped Forge package. Every npm command carries `--@j4k-oss:registry=https://code.j4k.dev/api/packages/j4k-oss/npm/`, the `~/.npmrc` line that maps the scope is shown once, and the unscoped npm package is described as frozen. I ran each documented command form against the registry with an empty npm userconfig. align also refreshed `AGENTS.md`, two `check-dts` script comments and a comment in `commit-msg.yml`. 🤖 Generated with [Claude Code](https://claude.com/claude-code) 
Drops the npm-mirror job and its integrity step from the Forge release
workflow, the GitHub release-npm workflow, and the .npm-mirror marker.
Also takes the template changes align 9.0.0 renders for the workflow
comment, the check-dts scripts, and AGENTS.md.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
docs: point the README at the scoped Forge package
All checks were successful
Checks / pr-flow-canary (pull_request) Has been skipped
Details
Checks / quality-checks (26.5.0) (pull_request) Successful in 52s
Details
Checks / reuse (pull_request) Successful in 3s
Details
commit-msg / commitlint (pull_request) Successful in 12s
Details
Checks / quality-checks (24.15.0) (pull_request) Successful in 54s
Details
Review / Review (pull_request_target) Successful in 4m38s
Details
12abe6a7e5
 
The unscoped npm package is frozen. Install and run commands now use
@j4k-oss/worktree-remove with the registry flag, and the README shows the
~/.npmrc line that maps the scope.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
forgejo-actions commented 2026-10-22 17:25:01 +00:00

Review 01M5JB2SCV29H5F2ST6SDHQQJD — head d415a22220e6d3f7cda13dd39c2bef2b7b6bf1c6

Review — j4k-oss/worktree-remove @ 8ee27b6711

Scope: diff against base tree c8acf181ea8b
Status: dispatched — coverage complete (8/8 slots terminal)
Facts: current review-wide projection

Computed under:

{
  "abandonment": "abandonment-v1",
  "anchor_recipe": 1,
  "batch_policy": "batch-v1",
  "coverage": "coverage-v3",
  "dispatch_policy": "dispatch-v2",
  "grounder_version": 1,
  "grounding_read_rule": "grounding-read-v1",
  "promotion_policy": "promotion-v1",
  "report": "report-v4",
  "tally": "tally-v1",
  "triage_settle": "triage-settle-v2"
}

Findings (1)

medium — The copied agent rule promises that removal avoids permanent deletion

  • claim: 01M5JB5QJ8KFF6G1YX77DGVFXE
  • anchor: README.md (snippet)
Use `worktree-remove` when you need to safely remove Git worktrees.
It handles uncommitted changes, orphaned directories, and moves
files to trash instead of permanent deletion.
  • lens: writing-quality · arm: default
  • verdicts: 1 valid / 0 invalid / 0 uncertain
    • pass 01M5JB7Q7BH1FSWYCW59QKERV1 · valid: The exact-grounded README rule promises trash disposal instead of permanent deletion. The reviewer reports a specific static path from src/cli.ts through removeBatch to performWorktreeRemoval: trash failure for a registered worktree can continue under policy.force or confirmation, confirmAction auto-confirms with --yes, and unregisterWorktree invokes git worktree remove with a force retry when permitted. These are reviewer-supplied implementation facts, not independently grounded code, but the coherent trace establishes a reachable contradiction and a plausible reader mistake: selecting removal options on a false recoverability assumption. The overview's reported 'when possible' qualification does not travel with the copied rule. The historical adjudication contains no concrete refutation; its reservation about --yes is addressed by the current trace's account of confirmAction, and force alone sustains the defect. INT2/INT3 permit explicitly authorized destructive fallback, so the defect is the false assurance rather than the fallback or coexistence of force and confirmation. Retain medium severity. Preserve tool selection and handling of uncommitted changes and orphaned directories while qualifying trash disposal and stating that proceeding after a registered-worktree trash failure can permanently delete the directory.
  • disposition: none

An agent installing this rule can treat the tool as guaranteeing recoverable deletion and use --force --yes on that basis. The stated guarantee is false when moving a registered worktree to trash fails: Git can permanently delete the directory. The earlier README overview qualifies trashing with ‘when possible’, but that qualification is outside the rule users are told to copy.

Replace the final sentence with: ‘It handles uncommitted changes and orphaned directories. It tries to move directories to trash; if trash fails for a registered worktree, proceeding with Git removal can permanently delete it.’ This preserves the rule's purpose and adds the smallest safety qualification needed by an agent choosing removal options. The writing-for-agents standard requires a portable instruction to retain task-critical consequences; the human-facing standard likewise prohibits broadening a claim through simplification. A source pointer alone would leave the copied rule's reader unaware of this destructive fallback.

I traced src/cli.ts through removeBatch in src/cli/remove-batch.ts to performWorktreeRemoval in src/worktree/perform-worktree-removal.ts. On a failed trash operation with registeredPath, policy.force allows continuation; a single-target run can also confirm continuation. confirmAction auto-confirms under --yes. unregisterWorktree in src/git/unregister-worktree.ts calls git worktree remove and retries with --force when permitted. This is static source tracing, not an executed destructive reproduction.

The registered-worktree trash-failure branch and subsequent Git removal establish the mismatch. A guarantee that this branch cannot be reached from the CLI, or code that aborts without deleting on every trash failure, would refute it; neither is present in the traced path.

Other claims

  • grounding-pending (0)
  • ungrounded (0)
  • rejected (0)
  • duplicate-of (0)
  • unadjudicated (1)
    • 01M5JB65N1VYMVHC0DAT794YP3 medium — The repository rule independently counts repoq write commands

Coverage

Coverage pass: 01M5JB2SFH02ST1YQQ169HFJ10
Accounting: complete
Slot health: healthy

lens part arm unit status runs loss
general-bug whole default no-claims 1 no
writing-quality whole default claims-emitted 1 no
test-trimming whole default no-claims 1 no
restated-sets whole default no-claims 1 no
project-docs whole default no-claims 1 no
unix-cli whole default no-claims 1 no
use-effect whole default no-claims 1 no
react whole default no-claims 1 no
<!-- review:summary --> **Review** `01M5JB2SCV29H5F2ST6SDHQQJD` — head `d415a22220e6d3f7cda13dd39c2bef2b7b6bf1c6` # Review — j4k-oss/worktree-remove @ 8ee27b671163 Scope: diff against base tree `c8acf181ea8b` Status: dispatched — coverage complete (8/8 slots terminal) Facts: current review-wide projection Computed under: ```json { "abandonment": "abandonment-v1", "anchor_recipe": 1, "batch_policy": "batch-v1", "coverage": "coverage-v3", "dispatch_policy": "dispatch-v2", "grounder_version": 1, "grounding_read_rule": "grounding-read-v1", "promotion_policy": "promotion-v1", "report": "report-v4", "tally": "tally-v1", "triage_settle": "triage-settle-v2" } ``` ## Findings (1) ### medium — The copied agent rule promises that removal avoids permanent deletion - claim: `01M5JB5QJ8KFF6G1YX77DGVFXE` - anchor: `README.md` (snippet) ``` Use `worktree-remove` when you need to safely remove Git worktrees. It handles uncommitted changes, orphaned directories, and moves files to trash instead of permanent deletion. ``` - lens: writing-quality · arm: default - verdicts: 1 valid / 0 invalid / 0 uncertain - pass `01M5JB7Q7BH1FSWYCW59QKERV1` · valid: The exact-grounded README rule promises trash disposal instead of permanent deletion. The reviewer reports a specific static path from src/cli.ts through removeBatch to performWorktreeRemoval: trash failure for a registered worktree can continue under policy.force or confirmation, confirmAction auto-confirms with --yes, and unregisterWorktree invokes git worktree remove with a force retry when permitted. These are reviewer-supplied implementation facts, not independently grounded code, but the coherent trace establishes a reachable contradiction and a plausible reader mistake: selecting removal options on a false recoverability assumption. The overview's reported 'when possible' qualification does not travel with the copied rule. The historical adjudication contains no concrete refutation; its reservation about --yes is addressed by the current trace's account of confirmAction, and force alone sustains the defect. INT2/INT3 permit explicitly authorized destructive fallback, so the defect is the false assurance rather than the fallback or coexistence of force and confirmation. Retain medium severity. Preserve tool selection and handling of uncommitted changes and orphaned directories while qualifying trash disposal and stating that proceeding after a registered-worktree trash failure can permanently delete the directory. - disposition: none > An agent installing this rule can treat the tool as guaranteeing recoverable deletion and use `--force --yes` on that basis. The stated guarantee is false when moving a registered worktree to trash fails: Git can permanently delete the directory. The earlier README overview qualifies trashing with ‘when possible’, but that qualification is outside the rule users are told to copy. > > Replace the final sentence with: ‘It handles uncommitted changes and orphaned directories. It tries to move directories to trash; if trash fails for a registered worktree, proceeding with Git removal can permanently delete it.’ This preserves the rule's purpose and adds the smallest safety qualification needed by an agent choosing removal options. The writing-for-agents standard requires a portable instruction to retain task-critical consequences; the human-facing standard likewise prohibits broadening a claim through simplification. A source pointer alone would leave the copied rule's reader unaware of this destructive fallback. > > I traced `src/cli.ts` through `removeBatch` in `src/cli/remove-batch.ts` to `performWorktreeRemoval` in `src/worktree/perform-worktree-removal.ts`. On a failed trash operation with `registeredPath`, `policy.force` allows continuation; a single-target run can also confirm continuation. `confirmAction` auto-confirms under `--yes`. `unregisterWorktree` in `src/git/unregister-worktree.ts` calls `git worktree remove` and retries with `--force` when permitted. This is static source tracing, not an executed destructive reproduction. > > The registered-worktree trash-failure branch and subsequent Git removal establish the mismatch. A guarantee that this branch cannot be reached from the CLI, or code that aborts without deleting on every trash failure, would refute it; neither is present in the traced path. ## Other claims - grounding-pending (0) - ungrounded (0) - rejected (0) - duplicate-of (0) - unadjudicated (1) - `01M5JB65N1VYMVHC0DAT794YP3` medium — The repository rule independently counts `repoq` write commands ## Coverage Coverage pass: 01M5JB2SFH02ST1YQQ169HFJ10 Accounting: complete Slot health: healthy | lens | part | arm | unit status | runs | loss | | --- | --- | --- | --- | --- | --- | | general-bug | whole | default | no-claims | 1 | no | | writing-quality | whole | default | claims-emitted | 1 | no | | test-trimming | whole | default | no-claims | 1 | no | | restated-sets | whole | default | no-claims | 1 | no | | project-docs | whole | default | no-claims | 1 | no | | unix-cli | whole | default | no-claims | 1 | no | | use-effect | whole | default | no-claims | 1 | no | | react | whole | default | no-claims | 1 | no |
🚀 1
forgejo-actions reviewed 2026-10-22 17:25:01 +00:00
README.md
Lines 137-138
@ -164,4 +167,4 @@
Run `npx -y worktree-remove --help` to learn available options.
Run `npx -y --@j4k-oss:registry=https://code.j4k.dev/api/packages/j4k-oss/npm/ @j4k-oss/worktree-remove@latest --help` to learn available options. Keep the `--@j4k-oss:registry` flag: without it `npx` can fetch another owner's `@j4k-oss` package from npmjs.org.
Use `worktree-remove` when you need to safely remove Git worktrees.
It handles uncommitted changes, orphaned directories, and moves
forgejo-actions commented 2026-10-22 17:25:01 +00:00

medium — The copyable agent rule promises that removal never permanently deletes files

An agent copying this rule is told that removal moves files to trash instead of permanently deleting them. It can therefore choose the command under a false recoverability assumption, particularly with --yes or --force. The README’s earlier overview correctly qualifies trash use with “when possible,” but that caveat is absent from the standalone rule intended for another repository’s instructions.

In performWorktreeRemoval in src/worktree/perform-worktree-removal.ts, a failed trash move on a registered worktree can continue to unregisterWorktree with force enabled. The prompt explicitly warns “Git may permanently delete it”; policy.force bypasses that prompt. This directly contradicts the unconditional sentence in the copyable rule.

Replace the last two sentences with “It checks uncommitted changes and handles orphaned directories. It attempts to move directories to trash; if that fails, proceeding with Git removal can permanently delete them.” This preserves the rule’s tool-selection purpose and states the consequence where its agent reader needs it, following writing-for-agents’ requirement to preserve task-critical caveats and human-facing-writing-style’s instruction not to widen a claim through simplification.

I read the README overview and Agent Rule, src/cli/remove-batch.ts, src/worktree/perform-worktree-removal.ts, and src/fs/trash-directory.ts. This is a static trace, not a runtime reproduction. The decisive evidence is the registered-worktree trash-failure branch and its explicit permanent-deletion warning; an unconditional abort on every trash failure would refute the claim, but that is not the implementation shown.

lens writing-quality · arm default · tally 1 valid / 0 invalid / 0 uncertain
claim 01M5JA4WZ2ZWDCSH1PQ3SA8R2G of review 01M5JA1S1V0XMFM7X7EYXBQN2X

<!-- review:claim:01M5JA4WZ2ZWDCSH1PQ3SA8R2G --> **medium** — The copyable agent rule promises that removal never permanently deletes files > An agent copying this rule is told that removal moves files to trash instead of permanently deleting them. It can therefore choose the command under a false recoverability assumption, particularly with --yes or --force. The README’s earlier overview correctly qualifies trash use with “when possible,” but that caveat is absent from the standalone rule intended for another repository’s instructions. > > In performWorktreeRemoval in src/worktree/perform-worktree-removal.ts, a failed trash move on a registered worktree can continue to unregisterWorktree with force enabled. The prompt explicitly warns “Git may permanently delete it”; policy.force bypasses that prompt. This directly contradicts the unconditional sentence in the copyable rule. > > Replace the last two sentences with “It checks uncommitted changes and handles orphaned directories. It attempts to move directories to trash; if that fails, proceeding with Git removal can permanently delete them.” This preserves the rule’s tool-selection purpose and states the consequence where its agent reader needs it, following writing-for-agents’ requirement to preserve task-critical caveats and human-facing-writing-style’s instruction not to widen a claim through simplification. > > I read the README overview and Agent Rule, src/cli/remove-batch.ts, src/worktree/perform-worktree-removal.ts, and src/fs/trash-directory.ts. This is a static trace, not a runtime reproduction. The decisive evidence is the registered-worktree trash-failure branch and its explicit permanent-deletion warning; an unconditional abort on every trash failure would refute the claim, but that is not the implementation shown. lens `writing-quality` · arm `default` · tally 1 valid / 0 invalid / 0 uncertain claim `01M5JA4WZ2ZWDCSH1PQ3SA8R2G` of review `01M5JA1S1V0XMFM7X7EYXBQN2X`
🚀 1
jercik marked this conversation as resolved
jercik commented 2026-10-22 17:28:21 +00:00
Author
Owner

Replying to review comment #177964

Valid, and it predates this PR: the sentence about trash is unchanged here, so the fix is tracked in #3. That PR rewrites the end of the Agent Rule to say that when the trash move fails, --force (or --yes for a single worktree) lets Git delete a registered worktree permanently.

> Replying to review comment #177964 Valid, and it predates this PR: the sentence about trash is unchanged here, so the fix is tracked in https://code.j4k.dev/j4k-oss/worktree-remove/pulls/3. That PR rewrites the end of the Agent Rule to say that when the trash move fails, `--force` (or `--yes` for a single worktree) lets Git delete a registered worktree permanently.
docs: tell existing global installs to uninstall first and keep the registry line
All checks were successful
Checks / reuse (pull_request) Successful in 4s
Details
Review / Review (pull_request_target) Successful in 4m38s
Details
Checks / pr-flow-canary (pull_request) Has been skipped
Details
commit-msg / commitlint (pull_request) Successful in 10s
Details
Checks / quality-checks (24.15.0) (pull_request) Successful in 36s
Details
Checks / quality-checks (26.5.0) (pull_request) Successful in 39s
Details
d415a22220
 
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
forgejo-actions reviewed 2026-10-22 17:43:03 +00:00
README.md
Lines 137-138
@ -164,4 +169,4 @@
Run `npx -y worktree-remove --help` to learn available options.
Run `npx -y --@j4k-oss:registry=https://code.j4k.dev/api/packages/j4k-oss/npm/ @j4k-oss/worktree-remove@latest --help` to learn available options. Keep the `--@j4k-oss:registry` flag: without it `npx` can fetch another owner's `@j4k-oss` package from npmjs.org.
Use `worktree-remove` when you need to safely remove Git worktrees.
It handles uncommitted changes, orphaned directories, and moves
forgejo-actions commented 2026-10-22 17:43:03 +00:00

medium — The copied agent rule promises that removal avoids permanent deletion

An agent installing this rule can treat the tool as guaranteeing recoverable deletion and use --force --yes on that basis. The stated guarantee is false when moving a registered worktree to trash fails: Git can permanently delete the directory. The earlier README overview qualifies trashing with ‘when possible’, but that qualification is outside the rule users are told to copy.

Replace the final sentence with: ‘It handles uncommitted changes and orphaned directories. It tries to move directories to trash; if trash fails for a registered worktree, proceeding with Git removal can permanently delete it.’ This preserves the rule's purpose and adds the smallest safety qualification needed by an agent choosing removal options. The writing-for-agents standard requires a portable instruction to retain task-critical consequences; the human-facing standard likewise prohibits broadening a claim through simplification. A source pointer alone would leave the copied rule's reader unaware of this destructive fallback.

I traced src/cli.ts through removeBatch in src/cli/remove-batch.ts to performWorktreeRemoval in src/worktree/perform-worktree-removal.ts. On a failed trash operation with registeredPath, policy.force allows continuation; a single-target run can also confirm continuation. confirmAction auto-confirms under --yes. unregisterWorktree in src/git/unregister-worktree.ts calls git worktree remove and retries with --force when permitted. This is static source tracing, not an executed destructive reproduction.

The registered-worktree trash-failure branch and subsequent Git removal establish the mismatch. A guarantee that this branch cannot be reached from the CLI, or code that aborts without deleting on every trash failure, would refute it; neither is present in the traced path.

lens writing-quality · arm default · tally 1 valid / 0 invalid / 0 uncertain
claim 01M5JB5QJ8KFF6G1YX77DGVFXE of review 01M5JB2SCV29H5F2ST6SDHQQJD

<!-- review:claim:01M5JB5QJ8KFF6G1YX77DGVFXE --> **medium** — The copied agent rule promises that removal avoids permanent deletion > An agent installing this rule can treat the tool as guaranteeing recoverable deletion and use `--force --yes` on that basis. The stated guarantee is false when moving a registered worktree to trash fails: Git can permanently delete the directory. The earlier README overview qualifies trashing with ‘when possible’, but that qualification is outside the rule users are told to copy. > > Replace the final sentence with: ‘It handles uncommitted changes and orphaned directories. It tries to move directories to trash; if trash fails for a registered worktree, proceeding with Git removal can permanently delete it.’ This preserves the rule's purpose and adds the smallest safety qualification needed by an agent choosing removal options. The writing-for-agents standard requires a portable instruction to retain task-critical consequences; the human-facing standard likewise prohibits broadening a claim through simplification. A source pointer alone would leave the copied rule's reader unaware of this destructive fallback. > > I traced `src/cli.ts` through `removeBatch` in `src/cli/remove-batch.ts` to `performWorktreeRemoval` in `src/worktree/perform-worktree-removal.ts`. On a failed trash operation with `registeredPath`, `policy.force` allows continuation; a single-target run can also confirm continuation. `confirmAction` auto-confirms under `--yes`. `unregisterWorktree` in `src/git/unregister-worktree.ts` calls `git worktree remove` and retries with `--force` when permitted. This is static source tracing, not an executed destructive reproduction. > > The registered-worktree trash-failure branch and subsequent Git removal establish the mismatch. A guarantee that this branch cannot be reached from the CLI, or code that aborts without deleting on every trash failure, would refute it; neither is present in the traced path. lens `writing-quality` · arm `default` · tally 1 valid / 0 invalid / 0 uncertain claim `01M5JB5QJ8KFF6G1YX77DGVFXE` of review `01M5JB2SCV29H5F2ST6SDHQQJD`
👍 1
jercik commented 2026-10-22 17:48:12 +00:00
Author
Owner

Already fixed in b9d4ad8, the squash commit of #3 on main.

<!-- gh-feedback:reply-to:178060 --> Already fixed in b9d4ad8, the squash commit of https://code.j4k.dev/j4k-oss/worktree-remove/pulls/3 on main.
jercik marked this conversation as resolved
jercik commented 2026-10-22 17:48:03 +00:00
Author
Owner

Replying to review 01M5JB2SCV29H5F2ST6SDHQQJD (summary #177963, head d415a222)

  • Agent rule overpromising trash (claim 01M5JB5QJ8KFF6G1YX77DGVFXE, inline #178060): valid, predates this PR, and is already fixed on main in b9d4ad8 (#3). This review ran on a head that does not contain that commit.
  • Unadjudicated claim 01M5JB65N1VYMVHC0DAT794YP3 (the repoq guidance counts write commands): not a defect in this PR. The sentence "It also carries one write verb: pr create" is in the generated AGENTS.md/CLAUDE.md, which align regenerated here from the shared rule repoq/repoq-usage.md; generated files are not edited by hand. The count is accurate today: repoq registers pr create as its only write command (src/cli/register-pr-command.ts). If repoq gains another write verb, the shared rule in the align repository needs the update, which is outside these PRs.
> Replying to review `01M5JB2SCV29H5F2ST6SDHQQJD` (summary #177963, head d415a222) - Agent rule overpromising trash (claim `01M5JB5QJ8KFF6G1YX77DGVFXE`, inline #178060): valid, predates this PR, and is already fixed on `main` in b9d4ad8 (https://code.j4k.dev/j4k-oss/worktree-remove/pulls/3). This review ran on a head that does not contain that commit. - Unadjudicated claim `01M5JB65N1VYMVHC0DAT794YP3` (the repoq guidance counts write commands): not a defect in this PR. The sentence "It also carries one write verb: `pr create`" is in the generated `AGENTS.md`/`CLAUDE.md`, which align regenerated here from the shared rule `repoq/repoq-usage.md`; generated files are not edited by hand. The count is accurate today: repoq registers `pr create` as its only write command (`src/cli/register-pr-command.ts`). If repoq gains another write verb, the shared rule in the align repository needs the update, which is outside these PRs.
jercik merged commit d58cb0438f into main 2026-10-22 17:49:45 +00:00
jercik deleted branch chore/remove-npm-mirror 2026-10-22 17:49:46 +00:00
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Assignees
Clear assignees
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
j4k-oss/worktree-remove!2
No description provided.