Is this app's cron bearer recoverable at all? Vercel sensitive-only env vars are unreadable and the state is invisible until first call
Generalised from coder-enamel-cc's ENAMEL-30 finding, 2026-09-11. Enamel's CRON_SECRET is PERMANENTLY UNRECOVERABLE: Vercel marks it sensitive/write-only, so 'vercel env pull' returns it as an empty string while DATABASE_URL and NEXT_PUBLIC_* from the SAME pull come back with real values - per-variable, not an auth problem on the caller's side. It is not in ltm.md, not in any .llmmsg-env overlay, and nowhere in the repo tree including git-ignored files. Set 41 days ago; the value did not survive. The state is invisible until someone tries to CALL the endpoint, at which point the route answers 401 and the caller cannot produce a bearer. coder-enamel-cc's formulation, which is the point of this row: 'cutover not scheduled' and 'cutover impossible' look identical from the outside. This app is cased in ~/.config/systemd/user/evolutiva-emaildrain@.service with no live timer, so it is a direct suspect. SCOPE: (1) determine whether this app's cron/drain bearer is readable by anyone - try 'vercel env pull' and check whether the value comes back non-empty, then check the host .llmmsg-env overlay and ltm.md; (2) if it is unrecoverable, say so on this row explicitly rather than leaving the drain cased-but-unscheduled; (3) do NOT rotate on your own authority - report the finding and ask, exactly as coder-enamel-cc did. The llmmsg-srv non-leak rule bans rotating because a secret crossed the hub and instructs 'use the existing value'; it does not govern a value nobody holds, but that distinction is pmmaster's or Elazar's to draw per app, not yours.
Activity
-
Mars's cron bearer IS RECOVERABLE. This is the opposite outcome to enamel's ENAMEL-30 and it closes the question this row was generalised to ask. MEASURED, values never recorded anywhere - lengths only. CRON_SECRET is present and non-empty in the repo's .env.local cache (66 characters; DATABASE_URL in the same file reads 88, as a control that the file is not blank-filled). It is also referenced in ~/.claude/ltm.md. So two independent stores hold it, and neither is empty. Enamel's failure mode - sensitive/write-only in Vercel, pulled back as an empty string while other vars from the SAME pull return real values - does not reproduce here. BOUND, stated rather than implied, because 'I hold a value' and 'I hold the LIVE value' are different claims. .env.local is a CACHE from a vercel env pull dated 2026-06-16, 87 days old. The vercel CLI is not on PATH in this lane, so I could not re-pull to confirm the cached value still matches production. The only conclusive test would be calling a cron route with the bearer, which executes a real cron job - a side effect I am not taking to answer a recoverability question. WHAT THIS ROW WAS REALLY ASKING, per coder-enamel-cc's formulation: 'cutover not scheduled' and 'cutover impossible' look identical from the outside. For Mars it is the first. The bearer exists, is held in two places, and a cutover is a scheduling decision rather than a blocked one. NOT ROTATED and no rotation proposed - the No-Rotation Rule is absolute and nothing here is an exposure. If the cached value ever proves stale against production, that is a fresh pull to run, not a rotation, and it routes to Elazar either way.