fix(triage_daemon): anchor the force-push deny glob to its own token

[springfall2008]

Summary

The AI triage bot's PR flow (/issue-pr) got blocked pushing a completely
ordinary branch: git push -u origin fix/power-flow-car-outside-ct-clamp-4788
was denied by the permission policy, so no PR was ever opened for #4788
even though the fix was complete and both quality gates had passed.

Root cause: _PR_FORCE_PUSH_DENIALS used "Bash(git push*-f*)" - an
unanchored glob that matches -f as a substring anywhere in the
command, not just as an actual flag. fix/power-flow-car-outside-ct-clamp-4788
contains power-flow, whose -flow includes -f, so the permission
engine read the branch name itself as a force-push attempt. Any branch
with -fix, -format, -field, etc. would trip the same false positive.

Fix

Anchor -f to its own token (spaces on both sides, or end of the
command): Bash(git push* -f), Bash(git push* -f *), plus the existing
Bash(git push* --force*). Still denies every real force-push spelling
(-f, --force, --force-with-lease); no longer matches substrings
inside ordinary branch names.

Testing

• Added two regression tests in tools/test_triage_daemon.py that
  simulate Claude Code's prefix-glob matching: one pins that branch names
  containing -flow/-format/-field are no longer falsely denied,
  the other pins that real force-push spellings still are.
• python3 -m unittest test_triage_daemon - 110/110 pass (was 108 before
  the two new tests).
• pre-commit run --files tools/triage_daemon.py tools/test_triage_daemon.py
  • clean (ruff, black, cspell, the triage-daemon unit-test hook).

Notes

Issue #4788's own branch (fix/power-flow-car-outside-ct-clamp-4788,
commit fd7f4f1a) already reached origin despite the bot's failure
report - likely a later retry with a different push spelling that
happened to dodge this bug, which the bot itself never noticed. That
issue is labelled BOT_PR_FAILED and is left for manual follow-up
separately from this fix.

The daemon (currently running as a long-lived process from the dedicated
clone) won't pick this fix up until that clone is synced to main and
the process restarted.

[Copilot]

🟡 Changes recommended

The new deny globs still allow combined short-flag spellings (e.g., -fu/-uf), and the new tests don’t currently cover (or reliably select) those cases.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Pull request overview

This PR fixes a false-positive in the triage daemon’s permission-policy denylist where git push branch names containing substrings like -flow could be misread as a -f force-push flag, blocking the /issue-pr flow from pushing branches and opening PRs.

Changes:

• Tightens the _PR_FORCE_PUSH_DENIALS glob patterns to anchor -f to a flag token rather than matching it as an arbitrary substring.
• Adds regression tests to ensure ordinary branch names containing -flow/-format/-field are not denied, while explicit force-push spellings still are.

File summaries

File	Description
tools/triage_daemon.py	Replaces the overly-broad git push*-f* denial glob with token-anchored variants to prevent branch-name substring false positives.
tools/test_triage_daemon.py	Adds unit tests simulating prefix-glob matching to prevent regressions for both false positives and real force-push denials.

Review details

Suppressed comments (1)

tools/test_triage_daemon.py:423

• To ensure the force-push deny rules really cover the combined short-option spellings, add git push -fu ... and git push -uf ... to real_force_pushes (these won’t match the current " ... -f " / end-of-command patterns). Also make sure the force_push_denials filter includes "-uf", otherwise the test can’t match against the new -uf denial rules even if they exist.

            "git push -f origin main",
            "git push origin main -f",
            "git push --force origin main",
            "git push --force-with-lease origin main",
        ]
        force_push_denials = [rule for rule in triage_daemon.DISALLOWED_TOOLS_PR.split(",") if "force" in rule or "-f" in rule]
        for command in real_force_pushes:
            matched = any(bash_rule_matches(rule, command) for rule in force_push_denials)
            self.assertTrue(matched, f"{command!r} should still be denied, but no rule in {force_push_denials} matched")

• Files reviewed: 2/2 changed files
• Comments generated: 2
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.