- Shipped
- August 22, 2026 at 9:02 PM UTC
- Author
- Kamo
- Commit
- 30eae8d
kamo-internal polls GET /api/security/session/god-mode once on mount and every 60s thereafter. That endpoint was removed in 9c70cb7 along with the rest of the time-box, so Spring matched the path against a POST-only mapping and answered 405 to every poll. The Next proxy relays upstream status verbatim, which is how it reached the browser console. The console noise was the harmless half. godMode.ts publishes "not elevated" whenever it cannot confirm an elevation — deliberately, since claiming access the server has withdrawn is the worse failure — so a permanently-405ing status call meant the client never verified elevation against the server at all. The surviving POST returns {success, godModeActive} with no expiry, and the client treats an active claim with no expiry as inactive, so activating god mode also published "not elevated": the indicator never appeared and every frontend god gate stayed shut, while the *** flag the backend gates read was in fact being written. Elevated server-side, blind client-side. Restores GodModeSession, the GET status endpoint, the justification floor, the bounded non-sliding window, the PHI audit rows on both edges, and the mask-if-expired call in KSessionService.getSession that makes the box real for the ~10 gates that read godModeActive directly. This is a re-apply onto current HEAD rather than a revert: four commits have touched these files since, and the sliding-TTL comment maskIfExpired carried no longer described the code, so it now explains the session lifetime instead. 9c70cb7 recorded that it was checking in another session's uncommitted work "so main is not left with a tree that does not compile" — not a judgement that the removal was right. Restoring it puts back a control a covered entity's security review asks about directly: an elevation with a recorded reason and an end. Verified: mvn -o -T1C test — 833 tests, 0 failures, including the restored GodModeSessionTest (16) and ****************