claude-config audit-instructions: emit-findings.sh declines the relative scan-row paths instruction-scan.sh produces, dropping those findings

[kyle-sexton]

What is wrong

Two sibling scripts in the claude-config:audit-instructions skill disagree about the path form a scan row may carry, so findings are discarded between them.

scripts/instruction-scan.sh emits candidate rows as file:line:check-id, using whatever path form the caller handed it. Naming a repo-owned surface relatively is the ordinary invocation, and SKILL.md documents the call as instruction-scan.sh <file>... with no requirement that the path be absolute.

scripts/emit-findings.sh relativizes each row's path with relativize_in_repo(), which tests the path against three absolute anchors (repo_root_pwd, repo_root, repo_root_alt) and returns the empty string when none of them prefixes it. A path that is already repo-relative — exactly the form Location requires — matches no absolute anchor, so it returns empty and the row is declined as outside-repo-root.

Reproduction

In a git checkout containing withfm.md (a file with ordinary YAML frontmatter and a CRITICAL: directive in its body):

$ bash instruction-scan.sh --body-only withfm.md
withfm.md:6:I28-a

$ bash emit-findings.sh --from scan.txt --out out.md --branch b
$ grep -E '^\| [0-9]|Declined|Emitted' out.md
Scan rows read: 1. Emitted: 0.
Declined candidates: I28-a count=1 reason=outside-repo-root (Location must be repo-relative; human report only)

The identical file named by absolute path emits normally:

Scan rows read: 1. Emitted: 1.
| 1 | IMPORTANT | high | withfm.md:6 | ... |

Note that the emitted Location in the working case is withfm.md:6 — the very form that was rejected as not repo-relative when supplied directly.

Why it matters

The scanner's own natural output is silently unusable by its consumer. Every finding from a relatively-named target is dropped from the machine-readable relay and survives only in the human report, and the stated decline reason ("Location must be repo-relative") is the opposite of the truth for these rows.

plugins/ai-slop/skills/audit/scripts/emit-findings.sh does not have this gap: its relativize() returns the path unchanged when no anchor matches, rather than declining the row.

Suggested direction

Treat a path that is not absolute as already repo-relative and admit it as-is.

One caveat worth handling in the same change: admitting relative paths is what makes traversal expressible here. The anchor test is lexical, so .. segments are not currently considered — <repo>/../outside.md prefix-matches an anchor and would relativize to ../outside.md, which the fix pass would then resolve outside the working tree. A path holding a .. segment should be refused outright, which is the fail-closed direction and preserves the fence's stated purpose.

Context

#3242 reworked path anchoring in both emit-findings.sh producers to resolve repo-root spelling differences. The relative-path case was not part of that change. There is no test covering a relative scan-row path in scripts/emit-findings.test.sh today.

[kyle-sexton]

[kyle-sexton]

Standing down: this was fixed and merged as 7b028f9 while I held a lease on it, and the merged fix is complete. No pull request from me.

At claim time the item had no live lease, no matching branch, no close-linking pull request, and no activity, so the claim was legitimate; the duplicate came from two lanes converging on the same item rather than from a stale marker. My branch is deleted and the lease is released.

The merged fix and mine reached the same design independently: resolve a non-absolute row against the calling directory (the directory the writer already reads the file from) rather than against the repo root, then apply the unchanged fail-closed fence. I verified 7b028f9 empirically on the two cases I considered load-bearing. A subdirectory-relative row emits sub/nested.md:7, the correct root-relative Location rather than a plausible-looking bare nested.md. A backslash-spelled traversal is declined and counted rather than reaching the table. Both behave correctly, and its has_dotdot_segment() is a more granular treatment of the traversal spellings than the separator-normalizing form I had written.

Two findings from the review this work went through are worth recording, since they were reached against an equivalent implementation and therefore apply to the merged one.

The traversal refusal reports reason=outside-repo-root for a path that traverses but resolves back inside the repository. The drop is counted, so the contract holds, but the stated reason is inaccurate for that case. Left alone deliberately: the docs-hygiene:audit-noise sibling counts its own .. refusal under the same label, and one producer inventing a private reason string is how two consumers of one convention drift apart.

The second is a genuine silent drop and is filed separately as #3279. A row that misses the intake pattern increments no counter and reaches no decline bucket, so it appears in neither Scan rows read nor any Declined candidates line. That is pre-existing rather than introduced by either fix, and latent today because every check id the two producers actually emit matches the pattern.

An autonomous agent panel produced these conclusions; no human has confirmed them.