Cloud Fleet VM Approval

What it is

A decision card, not a screen. When the cloud fleet has no capacity for the work a session has been handed, the fleet's own capacity check can raise a request for one more machine. Because a machine is billed by the hour for as long as it runs, that request is held rather than created: Omniscio writes an approval card and waits.

The card tells you what you are deciding: the machine's name, operating system, machine type, how its storage is obtained, and its disk size; the reason it was asked for; which session asked; how long it is allowed to live before it stops itself; and the cost — first what the request actually costs over that lifetime, then the larger monthly figure that applies only if the machine is left running. It also names, in plain language, the rules that made this a person's decision rather than an automatic one (a budget ceiling, a spend threshold, or similar).

Approving creates that one machine and adds it to the fleet for its lifetime. Declining creates nothing. Both answers are recorded in the fleet ledger, which is the running record of what the fleet owns and what it costs.

A request that stays inside policy never becomes a card at all — it is created straight away, and the ledger records that no approval was needed.

Where to find it

The card arrives in your inbox, in the Alerts section, on the computer that owns the shared cloud fleet. It looks like any other alert, with the two buttons in place of the usual single action.

It can also be answered from your paired phone, exactly as from the desktop — the same card, the same two buttons — with your account's second factor required, as it is for every other decision you make from a phone.

Answering by hand from a terminal is still possible on the operator computer (npm run cloud:fleet-approve), and it performs exactly the same ledger write the button does — one implementation, two doors.

How it behaves

• Nothing exists until you answer. Raising the card does not reserve, start or pay for anything. Declining leaves the fleet exactly as it was.
• Only the fleet's own computer may answer. The shared fleet belongs to one designated computer; every other computer uses it and may not buy capacity on it. On any other machine the answer is refused and the card stays put — the gate fails closed, so a missing or unreadable claim refuses rather than assumes.
• No agent can answer it — by design. There is no command-line route to this decision, because an agent that could answer it would have granted itself exactly the capacity the cost threshold was there to withhold. The only exceptions the app allows are the two above: a person at the fleet's computer, or a person on their paired phone.
• An answer that cannot be recorded is a failure, not an approval. If the ledger write does not land, the app says so and leaves the card in place. A refusal is a normal answer carrying its own reason — already answered, unknown request, or the ledger not writable — never a silent success.
• One card per request. Each request carries its own identifier, so the same request can never appear twice and two different requests never overwrite each other.
• The lifetime is the point. The card states how long the machine may live so you are deciding on a bounded cost, not a standing one. A machine left running past its lifetime is the risk the monthly figure is warning about.

For agents

There is deliberately no route for this: the channel is classified security-boundary-human-only in the parity manifest, and a full-trust-token route was considered and rejected, because any session on the operator computer can read the full-trust token — it would have been a gate in name only.

What an agent DOES have is the request half. A helper that needs capacity calls the fleet-create path (scripts/cloud/fleet-create.mjs), which either creates the machine within policy or holds it and raises the card; the agent then reports that it is waiting for a person.

• The card's identity is its dedup key: the prefix cloud-fleet-vm-approval- followed by the request id, parsed in ONE place (src/shared/alert-features/fleet-vm-approval-card.ts) — the request-id shape deliberately excludes a leading dash so an id can never read as a flag.
• The click reaches IPC.CLOUD_FLEET_ANSWER_REQUEST (src/main/ipc/cloud-fleet-approval-handlers.ts), whose handler validates the request id, refuses unless this is the claimed operator computer, and then spawns the SAME scripts/cloud/fleet-approve.mjs the operator runs by hand — Main never re-implements the ledger write.
• The buttons are declared as approve-fleet-vm-request / deny-fleet-vm-request in src/shared/alert-actions/dev-and-maintenance.ts, and the card's resolver re-checks the key through the same parser the handler uses, so a button can never be drawn for a card it cannot action.
• Fail-mode is FAIL-CLOSED at both seams: the operator gate, and the ledger write.

Related

• Cloud Control Plane — the fleet's health, the queue, and where cloud work is inspected before you dispatch it.
• Hand a job list to the cloud and watch it land — what happens after capacity exists and work is sent to the fleet.
• Inbox Alerts — how cards in your inbox behave generally: what raises them, what clears them, and how to mute them.