Document the 2026-09-28 specification review and its fixes (B-73..B-97)

Fourth full audit, run against the docs/ specification instead of the code
alone, found logical flaws rooted in PLM's small hashrate (~22 TH/s): a
minable draw, no distinction between "never broadcast" and "unknown if
broadcast", an Electrum client that degrades as the pool address's history
grows, and 1-confirmation deposits on a chain where a reorg is rentable.

The spec now describes the target behaviour for every finding, marked
*Stato:* da implementare (B-nn) with an *Oggi:* line for what the code does
now; docs/piano-correzioni.md records the design decisions and the
implementation order. No code changed — this is spec-only, per B-nn
convention when a bug reveals the spec itself was incomplete.

Also documents, as an accepted-but-open risk (LIM-24), that the optional
jackpot cap (max_round_pool_sats) isn't tied to the cost of a 51% attack —
deferred, not decided.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

docs/processo-di-modifica.md

@@ -11,8 +11,9 @@ Ogni regola verificabile ha un **identificativo stabile**, nella forma
 seguito dai riferimenti all'implementazione e, dove esistono, ai test:
 
 ```markdown
-- **[RND-11]** Alla scadenza il round passa subito a `closing`: da quel momento
-  nessuna scommessa è più accettata.
+- **[RND-11]** Al primo passo dello scheduler successivo alla scadenza il round
+  passa a `closing`; le scommesse sono però rifiutate già dall'istante della
+  scadenza ([BET-04]).
   *Codice:* `app/rounds/scheduler.py:RoundScheduler._tick` ·
   *Test:* `tests/unit/test_scheduler.py`
 ```
@@ -28,6 +29,41 @@ Regole della convenzione:
   mai numeri di riga (cambiano a ogni modifica).
 - Il testo descrittivo che non contiene regole (introduzioni, spiegazioni,
   esempi) non ha identificativo.
+- **Un solo proprietario per regola.** Ogni regola ha l'identificativo in un
+  solo documento; gli altri documenti che la citano rimandano a quell'ID
+  invece di ripeterla con un ID proprio. Il documento di dominio (round,
+  scommesse, transazioni…) è proprietario del comportamento, `DAT` dello
+  schema, `SEC` delle soglie di sicurezza.
+- **Niente formulazioni vaghe nelle regole.** "Circa", "normalmente", "prima o
+  poi" non compaiono in un requisito: si scrive la condizione esatta, con il
+  nome della costante.
+
+### Requisiti non ancora implementati
+
+La specifica può essere più avanti del codice: è il caso normale fra il passo 1
+e il passo 3 del ciclo qui sotto. Un requisito che il codice non soddisfa
+ancora porta, subito dopo i riferimenti, una riga di stato e una che dice cosa
+fa il codice oggi:
+
+```markdown
+- **[RND-33]** L'altezza del blocco di estrazione è fissata all'ingresso in
+  `drawing` come `tip_at_close + 1` e non cambia più.
+  *Codice:* `app/rounds/scheduler.py:RoundScheduler._close_and_draw` ·
+  *Test:* —
+  *Stato:* da implementare (B-73) · *Oggi:* si usa la punta vista al primo
+  controllo utile, che può essere un blocco successivo.
+```
+
+- *Codice* indica dove andrà l'implementazione (il file o la funzione
+  esistente più vicina); *Test* è `—` finché il test non esiste.
+- Il B-nn rimanda alla voce di [BUGS.md](../BUGS.md) che descrive la
+  correzione; l'ordine di implementazione è in
+  [piano-correzioni.md](piano-correzioni.md).
+- Quando il codice viene implementato, nello stesso commit si tolgono le righe
+  *Stato* e *Oggi* e si completano *Codice* e *Test*. `git grep "da
+  implementare"` elenca in ogni momento tutto ciò che manca.
+- Un requisito modificato (non nuovo) mantiene il suo identificativo: il testo
+  descrive il comportamento atteso, *Oggi* quello attuale.
 
 ### Prefissi