updates from chat

MEMBER-CORRECTIONS-2026-10-21.md

@@ -0,0 +1,49 @@
+# Member-summary dues corrections and payment reversals
+
+Administrators can now open Correct dues beside a member's season dues and
+Reverse incorrect payment beside an unreversed receipt on the member summary.
+The correction dialog prefills the current effective dues total and requires a
+reason. The reversal dialog identifies the member and receipt, requires a reason
+and confirmation, and explains that reversal does not issue a refund.
+
+Successful actions return to the same member summary and preserve paging.
+Totals, balances, correction history and payment status refresh immediately.
+Cancel does not change the ledger. Reversed receipts remain visible with their
+reason and no longer offer a reversal button. Members and archived clubs retain
+their existing read-only behavior.
+
+`classes/MemberSummary.php` adds the two dialogs and the explicit `adjust` and
+`reverse` POST actions. They use the existing CSRF and club-management checks and
+the existing modal validation/error handling. The summary remains free of inline
+editing fields.
+
+`classes/LedgerService.php` adds optional membership constraints to corrections
+and reversals. These are checked against the locked dues record inside each
+transaction, before writes or idempotent success. Forged requests cannot correct
+another member's dues or reverse another member's receipt, including within the
+same club. Existing club-page callers remain compatible.
+
+Corrections still cannot reduce dues below payments received. Both operations
+append records and require a successful audit write in the same transaction.
+Duplicate request keys remain idempotent; already-reversed payments reject a new
+reversal request. No financial history is deleted and no external payment or
+refund is initiated. No schema change, dependency or migration is required.
+
+Regression coverage includes prefilled correction values, successful browser
+correction/reversal, cancellation, updated totals, removal of reversal buttons,
+wrong-member and foreign-club requests, member access restrictions, correction
+limits, duplicate requests, audit rollback and preserved reasons. The history
+paging test counts actual payment-table records separately from hidden dialog
+context, which now also identifies the selected receipt.
+
+Validation passed 186 targeted checks: 35 member-action HTTP, 22 member-summary
+HTTP, 28 tenant browser, 33 general browser, 41 security/capacity service,
+11 paging/export HTTP and 16 deployment tooling checks. Source validation passed
+for 67 PHP files, 58 JavaScript files and 39 XSL stylesheets.
+
+The two application files were deployed to development and hash verified. A
+protected temporary runtime probe confirmed the membership-scoped correction
+and reversal methods, then was removed. Prior files were saved under
+`.tools/deployment-backups/member-corrections-7f0ba3ed47d24a3789f30bc116f8a8a8`.
+No development database records were changed. Tests used disposable data with
+external email disabled; the isolated database server was stopped after cleanup.