Summary
taskless check reports findings from paths git ignores. Observed with a git worktree at worktrees/<name>/, which is a complete second checkout of the repository — so every rule fires a second time, against another branch's code.
Reproduction
In taskless/cli, which ignores worktrees/ in .gitignore, .prettierignore, and eslint.config.js:
git worktree add worktrees/probe -b throwaway origin/main
taskless check --json
Findings before the worktree existed: 2. After: 5 — the same three READMEs reported again under worktrees/probe/.
docs-npx-cli README.md:37
docs-npx-cli packages/cli/README.md:17
docs-npx-cli worktrees/probe/.taskless/README.md:10
docs-npx-cli worktrees/probe/README.md:37
docs-npx-cli worktrees/probe/packages/cli/README.md:17
git check-ignore -v worktrees/probe/README.md → .gitignore:49:worktrees/.
Why it matters
A worktree is the worst case because it duplicates every finding and attributes them to a branch the user is not working on — including half-written code an agent is mid-edit on. But the general shape is the problem: build output, vendored copies, and local scratch directories are all conventionally gitignored, and a check that reads them reports on files no one is maintaining.
It also makes findings unstable in a way that is hard to attribute: the count changes when a worktree is added or removed, with nothing in the output explaining why.
Proposed fix
Honor .gitignore during the project walk. In a git repository, git ls-files --cached --others --exclude-standard is the exact set of files a user considers part of the project, and it is one call.
Points worth deciding:
- Explicit paths should probably still be checked.
taskless check worktrees/probe naming an ignored path is an instruction, not an accident — the ignore rule belongs to the bare project walk.
- Interaction with hidden-directory scanning. There is prior work on scanning hidden directories deliberately (
.changeset/scan-hidden-directories.md); hidden and ignored are different questions and the fix should not undo that. .github/ is hidden and tracked; worktrees/ is visible and ignored.
- Non-git directories need the existing walk as a fallback.
🤖 Generated with Claude Code
https://claude.ai/code/session_017cEN93Acyp4zBwP3oDnyy1
Summary
taskless checkreports findings from paths git ignores. Observed with a git worktree atworktrees/<name>/, which is a complete second checkout of the repository — so every rule fires a second time, against another branch's code.Reproduction
In
taskless/cli, which ignoresworktrees/in.gitignore,.prettierignore, andeslint.config.js:Findings before the worktree existed: 2. After: 5 — the same three READMEs reported again under
worktrees/probe/.git check-ignore -v worktrees/probe/README.md→.gitignore:49:worktrees/.Why it matters
A worktree is the worst case because it duplicates every finding and attributes them to a branch the user is not working on — including half-written code an agent is mid-edit on. But the general shape is the problem: build output, vendored copies, and local scratch directories are all conventionally gitignored, and a check that reads them reports on files no one is maintaining.
It also makes findings unstable in a way that is hard to attribute: the count changes when a worktree is added or removed, with nothing in the output explaining why.
Proposed fix
Honor
.gitignoreduring the project walk. In a git repository,git ls-files --cached --others --exclude-standardis the exact set of files a user considers part of the project, and it is one call.Points worth deciding:
taskless check worktrees/probenaming an ignored path is an instruction, not an accident — the ignore rule belongs to the bare project walk..changeset/scan-hidden-directories.md); hidden and ignored are different questions and the fix should not undo that..github/is hidden and tracked;worktrees/is visible and ignored.🤖 Generated with Claude Code
https://claude.ai/code/session_017cEN93Acyp4zBwP3oDnyy1