CI Failure DoctorCI Failure Investigation - Run #24921324240 — test_permission_guard.py fails on main branch

[github-actions]

Summary

The validate job's Run tests step fails because test_permission_guard.py runs on the main branch in CI, triggering the BLOCKED_ON_MAIN guard in git-permission-guard.py before the expected ask/silent_allow logic can execute.

Failure Details

• Run: 24921324240
• Commit: 8e5df03e64c0fe8825e5296c2a9a3123d6db358e
• Trigger: push to main — fix(content-guards): bound validate-markdown parent-walk at repo / $HOME (#247)
• Failed Step: Step 13 — Run tests

Root Cause Analysis

git-permission-guard.py has a BLOCKED_ON_MAIN = {"add", "commit", "push"} set. Whenever the first git subcommand token is in that set, _is_on_main_branch() is called (runs git branch --show-current). In CI the working directory is checked out on main, so it returns True and immediately returns deny — before the downstream ASK_GIT / silent-allow code paths run.

The three affected test cases expected ask or silent_allow, but the main-branch guard intercepts them first:

Test case	Command	Expected	Actual
git push --force feature branch	git push --force origin feature/my-branch	ask	deny
hooksPath in value only	git -c some.key=echo-core.hooksPath commit -m test	silent_allow	deny
hooksPath in commit message	git -c user.name=test commit -m "allow -c core.hooksPath bypass example"	silent_allow	deny

Note: This failure is not caused by PR #247. All 9 validate-markdown.bats tests (including the new TC9 HOME-boundary regression) pass cleanly. The test_permission_guard.py test gap surfaces whenever CI runs on the main branch.

Failed Jobs and Errors

FAIL [git push --force feature branch]: decision=deny (Expected: ask, Got: deny)
FAIL [hooksPath in value only]: decision=deny (Expected: silent_allow, Got: deny)
FAIL [hooksPath in commit message]: decision=deny (Expected: silent_allow, Got: deny)
SOME TESTS FAILED (from test_permission_guard.py)
Process completed with exit code 1.
```

## Recommended Actions

- [ ] **Option A (preferred):** Run `test_permission_guard.py` from a temporary git repo initialised on a feature branch, so `_is_on_main_branch()` returns `False` and tests execute against the logic they were written for.
- [ ] **Option B:** Add a `GIT_GUARD_SKIP_MAIN_CHECK=1` environment variable to `git-permission-guard.py` that disables `BLOCKED_ON_MAIN` when set — for test isolation only.
- [ ] **Option C (minimal):** Update the 3 failing test expectations to `deny` and add comments clarifying that those commands are correctly blocked on main — accepting that the test is now a main-branch-only scenario.

## Prevention Strategies

- Test scripts that exercise commands blocked by branch-specific guards should either create an isolated git repo on a non-main branch **or** mock/stub the branch detection function.
- Consider adding a CI check that runs `test_permission_guard.py` inside a temporary repo on a dedicated `test/guard-tests` branch to guarantee consistent behaviour regardless of the checkout branch.

## AI Team Self-Improvement

> Copy-paste into your AI coding instructions / `instructions.md`:

```
When writing or updating guard scripts that branch on `git branch --show-current`
(or any mechanism that detects the active branch), ensure the accompanying test
suite runs inside a temporary git repository initialised on a *non-main* branch,
or mocks the branch-detection call. Tests that rely on the real working directory's
branch will produce false failures when run on main in CI.

Historical Context

No prior investigations on record for this repository. This is the first captured failure pattern: test_permission_guard_py_main_branch_check — BLOCKED_ON_MAIN guard intercepting tests that assume a feature-branch context.

Note

🔒 Integrity filter blocked 1 item

The following item were blocked because they don't meet the GitHub integrity level.

• 8e5df03 list_commits: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".

To allow these resources, lower min-integrity in your GitHub frontmatter:

tools:
  github:
    min-integrity: approved  # merged | approved | unapproved | none

Generated by CI Failure Doctor · ● 3.5M · ◷

[github-actions]

🔁 Recurrence — Run #24941826312

The same test_permission_guard.py / BLOCKED_ON_MAIN failure recurred on the latest push.

Commit: f6d419e440a14392b23275f203bb05048dbced03
Change: Deleted the skill-guards plugin (redundant advisory-only hook) and updated finalize-pr, ship, and refresh-repo skills.

Why the failure persists

The commit does not touch git-guards/scripts/test_permission_guard.py or git-guards/scripts/git-permission-guard.py, so the three BLOCKED_ON_MAIN false-positive test cases remain:

Test	Command	Expected	Actual on main
git push --force feature branch	git push --force origin feature/my-branch	ask	deny
hooksPath in value only	git -c some.key=echo-core.hooksPath commit -m test	silent_allow	deny
hooksPath in commit message	git -c user.name=test commit -m "..."	silent_allow	deny

Note on skill-guards deletion

The deleted bats test (tests/skill-guards/...) lived in the top-level tests/ directory which scripts/run-tests.sh does not scan (it only scans <plugin>/tests/). There were no Python tests for skill-guards. The deletion itself causes no new test failures.

This issue will keep recurring on every push until the fix from the Recommended Actions section is applied.

Generated by CI Failure Doctor · ● 298.9K · ◷

[github-actions]

Another occurrence — Run #25092556307

Commit: b561a1593bfffae862fbc616c428f8f0b2003933 — chore(git-standards): forbid emoji in commits and PR titles (#266)

This is a recurring post-merge failure of the same root cause: test_permission_guard.py runs in CI on main, triggering the BLOCKED_ON_MAIN guard before the expected ask/silent_allow logic executes.

Note: The triggering commit only modified two markdown files (git-standards/skills/*/SKILL.md). All pre-merge checks on PR #266 passed — this failure appears only in the post-merge main branch CI run.

This continues to be a pre-existing test environment issue, not a regression from the merged change. The underlying fix remains as recommended above.

Generated by CI Failure Doctor · ● 216K · ◷