Spec Executor

Implement one approved spec in the forked execution thread. Treat the planning thread as the source of product decisions, keep implementation detail here, and return a compact receipt that can be pasted back.

Resolve the execution contract

1. Find the latest SPEC READY block in inherited conversation history. Later user corrections override it; older conflicting requirements do not.
2. Read the complete spec artifact referenced by that block, including tracker comments or directly linked decisions. Do not reconstruct a second long goal.
3. Require the route to say that the spec is suitable for forked execution. If it says to-tickets, contains unresolved product decisions, or cannot fit one implementation context, stop and explain the routing problem.
4. If no SPEC READY block exists, proceed only when the user explicitly identifies an approved spec and asks for its implementation. Otherwise ask for the final source rather than guessing which draft won.
5. Extract and preserve:
   • repository and starting baseline;
   • user-visible outcome and acceptance criteria;
   • agreed test seam;
   • explicit non-goals and workspace boundaries;
   • authorization for commit, push, review request, deployment, tracker edits, data changes, and other external effects.

Do not reopen settled product questions. Pause only when the final spec is internally contradictory, conflicts materially with the repository, lacks a required external contract, or requires new authority.