debito 7: la cadenza del libro e' ORARIA — docstring riscritto, tre fonti tenute d'accordo da un test

Il docstring di book_execute.py prescriveva «ogni ~230 minuti» mentre il cron gira ogni ora
(47 * * * *). Era il docstring a sbagliare: sulla riga 4h BTC raddoppia gli scatti del
disaster-SL rotolante (r0823_sl_anchor.py), e chi avesse "corretto" il cron verso il
docstring avrebbe spostato il libro sulla riga peggiore.

- scripts/live/book_execute.py: CADENZA: ORARIA, la riga di crontab, la ragione (giro
  idempotente, latenza SKH01 <=1h, ri-ancoraggio orario) e il divieto esplicito con la data.
- tests/test_book_cadenza.py (10): deriva e confronta docstring, intestazione di
  cron_book.sh e crontab installata (crontab -l; SALTATO se illeggibile, non verde);
  parser a 5 campi solo per cadenze regolari; 60 < 230 < 240; minuto != :00.
- docs: CLAUDE.md §5.7 chiuso, §13 conteggio 842; memoria 40; diario 02/09b.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RziUCB336YPUUyDJ29x4Ke

docs/diary/2026-09-02b-debito-7-cadenza-docstring.md

@@ -0,0 +1,45 @@
+# 2026-09-02 — Debito 7: il docstring diceva 230 minuti, il cron gira ogni ora
+
+*Scritto il 2026-09-02 alle 14:45Z. Cadenza misurata dal log (`r0823_sl_anchor.py`: 1.443 giri in
+1.442 ore) e dalla crontab installata, letta dal test.*
+
+## Il difetto
+
+| fonte | cosa diceva | dal |
+|---|---|---|
+| `scripts/live/book_execute.py`, docstring | «va lanciato ogni ~230 minuti» | 20/06 |
+| `scripts/cron_book.sh`, intestazione | cadenza ORARIA, `47 * * * *` | 25/08 (prima `:07`, sempre orario) |
+| crontab della VPS | `47 * * * *` | 25/08 |
+
+Era il **docstring** a sbagliare. E non era una svista innocua: sulla riga 4h (la più vicina ai 230
+minuti) BTC **raddoppia** gli scatti del disaster-SL rotolante (2 contro 1; a 24h ETH arriva a 5, con
+2 in 30 giorni). Il rischio era un lettore diligente che "allineasse" il cron al docstring.
+
+## La riparazione
+
+1. **Docstring riscritto**: `CADENZA: ORARIA`, la riga di crontab citata, la ragione (giro
+   idempotente → girare più fitto della griglia non costa ordini; latenza ≤1h sugli ingressi/uscite
+   software di SKH01; ri-ancoraggio orario del rotolante) e il divieto esplicito, con la data.
+2. **`tests/test_book_cadenza.py`, 10 test.** P1: non ridichiara «60 minuti», **deriva** le tre
+   fonti e le confronta fra loro:
+   - il docstring non contiene più «ogni ~230» e dichiara ORARIA;
+   - la riga di crontab citata nel docstring è quella dichiarata in `cron_book.sh`;
+   - la riga dichiarata è oraria (parser a 5 campi, solo casi regolari, rifiuta il resto),
+     sotto i 230 della griglia e lontana dai 240 della riga peggiore, e fuori dal minuto `:00`;
+   - **la crontab installata** (`crontab -l`) coincide con la dichiarata. Dove la crontab non è
+     leggibile il test è **saltato**, non verde (P5). Sulla VPS oggi gira e passa.
+
+## Numeri
+
+| | |
+|---|---|
+| test nuovi | 10, tutti verdi; suite dei moduli che toccano `book_execute`: 231 verdi |
+| cadenza dichiarata / installata | 60 min / 60 min |
+| griglia SKH01 | 230 min (la riga da non usare) |
+| riga peggiore misurata | 240 min (BTC 2 scatti contro 1) |
+
+## Cosa NON ho fatto
+
+- Non ho toccato il cron né `cron_book.sh`: la configurazione che gira era quella giusta.
+- Non ho aggiunto un sorvegliante a runtime sulla cadenza (contare i giri per ora nel log): il
+  giornale già stampa «giri mancanti» ogni giorno, e il test copre la deriva di configurazione.

docs/memory/40-produzione-e-deploy.md

@@ -915,6 +915,23 @@ Sulle 4 finestre osservate 3 sono rientrate entro l'ora → il `:47` ne avrebbe
 **Se al prossimo martedì il `:47` becca comunque la manutenzione, la previsione è sbagliata** e lo
 slot non è quello descritto in `venue_probe.RELEASE_*`: rileggerlo prima di spostare ancora.
 
+### La cadenza è ORARIA, e ora lo dicono tutte e tre le fonti (debito §5.7, chiuso il 2026-09-02)
+
+Il docstring di `book_execute.py` prescriveva «ogni ~230 minuti» (la griglia di SKH01) mentre il cron
+gira ogni ora. Non era cosmetico: `r0823_sl_anchor.py` misura che l'accumulo di scatti del disaster-SL
+rotolante è funzione della **cadenza del cron** (1h: BTC 0 / ETH 1 in 7-8 anni · 4h: BTC 2 · 24h: ETH 5
+con 2 in 30 giorni), quindi chi avesse "corretto" il cron verso il docstring avrebbe spostato il libro
+sulla riga peggiore. La riparazione è il docstring stesso — cadenza ORARIA, la ragione (giro
+idempotente: girare più fitto della griglia non costa ordini, e compra latenza ≤1h per gli
+ingressi/uscite software di SKH01 e un ri-ancoraggio orario del rotolante) e il divieto scritto —
+più `tests/test_book_cadenza.py`, che **deriva** (P1) le tre dichiarazioni e le confronta: la riga
+citata nel docstring, quella dichiarata nell'intestazione di `cron_book.sh` (`47 * * * *`) e la
+crontab **installata** (`crontab -l`; se non è leggibile il test è SALTATO, non verde — P5). Il
+parser accetta solo espressioni regolari e rifiuta il resto. Vincolo del minuto tondo verificato
+(≠ `:00`). La regola generale è la stessa del `:47`: **una cadenza si difende nella sua ragione, e
+un commento che dichiara una cadenza diversa da quella che gira si paga quando qualcuno lo "corregge"
+nel verso sbagliato.**
+
 ### Cosa resta scoperto
 
 1. **La sonda dice di chi è il guasto, non lo aggira.** Col gateway giù il libro continua ad