| name | codestra-gsd-parallel |
| description | Esegue una fase GSD in parallelo distribuendo i piani sui worker Codestra disponibili. Sostituisce gsd-execute-phase quando ci sono worker idle. |
| argument-hint | <phase-number> [plan-ids...] |
| disable-model-invocation | false |
Esegue una fase GSD in parallelo distribuendo i piani sui worker Codestra registrati nell'hub.
Argomenti ricevuti: $ARGUMENTS
Parametri:
- Phase (
$0): numero di fase GSD da eseguire (obbligatorio, es. 03).
- Plan IDs (
$1...$N): piani specifici da distribuire. Opzionale — se omessi, legge tutti i piani dal PLAN.md della fase.
Fase 1 — Prerequisiti
Verifica:
SWARM_HUB_URL nell'env. Se assente, informa utente e suggerisci di usare /gsd-execute-phase standard.- File
.planning/phases/<phase>/PLAN.md esiste. Se assente, suggerisci /gsd-plan-phase $0 prima.
Leggi PLAN.md e identifica i piani disponibili (sezioni con ID tipo 03-01, 03-02, ecc.).
Fase 2 — Scoperta worker
curl -s \
${SWARM_SECRET:+-H "Authorization: Bearer $SWARM_SECRET"} \
"$SWARM_HUB_URL/workers"
Filtra worker con status: "idle". Se nessun worker idle:
- Mostra worker disponibili con loro stato
- Chiedi all'utente: "Nessun worker idle. Eseguire in locale con /gsd-execute-phase? [s/n]"
- Se sì: esegui skill
gsd-execute-phase con $0
- Se no: interrompi
Fase 3 — Assignment
Abbina piani a worker (round-robin se piani > worker):
| Piano | Worker ID | Comando |
|---|
| 03-01 | wkr-abc | /gsd-execute-plan 03 03-01 |
| 03-02 | wkr-xyz | /gsd-execute-plan 03 03-02 |
Se piani > worker disponibili: informa l'utente, chiedi conferma (i piani in eccesso aspetteranno worker liberi).
Fase 4 — Dispatch
Per ogni coppia piano-worker, invia task via messaggio:
curl -s -X POST \
${SWARM_SECRET:+-H "Authorization: Bearer $SWARM_SECRET"} \
-H "Content-Type: application/json" \
-d "{\"from\":\"hub\",\"to\":\"<worker-id>\",\"body\":\"/gsd-execute-plan $0 <plan-id>\"}" \
"$SWARM_HUB_URL/messages"
Mostra tabella dispatch con timestamp invio per ogni piano.
Fase 5 — Monitoraggio
Poll ogni 30 secondi lo stato di tutti i worker assegnati:
curl -s \
${SWARM_SECRET:+-H "Authorization: Bearer $SWARM_SECRET"} \
"$SWARM_HUB_URL/workers"
Mostra aggiornamento stato ad ogni poll:
[HH:MM:SS] Piano 03-01 → wkr-abc: busy (60s)
[HH:MM:SS] Piano 03-02 → wkr-xyz: done ✓
Continua fino a che tutti i worker assegnati sono done o error.
Fase 6 — Risultati
Leggi messaggi di risposta dall'hub:
curl -s \
${SWARM_SECRET:+-H "Authorization: Bearer $SWARM_SECRET"} \
"$SWARM_HUB_URL/messages/hub?unread=true"
Mostra riepilogo finale:
Fase $0 — Esecuzione parallela completata
✓ 03-01 (wkr-abc) — completato in 4m 32s
✓ 03-02 (wkr-xyz) — completato in 3m 18s
✗ 03-03 (wkr-def) — errore: <dettaglio>
Piani riusciti: 2/3
Se ci sono errori: suggerisci /gsd-execute-plan $0 <plan-id> per ri-eseguire i piani falliti.
Note operative
- Dipendenze tra piani: GSD non garantisce ordine in modalità parallela. L'utente è responsabile di distribuire solo piani indipendenti, o specificare
$1...$N esplicitamente.
- Worker lenti: se un worker non risponde entro 10 minuti, mostra warning ma continua monitoring.
- Fallback: se hub non raggiungibile durante monitoring, offri di continuare in locale.
