Replace flowchart/ with a traceable specification in docs/
The two Mermaid diagrams under flowchart/ described the intended flow but had drifted from the code and carried no link back to it. docs/ now holds the specification instead: 15 Italian documents (flows, architecture, data model, API, security, audit log, operations, decisions and limits, bug history) with 472 numbered requirements, each pointing at the function that implements it and the test that covers it. docs/processo-di-modifica.md defines the ID convention and the spec -> code -> test change workflow, and CLAUDE.md now names docs/ as authoritative. Writing the spec from the code also corrected stale claims in CLAUDE.md (B-41's get_history check, BUGS.md still tracking B-71/B-72, Cache-Control scope, the error contract's bare-string exceptions) and in the operator guides (payouts do retry, only `drawing` fails to resume, rounds do not open without fee_address). The B-70 doc test now pins the prose in docs/scommesse-e-prelievi.md instead of the deleted diagram. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
1 parent
526a649c8b
commit
61efbb0e37
29 files changed
+6964
-310
No files matched your search
+17
-8
@@ -2,6 +2,8 @@
|
||||
|
||||
Come gestire la configurazione operativa di PLM Lottery. Presuppone che il
|
||||
server sia già avviato — vedi [running-the-server.md](running-the-server.md).
|
||||
Per il funzionamento interno (stati del round, riconciliazione delle
|
||||
transazioni, connessione Electrum) vedi [come-funziona.md](come-funziona.md).
|
||||
|
||||
## Accesso
|
||||
|
||||
@@ -23,7 +25,8 @@ sola schermata di login.
|
||||
- **Utenti** — elenco utenti, saldo, accesso alla chiave privata, reset password
|
||||
- **Round** — storico round: stato, vincitore, importi, txid di payout
|
||||
- **Transazioni pendenti** — bet/payout/prelievi non ancora confermati, candidati al fee-bump RBF
|
||||
- **Audit log** — eventi registrati dal sistema (config cambiata, bet, payout, accessi a chiavi private, ecc.)
|
||||
- **Audit log** — eventi registrati dal sistema (config cambiata, bet, payout, accessi a chiavi private, ecc.; catalogo completo in [audit-log.md](audit-log.md))
|
||||
- **Bug report** — segnalazioni inviate da `/report-bug`, da smistare `open` → `read` → `resolved`
|
||||
|
||||
## Parametri
|
||||
|
||||
@@ -90,8 +93,11 @@ sempre **chi ha originato la transazione**, non il destinatario: per bet e
|
||||
prelievi è l'utente stesso (gli torna un resto più piccolo), per i payout è
|
||||
il pool (il resto che torna all'indirizzo pool si riduce) — la quota del
|
||||
vincitore e quella delle fee, già fissate, non vengono mai toccate. Se non
|
||||
c'è un resto abbastanza grande da assorbire l'aumento, il bump fallisce e
|
||||
resta un intervento manuale (vedi "Limiti noti").
|
||||
c'è un resto abbastanza grande da assorbire l'aumento, il bump fallisce: la
|
||||
transazione resta in attesa finché non conferma da sola o finché il
|
||||
riconciliatore non la abbandona liberandone le monete (vedi
|
||||
[transazioni-e-riconciliazione.md](transazioni-e-riconciliazione.md) e
|
||||
[operativita.md](operativita.md)).
|
||||
|
||||
## Round
|
||||
|
||||
@@ -125,7 +131,7 @@ Eventi a cui vale la pena prestare attenzione:
|
||||
| `pending_tx_abandoned` | Una transazione trasmessa è scomparsa dalla catena e il sistema l'ha dichiarata persa: UTXO liberati, bet rimossa o prelievo segnato `failed`. Se capita spesso, la fee rate configurata è probabilmente troppo bassa. |
|
||||
| `pending_tx_recovered` | Una transazione che si credeva incompleta è invece finita in catena (tipicamente dopo un riavvio a metà invio) e il sistema l'ha ripresa da sé. |
|
||||
| `bug_report_status_changed` | Un admin ha cambiato lo stato di una segnalazione (payload: `report_id`, stato precedente e nuovo). Con un token admin unico e condiviso, questa riga è l'unica traccia di chi tocca le segnalazioni. |
|
||||
| `payout_failed` | Il payout di un round non è partito. Il round resta in `paying_out` e **richiede intervento manuale**: non esiste un retry automatico. Controlla `fee_address`, il saldo dell'indirizzo pool e la connessione Electrum. |
|
||||
| `payout_failed` | Un tentativo di payout di un round non è partito; il campo `reason` dice perché. Il round resta in `paying_out` e lo scheduler **riprova da solo al massimo una volta ogni 60 secondi**. Se l'evento si ripete, controlla `fee_address`, il saldo dell'indirizzo pool e la connessione Electrum (procedure in [operativita.md](operativita.md)). |
|
||||
|
||||
## Alternative all'interfaccia grafica
|
||||
|
||||
@@ -182,11 +188,14 @@ per l'utente: solo un admin col token può farlo.
|
||||
|
||||
- Il token è unico e condiviso: non c'è identità per singolo admin né audit
|
||||
di chi ha cambiato cosa (oltre alla tabella `audit_log` generica).
|
||||
- Nessun rate limiting sugli endpoint admin (né su registrazione/bet/
|
||||
prelievo utente).
|
||||
- Nessun rate limiting sugli endpoint admin, né su bet e prelievo. Solo il
|
||||
login (tentativi falliti) e la registrazione (5 account/ora per IP) sono
|
||||
limitati — vedi [sicurezza.md](sicurezza.md).
|
||||
- Se un payout fallisce (es. Electrum disconnesso, UTXO insufficienti), il
|
||||
round resta bloccato in `paying_out` senza retry automatico — richiede
|
||||
intervento manuale.
|
||||
round resta in `paying_out` e il payout viene ritentato ogni 60 secondi;
|
||||
alcuni motivi però non si risolvono da soli (vedi
|
||||
[operativita.md](operativita.md)).
|
||||
- Elenco completo dei limiti accettati: [decisioni-e-limiti.md](decisioni-e-limiti.md).
|
||||
|
||||
Per l'elenco completo dei gap noti vedi la sezione "Known gaps / TODO" in
|
||||
`CLAUDE.md`.
|
||||
Reference in new issue
Block a user