docs: remove iii prefix from some migrated workers

docs/next/creating-workers/http.mdx

@@ -1,20 +1,20 @@
 ---
 title: "HTTP"
-description: "Expose functions as HTTP endpoints with the iii-http worker."
+description: "Expose functions as HTTP endpoints with the http worker."
 owner: "devrel"
 type: "how-to"
 ---
 
-The `iii-http` worker exposes your functions as HTTP endpoints, turning a function into a REST route
+The `http` worker exposes your functions as HTTP endpoints, turning a function into a REST route
 without standing up a separate web server.
 
 ```bash
-iii worker add iii-http
+iii worker add http
 ```
 
 <Note>
   This page is a quick tour. For path patterns, methods, headers, and response handling, see the
-  [iii-http worker docs](https://workers.iii.dev/workers/iii-http). The worker's server settings
+  [http worker docs](https://workers.iii.dev/workers/http). The worker's server settings
   (port, host, CORS, timeouts) are managed at runtime through the
   [configuration worker](../using-iii/configuration).
 </Note>
@@ -139,7 +139,7 @@ iii worker add ./my-worker
 ```
 
 For path patterns, request and response shapes, and the other configuration options, see the
-[iii-http worker docs](https://workers.iii.dev/workers/iii-http).
+[http worker docs](https://workers.iii.dev/workers/http).
 
 ## Calling the endpoint
 

docs/next/creating-workers/http.mdx.skill.md

@@ -1,16 +1,16 @@
 <!-- generated by iii-skill-render. DO NOT EDIT (changes here are overwritten on the next render). Edit docs/next/creating-workers/http.mdx. -->
 
 
-The `iii-http` worker exposes your functions as HTTP endpoints, turning a function into a REST route
+The `http` worker exposes your functions as HTTP endpoints, turning a function into a REST route
 without standing up a separate web server.
 
 ```bash
-iii worker add iii-http
+iii worker add http
 ```
 
 <Note>
   This page is a quick tour. For path patterns, methods, headers, and response handling, see the
-  [iii-http worker docs](https://workers.iii.dev/workers/iii-http). The worker's server settings
+  [http worker docs](https://workers.iii.dev/workers/http). The worker's server settings
   (port, host, CORS, timeouts) are managed at runtime through the
   [configuration worker](../using-iii/configuration).
 </Note>
@@ -135,7 +135,7 @@ iii worker add ./my-worker
 ```
 
 For path patterns, request and response shapes, and the other configuration options, see the
-[iii-http worker docs](https://workers.iii.dev/workers/iii-http).
+[http worker docs](https://workers.iii.dev/workers/http).
 
 ## Calling the endpoint
 

docs/next/creating-workers/queues.mdx

@@ -1,18 +1,18 @@
 ---
 title: "Queues"
 description:
-  "Async job processing with named topics, retries, and dead-letter support via the iii-queue
+  "Async job processing with named topics, retries, and dead-letter support via the queue
   worker."
 owner: "devrel"
 type: "how-to"
 ---
 
-The `iii-queue` worker decouples producers from consumers: a function publishes a message to a named
+The `queue` worker decouples producers from consumers: a function publishes a message to a named
 topic and returns right away, and any function subscribed to that topic processes the message in the
 background, with retries and a dead-letter queue (DLQ) for messages that keep failing.
 
 ```bash
-iii worker add iii-queue
+iii worker add queue
 ```
 
 <Note>
@@ -27,10 +27,10 @@ number of retries then you can use `TriggerAction.Enqueue` to place that operati
 
 ### Creating a Queue
 
-Queues are defined in the `iii-queue` worker's config under `queue_configs`:
+Queues are defined in the `queue` worker's config under `queue_configs`:
 
 ```yaml
-- name: iii-queue
+- name: queue
   config:
     queue_configs:
       email-jobs:

docs/next/creating-workers/queues.mdx.skill.md

@@ -1,12 +1,12 @@
 <!-- generated by iii-skill-render. DO NOT EDIT (changes here are overwritten on the next render). Edit docs/next/creating-workers/queues.mdx. -->
 
 
-The `iii-queue` worker decouples producers from consumers: a function publishes a message to a named
+The `queue` worker decouples producers from consumers: a function publishes a message to a named
 topic and returns right away, and any function subscribed to that topic processes the message in the
 background, with retries and a dead-letter queue (DLQ) for messages that keep failing.
 
 ```bash
-iii worker add iii-queue
+iii worker add queue
 ```
 
 <Note>
@@ -21,10 +21,10 @@ number of retries then you can use `TriggerAction.Enqueue` to place that operati
 
 ### Creating a Queue
 
-Queues are defined in the `iii-queue` worker's config under `queue_configs`:
+Queues are defined in the `queue` worker's config under `queue_configs`:
 
 ```yaml
-- name: iii-queue
+- name: queue
   config:
     queue_configs:
       email-jobs:

docs/next/creating-workers/triggers.mdx

@@ -9,10 +9,10 @@ type: "how-to"
 ## What "writing a trigger" means
 
 A worker uses triggers two ways. Most of the time, you bind the worker's functions by registering a
-trigger on an existing trigger type such as: [`http`](https://workers.iii.dev/workers/iii-http),
-[`cron`](https://workers.iii.dev/workers/iii-cron),
-[queue messages](https://workers.iii.dev/workers/iii-queue),
-[`state` changes](https://workers.iii.dev/workers/iii-state), and any other event source in the
+trigger on an existing trigger type such as: [`http`](https://workers.iii.dev/workers/http),
+[`cron`](https://workers.iii.dev/workers/cron),
+[queue messages](https://workers.iii.dev/workers/queue),
+[`state` changes](https://workers.iii.dev/workers/state), and any other event source in the
 system. Less often, you register a new trigger type from your worker so other workers can bind their
 functions to events your worker emits.
 
@@ -30,10 +30,10 @@ triggers in new workers then refer to [Using iii / Triggers](../using-iii/trigge
 ## Bind a function to an existing trigger type
 
 Most workers consume trigger types that other workers already publish: `http` from
-[iii-http](https://workers.iii.dev/workers/iii-http) to expose a function as an endpoint, `cron`
-from [iii-cron](https://workers.iii.dev/workers/iii-cron) to run a function on a schedule, queue
-triggers from [iii-queue](https://workers.iii.dev/workers/iii-queue) to fire a function on each
-message, `state` from [iii-state](https://workers.iii.dev/workers/iii-state) to react to data
+[http](https://workers.iii.dev/workers/http) to expose a function as an endpoint, `cron`
+from [cron](https://workers.iii.dev/workers/cron) to run a function on a schedule, queue
+triggers from [queue](https://workers.iii.dev/workers/queue) to fire a function on each
+message, `state` from [state](https://workers.iii.dev/workers/state) to react to data
 changes. Bind one of your worker's functions to a trigger type with
 `worker.registerTrigger({ type, function_id, config })`. The worker that publishes the trigger type
 must be connected when you register; otherwise the registration fails.
@@ -146,7 +146,7 @@ Don't confuse trigger _metadata_ with trigger type [_schemas_](#attach-schemas-t
   surfaces this information on request.
 - **Schemas** are set by the **publisher** when declaring the trigger type. They document the JSON
   shapes the consumer interacts with. For example, the `http` type published by
-  [iii-http](https://workers.iii.dev/workers/iii-http) declares:
+  [http](https://workers.iii.dev/workers/http) declares:
   - `config` (what the consumer passes at bind time): `{ api_path, http_method }`.
   - invocation payload (what their bound function receives on each request):
     `{ method, headers, query_params, body }`.
@@ -190,11 +190,11 @@ The trigger type can be torn down at any point during runtime with
 See the [Unregister a Trigger Type](#unregister-a-trigger-type) section below for per-language
 signatures.
 
-### Example: A mini `iii-http` from scratch
+### Example: A mini `http` from scratch
 
 {/* TODO: Review against real SDK/CLI surface (now, and post-sdk rework, separately) */}
 
-The example below sketches a tiny version of [iii-http](https://workers.iii.dev/workers/iii-http),
+The example below sketches a tiny version of [http](https://workers.iii.dev/workers/http),
 the worker that publishes the real `http` trigger type. The publisher worker:
 
 1. Declares an HTTP-shaped trigger type called `mini-http`

docs/next/creating-workers/triggers.mdx.skill.md

@@ -4,10 +4,10 @@
 ## What "writing a trigger" means
 
 A worker uses triggers two ways. Most of the time, you bind the worker's functions by registering a
-trigger on an existing trigger type such as: [`http`](https://workers.iii.dev/workers/iii-http),
-[`cron`](https://workers.iii.dev/workers/iii-cron),
-[queue messages](https://workers.iii.dev/workers/iii-queue),
-[`state` changes](https://workers.iii.dev/workers/iii-state), and any other event source in the
+trigger on an existing trigger type such as: [`http`](https://workers.iii.dev/workers/http),
+[`cron`](https://workers.iii.dev/workers/cron),
+[queue messages](https://workers.iii.dev/workers/queue),
+[`state` changes](https://workers.iii.dev/workers/state), and any other event source in the
 system. Less often, you register a new trigger type from your worker so other workers can bind their
 functions to events your worker emits.
 
@@ -25,10 +25,10 @@ triggers in new workers then refer to [Using iii / Triggers](../using-iii/trigge
 ## Bind a function to an existing trigger type
 
 Most workers consume trigger types that other workers already publish: `http` from
-[iii-http](https://workers.iii.dev/workers/iii-http) to expose a function as an endpoint, `cron`
-from [iii-cron](https://workers.iii.dev/workers/iii-cron) to run a function on a schedule, queue
-triggers from [iii-queue](https://workers.iii.dev/workers/iii-queue) to fire a function on each
-message, `state` from [iii-state](https://workers.iii.dev/workers/iii-state) to react to data
+[http](https://workers.iii.dev/workers/http) to expose a function as an endpoint, `cron`
+from [cron](https://workers.iii.dev/workers/cron) to run a function on a schedule, queue
+triggers from [queue](https://workers.iii.dev/workers/queue) to fire a function on each
+message, `state` from [state](https://workers.iii.dev/workers/state) to react to data
 changes. Bind one of your worker's functions to a trigger type with
 `worker.registerTrigger({ type, function_id, config })`. The worker that publishes the trigger type
 must be connected when you register; otherwise the registration fails.
@@ -141,7 +141,7 @@ Don't confuse trigger _metadata_ with trigger type [_schemas_](#attach-schemas-t
   surfaces this information on request.
 - **Schemas** are set by the **publisher** when declaring the trigger type. They document the JSON
   shapes the consumer interacts with. For example, the `http` type published by
-  [iii-http](https://workers.iii.dev/workers/iii-http) declares:
+  [http](https://workers.iii.dev/workers/http) declares:
   - `config` (what the consumer passes at bind time): `{ api_path, http_method }`.
   - invocation payload (what their bound function receives on each request):
     `{ method, headers, query_params, body }`.
@@ -185,11 +185,11 @@ The trigger type can be torn down at any point during runtime with
 See the [Unregister a Trigger Type](#unregister-a-trigger-type) section below for per-language
 signatures.
 
-### Example: A mini `iii-http` from scratch
+### Example: A mini `http` from scratch
 
 {/* TODO: Review against real SDK/CLI surface (now, and post-sdk rework, separately) */}
 
-The example below sketches a tiny version of [iii-http](https://workers.iii.dev/workers/iii-http),
+The example below sketches a tiny version of [http](https://workers.iii.dev/workers/http),
 the worker that publishes the real `http` trigger type. The publisher worker:
 
 1. Declares an HTTP-shaped trigger type called `mini-http`

docs/next/creating-workers/worker-manifest.mdx

@@ -154,8 +154,8 @@ against the registry.
 
 ```yaml
 dependencies:
-  iii-http: "^0.20"
-  iii-state: "^0.20"
+  http: "^0.20"
+  state: "^0.20"
 ```
 
 Rules:

docs/next/creating-workers/worker-manifest.mdx.skill.md

@@ -150,8 +150,8 @@ against the registry.
 
 ```yaml
 dependencies:
-  iii-http: "^0.20"
-  iii-state: "^0.20"
+  http: "^0.20"
+  state: "^0.20"
 ```
 
 Rules:

docs/next/how-to/schedule-cron-task.mdx

@@ -1,8 +1,8 @@
 ---
 title: "Schedule a cron task"
-description: "Run a function on a recurring schedule with the iii-cron trigger type."
+description: "Run a function on a recurring schedule with the cron trigger type."
 owner: "devrel"
 type: "how-to"
 ---
 
-{/* TODO: write the how-to. Cover installing/enabling iii-cron, registering a function, binding it to a `cron` trigger with a schedule expression, verifying it fires, common schedule strings, timezone behaviour, what happens on overlap (skip vs queue), and how to manually invoke for testing. */}
+{/* TODO: write the how-to. Cover installing/enabling cron, registering a function, binding it to a `cron` trigger with a schedule expression, verifying it fires, common schedule strings, timezone behaviour, what happens on overlap (skip vs queue), and how to manually invoke for testing. */}

docs/next/how-to/schedule-cron-task.mdx.skill.md

@@ -3,4 +3,4 @@
 # Schedule a cron task
 
 
-{/* TODO: write the how-to. Cover installing/enabling iii-cron, registering a function, binding it to a `cron` trigger with a schedule expression, verifying it fires, common schedule strings, timezone behaviour, what happens on overlap (skip vs queue), and how to manually invoke for testing. */}
+{/* TODO: write the how-to. Cover installing/enabling cron, registering a function, binding it to a `cron` trigger with a schedule expression, verifying it fires, common schedule strings, timezone behaviour, what happens on overlap (skip vs queue), and how to manually invoke for testing. */}

docs/next/quickstart.mdx

@@ -138,7 +138,7 @@ Start by adding the state worker, which gives every function access to a persist
 From the folder containing iii's `config.yaml` run:
 
 ```bash
-iii worker add iii-state
+iii worker add state
 ```
 
 Now open `workers/math-worker/src/math_worker.py` in your code editor and uncomment the state block so
@@ -197,7 +197,7 @@ Now let's add an HTTP worker to expose your functions as REST endpoints.
 From the folder containing iii's `config.yaml` run:
 
 ```bash
-iii worker add iii-http
+iii worker add http
 ```
 
 Open `workers/caller-worker/src/worker.ts` and uncomment the HTTP block at the bottom of the file:

docs/next/quickstart.mdx.skill.md

@@ -134,7 +134,7 @@ Start by adding the state worker, which gives every function access to a persist
 From the folder containing iii's `config.yaml` run:
 
 ```bash
-iii worker add iii-state
+iii worker add state
 ```
 
 Now open `workers/math-worker/src/math_worker.py` in your code editor and uncomment the state block so
@@ -193,7 +193,7 @@ Now let's add an HTTP worker to expose your functions as REST endpoints.
 From the folder containing iii's `config.yaml` run:
 
 ```bash
-iii worker add iii-http
+iii worker add http
 ```
 
 Open `workers/caller-worker/src/worker.ts` and uncomment the HTTP block at the bottom of the file:

docs/next/reference/engine-protocol.mdx

@@ -99,7 +99,7 @@ functions (`HttpInvocationRef`); leave it `null` for in-process handlers.
 ```
 
 `config` is the per-trigger-type configuration; the shape is defined by whatever worker advertised
-that `trigger_type` (e.g. `iii-http` for `http` triggers). The engine responds with a
+that `trigger_type` (e.g. `http` for `http` triggers). The engine responds with a
 `TriggerRegistrationResult` carrying an optional `error: ErrorBody`.
 
 ## `RegisterTriggerType`
@@ -190,7 +190,7 @@ call and surfaces this code to the caller), `function_not_found`, `function_not_
 | ---------------------------------------- | -------------------------------------------------------- |
 | omitted / `null`                         | Synchronous; the worker replies with `InvocationResult`. |
 | `{ "type": "void" }`                     | Fire-and-forget; no `invocation_id`, no reply.           |
-| `{ "type": "enqueue", "queue": "math" }` | Route through the named queue (provided by `iii-queue`). |
+| `{ "type": "enqueue", "queue": "math" }` | Route through the named queue (provided by `queue`). |
 
 ## Invocation lifecycle
 

docs/next/reference/engine-protocol.mdx.skill.md

@@ -97,7 +97,7 @@ functions (`HttpInvocationRef`); leave it `null` for in-process handlers.
 ```
 
 `config` is the per-trigger-type configuration; the shape is defined by whatever worker advertised
-that `trigger_type` (e.g. `iii-http` for `http` triggers). The engine responds with a
+that `trigger_type` (e.g. `http` for `http` triggers). The engine responds with a
 `TriggerRegistrationResult` carrying an optional `error: ErrorBody`.
 
 ## `RegisterTriggerType`
@@ -188,7 +188,7 @@ call and surfaces this code to the caller), `function_not_found`, `function_not_
 | ---------------------------------------- | -------------------------------------------------------- |
 | omitted / `null`                         | Synchronous; the worker replies with `InvocationResult`. |
 | `{ "type": "void" }`                     | Fire-and-forget; no `invocation_id`, no reply.           |
-| `{ "type": "enqueue", "queue": "math" }` | Route through the named queue (provided by `iii-queue`). |
+| `{ "type": "enqueue", "queue": "math" }` | Route through the named queue (provided by `queue`). |
 
 ## Invocation lifecycle
 

docs/next/reference/sdk-browser.mdx

@@ -231,7 +231,7 @@ await worker.trigger({
 })
 
 // Enqueue for async processing (the queue must be declared in the
-// iii-queue worker's queue_configs)
+// queue worker's queue_configs)
 const receipt = await worker.trigger({
   function_id: 'process-order',
   payload: { orderId: '123' },

docs/next/reference/sdk-browser.mdx.skill.md

@@ -229,7 +229,7 @@ await worker.trigger({
 })
 
 // Enqueue for async processing (the queue must be declared in the
-// iii-queue worker's queue_configs)
+// queue worker's queue_configs)
 const receipt = await worker.trigger({
   function_id: 'process-order',
   payload: { orderId: '123' },

docs/next/reference/sdk-node.mdx

@@ -266,7 +266,7 @@ await worker.trigger({
 })
 
 // Enqueue for async processing (the queue must be declared in the
-// iii-queue worker's queue_configs)
+// queue worker's queue_configs)
 const receipt = await worker.trigger({
   function_id: 'process-order',
   payload: { orderId: '123' },

docs/next/reference/sdk-node.mdx.skill.md

@@ -264,7 +264,7 @@ await worker.trigger({
 })
 
 // Enqueue for async processing (the queue must be declared in the
-// iii-queue worker's queue_configs)
+// queue worker's queue_configs)
 const receipt = await worker.trigger({
   function_id: 'process-order',
   payload: { orderId: '123' },

docs/next/reference/sdk-rust.mdx

@@ -267,7 +267,7 @@ worker.trigger(TriggerRequest {
     timeout_ms: None,
 }).await?;
 
-// Enqueue (the queue must be declared in the iii-queue worker's
+// Enqueue (the queue must be declared in the queue worker's
 // queue_configs)
 let receipt = worker.trigger(TriggerRequest {
     function_id: "iii::durable::publish".to_string(),

docs/next/reference/sdk-rust.mdx.skill.md

@@ -265,7 +265,7 @@ worker.trigger(TriggerRequest {
     timeout_ms: None,
 }).await?;
 
-// Enqueue (the queue must be declared in the iii-queue worker's
+// Enqueue (the queue must be declared in the queue worker's
 // queue_configs)
 let receipt = worker.trigger(TriggerRequest {
     function_id: "iii::durable::publish".to_string(),