harness-planninglisted

# harness-planning Write a task-by-task TDD plan after the design is approved. - Each task names files, interfaces, failing test, expected failure, minimal code, green test, and verification command. - Order steps by dependency and make every handoff independently checkable. - Mark sensitive paths, rollback, blast radius, and required model route. - Avoid placeholders, giant refactors, and tests that merely repeat prose. Before naming test paths, inspect existing tests, runner configuration and project instructions. Follow any established test layout for new tests; never move existing tests just to apply a default. If none exists, put all new test files under one root `tests/` directory, grouped by domain or feature, with fixtures there too. Scope runner configuration in the first task that adds tests so it discovers `tests/`. An empty repository does not override an explicit project convention. For a Pi session that uses `task_pipeline_version: 1`, decompose plan tasks so each implementation can run in an isolated worktree. Declare complete `depends_on`, `scope_paths`, `locked_tests[].path`, and `fixture_paths`; shared or ancestor paths make tasks conflict, so use dependencies when they cannot run safely together. Keep aggregate verification, harvest, final review, and shipping with the global parent rather than inventing a parent-only implementation task. This Pi-specific decomposition does not change planning or dispatch for other hosts. Within this Pi task pipeline: