Coordinate the team that never clocks out.

The local run planner reads seven fields: two agent names, two roles, two tasks, and a handoff note. Validation trims their values and requires all seven to be nonempty. Clearing one field leaves six, so at forty pixels per populated field the bars shrink from two hundred eighty to two hundred forty. A valid form is saved in browser storage and displays two ordered tasks. This is completeness checking, not evidence that either agent is available, that a role was performed, or that sources were checked. The planner does not execute or monitor agents. The interface contains two agent-name fields. Entering the same nonempty name in both still passes the written validator. There are two populated name fields but only one distinct name. At one hundred twenty pixels per name count the bars show two hundred forty and one hundred twenty. The summary still says two ordered tasks and Task two waits for Task one. Those relationships are fixed presentation, not a validated dependency graph. Use different names and inspect the roles when that is your intent, but do not infer uniqueness, scheduling, or live coordination from the ready label. After validation, the download button reads the stored snapshot. If a task field is edited without validating again, that new edit is absent from the downloaded brief. The first bar represents one saved snapshot at one hundred sixty pixels, while zero newly adopted edits keeps the second at zero. An empty current field can fail a later validation while the previously saved snapshot still remains downloadable. This preserves a durable plan but can surprise someone expecting export to read the current form. Inspect the downloaded task text, and remember it is a local planning artifact with no live agent execution attached.