Cron feasibility was already confirmed 08/10/26 (decision id=700) but the actual sweep script and cron entry were never built until now. Built systems/commands/HOUSEKEEPING-SWEEP.php running CLEAN.php (orphan sweep + auto trash-lifecycle, USR369-approved 08/05/26), CLEANBACKUPS.php (rotation + snapshot retention, platform-wide), and GOV-INVENTORY.php, then logs a summary line to MAINTENANCE-LOG.md matching its documented format. Installed a real crontab entry: 0 10 * * 0 (every Sunday, server-local EDT -- confirmed via live date check the server runs EDT not PT, making this 7am PT, a reasonable low-traffic weekly window) /usr/bin/php .../HOUSEKEEPING-SWEEP.php, output appended to backend/tmp/housekeeping-cron.log. REAL PROBLEMS FOUND AND FIXED DURING THE BUILD, not just assembled from working parts: (1) first version used shell_exec-based subprocess isolation between steps -- 403'd on execution, consistent with WAF-PATTERNS.md's documented pattern of flagging shell-execution-looking function names; rewrote using direct include() after confirming no function-name collisions existed between the three target files. (2) CLEAN.php was being included twice (dry-run then real-run) -- fatal 'Cannot redeclare taskgate_recent_call()', since CLEAN.php declares functions at file scope; removed the dry-run call entirely since a dry-run has no reviewer in unattended automation anyway, real-run only. (3) CLEANBACKUPS.php's system= param is a SCOPE FILTER not a task-gate requirement (unlike CLEAN.php, which needed system=40 to satisfy TASKGATE) -- initially passing it accidentally narrowed a platform-wide sweep down to just Server's own backups (0 actions vs the real 225 actions once fixed). (4) GOV-INVENTORY.php's known HTTP-level 403 (T756, separately logged, still unresolved) does not manifest when include()'d directly rather than requested over HTTP -- it now runs successfully as part of this sweep even though standalone HTTP access to it remains broken. (5) MOST IMPORTANT: cron on this host invokes PHP via /usr/bin/php, which is php-cgi reporting sapi cgi-fcgi, NOT cli as originally assumed -- the script's is_cli detection would have silently treated every real cron run as a web request needing a token, failing auth every single week with nobody watching. Fixed by detecting automation via the absence of $_SERVER['REQUEST_METHOD'] instead (always set for genuine web requests, never set for direct/cron invocation) -- confirmed correct via a live probe of the exact invocation cron uses, then verified the full sweep end-to-end through that exact same invocation path before trusting the crontab install.