merge: dev6 → master — pacing weekly cumulative/debito-aware (bridge espone debt, finestra adattiva) + guida C-09/S-07 prompt 7 lingue

Author: leopu00

.launcher/sentinel-bridge.py

@@ -998,7 +998,12 @@ def _imp(name):
             cfg = None
         wreset_dt = datetime.fromtimestamp(wreset_unix, tz=timezone.utc)
         wah = wht.active_hours_in_range(now_dt, wreset_dt, cfg)
-        return wp.weekly_pace_assessment(str(DATA_JSONL), now_ts, wrem, wah)
+        # Ore attive dell'INTERO ciclo (per il debito cumulativo, 2026-06-28):
+        # il ciclo weekly e' di 7 giorni che terminano al reset → start = reset-7d.
+        # Cosi' weekly_pace puo' calcolare ideal_used e debt_pct (saldo vs retta).
+        wtot = wht.active_hours_in_range(wreset_dt - timedelta(days=7), wreset_dt, cfg)
+        return wp.weekly_pace_assessment(str(DATA_JSONL), now_ts, wrem, wah,
+                                         weekly_total_active_hours=wtot)
     except Exception:
         return None
 
@@ -1553,6 +1558,14 @@ def main():
                         f" ratio={weekly_pace['ratio']}x"
                         + (f" early_lockout={el}h" if el else "")
                     )
+                    # debt (2026-06-28): saldo cumulativo vs retta ideale. >0 =
+                    # speso troppo presto (front-load) → in debito la Sentinella
+                    # (S-07) usa tolleranza 1.0x e scala il freno anche sul debito,
+                    # non solo sul runway. Espone debt anche quando kind=ALLINEATO
+                    # (e' il caso che il rate da solo mascherava).
+                    dbt = weekly_pace.get("debt_pct")
+                    if isinstance(dbt, (int, float)):
+                        weekly_pace_field += f" debt={dbt:+.0f}pp"
                     # burn_mode (duale di early_lockout): SOTTO-PACE + vicino al
                     # reset + spreco alto → la Sentinella deve consigliare di
                     # SATURARE, non spalmare. Espone proiezione + spreco previsto.

agents/capitano/capitano.de.md

@@ -189,6 +189,7 @@ Numeri di riferimento (NON più il vecchio modello 24/7 del vps1-run-postmortem)
 - **NON** esiste una soglia di livello assoluta (tipo "frena a weekly 75/92%") — incaglierebbe a metà settimana, l'opposto dell'obiettivo. `weekly_remaining_pct` da solo è **awareness**, non un trigger.
 - Se la Sentinella segnala **SOPRA-PACE** (`vel_weekly` > 1.2× `sustainable`, con lockout anticipato) → **throttle-to-pace** per spalmare + ferma SOLO i NUOVI spawn finché rientri; se il throttle satura, **KILL** un worker (C-12). **Mai** freeze duro per il solo livello.
   - **Scala il FRENO al RUNWAY (P3 2026-06-13), non un freeze blanket.** L'intensità del throttle è proporzionale a quanto sei sopra-pace **e** a quanto runway resta: `early_lockout_h` grande + reset lontano → freno **leggero** (hai margine, basta spalmare); `early_lockout_h` piccolo + reset vicino → freno deciso. Con `weekly_remaining` ALTO (o `monthly_remaining_pct` alto su Kimi) un **freeze duro è sbagliato**: incaglia budget che poi sprechi. Il freeze totale si giustifica solo a ridosso del 100% **reale**, mai sul solo rate con runway abbondante.
+  - **Scala il freno anche sul DEBITO, non solo sul runway (2026-06-28).** Il `early_lockout_h` grande può ingannare: se hai **front-loadato** (la Sentinella ti gira ` debt=+Npp` alto, es. `+17pp`), il runway lungo è **illusorio** — quel budget è già stato speso, te ne resta meno per i giorni dopo. Quindi: con **debito alto** (`debt`≥+8pp) NON applicare il freno "leggero" da runway ampio (l'errore del boot 2026-06-28: `early_lockout=126h` → throttle 300s timido → il debito non rientrava); **frena in proporzione al DEBITO** (ladder più alta) finché il `debt` rientra verso 0, anche se `ratio` è solo ~1.0–1.2 e il reset è lontano. È il complemento del runway-scaling, non lo sostituisce: runway ampio **e** debito ~0 → freno leggero; runway ampio **ma** debito alto → freno deciso (recuperi il saldo). Il `debt`≥0 in pari/negativo = nessun recupero da fare.
   - **`burst_transient=True` → NON frenare duro, fai recuperare (P3).** Se `weekly_pace.burst_transient` è True, il SOPRA-PACE è un **picco PASSATO che sta svanendo** (rate dell'ultima ~0.5h < 40% della media 2h): la media 2h è ancora gonfia ma il team ha **già** rallentato. Allenta il throttle e fai rientrare in fretta invece di frenare su un burst finito (era la causa dell'**over-brake + recovery lento ~2h**: il `vel_weekly` a 2h trascinava il picco). Frena duro SOLO su SOPRA-PACE **sostenuto** (`burst_transient=False`).
 - Se sei **sotto-pace** (`vel_weekly` < `sustainable`, hai budget) → puoi **accelerare/spawnare**, SOPRATTUTTO a fine settimana, per non lasciare budget sul tavolo.
 - **BURN-MODE = il DUALE del SOPRA-PACE (trigger QUANTIFICATO, non più solo "accelera a fine settimana").** Se la Sentinella ti gira **`weekly_pace.burn_mode`** (= SOTTO-PACE **+ reset vicino** + spreco previsto alto — riga tick `BURN-MODE proj_final=X% spreco=Y%`) → **SATURA**: scala su worker sui colli di bottiglia e **togli ogni throttle weekly** finché `projected_final_pct` risale verso ~100%. È l'opposto della riga sopra (SOPRA-PACE): lì freni per non fare lockout anticipato, qui **acceleri per non sprecare `wasted_pct`** del budget poco prima del reset. Il gate "reset vicino" è ciò che distingue **Kimi** (reset a ore → `burn_mode` ON → satura) da **Codex** (reset a giorni → resta SOTTO-PACE **senza** `burn_mode` → ramp graduale, **NON** saturare: ha tempo di recuperare). Mai confondere i due: saturare un team con 5 giorni davanti è esattamente l'over-burn che il SOPRA-PACE poi punisce.