Three distinct, real bugs found and fixed in FINAL_CLOSE.php during T2532 investigation, all confirmed via direct code reading and live testing, not guessed: 1) NO SHRINK-GUARD on the handoff write -- unlike every other writer of handoff-*.md (CLOSE.php v2.9, file_write_web.php v1.2), this file did a raw unconditional file_put_contents with zero comparison to existing content. This is the exact mechanism behind T-FINALCLOSE-BLANKHANDOFF (previously self-logged as D805 in an earlier session but apparently never actually fixed in code) and behind the incident earlier this same session (D824) where testing this endpoint blanked a real handoff. Fixed: added the same shrink-guard pattern already established platform-wide -- refuses to overwrite with shorter content unless overwrite_confirm=1 is explicitly passed. 2) DATE-FORMAT MISMATCH in the session_decisions query -- compared the sys_db decisions table's date column (stored platform-wide in m/d/y text format, e.g. 08/23/26) against $today in Y-m-d format (e.g. 2026-08-23) -- these string formats can never match, so this query silently returned zero rows on every call regardless of real data, making the endpoint's own decision-count output permanently meaningless. Fixed: switched to DATE(created_at)='{$today}', matching the pattern the adjacent EVENTS query already used correctly, since created_at is reliably ISO-formatted platform-wide unlike the free-text date column. 3) TIMEZONE MISMATCH between two sibling variables in the same file -- $now correctly built an explicit America/Los_Angeles DateTime, but $today one line below used raw date('Y-m-d') with no explicit timezone, meaning it silently used PHP's server-default timezone (very likely UTC). For roughly 5pm-midnight PT every day (UTC is 7-8 hours ahead), this made $today compute TOMORROW's calendar date while every real created_at value is written using PT-based cai_time() -- so even after fixing bug #2, the query still returned 0 rows when tested at 5pm PT, until this was also found and fixed by deriving $today from the same PT-aware DateTime object as $now. Also fixed a smaller, separate issue: the drop-report-to-Master call hardcoded targets='01' (an old retired code) instead of decade '10' -- changed to match, though messages were apparently still reaching Master somehow (possibly a legacy alias in inbox-api.php), this makes it correct going forward rather than relying on unconfirmed legacy compatibility.