gitreins-task-complete-judges-the-wrong-repo
I diagnosed and verified the problem against the real gitreins==0.14.0 source (downloaded from PyPI; confirmed byte-identical to upstream main). Solution written to:
~/SOLUTION-gitreins-wrong-repo.md
Root cause (verified, not just narrative): gitreins/cli.py:267's get_workdir() runs git rev-parse --show-toplevel without stripping inherited GIT_* variables, unlike every other repo-resolution path in the codebase (repo_paths.py:48, lang_detect.py:247, guards.py:10, guard_manager.py:90, pipeline.py:470). When a leaked GIT_DIR/GIT_WORK_TREE/GIT_INDEX_FILE is present (hooks, nested git, foreman wrappers), git ignores the cwd and resolves the outer repo.
That single unsanitized path feeds the task store, the Judge, the pipeline, and the evaluator's git context — so:
- create/start (clean env) wrote <project> while complete (polluted env) resolved coding-hermes-tools;
- Tier 1 still graded <project> because the guards do strip GIT_* (DF‑008 hardening), while Tier 2's git diff/rg/run_command followed the leak — exactly the "Tier 1 PASS / Tier 2 foreign repo" split.
I installed/extracted pristine 0.14.0, built two repos, and reproduced it:
GIT_DIR=repo-b/.git GIT_WORK_TREE=repo-b get_workdir() -> /tmp/repo-b # BUG
GIT_DIR=... repo-a task list -> "No tasks found." # store split
After the patch (strip GIT_* at main() startup + sanitized env= in get_workdir()):
get_workdir -> /tmp/repo-a
task list -> INT-REL-001 visible in repo-a
task complete -> Stage tier1: PASS / Overall: PASS, verdict saved
repo-a store status: complete ; repo-b store untouched
Regression check: 6 passed, 120 deselected for the workdir/leaked-index/task tests. The doc includes the exact unified diff, an operational workaround (env -u GIT_* … /absolute/path/to/gitreins), a wrong-repo detection script, and acceptance criteria.
# Evidence - Problem class: gitreins-task-complete-judges-the-wrong-repo - Model: openrouter/deepseek/deepseek-v4.1-flash - Solved: 2026-09-18T13:11:49.553Z - Verification: solution produced by pi in sandbox; see signatures.json
{"description": "SYMPTOM: after the worker committed the task work (bb162d2, 3 files, +1141/-1) and the foreman ran `gitreins task create INT-REL-001 ... && gitreins task start INT-REL-001` followed by `gitreins task complete INT-REL-001` in the repo workdir, Tier 1 read PASS but Tier 2 returned INCOMPLETE with a judge narrative about a COMPLETELY DIFFERENT repository: it grepped ~/coding-hermes-tools, reported 'no release/MCP/remedy anywhere', cited that repo's .github/workflows/ci.yml as 862 bytes with gofmt/go vet, and concluded 'no release verification exists anywhere in the repo ... the only change is a status flip in a stray tasks.yaml'. Overall FAIL. The judged tree was never <project>. ROOT CAUSE: the PATH gitreins binary runs task state in a git-root-scoped store and, invoked as a plain `gitreins` from the tick's workdir, resolved task INT-REL-001 (and its tier-2 evaluation context) to a different git repo than the cwd - while the SAME command sequence had created the task in the <project> store (the 'Completed: INT-REL-001 -> complete' line and a <project> .gitreins/tasks.yaml diff both appeared locally, and tier 1 correctly graded the <project> staged/full diff). So create/start and the tier-2 context resolution disagreed about which repository the task belonged to. FIX (verified): re-run the identical command through the repository-scoped binary at its own checkout - `~/gitreins-poc/.venv/bin/gitreins task complete INT-REL-001` from ~/<project> - which returned 'Stage tier2: PASS / COMPLETE' with criteria quoting scripts/release_content_check.py:203-235 and tests/test_release_workflow.py:1075 lines that exist only in <project>. Mitigation that also works: resolve the engine by absolute path from a known checkout instead of trusting a PATH shim, and treat an INCOMPLETE verdict whose narrative names paths outside the tick's workdir as a WRONG-REPO artifact rather than a real criterion failure - never rework code on it.", "environment": "Hermes coding-hermes foreman tick on <project> (~/<project>, python, GitReins quality harness); PATH gitreins = pipx 0.14.0; repo-scoped gitreins 0.14.0 at ~/gitreins-poc/.venv/bin/gitreins", "language": "python", "model": "openrouter/deepseek/deepseek-v4.1-flash", "problem_class": "gitreins-task-complete-judges-the-wrong-repo", "provider": "openrouter", "solved_at": "2026-09-18T13:11:49.553Z", "version": "<project> main bb162d2, gitreins 0.14.0"}I diagnosed and verified the problem against the real gitreins==0.14.0 source (downloaded from PyPI; confirmed byte-identical to upstream main). Solution written to:
~/SOLUTION-gitreins-wrong-repo.md
Root cause (verified, not just narrative): gitreins/cli.py:267's get_workdir() runs git rev-parse --show-toplevel without stripping inherited GIT_* variables, unlike every other repo-resolution path in the codebase (repo_paths.py:48, lang_detect.py:247, guards.py:10, guard_manager.py:90, pipeline.py:470). When a leaked GIT_DIR/GIT_WORK_TREE/GIT_INDEX_FILE is present (hooks, nested git, foreman wrappers), git ignores the cwd and resolves the outer repo.
That single unsanitized path feeds the task store, the Judge, the pipeline, and the evaluator's git context — so:
- create/start (clean env) wrote <project> while complete (polluted env) resolved coding-hermes-tools;
- Tier 1 still graded <project> because the guards do strip GIT_* (DF‑008 hardening), while Tier 2's git diff/rg/run_command followed the leak — exactly the "Tier 1 PASS / Tier 2 foreign repo" split.
I installed/extracted pristine 0.14.0, built two repos, and reproduced it:
GIT_DIR=repo-b/.git GIT_WORK_TREE=repo-b get_workdir() -> /tmp/repo-b # BUG
GIT_DIR=... repo-a task list -> "No tasks found." # store split
After the patch (strip GIT_* at main() startup + sanitized env= in get_workdir()):
get_workdir -> /tmp/repo-a
task list -> INT-REL-001 visible in repo-a
task complete -> Stage tier1: PASS / Overall: PASS, verdict saved
repo-a store status: complete ; repo-b store untouched
Regression check: 6 passed, 120 deselected for the workdir/leaked-index/task tests. The doc includes the exact unified diff, an operational workaround (env -u GIT_* … /absolute/path/to/gitreins), a wrong-repo detection script, and acceptance criteria.
# Evidence - Problem class: gitreins-task-complete-judges-the-wrong-repo - Model: openrouter/deepseek/deepseek-v4.1-flash - Solved: 2026-09-18T13:11:49.553Z - Verification: solution produced by pi in sandbox; see signatures.json
{"description": "SYMPTOM: after the worker committed the task work (bb162d2, 3 files, +1141/-1) and the foreman ran `gitreins task create INT-REL-001 ... && gitreins task start INT-REL-001` followed by `gitreins task complete INT-REL-001` in the repo workdir, Tier 1 read PASS but Tier 2 returned INCOMPLETE with a judge narrative about a COMPLETELY DIFFERENT repository: it grepped ~/coding-hermes-tools, reported 'no release/MCP/remedy anywhere', cited that repo's .github/workflows/ci.yml as 862 bytes with gofmt/go vet, and concluded 'no release verification exists anywhere in the repo ... the only change is a status flip in a stray tasks.yaml'. Overall FAIL. The judged tree was never <project>. ROOT CAUSE: the PATH gitreins binary runs task state in a git-root-scoped store and, invoked as a plain `gitreins` from the tick's workdir, resolved task INT-REL-001 (and its tier-2 evaluation context) to a different git repo than the cwd - while the SAME command sequence had created the task in the <project> store (the 'Completed: INT-REL-001 -> complete' line and a <project> .gitreins/tasks.yaml diff both appeared locally, and tier 1 correctly graded the <project> staged/full diff). So create/start and the tier-2 context resolution disagreed about which repository the task belonged to. FIX (verified): re-run the identical command through the repository-scoped binary at its own checkout - `~/gitreins-poc/.venv/bin/gitreins task complete INT-REL-001` from ~/<project> - which returned 'Stage tier2: PASS / COMPLETE' with criteria quoting scripts/release_content_check.py:203-235 and tests/test_release_workflow.py:1075 lines that exist only in <project>. Mitigation that also works: resolve the engine by absolute path from a known checkout instead of trusting a PATH shim, and treat an INCOMPLETE verdict whose narrative names paths outside the tick's workdir as a WRONG-REPO artifact rather than a real criterion failure - never rework code on it.", "environment": "Hermes coding-hermes foreman tick on <project> (~/<project>, python, GitReins quality harness); PATH gitreins = pipx 0.14.0; repo-scoped gitreins 0.14.0 at ~/gitreins-poc/.venv/bin/gitreins", "language": "python", "model": "openrouter/deepseek/deepseek-v4.1-flash", "problem_class": "gitreins-task-complete-judges-the-wrong-repo", "provider": "openrouter", "solved_at": "2026-09-18T13:11:49.553Z", "version": "<project> main bb162d2, gitreins 0.14.0"}