ROOT CAUSE (confirmed via direct reproduction against live SOP-INDEX.md, not guessed): (1) the word sop was missing from the stopword list even though every single SOP entry name begins with SOP-....md -- 100% document frequency (41/41 live-checked), same failure class as taskgate already being stopped for the same reason. Any task mentioning SOP got a free +1 against every candidate. (2) The bigger issue: the score>=2 confidence threshold had no tie-check -- when the top score was tied across multiple SOPs, usort stability silently picked whichever appeared first in SOP-INDEX.md (insertion order), asserted as a confident match. Both live repro cases from this session landed as exact ties at the threshold: T2524 (Google Drive privileges task) tied 3-way at score=2 across SOP-DATA-BACKUP/SOP-GDRIVE-SERVICE-ACCOUNT/SOP-RESEARCH-MEDIA-DB (task actual subject -- privileges/scope -- appears in zero SOPs platform-wide, only the generic app name Google Drive overlapped); investigate-the-matcher task tied 2-way at score=2 between SOP-PICKUP-RESOLUTION/SOP-FINANCE-LEDGER purely because the latter SOPs own history section describes a past false-positive fix and contains the literal word sop in its filename. FIX: added sop to stopwords with inline comment explaining the 100%% document-frequency reasoning; added a tie-detection block after the score>=2 filter -- if the top score is shared by more than one SOP, treat it the same as no-match (matched:false) and return a new tied_candidates field listing them, instead of asserting one arbitrarily. Also fixed a duplicate log_call bug I introduced mid-patch (original unconditional log_call(false,null) before the buildWords block collided with a new tie-aware log_call -- removed the original, kept the new one which logs TIE:name1,name2 as the sop field so the audit trail shows why a call failed match). VERIFICATION: backed up original via BACKUP.php (Server_TASKGATE_CURRENT.php) before any edit. php-check.php (the platforms existing PHP syntax-check tool) returned HTTP 500 empty even against the untouched, already-live original file -- confirmed the tool itself is broken right now, not my patch (separate bug, not chased further this session). Substituted a bracket/brace/paren balance check (Python) as a sanity gate, then did the real verification: deployed to live, fetched the file back and confirmed both new code blocks present (SAFE-WRITE rule), then ran the exact two failing task strings from earlier this session live against the deployed TASKGATE.php -- both now return matched:false with a tied_candidates list instead of a false confident match. Also ran a known-good regression case (todays own T-HOUSEKEEPING-SCHEDULE task text) live -- still correctly and confidently matches SOP-HOUSEKEEPING-SCHEDULE.md (score 7 vs runner-up 3, clean win, no tie), confirming the fix does not suppress genuine matches. action=status still functions post-deploy (call_count=80 without since filter). SEPARATE FINDING, not fixed: action=status with a since= filter returns call_count=0 despite same-day real calls existing -- looks like the same PT-suffix strtotime double-handling class as K370, flagged not fixed (low-impact diagnostic feature, not gate-blocking). FILES TOUCHED: systems/commands/TASKGATE.php (live), backend/tmp/TASKGATE-test.php (scratch copy, not cleaned up yet), backups/40-server/php/Server_TASKGATE_CURRENT.php (pre-edit backup).