- Ya
- 7 Agosti 2026, 01:13 UTC
- Mwandishi
- Kamo
- Ahadi ya
- 5dbfd80
Adds com.kamo.z.shared.commission: an append-only signed ledger, a per-member balance row that exists purely to serialize concurrent withdrawals, the Commission Processor batch/line-item model, and the per-org Stripe Connect payout entities. Three decisions worth keeping: - The ledger is append-only and enforces it in Java (@PreUpdate/@PreRemove throw). @Column(updatable=false) only makes Hibernate omit a column from the UPDATE, it does not make the write fail, so a stale correction would look like it succeeded. Corrections are reversing rows. - Available vs pending is a query over EFFECTIVE_AT, not a state machine. A commission issued today with next month's maturity moves to available on its own, so no sweep exists that could fail and strand money as pending. - COMMISSION_MEMBER_BALANCE is redundant with the ledger by construction. It exists because a balance is an aggregate and SELECT FOR UPDATE cannot lock an aggregate; without one row to take PESSIMISTIC_WRITE on, two concurrent withdrawals both pass their own sufficiency check. Money is NUMERIC(19,4) throughout, org ids are plain INT8 columns rather than associations so financial records outlive member churn, and ORG_ID is duplicated onto child rows so no single-row fetch can read cross-tenant. Also adds three rights (187-189) for the finance surface. They are split so separation of duties is expressible: with one right the person who issues a commission could also release the payout and cancel the hold that exists to catch them. serviceType is null deliberately - a new ServiceType would group them automatically but render them in no editor at all, since app sections only appear when the org has that app enabled. Schema applied via KamoInitializer; all nine tables verified present in prod with ALL privileges for the kamo app user.