T-SF0G-start-task-handles-respec-rebase-churn

Status: closed/done · Impact: medium · Complexity: small

Goal

/sdlc:task-work Step 5b shells out to start_task.py, which commits chore(tasks): start <basename> on main (editing the task frontmatter to status: in-progress + last_reviewed) and then rebases the task branch onto main. When Step 5a’s readiness gate fails on first pass and /sdlc:task-define then fixes the spec, the task branch accumulates its own flag needs-definition → flesh out → verify frontmatter commits. Those collide with main’s chore(tasks): start edit of the same frontmatter region, so start_task.py’s git rebase main surfaces a conflict (exit 3) and leaves the worktree in REBASE state. Recovery is manual: abort the rebase, reset the branch to main, and re-apply the spec body as a single commit. Since the churn is frontmatter-only and the desired end-state is deterministic (main’s frontmatter + the branch’s body), start_task.py could detect this case and squash-or---onto instead of surfacing a raw conflict to the operator. Hit on 2026-05-19-engine-review-running-tick-decision (in github.com:sksizer/pumice).

From the originating post-mortem: “start_task.py’s rebase (Step 5b) hit a conflict because the task branch’s own flag-needs-definition → flesh-out → verify spec commits collided with main’s chore(tasks): start edit of the same frontmatter. Recovery required aborting the rebase, resetting the branch to main, and re-applying the table reformat as a single commit. … start_task.py could detect this case (task branch ahead of its own start point with frontmatter-only churn) and squash-or-onto rather than surfacing a raw conflict.”