local-first · v0.1

Capability Permission

Phase IV · V1.5 — Given an approved execution request, WHAT capabilities are available to the requester? The OS permission layer between Vault and Approval: Approval decides IF, Capability decides WHAT. Resolves permissions only — executes nothing, never bypasses the Vault. Read-only.

19
Capabilities
5
Profiles
6
Plans
2
Requires approval
Capability catalog (per-kind permission metadata — 19 kinds)
filesystem
high
browser
medium
desktop
high
window
low
vision
medium
api
mediumvaultprovider
terminal
critical
mcp
highprovider
memory
low
notifications
low
scheduling
medium
media
mediumvaultprovider
clipboard
medium
network
highvault
email
highvaultprovider
ocr
low
search
lowprovider
reasoning
low
planning
low

The Capability Permission Runtime is the operating-system permission model: per-profile grant tables (no default wildcard — an unlisted capability is denied), least-privilege scope with cross-tenant/product fail-closed, and a classification/risk approval ladder that can never be weakened. Decisions speak the Policy vocabulary (allow / deny / requires_approval) and normalize through Policy — emergency stop dominates, and a policy role-denied surface denies its capability. A capability that requires a secret names a Vault SecretRef that must resolve and be non-revoked; the permission layer records that a Vault release is required but never bypasses the Vault and never releases material. Approval (V2) consumes these plans; the Broker (V3) consumes Approval later. Distinct from the M19 capability catalog and the M16 environment selector.