Repository navigation
fix(testing): test judge marks a linked-worktree test UNKNOWN because its quotes are grounded against the wrong repository #6206
Description
This was generated by AI during work-loop.
Context
The testing plugin's Stop-hook test judge returned an UNKNOWN for a test file that sits in a linked worktree a dispatched implementer was still editing. The UNKNOWN then blocked the orchestrator's Stop with "show the user each verdict ... wait for the user", even though the verdict had no finding in it.
Observed 2026-10-04T07:10:11Z in an orchestrator session rooted at the main checkout (C:/Projects/melodic/claude-code-plugins, branch main). Review file .work/reviews/main/20261004T071011Z-test-judge.md:
UNKNOWN
C:/Projects/melodic/worktrees/melodic-software-claude-code-plugins-6187/plugins/harness-ops/skills/plugins/scripts/sync-run.test.sh(lines 1-1739)
Reason: a quoted line is in no file of the repository
Judge: sonnet at medium effort.
The reason string comes from the quote-grounding check in plugins/testing/hooks/judge-lib.sh (judge::quoted_in_repo, around line 605).
Suspected causes (unverified; reproduce first)
- Wrong repository for the quote check. The test file is in a linked worktree (
worktrees/...-6187, branchfeat/6187-plugins-sync-ask-installs), but the session's repository is the main checkout. If the grounding check searches the main checkout, a line that exists only on the worktree's branch is "in no file of the repository". This looks like the same family as fix(testing): test judge runs in the wrong repository and returns "Read permission denied" UNKNOWNs #6099 (judge in the wrong repository, closed by fix(testing): judge each test file in its own repository, with an absolute Read rule #6168), but on the quote-grounding path. - The file changed under the judge. The implementer kept editing the file after the judge read it, so a quoted line may no longer exist when it is checked.
- Scope. The test was edited by a subagent working in another worktree, not by this session. The parent session's Stop hook arguably should not judge it at all, or should judge it against that worktree's repository.
Proposed work
Reproduce with a test file in a linked worktree that a subagent edits, then judge it from a session rooted elsewhere. Fix whichever cause holds. At minimum, resolve the grounding repository from the test file's own git rev-parse --show-toplevel, not the session's. Then decide whether an UNKNOWN produced by grounding failure alone should block Stop and ask the user to act.
Acceptance criteria
- A regression test: a test file in a linked worktree, with a quoted line that exists only on that worktree's branch, is grounded successfully (no "in no file of the repository" UNKNOWN).
- A stay-quiet test: a quote that really exists nowhere still yields the UNKNOWN.
- An UNKNOWN that carries no finding does not block Stop with a request for user action, or the operator records why it should.
References
- fix(testing): test judge runs in the wrong repository and returns "Read permission denied" UNKNOWNs #6099, fix(testing): judge each test file in its own repository, with an absolute Read rule #6168 (judge ran in the wrong repository), fix(testing): skip temp-copy tests and stop blocking Stop on judge runs with nothing to decide #6037, fix(testing): reject comment-only judge repairs and judge identical tests consistently #6044
Metadata
Filed by the work-loop lane (instance melo-worker-1) at the operator's request. Not self-triaged.
Activity
github-actions commentedon Oct 4, 2026
Thanks for the report. Automated triage handed this issue to a maintainer.
Automated triage. A maintainer reviews it.
kyle-sexton commentedon Oct 4, 2026
This was generated by AI during work-loop.
Second occurrence, 2026-10-04T08:07:50Z: the same session (rooted at the main checkout) got the same UNKNOWN for the same linked-worktree file, now lines 1-1743, after the #6187 ready flow had pushed further commits there. Review file:
.work/reviews/main/20261004T080750Z-test-judge.md. It recurs at every Stop while the worktree's test differs from main, so each recurrence blocks Stop again.kyle-sexton commentedon Oct 4, 2026
This was generated by AI during triage.
Triage verdict: cause 1 confirmed for the code that ran, and fixed by #6168 (testing 0.22.6, on origin/main). Cause 2 and acceptance criterion 3 remain open. Needs an operator decision on scope.
Evidence
repoas the main checkout, not the-6187worktree. The judge itself returned PASS; validation turned it UNKNOWN because a quoted line was not found in the main checkout. Basis: verified, the testing plugin's data directory verdict record for that file,repo: C:/Projects/melodic/claude-code-plugins,verdict: PASS(before validation).judge::file_repo, and the local main checkout the directory marketplace points at is 17 commits behind origin/main and does not contain fix(testing): judge each test file in its own repository, with an absolute Read rule #6168. The recurrence at 08:07:50Z is the same stale code.judge::runresolves the repository from the test file's owngit rev-parse --show-topleveland records it on the verdict, andjudge::validategrounds quotes against that recorded repository. Basis: verified, origin/main plugins/testing/hooks/judge-lib.sh:567-571 and :662-667; plugins/testing/CHANGELOG.md 0.22.6 entry.judge::validatefilters quotes against the test file as it is at validation time, so if the file is edited after the judge read it, a quote can fail grounding even in the correct repository and produce this same UNKNOWN.Open question for the operator
Either way, the immediate recurrence stops only once the session runs testing 0.22.6 or later (update the local checkout and installed plugin).
Routing: human-gated, needs a decision. Priority medium. Work class scoped (bug fix) for whatever remains after the decision.
kyle-sexton commentedon Oct 4, 2026
This was generated by AI during work-loop.
Operator decision (2026-10-04): narrow this issue (option a, recommended in the triage comment).
Cause 1 (grounding against the wrong repository) is fixed by #6168, shipped in testing 0.22.6; the occurrences reported here came from an older installed testing version. What stays in scope:
Acceptance: a test for each of 1 and 3, red before the fix, and a recorded decision for 2, implemented if the answer is no.