the examples call methods the client has

Twelve ids came from the document's own old->new map; the rest are generated
method spellings the map does not carry, read off the regenerated client.
Neither set follows a search-and-replace: the document renamed 2014 operations
and 21 of those do not reduce to dropping `_v1_` — /tasks and /meet became
`*_app` and `*_app_assets` when the SPA and the API stopped sharing a name,
and `get_v1_team_transactor_api_v1_statistics` drops only the first, the
second being part of the path.

Checked, not assumed: every `.get_*`/`.post_*` an example calls resolves
against the 7519 methods the client exposes.

examples/agent/__main__.py

@@ -1,8 +1,8 @@
 """agent — define one, run it, read the run back.
 
-    POST /v1/agents            post_v1_agents
-    POST /v1/agents/{ref}/run  post_v1_agents_by_ref_run
-    GET  /v1/agents/{ref}/runs get_v1_agents_ref_runs
+    POST /v1/agents            post_agents
+    POST /v1/agents/{ref}/run  post_agents_by_ref_run
+    GET  /v1/agents/{ref}/runs get_agents_by_ref_runs
 
 ``ref`` is the agent's public id (``agent_...``) OR its org-unique name, which
 is why the run and the read below can both use the name we just created without
@@ -29,7 +29,7 @@ def main() -> None:
     with client() as api:
         agents = AgentsApi(api)
 
-        created = agents.post_v1_agents(
+        created = agents.post_agents(
             CreateAgentIn(
                 name=NAME,
                 model=MODEL,
@@ -39,10 +39,10 @@ def main() -> None:
         )
         print(f"created {created.name} ({created.id}) on {created.model}")
 
-        agents.post_v1_agents_by_ref_run(NAME)
+        agents.post_agents_by_ref_run(NAME)
         print("run started")
 
-        runs = agents.get_v1_agents_ref_runs(NAME, limit=5)
+        runs = agents.get_agents_by_ref_runs(NAME, limit=5)
         entries = runs.runs or []
         print(f"{len(entries)} run(s):")
         for entry in entries:

examples/hello/__main__.py

@@ -1,6 +1,6 @@
 """hello — prove the key works.
 
-``GET /v1/keys`` (operationId ``get_v1_keys``): the caller's own API keys.
+``GET /v1/keys`` (operationId ``get_keys``): the caller's own API keys.
 
 This flow's whole job is to FAIL when the key is bad, so the route has to be one
 that actually checks, and that is decided by probing api.hanzo.ai rather than by
@@ -33,7 +33,7 @@ from examples.client import BASE_URL, client, run
 
 def main() -> None:
     with client() as api:
-        listing = KeysApi(api).get_v1_keys()
+        listing = KeysApi(api).get_keys()
 
     keys = listing.keys or []
     print(f"hello from {BASE_URL}")

examples/money/__main__.py

@@ -1,7 +1,7 @@
 """money — what is in the wallet, and what spent it.
 
-    GET /v1/billing/balance   get_v1_billing_balance
-    GET /v1/billing/usage     get_v1_billing_usage
+    GET /v1/billing/balance   get_billing_balance
+    GET /v1/billing/usage     get_billing_usage
 
 Neither call takes an org: both derive the tenant SERVER-side from the token's
 ``owner`` claim, so a key can only ever read its own money. There is no org
@@ -28,8 +28,8 @@ def main() -> None:
     with client() as api:
         billing = BillingApi(api)
         for label, call in (
-            ("balance", billing.get_v1_billing_balance_without_preload_content),
-            ("usage", billing.get_v1_billing_usage_without_preload_content),
+            ("balance", billing.get_billing_balance_without_preload_content),
+            ("usage", billing.get_billing_usage_without_preload_content),
         ):
             response = call()
             body = response.read()

examples/store/__main__.py

@@ -1,8 +1,8 @@
 """store — a KV round-trip: provision a store, read it back, delete it.
 
-    POST   /v1/kv          post_v1_kv         provision
-    GET    /v1/kv/{name}   get_v1_kv_name     read back
-    DELETE /v1/kv/{name}   delete_v1_kv_name  tear down
+    POST   /v1/kv          post_kv         provision
+    GET    /v1/kv/{name}   get_kv_by_name     read back
+    DELETE /v1/kv/{name}   delete_kv_by_name  tear down
 
 This is the PROVISIONING plane. The per-key data plane the spec also describes
 (``/v1/kv/keys/{key}``) is not mounted anywhere — GET 404s and PUT/DELETE 405 at
@@ -29,15 +29,15 @@ def main() -> None:
     with client() as api:
         kv = KvApi(api)
 
-        kv.post_v1_kv(ProvisionRequest(name=NAME))
+        kv.post_kv(ProvisionRequest(name=NAME))
         print(f"provisioned {NAME}")
 
         try:
-            store = kv.get_v1_kv_name(NAME)
+            store = kv.get_kv_by_name(NAME)
             print(f"read back: {store.name} · {store.kind} · status {store.status}")
             print(f"  host {store.host}:{store.port}")
         finally:
-            kv.delete_v1_kv_name(NAME)
+            kv.delete_kv_by_name(NAME)
             print(f"deleted {NAME}")
 
 

examples/tools/__main__.py

@@ -1,6 +1,6 @@
 """tools — list the tools this key can reach.
 
-``GET /v1/tools`` (operationId ``get_v1_tools``), the catalog behind the
+``GET /v1/tools`` (operationId ``get_tools``), the catalog behind the
 MCP surface: each entry is a tool name, its description and its input schema.
 
 A note on the MCP door, because it is easy to pick the wrong one. There is a
@@ -22,7 +22,7 @@ from examples.client import client, run
 
 def main() -> None:
     with client() as api:
-        catalog = ToolsApi(api).get_v1_tools()
+        catalog = ToolsApi(api).get_tools()
 
     tools = catalog.tools or []
     print(f"{len(tools)} tools")