Capabilities — diagram coverage (assembly side vs consumption side)
Parent: capabilities
Same two-sided cut as connector-diagram-coverage: the assembly side (how capabilities register and get exposed per session) and the consumption side (what the loop actually holds). The plugin-loading types live on mcp-capability-plugins; skills runner types on skills-progressive-disclosure; frontend card types on ui-cards.
1 · Assembly side — registry, gates, session context
AssembleInput is the whole session context a capability may see — it carries the frozen RoleSnapshot, so every binding decision happens against the freeze; EnableGate (the live global layer) is the only live input. (Members verified against internal/capabilities/capreg/types.go / registry.go on 2026-09-07: the former CodeID / MaxBookings fields are gone — the code identity now travels as Subject, and the booking cap is a config key of the capability's own manifest (max_bookings in backend/capabilities/calendar.book/manifest.yaml).)
2 · Consumption side — what a session actually holds
Coverage checklist (anti-omission gate)
| type / area | diagrammed at | verified |
|---|---|---|
| Capability, Registry, AssembleInput, EnableGate | this page §1 | ✓ code |
| Binding, CapabilityState, VisitorAgent | this page §2 | ✓ code |
| Manifest / Transport / Sandbox / PluginSpec | mcp-capability-plugins | ✓ code |
| skillRunnerCapability + tool inputs/outputs | skills-progressive-disclosure | ✓ code |
| cardKindFor / McpAppCard / GenericDumpCard | ui-cards | ✓ code |
| mcpclient transports (http / in-process / stdio) | ☐ not yet diagrammed | — |
capsocket server + hostdesk op collection (hostop.Op, routes/hostdesk) | capsocket (prose) | ☐ no class diagram |