Guide
An executor that runs on the owner's machine
Some work needs the machine itself: a build, a script, a file operation, a program that has no API. The executor is the seat that runs that work, with a task and result contract instead of a shell string, and an approval boundary in front of anything that changes the host.
Task and result, not a shell string
A task is a versioned document with an operation, its arguments, a workspace and the origin binding. A result carries the outcome, the activities and the same origin, so the answer returns to the conversation that asked rather than to a mailbox nobody reads.
The schemas are versioned in the repository — task and result v2 plus the node descriptor, access policy and error documents — so an executor and a caller can disagree about the version without disagreeing about the shape.
What the runtime does
The runtime resolves a seat to a driver, holds a terminal pool, records every action in an authority ledger, and enforces a permission profile. Work that changes the host goes through the approval flow; a denied action is recorded as denied, not silently dropped.
node-contract— task, result, diagnostics, validationnode-runtime— permission profile, authority ledger, runner, terminal poolnode-directory— who may address this hostnode-driver-windows— approved commands, workspace, elevationnode-service-windows— the host service and its personal provisioning
The approval boundary
Anything that runs on the host is a potential incident. The executor treats shell.run_approved as an approval-required operation, binds it to a human decision, and records the decision with the task in the ledger. A caller cannot widen its own permission by asking.
Current status
The contract, runtime and Windows driver are in the repository and covered by contract tests, which pass. The Windows host service is a candidate for private deployments; public transport is not activated. Treat the executor as a private-deployment capability today, not a hosted service.