frutebox-node 0.1.0__py3-none-any.whl

frutebox/registry/providers.yaml

@@ -0,0 +1,518 @@
+# 28 §A4 / §A9 — the provider catalog.
+#
+# WHAT THIS FILE IS, AND IS NOT (§A9.4)
+# This is the SCHEMA and the SEED: it defines the shape of a provider row and the defaults a
+# fresh database starts from. It is NOT the live source of truth. Once seeded, the live
+# enable/region/credential state lives in the DATABASE, so adding a provider, turning one on in
+# a region, or rotating a key is a row change — no redeploy, no key copied to N services.
+#
+# PHASE 1 (launch) IS DELIBERATELY TINY (readme LAUNCH PHASING, 2026-09-07):
+#   RunPod (US) + ONE EU provider (Verda/DataCrunch). Gateways EU + US only.
+# Everything else in the geo roster is Phase 2 (plan 29) — defined here so the shape is settled,
+# but `enabled: false` so nothing provisions until launch is live and stable.
+#
+# CREDENTIALS ARE NOT IN THIS FILE, EVER. `env` names which variables a cold-start/local-dev
+# fallback would read; the real values live encrypted in the DB under STEVAI_DATA_KEY
+# (readme rule 10 — never a cloud KMS). `providers doctor` reports presence, masked.
+
+version: 1
+
+# `class` routes work to capacity built for it: an AI job never lands on a CPU-only host, and a
+# plain compute job never overpays on a GPU cloud (§A4).
+# `weights` is not a compute class and never enters the race — it is a model SOURCE
+# (plan 28 §A5 lists Hugging Face in the same credential table as the compute providers),
+# so its token lives in the same encrypted store rather than on a service that never uses it.
+classes: [gpu, compute, tee, weights]
+
+# ROSTER TIER 3 (owner ruling 2026-09-24): Alibaba, OVHcloud, Gcore, Cloudflare R2.
+# Z1 was in this tier when it was first recorded and was DROPPED hours later the same day;
+# OBJECT STORAGE STAYS ON CLOUDFLARE R2, which is now the only storage member.
+#
+# RECORDED HERE BECAUSE IT DID NOT EXIST ANYWHERE. A search of the whole repo found no provider
+# roster tiering at all — the geo roster in plan 28 §A6 is organised by continent, and the only
+# "tier 1/2/3" language in the code is `routing.py`'s COMPUTE tiers (tier 1 GPU, tier 2/3 CPU),
+# which is a different axis entirely. So this is a NEW list, not an edit to an existing one, and
+# two things about it are flagged rather than smoothed over:
+#
+#   1. THE NAME COLLIDES. "Tier 3" already means "CPU pool" in `routing.py` and in the planner
+#      tests. A reader who meets both will assume they are the same scheme. If this roster tiering
+#      is going to persist it wants a name that does not collide — `roster_tier` rather than
+#      `tier` — and the owner should say which.
+#   2. IT MIXES CLASSES. Alibaba, OVHcloud and Gcore are compute; Cloudflare R2 is OBJECT
+#      STORAGE. This file's `classes` list has no storage class at all, and the merit-order race
+#      is class-gated precisely so a job never lands on capacity built for something else. A
+#      storage provider in a tier alongside three compute providers cannot be expressed as a row
+#      here without either a new class or a separate roster.
+#
+# So it is written down as the owner stated it, and NOT modelled as rows or as a `tier:` field,
+# because modelling it wrong is worse than not modelling it yet. Neither Cloudflare R2 nor
+# OVHcloud has a row, a class or an adapter today.
+roster_tier_3: [alibaba, ovhcloud, gcore, cloudflare_r2]
+
+providers:
+  # ── PHASE 1 ────────────────────────────────────────────────────────────────────────────
+  # ── BEING REPLACED (owner decision 2026-10-16) ───────────────────────────────────────────
+  #
+  # Verda + Nebius replace RunPod. This row is deliberately UNCHANGED in every field that affects
+  # behaviour — `enabled: true`, `phase: 1`, `regions: [us, eu]` — because the cutover is a
+  # SEQUENCE and this is step zero of it, not step one. Disabling RunPod before Verda and Nebius
+  # have each proven a live boot would remove the only funded capacity there is, which is exactly
+  # the mistake the 2026-10-13 EU ruling made and the 10-14 reversal undid.
+  #
+  # The replacement is PREFERENCE-DRIVEN and needs no field here: `regionmap._DEFAULT` already asks
+  # Verda first and Nebius second for EU, and RunPod answers only what they cannot. As they are
+  # funded they take the traffic with no code change — the same property that made Verda's
+  # preference safe while it was empty.
+  #
+  # WHAT REMOVES THIS ROW is written down and is not a judgement call:
+  # `docs/provider-cutover-verda-nebius.md`, which also names the owner approval that teardown
+  # needs. DO NOT disable it here first; the pods currently serving EU media are on this provider.
+  - id: runpod
+    class: gpu
+    status: being_replaced
+    enabled: true
+    phase: 1
+    hq_country: US
+    # US ONLY (owner rule, 2026-10-21): "EU GPU work runs ONLY on Verda + Nebius. Never Google
+    # GPUs, never RunPod (RunPod pods are terminated and not used in the EU)."
+    #
+    # THE HISTORY MATTERS, BECAUSE THIS ROW HAS SAID BOTH THINGS. On 2026-10-13 `eu` was removed to
+    # stop "EU traffic being served by RunPod"; the owner REVERSED that on 10-14 with a reason —
+    # "RunPod must remain a valid EU provider because the other EU systems aren't funded yet" —
+    # and at the time it was the only funded EU capacity there was. That reason has now expired
+    # rather than been overruled: Verda and Nebius are both funded, both authenticate, and both
+    # start instances (an L40S reached RUNNING in 78s on 2026-10-20). So the capacity argument that
+    # justified the reversal no longer applies, and the owner has closed it.
+    #
+    # WHY THE ROW AND NOT ONLY `regionmap`. There are THREE EU candidate sets and they must agree:
+    # `regionmap._DEFAULT` (dispatch), `nodewake.warmpool_providers` (pod creation), and
+    # `providers.eligible(region="eu")` — which reads THIS field. Leaving `eu` here would have kept
+    # RunPod eligible EU capacity while the other two refused it, and a gate has to go where the
+    # grant happens. `tests/test_eu_is_verda_and_nebius_only.py` pins all three together.
+    #
+    # The RESIDENCY lock is unchanged and was never the thing letting RunPod in: it is derived from
+    # `hq_country` and has always been Verda (now Verda + Nebius) with no fallback.
+    regions: [us]
+    api_base: https://rest.runpod.io/v1
+    env: [RUNPOD_API_KEY]
+    # §A5: account-scoped resource ids are DISCOVERED from the key, never hand-entered.
+    derived: [RUNPOD_NETWORK_VOLUME_ID, RUNPOD_VOLUME_DATACENTER]
+    capabilities:
+      gpu_types: [A40, A100, H100, H200, RTX4090]
+      network_volume: true
+
+  # VERDA (ex-DataCrunch). FIRST CHOICE FOR EU, and as of owner decision 2026-10-16 one of the two
+  # providers REPLACING RunPod.
+  #
+  # THE ID STAYS `datacrunch` AND THAT IS DELIBERATE. The company renamed itself to Verda in
+  # Nov 2025, but this id is a primary key: it is the key in `gpuproviders.PROVIDERS`, the key in
+  # `gpuprices._FETCHERS`, the `providerId` on every credential row already stored in the database,
+  # and the prefix `regionmap.provider_of_node` attributes a running node by. Renaming it would
+  # orphan the stored credential and un-attribute every live EU node — a key rename is a migration,
+  # not a tidy-up. Operator-facing text says Verda; the id says datacrunch.
+  - id: datacrunch
+    class: gpu
+    status: active
+    enabled: true
+    phase: 1
+    hq_country: FI
+    regions: [eu]              # the Phase-1 EU-sovereign provider (Verda / DataCrunch)
+    # `api.verda.com` since 2026-10-16, following the vendor's OWN SDK default
+    # (`verda.VerdaClient.base_url`). The old `api.datacrunch.io` host still answers, so this was
+    # never an outage — only a host one vendor decision away from being one.
+    api_base: https://api.verda.com/v1
+    # BOTH NAMINGS, NEW ONE FIRST — and the adapter reads them in this order.
+    #
+    # The 2026-09-07 discrepancy (plan 28 §A6 said `DATACRUNCH_API_KEY`; the SUPERVISOR_LOG said
+    # client id + secret) is SETTLED: the vendor's own SDK authenticates with an OAuth2
+    # client-credentials id and secret, so the log was right and there is no API-key form.
+    #
+    # The rebrand then added a second question — which name the stored credential is under. That is
+    # not knowable from the code, so both are declared and `DataCrunchProvider._creds` resolves
+    # each naming WHOLE, taking the first complete pair. Half of a rotated pair and half of a
+    # retired one authenticate as neither, and the resulting 401 reads as a revoked key rather
+    # than a seeding mistake.
+    env: [VERDA_CLIENT_ID, VERDA_CLIENT_SECRET, DATACRUNCH_CLIENT_ID, DATACRUNCH_CLIENT_SECRET]
+    # EITHER PAIR IS A COMPLETE CREDENTIAL — see `ProviderRow.env_groups`. Without this the doctor
+    # reads `env` as a conjunction and reports a WORKING deployment as unconfigured, missing two
+    # names it does not need. New naming first, so that is the one an empty account is told to set.
+    env_groups:
+      - [VERDA_CLIENT_ID, VERDA_CLIENT_SECRET]
+      - [DATACRUNCH_CLIENT_ID, DATACRUNCH_CLIENT_SECRET]
+    capabilities:
+      gpu_types: [V100, A100, H100]
+      network_volume: false
+    notes: >-
+      Verda (ex-DataCrunch), Finland. EU locations FIN-01/02/03 only — the vendor also offers
+      ICE-01, which is in ICELAND (EEA, not EU), and `DataCrunchProvider.create` refuses it.
+      `location_code` is REQUIRED on create since 2026-03-23 (absent is HTTP 400, not a default to
+      FIN-01). A delete that names no volumes LEAVES THE OS VOLUME BILLING — "by default, no
+      storage is selected for deletion" — so `destroy` names the volume ids with
+      delete_permanently. A shut-down instance keeps charging, which is why `offline` counts as
+      billing-but-not-serving. HDD volumes were decommissioned 2026-09-21: create/resize return
+      400, NVMe only.
+      MULTI-REGION (measured live 2026-10-18): the account's EU locations are FIN-01, FIN-02 and
+      FIN-03, all Finland, so Verda covers the eu-north geography only - ICE-01 is Iceland and is
+      refused by the adapter. An image boot REQUIRES at least one SSH key on the account ("SSH keys
+      must be provided if image is not an OS volume"), which the spec derivation reads rather than
+      assumes.
+
+  - id: huggingface
+    class: weights
+    status: active
+    enabled: true
+    phase: 1
+    hq_country: US
+    regions: [eu, us]
+    api_base: https://huggingface.co
+    env: [HF_TOKEN]
+    notes: >-
+      Model weight source for plan 28 §B (pinned hf_repo + revision). NOT a compute provider —
+      never enters the merit-order race. §B is not built yet, so nothing reads this token on the
+      request path today; it is stored here so §B finds it and so it is off the gateways.
+
+  # OWNER RULING 2026-09-22: vast PARTICIPATES. Four things said so — it is in the launch pool
+  # (tier 1 of the roster), it has a credential row, it is live-configured, and it is in the
+  # `WARMPOOL_PROVIDERS` default — and one field said otherwise. That field was the lie, so that
+  # field moved. `phase: 1` moves WITH `enabled: true`: enabling a phase-2 row on its own would
+  # have broken the "no phase-2 provider is enabled" invariant and swapped one inconsistency for
+  # a newer, less obvious one. `status: backup` STAYS — it describes vast's ROLE, a marketplace
+  # stock-out fallback, which is exactly what it is and is not what enabled/phase are for.
+  - id: vast
+    class: gpu
+    status: backup
+    enabled: true
+    phase: 1
+    hq_country: US
+    # US ONLY, and this is the SAME finding as RunPod's above with a sharper edge (2026-10-13).
+    #
+    # Vast is a MARKETPLACE, and `VastProvider._cheapest_offer` sends no location filter at all —
+    # its `/bundles/` query asks for rentable + verified + gpu_ram and nothing about WHERE the
+    # machine is. So an `eu` claim on this row could not be honoured even in principle: a job placed
+    # on "vast, region eu" lands on whichever stranger's host is cheapest, anywhere in the world.
+    # That is weaker than RunPod's claim was, not stronger, because RunPod at least has named
+    # datacentres.
+    #
+    # TO RESTORE `eu` HERE, `_cheapest_offer` must filter offers by geography first — the row is a
+    # promise about placement and the adapter is what keeps it. Until then the registry says what is
+    # true. (US capacity is unaffected; this is the EU claim only.)
+    regions: [us]
+    api_base: https://console.vast.ai/api/v0
+    env: [VAST_API_KEY]
+
+  # OWNER RULING 2026-09-21: lambda is IN the launch pool, and the key is already on the
+  # directory. It was previously in `on_hold` while `gpuproviders.LambdaProvider` resolved it and
+  # `nodewake.warmpool_providers()` defaulted to `vast,runpod,lambda,datacrunch` — the resolver
+  # returns {} for a provider the seed does not know, so a Lambda credential could never come
+  # from the database however it was stored. With this row the warmpool default is correct as
+  # written. `enabled: true` follows "in the launch pool"; until the credential is PUT it
+  # resolves as unconfigured and the race skips it, so nothing launches on an absent key.
+  - id: lambda
+    class: gpu
+    status: active
+    enabled: true
+    phase: 1
+    hq_country: US
+    regions: [us]
+    api_base: https://cloud.lambdalabs.com/api/v1
+    env: [LAMBDA_API_KEY]
+    # Account-scoped resources, not secrets — §A5: the owner supplies the credential, the code
+    # discovers the rest.
+    derived: [LAMBDA_REGION, LAMBDA_SSH_KEYS, LAMBDA_INSTANCE_TYPE]
+
+
+  # ── PROMOTED TO PHASE 1 AND ENABLED — OWNER 7 IS DONE, owner ruling 2026-10-20 ───────────
+  #
+  # THIS REPLACES THE 2026-09-21 RECORD that "Phala = Phase 2 / deferred". That record was true
+  # when it was written: the row described an API nobody had called and there was no key, so a
+  # tenant asking for the `tee` rung got an empty candidate set. `PHALA_API_KEY` now exists in the
+  # estate and is loaded into the encrypted provider-credential store, and the doctor's probe
+  # reports `configured: true, auth: accepted, reachable: true` — PROVED with the key ABSENT from
+  # the environment, so the only possible source was the store.
+  #
+  # `phase: 1` MOVES WITH `enabled: true`, following the vast and nebius precedents above:
+  # enabling a phase-2 row on its own would break the "no phase-2 provider is enabled" invariant
+  # and trade one inconsistency for a less obvious one.
+  #
+  # ⚠️ ENABLED IS NOT DEFAULT-ON. `class: tee` keeps this provider out of the ordinary merit-order
+  # race entirely — the TEE lane is reachable only by a request that asks for it (`require_tee`),
+  # which is plan 08's own rule and is asserted in `tests/test_phala_tee_provider.py`. So
+  # `enabled: true` here means "available to a tenant who requires attestation", not "available to
+  # everyone's next chat". `status: emerging` STAYS: it describes maturity, which this ruling did
+  # not change.
+  - id: phala
+    class: tee
+    status: emerging
+    enabled: true
+    phase: 1
+    hq_country: SG
+    regions: [eu, us]
+    # CORRECTED 2026-10-07 (owner). `https://api.phala.network` was wrong and nothing had ever called it,
+    # so nothing failed — the row simply described an API that is not there. `cloud.phala.com` is the
+    # DASHBOARD, not the API. The real base is below, and it matches the paths in Phala's own OpenAPI
+    # (`/api/v1/cvms/provision`, `/api/v1/cvms`, `/api/v1/cvms/{cvm_id}`); Phala's own SDK calls the
+    # override `PHALA_CLOUD_API_PREFIX`.
+    api_base: https://cloud-api.phala.com/api/v1
+    env: [PHALA_API_KEY]
+    notes: >-
+      TEE lane, Phase 1 since 2026-10-20 (Owner 7 done, key loaded). DEFAULT-OFF BY CLASS: a `tee`
+      provider never enters the merit-order race, so it serves only requests that set `require_tee`
+      (plan 08). A tenant requiring the rung now gets attested capacity instead of an empty set.
+
+  # ── PHASE 2 — defined so the shape is settled; provisioned only after launch (plan 29) ──
+  - id: alibaba
+    class: gpu
+    status: backup
+    enabled: false
+    phase: 2
+    hq_country: CN
+    # INTERNATIONAL ONLY, and REGION-LOCKED because the company is PRC-incorporated (2026-10-12).
+    #
+    # `ap-southeast` is the PRODUCT's region label (the deployment serves eu-west, eu-central,
+    # eu-north, uk, us-east, us-west, ap-southeast); Alibaba's own region id is `ap-southeast-1`
+    # (Singapore) and lives in `ALIBABA_REGION_ID`. Two vocabularies, deliberately not conflated.
+    #
+    # `region_locked` is what actually fences it. `regions` alone does NOT: `providers.eligible()`
+    # skips region narrowing entirely when no region is given — the warm pool reconciles that way by
+    # design — so before this field an enabled row was eligible for every unlabelled launch. It was
+    # measured that way before the field existed. Unstated is not permitted.
+    regions: [ap-southeast]
+    region_locked: true
+    api_base: https://ecs.ap-southeast-1.aliyuncs.com
+    # The SDK's OWN names. `ALIBABA_ACCESS_KEY_ID`/`_SECRET` were seeded here and are not
+    # what any Alibaba Cloud SDK reads — it looks for the `ALIBABA_CLOUD_` prefix. Verified
+    # against SDK source 2026-09-05; it had regressed to the short form since. Nothing
+    # reads these today (no account, `enabled: false`), which is exactly why a wrong name
+    # survives here unnoticed until the day it is needed.
+    env: [ALIBABA_CLOUD_ACCESS_KEY_ID, ALIBABA_CLOUD_ACCESS_KEY_SECRET]
+    notes: >-
+      Alibaba Cloud INTERNATIONAL (Singapore), ECS gn-series. RAM user credential, never the root
+      account. Region-locked: it may serve ap-southeast traffic only and is excluded from every
+      EU/UK/US job and from any launch whose region is unstated. `enabled: false` until a key
+      exists. Launch spec is the operator's (FRUTEBOX_ALIBABA_ECS_SPEC: ImageId, InstanceType,
+      SecurityGroupId, VSwitchId); `create` refuses without it. Terminate never stop —
+      DeleteInstance with Force=true, because Force=false requires a Stopped instance first and a
+      stopped-but-unreleased instance still bills for its disks. US export controls apply to the
+      hardware available (H20-class).
+
+  # NEBIUS — PROMOTED TO PHASE 1 AND ENABLED (owner decision 2026-10-16: Verda + Nebius replace
+  # RunPod). It was `phase: 2, enabled: false` while its API shape was unverified and its
+  # credential absent; the shape is now read from the vendor's published OpenAPI document and
+  # pinned in `gpuproviders`, so the row no longer has to hold the lane shut.
+  #
+  # IT STILL CANNOT LAUNCH WITHOUT A CREDENTIAL, and that is the right kind of gate: the authorized
+  # key is an owner action (Owner 34), `configured()` is False without it, and the race skips an
+  # unconfigured provider. `enabled: true` says "this lane is open"; the credential says "and it
+  # can serve". Those are different claims and only the second one is missing.
+  - id: nebius
+    class: gpu
+    status: active
+    enabled: true
+    phase: 1
+    # Nebius Group N.V. is DUTCH (Amsterdam) — verified 2026-10-14 — so `hq_country: NL` makes it
+    # EU-incorporated and `regionmap.residency_providers` would derive it as EU-sovereign.
+    hq_country: NL
+    regions: [eu]
+    # SECOND EU PROVIDER, BEHIND VERDA (owner decision 7). Its place in the preference order is in
+    # `FRUTEBOX_REGION_PROVIDERS` / `regionmap._DEFAULT`, not here: this row says what it IS, the map
+    # says who is asked first.
+    #
+    # HELD FROM RESIDENCY-LOCKED WORK, and that is a decision recorded rather than taken. Nebius was
+    # spun out of Yandex N.V. (Russian assets sold July 2024, international business renamed August
+    # 2024). It is Dutch-incorporated, so the hq_country derivation alone would admit it to
+    # EU-sovereign work — and whether a Yandex-descended entity may serve legally pinned EU traffic
+    # is the same class of question the owner reserved for themselves on `kandinsky-5.0`. The
+    # owner's own instruction said strict-EU-residency prefers Verda and Nebius takes non-residency
+    # overflow and the frontier/large models.
+    #
+    # CLEARED BY THE OWNER, 2026-10-20: "Nebius may run EU-locked work; remove the residency hold."
+    # The question the hold was holding for has been answered, so the flag goes rather than being
+    # left `false` with the prose still arguing for it — a held provider nobody can tell is held is
+    # worse than either state. What still gates placement is the thing that is checked rather than
+    # declared: `_assert_eu_project` reads the project's own region from IAM before any create, and
+    # eu-north2 stays excluded because it is Iceland (EEA, not EU).
+    api_base: https://api.nebius.cloud
+    # A SERVICE-ACCOUNT AUTHORIZED KEY, as JSON — not an API token. Nebius IAM issues a key file
+    # holding a key id, a service-account id and a PRIVATE KEY; the client signs a JWT with it and
+    # exchanges that for a short-lived IAM token. So this is ONE env var holding a JSON document,
+    # and `AuthorizedKeyError` is what `configured()` reports when it will not parse.
+    # TWO NAMES, AND THE SECOND IS NOT A SECRET. The authorized key is the credential; the project
+    # id is an account-scoped resource — but it is NOT `derived:`, because an account holds one
+    # project PER REGION and choosing one for the operator would be choosing the jurisdiction the
+    # data lands in. So it is required configuration, read through `_provider_credential` like
+    # everything else, and its region is CHECKED against IAM before any create.
+    env: [NEBIUS_SERVICE_ACCOUNT_KEY, NEBIUS_PROJECT_ID, NEBIUS_SERVICE_ACCOUNT_ID,
+          NEBIUS_PUBLIC_KEY_ID, NEBIUS_PRIVATE_KEY, NEBIUS_PRIVATE_KEY_FILE,
+          NEBIUS_KEY_ID]
+    # EITHER FORM IS A COMPLETE CREDENTIAL — see `ProviderRow.env_groups`. IAM hands you a key id,
+    # an account id and a PEM in three places and never the assembled document, so requiring the
+    # single JSON var meant hand-building JSON around a private key; with the parts present the
+    # provider still reported itself unconfigured. The JSON form is listed first because it is one
+    # secret instead of three, so it is what an empty account is told to set.
+    #
+    # NEBIUS_KEY_ID is declared SO IT CAN BE DIAGNOSED, not because it authenticates: it is the
+    # object-storage access-key id, which the compute API's IAM rejects outright ("Invalid nid
+    # format", measured 2026-10-20). It is in no group, so it never counts towards a complete
+    # credential — it is here only so the loader may recognise it and say which kind of key it
+    # found and which kind it needs.
+    env_groups:
+      - [NEBIUS_SERVICE_ACCOUNT_KEY, NEBIUS_PROJECT_ID]
+      - [NEBIUS_SERVICE_ACCOUNT_ID, NEBIUS_PUBLIC_KEY_ID, NEBIUS_PRIVATE_KEY, NEBIUS_PROJECT_ID]
+      - [NEBIUS_SERVICE_ACCOUNT_ID, NEBIUS_PUBLIC_KEY_ID, NEBIUS_PRIVATE_KEY_FILE, NEBIUS_PROJECT_ID]
+    notes: >-
+      Second EU GPU provider, behind Verda in the preference order. Credential is a JSON document
+      (authorized key id + service account id + RSA private key), signed into a short-lived JWT and
+      exchanged at auth.eu.nebius.com for a 12-hour IAM token — never a static API key. The REST
+      shape is CONFIRMED: read from the vendor's published OpenAPI document
+      (api.nebius.cloud/openapi.json, 2026-10-16), so /compute/v1/instances create/list/get/delete
+      are quoted rather than guessed. The REGION IS A PROPERTY OF THE PROJECT, not of the instance —
+      a create body carries no region at all — so EU placement is enforced by checking the
+      project's spec.region against IAM before creating, and eu-north2 is excluded because it is
+      ICELAND (EEA, not EU). The boot disk is always VM-MANAGED so the vendor deletes it with the
+      instance. CLEARED FOR EU-RESIDENCY-LOCKED WORK by the owner on 2026-10-20 (the Yandex-lineage
+      question is answered); it shares EU work with Verda on price and availability, and still
+      carries the frontier/large models needing H200/B200.
+      LIVE CALL MADE 2026-10-18 (Owner 34 landed): the authorized key signs, exchanges for an IAM
+      token, and the adapter created and terminated a real instance
+      (computeinstance-e04fk8xszm6whg8fss) in project default-project-eu-west2. Two shapes only a
+      live call could settle: the boot disk is a NAMED resource wrapping its own spec, and the
+      public image catalog requires a region parameter.
+      WHICH EU PROJECT TO USE, MEASURED 2026-10-20. The account holds one project per region and
+      their GPU catalogues are NOT the same, which is what made this provider look broken: the
+      configured project was eu-west2, whose catalogue offers gpu-b300-sxm AND NOTHING ELSE, so
+      "the cheapest EU single-GPU preset" could only ever be a 1xB300 - and that preset goes
+      STARTING -> STOPPED after ~5m20s with no status message, no operation record and no serial
+      console (the API exposes none). eu-north1 publishes 17 GPU presets including single-GPU
+      L40S, H100 and H200; on the identical code path, image family and discovered subnet an
+      L40S-a/1gpu reached RUNNING in 78 seconds. So the B300 churn is vendor-side capacity for
+      this account in that region, not configuration - and FRUTEBOX_NEBIUS_PROJECT_ID should name
+      the eu-north1 project. Catalogue per region: eu-north1 = L40S/H100/H200/GB300 (17 presets),
+      eu-west1 = H200 only, eu-west2 = B300 only, eu-south1 = RTX6000-Ada only.
+      MULTI-REGION: the vendor's EU regions are eu-north1 (Finland), eu-west1 and eu-west2
+      (France); eu-north2 is Iceland and excluded. The REGION IS A PROPERTY OF THE PROJECT - a
+      create body carries none - and this account's project is eu-west2, verified against IAM
+      before any create. The project id is discoverable from the service account's own profile
+      (/iam/v1/profiles -> serviceAccountProfile.info.metadata.parentId).
+      PRICE: the vendor publishes no price LIST but DOES price a configuration, via
+      /billing/v1alpha1/calculators/estimate - 9.5/hr for the one qualifying EU single-GPU preset
+      (gpu-b300-sxm/1gpu-24vcpu-346gb) on 2026-10-18.
+
+  - id: hetzner
+    class: compute
+    status: backup
+    enabled: false
+    phase: 2
+    hq_country: DE
+    regions: [eu]
+    api_base: https://api.hetzner.cloud/v1
+    env: [HETZNER_API_TOKEN]
+
+  - id: vultr
+    class: compute
+    status: backup
+    enabled: false
+    phase: 2
+    hq_country: US
+    regions: [us]
+    api_base: https://api.vultr.com/v2
+    env: [VULTR_API_KEY]
+
+  # OFF on_hold 2026-09-21. The readme records azure "STRUCK FROM THIS LIST (supervisor
+  # correction 2026-09-12)", and the owner's 2026-09-08 ruling puts the GCP + Azure TEE lane in
+  # PHASE 1 — the readme is authoritative over this file on that point.
+  #
+  # `enabled: false` is not a hedge: plan 28 §A3's `HyperscalerConfidentialProvider` does not
+  # exist yet, so nothing can resolve or launch this. The row exists so the credential has
+  # somewhere to live when the service principal is PUT, and so the doctor reports it instead of
+  # omitting it — a provider missing from this file does not report as broken, it does not
+  # report at all. The lane also stays unreachable unless STEVAI_TEE_ALLOW_HYPERSCALER=true.
+  # OWNER RULING 2026-09-24 — AZURE IS ALSO THE AUSTRALIA LANE, AND THAT IS A SECOND LANE.
+  # Sharon AI is ELIMINATED from the roster and Hyperstack is DROPPED; Australia moves to Azure.
+  # The row below is the TEE lane and does NOT serve that: it is `class: tee`, so the class gate in
+  # `nodewake` will never place a general GPU pod on it. The general-purpose Australia lane is a
+  # SEPARATE row with its own class and its own `AZURE_POD_SPEC`, and one spec cannot serve both —
+  # a TEE instance type and a general GPU instance type are different machines.
+  #
+  # DELIBERATELY NOT ADDED AS A ROW YET. Owner: "do not build the Azure lane yet." A disabled row
+  # is one edit away from being enabled, and a lane with no spec of its own is exactly what the
+  # 2026-09-24 ruling on `VAST_POD_SPEC` forbids — a provider that borrows another's spec deploys
+  # the wrong machine and bills for it. QUEUED BEHIND `LAMBDA_POD_SPEC` and `DATACRUNCH_POD_SPEC`,
+  # in that order.
+  #
+  # `SHARONAI_API_KEY` has no row here and no code reader, but IS set on all three live gateways.
+  # OWNER RULING 2026-09-24: IT STAYS FOR NOW, and the reason is recorded so nobody removes it as
+  # tidy-up or leaves it as forgotten drift. Sharon AI is ELIMINATED from the roster but PERMITTED
+  # SHORT-TERM while the Azure lane is built, and it is not in `WARMPOOL_PROVIDERS`, so the key is
+  # INERT rather than drift: nothing reads it, and the race cannot reach the provider.
+  # REMOVE IT WHEN THE AZURE LANE IS LIVE. Until then it is also one of the 13 provider keys that
+  # readme rule 9 says belong on the DIRECTORY and not on the gateways (recorded 2026-09-17), so
+  # removing it later closes that divergence too.
+  - id: azure
+    class: tee
+    status: emerging
+    enabled: false
+    phase: 1
+    hq_country: US
+    regions: [eu, us]
+    api_base: https://management.azure.com
+    env: [AZURE_TEE_TENANT_ID, AZURE_TEE_CLIENT_ID, AZURE_TEE_CLIENT_SECRET, AZURE_TEE_SUBSCRIPTION_ID]
+    notes: >-
+      Standard_NCCadsH100v5, typically needing a one-off quota request. Unreachable unless
+      STEVAI_TEE_ALLOW_HYPERSCALER=true (default off), so it incurs nothing until an org sets
+      require_tee. Provider class still to be built (28 §A3).
+
+  # GCP CONFIDENTIAL H100 — THE SECOND HALF OF THE TEE PATH THE OWNER NAMED (2026-10-14: "the TEE
+  # path (Phala+GCP)").
+  #
+  # WHY THIS ROW DID NOT EXIST, WHICH IS THE WHOLE FINDING. `gcp` was ALREADY in
+  # `tee.HYPERSCALER_TEE_PROVIDERS`, so the policy half was right and the module's own docstring
+  # said "Azure and GCP are capable but gated by ALLOW_HYPERSCALER". But
+  # `provider_can_host_tee` finishes by asking the REGISTRY for a `class: tee` row, and there was
+  # no `gcp` row of any class — so `provider_can_host_tee("gcp")` returned False even with
+  # STEVAI_TEE_ALLOW_HYPERSCALER=true. Measured, not read: with the flag ON, phala=True,
+  # azure=True, gcp=False. The gate was closed by an absent row rather than by a decision, which
+  # is the shape that reads as a policy and is not one.
+  #
+  # `enabled: false`, and that is NOT a hedge — it is 08-A's own instruction. The plan lists GCP
+  # as "4) GCP confidential H100 (*verify GA at build; preview → disabled*)", and nothing here
+  # can verify GA. So the row exists (the doctor reports it, the credential has somewhere to
+  # live, routing can see it) and it cannot launch anything until an owner both VERIFIES GA and
+  # enables it. A provider missing from this file does not report as broken — it does not report
+  # at all, which is how this gap survived.
+  #
+  # Reachable only when STEVAI_TEE_ALLOW_HYPERSCALER=true (default off), exactly like azure:
+  # cloud-MEDIATED attestation is a deeper lock-in than renting, so the direct-NRAS lane (phala)
+  # sorts first in `allowed_tee_providers` even when this is switched on. Credentials by env name
+  # only — never committed, never a cloud KMS or Secret Manager (rule 10).
+  - id: gcp
+    class: tee
+    status: emerging
+    enabled: false
+    phase: 1
+    hq_country: US
+    regions: [eu, us]
+    api_base: https://compute.googleapis.com/compute/v1
+    env: [GCP_TEE_PROJECT, GCP_TEE_ZONE, GCP_TEE_SA_JSON]
+    notes: >-
+      Confidential H100 (a3-highgpu / CC mode) on Confidential VMs. VERIFY GA BEFORE ENABLING —
+      08-A says preview means disabled. Unreachable unless STEVAI_TEE_ALLOW_HYPERSCALER=true
+      (default off), so it incurs nothing until an org sets require_tee. Attestation is
+      cloud-MEDIATED, so phala stays the preferred direct-NRAS lane. Provider class still to be
+      built (28 §A3) — this row makes the lane VISIBLE to routing, not launchable.
+
+# ON HOLD — never a launch dependency (readme provider-key placement note). Deliberately NOT
+# rows above, so nothing can enable them by flipping a flag: Lambda, NAVER, Sakura,
+# Spheron, Azure.
+#
+# MAGALU AND BINARYLANE ARE DROPPED, not on hold (owner ruling 2026-09-24). On-hold means "we may
+# yet use this"; dropped means we will not, so leaving either here would be a standing invitation
+# to re-enable something the owner removed. Neither ever had a row, a code reader or an adapter.
+# `MAGALU_API_KEY` was never set on any service. `BINARYLANE_API_TOKEN` WAS set on all three
+# gateways and has been removed from them.
+#
+# Z1 IS ALSO DROPPED (owner ruling 2026-09-24), and it is the clearest case yet for checking the
+# real variable names before removing anything: the ruling named `Z1_ACCESS_KEY_ID` and
+# `Z1_SECRET_ACCESS_KEY`, but the live names were `Z1_S3_ACCESS_KEY` and `Z1_S3_SECRET_KEY`.
+# Removing exactly what was named would have deleted `Z1_S3_ENDPOINT` and LEFT BOTH CREDENTIALS
+# on all three gateways, while reporting the job done. All three are removed.
+on_hold: [naver, sakura, spheron]