Specifications

Spec Index

The per-requirement status tables are authoritative. Draft means that the requirement is not implemented or has not yet been verified by executable evidence, even when the broader subsystem is available.

Startup Sequence

outcalld initializes its security boundary before serving either API. Invalid rules, socket conflicts, bridge-policy failures, and required DNS/proxy bind failures abort startup.

1. Rule Engine (S003)     — load and validate YAML rules
   ↓
2. API sockets            — bind host and agent Unix sockets without serving
   ↓
3. Bridge (S001)          — create/validate bridge, apply fail-closed base policy
   ↓
4. Docker Manager (S008)  — connect to Docker; degraded mode is allowed
   ↓
5. Dynamic Rules (S009)   — start lifecycle and expiry watchers
   ↓
6. DNS Filter (S007)      — bind the managed resolver
   ↓
7. HTTP Proxy (S006)      — bind unless explicitly disabled
   ↓
8. Network (S002)         — initialize managed network allocation
   ↓
9. Host and Agent APIs    — begin serving the pre-bound sockets

Shutdown Sequence

1. Host and Agent APIs    — stop serving requests
2. HTTP Proxy and DNS     — stop and join listener tasks
3. Dynamic Rules (S009)   — stop watchers and flush temporary grants
4. Bridge (S001)          — reapply the fail-closed base policy
5. Background managers    — stop Docker and netlink watcher tasks
6. API sockets            — remove host and agent socket files

Networks and containers intentionally outlive the daemon (S002-EC-010). Normal shutdown preserves the bridge and nftables table, removes dynamic grants, and leaves managed container egress blocked until the daemon services restart.

Validation

Validate requirement IDs, status values, duplicate definitions, and index coverage before committing spec changes:

scripts/check-spec-indexes.sh

Design Principles

1. Default BLOCK — no rule match means denied. Every subsystem enforces this independently.
2. Fail closed — if any subsystem is unavailable, the answer is BLOCK/deny/SERVFAIL/exit-5.
3. Host-only management — bridge, network, rule, and container management happens on host.sock only.
4. Agent isolation — containers see only agent.sock. No access to host API, bridge, or nftables.
5. Single daemon process — daemon subsystems run as owned Tokio tasks in outcalld.