Record INTERNAL_EMAIL_KEY in unverifiable-state; close SUPPORT_API_KEY value question

Sub-tickets

Activity

• coder-mars-cc created · 2w ago
• coder-mars-cc completed · 2w ago
  Two SHAs. bf6041d (v2.82.15) adds the INTERNAL_EMAIL_KEY entry - VERIFIED LIVE, /api/health reports 2.82.15. 9d76186 (v2.82.16) carries two corrections - PUSHED BUT NOT YET VERIFIED LIVE: at check time /api/health still read 2.82.15 against remote main 2.82.16, i.e. the deploy was in flight, not mismatched. Whoever picks this up re-probes; do not read this close as a version-match pass on the second SHA. FINDINGS. (1) The coder lane has NO Vercel read path at all on this seat: no vercel CLI (command not found, absent from node_modules/.bin) and the Vercel MCP returns 0 projects unscoped and on team_WG6Gxa6RLXDjS2DFj3Tp99RV. support-evolutiva-cc had diagnosed this as its own missing project scope and withdrew that after I reproduced it. The lane that owns deploys cannot enumerate its own project - that is the root cause of the INTERNAL_EMAIL_KEY entry, not a detail of it, and it is worth its own item. (2) SUPPORT_API_KEY's value question is CLOSED, and the method generalises: support-evolutiva-cc authenticated with the pm/06:66 plaintext against production and got 400 'provide one of ticketId/ticketRef/ticketNumber' rather than 401, so the bearer was accepted and the documented plaintext IS the live value. A bearer can be confirmed by PRESENTING it to the gate; no read path is needed. That route was available to every bearer-shaped entry in this file the whole time and nobody had taken it. (3) Corrected my own entry: I had written that support-evolutiva-cc 'independently' held a 66-char copy. A fingerprint exchange returned identical sha256 first12 252d4877292e on both seats - one stale .env.local cache read twice, not two sources. Matching LENGTH had looked like corroboration. STILL BLOCKED, unchanged: INTERNAL_EMAIL_KEY prod value is obtainable only by Elazar reading it off the Vercel dashboard. No-rotation binds - nobody mints a replacement, and the 401 is gate-correct and must not be relaxed. The MARS-770 notice stays held. Separately, support-evolutiva-cc established mars support-action has no create op and the affected user has zero supportTickets rows ever, so the ticket path cannot deliver that notice either; it declined to hand-INSERT a row, correctly.