@fleetless/contracts 1.0.0

package/dist/rest.d.ts

@@ -0,0 +1,1989 @@
+import { z } from 'zod';
+/**
+ * REST shapes of the robot resource (spec §11.1). W1 scope: create, list,
+ * get, and the built-in `bridge_state` datapoint read.
+ */
+export declare const robot: z.ZodObject<{
+    id: z.ZodUUID;
+    name: z.ZodString;
+    created_at: z.ZodISODateTime;
+}, z.core.$strip>;
+export type Robot = z.infer<typeof robot>;
+/** What `PATCH /api/robots/:id` answers: the robot as it now stands. */
+export declare const patchRobotResponse: z.ZodObject<{
+    robot: z.ZodObject<{
+        id: z.ZodUUID;
+        name: z.ZodString;
+        created_at: z.ZodISODateTime;
+    }, z.core.$strip>;
+}, z.core.$strip>;
+export type PatchRobotResponse = z.infer<typeof patchRobotResponse>;
+export declare const createRobotRequest: z.ZodObject<{
+    name: z.ZodString;
+}, z.core.$strip>;
+export type CreateRobotRequest = z.infer<typeof createRobotRequest>;
+/**
+ * The robot token binds one bridge to one robot (spec §5). It is returned
+ * exactly once, here; the cloud stores only a hash of it.
+ */
+export declare const robotToken: z.ZodString;
+export declare const createRobotResponse: z.ZodObject<{
+    robot: z.ZodObject<{
+        id: z.ZodUUID;
+        name: z.ZodString;
+        created_at: z.ZodISODateTime;
+    }, z.core.$strip>;
+    token: z.ZodString;
+}, z.core.$strip>;
+export type CreateRobotResponse = z.infer<typeof createRobotResponse>;
+/**
+ * How many things a robot exposes, per kind (spec `2026-08-21-exposure-and-revoke-design` D1).
+ *
+ * **Five numbers, never a sum.** `robotDeletionSummary.slug_count` already made
+ * this call and wrote down why: fold cameras in and the sentence "this deletes
+ * N slugs and M cameras" counts them twice. A list row has the same problem.
+ *
+ * **Counted from the published configuration, and excluding the built-ins.**
+ * `GET /api/robots/:id/exposures` answers *which* slugs and prepends the
+ * three built-in datapoints — `bridge_state`, `robot_details` and
+ * `bridge_pressure` — as `builtin: true`; this answers *how many* and counts
+ * only what somebody configured. So a robot with an empty published config
+ * reports `datapoints: 0` here and three entries there. That is intentional,
+ * and it is written on both sides so the disagreement is never mistaken for a
+ * bug.
+ *
+ * The number is "three" and not "two" as of `bridge_pressure`; the cloud
+ * builds that prefix from `PLANE_BUILTIN_DATAPOINTS` rather than a literal,
+ * so a further built-in moves this count again. Read the count off that set,
+ * not off this sentence, before filing the bug this comment exists to
+ * prevent.
+ */
+export declare const exposureCounts: z.ZodObject<{
+    datapoints: z.ZodNumber;
+    actions: z.ZodNumber;
+    services: z.ZodNumber;
+    publishers: z.ZodNumber;
+    cameras: z.ZodNumber;
+}, z.core.$strip>;
+export type ExposureCounts = z.infer<typeof exposureCounts>;
+/** A robot as listed, with its current built-in `bridge_state`. */
+export declare const robotListItem: z.ZodObject<{
+    bridge_state: z.ZodObject<{
+        online: z.ZodBoolean;
+        latency_ms: z.ZodNullable<z.ZodNumber>;
+    }, z.core.$strip>;
+    exposes: z.ZodObject<{
+        datapoints: z.ZodNumber;
+        actions: z.ZodNumber;
+        services: z.ZodNumber;
+        publishers: z.ZodNumber;
+        cameras: z.ZodNumber;
+    }, z.core.$strip>;
+    id: z.ZodUUID;
+    name: z.ZodString;
+    created_at: z.ZodISODateTime;
+}, z.core.$strip>;
+export type RobotListItem = z.infer<typeof robotListItem>;
+export declare const robotListResponse: z.ZodObject<{
+    robots: z.ZodArray<z.ZodObject<{
+        bridge_state: z.ZodObject<{
+            online: z.ZodBoolean;
+            latency_ms: z.ZodNullable<z.ZodNumber>;
+        }, z.core.$strip>;
+        exposes: z.ZodObject<{
+            datapoints: z.ZodNumber;
+            actions: z.ZodNumber;
+            services: z.ZodNumber;
+            publishers: z.ZodNumber;
+            cameras: z.ZodNumber;
+        }, z.core.$strip>;
+        id: z.ZodUUID;
+        name: z.ZodString;
+        created_at: z.ZodISODateTime;
+    }, z.core.$strip>>;
+}, z.core.$strip>;
+export type RobotListResponse = z.infer<typeof robotListResponse>;
+/**
+ * The REST read of one datapoint. For bridge-captured data `timestamp_ms`
+ * is the capture time at the bridge (spec §6.3); for the cloud-observed
+ * built-in `bridge_state` it is the time the cloud observed the state.
+ */
+export declare const datapointValue: z.ZodObject<{
+    slug: z.ZodString;
+    value: z.ZodUnknown;
+    timestamp_ms: z.ZodNumber;
+}, z.core.$strip>;
+export type DatapointValue = z.infer<typeof datapointValue>;
+/**
+ * One robot in full: what the list shows, plus what only the detail view
+ * needs — which bridge build is connected, why the last hello was refused,
+ * and where the configuration stands (spec §15.2, tab 1).
+ */
+export declare const robotDetailResponse: z.ZodObject<{
+    bridge_version: z.ZodNullable<z.ZodString>;
+    last_hello_error: z.ZodNullable<z.ZodObject<{
+        code: z.ZodString;
+        message: z.ZodString;
+        at: z.ZodISODateTime;
+    }, z.core.$strip>>;
+    config: z.ZodObject<{
+        published_version: z.ZodNullable<z.ZodNumber>;
+        published_at: z.ZodNullable<z.ZodISODateTime>;
+        draft_updated_at: z.ZodNullable<z.ZodISODateTime>;
+        applied_version: z.ZodNullable<z.ZodNumber>;
+        applied_ok: z.ZodNullable<z.ZodBoolean>;
+        applied_errors: z.ZodNullable<z.ZodArray<z.ZodObject<{
+            slug: z.ZodString;
+            kind: z.ZodEnum<{
+                datapoint: "datapoint";
+                action: "action";
+                service: "service";
+                publisher: "publisher";
+                camera: "camera";
+            }>;
+            code: z.ZodString;
+            message: z.ZodString;
+            details: z.ZodOptional<z.ZodRecord<z.ZodString, z.ZodUnknown>>;
+        }, z.core.$strip>>>;
+    }, z.core.$strip>;
+    bridge_state: z.ZodObject<{
+        online: z.ZodBoolean;
+        latency_ms: z.ZodNullable<z.ZodNumber>;
+    }, z.core.$strip>;
+    exposes: z.ZodObject<{
+        datapoints: z.ZodNumber;
+        actions: z.ZodNumber;
+        services: z.ZodNumber;
+        publishers: z.ZodNumber;
+        cameras: z.ZodNumber;
+    }, z.core.$strip>;
+    id: z.ZodUUID;
+    name: z.ZodString;
+    created_at: z.ZodISODateTime;
+}, z.core.$strip>;
+export type RobotDetailResponse = z.infer<typeof robotDetailResponse>;
+/**
+ * The editable configuration. `issues` is recomputed on every read and
+ * write, so the editor never has to guess whether it may publish.
+ *
+ * **`source` is the author's text and `doc` is what it parses to.** Both are
+ * sent because they answer different questions: an editor renders the text a
+ * developer wrote, comments and key order intact, while every other consumer —
+ * the robot page, the MCP tools, the bridge frame — reads the parsed document
+ * and should never have to parse YAML to do it.
+ *
+ * **`doc` is null when the text is valid YAML but not a fleetless document.**
+ * A draft is saved whenever it parses as YAML; publish is the gate that asks
+ * for a document. So a stored draft can genuinely have no document, and `null`
+ * says exactly that: *this text does not currently parse to a configuration*.
+ * It does **not** mean "nothing is configured" — the last published version is
+ * untouched — and a reader that renders a tree from `doc` has to tell those two
+ * apart before it draws anything.
+ *
+ * The alternative was to put the raw parsed YAML value in `doc`. It was
+ * rejected because a reader could then no longer tell whether what it holds is
+ * a document: every consumer would have to re-validate to find out, and the one
+ * that forgot would render a stranger's mapping as a configuration. `null`
+ * forces the question at the point of reading.
+ *
+ * `source` is never null, and that is what makes the pair `doc: null,
+ * source: null` unrepresentable here rather than merely discouraged. A draft
+ * exists from the moment a robot does, before anyone has typed anything; for
+ * that one the server renders the document instead, so a reader always has text
+ * to show and — when there is no document — always has the text that failed to
+ * become one.
+ */
+export declare const configDraftResponse: z.ZodObject<{
+    doc: z.ZodNullable<z.ZodObject<{
+        fleetless: z.ZodLiteral<1>;
+        messages: z.ZodOptional<z.ZodRecord<z.ZodString, z.ZodUnknown>>;
+        datapoints: z.ZodOptional<z.ZodRecord<z.ZodString, z.ZodObject<{
+            topic: z.ZodString;
+            type: z.ZodString;
+            field: z.ZodOptional<z.ZodString>;
+            rate_throttle_hz: z.ZodOptional<z.ZodNumber>;
+            description: z.ZodOptional<z.ZodString>;
+            numeric: z.ZodOptional<z.ZodObject<{
+                scale: z.ZodOptional<z.ZodNumber>;
+                offset: z.ZodOptional<z.ZodNumber>;
+                unit: z.ZodOptional<z.ZodString>;
+                decimals: z.ZodOptional<z.ZodNumber>;
+            }, z.core.$strict>>;
+            retention: z.ZodOptional<z.ZodObject<{
+                enabled: z.ZodOptional<z.ZodBoolean>;
+                interval_seconds: z.ZodOptional<z.ZodNumber>;
+                max_buffer_values: z.ZodOptional<z.ZodNumber>;
+            }, z.core.$strict>>;
+            chart: z.ZodOptional<z.ZodObject<{
+                y_min: z.ZodOptional<z.ZodNumber>;
+                y_max: z.ZodOptional<z.ZodNumber>;
+                style: z.ZodOptional<z.ZodEnum<{
+                    line: "line";
+                    step: "step";
+                }>>;
+                default_window_minutes: z.ZodOptional<z.ZodNumber>;
+            }, z.core.$strict>>;
+            alerts: z.ZodOptional<z.ZodRecord<z.ZodString, z.ZodObject<{
+                condition: z.ZodObject<{
+                    fire_at: z.ZodUnion<readonly [z.ZodNumber, z.ZodString, z.ZodBoolean]>;
+                    resolve_at: z.ZodOptional<z.ZodNumber>;
+                }, z.core.$strict>;
+                severity: z.ZodOptional<z.ZodEnum<{
+                    error: "error";
+                    warning: "warning";
+                }>>;
+                name: z.ZodOptional<z.ZodString>;
+                enabled: z.ZodOptional<z.ZodBoolean>;
+            }, z.core.$strict>>>;
+        }, z.core.$strict>>>;
+        actions: z.ZodOptional<z.ZodRecord<z.ZodString, z.ZodObject<{
+            ros_name: z.ZodString;
+            type: z.ZodString;
+            message: z.ZodOptional<z.ZodUnknown>;
+            parameters: z.ZodOptional<z.ZodRecord<z.ZodString, z.ZodObject<{
+                type: z.ZodEnum<{
+                    string: "string";
+                    bool: "bool";
+                    byte: "byte";
+                    char: "char";
+                    int8: "int8";
+                    uint8: "uint8";
+                    int16: "int16";
+                    uint16: "uint16";
+                    int32: "int32";
+                    uint32: "uint32";
+                    int64: "int64";
+                    uint64: "uint64";
+                    float32: "float32";
+                    float64: "float64";
+                    wstring: "wstring";
+                }>;
+                default: z.ZodOptional<z.ZodUnion<readonly [z.ZodNumber, z.ZodString, z.ZodBoolean]>>;
+                min_value: z.ZodOptional<z.ZodNumber>;
+                max_value: z.ZodOptional<z.ZodNumber>;
+                enum: z.ZodOptional<z.ZodArray<z.ZodUnion<readonly [z.ZodString, z.ZodNumber]>>>;
+                regex: z.ZodOptional<z.ZodString>;
+                description: z.ZodOptional<z.ZodString>;
+            }, z.core.$strict>>>;
+            description: z.ZodOptional<z.ZodString>;
+        }, z.core.$strict>>>;
+        services: z.ZodOptional<z.ZodRecord<z.ZodString, z.ZodObject<{
+            ros_name: z.ZodString;
+            type: z.ZodString;
+            message: z.ZodOptional<z.ZodUnknown>;
+            parameters: z.ZodOptional<z.ZodRecord<z.ZodString, z.ZodObject<{
+                type: z.ZodEnum<{
+                    string: "string";
+                    bool: "bool";
+                    byte: "byte";
+                    char: "char";
+                    int8: "int8";
+                    uint8: "uint8";
+                    int16: "int16";
+                    uint16: "uint16";
+                    int32: "int32";
+                    uint32: "uint32";
+                    int64: "int64";
+                    uint64: "uint64";
+                    float32: "float32";
+                    float64: "float64";
+                    wstring: "wstring";
+                }>;
+                default: z.ZodOptional<z.ZodUnion<readonly [z.ZodNumber, z.ZodString, z.ZodBoolean]>>;
+                min_value: z.ZodOptional<z.ZodNumber>;
+                max_value: z.ZodOptional<z.ZodNumber>;
+                enum: z.ZodOptional<z.ZodArray<z.ZodUnion<readonly [z.ZodString, z.ZodNumber]>>>;
+                regex: z.ZodOptional<z.ZodString>;
+                description: z.ZodOptional<z.ZodString>;
+            }, z.core.$strict>>>;
+            description: z.ZodOptional<z.ZodString>;
+        }, z.core.$strict>>>;
+        publishers: z.ZodOptional<z.ZodRecord<z.ZodString, z.ZodObject<{
+            topic: z.ZodString;
+            type: z.ZodString;
+            message: z.ZodUnknown;
+            parameters: z.ZodOptional<z.ZodRecord<z.ZodString, z.ZodObject<{
+                type: z.ZodEnum<{
+                    string: "string";
+                    bool: "bool";
+                    byte: "byte";
+                    char: "char";
+                    int8: "int8";
+                    uint8: "uint8";
+                    int16: "int16";
+                    uint16: "uint16";
+                    int32: "int32";
+                    uint32: "uint32";
+                    int64: "int64";
+                    uint64: "uint64";
+                    float32: "float32";
+                    float64: "float64";
+                    wstring: "wstring";
+                }>;
+                default: z.ZodOptional<z.ZodUnion<readonly [z.ZodNumber, z.ZodString, z.ZodBoolean]>>;
+                min_value: z.ZodOptional<z.ZodNumber>;
+                max_value: z.ZodOptional<z.ZodNumber>;
+                enum: z.ZodOptional<z.ZodArray<z.ZodUnion<readonly [z.ZodString, z.ZodNumber]>>>;
+                regex: z.ZodOptional<z.ZodString>;
+                description: z.ZodOptional<z.ZodString>;
+            }, z.core.$strict>>>;
+            failsafe: z.ZodObject<{
+                timeout_ms: z.ZodNumber;
+                message: z.ZodUnknown;
+            }, z.core.$strict>;
+            quiet_timeout_ms: z.ZodNumber;
+            description: z.ZodOptional<z.ZodString>;
+        }, z.core.$strict>>>;
+        cameras: z.ZodOptional<z.ZodRecord<z.ZodString, z.ZodObject<{
+            source: z.ZodDiscriminatedUnion<[z.ZodObject<{
+                kind: z.ZodLiteral<"ros">;
+                topic: z.ZodString;
+                type: z.ZodString;
+            }, z.core.$strict>, z.ZodObject<{
+                kind: z.ZodLiteral<"rtsp">;
+                url: z.ZodString;
+                transport: z.ZodOptional<z.ZodEnum<{
+                    tcp: "tcp";
+                    udp: "udp";
+                }>>;
+                credentials: z.ZodOptional<z.ZodObject<{
+                    username: z.ZodOptional<z.ZodString>;
+                    password: z.ZodOptional<z.ZodString>;
+                }, z.core.$strict>>;
+            }, z.core.$strict>, z.ZodObject<{
+                kind: z.ZodLiteral<"mjpeg">;
+                url: z.ZodString;
+                credentials: z.ZodOptional<z.ZodObject<{
+                    username: z.ZodOptional<z.ZodString>;
+                    password: z.ZodOptional<z.ZodString>;
+                }, z.core.$strict>>;
+            }, z.core.$strict>, z.ZodObject<{
+                kind: z.ZodLiteral<"v4l2">;
+                device: z.ZodString;
+            }, z.core.$strict>], "kind">;
+            width: z.ZodNumber;
+            height: z.ZodNumber;
+            fps: z.ZodNumber;
+            bitrate_kbps: z.ZodNumber;
+            snapshot_interval_seconds: z.ZodNumber;
+            description: z.ZodOptional<z.ZodString>;
+        }, z.core.$strict>>>;
+    }, z.core.$strict>>;
+    source: z.ZodString;
+    updated_at: z.ZodNullable<z.ZodISODateTime>;
+    issues: z.ZodArray<z.ZodObject<{
+        path: z.ZodString;
+        slug: z.ZodNullable<z.ZodString>;
+        code: z.ZodString;
+        message: z.ZodString;
+        severity: z.ZodEnum<{
+            error: "error";
+            warning: "warning";
+        }>;
+    }, z.core.$strip>>;
+}, z.core.$strip>;
+export type ConfigDraftResponse = z.infer<typeof configDraftResponse>;
+/**
+ * A write carries the **text only**, and that is the point.
+ *
+ * If it carried both the text and the parsed document, the two could
+ * disagree. Sending only the source makes that unrepresentable on the wire:
+ * the server parses it, and there is exactly one account of what the
+ * configuration says.
+ *
+ * It also settles who owns parsing, and **FL-005 D2 moved that line**. The
+ * sentence here used to read that the console refuses unparsable YAML before it
+ * sends, so a syntax error never reaches the server. That is no longer the
+ * rule: the **server** refuses text that is not valid YAML, with the line and
+ * column, and stores everything else — including valid YAML that is not a
+ * fleetless document, which comes back with `doc: null` and its issues. The
+ * console checks as you type so the answer is immediate; the server checks
+ * because it is the one that decides. Two checks of one question, and the
+ * server's is the one that binds.
+ *
+ * The pair that used to be called a defect — a stored source that does not
+ * parse to its stored document — is now a **represented state**: no document at
+ * all. See `configDraftResponse` above.
+ */
+export declare const putConfigDraftRequest: z.ZodObject<{
+    source: z.ZodString;
+}, z.core.$strip>;
+export type PutConfigDraftRequest = z.infer<typeof putConfigDraftRequest>;
+/** Publishing freezes the draft into the next immutable version. */
+export declare const publishConfigResponse: z.ZodObject<{
+    version: z.ZodNumber;
+    published_at: z.ZodISODateTime;
+}, z.core.$strip>;
+export type PublishConfigResponse = z.infer<typeof publishConfigResponse>;
+export declare const configVersionsResponse: z.ZodObject<{
+    versions: z.ZodArray<z.ZodObject<{
+        version: z.ZodNumber;
+        published_at: z.ZodISODateTime;
+    }, z.core.$strip>>;
+}, z.core.$strip>;
+export type ConfigVersionsResponse = z.infer<typeof configVersionsResponse>;
+/**
+ * One published version, with the text it was published from.
+ *
+ * The text is what makes a version diff readable and a restore honest: a
+ * restore that returned only the document would hand back a configuration
+ * stripped of every comment the author wrote, which is the loss this format
+ * exists to prevent.
+ */
+export declare const configVersionResponse: z.ZodObject<{
+    version: z.ZodNumber;
+    published_at: z.ZodISODateTime;
+    doc: z.ZodObject<{
+        fleetless: z.ZodLiteral<1>;
+        messages: z.ZodOptional<z.ZodRecord<z.ZodString, z.ZodUnknown>>;
+        datapoints: z.ZodOptional<z.ZodRecord<z.ZodString, z.ZodObject<{
+            topic: z.ZodString;
+            type: z.ZodString;
+            field: z.ZodOptional<z.ZodString>;
+            rate_throttle_hz: z.ZodOptional<z.ZodNumber>;
+            description: z.ZodOptional<z.ZodString>;
+            numeric: z.ZodOptional<z.ZodObject<{
+                scale: z.ZodOptional<z.ZodNumber>;
+                offset: z.ZodOptional<z.ZodNumber>;
+                unit: z.ZodOptional<z.ZodString>;
+                decimals: z.ZodOptional<z.ZodNumber>;
+            }, z.core.$strict>>;
+            retention: z.ZodOptional<z.ZodObject<{
+                enabled: z.ZodOptional<z.ZodBoolean>;
+                interval_seconds: z.ZodOptional<z.ZodNumber>;
+                max_buffer_values: z.ZodOptional<z.ZodNumber>;
+            }, z.core.$strict>>;
+            chart: z.ZodOptional<z.ZodObject<{
+                y_min: z.ZodOptional<z.ZodNumber>;
+                y_max: z.ZodOptional<z.ZodNumber>;
+                style: z.ZodOptional<z.ZodEnum<{
+                    line: "line";
+                    step: "step";
+                }>>;
+                default_window_minutes: z.ZodOptional<z.ZodNumber>;
+            }, z.core.$strict>>;
+            alerts: z.ZodOptional<z.ZodRecord<z.ZodString, z.ZodObject<{
+                condition: z.ZodObject<{
+                    fire_at: z.ZodUnion<readonly [z.ZodNumber, z.ZodString, z.ZodBoolean]>;
+                    resolve_at: z.ZodOptional<z.ZodNumber>;
+                }, z.core.$strict>;
+                severity: z.ZodOptional<z.ZodEnum<{
+                    error: "error";
+                    warning: "warning";
+                }>>;
+                name: z.ZodOptional<z.ZodString>;
+                enabled: z.ZodOptional<z.ZodBoolean>;
+            }, z.core.$strict>>>;
+        }, z.core.$strict>>>;
+        actions: z.ZodOptional<z.ZodRecord<z.ZodString, z.ZodObject<{
+            ros_name: z.ZodString;
+            type: z.ZodString;
+            message: z.ZodOptional<z.ZodUnknown>;
+            parameters: z.ZodOptional<z.ZodRecord<z.ZodString, z.ZodObject<{
+                type: z.ZodEnum<{
+                    string: "string";
+                    bool: "bool";
+                    byte: "byte";
+                    char: "char";
+                    int8: "int8";
+                    uint8: "uint8";
+                    int16: "int16";
+                    uint16: "uint16";
+                    int32: "int32";
+                    uint32: "uint32";
+                    int64: "int64";
+                    uint64: "uint64";
+                    float32: "float32";
+                    float64: "float64";
+                    wstring: "wstring";
+                }>;
+                default: z.ZodOptional<z.ZodUnion<readonly [z.ZodNumber, z.ZodString, z.ZodBoolean]>>;
+                min_value: z.ZodOptional<z.ZodNumber>;
+                max_value: z.ZodOptional<z.ZodNumber>;
+                enum: z.ZodOptional<z.ZodArray<z.ZodUnion<readonly [z.ZodString, z.ZodNumber]>>>;
+                regex: z.ZodOptional<z.ZodString>;
+                description: z.ZodOptional<z.ZodString>;
+            }, z.core.$strict>>>;
+            description: z.ZodOptional<z.ZodString>;
+        }, z.core.$strict>>>;
+        services: z.ZodOptional<z.ZodRecord<z.ZodString, z.ZodObject<{
+            ros_name: z.ZodString;
+            type: z.ZodString;
+            message: z.ZodOptional<z.ZodUnknown>;
+            parameters: z.ZodOptional<z.ZodRecord<z.ZodString, z.ZodObject<{
+                type: z.ZodEnum<{
+                    string: "string";
+                    bool: "bool";
+                    byte: "byte";
+                    char: "char";
+                    int8: "int8";
+                    uint8: "uint8";
+                    int16: "int16";
+                    uint16: "uint16";
+                    int32: "int32";
+                    uint32: "uint32";
+                    int64: "int64";
+                    uint64: "uint64";
+                    float32: "float32";
+                    float64: "float64";
+                    wstring: "wstring";
+                }>;
+                default: z.ZodOptional<z.ZodUnion<readonly [z.ZodNumber, z.ZodString, z.ZodBoolean]>>;
+                min_value: z.ZodOptional<z.ZodNumber>;
+                max_value: z.ZodOptional<z.ZodNumber>;
+                enum: z.ZodOptional<z.ZodArray<z.ZodUnion<readonly [z.ZodString, z.ZodNumber]>>>;
+                regex: z.ZodOptional<z.ZodString>;
+                description: z.ZodOptional<z.ZodString>;
+            }, z.core.$strict>>>;
+            description: z.ZodOptional<z.ZodString>;
+        }, z.core.$strict>>>;
+        publishers: z.ZodOptional<z.ZodRecord<z.ZodString, z.ZodObject<{
+            topic: z.ZodString;
+            type: z.ZodString;
+            message: z.ZodUnknown;
+            parameters: z.ZodOptional<z.ZodRecord<z.ZodString, z.ZodObject<{
+                type: z.ZodEnum<{
+                    string: "string";
+                    bool: "bool";
+                    byte: "byte";
+                    char: "char";
+                    int8: "int8";
+                    uint8: "uint8";
+                    int16: "int16";
+                    uint16: "uint16";
+                    int32: "int32";
+                    uint32: "uint32";
+                    int64: "int64";
+                    uint64: "uint64";
+                    float32: "float32";
+                    float64: "float64";
+                    wstring: "wstring";
+                }>;
+                default: z.ZodOptional<z.ZodUnion<readonly [z.ZodNumber, z.ZodString, z.ZodBoolean]>>;
+                min_value: z.ZodOptional<z.ZodNumber>;
+                max_value: z.ZodOptional<z.ZodNumber>;
+                enum: z.ZodOptional<z.ZodArray<z.ZodUnion<readonly [z.ZodString, z.ZodNumber]>>>;
+                regex: z.ZodOptional<z.ZodString>;
+                description: z.ZodOptional<z.ZodString>;
+            }, z.core.$strict>>>;
+            failsafe: z.ZodObject<{
+                timeout_ms: z.ZodNumber;
+                message: z.ZodUnknown;
+            }, z.core.$strict>;
+            quiet_timeout_ms: z.ZodNumber;
+            description: z.ZodOptional<z.ZodString>;
+        }, z.core.$strict>>>;
+        cameras: z.ZodOptional<z.ZodRecord<z.ZodString, z.ZodObject<{
+            source: z.ZodDiscriminatedUnion<[z.ZodObject<{
+                kind: z.ZodLiteral<"ros">;
+                topic: z.ZodString;
+                type: z.ZodString;
+            }, z.core.$strict>, z.ZodObject<{
+                kind: z.ZodLiteral<"rtsp">;
+                url: z.ZodString;
+                transport: z.ZodOptional<z.ZodEnum<{
+                    tcp: "tcp";
+                    udp: "udp";
+                }>>;
+                credentials: z.ZodOptional<z.ZodObject<{
+                    username: z.ZodOptional<z.ZodString>;
+                    password: z.ZodOptional<z.ZodString>;
+                }, z.core.$strict>>;
+            }, z.core.$strict>, z.ZodObject<{
+                kind: z.ZodLiteral<"mjpeg">;
+                url: z.ZodString;
+                credentials: z.ZodOptional<z.ZodObject<{
+                    username: z.ZodOptional<z.ZodString>;
+                    password: z.ZodOptional<z.ZodString>;
+                }, z.core.$strict>>;
+            }, z.core.$strict>, z.ZodObject<{
+                kind: z.ZodLiteral<"v4l2">;
+                device: z.ZodString;
+            }, z.core.$strict>], "kind">;
+            width: z.ZodNumber;
+            height: z.ZodNumber;
+            fps: z.ZodNumber;
+            bitrate_kbps: z.ZodNumber;
+            snapshot_interval_seconds: z.ZodNumber;
+            description: z.ZodOptional<z.ZodString>;
+        }, z.core.$strict>>>;
+    }, z.core.$strict>;
+    source: z.ZodString;
+}, z.core.$strip>;
+export type ConfigVersionResponse = z.infer<typeof configVersionResponse>;
+/**
+ * The cached ROS graph. It survives the bridge going offline on purpose —
+ * a developer keeps configuring while the robot is off; `stale` says the
+ * bridge is not connected right now, `fetched_at` how old the picture is.
+ */
+export declare const introspectionResponse: z.ZodObject<{
+    graph: z.ZodObject<{
+        topics: z.ZodArray<z.ZodObject<{
+            name: z.ZodString;
+            types: z.ZodArray<z.ZodString>;
+        }, z.core.$strip>>;
+        services: z.ZodArray<z.ZodObject<{
+            name: z.ZodString;
+            types: z.ZodArray<z.ZodString>;
+        }, z.core.$strip>>;
+        actions: z.ZodArray<z.ZodObject<{
+            name: z.ZodString;
+            types: z.ZodArray<z.ZodString>;
+        }, z.core.$strip>>;
+        captured_at_ms: z.ZodNumber;
+    }, z.core.$strip>;
+    fetched_at: z.ZodISODateTime;
+    stale: z.ZodBoolean;
+}, z.core.$strip>;
+export type IntrospectionResponse = z.infer<typeof introspectionResponse>;
+export declare const typesResponse: z.ZodObject<{
+    types: z.ZodArray<z.ZodDiscriminatedUnion<[z.ZodObject<{
+        name: z.ZodString;
+        kind: z.ZodLiteral<"msg">;
+        fields: z.ZodArray<z.ZodType<import("./introspection.js").TypeField, unknown, z.core.$ZodTypeInternals<import("./introspection.js").TypeField, unknown>>>;
+    }, z.core.$strip>, z.ZodObject<{
+        name: z.ZodString;
+        kind: z.ZodLiteral<"srv">;
+        request: z.ZodArray<z.ZodType<import("./introspection.js").TypeField, unknown, z.core.$ZodTypeInternals<import("./introspection.js").TypeField, unknown>>>;
+        response: z.ZodArray<z.ZodType<import("./introspection.js").TypeField, unknown, z.core.$ZodTypeInternals<import("./introspection.js").TypeField, unknown>>>;
+    }, z.core.$strip>, z.ZodObject<{
+        name: z.ZodString;
+        kind: z.ZodLiteral<"action">;
+        goal: z.ZodArray<z.ZodType<import("./introspection.js").TypeField, unknown, z.core.$ZodTypeInternals<import("./introspection.js").TypeField, unknown>>>;
+        result: z.ZodArray<z.ZodType<import("./introspection.js").TypeField, unknown, z.core.$ZodTypeInternals<import("./introspection.js").TypeField, unknown>>>;
+        feedback: z.ZodArray<z.ZodType<import("./introspection.js").TypeField, unknown, z.core.$ZodTypeInternals<import("./introspection.js").TypeField, unknown>>>;
+    }, z.core.$strip>], "kind">>;
+}, z.core.$strip>;
+export type TypesResponse = z.infer<typeof typesResponse>;
+/** Fetch (and store) type definitions for this robot from its bridge. */
+export declare const fetchTypesRequest: z.ZodObject<{
+    type_names: z.ZodArray<z.ZodString>;
+}, z.core.$strip>;
+export type FetchTypesRequest = z.infer<typeof fetchTypesRequest>;
+export declare const fetchTypesResponse: z.ZodObject<{
+    types: z.ZodArray<z.ZodDiscriminatedUnion<[z.ZodObject<{
+        name: z.ZodString;
+        kind: z.ZodLiteral<"msg">;
+        fields: z.ZodArray<z.ZodType<import("./introspection.js").TypeField, unknown, z.core.$ZodTypeInternals<import("./introspection.js").TypeField, unknown>>>;
+    }, z.core.$strip>, z.ZodObject<{
+        name: z.ZodString;
+        kind: z.ZodLiteral<"srv">;
+        request: z.ZodArray<z.ZodType<import("./introspection.js").TypeField, unknown, z.core.$ZodTypeInternals<import("./introspection.js").TypeField, unknown>>>;
+        response: z.ZodArray<z.ZodType<import("./introspection.js").TypeField, unknown, z.core.$ZodTypeInternals<import("./introspection.js").TypeField, unknown>>>;
+    }, z.core.$strip>, z.ZodObject<{
+        name: z.ZodString;
+        kind: z.ZodLiteral<"action">;
+        goal: z.ZodArray<z.ZodType<import("./introspection.js").TypeField, unknown, z.core.$ZodTypeInternals<import("./introspection.js").TypeField, unknown>>>;
+        result: z.ZodArray<z.ZodType<import("./introspection.js").TypeField, unknown, z.core.$ZodTypeInternals<import("./introspection.js").TypeField, unknown>>>;
+        feedback: z.ZodArray<z.ZodType<import("./introspection.js").TypeField, unknown, z.core.$ZodTypeInternals<import("./introspection.js").TypeField, unknown>>>;
+    }, z.core.$strip>], "kind">>;
+    unresolved: z.ZodArray<z.ZodString>;
+}, z.core.$strip>;
+export type FetchTypesResponse = z.infer<typeof fetchTypesResponse>;
+/**
+ * What a client can read on this robot: the built-ins plus everything the
+ * published configuration exposes. This is the seed of the generated
+ * per-robot API (§11.2).
+ *
+ * **The OpenAPI rendering exists since the route manifest (`routes.ts`):
+ * `artifacts/openapi.json`, derived from the manifest and these schemas by
+ * `scripts/export-schemas.ts`.**
+ */
+export declare const datapointDescriptor: z.ZodObject<{
+    slug: z.ZodString;
+    builtin: z.ZodBoolean;
+    unit: z.ZodNullable<z.ZodString>;
+    rate_throttle_hz: z.ZodNullable<z.ZodNumber>;
+}, z.core.$strip>;
+export type DatapointDescriptor = z.infer<typeof datapointDescriptor>;
+export declare const datapointListResponse: z.ZodObject<{
+    datapoints: z.ZodArray<z.ZodObject<{
+        slug: z.ZodString;
+        builtin: z.ZodBoolean;
+        unit: z.ZodNullable<z.ZodString>;
+        rate_throttle_hz: z.ZodNullable<z.ZodNumber>;
+    }, z.core.$strip>>;
+}, z.core.$strip>;
+export type DatapointListResponse = z.infer<typeof datapointListResponse>;
+/**
+ * The built-in `robot_details` datapoint (spec §4.3): static properties the
+ * developer maintains. Bounded so one robot cannot become a document store.
+ */
+export declare const robotDetailsDoc: z.ZodRecord<z.ZodString, z.ZodUnion<readonly [z.ZodString, z.ZodNumber, z.ZodBoolean, z.ZodArray<z.ZodUnknown>, z.ZodRecord<z.ZodString, z.ZodUnknown>]>>;
+export type RobotDetailsDoc = z.infer<typeof robotDetailsDoc>;
+/** What `PUT /api/robots/:id/details` answers: the stored document, which is the one that was sent. */
+export declare const putRobotDetailsResponse: z.ZodObject<{
+    details: z.ZodRecord<z.ZodString, z.ZodUnion<readonly [z.ZodString, z.ZodNumber, z.ZodBoolean, z.ZodArray<z.ZodUnknown>, z.ZodRecord<z.ZodString, z.ZodUnknown>]>>;
+}, z.core.$strip>;
+export type PutRobotDetailsResponse = z.infer<typeof putRobotDetailsResponse>;
+export declare const putRobotDetailsRequest: z.ZodObject<{
+    details: z.ZodRecord<z.ZodString, z.ZodUnion<readonly [z.ZodString, z.ZodNumber, z.ZodBoolean, z.ZodArray<z.ZodUnknown>, z.ZodRecord<z.ZodString, z.ZodUnknown>]>>;
+}, z.core.$strip>;
+export type PutRobotDetailsRequest = z.infer<typeof putRobotDetailsRequest>;
+/**
+ * Invoke an action or call a service; parameters by field path (§4.4).
+ *
+ * Flat, keyed by `parameterSpec.name` — see `cloudInvoke.params` for why the
+ * flat form is the one that makes a refusal legible.
+ */
+export declare const invokeRequest: z.ZodObject<{
+    params: z.ZodRecord<z.ZodString, z.ZodUnknown>;
+    patience_ms: z.ZodOptional<z.ZodNumber>;
+}, z.core.$strip>;
+export type InvokeRequest = z.infer<typeof invokeRequest>;
+/**
+ * The answer to an invoke. The job id is informative (§11.3): state is
+ * observed by slug afterwards, over polling or a subscription.
+ */
+/**
+ * The body of a cancel (W6b). **Every field optional, and the body itself may
+ * be absent** — `POST .../cancel` was bodyless before this wave and every
+ * existing caller still sends nothing.
+ *
+ * That is not politeness, it is the W5 defect: a bodyless `POST` carrying
+ * `content-type: application/json` was rejected outright, which made
+ * `cameras.live()` unreachable through the SDK and took `cancel`, publish,
+ * restore, key rotation and member removal with it — unnoticed since W4. A
+ * schema that demands a body would reintroduce it on the one verb that stops
+ * a machine.
+ *
+ * **`.strict()`, and that is the whole point of the shape.** A plain object
+ * strips unknown keys, so a caller who *means* to name a job and misspells the
+ * field — `jobId` for `job_id` — has their id silently removed and gets the
+ * **slug-wide** cancel instead: the most destructive reading of a request they
+ * did not make. Measured in W6b's review: `{"jobId": "<some other job>"}`
+ * answered `200` and stopped the job that was actually running, which nobody
+ * had named. The `?force=true` precedent this route's design borrowed from
+ * fails *safe* on a typo — a misspelled `force` simply does not force.
+ * Stripping here fails unsafe, so unknown keys are refused instead.
+ *
+ * `job_id` absent and `job_id: null` mean the **same** thing here, and that is
+ * deliberate: over REST an absent body is how every caller written before this
+ * wave says "cancel whatever is running". On the socket, `clientCancel.job_id`
+ * is required-and-nullable instead, because a frame is assembled fresh by a
+ * client that has already been updated — there, `null` is a decision and an
+ * omission is a bug.
+ */
+export declare const cancelRequest: z.ZodObject<{
+    job_id: z.ZodOptional<z.ZodNullable<z.ZodUUID>>;
+}, z.core.$strict>;
+export type CancelRequest = z.infer<typeof cancelRequest>;
+/**
+ * The query of a live release (W6b): `DELETE .../live?session_id=<uuid>`.
+ *
+ * A query parameter rather than a body, following `?force=true` on robot
+ * deletion — the precedent this repo already set for "a DELETE that needs one
+ * more fact". A body on a DELETE is carried inconsistently by proxies and by
+ * `fetch` itself, and this call runs from a browser tab that is often closing.
+ *
+ * **`.strict()`, for the reason `cancelRequest` is** — `?sessionid=` instead of
+ * `?session_id=` was measured releasing **both** of an identity's holds and
+ * stranding the other tab, which is precisely the defect this field was added
+ * to remove. A refused typo costs a round trip; a stripped one stops a robot
+ * somebody else is watching.
+ *
+ * Absent means today's meaning: release **all** of this identity's holds on
+ * this camera. A client that has lost its id, or is going away entirely, still
+ * needs a way to let go — it is the blunt form, and it is the one that strands
+ * the identity's other tabs.
+ */
+export declare const releaseLiveQuery: z.ZodObject<{
+    session_id: z.ZodOptional<z.ZodUUID>;
+}, z.core.$strict>;
+export type ReleaseLiveQuery = z.infer<typeof releaseLiveQuery>;
+export declare const invokeResponse: z.ZodObject<{
+    job: z.ZodObject<{
+        id: z.ZodUUID;
+        robot_id: z.ZodUUID;
+        slug: z.ZodString;
+        state: z.ZodEnum<{
+            failed: "failed";
+            running: "running";
+            succeeded: "succeeded";
+            cancelled: "cancelled";
+            lost: "lost";
+        }>;
+        started_at: z.ZodISODateTime;
+        updated_at: z.ZodISODateTime;
+        seq: z.ZodNumber;
+        result: z.ZodNullable<z.ZodUnknown>;
+        error: z.ZodNullable<z.ZodObject<{
+            code: z.ZodString;
+            message: z.ZodString;
+            details: z.ZodOptional<z.ZodUnknown>;
+        }, z.core.$strip>>;
+    }, z.core.$strip>;
+    kind: z.ZodEnum<{
+        action: "action";
+        service: "service";
+    }>;
+}, z.core.$strip>;
+export type InvokeResponse = z.infer<typeof invokeResponse>;
+/** A service call answers with its result directly — no job to observe. */
+export declare const serviceCallResponse: z.ZodObject<{
+    result: z.ZodUnknown;
+}, z.core.$strip>;
+export type ServiceCallResponse = z.infer<typeof serviceCallResponse>;
+/**
+ * **What `POST /api/robots/:id/jobs/:slug` answers, which is one of two
+ * shapes.**
+ *
+ * One route serves both kinds, because a path segment naming the kind would
+ * demand a fact a role grant does not carry. **The slug's kind decides, and
+ * nothing in the request does**: an *action* answers `202` with an
+ * `invokeResponse` the moment the job exists, a *service* answers `200` with
+ * a `serviceCallResponse` once the result is in. They differ only in what the
+ * cloud waits for before it answers.
+ *
+ * The two are told apart without inspecting the status code: `invokeResponse`
+ * carries `kind` and `job`, `serviceCallResponse` carries `result` alone.
+ *
+ * **This union exists so the route can name a response at all.** The entry
+ * carried `response: null` while the handler demonstrably answers something,
+ * which reads in the generated reference as *this route returns nothing* —
+ * the documented absence this project keeps paying for. A `null` there should
+ * mean `204`, and on this route it did not.
+ */
+export declare const invokeOrServiceResponse: z.ZodUnion<readonly [z.ZodObject<{
+    job: z.ZodObject<{
+        id: z.ZodUUID;
+        robot_id: z.ZodUUID;
+        slug: z.ZodString;
+        state: z.ZodEnum<{
+            failed: "failed";
+            running: "running";
+            succeeded: "succeeded";
+            cancelled: "cancelled";
+            lost: "lost";
+        }>;
+        started_at: z.ZodISODateTime;
+        updated_at: z.ZodISODateTime;
+        seq: z.ZodNumber;
+        result: z.ZodNullable<z.ZodUnknown>;
+        error: z.ZodNullable<z.ZodObject<{
+            code: z.ZodString;
+            message: z.ZodString;
+            details: z.ZodOptional<z.ZodUnknown>;
+        }, z.core.$strip>>;
+    }, z.core.$strip>;
+    kind: z.ZodEnum<{
+        action: "action";
+        service: "service";
+    }>;
+}, z.core.$strip>, z.ZodObject<{
+    result: z.ZodUnknown;
+}, z.core.$strip>]>;
+export type InvokeOrServiceResponse = z.infer<typeof invokeOrServiceResponse>;
+export declare const publishRequest: z.ZodObject<{
+    message: z.ZodRecord<z.ZodString, z.ZodUnknown>;
+}, z.core.$strip>;
+export type PublishRequest = z.infer<typeof publishRequest>;
+/**
+ * The **most recent** job on a slug — running or already finished — or null
+ * only when nothing has ever run there.
+ *
+ * It said "the job currently running" until W4's review, and that quietly
+ * made §11.3's first sentence false. The spec offers two equal ways to
+ * observe a slug — *"Polling (REST) oder Subscription (Realtime)"* — but a
+ * route that forgets a job the moment it settles lets a poller see only
+ * `running`, then `null`. Succeeded, failed, cancelled, `lost` and
+ * never-invoked all become the same answer, so §6.1's promise that a lost
+ * job is *said out loud* held for subscribers and silently did not hold for
+ * anyone polling. It is also the recovery `command_outcome_unknown` points
+ * a caller to.
+ *
+ * Read `job.state` to tell a live job from a finished one; that is what the
+ * field is for.
+ */
+export declare const jobResponse: z.ZodObject<{
+    job: z.ZodNullable<z.ZodObject<{
+        id: z.ZodUUID;
+        robot_id: z.ZodUUID;
+        slug: z.ZodString;
+        state: z.ZodEnum<{
+            failed: "failed";
+            running: "running";
+            succeeded: "succeeded";
+            cancelled: "cancelled";
+            lost: "lost";
+        }>;
+        started_at: z.ZodISODateTime;
+        updated_at: z.ZodISODateTime;
+        seq: z.ZodNumber;
+        result: z.ZodNullable<z.ZodUnknown>;
+        error: z.ZodNullable<z.ZodObject<{
+            code: z.ZodString;
+            message: z.ZodString;
+            details: z.ZodOptional<z.ZodUnknown>;
+        }, z.core.$strip>>;
+    }, z.core.$strip>>;
+}, z.core.$strip>;
+export type JobResponse = z.infer<typeof jobResponse>;
+/**
+ * Every job the platform currently believes this robot has — `GET
+ * /api/robots/:id/jobs` (W6b).
+ *
+ * `jobResponse` answers "what is on this slug", which requires knowing the
+ * slug first. That was enough while a job could only exist on a slug the
+ * published configuration named. W6b breaks that assumption twice: a
+ * reconnecting bridge can name a job the cloud has **no row for** and the
+ * cloud adopts it, and a configuration change can leave a job on a slug the
+ * document no longer contains. Both are jobs nobody can ask about, because
+ * asking requires already knowing what to ask for.
+ *
+ * So this route exists to answer the question the per-slug route cannot: not
+ * "is something running here", but "what is this robot doing". A restarted
+ * cloud that has just reconciled a robot's `hello.active_jobs` has exactly
+ * this list and, until now, no way to say it out loud.
+ *
+ * The array is ordered newest first and is **never null**: a robot doing
+ * nothing answers `{ jobs: [] }`. "Nothing is running" and "we did not look"
+ * are different facts, and a nullable list would merge them — the same
+ * distinction `robotDeletionSummary` was made all-required for.
+ *
+ * **At most one entry per slug: the current job there, exactly what
+ * `jobResponse` would answer for that slug.** This is not a history endpoint
+ * and must not become one. The first implementation returned every job the
+ * registry still held — six rows and four complete Fibonacci results after a
+ * few minutes of gate traffic, and unbounded in both count and payload for a
+ * robot that has been working all day. The list would have grown until a
+ * console page carried a robot's entire past, and the one thing it exists to
+ * answer — *what is this robot doing* — would have been the first line of a
+ * scroll.
+ *
+ * A settled job stays visible as its slug's current entry until something
+ * else runs there, which is what makes a job that just failed still findable.
+ * Read `state` to tell a live one from a finished one, exactly as with
+ * `jobResponse`.
+ */
+/**
+ * What a `rate_limited` refusal tells the caller (W6c).
+ *
+ * One number, and it is the only one that matters: **when to come back.** A
+ * limit that says "too many" without saying "in 800 ms" produces a client that
+ * retries immediately, which is the behaviour the limit exists to stop — so
+ * omitting it would make the refusal part of the attack.
+ *
+ * Deliberately **not** carrying the limit, the window, or how many attempts
+ * remain: those describe the defence to whoever is probing it, and none of
+ * them changes what an honest caller does.
+ */
+export declare const rateLimitDetails: z.ZodObject<{
+    retry_after_ms: z.ZodNumber;
+}, z.core.$strip>;
+export type RateLimitDetails = z.infer<typeof rateLimitDetails>;
+/**
+ * Every job this robot's registry currently holds, **ordered newest first by
+ * `started_at`, with `seq` as the tiebreaker** (W7, register rows 2j and 2l).
+ *
+ * The field is named because the previous version of this comment claimed an
+ * order without saying what produced it, and the answer turned out to matter
+ * twice over:
+ *
+ * 1. **`started_at` alone is not a total order.** Two jobs minted in the same
+ *    millisecond sorted against each other arbitrarily — differently on each
+ *    query — so a reader could see one twice and the other not at all. `seq`
+ *    is monotonic in mint order and settles it. Note its scope, which is in
+ *    `job.seq`'s own comment: per cloud process, per run, because job state
+ *    lives in memory and the counter restarts with the registry it orders.
+ * 2. **For an adopted job, `started_at` is adoption time, not the real
+ *    start.** The cloud learns of it at `hello`, having never minted it, and
+ *    has no other honest value to put there. So this list is newest-*known*
+ *    first, and a job the robot has been running for an hour can sit above one
+ *    started a minute ago. Stated rather than smoothed over: the console's own
+ *    "Known running since" wording exists for the same reason, and a contract
+ *    that quietly implies otherwise would send somebody to debug the sort.
+ */
+export declare const robotJobsResponse: z.ZodObject<{
+    jobs: z.ZodArray<z.ZodObject<{
+        id: z.ZodUUID;
+        robot_id: z.ZodUUID;
+        slug: z.ZodString;
+        state: z.ZodEnum<{
+            failed: "failed";
+            running: "running";
+            succeeded: "succeeded";
+            cancelled: "cancelled";
+            lost: "lost";
+        }>;
+        started_at: z.ZodISODateTime;
+        updated_at: z.ZodISODateTime;
+        seq: z.ZodNumber;
+        result: z.ZodNullable<z.ZodUnknown>;
+        error: z.ZodNullable<z.ZodObject<{
+            code: z.ZodString;
+            message: z.ZodString;
+            details: z.ZodOptional<z.ZodUnknown>;
+        }, z.core.$strip>>;
+    }, z.core.$strip>>;
+}, z.core.$strip>;
+export type RobotJobsResponse = z.infer<typeof robotJobsResponse>;
+/**
+ * Every slug of a robot that a role can be granted, **with its kind**.
+ *
+ * The roles matrix was built in W3 against the datapoint list, which was the
+ * only kind that existed. With four kinds it needs one list that names them,
+ * or the matrix silently cannot grant an action.
+ */
+export declare const exposure: z.ZodObject<{
+    slug: z.ZodString;
+    kind: z.ZodEnum<{
+        datapoint: "datapoint";
+        action: "action";
+        service: "service";
+        publisher: "publisher";
+        camera: "camera";
+    }>;
+    builtin: z.ZodBoolean;
+}, z.core.$strip>;
+export type Exposure = z.infer<typeof exposure>;
+export declare const exposureListResponse: z.ZodObject<{
+    exposures: z.ZodArray<z.ZodObject<{
+        slug: z.ZodString;
+        kind: z.ZodEnum<{
+            datapoint: "datapoint";
+            action: "action";
+            service: "service";
+            publisher: "publisher";
+            camera: "camera";
+        }>;
+        builtin: z.ZodBoolean;
+    }, z.core.$strip>>;
+}, z.core.$strip>;
+export type ExposureListResponse = z.infer<typeof exposureListResponse>;
+/**
+ * The response headers a binary snapshot carries, named here so the cloud and
+ * every client agree without negotiating:
+ *
+ * - `Content-Type`      — the image's mime, standard rather than invented.
+ * - `X-Fleetless-Age-Ms`      — how old the frame is, **computed by the cloud**.
+ * - `X-Fleetless-Timestamp-Ms`— the bridge's capture time.
+ * - `X-Fleetless-Width` / `X-Fleetless-Height`.
+ *
+ * A client must take `age_ms` from the header and **never** recompute it as
+ * `Date.now() - timestamp_ms`: the cloud is the one clock that knows how long
+ * it has actually been holding the frame, and recomputing reintroduces the
+ * viewer's clock skew as a source of lying about freshness.
+ */
+export declare const SNAPSHOT_HEADERS: {
+    readonly ageMs: "x-fleetless-age-ms";
+    readonly timestampMs: "x-fleetless-timestamp-ms";
+    readonly width: "x-fleetless-width";
+    readonly height: "x-fleetless-height";
+};
+/**
+ * The metadata an asset upload carries beside its raw body (W7).
+ *
+ * Here rather than as a convention documented on both sides, and the reason is
+ * a scar. W5 shipped `x-fleetless-*` headers the CORS policy did not expose,
+ * so `age_ms` was `null` in **every** browser while the SDK documented `null`
+ * as "nothing captured yet" — a fresh frame reporting as no snapshot at all,
+ * invisible to three test suites because none of them was a browser. And W6b
+ * found the general form: three repos agreeing with each other about a payload
+ * none of them exchanged, each right in its own tests.
+ *
+ * **A string shared by two repos and defined in both is a string that drifts.**
+ * A zod schema cannot validate a header, which is an argument for writing the
+ * names down once, not an argument for writing them down twice.
+ *
+ * `name` is the `package://` URI verbatim for a mesh — the same string
+ * `asset.name` stores, and the same one `urdfCompleteness.missing` reports, so
+ * a failed upload and a missing mesh can be matched by eye.
+ */
+/**
+ * **`name` travels percent-encoded, and that is a fix rather than a
+ * convention** (W7a review, André's decision to fix rather than defer).
+ *
+ * HTTP header values are latin-1 (`http.client` in Python, and the same is
+ * true on the other side). So a texture called `textures/日本語.png` raised a
+ * `UnicodeEncodeError` **inside `urllib`** — a `ValueError`, caught by neither
+ * `HTTPError` nor `URLError` — which propagated to the sync's broad handler
+ * and marked **everything still remaining** as failed. One non-ASCII filename
+ * cost a developer every mesh after it in that sync, with no cause on the
+ * wire. R6 made it ordinary rather than exotic: `.dae` internal names come
+ * from 3D-authoring tools, where non-ASCII is Tuesday.
+ *
+ * The encoding is not invented here. **`GET .../assets/missing?name=` already
+ * carries this exact string percent-encoded**, because a query parameter is
+ * percent-encoded by definition — same value, same wire, question already
+ * answered.
+ *
+ * **It is a SECOND header, and that is the whole design rather than a
+ * detail.** The first version overloaded `name` itself: the producer would
+ * encode, the store would `decodeURIComponent`. That decodes identically for
+ * every name without a `%`, so an **older bridge and a newer cloud agree by
+ * luck** — right up until a name contains `%2f`, which the store would then
+ * silently turn into a `/`. A wire change whose breakage is invisible in the
+ * common case and silent in the uncommon one is the worst of both (Argus-W7a,
+ * reading the contract rather than the code).
+ *
+ * So `name` keeps meaning exactly what it always meant, and `nameEncoded`
+ * carries the percent-encoded UTF-8 form. **The store prefers `nameEncoded`
+ * when present and uses `name` otherwise**, so:
+ *
+ * - an older bridge sends only `name` and behaves exactly as before;
+ * - a newer bridge sends both, and a name it cannot express in latin-1 travels
+ *   intact for the first time;
+ * - no value is ever ambiguous about which encoding it is in.
+ *
+ * A producer that can send `nameEncoded` should send both, so a store older
+ * than this contract keeps working too. Agreement by construction, not by the
+ * absence of a `%`.
+ */
+export declare const ASSET_UPLOAD_HEADERS: {
+    readonly kind: "x-fleetless-asset-kind";
+    readonly name: "x-fleetless-asset-name";
+    readonly nameEncoded: "x-fleetless-asset-name-encoded";
+    readonly syncId: "x-fleetless-sync-id";
+    /**
+     * **Die angekündigte Größe, und sie ist der Grund, warum `asset_too_large`
+     * überhaupt entstehen kann (W9b, DEF-116).**
+     *
+     * Fastifys `bodyLimit` greift im Content-Type-Parser, also **vor** dem
+     * Handler — eine zu große Datei bekam damit ein blankes `413 bad_request`
+     * ohne `limit_bytes` und ohne `size_bytes`, und der strukturierte Fehlercode,
+     * den `assetTooLargeDetails` beschreibt, hatte schlicht keinen erreichbaren
+     * Erzeuger (Momus-W7, M1, an den echten Routenoptionen reproduziert).
+     *
+     * Mit einer angekündigten Größe im Kopf kann die Ablehnung dort entstehen,
+     * wo sie etwas sagen kann: bevor ein Byte gepuffert ist, mit beiden Zahlen.
+     * Und die Bridge erfährt ihre Grenze, ohne 194 MB zu lesen, um sie zu
+     * entdecken — was am 2026-08-18 auf rx1 genau so ausging (DEF-148).
+     *
+     * Der Kopf ist eine **Ankündigung, kein Beweis**: Ein Absender kann lügen.
+     * Der Deckel gilt weiterhin auch am Körper — dies ersetzt die Durchsetzung
+     * nicht, es macht die Absage nur beantwortbar.
+     */
+    readonly size: "x-fleetless-asset-size";
+};
+export declare const cameraDescriptor: z.ZodObject<{
+    slug: z.ZodString;
+    width: z.ZodNumber;
+    height: z.ZodNumber;
+    fps: z.ZodNumber;
+    snapshot_interval_seconds: z.ZodNumber;
+}, z.core.$strip>;
+export type CameraDescriptor = z.infer<typeof cameraDescriptor>;
+export declare const cameraListResponse: z.ZodObject<{
+    cameras: z.ZodArray<z.ZodObject<{
+        slug: z.ZodString;
+        width: z.ZodNumber;
+        height: z.ZodNumber;
+        fps: z.ZodNumber;
+        snapshot_interval_seconds: z.ZodNumber;
+    }, z.core.$strip>>;
+}, z.core.$strip>;
+export type CameraListResponse = z.infer<typeof cameraListResponse>;
+/**
+ * What a viewer needs to join, and **what it costs them to hold**.
+ *
+ * `POST` takes a refcount hold and `DELETE` releases it; the first hold
+ * starts the robot publishing and the last release stops it (§10). A client
+ * that forgets to release keeps a robot streaming to nobody, so the SDK hands
+ * back a `release()` rather than a bare token.
+ *
+ * **`expires_at` is a join deadline, not a session backstop.** A LiveKit
+ * token is checked when a participant connects and not again afterwards, so a
+ * viewer who has already joined keeps receiving video straight past this
+ * moment. Do not design cleanup around it. What actually ends a session is
+ * `release()` together with disconnecting the room, the cloud reconciling the
+ * hold away against LiveKit's real participants, or a revocation kicking the
+ * participant out. This comment previously claimed the opposite and the SDK
+ * inherited the claim from here — a developer reading it would reasonably
+ * have skipped cleanup on purpose.
+ */
+export declare const liveSessionResponse: z.ZodObject<{
+    session_id: z.ZodUUID;
+    url: z.ZodString;
+    room: z.ZodString;
+    token: z.ZodString;
+    expires_at: z.ZodISODateTime;
+}, z.core.$strip>;
+export type LiveSessionResponse = z.infer<typeof liveSessionResponse>;
+/**
+ * The snapshot read **without the bytes**.
+ *
+ * A viewer polling at the camera's interval otherwise re-downloads a whole
+ * image to discover whether a new one exists. This is the cheap question —
+ * *how old is what you have?* — so a client can fetch pixels only when the
+ * timestamp actually moved. It matters most on the console's snapshot view,
+ * which polls continuously while a tab is open.
+ *
+ * `age_ms` is not a convenience: a cached frame served without its age is
+ * indistinguishable from a live one, and §10 makes snapshots deliberately
+ * cheap and therefore deliberately old. `null` values mean nothing has been
+ * captured yet — which is an answer, not an error.
+ */
+export declare const snapshotMetaResponse: z.ZodObject<{
+    slug: z.ZodString;
+    timestamp_ms: z.ZodNullable<z.ZodNumber>;
+    age_ms: z.ZodNullable<z.ZodNumber>;
+    width: z.ZodNullable<z.ZodNumber>;
+    height: z.ZodNullable<z.ZodNumber>;
+    mime: z.ZodNullable<z.ZodString>;
+}, z.core.$strip>;
+export type SnapshotMetaResponse = z.infer<typeof snapshotMetaResponse>;
+/**
+ * **Both history shapes answer the same boundary the same way: `[from, to)`
+ * (W9d, DEF-062 — decision pre-made at the W6 boundary so no wave
+ * re-litigates it).**
+ *
+ * They did not. `samples` was inclusive of `to`, `buckets` exclusive — same
+ * range, same data, opposite answers for a point landing exactly on `to`, and
+ * the buckets answer rendered as a gap tooltipped *"empty — no samples"*.
+ * `sdk/README.md` documented the inclusive notation for the half-open path,
+ * so it was wrong for one of the two whichever way you read it.
+ *
+ * Half-open wins because it is the only rule under which **adjacent windows
+ * tile without overlap**: `[0,10)` then `[10,20)` covers every instant once.
+ * With an inclusive upper bound a sample at exactly `10` belongs to both
+ * windows, and any consumer summing them counts it twice.
+ *
+ * This is a statement about behaviour, not a field — nothing in the shapes
+ * below can enforce it. It is written here because this is the one place both
+ * shapes are defined together, and the cloud's `history-store` and the SDK's
+ * README are the two places that have to agree with it.
+ */
+/**
+ * A history query (§8). `from`/`to` accept **either** a relative expression
+ * (`now-30s`, `now-5m`, `now-1h`) **or** absolute unix milliseconds, because
+ * a chart asks the first way and a report asks the second, and making a
+ * client convert is making it guess our clock.
+ *
+ * `window` without `agg` is meaningless and `agg` without `window` is
+ * ambiguous — both are refused rather than assigned a default, since a
+ * silently chosen aggregation is a chart that lies quietly.
+ */
+export declare const historyQuery: z.ZodObject<{
+    from: z.ZodString;
+    to: z.ZodOptional<z.ZodString>;
+    window: z.ZodOptional<z.ZodString>;
+    agg: z.ZodOptional<z.ZodEnum<{
+        min: "min";
+        max: "max";
+        avg: "avg";
+    }>>;
+    field: z.ZodOptional<z.ZodString>;
+    limit: z.ZodOptional<z.ZodPipe<z.ZodPipe<z.ZodUnion<readonly [z.ZodString, z.ZodNumber]>, z.ZodTransform<number, string | number>>, z.ZodNumber>>;
+}, z.core.$strip>;
+export type HistoryQuery = z.infer<typeof historyQuery>;
+/**
+ * Raw samples. `timestamp_ms` is the **bridge's capture time** (§6.3) — the
+ * same instant the live value carried, so a recorded point and a live one can
+ * be placed on one axis without apology.
+ *
+ * `truncated` says the response was cut short. A short array that does not
+ * admit it is indistinguishable from a quiet period, and the two lead a
+ * developer to opposite conclusions.
+ */
+export declare const historySamplesResponse: z.ZodObject<{
+    slug: z.ZodString;
+    kind: z.ZodLiteral<"samples">;
+    samples: z.ZodArray<z.ZodObject<{
+        timestamp_ms: z.ZodNumber;
+        value: z.ZodUnknown;
+    }, z.core.$strip>>;
+    truncated: z.ZodBoolean;
+    truncated_by: z.ZodNullable<z.ZodEnum<{
+        limit: "limit";
+        bytes: "bytes";
+    }>>;
+}, z.core.$strip>;
+export type HistorySamplesResponse = z.infer<typeof historySamplesResponse>;
+/**
+ * Aggregated buckets — a **separate shape**, not the samples shape with nulls
+ * in it, so a client knows by type what it received rather than by
+ * inspection.
+ *
+ * `sample_count` exists because an empty bucket and a bucket whose average is
+ * zero are different facts. W5 established at some cost what happens when two
+ * facts share one representation, and a chart is the easiest place in this
+ * product to draw a gap as a line.
+ */
+export declare const historyBucketsResponse: z.ZodObject<{
+    slug: z.ZodString;
+    kind: z.ZodLiteral<"buckets">;
+    window_ms: z.ZodNumber;
+    agg: z.ZodEnum<{
+        min: "min";
+        max: "max";
+        avg: "avg";
+    }>;
+    buckets: z.ZodArray<z.ZodObject<{
+        bucket_start_ms: z.ZodNumber;
+        value: z.ZodNullable<z.ZodNumber>;
+        sample_count: z.ZodNumber;
+    }, z.core.$strip>>;
+}, z.core.$strip>;
+export type HistoryBucketsResponse = z.infer<typeof historyBucketsResponse>;
+/**
+ * **What `GET /api/robots/:id/datapoints/:slug/history` answers, which is one
+ * of two shapes.**
+ *
+ * **The query decides, and only the query**: without `window` it is a
+ * `historySamplesResponse`, with one it is a `historyBucketsResponse`.
+ * `window` and `agg` must be given together or not at all — one without the
+ * other is refused rather than defaulted, since a silently chosen aggregation
+ * is a chart that lies quietly.
+ *
+ * Told apart by `kind`, which is `'samples'` or `'buckets'`, so a client
+ * branches on a field rather than on which other fields happen to be present.
+ * The two are deliberately not one shape with nullable halves: an aggregate
+ * and a raw reading answer different questions, and `sample_count` exists on
+ * only one of them.
+ *
+ * **This union exists so the route can name a response at all.** The entry
+ * carried `response: null` while the handler demonstrably answers something,
+ * which reads in the generated reference as *this route returns nothing*.
+ */
+export declare const historyResponse: z.ZodUnion<readonly [z.ZodObject<{
+    slug: z.ZodString;
+    kind: z.ZodLiteral<"samples">;
+    samples: z.ZodArray<z.ZodObject<{
+        timestamp_ms: z.ZodNumber;
+        value: z.ZodUnknown;
+    }, z.core.$strip>>;
+    truncated: z.ZodBoolean;
+    truncated_by: z.ZodNullable<z.ZodEnum<{
+        limit: "limit";
+        bytes: "bytes";
+    }>>;
+}, z.core.$strip>, z.ZodObject<{
+    slug: z.ZodString;
+    kind: z.ZodLiteral<"buckets">;
+    window_ms: z.ZodNumber;
+    agg: z.ZodEnum<{
+        min: "min";
+        max: "max";
+        avg: "avg";
+    }>;
+    buckets: z.ZodArray<z.ZodObject<{
+        bucket_start_ms: z.ZodNumber;
+        value: z.ZodNullable<z.ZodNumber>;
+        sample_count: z.ZodNumber;
+    }, z.core.$strip>>;
+}, z.core.$strip>]>;
+export type HistoryResponse = z.infer<typeof historyResponse>;
+/**
+ * W6a — deletion, and the one channel that reports health.
+ *
+ * | Route | Body | Answer |
+ * |---|---|---|
+ * | `DELETE /api/robots/:id` | — | `204`. `?force=true` to proceed while a live session is open; without it, `409 robot_in_use` |
+ * | `GET /api/robots/:id/deletion-preview` | — | `robotDeletionSummary` — the same shape the audit event carries |
+ * | `GET /api/org/health` | — | `resourceHealthListResponse`; `?robot_id=` narrows it to one robot |
+ *
+ * Plus `resourceHealthEvent`, pushed on the **developer** realtime socket
+ * and scoped to the org — not to a subscription, because its job is to reach
+ * somebody who is *not* looking at the thing that broke.
+ *
+ * Two of these paths are worth stating rather than inferring:
+ *
+ * **The preview exists because a confirmation must be able to name what it
+ * destroys.** `DELETE` answers `204` with no body, so the counts only ever
+ * appear on the audit event — written *after* the irreversible click. A
+ * dialog built on that can say nothing better than "are you sure?". The
+ * preview returns the *same shape* as the audit record on purpose: the
+ * warning and the receipt then agree by construction, and a disagreement
+ * between them is a real finding rather than two estimates drifting.
+ *
+ * **The snapshot and the event share the org's scope**, and the snapshot
+ * takes an optional `robot_id` filter rather than living at a per-robot
+ * path.
+ *
+ * The first version of this table said the opposite, with a justification
+ * that sounded right and was incomplete: it reasoned only from a page that
+ * has just opened one robot. But the console shows health on the **robot
+ * list** too, and a per-robot path makes that N requests to render one
+ * screen — while the event that must keep it fresh arrives org-wide anyway.
+ * A snapshot and a channel that disagree about scope are not two halves of
+ * one thing; they are two things that have to be reconciled by every
+ * consumer, separately, forever.
+ *
+ * So: same scope, one route, and `?robot_id=` for the narrow question. The
+ * cloud owner proposed this while unblocking the console, and was right.
+ *
+ * This table was missing from the first W6a delta, and a teammate had to ask
+ * three separate people for the paths — which is how a route becomes a fact
+ * that lives only in an inbox.
+ */
+/**
+ * What a `robot.deleted` audit event carries (W6a).
+ *
+ * A deletion record that says only *that* something was destroyed is a
+ * receipt for an unknown amount. This names it: how many configured slugs,
+ * how many stored samples, how many bytes that freed against the retention
+ * quota, which cameras existed, how much attributed run history went with
+ * it, and whether somebody was watching at the time. Those are the questions
+ * asked afterwards, and afterwards is the one moment the data cannot be
+ * consulted.
+ */
+export declare const robotDeletionSummary: z.ZodObject<{
+    slug_count: z.ZodNumber;
+    sample_rows: z.ZodNumber;
+    bytes_freed: z.ZodNumber;
+    cameras: z.ZodArray<z.ZodString>;
+    asset_count: z.ZodNumber;
+    asset_bytes_freed: z.ZodNumber;
+    job_run_count: z.ZodNumber;
+    had_live_session: z.ZodBoolean;
+    had_unpublished_draft: z.ZodBoolean;
+}, z.core.$strip>;
+export type RobotDeletionSummary = z.infer<typeof robotDeletionSummary>;
+/**
+ * The query of `DELETE /api/robots/:id`.
+ *
+ * **`force=true` or nothing, and every other value is refused.** The handler
+ * parses the query with this schema and answers `400 validation_error` on
+ * anything else, so `?force=1` and `?force=TRUE` are neither forced nor
+ * quietly un-forced. That is the whole point of the strictness: silently
+ * false was the worst answer available, because a caller who believes they
+ * authorised a cascade and did not then gets a `409` naming the very flag
+ * they passed, and cannot tell which of the two happened.
+ *
+ * Declared as the literal string because it is the only value that does
+ * anything — a `z.boolean()` here would describe a wire shape a query string
+ * cannot carry, and a `z.string()` would document nothing. The MCP door takes
+ * a real boolean and cannot express the ambiguity at all, so the two are one
+ * policy in two vocabularies rather than two policies.
+ */
+export declare const robotDeleteQuery: z.ZodObject<{
+    force: z.ZodOptional<z.ZodLiteral<"true">>;
+}, z.core.$strip>;
+export type RobotDeleteQuery = z.infer<typeof robotDeleteQuery>;
+/**
+ * The seven health states, declared **once** (W6a review).
+ *
+ * `resourceHealthState` and `resourceHealthEvent` are the snapshot and the
+ * push of the same thing, and they had the same seven values written out
+ * twice, linked by nothing — the artifacts published two independent copies
+ * with no `$ref`. They agreed only because whoever added `unknown` remembered
+ * to add it in both places, on the wave's last contract commit.
+ *
+ * One concept rendering as two artifacts that nothing keeps in step is its
+ * own class of artifact-versus-source defect, distinct from `.default()`
+ * publishing as `required` and from `z.coerce`'s unrepresentable input.
+ */
+export declare const RESOURCE_HEALTH_STATES: readonly ["ok", "unreachable", "auth_failed", "unreadable_credential", "credential_missing", "stopped_by_config_change", "publish_failed", "unknown"];
+/**
+ * The health of one thing a developer configured, as the platform currently
+ * sees it (W6a).
+ *
+ * This exists because four separate findings turned out to be one absence:
+ * nothing carried the state of a camera, a source or a credential to a
+ * developer who was not, at that exact moment, pressing a button. A publish
+ * failure after the `201` never reached the viewer holding the token; a
+ * source whose password was wrong failed at config-apply time with nobody
+ * watching and stayed silent until someone pressed "Go live" days later; a
+ * viewer could not learn *why* a stream ended, so the console had to offer
+ * two possibilities and rank neither; and an undecryptable credential
+ * reported as healthy.
+ *
+ * One shape, because four patches against four symptoms is how W5 nearly
+ * wrote a failure report into `publishState` — a field the cloud writes and
+ * reads in exactly one place, which would have been a dead end.
+ *
+ * `reason` is for a human and is **never** built from an exception message:
+ * W6 found a camera password in a log through `log.exception`, and again in
+ * `LiveStartError`'s message, which travels to the cloud on this very path.
+ * Type names and fixed strings only.
+ */
+export declare const resourceHealthState: z.ZodObject<{
+    robot_id: z.ZodUUID;
+    kind: z.ZodEnum<{
+        camera: "camera";
+    }>;
+    ref: z.ZodString;
+    facet: z.ZodEnum<{
+        source: "source";
+        publish: "publish";
+    }>;
+    state: z.ZodEnum<{
+        unknown: "unknown";
+        ok: "ok";
+        unreachable: "unreachable";
+        auth_failed: "auth_failed";
+        unreadable_credential: "unreadable_credential";
+        credential_missing: "credential_missing";
+        stopped_by_config_change: "stopped_by_config_change";
+        publish_failed: "publish_failed";
+    }>;
+    reason: z.ZodNullable<z.ZodString>;
+    changed_at_ms: z.ZodNumber;
+}, z.core.$strip>;
+export type ResourceHealthState = z.infer<typeof resourceHealthState>;
+/**
+ * The current state of everything in the **org**.
+ *
+ * This doc said "on one robot" until the W6a review found it: the route moved
+ * to org scope in `2bb67c5` and the route table forty lines above spends a
+ * paragraph explaining why the per-robot reading was wrong — while the schema
+ * it describes still said the old thing. Cloud, console and SDK all implement
+ * org-wide correctly; contracts was the only place still saying otherwise,
+ * and it is the first place a fourth consumer reads.
+ *
+ * A channel with no snapshot cannot answer "what is the state now?" for a
+ * page that just loaded — it can only report the next change, which may be
+ * hours away. Both halves or neither.
+ */
+export declare const resourceHealthListResponse: z.ZodObject<{
+    resources: z.ZodArray<z.ZodObject<{
+        robot_id: z.ZodUUID;
+        kind: z.ZodEnum<{
+            camera: "camera";
+        }>;
+        ref: z.ZodString;
+        facet: z.ZodEnum<{
+            source: "source";
+            publish: "publish";
+        }>;
+        state: z.ZodEnum<{
+            unknown: "unknown";
+            ok: "ok";
+            unreachable: "unreachable";
+            auth_failed: "auth_failed";
+            unreadable_credential: "unreadable_credential";
+            credential_missing: "credential_missing";
+            stopped_by_config_change: "stopped_by_config_change";
+            publish_failed: "publish_failed";
+        }>;
+        reason: z.ZodNullable<z.ZodString>;
+        changed_at_ms: z.ZodNumber;
+    }, z.core.$strip>>;
+}, z.core.$strip>;
+export type ResourceHealthListResponse = z.infer<typeof resourceHealthListResponse>;
+/**
+ * The query of `GET /api/org/health`: optionally one robot instead of the org.
+ *
+ * The narrowing lives in a query rather than at a per-robot path because the
+ * console shows health on the robot list too, and a per-robot path would make
+ * that N requests to render one screen.
+ */
+export declare const orgHealthQuery: z.ZodObject<{
+    robot_id: z.ZodOptional<z.ZodUUID>;
+}, z.core.$strip>;
+export type OrgHealthQuery = z.infer<typeof orgHealthQuery>;
+/**
+ * Org protection quotas (§12.4) — generous, server-side adjustable, visible
+ * in Settings. Protection against runaway use, not a business model; a later
+ * one docks onto the same dials.
+ */
+export declare const orgQuotas: z.ZodObject<{
+    max_robots: z.ZodNumber;
+    max_apps: z.ZodNumber;
+    max_end_users: z.ZodNumber;
+    max_retention_bytes: z.ZodNumber;
+    max_retention_writes_per_minute: z.ZodNumber;
+    max_realtime_connections: z.ZodNumber;
+    max_asset_storage_bytes: z.ZodNumber;
+}, z.core.$strip>;
+export type OrgQuotas = z.infer<typeof orgQuotas>;
+/**
+ * What an org is **actually using**, per quota.
+ *
+ * A separate shape rather than `orgQuotas.partial()`, which is what this was
+ * first — and that was wrong in a way its own tests caught: a limit is
+ * `positive()` because a quota of zero would forbid everything, but a
+ * **usage** of zero is the honest answer for every org on the day it signs
+ * up. Reusing one schema for a limit and a measurement is the same mistake as
+ * letting an empty bucket and a zero average share a representation, which
+ * this wave spent a lot of care avoiding one layer up.
+ *
+ * Every field is optional because a quota we do not measure must be
+ * **absent**, never reported as `0` — "not measured" and "measured as zero"
+ * are different facts, and a dashboard that renders the first as the second
+ * is lying quietly.
+ */
+export declare const orgQuotaUsageCounts: z.ZodObject<{
+    max_robots: z.ZodOptional<z.ZodNumber>;
+    max_apps: z.ZodOptional<z.ZodNumber>;
+    max_end_users: z.ZodOptional<z.ZodNumber>;
+    max_retention_bytes: z.ZodOptional<z.ZodNumber>;
+    max_asset_storage_bytes: z.ZodOptional<z.ZodNumber>;
+    max_retention_writes_per_minute: z.ZodOptional<z.ZodNumber>;
+    max_realtime_connections: z.ZodOptional<z.ZodNumber>;
+}, z.core.$strip>;
+export type OrgQuotaUsageCounts = z.infer<typeof orgQuotaUsageCounts>;
+/** Limits beside what is actually used — a limit alone tells nobody where they stand. */
+export declare const orgQuotaUsage: z.ZodObject<{
+    quotas: z.ZodObject<{
+        max_robots: z.ZodNumber;
+        max_apps: z.ZodNumber;
+        max_end_users: z.ZodNumber;
+        max_retention_bytes: z.ZodNumber;
+        max_retention_writes_per_minute: z.ZodNumber;
+        max_realtime_connections: z.ZodNumber;
+        max_asset_storage_bytes: z.ZodNumber;
+    }, z.core.$strip>;
+    usage: z.ZodObject<{
+        max_robots: z.ZodOptional<z.ZodNumber>;
+        max_apps: z.ZodOptional<z.ZodNumber>;
+        max_end_users: z.ZodOptional<z.ZodNumber>;
+        max_retention_bytes: z.ZodOptional<z.ZodNumber>;
+        max_asset_storage_bytes: z.ZodOptional<z.ZodNumber>;
+        max_retention_writes_per_minute: z.ZodOptional<z.ZodNumber>;
+        max_realtime_connections: z.ZodOptional<z.ZodNumber>;
+    }, z.core.$strip>;
+}, z.core.$strip>;
+export type OrgQuotaUsage = z.infer<typeof orgQuotaUsage>;
+/** One bucket is one minute. Stated here so the cloud and any client agree without guessing. */
+export declare const LATENCY_BUCKET_MS = 60000;
+/**
+ * Latency buckets are **platform telemetry, not a customer datapoint**, and
+ * this short retention is why that distinction was worth making: the cloud
+ * pings every bridge every 2 seconds, ~43 200 measurements per robot per day,
+ * and a sparkline needs about 60 points per hour. Seven days is generous for
+ * what reads it and costs the org's retention quota nothing, because it is not
+ * counted against it.
+ */
+export declare const BRIDGE_LATENCY_RETENTION_DAYS = 7;
+/**
+ * Every read of the durable run history and the latency buckets: the three
+ * org-wide ones the fleet overview is built on, and the one robot-scoped door
+ * a client app has into the same table.
+ *
+ * | Route | Query | Answer |
+ * |---|---|---|
+ * | `GET /api/org/jobs` | `jobRunQuery` | `jobRunListResponse` — newest first, cursor-paged over the durable `seq` |
+ * | `GET /api/org/jobs/summary` | `jobRunSummaryQuery` | `jobRunSummary` — three numbers over the window the caller named |
+ * | `GET /api/org/latency` | `orgLatencyQuery` | `orgLatencyResponse` — one series per robot, truncation named |
+ * | `GET /api/robots/:id/jobs/history` | `jobRunQuery` | `jobRunListResponse` — the same read, robot-scoped, developers **and** clients |
+ *
+ * **Written down here because the last time a delta shipped shapes without
+ * their paths, a teammate had to ask three separate people** — see
+ * `robotDeletionSummary`'s neighbouring table, which exists for exactly that
+ * reason. The shapes landed one wave before the routes did, so this table is
+ * the only place the two halves meet.
+ *
+ * Three things about them are worth stating rather than inferring:
+ *
+ * **The three `/api/org/…` reads are org-wide, and `?robot_id=` narrows
+ * them** — the same choice `GET /api/org/health` already made, for the same
+ * reason: the overview screen shows every robot at once, and a per-robot path
+ * would make one screen N requests.
+ *
+ * **Those three are developer-only, and that is a property of their scope,
+ * not of the data.** An org-wide read has no client meaning: an end user is
+ * scoped to the robots their app assigns, never to an org.
+ *
+ * **The client-facing read of the same table is
+ * `GET /api/robots/:id/jobs/history`** — robot-scoped, one route for
+ * developers and clients like every other robot-scoped read (`.../jobs`,
+ * `.../assets`, `.../datapoints`), never a parallel `/api/client/…` twin. An
+ * end user reaches it only when their role's `capabilities.action_history`
+ * says so — otherwise `403 capability_required`, naming the capability — and
+ * sees only runs on slugs their role grants. On this route `?robot_id=` is
+ * not a filter: the path already names the robot, and a query naming a
+ * different one is refused rather than quietly answered about the path's.
+ *
+ * **It discloses the actor, and that is what a developer weighs before
+ * granting the capability.** A `jobRun` names who invoked it — `jobActor`
+ * carries an email — so an end user reading a robot's history learns which
+ * other people have been driving that machine. Robot scope plus a role
+ * capability is what makes that a decision a developer takes per role,
+ * instead of something every session gets: an end-user-facing
+ * `GET /api/org/jobs` would have handed over the whole org's actors with no
+ * such decision anywhere, which is why there is none.
+ *
+ * **A page can be shorter than `limit` while `next_cursor` is non-null**, on
+ * the robot-scoped route specifically: the slug filter is applied to the
+ * page the store returned, so a role granting one slug in ten sees thin — and
+ * sometimes empty — pages. That is what `jobRunListResponse.next_cursor`'s
+ * own doc comment means by a promise rather than an observation; a client
+ * keeps reading until it is null.
+ *
+ * **Neither window is optional, and neither has a default.** A summary over
+ * an unnamed window is a number nobody can reproduce; an unbounded latency
+ * window is a response size chosen by whoever forgot to pass one. Each
+ * query's own doc comment says which of those two reasons applies to it.
+ */
+/** Seven days x 1440 buckets x N robots is otherwise an unbounded response. */
+export declare const MAX_LATENCY_BUCKETS_PER_RESPONSE = 20000;
+export declare const latencyBucket: z.ZodObject<{
+    bucket_at: z.ZodISODateTime;
+    min_ms: z.ZodNullable<z.ZodNumber>;
+    avg_ms: z.ZodNullable<z.ZodNumber>;
+    max_ms: z.ZodNullable<z.ZodNumber>;
+    samples: z.ZodNumber;
+    online_ms: z.ZodNumber;
+}, z.core.$strip>;
+export type LatencyBucket = z.infer<typeof latencyBucket>;
+export declare const robotLatencySeries: z.ZodObject<{
+    robot_id: z.ZodUUID;
+    buckets: z.ZodArray<z.ZodObject<{
+        bucket_at: z.ZodISODateTime;
+        min_ms: z.ZodNullable<z.ZodNumber>;
+        avg_ms: z.ZodNullable<z.ZodNumber>;
+        max_ms: z.ZodNullable<z.ZodNumber>;
+        samples: z.ZodNumber;
+        online_ms: z.ZodNumber;
+    }, z.core.$strip>>;
+}, z.core.$strip>;
+export type RobotLatencySeries = z.infer<typeof robotLatencySeries>;
+/**
+ * `GET /api/org/latency`'s query.
+ *
+ * **Both bounds are required**, for a reason narrower than
+ * `jobRunSummaryQuery`'s: this table holds a bucket per robot per minute for
+ * `BRIDGE_LATENCY_RETENTION_DAYS`, so "everything" is up to 10 080 rows per
+ * robot, and a default window would be a response size chosen by whoever
+ * forgot to pass one. `MAX_LATENCY_BUCKETS_PER_RESPONSE` still bounds the
+ * answer; required bounds are what let a caller decide *which* buckets they
+ * get instead of discovering the ceiling ate the ones they wanted.
+ *
+ * `wireTimestampMs` rather than a plain integer, for its own documented
+ * reason: the union's input branch is what a query string actually carries,
+ * and the year bound is what keeps `253402300800000` from reaching the
+ * Postgres bind path as a `500` where a `400` belongs.
+ */
+export declare const orgLatencyQuery: z.ZodObject<{
+    from_ms: z.ZodPipe<z.ZodPipe<z.ZodUnion<readonly [z.ZodString, z.ZodNumber]>, z.ZodTransform<number, string | number>>, z.ZodNumber>;
+    to_ms: z.ZodPipe<z.ZodPipe<z.ZodUnion<readonly [z.ZodString, z.ZodNumber]>, z.ZodTransform<number, string | number>>, z.ZodNumber>;
+    robot_id: z.ZodOptional<z.ZodUUID>;
+}, z.core.$strict>;
+export type OrgLatencyQuery = z.infer<typeof orgLatencyQuery>;
+export declare const orgLatencyResponse: z.ZodObject<{
+    series: z.ZodArray<z.ZodObject<{
+        robot_id: z.ZodUUID;
+        buckets: z.ZodArray<z.ZodObject<{
+            bucket_at: z.ZodISODateTime;
+            min_ms: z.ZodNullable<z.ZodNumber>;
+            avg_ms: z.ZodNullable<z.ZodNumber>;
+            max_ms: z.ZodNullable<z.ZodNumber>;
+            samples: z.ZodNumber;
+            online_ms: z.ZodNumber;
+        }, z.core.$strip>>;
+    }, z.core.$strip>>;
+    from_ms: z.ZodNumber;
+    to_ms: z.ZodNumber;
+    truncated: z.ZodBoolean;
+    truncated_by: z.ZodNullable<z.ZodEnum<{
+        limit: "limit";
+        bytes: "bytes";
+    }>>;
+}, z.core.$strip>;
+export type OrgLatencyResponse = z.infer<typeof orgLatencyResponse>;
+/**
+ * How long a usage window may be, in days. **Refused above this, not capped** —
+ * the rule `jobRunQuery.limit` already states: a caller who asked for more than
+ * the platform will answer is owed a `400` naming the field, not a quietly
+ * shorter answer they will mistake for the whole picture.
+ *
+ * 366 rather than 365, so "the last full year" is expressible in a leap year.
+ */
+export declare const USAGE_WINDOW_MAX_DAYS = 366;
+/**
+ * The five things the meter records (spec D1).
+ *
+ * Storage is two metrics and not one summed byte count, for
+ * `org_quotas.max_asset_storage_bytes`'s own reason applied to billing: a sync
+ * grows storage in jumps and time series grow steadily, and one number would
+ * let the first crowd out the second on the invoice the same way it would on
+ * the quota.
+ */
+export declare const usageMetric: z.ZodEnum<{
+    api_calls: "api_calls";
+    live_session_ms: "live_session_ms";
+    retention_bytes: "retention_bytes";
+    asset_bytes: "asset_bytes";
+    robot_online_ms: "robot_online_ms";
+}>;
+export type UsageMetric = z.infer<typeof usageMetric>;
+/**
+ * A UTC calendar day, `YYYY-MM-DD`.
+ *
+ * A string and not a millisecond instant, because the thing being described is
+ * a day and not a moment: a `Date` here would carry a time and a zone the
+ * column does not have, and every bug in this area starts with one being
+ * silently converted.
+ *
+ * **The regex checks shape, not validity** — `2026-13-45` and `2026-02-30`
+ * both match `\d{4}-\d{2}-\d{2}$` — so the `.refine()` below round-trips the
+ * string through `Date`'s UTC parser and rejects anything that does not come
+ * back unchanged: `2026-13-45` parses to `Invalid Date`, and `2026-02-30`
+ * (which `Date` rolls over rather than rejects) comes back as `2026-03-02`,
+ * a mismatch either way. Same defect class as `auditQuery.from_ms`'s
+ * `253402300800000`: a value that is the right *shape* reaching the Postgres
+ * bind path for a `date` column and answering `500` where `400` belongs.
+ *
+ * **What the published artifact does not say:** `wireTimestampMs`'s own
+ * note applies unchanged — a `.refine()` has no JSON Schema rendering, so
+ * `org-usage-query.schema.json` shows only the shape-checking `pattern` and
+ * a generated client that validates against the artifact alone will believe
+ * `2026-02-30` is acceptable. The runtime is the authority for this field.
+ */
+export declare const usageDay: z.ZodString;
+/**
+ * **The window is inclusive at both ends**, unlike every millisecond window in
+ * this file (`from_ms`/`to_ms`, half-open per DEF-062).
+ *
+ * That inconsistency is deliberate and is stated here rather than left to be
+ * discovered: a calendar day is a unit, not an instant, and a person asking for
+ * July will write `from_day=2026-07-01&to_day=2026-07-31`. A half-open day
+ * window would silently drop the 31st.
+ *
+ * Both parameters are required and have no default — the rule `/api/org/latency`
+ * and `/api/org/jobs/summary` already follow. "This month" is a question only
+ * the caller's calendar can answer, and a default window would be a query size
+ * chosen by whoever forgot to pass one.
+ *
+ * **The published artifact cannot express any of this**, and that is worth
+ * saying out loud rather than leaving a reader to assume the JSON Schema is
+ * the whole contract, for `orgLatencyQuery`'s own reason: a cross-field
+ * comparison has no JSON Schema rendering, so `org-usage-query.schema.json`
+ * describes two independent pattern-matched strings and validates an
+ * inverted window happily — the cloud is the only enforcement point for the
+ * ordering. The artifact is equally silent about the inclusivity called out
+ * above: nothing in the shape distinguishes an inclusive day window from a
+ * half-open one, that is a fact about behaviour, not a field (the same gap
+ * `historyQuery`/`historyBucketsResponse` name for their own half-open
+ * boundary). And it says nothing about `USAGE_WINDOW_MAX_DAYS` at all — the
+ * constant is not wired into this schema as a check on the span between
+ * `from_day` and `to_day`; the cloud route is where a caller who asked for
+ * more than the ceiling is refused, so a generated client validating against
+ * the artifact alone can build a five-year window and get a `400` from the
+ * route it did not predict.
+ */
+export declare const orgUsageQuery: z.ZodObject<{
+    from_day: z.ZodString;
+    to_day: z.ZodString;
+}, z.core.$strict>;
+export type OrgUsageQuery = z.infer<typeof orgUsageQuery>;
+/**
+ * One day's reading for one metric.
+ *
+ * **`app_id` is `null` when the consumer is the org itself** (spec D2), and
+ * what that `null` means for billing depends on the *metric*, not on
+ * `app_id` alone. `api_calls` and `live_session_ms` are attributable to an
+ * app: a `null` app_id on those two is the developer console's own traffic,
+ * deliberately *not* billable. `retention_bytes`, `asset_bytes` and
+ * `robot_online_ms` have no app dimension at all — every row for those three
+ * carries `app_id: null` unconditionally, and every one is billable org-level
+ * consumption. **A reader must check `metric` before treating `app_id ===
+ * null` as "not billable"** — for three of the five metrics that reading is
+ * always wrong.
+ *
+ * `app_name` is `null` whenever `app_id` is, and also when the app has since
+ * been deleted — usage outlives the app it was attributed to, because an org
+ * still owes for what it used. A UUID alone on an invoice line helps nobody,
+ * and a copy of the name stored on every row would be a second truth that
+ * drifts on the first rename.
+ *
+ * **What this number cannot promise**, and the bound is conditional rather
+ * than flat. `api_calls` and `live_session_ms` are aggregated in memory and
+ * written every 30 seconds.
+ *
+ * *While those writes are landing*, a `kill -9` loses up to 30 seconds of
+ * counting — never more, and never against the caller, since an unflushed
+ * count is simply not billed.
+ *
+ * *While they are failing* — an unreachable database, say — that bound does
+ * not hold at all: everything counted since the last successful flush is
+ * held in memory, deliberately uncapped, and a `kill -9` loses all of it.
+ * The trade is intentional (dropping billing data to bound process memory is
+ * the worse half of it), but "at most one interval" describes a platform
+ * whose writes are landing, not a guarantee that survives an outage. This
+ * sentence used to say "never more", and it was false.
+ *
+ * A row the database rejects **permanently** — most concretely one whose org
+ * has been deleted since the count, since a usage row's `org_id` is `ON
+ * DELETE NO ACTION` — is written off instead: given up on, reported with a
+ * count, and never billed. That is a deliberate loss, and it is the smaller
+ * one. Before it, a single such row failed the whole batched write on every
+ * retry, forever, and stopped `api_calls` and `live_session_ms` reaching the
+ * database for **every** org on the platform.
+ *
+ * A graceful shutdown loses nothing **provided its final flush succeeds**.
+ * If that write fails, the process reports how many rows it is carrying and
+ * exits carrying them — there is no second attempt, because there is no
+ * longer a process to make one.
+ *
+ * The other three metrics never travel this path. They are sampled from
+ * other tables on their own timer and can lag; what a missed sample costs,
+ * per metric, is in the docs' `/api/org/usage` notes.
+ */
+export declare const usageRow: z.ZodObject<{
+    app_id: z.ZodNullable<z.ZodUUID>;
+    app_name: z.ZodNullable<z.ZodString>;
+    metric: z.ZodEnum<{
+        api_calls: "api_calls";
+        live_session_ms: "live_session_ms";
+        retention_bytes: "retention_bytes";
+        asset_bytes: "asset_bytes";
+        robot_online_ms: "robot_online_ms";
+    }>;
+    day: z.ZodString;
+    value: z.ZodNumber;
+}, z.core.$strip>;
+export type UsageRow = z.infer<typeof usageRow>;
+/** The window is echoed back for `orgLatencyResponse`'s reason: a rendered total has to be able to say which window it describes. */
+export declare const orgUsageResponse: z.ZodObject<{
+    rows: z.ZodArray<z.ZodObject<{
+        app_id: z.ZodNullable<z.ZodUUID>;
+        app_name: z.ZodNullable<z.ZodString>;
+        metric: z.ZodEnum<{
+            api_calls: "api_calls";
+            live_session_ms: "live_session_ms";
+            retention_bytes: "retention_bytes";
+            asset_bytes: "asset_bytes";
+            robot_online_ms: "robot_online_ms";
+        }>;
+        day: z.ZodString;
+        value: z.ZodNumber;
+    }, z.core.$strip>>;
+    from_day: z.ZodString;
+    to_day: z.ZodString;
+}, z.core.$strip>;
+export type OrgUsageResponse = z.infer<typeof orgUsageResponse>;
+/** `PATCH /api/robots/:id` — rename the robot. Display-only: nothing references robot names. */
+export declare const patchRobotRequest: z.ZodObject<{
+    name: z.ZodString;
+}, z.core.$strict>;
+export type PatchRobotRequest = z.infer<typeof patchRobotRequest>;
+/**
+ * `POST /api/robots/:id/config/rename-slug` — atomic server-side rename:
+ * rewrites the **draft** config, every app-role grant carrying
+ * `{robot_id, from}`, and the recorded history rows, in one transaction.
+ * Job runs and audit events keep the old slug as historical fact. The
+ * published config is immutable, so the caller must publish afterwards
+ * (`requires_publish`); samples arriving between rename and the applied
+ * publish still land under the old slug — named residual, not migrated.
+ * Second residual in that same window: grants and the draft already name
+ * `to`, but the still-published config exposes only `from` until the
+ * publish lands — an end user's app has no working name for the datapoint
+ * at all for however long that gap lasts, since `to` isn't published yet
+ * and `from` no longer has a grant behind it. The console must publish
+ * immediately after a rename to keep this window short; nothing server-side
+ * closes it.
+ * This schema only enforces slug *shape*; whether `to` is reserved or
+ * already in use on this robot is checked once, behind the cloud's
+ * `validation.ts` door — one door, not a second copy of that rule here.
+ */
+export declare const renameSlugRequest: z.ZodObject<{
+    from: z.ZodString;
+    to: z.ZodString;
+}, z.core.$strict>;
+export type RenameSlugRequest = z.infer<typeof renameSlugRequest>;
+export declare const renameSlugResponse: z.ZodObject<{
+    rewritten_grants: z.ZodNumber;
+    history_moved: z.ZodBoolean;
+    requires_publish: z.ZodLiteral<true>;
+}, z.core.$strip>;
+export type RenameSlugResponse = z.infer<typeof renameSlugResponse>;
+/**
+ * `GET /api/robots/:id/config/slug-usage/:slug` — what a rename would touch;
+ * feeds the console's confirm dialog.
+ *
+ * `alert_count` (spec `2026-08-28-alerts-and-datapoint-modal-design`, D5)
+ * joined the atomic rename transaction alongside grants and history: alerts
+ * are keyed by `(robot_id, slug)` too, and a rename that silently moved the
+ * alert row while the usage preview stayed silent about it would show a
+ * developer a smaller blast radius than the rename actually has.
+ */
+export declare const slugUsageResponse: z.ZodObject<{
+    grant_count: z.ZodNumber;
+    app_identifiers: z.ZodArray<z.ZodString>;
+    has_recorded_history: z.ZodBoolean;
+    alert_count: z.ZodNumber;
+}, z.core.$strip>;
+export type SlugUsageResponse = z.infer<typeof slugUsageResponse>;