Session open blocked on actionability -- 2 flagged items, one of which was CC[100]'s R002 CRITICAL report: admin token hardcoded in plain text, publicly readable with no auth, in 7 browser-delivered files, chained through file_write_web.php's arbitrary-path-write capability to a real RCE risk. Per D-CONFIRM-CONSEQUENTIAL, did not take the report at face value -- independently re-verified all 7 files anonymously (no credentials, same method CC used) before acting. RESULT: 3 of 7 were already clean (dashboard.html, panel.html, db-admin.html) -- fixed in this session's earlier D796 pass, before CC's report arrived. CC's scan of those 3 was almost certainly from before that fix landed. 4 were confirmed genuinely still exposed: cmd-popup.js and commands.html (token embedded in the file-editor.php Edit link and CMD_INVENTORY_URL -- these weren't part of the original 13-page migration since they're reference/documentation pages, a real gap), plus media-viewer.html, jobs/index.html, and web-fetch.html -- confirmed missed by every prior pass, still carrying only the OLD token. Also independently checked CC's directory-listing claim (backend/sys-com/ returning an autoindex) -- did not hold up. That path serves index.html normally, real page content, not a directory listing. Corrected this back to CC rather than silently accepting it. Fixed all 5 confirmed-exposed files: backed up first, removed the token entirely (cmd-popup.js/commands.html now call records-api.php with no token param at all, relying on session same as everything else; media-viewer.html/jobs/index.html/web-fetch.html migrated to the same session-login-redirect pattern as the earlier 13-page rollout). Re-verified all 5 clean via the identical anonymous curl method used to find them. CC's doubled-prefix-token finding (yttcom-admin-yttcom-admin-) was already found and fixed independently earlier this session (D795) before CC's report arrived -- confirmed still clean, CC's staged patch files are superseded and don't need deploying. CC's larger architectural recommendation (Authorization header for machine callers instead of ?token= query strings, using a separate token from the browser session entirely; split read-only vs write credentials) is the real fix and is NOT built yet -- filed as T-R002-PROXY-GATE to Server[40], per CC's own suggested ownership, rather than attempting it in this same pass. Not rotating the token again until that work is done, per CC's explicit recommendation. Replied to CC and Server[40] directly with the full comparison (what was already fixed, what was newly fixed, the directory-listing correction, and the filed follow-up task).