Files
plm-lottery/docs
davideandClaude Sonnet 5.5 f936d6660c Track every version of a bumped transaction and write the RBF replacement before broadcasting it (B-77, TX-12, TX-13, TX-19, TX-21, DAT-13, DAT-14, DAT-34, DAT-44, DAT-45, DAT-70, DAT-71)
The poller and the reconciler matched current_txid only. If an earlier version of
a bumped transaction confirmed it was never seen, and after 6h the row was abandoned:
a confirmed bet's participant deleted, a sent withdrawal marked failed, a paid payout
rebuilt. bump_fee also broadcast in phase 2 and persisted in phase 3 unconditionally,
so a crash or a `database is locked` in between left a transaction on the network that
the DB did not know, and an abandon or a confirmation in the meantime was overwritten.

- New table pending_transaction_txids (migration a3f5c2d9b7e1; txid unique, index on
  the owning row; existing rows backfilled with current_txid + raw and the txid their
  last bump replaced, raw_hex empty). Written with the row by place_bet,
  request_withdrawal and _trigger_payout; removed with a bet row that a verified
  refusal deletes (DAT-38).
- bump_fee in four phases: read, build and sign, commit the replacement as a candidate
  version, broadcast (verdict of B-76, fanned out when accepted; an explicit refusal
  raises RbfError and leaves the row), then switch the row over with
  `UPDATE ... WHERE status='pending' AND current_txid=<replaced>`. Zero rows matched is
  a logged conflict: nothing is overwritten and the candidate stays recorded. An
  uncertain broadcast adopts the replacement. A retry rebuilds the same candidate
  without tripping the unique txid.
- poll_once and reconcile_once look for every txid of a row. When the version found is
  not the current one, broadcast.adopt_version makes it current (raw tx included) and
  retargets spent_txid, bet_txid, withdrawals.txid and payout_txid as a bump does,
  before the confirmation handler runs. _release_inputs frees inputs claimed by any
  version of the row.
- RbfBumper takes the listener as `network`.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
2026-10-14 14:46:43 +02:00
..

Documentazione di PLM Lottery

Questa cartella è la fonte di verità del progetto: si lavora docs-first (prima si scrive o si modifica la documentazione, poi il codice) e ogni informazione ha un solo proprietario (SSOT). Questo file è l'indice: da qui si raggiunge tutto il resto.

I tre principi

  1. Docs-first. Nessuna modifica di comportamento parte dal codice. Si modifica il requisito (o si scrive l'ADR, se è una scelta nuova), poi si implementa, poi si testa. Spec, codice e test entrano nello stesso commit.
  2. SSOT — un solo proprietario per ogni informazione. Il perché di una scelta sta in un ADR; il cosa verificabile in un requisito (PREFISSO-NN) del documento di dominio; il come nel codice; la cronologia dei difetti in storico-bug.md. Gli altri documenti rimandano all'ID, non ripetono il testo. Se due documenti dicono cose diverse, vince la specifica e si corregge l'altro.
  3. Un ADR per ogni funzionalità. Ogni funzionalità nuova inizia con un ADR in adr/ (modello: adr/TEMPLATE.md) che registra contesto, decisione, alternative scartate e conseguenze, e ne elenca i requisiti.

Dove si trova cosa

Domanda Dove
Perché è fatto così? Quali alternative sono state scartate? adr/ — indice per area e tabella funzionalità → ADR
Cosa deve fare esattamente il software? I documenti di dominio qui sotto (requisiti con ID stabile)
Quali limiti abbiamo accettato? limiti-noti.md (LIM-nn)
Che bug sono stati trovati/corretti? Quali restano aperti? storico-bug.md; i soli aperti in ../BUGS.md
In che ordine si implementano le correzioni aperte? piano-correzioni.md
Come si modifica la documentazione/il codice? processo-di-modifica.md
Come si installa, si avvia, si usa? Guide operative qui sotto

Specifica (documenti di dominio)

Punto d'ingresso narrativo: come-funziona.md.

Documento Prefisso Contenuto
registrazione-e-depositi.md REG, DEP Account, indirizzi, depositi, saldo
scommesse-e-prelievi.md BET, WDR Scommesse e prelievi
ciclo-di-vita-del-round.md RND Apertura, chiusura, estrazione, pagamento
transazioni-e-riconciliazione.md TX Ciclo di vita delle transazioni, RBF, riconciliazione
connessione-electrum.md ELC Accesso alla rete PLM e difese
architettura.md ARC Struttura del codice, processi, frontend, test
modello-dati.md DAT Tabelle, campi, stati, vincoli
api.md API Endpoint, risposte, codici di errore
sicurezza.md SEC Fiducia, chiavi, autenticazione, limiti sui tentativi
audit-log.md AUD Catalogo degli eventi di audit
operativita.md OPS Backup, riavvii, incidenti

Decisioni, limiti, storia

Documento Prefisso Contenuto
adr/ ADR Una decisione di progetto per file (53 al momento)
limiti-noti.md LIM Limiti accettati consapevolmente
storico-bug.md B-nn Tutti i bug trovati e corretti
piano-correzioni.md — Ordine di implementazione delle correzioni aperte

Guide operative (senza requisiti)

setup.md · running-the-server.md · guida-utente.md · guida-admin.md. Si aggiornano quando la specifica cambia qualcosa di visibile.

Lingua

La documentazione di docs/ è in italiano, per scelta esplicita; tutto il resto del repository (codice, commenti, commit, CLAUDE.md, BUGS.md) è in inglese.