Env writes, redeploys and secret mints now reach the founder as one Telegram tap each

Vercel env writes, redeploys and secret mints no longer wait in a to-do file for hand-typed commands. Each now becomes one Telegram card, approve or deny, and a CI lane executes only what was approved. The lane merged on Oct 18 as a main-only, kill-switch-gated workflow with eleven tested invariants.

What was left to do by hand?

Earlier automation work had already turned merges, flag flips and digests into taps. What remained was labelled credential-bound: `vercel env add`, a dashboard Redeploy, `gh secret set`, a key re-seal. By October those were the paste lines in the founder's to-do file.

The target was simple: the only manual act left is approving a card. Provider-issued keys, logins and signatures stay paste lines, because no lane can mint those.

Why does this not add new authority?

Vercel tokens are scoped to a team, not to a permission, so CI already held the write capability for its env-sync and deploy-health jobs. The lane adds a human approval in front of that capability and nothing behind it.

Around it sit deny lists: approval and worker credentials can never be written through it, public repos are never a target for secrets, and the repo that holds the approval secret is excluded. Requests for those names are refused before any card exists, so the founder never sees a card that can only fail.

An edited request is a new id, and a new id is a new card.

How does an approval stay bound to what was approved?

The first design did not. Two fresh-context skeptic rounds and a code review each broke it. A re-attached approved row could replay an edited payload. A logged literal could forge result lines. Multi-target rows would have been shrunk silently.

The fixes are structural. A request id is `h-` plus ten hex characters of the hash of its content, so an approval can only belong to identical content. Before anything executes the run takes a durable `SET NX` marker for that id in Redis, so an id runs once, ever. Literal values are shown on the card, capped at 60 printable characters, and refused if they look like a credential. Secrets are minted on the runner and never logged. A request that would be silently shrunk is refused instead.

Does it work end to end yet?

Partly, and the status matters. The first live tap, a harmless canary flag on one app, wrote the env value correctly. The redeploy that followed was cancelled by that project's Ignored Build Step, and the fix for that is a pull request still waiting on a merge. GitHub-side verbs ship dark until a fine-grained token is provisioned. Next on the list: a GitHub Environment restricted to main, and sealing minted values to a founder public key.