bug: implement-batch riporta successo su un batch vuoto per args invalidi, e la guardia anti-duplicazione della first-review dipende da `prNumber` passato dal chiamante

[rucka]

Problema

Due difetti in .claude/workflows/implement-batch.js, entrambi osservati guidando il batch #277/#230/#281/#236/#234/#279 (PR #386–#391).

1. Un batch che non guida nulla riporta successo

args veniva normalizzato così: se stringa, JSON.parse in try/catch; al catch, _args = undefined; poi const STORIES = _args?.stories ?? [].

Chiamandolo con args: "#234 #236 #281 …" — la forma suggerita dalla riga di invocazione della skill, che interpola verbatim gli argomenti ricevuti — il parse falliva, STORIES diventava [], e il run usciva in ~30 ms con zero agent restituendo:

{ "contracts": [], "batch": [], "note": "PRs are ready-for-merge or escalated. Merge is the human gate…" }

Cioè la forma di un batch completato con successo, indistinguibile da un run reale in cui tutte le storie sono fallite. Il primo lancio del batch è andato a vuoto senza alcun segnale.

2. La guardia anti-duplicazione della first-review dipendeva dalla contabilità del chiamante

Il continuation probe (#373) era dentro if (resuming), dove resuming = Number.isInteger(story.prNumber) — quindi girava solo se il chiamante aveva passato prNumber nell'oggetto storia.

Un resume via Workflow({resumeFromRunId}) rieseguisce gli agent implement/PR dalla cache con gli stessi args: story.prNumber è assente, resuming è false, il probe non parte, firstReviewPosted resta false e il round-0 posta un'altra first-review su una PR che ne ha già una.

Osservato tre volte sulla stessa storia (#234, PR #390) attraverso tre cicli pausa/ripresa: quella storia è stata rivista da zero ogni volta invece di avanzare nei round di fix, ed è finita la meno progredita del batch — con 4 Major ancora aperti quando le altre erano a zero.

Impatto

• (1) fa perdere un lancio senza accorgersene; un orchestratore che riceve batch: [] non ha modo di distinguere "input sbagliato" da "batch vuoto legittimo".
• (2) spreca un round di review opus/xhigh per storia per ciclo di ripresa, e fa regredire il progresso della storia.

Fix atteso

1. Validare l'input rumorosamente: lanciare su stringa non-JSON, args assente, oggetto senza stories, o storia priva di id/title/branch — con un messaggio che dica la forma richiesta e perché title/branch non sono derivabili (il sandbox non ha accesso a gh/filesystem). Una lista esplicitamente vuota resta un no-op legittimo.
2. Legare il probe all'esistenza della PR, non a story.prNumber: un probe sonnet/low per storia per run costa molto meno di una review opus duplicata, e su una storia fresh entrambi i segnali tornano false lasciando il comportamento identico.
3. Rendere il contratto degli argomenti visibile nel meta del workflow, così il chiamante lo legge prima di invocare.

Note

Il difetto (1) non è "il chiamante ha sbagliato": la riga di invocazione della skill interpola gli argomenti ricevuti dentro Workflow({args: …}) senza convertirli, quindi la forma sbagliata è raggiungibile per costruzione.

[rucka]

Risolta su main in 17948065

Merge diretto su richiesta: è un fix al workflow di orchestrazione, serviva operativo subito e non passa dal ciclo PR.

• Difetto 1 — validazione loud. Stringa non-JSON, args assente, oggetto senza stories, o storia priva di id/title/branch ora lanciano, con un messaggio che nomina la forma richiesta e spiega perché title/branch non sono derivabili (il sandbox non ha gh né filesystem). Una lista esplicitamente vuota resta un no-op legittimo: un chiamante che ha calcolato "niente da fare" non sta sbagliando. Accettati anche un array nudo e una stringa JSON; un # iniziale nell'id viene normalizzato, così nessun path di worktree lo porta.
• Difetto 2 — guardia indipendente dal chiamante. Il probe è ora legato all'esistenza della PR, non a story.prNumber. Un probe sonnet/low per storia per run costa molto meno di una review opus/xhigh duplicata, e su una storia fresh entrambi i segnali tornano false: percorso fresh invariato.
• Il contratto degli argomenti è ora in meta.whenToUse, così il chiamante lo legge prima di invocare — è lì che il difetto era raggiungibile per costruzione, perché il wrapper della skill interpola gli argomenti ricevuti verbatim in Workflow({args}).

Verifica: test 46 → 55, tutti verdi. Riprodotto il difetto originale end-to-end prima e dopo: con args: "#234 #236 #281 #230 #277 #279" il workflow ora lancia invece di restituire {batch: []} con la nota di successo.

Una nota di onestà sui test: un'asserzione preesistente è stata invertita deliberatamente. #373 fresh story: no continuation probe runs (fresh path unchanged, AC6) pinnava esattamente il risparmio che ha causato il difetto 2. Il suo intento reale — "il percorso fresh non cambia" — è preservato e ora asserito sull'esito (la first-review viene comunque postata), più un test nuovo che prova che un probe che restituisce spazzatura non può silenziarla (fail-open verso la visibilità).