session-loop-multi-wt

Multi-WT Session Loop Extension

This file contains the multi-worktree steps referenced by session-loop.md. Read this only when auto_assign = true in config.toml. When auto_assign is false (default) or absent, these steps do not apply.

These steps interleave with the main session-loop procedure:

• Steps 1b–1d run between Step 1 (fetch tasks) and Step 2 (plan implementation)
• Step 5-wt replaces the conventional Step 5 (launch Workflow)
• Step 6 multi-WT replaces the conventional Step 6 (process results)
• Steps 9–10 run after Step 8 (next session), before session close

Step 1b. Functional grouping + WT assignment plan

Gate check:

handoff_get_config

Read worktree.session_loop.auto_assign. If it is absent or false, skip Steps 1b/1c/1d and continue at Step 2 with the todo tasks fetched in Step 1. Only proceed with the rest of this step when it is explicitly true.

Grouping logic (applied to the todo tasks fetched in Step 1):

1. Dependency chains: tasks connected by dependencies belong to the same group — a WT boundary must never split a dependency edge.
2. File scope overlap: fetch each task's scope_paths via handoff_get_task. Tasks whose scope_paths overlap (same file/dir, or a prefix relationship) belong to the same group. When scope_paths is empty for a task, estimate its file footprint from notes/title instead of leaving it ungrouped.
3. Functional proximity: tasks that clearly belong to the same feature or subsystem (e.g. all "auth", all "api") are grouped together even without a direct dependency or scope overlap — this is a manager (LLM) judgment call, not a mechanical rule.
4. Single-group fallback: if grouping produces a single group, or the total task count is <= MAX_TASKS_PER_SESSION, do not use WTs — fall back to the conventional single-session flow (Step 2 onward) exactly as if auto_assign were false. Multi-WT execution only makes sense when there are genuinely independent, parallelizable groups.