Convex deployment keys

• Provider documentation convex-backend 032e81e: format_admin_key / split_admin_key / remove_type_prefix, ADMIN_KEY_VERSION = 1, encrypt_proto + const_hex::encode (re-checked 2026-09-28) · observed 2026-09-28 · provider code (ruling R1): an optional prod:/dev: + cloud name or preview:/project: + two slugs lead, the deployment or instance name, exactly one |, then 01 + lowercase hex whose even length 74–96 is derived from the generator (29-byte envelope plus a 8–19-byte AdminKey proto); the docs show the typed leads and the | join
• Reference 1
• Reference 2
• Reference 3
• Reference 4
• Reference 5
• Reference 6
• Reference 7
• Reference 8
• Reference 9
• Reference 10
• Reference 11
• Reference 12
• Reference 13
• Reference 14
• Reference 15

Arrival evidence (#436, product redact-secret#912; #860 handoff convex.md, READY for the hex body). T1 under ruling R1: the provider backend joins {deployment_name}|{encrypted_part}, writes version byte 01, a 12-byte nonce, the AES-GCM-SIV ciphertext and a 16-byte tag, and hex-encodes it in lower case; the 74–96 even length is derived from the proto fields the broker always sets. The CLI accepts prod:/dev: + a cloud name and preview:/project: + two slugs; the slug grammar is project policy (bounded, no source). The secret span is the whole key, name included, because it is the one string the CLI consumes. Excluded: CONVEX_DEPLOYMENT=dev:<name> selectors (no |), convex.cloud URLs, pre-0.16.0 bare keys, team and OAuth tokens, docs placeholders whose body fails the grammar. The current cloud deploy-key body (eyJ2…) is issuance-gated: ruling R4 fixes only its prefix, so no fixture asserts it either way. Neither pinned peer has a Convex rule. Graduated to a registry detector at the 1127bf9 re-pin (redact-secret PR #938).