Running the CLI migrates .taskless/ as a side effect, which lands in unrelated commits #188

What happens

Running any command that loads the rule layout (taskless check is the one that caught this) migrates .taskless/ on disk as a side effect, rewriting tracked files. Observed while running pnpm cli check to verify an unrelated change:

M  .taskless/.gitignore
A  .taskless/rules/runtime/.gitkeep
A  .taskless/rules/sg/no-eval/.tests/.gitkeep
R  .taskless/rules/no-eval.yml -> .taskless/rules/sg/no-eval/no-eval.yml
A  .taskless/rules/vale/.gitkeep
D  .taskless/sgconfig.yml
M  .taskless/taskless.json

The migration itself is correct and intended. The surprise is that a read-shaped verb performs it, and that it lands in git status as a tracked-file change the caller did not ask for.

Why it matters here specifically

This repository dogfoods its own CLI, so pnpm cli check is now a step in validate.yml and is run by hand constantly while developing. Two concrete ways it bites:

1. It silently joins whatever commit you are making. A git add -A after a verification run stages a layout migration alongside an unrelated change. I caught this on a branch for A GitHub remote should not be a precondition for Taskless #179; without the check it would have shipped a .taskless/ migration inside an error-code commit.
2. Two branches that both run it produce the same migration independently, so the identical generated layout arrives twice and conflicts on merge. The migration is already carried by feat: enforce the house-style rules on main, including the agent recipes #187; any branch that runs check before that lands reproduces it.

Neither is a bug in the migration. Both come from a verb that reads producing a diff that writes.

Ask

A note in CLAUDE.md so an agent working in this repository expects it, roughly:

Running the CLI can modify tracked files. pnpm cli check (and anything else that loads the rule layout) runs the .taskless/ layout migration as a side effect. Check git status after running it, and do not git add -A a verification run without looking. The migration is legitimate; it just should not ride along in an unrelated commit.

Worth considering separately, and not proposed here: whether a read-shaped verb should migrate at all, or whether the migration belongs behind an explicit command with the read paths reporting "this layout is out of date, run X" instead. That is a larger behavioural question than the documentation note.

Notes

Found while implementing #179. Not a blocker for it; the migration was reverted before committing.