ORA-2026-0038

Pattern

Adding one LLM provider key requires writes to three layers (Supabase secrets, Vercel env vars, macOS Keychain) using a dual-name convention (canonical name + alias). With 3 providers × 3 layers × 2 names, a single provider addition is 18 discrete write-sites. This is N×M plumbing that compounds with every new provider or layer.

Proven shape (3 providers, 2026-04-22)

All three providers now follow the same template:

The dual-name pattern exists because different consumers reference the same credential by different names (edge functions use canonical, local scripts use alias, Keychain uses service-account convention).

Why this matters

1. Each new provider (Mistral, Cohere, etc.) should follow the identical shape. Without a template, each addition reinvents the plumbing and risks partial provisioning (key set in Supabase but not Vercel — dormant on deploy). 2. Partial provisioning is a Dormant Capability with negative blast radius (per ORA-2026-0036 credential sub-class). A key set in one layer but not another creates silent failures or unguarded exposure. 3. The plumbing is scriptable. Three layers, two names, one key value. A provision-llm-provider script that takes (provider, key_value) and writes all 6 sites eliminates the N×M manual matrix.

Recommended countermeasure

Build a provision-llm-provider script (or extend existing lane-boot / credential tooling) that:

1. Accepts --provider <name> --key <value> 2. Writes canonical + alias to all three layers 3. Verifies readback from each layer 4. Prints a summary showing 6/6 sites confirmed

Until the script exists, any provider-addition ticket MUST include a checklist of all 6 write-sites in the ticket body, and the DONE post must confirm all 6.

Elevation criteria

Promote to M3 (doctrine candidate) if a fourth provider is added and follows the template. Promote to M4 (doctrine) if the provisioning script is built and proven.