DocsRuntime v0.13.0 · macOS, Linux and Windows
Everything you need to run
Engineering Runtime.
Install it, set policy, connect your platforms and run capabilities — with commands you can copy, real expected output, and recovery steps for when something is refused.
Why was the second write denied? Compiled defaults grant file writes inside the working directory. ../outside.txt escapes that grant, so it is refused before anything runs, and the output names which check refused it. Abridged from the v0.13.0 output.
What you get here
Commands you can copy
Every step is a command you can run exactly as written.
Real expected output
Output is copied from the released binary, so you can compare your run line by line.
Recovery when it refuses
Common failures, exact error text and the fix — including why policy said no.
A path for every caller
Guides for your laptop, CI/CD pipelines and AI assistants.
What these docs contain¶
Use this site to move from a clean machine to repeatable engineering work. Each path tells you what to run, what to set, what to expect back, and how to recover.
Three ways to use it¶
On your laptop
Install the binary, then run provider operations and capabilities from your terminal. The Runtime Home is created on the first command.
Local guideIn CI/CD
A per-job Home, the setup-runtime action, secrets, and capability execution in GitHub Actions or any pipeline.
With an AI assistant
Your assistant may only call runtime. Tools with hook systems enforce that mechanically; others follow it as written guidance.
Full map: Ways to use.
Learn here. Execute against the contract your Runtime carries.
Point your assistant at this site and supervise. The prompts name a URL and a goal, never a vendor.
Use these pages for goals, prerequisites, expected results, recovery, and upgrade guidance.
Use RUNTIME-AGENT.md, manifest.json, specs, and command sheets for your installed version.
The execution lifecycle¶
Direct operations and capability steps share the same governed lifecycle, whoever starts them.
Before anything runs
Bootstrap prepares the Runtime Home, and targets are resolved before policy is evaluated.
Policy and safety
Compiled safety rules cannot be bypassed by configurable policy — on every step of every capability.
Results
All four engines share one sanitizer; JSON output carries the complete sanitized result.
Audit and evidence
Intent is recorded before dispatch, so the audit trail is more than a final log line.
Full lifecycle detail — control boundaries, guarantees and limits
Runtime v0.9.9's control boundaries are:
Intent → Capability / Operation → Provider / Tool Semantics
→ Compiled Safety → Configurable Policy → Authentication + Context
→ REST / GraphQL / Command / File → Shared Sanitizer
→ Canonical Safe Result → Audit + Evidence → CLI / JSON / compatibility
Before anything runs
- Bootstrap first prepares Runtime-owned contracts and state.
- Targets are prepared before policy is evaluated.
- Authentication and context probes record their own durable intent before any effect.
- Known coarse denials are refused without a credential round trip.
- Native credentials and context stay owned by the tool, not by Runtime profiles.
Policy and safety
- Compiled invariants cannot be bypassed by configurable policy.
- Capabilities inherit these same controls on every step.
Results
- All four engines share one result sanitizer.
- Canonical JSON contains the complete admitted, sanitized result.
- Human CLI output is bounded. Optional provider display metadata changes neither the JSON nor security.
- Opaque text is not treated as structured just because of its first character.
- Sanitization protects recognizable, structured and known values. It is not universal data-loss prevention (DLP).
Audit and evidence
- Operation intent is recorded before engine dispatch, so audit is more than a final log write.
- Audit and evidence preserve execution truth.
- Evidence can fail after an operation has already succeeded. It does not roll the operation back.
Pick the right execution surface¶
Both routes use the same Runtime lifecycle. Choose based on whether the operation already has a curated Runtime interface.
Choose this when Runtime exposes a named operation. State the outcome; the provider selects its supported transport.
GitHub · files · GCP project read Browse provider operations → Existing engineering tool Use the Command EngineChoose this when your team already uses an approved native binary. Runtime applies its allow-list and subcommand policy.
The tool must already be installed on yourPATH
Open command run →
Build repeatable work with capabilities¶
A capability is a Markdown file with an embedded runtime block. It sequences operations into work that a human, a pipeline, or an AI can run through the same contract.