2026-09-19 — Bot logout + auth native cutover (and a scare)

What shipped

• Logout button on all four scorpiox-bot-web pages (fleet hub, chat, settings, servers). New bot_logout.h component: BOT_LOGOUT_BTN (danger icon-btn) + BOT_LOGOUT_JS (runtime removal on non-*.scorpiox.net origins so self-hosted Windows/LAN boxes render unchanged). Commit 675a9a9 in scorpiox-bot-web.
• **auth.scorpiox.net /logout?next=** — the logout page now honors a validated next target (relative or *.scorpiox.net only), in both the Python repo (accf023) and the native C repo (bdb5fef + root binary rebuild 2523ef6).
• Production cutover of scorpiox-auth to the native C CGI (first of the 8-batch tracker). Edited the infra-config unit symlink target (5ec5fbe), restarted on .12, verified with real prod-minted tokens. Rollback = point the unit back at scorpiox-auth.git; no token invalidation (same HS256 scheme + key).

Flow verified end-to-end: logout clears the HttpOnly sx_token cookie → 302 to login?redirect=https://bot.scorpiox.net/ → re-login bounces straight back to the Fleet Hub.

The scare — concurrent session on a shared checkout

While editing chat.c, someone else's uncommitted work (base64 preloaded cards + js_escape_str hardening — looked like the botwebthinking issue work) appeared in the working tree. My edits kept getting "eaten". Turned out the file was being modified out from under me, not any tool bug. Resolution: backed up their chat.c to /root/backups/chat.c.prelogout-20260919-113407 before checking it out, and told the user. **Lesson: on shared .100 checkouts, if your git diff suddenly contains work you didn't write, stop and diff-dating-check before touching anything else.**

Notes

• scorpiox-editfile LINE ranges are positional (current file state), not from an old read — two of my edits double-applied because I reused stale line numbers after other edits shifted lines. Re-read before every edit.
• The native auth service_token file contains a literal \n in the middle of the token — Python and C both read raw file so they agree; don't "fix" the file.
• Tracker rule honored: auth cutover required explicit user order (it got one), unit is a symlink so I committed the infra-config target, not the symlink.

Bonus fix — "Invalid verification code" on password reset (found same evening)

User hit "invalid validation code" resetting support@scorpioplayer.com. The AAA

CheckPassCode endpoint answers HTTP 200 with an EMPTY body for a valid

code and HTTP 400 problem+json for an invalid one — but both the Python

login.py and the native auth_common.c required the body to start with

true/1. So every valid code was rejected. Fixed both (native 93de80d,

Python pending). Verified live: fresh code → POST /login step=reset_code

through Caddy → page advanced to "New Password". Empty 200 body = success;

non-empty body still honours legacy true/1/false/0.