Missions in Strug Central decompose into subtasks. A high-level directive like "ship a new product page" becomes a sequence of concrete steps: scaffold the route, build components, write tests, review accessibility. This decomposition is how we turn ambitious goals into executable work.
But we had a problem. When the orchestrator broke missions into subtasks and enqueued them, those subtasks lost their connection to the parent mission. The mission_id wasn't being passed through the enqueuing logic, so downstream agents had no idea they were working on behalf of a larger mission. Progress tracking broke. Context disappeared. Agents couldn't report back to the right mission when they finished their work.
The fix spans four surfaces: task_queue.py now accepts and preserves mission_id during enqueue operations, the orchestrator passes mission context through when decomposing work, the missions router maintains linkage when creating derivative tasks, and we added a database migration to ensure mission_id is properly tracked in the task_queue table.
This matters because mission decomposition is core to how Strug Central handles complexity. Without proper linkage, we can't answer questions like "which tasks belong to this mission?" or "what's blocking mission completion?" or "which agent is working on which part of the plan?" Mission status becomes unreliable. The Dispatcher can't show accurate progress. Agents can't update mission state when they finish their assigned subtask.
The root cause was simple: we built mission decomposition before we built mission tracking. The orchestrator knew how to break work into pieces, but the task queue didn't know those pieces came from a mission. When we added mission_id to the missions table and built the Dispatcher UI, we never went back and threaded that context through the enqueuing logic.
What's Next
Now that subtasks correctly track their parent mission, we can build features that depend on this relationship. Mission progress bars in the Dispatcher can aggregate completion status from all linked subtasks. The Task Board can filter by mission. Agents can automatically update mission status when the final subtask completes.
We're also planning mission replay capabilities—when a mission partially fails, we want to retry just the failed subtasks rather than restarting the entire mission from scratch. That requires knowing which tasks belong to which mission and what their dependencies are. This fix is the foundation for that work.
Longer term, mission context enables smarter orchestration. If the system knows multiple subtasks come from the same mission, it can prioritize them together, allocate resources more intelligently, and provide better visibility into overall mission health. Mission linkage is infrastructure for more sophisticated planning and execution patterns down the road.