Added a genuine audit step to HOUSEKEEPING-SWEEP.php: after every run, parses systems/commands/.htaccess's own FilesMatch allowlist live (not a third hardcoded copy) and confirms every listed command still exists on disk. If anything is missing, writes an ALERT-tagged line to MAINTENANCE-LOG.md plus a dedicated timestamped alert file in backend/tmp/ (does NOT attempt an HTTP call to inbox-api.php for the alert -- that would hit the confirmed LiteSpeed self-loopback block, K107, failing silently in exactly the scenario where the alert matters most). MY OWN TESTING MISTAKE, disclosed honestly: to verify the alert actually fires, renamed ML.php to ML.php.audittest_moved, ran the sweep, then tried to rename it back. Did not anticipate that stripping the .php extension during the test also stripped CLEAN.php's own versioned-docblock protection (that check requires the extension to literally be 'php' before it even looks at file content) -- CLEAN.php's real run genuinely trashed the renamed test file within the same script execution, before my own restore step ran, so that rename() call silently failed (return value not checked) against a file that no longer existed at the expected path. Found it in backups/40-server/trash/archive/ (already auto-archived, worth separately noting since it should not have crossed the 3-day threshold instantly -- flagging as a possible trash_lifecycle age-calculation issue, NOT fixed this pass, out of time budget) and restored it, confirmed functional via a real request. VERIFIED THE AUDIT ITSELF WORKS CORRECTLY throughout this: it correctly reported the missing command (ok:false) during the incident, and correctly reported ok:true again on the very next run after ML.php was restored -- ironically, my own testing mistake became a real, unplanned proof that the audit layer catches genuine problems, not just a synthetic test.