A dead-path Violation CI Reports Cannot Be Reproduced Locally, So the Fix Loop Is Push and Guess

[ptr727]

Found while fixing #1403. Separate from that fix, because it obstructs anyone fixing any
dead-path finding rather than being about the one file.

The gap

A dead-path violation reported by CI cannot be reproduced locally, so it cannot be confirmed
fixed before pushing.

Measured on ptr727/HomeAutomation-Config PR #160, whose CI reported three:

.github/skills/operational-vs-release-workflow/references/branch-protection-and-promotion.md:17: dead-path: path 'repo-config/README.md' is deleted from this tree
.github/skills/operational-vs-release-workflow/references/branch-protection-and-promotion.md:26: dead-path: path 'repo-config/settings.json' is deleted from this tree
.github/skills/operational-vs-release-workflow/references/branch-protection-and-promotion.md:110: dead-path: path 'repo-config/README.md' is deleted from this tree

Run against the same worktree, at the same commit, with the same diff base f311fe8 that CI used:

Invocation	Result
.github/actions/prose-gate/prose_lint.py --diff f311fe8 .	30 of 237 files read, no violation
scripts/prose_lint.py --diff f311fe8 .	30 of 237 files read, no violation
either, --check dead-path <the file>	1 file read, no violation
either, --check dead-path . (whole tree)	237 files read, 1 violation, an unrelated .vscode/settings.json in GOVERNANCE.md

Ruled out: version skew, since the action's copy on main and on develop are byte-identical and
both behave the same here; the two prose_lint.py copies differing, since both behave the same;
the diff base, since it is the one CI used; and the check being inert, since the whole-tree run
does fire on a different path in the same repository.

The file still contains all three mentions at the time of every run above, verified by grep.

Why it matters more than the finding it hides

The gate is one a downstream repository hits on carried content it cannot fix, per #1403 and
#1138. Whoever fixes that content is in the hub, and cannot confirm the fix from the hub either,
because dead-path keys on history: "No mention of a path git once tracked and the tree no
longer holds". In the hub repo-config/ exists, so nothing fires there by construction. The only
place the check speaks is a repository that once tracked the path and deleted it, and that is
exactly where the local run above stays silent.

So the fix loop for this class of finding currently is: push, wait for CI, read, guess again. A
gate that cannot be run before the push is the one property the fleet's own verification rules
say a gate must not have.

What would settle it

Establishing which of the two the local runs are doing, since the remedies differ:

1. The local invocation is wrong, and the runbook should state the one that reproduces CI.
   GOVERNANCE.md "Running the Linters Locally (Known-Working Invocations)" exists for exactly
   this, and carries no dead-path entry today.
2. The action and a local run genuinely differ, in which case the difference is a defect in
   one of them, and the composite action is the one CI trusts.

Either way a regression test over a fixture repository that tracked and deleted a path would pin
the behavior, since the current suite passes while the two disagree.

[ptr727]

Settled by #1417, merged to develop as 0b4657d. This issue stays open until a develop -> main promotion registers the closing reference.

The answer is neither of the two candidates above

This issue proposed that either the local invocation was wrong, or the action and a local run genuinely differ. Both are wrong. The local invocation was correct and the composite action is not defective.

HomeAutomation-Config pins the hub reusable workflow at 389f5b9. The HUB_HOSTED exemption that silences repo-config/README.md and repo-config/settings.json landed in e31d3fc, the immediately following commit. Its CI therefore ran a prose gate exactly one commit behind the rule, and no local run of a current copy could reproduce it.

Reproduced by extracting the pinned copy and running it against the same worktree and the same diff base:

Copy	Result
389f5b9, what CI ran	3 violations at lines 17, 26 and 110, matching the CI output quoted above
hub develop	0 violations

So the three findings were stale-pin false positives, and the "ruled out" list above was sound as far as it went. What it could not rule out was a difference between the copy CI fetched and every copy available locally, because nothing in either verdict said which copy produced it.

Why the pin was stale

Dependabot version updates had never run on that repository. Account-level "Dependabot on self-hosted runners" was enabled, routing update jobs to runners that do not exist, which silently affected every private repository in the fleet and no public one. The maintainer has since disabled it. Filed separately as #1418, since the fleet's own conformance script asserts the two Dependabot security features and nothing about version updates.

What changed

Every prose-gate verdict now names the copy that produced it, on the scope line: gate <owner>/<repo>@<ref> from a pinned remote action, gate local <sha> from a checkout tracking the script at that commit, -dirty where the working copy moved, and unknown where no commit describes it. A verdict with no gate clause predates the change, which dates the copy just as well.

GOVERNANCE.md gains the reproduction recipe this issue found missing, verified verbatim against the case above. So the remedy is option 1 from "What would settle it", the runbook entry, with the attribution added so the question answers itself before anyone reaches for the runbook.

Three follow-ups were carried out of that pull request rather than left in its body: #1419, #1420 and #1421.

[ptr727]

Owed on the promotion pull request that closes this issue: trigger CodeRabbit with @coderabbitai review.

#1417 merged without one. CodeRabbit's open-source tier does not auto-review a repository under ten stars, so it posted its skip notice while its status check reported success, and I read the green check as coverage instead of prompting it, which .agents/skills/pr-review-conduct/SKILL.md "Which Reviewers a Repository Actually Has" requires the driving agent to do.

Triggering it after the merge does not recover it. CodeRabbit answers a closed pull request with "Action not completed - Pull request is closed", and it does not re-review already reviewed commits, so the only remaining opportunity for these five files to receive a CodeRabbit read is the develop -> main promotion pull request that carries them.

Recording it here rather than in a session log, since this issue is already the one held open until that promotion runs.

[coderabbitai]

@ptr727, acknowledged. On the open develop -> main promotion pull request, post:

`@coderabbitai` review

This triggers the CodeRabbit review for the changes from #1417 before the promotion pull request closes.

---

✏️ Learnings added

Learnt from: ptr727
URL: https://github.com/ptr727/ProjectTemplate/issues/1412

Timestamp: 2026-09-07T18:58:14.127Z
Learning: In `ptr727/ProjectTemplate`, the open `develop -> main` promotion pull request that closes GitHub issue `#1412` must receive an explicit `coderabbitai review` comment. The repository has fewer than ten stars, so the CodeRabbit open-source tier can skip automatic reviews while its status check still succeeds. The review-conduct procedure in `.agents/skills/pr-review-conduct/SKILL.md`, section `Which Reviewers a Repository Actually Has`, requires the driving agent to trigger CodeRabbit when automatic coverage is unavailable.

Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.

You are interacting with an AI system.