zeekay
19fdf55ceb
A key now opens with what it is allowed to touch. `pk-` is publishable and safe in a browser; `sk-` is secret and never leaves a server. The five marks it replaces all began `ph` -- the upstream's initials -- and they were the last of its brand a customer read back to us, in every SDK snippet. No word rule could reach them, because `ph` is not a word. The marks were also not telling the truth. The constant said `phc_` while every live project token said `hi_`, so the middleware that routes on the constant matched no real token at all. Two spellings existed and one was fiction. Minting now happens in exactly one function and reading in exactly one, so a second spelling has nowhere to live. `phx_` (personal) and `phs_` (project secret) both become `sk-`. The mark now says only that a value is secret; which store holds it is settled by asking. That was already how personal keys worked -- keys minted before the marks carry none, so the store always decided -- and both secret resolvers already returned None on a miss and fell through, so one shared extractor replaces the two that could drift apart. OAuth's access and refresh tokens stay distinguishable as `at-` and `rt-`, because the parser tells them apart before either is looked up, and the domain-verification token becomes `vt-` rather than keeping a sixth mint of its own. `bin/debrand --check` now refuses the marks as a shape, so a seventh cannot be coined. Two rules that were about to rename things that are not ours to spell are bounded: `Lemon` no longer eats `LemonSqueezy`, and the `hog_flow` rules no longer reach a Postgres table, a Datastore table or a route. Keys are stored hashed, so a mark cannot be rewritten in place: the three live project tokens have to be reminted.
6.6 KiB
name, description
| name | description |
|---|---|
| finding-llm-gateway-migration-candidates | Finds and ranks callers that could move from services/llm-gateway to Insights/ai-gateway. Use when asked what to migrate next, to find low-risk gateway migration candidates, to audit remaining Python gateway callers, or to identify callers blocked by Go gateway parity. Searches code and deployment wiring, inventories each caller's required contract, filters out unsupported migrations, and returns an evidence-backed shortlist without changing callers. |
Finding LLM gateway migration candidates
Use services/llm-gateway/PARITY.md as the current contract decision record. If implementation evidence contradicts it, run /auditing-llm-gateway-parity before ranking candidates.
This skill produces a point-in-time shortlist. Do not turn the parity document into a fleet-wide migration tracker.
Discover callers
Search the current default branches for Python gateway use, including:
LLM_GATEWAY_URL,LLM_GATEWAY_API_KEY, and product-slug URLsget_llm_client,get_async_llm_client, andget_async_anthropic_gateway_client- direct OpenAI, Anthropic, or agent SDK clients configured with a gateway base URL
- Python product names from
services/llm-gateway/src/llm_gateway/products/config.py - deployment, sandbox, workflow, and secret wiring in other Insights repositories
Trace each result to the production call site. Exclude tests, development-only tools, dead code, and callers already configured exclusively for Go. Treat shared worker configuration as evidence about availability, not proof that every call in that process uses Go.
Search open and recently merged PRs across involved repositories before proposing work. A migration may already be underway even when the default branch still uses Python.
Prove the production path
Before classifying a caller, follow it through every runtime boundary:
- Find the API, task, workflow, schedule, or command that invokes it.
- For Temporal, map the workflow and activity to the exact task queue, then map that queue to its deployed worker.
- Inspect every environment overlay that runs the caller. Do not borrow configuration from another worker in the same product.
- Resolve the configured URL by host and path. Variable names are not proof: an
AI_GATEWAY_URLcan still contain a Python product-slug URL. - Confirm the current call can succeed. A broad exception handler with a deterministic fallback can hide missing credentials or a route that never runs.
A missing sk- credential is deployment work, not a parity blocker. Once the intended paying team is known, create a project secret with llm_gateway:read in the Insights dashboard and fund or configure that team wallet as part of the migration. A secret reference proves only that a credential is injected; verify ownership, scope, and funding during implementation or rollout.
Inventory each candidate
Record only the contracts that affect the migration decision:
- user-facing use case and production entry point
- credential source and trusted authorization policy
- spend owner, budget enforcement, current Python billing behavior, and the team wallet that should own Go spend
- API shape and model as one pair, provider, streaming, tools, and structured output
- distinct ID, trace, product, team, and custom attribution
- retry, timeout, fallback, and error behavior
- deployment and egress changes needed to activate and roll back the route
Do not infer requirements from a product name. Read the call and its configuration.
Check model and API shape together. Python can expose an Anthropic model through OpenAI Chat Completions, while Go's native routes do not generally cross-translate shapes. A migration may need both a gateway change and an SDK-shape change.
Separate billing identity from event attribution. Go debits the credential's team. A caller-supplied team_id or ai_product property can preserve reporting context but cannot select the wallet.
Classify readiness
Match the inventory to the parity record and current Go implementation:
- ✅ Ready: required contracts are supported and the remaining work is client, test, or deployment wiring.
- 🔎 Verify: support probably exists, but model availability, wire behavior, billing, attribution, or deployment configuration needs a targeted check.
- ⛔ Blocked: migration would lose a required auth, policy, billing, provider, API, or attribution contract.
- 🚧 In progress: an open or recently merged PR already owns the migration.
Name the exact evidence for every status. An existing Python helper is migration effort, not a blocker. An ai_product property is telemetry, not trusted identity or billing policy.
Python's unbilled flag is not a blocker when an internal workload should debit a Insights-owned team wallet for spend attribution. Verify that the Go credential resolves to that team. Treat billing as blocked only when migration would charge a customer incorrectly, lose required customer budget policy, or violate a requirement to debit no wallet.
Use ✅ when the production entry point, worker or process, intended paying team, model and API pair, attribution conversion, and rollback path are supported by evidence. The token itself may still need to be created and wired. Use 🔎 when the spend owner, required policy, runtime behavior, or another migration contract is unknown.
Rank the shortlist
Prioritize candidates that:
- Have no ⛔ contract.
- Use a shared Go-capable builder or a stock SDK with a simple base URL change.
- Already use a Go-supported model, provider, and API shape.
- Need informational attribution rather than trusted product identity.
- Can use a customer wallet intentionally or a Insights-owned wallet for internal spend.
- Have a narrow deployment boundary, explicit fallback, and cheap verification path.
Lower the rank for broad shared-process switches, unverified billing changes, cross-repository deployment work, or missing production tests. Do not rank by code size alone.
Report candidates
Return a small decision-oriented table with:
| Candidate | Readiness | Why | Required work | Evidence gaps |
|---|
List the strongest ready candidate first. Name the exact production process and deployment for each candidate. For blocked callers, state the missing Go contract and where it was verified. For in-progress work, link the existing PR instead of proposing duplicate work. For 🔎 candidates, state the one check that would promote or reject them.
Do not modify callers while running this skill. Once a candidate is selected, run /migrating-llm-gateway-callers for that caller.