Skip to content

chore(guardrails): reinstall the commit-msg git hooks on operator machines after the convention move #9735

Closed

Description

@kyle-sexton

Parent

Refs #5906

Depends on

Needs a person: the installed commit-msg hooks live in each operator machine's clones and user git config, which no CI agent can reach.

Outcome

Every operator machine runs the guardrails commit-msg hook from a release whose resolver reads
docs/conventions/source-control.yaml, so this repository's .claude/source-control.md can be deleted.

Decisions

Done when

  • A guardrails release containing the change that closed the guardrails resolver slice is published (git tag --contains <its merge commit> prints a guardrails tag).
  • On each operator machine, /guardrails:setup apply install-commit-msg (or the config-hook lane, where installed) has been re-run, and a commit in this repository with a non-conforming subject is refused.
  • A comment on this issue lists the machines done.

Activity

  1. added theissue type on Oct 24, 2026
  2. added
    priority: mediumReal value, no hard deadline; normal backlog flow.
    needs-humanHuman-in-the-loop required; autonomous sessions must not resolve items carrying this.
    on Oct 24, 2026
  3. added
    host-runNeeds an unattended run on a host; the host runner takes it, not a person or the issue lane.
    and removed
    needs-humanHuman-in-the-loop required; autonomous sessions must not resolve items carrying this.
    on Oct 28, 2026
  4. added
    needs-triageNot yet classified. Floor until a type and one priority tier are set.
    on Oct 28, 2026
  5. github-actions commented on Oct 28, 2026

    @github-actions
    Contributor

    Proposed work class: none

    Size: Small
    Complexity: Low
    Uncertainty: Known
    Flags: none
    Blocked by: #9727

    Understood: once a guardrails release carrying the new resolver (reading docs/conventions/source-control.yaml) ships, each operator machine needs its commit-msg hook reinstalled. After that, .claude/source-control.md can be deleted. The work is blocked by the resolver refactor in #9727. #9725 does not appear in the open issues, so it may already be closed. The release check and the per-machine reinstall are host-run steps that an unattended lane cannot do. Nothing else is missing. No duplicates found.

    Automated triage. A maintainer reviews it.

  6. removed
    needs-triageNot yet classified. Floor until a type and one priority tier are set.
    on Oct 28, 2026
  7. 2 remaining items

  8. melodic-automation-lanes commented on Oct 28, 2026

    @melodic-automation-lanes
    Contributor

    The latest triage verdict holds nothing: admission moved the issue to status: needs-decision; its comment says why.

  9. kyle-sexton commented on Oct 29, 2026

    @kyle-sexton
    MemberAuthor

    Re-triage. Not an owner stop. The issue waits on #9727, the guardrails resolver slice, which is open and already linked as its blocker. #9725, the other dependency, closed as completed. The reinstall on each operator machine is a host step, which host-run already routes to the host runner. The issue lane does not take it. Admission's note that the last criterion is a comment does not apply to a host-run issue.

    Acceptance criteria (unchanged; run once #9727 is closed):

  10. added
    status: confirmedA maintainer confirmed the item is real and in scope; ready to be worked.
    and removed
    status: needs-decisionAwaiting a human or maintainer judgment call.
    on Oct 29, 2026
  11. github-actions commented on Oct 31, 2026

    @github-actions
    Contributor
    No description provided.
  12. melodic-automation-lanes commented on Oct 31, 2026

    @melodic-automation-lanes
    Contributor

    This records a re-fire of an earlier refusal, not a new refusal. The lanes kill switch stopped run 41221398022, the work-resolve-issue run that agent-ready started, before it did any work; that run ended at 2026-10-31T18:06:47Z. work-unblock has now removed and added agent-ready back to start a fresh run. A kill-switch refusal is no fault in this issue or the lanes, so it never counts against later re-fires; after limits.limit-stops-per-issue of them since a person last added agent-ready or a run last reported, work-unblock waits longer before each one, up to 24 hours.

  13. added
    agent-readyFully specified and briefed; eligible for autonomous pickup from the frontier.
    and removed
    agent-readyFully specified and briefed; eligible for autonomous pickup from the frontier.
    on Oct 31, 2026
  14. github-actions commented on Oct 31, 2026

    @github-actions
    Contributor
    No description provided.
  15. github-actions commented on Oct 31, 2026

    @github-actions
    Contributor
    No description provided.
  16. removed
    agent-readyFully specified and briefed; eligible for autonomous pickup from the frontier.
    on Oct 31, 2026
  17. melodic-automation-lanes commented on Oct 31, 2026

    @melodic-automation-lanes
    Contributor

    The work-resolve-issue lane stopped on this issue (host-only): the run reports the work needs a host run the lane cannot make.
    It added host-run and removed agent-ready: an agent run on a host builds it, and it waits on no decision from a person.

    In the run's words:

    host-only: every done-when item is a host or owner step this lane cannot take. The issue body says 'Needs a person: the installed commit-msg hooks live in each operator machine's clones and user git config, which no CI agent can reach', and the issue carries the host-run label. The work is to re-run /guardrails:setup apply install-commit-msg on each operator machine, confirm a non-conforming commit subject is refused there, and comment the machines done. It also waits on #9727, the guardrails resolver slice, and on a guardrails release that contains it, per the 2026-10-29 re-triage comment.

    What the run says it did not do:

    • Publishing a guardrails release that contains #9727's merge commit, and the git tag --contains check: #9727 is still open, and releases are not this lane's to cut
    • Re-running /guardrails:setup apply install-commit-msg on each operator machine and confirming a non-conforming subject is refused: needs a host run on each operator machine
    • The comment listing the machines done: written once the host step finishes
    • Tidy, review, verify and checks pipeline steps: skipped because there is no diff

    Run: https://github.com/melodic-software/claude-code-plugins/actions/runs/41250057012

    To hand it back to the lane, remove host-run and add agent-ready again.

  18. kyle-sexton commented on Nov 2, 2026

    @kyle-sexton
    MemberAuthor

    Host run (Lane 5): done on every operator machine. The commit-msg hook refuses a non-conforming subject in every clone of this repository, and it reads the pattern from docs/conventions/source-control.yaml.

    Done when

    1. Release. This repository releases through chore(release) version bumps, not tags, so git tag --contains prints nothing for any commit here. The resolver change (refactor(guardrails): resolve the commit convention from docs/conventions/source-control.yaml #9727, merged in refactor(guardrails): delete the folder-form commit convention file #11625 as cc3c084) first shipped in guardrails 0.76.0 (release chore(release): release 6 plugins #11673), and 13 more guardrails release commits have landed since. main is at 0.83.0.
    2. Hooks. /guardrails:setup apply install-commit-msg is retired in current guardrails. Every clone now runs the hook through lefthook's remote: the guardrails-remote-commit-msg-convention job, from lefthook's fetched copy of main (.git/info/lefthook-remotes/claude-code-plugins-main). Test: git hook run commit-msg -- <file> with the subject bad subject without a type, run from inside each clone, so no commit was made.
    Machine / clone Result
    melo-lap-001, WSL (~/repos/...) refused, exit 1
    melo-lap-001, native Windows (D:\repos\...) refused, exit 1
    melo-desk-001, WSL (~/repos/...) refused, exit 1
    melo-desk-001, native Windows (D:\repos\...), run as the console account refused, exit 1

    Every refusal printed subject_pattern in docs/conventions/source-control.yaml.

    1. Machines done: the four clones above. melo-phone-001 is a client with no clones.

    Found

    • On the laptop's Windows clone, git.exe -C C:\Users\KyleSexton\repos\... called from WSL passed the bad subject. That path reaches the clone through a link to D:\repos. Run from inside the clone, the same hook refused, and its verbose output showed both the work-tree copy and the fetched remote copy running. Normal commits run inside the clone, so this does not affect them. Why the -C form skipped the refusal is UNVERIFIED.

    .claude/source-control.md can now be deleted. That is #9737.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    host-runNeeds an unattended run on a host; the host runner takes it, not a person or the issue lane.priority: mediumReal value, no hard deadline; normal backlog flow.status: confirmedA maintainer confirmed the item is real and in scope; ready to be worked.

    Type

    Fields

    No fields configured for Task.

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions