Follow-up to D783/sys_id 98 (same session). The sop-stopword + top-score-tie fix caught two of three live false positives but missed a third, harder class: a LONE candidate (no tie to catch) reaching the raw score>=2 threshold purely on generic words shared with many SOPs. Live repro: task update_task API ignores description param stale task records cannot be edited (T00-DESCFIELD) matched SOP-HEALTH-LOG.md on shared words {api, stale} alone -- both common terms scattered across several SOPs, zero relation to the actual records-api.php bug. ROOT CAUSE: raw word-count treats a common word (appears in many SOPs) identically to a rare, specific word -- no notion of term specificity. FIX: added document-frequency (IDF-style) weighting -- computed docfreq(word) = how many of the 41 live SOPs contain that word, then each shared word contributes 1/docfreq instead of a flat 1. Added a minimum weighted-score threshold of 1.0 to trust a match, and changed the tie-check to operate on weighted score (near-tie = within 15%% of top) instead of raw count, since raw-count ties and weighted-score ties are not the same thing once weighting is in play. Calibrated the 1.0 threshold against 10 real task strings pulled from this actual session backlog (T2524, the matcher-investigation task, T00-DESCFIELD, T-HOUSEKEEPING-SCHEDULE, T00-NOAUDIT, T2532, T764, T2531, T00-ADMIN, T762, T760) -- every genuine match scored 1.5-3.3+ weighted, every coincidental one scored under 1.0, calibrated with real data not picked arbitrarily. VERIFICATION: same balance-check + deploy + SAFE-WRITE readback pattern as round 1 (php-check.php tool still returning HTTP 500 on any input, unrelated pre-existing bug, not chased). Live-tested all three original false-positive strings post-deploy -- all three now correctly return matched:false (two as clean no-match, one as an explicit near-tie between 2 SOPs at wscore=1.0). Live-tested the known-good T-HOUSEKEEPING-SCHEDULE string -- unchanged, still confidently matches (score=7, wscore=3.33, comfortably clear of both the 1.0 threshold and the 15%% tie band). Live-tested one more diverse real task (gdrive-api read/verify action) -- correctly matches SOP-GDRIVE-SERVICE-ACCOUNT.md (wscore=2.14). action=status confirmed still functional post-deploy (call_count=87). FILES TOUCHED: systems/commands/TASKGATE.php (live, second edit this session -- same file already backed up pre-round-1, not re-backed-up for round 2 since BACKUP.php's CURRENT/PREVIOUS rotation only keeps one prior version and round 1's deployed-live state was itself already tested/working, not a rollback risk point).