j4k-oss/conventional-commit-msg
Watch
2
0
Fork
You've already forked conventional-commit-msg
 0
Code Issues Pull requests Releases 3 Packages 1 Activity Actions

chore: sync alignment guidance and managed automation #5

Merged
jercik merged 2 commits from chore/align-local-command into main 2026-10-24 06:36:10 +00:00
Conversation 2 Commits 2 Files changed 4 +82 -22
jercik commented 2026-10-23 18:46:01 +00:00
Owner

Regenerates alignment guidance and managed automation for the local-command migration in Align #809. The review wrapper retains the existing zero-failed-unit requirement, and commit checks retain staged-file isolation.

Do not merge until Align 13 is published and verified. The generated command guidance uses its new CLI.

Regenerates alignment guidance and managed automation for the local-command migration in [Align #809](https://code.j4k.dev/j4k/align/pulls/809). The review wrapper retains the existing zero-failed-unit requirement, and commit checks retain staged-file isolation. Do not merge until Align 13 is published and verified. The generated command guidance uses its new CLI.
chore: preserve zero-failure review requirement
All checks were successful
Checks / pr-flow-canary (pull_request) Has been skipped
Details
Checks / reuse (pull_request) Successful in 5s
Details
commit-msg / commitlint (pull_request) Successful in 12s
Details
Checks / quality-checks (26.5.0) (pull_request) Successful in 44s
Details
Checks / quality-checks (24.15.0) (pull_request) Successful in 44s
Details
Review / Review (pull_request_target) Successful in 4m49s
Details
62812d9e66
forgejo-actions commented 2026-10-23 18:50:49 +00:00

Review 01M5N1B8DXB4TH1MFS79FZZJT7 — head 62812d9e661286a75df92f48c9e80b96d8b3827e

Review — j4k-oss/conventional-commit-msg @ b88595f3fa

Scope: diff against base tree b28bbaa36eaf
Review finished: 10 succeeded, 0 failed
Triage: settled
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-v5",
  "tally": "tally-v1",
  "triage_settle": "triage-settle-v2"
}

Findings (1)

medium — Snapshot cleanup leaves an active checkout running after the hook is killed

  • claim: 01M5N1G1K55SDYQ3T6QB0D32SZ
  • anchor: .githooks/commit-msg (snippet)
git --git-dir="$git_common_dir" -c worktree.useRelativePaths=false -c core.hooksPath=/dev/null worktree add --quiet --detach "$snapshot_dir" "$snapshot_commit" 6>&-
  • lens: unix-cli · arm: default
  • verdicts: 1 valid / 0 invalid / 0 uncertain
    • pass 01M5N1J21H67Z8QFQFWY3ETT8Q · valid: The exact-grounded invocation closes fd 6. The reviewer supplies a coherent trace through run_step, tell_watcher, watch_snapshot and remove_snapshot_files: creation is not registered, so hook-only SIGKILL produces EOF with no process group to stop before deletion. The reported Linux/Bash/Git probe establishes a surviving blocked filter and subsequent checkout errors against the removed directory; it is reported evidence, not a reproduction performed by triage. ERR4 applies to the watcher’s described cleanup obligation and surviving owned work. SIGKILL being uncatchable in the hook does not refute a defect in its surviving supervisor, and whole-group cancellation would bypass this case. Medium severity is supported. Track creation and ensure it has stopped before deleting its resources, while preserving fd closure against filter-daemon inheritance.
  • duplicates: 01M5N1HAZCXKGJJ35CC65MJFBP (aposd-plain)
  • disposition: none

If the hook receives SIGKILL while checkout is running a slow or blocked smudge filter, its Git child and the filter survive cancellation. The watcher deletes their worktree while they are still using it; a blocked filter can remain running indefinitely, and a resumed checkout attempts to write into the deleted directory. This violates the cancellation and cleanup obligation covered by ERR4.

The new watcher explicitly handles the hook dying by SIGKILL. This worktree-add invocation closes fd 6, so killing the hook immediately gives the watcher EOF even though checkout is still active. However, only run_step reports a process group through tell_watcher. During worktree add, watch_snapshot therefore has an empty process_group and calls remove_snapshot_files without stopping Git or its filter.

Run checkout in a separately tracked process group and report it to the watcher before relying on EOF to trigger cleanup, so cleanup stops the active checkout and its children before removing their files. Preserve the fd closure needed to avoid detached filter daemons retaining the pipe.

I traced run_step, watch_snapshot, remove_snapshot_files and the package.json prepare hook that enables this Git hook. On Linux with Bash 5.2 and Git 2.47, I ran node /tmp/review-hook-probe.mjs checkout-kill: the harness copied the unchanged subject hook and check-msg.sh into a temporary Git repository, staged package.json, pnpm-lock.yaml and a file with a blocking smudge filter, supplied a pnpm stub, invoked bash hook <message-file>, waited for the filter to start, then sent SIGKILL only to the hook PID. The snapshot disappeared, but a signal-zero probe confirmed the filter was alive. Releasing the filter let it finish, after which Git emitted errors including unable to create file a.txt: No such file or directory. The same harness without cancellation completed successfully and removed the snapshot. Real dependency installation was not exercised.

The decisive check is cancellation of the hook PID during an active checkout: both Git and its filter must stop before the watcher removes the snapshot. Cancellation of the entire process group does not exercise this case because that independently kills the checkout.

Other claims

  • grounding-pending (0)
  • ungrounded (0)
  • rejected (0)
  • duplicate-of (1)
    • 01M5N1HAZCXKGJJ35CC65MJFBP medium — Snapshot cleanup does not control the process that creates the worktree → 01M5N1G1K55SDYQ3T6QB0D32SZ
  • unadjudicated (0)

Coverage

Coverage pass: 01M5N1BM4CMVF8VHXX5JQ2VACX
Accounting: complete (all slots terminal; see slot results for failures)
Slot health: healthy

lens part arm unit status runs loss
general-bug whole default no-claims 1 no
writing-quality whole default no-claims 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 claims-emitted 1 no
use-effect whole default no-claims 1 no
module-design whole default no-claims 1 no
aposd-plain whole default claims-emitted 1 no
react whole default no-claims 1 no
<!-- review:summary --> **Review** `01M5N1B8DXB4TH1MFS79FZZJT7` — head `62812d9e661286a75df92f48c9e80b96d8b3827e` # Review — j4k-oss/conventional-commit-msg @ b88595f3fa56 Scope: diff against base tree `b28bbaa36eaf` Review finished: 10 succeeded, 0 failed Triage: settled 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-v5", "tally": "tally-v1", "triage_settle": "triage-settle-v2" } ``` ## Findings (1) ### medium — Snapshot cleanup leaves an active checkout running after the hook is killed - claim: `01M5N1G1K55SDYQ3T6QB0D32SZ` - anchor: `.githooks/commit-msg` (snippet) ``` git --git-dir="$git_common_dir" -c worktree.useRelativePaths=false -c core.hooksPath=/dev/null worktree add --quiet --detach "$snapshot_dir" "$snapshot_commit" 6>&- ``` - lens: unix-cli · arm: default - verdicts: 1 valid / 0 invalid / 0 uncertain - pass `01M5N1J21H67Z8QFQFWY3ETT8Q` · valid: The exact-grounded invocation closes fd 6. The reviewer supplies a coherent trace through run_step, tell_watcher, watch_snapshot and remove_snapshot_files: creation is not registered, so hook-only SIGKILL produces EOF with no process group to stop before deletion. The reported Linux/Bash/Git probe establishes a surviving blocked filter and subsequent checkout errors against the removed directory; it is reported evidence, not a reproduction performed by triage. ERR4 applies to the watcher’s described cleanup obligation and surviving owned work. SIGKILL being uncatchable in the hook does not refute a defect in its surviving supervisor, and whole-group cancellation would bypass this case. Medium severity is supported. Track creation and ensure it has stopped before deleting its resources, while preserving fd closure against filter-daemon inheritance. - duplicates: `01M5N1HAZCXKGJJ35CC65MJFBP` (aposd-plain) - disposition: none > If the hook receives SIGKILL while checkout is running a slow or blocked smudge filter, its Git child and the filter survive cancellation. The watcher deletes their worktree while they are still using it; a blocked filter can remain running indefinitely, and a resumed checkout attempts to write into the deleted directory. This violates the cancellation and cleanup obligation covered by ERR4. > > The new watcher explicitly handles the hook dying by SIGKILL. This worktree-add invocation closes fd 6, so killing the hook immediately gives the watcher EOF even though checkout is still active. However, only run_step reports a process group through tell_watcher. During worktree add, watch_snapshot therefore has an empty process_group and calls remove_snapshot_files without stopping Git or its filter. > > Run checkout in a separately tracked process group and report it to the watcher before relying on EOF to trigger cleanup, so cleanup stops the active checkout and its children before removing their files. Preserve the fd closure needed to avoid detached filter daemons retaining the pipe. > > I traced run_step, watch_snapshot, remove_snapshot_files and the package.json prepare hook that enables this Git hook. On Linux with Bash 5.2 and Git 2.47, I ran `node /tmp/review-hook-probe.mjs checkout-kill`: the harness copied the unchanged subject hook and check-msg.sh into a temporary Git repository, staged package.json, pnpm-lock.yaml and a file with a blocking smudge filter, supplied a pnpm stub, invoked <code>bash hook &lt;message-file&gt;</code>, waited for the filter to start, then sent SIGKILL only to the hook PID. The snapshot disappeared, but a signal-zero probe confirmed the filter was alive. Releasing the filter let it finish, after which Git emitted errors including `unable to create file a.txt: No such file or directory`. The same harness without cancellation completed successfully and removed the snapshot. Real dependency installation was not exercised. > > The decisive check is cancellation of the hook PID during an active checkout: both Git and its filter must stop before the watcher removes the snapshot. Cancellation of the entire process group does not exercise this case because that independently kills the checkout. ## Other claims - grounding-pending (0) - ungrounded (0) - rejected (0) - duplicate-of (1) - `01M5N1HAZCXKGJJ35CC65MJFBP` medium — Snapshot cleanup does not control the process that creates the worktree → `01M5N1G1K55SDYQ3T6QB0D32SZ` - unadjudicated (0) ## Coverage Coverage pass: 01M5N1BM4CMVF8VHXX5JQ2VACX Accounting: complete (all slots terminal; see slot results for failures) Slot health: healthy | lens | part | arm | unit status | runs | loss | | --- | --- | --- | --- | --- | --- | | general-bug | whole | default | no-claims | 1 | no | | writing-quality | whole | default | no-claims | 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 | claims-emitted | 1 | no | | use-effect | whole | default | no-claims | 1 | no | | module-design | whole | default | no-claims | 1 | no | | aposd-plain | whole | default | claims-emitted | 1 | no | | react | whole | default | no-claims | 1 | no |
🚀 1
forgejo-actions reviewed 2026-10-23 18:50:50 +00:00
.githooks/commit-msg
@ -146,2 +205,3 @@
exec 6> >(set -m; watch_snapshot <&0 > /dev/null &)
# Relative worktree paths would upgrade the repository format; post-checkout hooks must not run here.
git --git-dir="$git_common_dir" -c worktree.useRelativePaths=false -c core.hooksPath=/dev/null worktree add --quiet --detach "$snapshot_dir" "$snapshot_commit"
git --git-dir="$git_common_dir" -c worktree.useRelativePaths=false -c core.hooksPath=/dev/null worktree add --quiet --detach "$snapshot_dir" "$snapshot_commit" 6>&-
forgejo-actions commented 2026-10-23 18:50:50 +00:00

medium — Snapshot cleanup leaves an active checkout running after the hook is killed

If the hook receives SIGKILL while checkout is running a slow or blocked smudge filter, its Git child and the filter survive cancellation. The watcher deletes their worktree while they are still using it; a blocked filter can remain running indefinitely, and a resumed checkout attempts to write into the deleted directory. This violates the cancellation and cleanup obligation covered by ERR4.

The new watcher explicitly handles the hook dying by SIGKILL. This worktree-add invocation closes fd 6, so killing the hook immediately gives the watcher EOF even though checkout is still active. However, only run_step reports a process group through tell_watcher. During worktree add, watch_snapshot therefore has an empty process_group and calls remove_snapshot_files without stopping Git or its filter.

Run checkout in a separately tracked process group and report it to the watcher before relying on EOF to trigger cleanup, so cleanup stops the active checkout and its children before removing their files. Preserve the fd closure needed to avoid detached filter daemons retaining the pipe.

I traced run_step, watch_snapshot, remove_snapshot_files and the package.json prepare hook that enables this Git hook. On Linux with Bash 5.2 and Git 2.47, I ran node /tmp/review-hook-probe.mjs checkout-kill: the harness copied the unchanged subject hook and check-msg.sh into a temporary Git repository, staged package.json, pnpm-lock.yaml and a file with a blocking smudge filter, supplied a pnpm stub, invoked bash hook <message-file>, waited for the filter to start, then sent SIGKILL only to the hook PID. The snapshot disappeared, but a signal-zero probe confirmed the filter was alive. Releasing the filter let it finish, after which Git emitted errors including unable to create file a.txt: No such file or directory. The same harness without cancellation completed successfully and removed the snapshot. Real dependency installation was not exercised.

The decisive check is cancellation of the hook PID during an active checkout: both Git and its filter must stop before the watcher removes the snapshot. Cancellation of the entire process group does not exercise this case because that independently kills the checkout.

lens unix-cli · arm default · tally 1 valid / 0 invalid / 0 uncertain
claim 01M5N1G1K55SDYQ3T6QB0D32SZ of review 01M5N1B8DXB4TH1MFS79FZZJT7

<!-- review:claim:01M5N1G1K55SDYQ3T6QB0D32SZ --> **medium** — Snapshot cleanup leaves an active checkout running after the hook is killed > If the hook receives SIGKILL while checkout is running a slow or blocked smudge filter, its Git child and the filter survive cancellation. The watcher deletes their worktree while they are still using it; a blocked filter can remain running indefinitely, and a resumed checkout attempts to write into the deleted directory. This violates the cancellation and cleanup obligation covered by ERR4. > > The new watcher explicitly handles the hook dying by SIGKILL. This worktree-add invocation closes fd 6, so killing the hook immediately gives the watcher EOF even though checkout is still active. However, only run_step reports a process group through tell_watcher. During worktree add, watch_snapshot therefore has an empty process_group and calls remove_snapshot_files without stopping Git or its filter. > > Run checkout in a separately tracked process group and report it to the watcher before relying on EOF to trigger cleanup, so cleanup stops the active checkout and its children before removing their files. Preserve the fd closure needed to avoid detached filter daemons retaining the pipe. > > I traced run_step, watch_snapshot, remove_snapshot_files and the package.json prepare hook that enables this Git hook. On Linux with Bash 5.2 and Git 2.47, I ran `node /tmp/review-hook-probe.mjs checkout-kill`: the harness copied the unchanged subject hook and check-msg.sh into a temporary Git repository, staged package.json, pnpm-lock.yaml and a file with a blocking smudge filter, supplied a pnpm stub, invoked <code>bash hook &lt;message-file&gt;</code>, waited for the filter to start, then sent SIGKILL only to the hook PID. The snapshot disappeared, but a signal-zero probe confirmed the filter was alive. Releasing the filter let it finish, after which Git emitted errors including `unable to create file a.txt: No such file or directory`. The same harness without cancellation completed successfully and removed the snapshot. Real dependency installation was not exercised. > > The decisive check is cancellation of the hook PID during an active checkout: both Git and its filter must stop before the watcher removes the snapshot. Cancellation of the entire process group does not exercise this case because that independently kills the checkout. lens `unix-cli` · arm `default` · tally 1 valid / 0 invalid / 0 uncertain claim `01M5N1G1K55SDYQ3T6QB0D32SZ` of review `01M5N1B8DXB4TH1MFS79FZZJT7`
👎 1
jercik commented 2026-10-23 18:54:23 +00:00
Author
Owner

Declined for this owned-repository migration. At head 62812d9e, git check-attr reports no filter assigned to any of the 47 tracked paths. The watcher gap described for a deliberately blocked smudge filter is plausible, and I am not claiming that scenario is fixed or disproved. The owner explicitly limits Align to our actual repositories and rejects speculative edge-case machinery. We will retain the generated producer hook rather than add checkout supervision for an unused filter configuration. No follow-up PR is promised.

<!-- gh-feedback:reply-to:182194 --> Declined for this owned-repository migration. At head 62812d9e, git check-attr reports no filter assigned to any of the 47 tracked paths. The watcher gap described for a deliberately blocked smudge filter is plausible, and I am not claiming that scenario is fixed or disproved. The owner explicitly limits Align to our actual repositories and rejects speculative edge-case machinery. We will retain the generated producer hook rather than add checkout supervision for an unused filter configuration. No follow-up PR is promised.
jercik marked this conversation as resolved
jercik merged commit 1fda7bdb94 into main 2026-10-24 06:36:10 +00:00
jercik deleted branch chore/align-local-command 2026-10-24 06:36:10 +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/conventional-commit-msg!5
No description provided.