Capabilities
A capability is a stable description of something Dawn can do. The catalog is the common core; HTTP routes, frontend actions, agent tools, and documentation are projections of it.
packages/capabilities/manifest.json
│
├── API endpoint + typed payload
├── frontend capability client
├── agent tool selection + approval
└── this generated catalogThe JSON manifest owns semantic facts only: stable ID, version, description, domain, query or command kind, data effect, tenant scope, and data classification. It does not contain React components, URLs, icons, shortcuts, HTTP methods, or implementation functions.
@dawn/api binds a capability to its Zod payloads and transport. Generated
OpenAPI operations carry the same metadata in x-dawn-capability. The API also
serves the language-neutral manifest at /capabilities.json.
Reference
The capability registry is generated directly from the registry. It lists every implemented capability and its complete semantic metadata.
Composition
Consumers select capabilities and add only surface-specific details. The
workspace app invokes them through api.capabilities; the agent derives its
OpenAPI allowlist and approval behavior from a composed capability set. This
page reads the same catalog directly.
A future menu can add a localized label, icon, shortcut, and handler without changing the core capability. Navigation and purely local UI state are not system capabilities.
Modules group capabilities into product areas and add app readiness plus workspace enablement. A capability can exist while a module remains unavailable in an app whose complete journey is not ready.
Adding a capability
- Implement and test the domain behavior.
- Add the semantic entry to
packages/capabilities/manifest.json. - Bind it to an endpoint and typed payload in
@dawn/api. - Compose it into only the surfaces that should expose it.
- Regenerate OpenAPI and run the capability, API, and consumer tests.
Do not catalog planned behavior. Presence in the manifest means the underlying capability exists.