Capability Vocabulary Inventory

This Phase 0 artifact inventories the current authorization capability strings, classifies their status, and records the canonical migration targets for the clean-cutover capability-vocabulary refactor.

Scope

This inventory covers authorization capability names used in:

• product Rust call sites
• Biscuit token issuance
• guard snapshots and guard checks
• choreography .tell files
• docs and examples that currently teach or exercise capability annotations
• test fixtures that still exercise legacy naming

This inventory does not treat the following as authorization capability names:

• aura_core::effects::CapabilityKey runtime-admission keys
• version-handshake feature flags such as ceremony_supersession
• explicit negative-test placeholders such as unknown_capability
• documentation placeholders such as capability_name
• diagnostic labels such as bundle linking and session delegation
• unrelated "capability" terminology in ownership or crypto docs

No out-of-tree module manifests currently exist in-tree. The module namespace rules below therefore reserve the future extension path, but no concrete module capabilities are currently admitted.

Reserved Namespaces

First-Party Authorization Namespaces

These namespace roots are reserved for first-party Aura capability families:

Generic Host-Owned Capabilities

These names stay reserved by the host and are not owned by a feature crate:

• read
• write
• execute
• delegate
• moderator
• flow_charge

Reserved Module Namespace

Out-of-tree module-defined capabilities must use:

module:<module_id>:<capability_path>

Rules:

• <module_id> is the admitted host-reviewed module identity, not an arbitrary author-chosen prefix.
• <capability_path> uses the same validated lower-case segment grammar as first-party names.
• modules may not claim first-party namespace roots such as invitation, consensus, or sync
• modules may not claim generic host-owned names such as read or write
• host runtime code must consume admitted descriptors, not hand-written module:<module_id>:... strings

Canonical First-Party Capability Inventory

These are the canonical migration targets for first-party product code.

Legacy Aliases and Invalid Drift

These strings are present today but are not approved as long-lived capability surface. They exist only as migration or deletion targets.

Choreography and Example Names That Must Become Namespaced

These current names are intentionally not approved as canonical product capabilities. They either move into an owned first-party namespace or into the reserved host-owned example:* namespace for teaching material.

Explicit Audit Exclusions

These strings were caught by broad Phase 0 grep passes but are not part of the authorization capability vocabulary:

Quarantine Notes

• Historical scratch notes remain explicitly quarantined as non-authoritative archive material.
• This file replaces ad hoc capability-name scratch lists for the Phase 0 refactor inventory.
• Remaining legacy names are recorded here only as migration/deletion targets. They are not approved compatibility surfaces.

Audit Commands

Phase 0 inventory data was gathered with:

rg -n --no-heading 'CAP_[A-Z0-9_]+: &str = "[^"]+"' crates -g'*.rs'
rg -n --no-heading 'CapabilityId::from\("[^"]+"|has_capability\("[^"]+"' crates -g'*.rs'
rg -n --no-heading 'guard_capability = "[^"]+"|#\[guard_capability\("[^"]+"\)\]' crates docs examples -g'*.rs' -g'*.md' -g'*.tell'
rg -n --no-heading 'capability\("[^"]+"\)' crates docs examples -g'*.rs' -g'*.md'