Document rolling captain teams

This commit is contained in:
2026-06-12 19:09:02 +02:00
parent 231dce8875
commit a4cc251c68

View File

@@ -15,6 +15,8 @@ a task is complex. The default is still one agent executing one task from
- Use stronger models only where they change the outcome.
- Keep each implementation slice measurable, validated, committed, and pushed.
- Avoid merge conflicts by giving every agent a disjoint task and file scope.
- Keep teams rolling: when one team finishes, integrate or park its result and
start the next disjoint team without waiting for every other team to finish.
## Roles
@@ -55,13 +57,16 @@ example:
- dependency cleanup
- test/hardening work
The captain owns implementation for its assigned task group. The captain turns
one task-group objective into smaller disjoint subtasks, spawns or requests
workers when useful, reviews their changes, runs focused validation when cheap,
and returns an integration-ready result. If nested subagents are available, the
captain may spawn workers. If nested subagents are not available in the current
surface, the captain returns a worker plan and the director performs the
second-level spawns without taking over implementation.
The captain owns implementation for its assigned task group. A team should be a
captain plus multiple workers when the work can be split into disjoint files.
The captain turns one task-group objective, or a small coherent run of adjacent
task rows, into smaller disjoint subtasks, spawns or requests workers when
useful, reviews their changes, runs focused validation when cheap, and returns
an integration-ready result. If nested subagents are available, the captain may
spawn workers and continue through the next compatible subtask after each worker
returns. If nested subagents are not available in the current surface, the
captain returns a worker plan and the director performs the second-level spawns
without taking over implementation.
The captain must not edit broad shared files unless assigned. The captain must
not rewrite the task tracker or roadmap except for a requested status note.
@@ -111,38 +116,47 @@ has requested `gpt-5.4` captains, so use that override for captains.
- Prefer the smallest number of teams that keeps disjoint work moving. Multiple
captains are appropriate when task rows have non-overlapping write scopes and
can validate independently. Avoid many agents in one file family.
- Do not synchronize all teams at a barrier unless validation or merge risk
requires it. Use rolling integration: wait for whichever team finishes first,
process that result, then immediately start another disjoint team if ready
work remains.
## Delegation Flow
1. Director picks one or more `Ready` tasks from
1. Director picks two or more `Ready` tasks from
`docs/modernization/tasks.md` with disjoint write scopes.
2. Director assigns each independent task group to a `gpt-5.4` captain.
3. Captains implement directly or coordinate workers/explorers for disjoint
subtasks.
subtasks, and may continue through a coherent sequence of adjacent tasks
within the assigned scope.
4. Captains run focused validation when cheap and return changed files,
validation, blockers, and integration notes.
5. Director reviews for scope conflicts and integrates returned changes.
6. Director runs the listed validation command or the quiet checkpoint wrapper.
5. Director waits for whichever team finishes first, reviews for scope
conflicts, integrates returned changes, and starts the next disjoint team
while other teams keep running.
6. Director runs the listed validation command or the quiet checkpoint wrapper
for each integrated slice.
7. Director updates `tasks.md`, `debt.md`, and `roadmap.md` if tasks moved.
8. Director commits and pushes the verified slice.
8. Director commits and pushes verified slices incrementally.
## Director Prompt Template For A Captain
```text
You are the gpt-5.4 team captain for the <group> task group in PanoPainter.
Task source: docs/modernization/tasks.md task <TASK-ID>.
Task source: docs/modernization/tasks.md task(s) <TASK-ID-LIST>.
Debt ids: <DEBT-LIST>.
Assigned scope: <FILES/DIRS>.
Validation: <COMMANDS>.
Goal: <ONE PARAGRAPH>.
Own this task group through implementation. Split into disjoint worker tasks
only when that is faster or safer than doing the bounded edits yourself. Use
gpt-5.4 only for risky C++ behavior changes. Keep tasks small enough to
validate. Do not edit outside the assigned scope. Other agents may be working
in parallel; do not revert unrelated changes.
Own this task group through implementation. Build a small team of workers for
disjoint subtasks when possible, review their outputs, and keep looping through
the assigned coherent task sequence until the scope is done, blocked, or no
longer safe to continue. Use gpt-5.4 only for risky C++ behavior changes. Keep
tasks small enough to validate. Do not edit outside the assigned scope. Other
agents may be working in parallel; do not revert unrelated changes.
Return:
- recommended worker tasks with model choice and file scope