<capacity-plan>
Compact ledger that ties iron-triangle capacity, quality-target spend, and slotted work-item costs into a stacked-bar plan view.
Overview
The <capacity-plan> stitches the planning chain together visibly. It reads three numbers — capacity from a paired <iron-triangle>, quality spend from a paired <quality-target>, and feature spend from slotted elements with data-capacity-cost — and renders a four-row ledger with proportional bars: capacity vs quality vs features vs slack.
It's the answer to "where did my capacity go?" Without it, the chain is implicit; with it, the math is the first thing the team sees on the requirements page.
<iron-triangle id="shape"></iron-triangle><quality-target id="quality" data-bind-to="shape"></quality-target> <capacity-plan data-bind-triangle="shape" data-bind-quality="quality"> <work-item data-capacity-cost="3">Bulk import</work-item> <work-item data-capacity-cost="2">API webhooks</work-item></capacity-plan>
The arithmetic
Plain subtraction:
slack = capacityPoints − qualityCriticalSum − featureCostSum
When capacityPoints is unbounded (no triangle bound and no data-capacity-points on the target), slack is reported as ∞ and the bar visualization scales against actual spend. The slack row turns red and capacity-plan:overdrawn fires when slack crosses zero.
Two ways to supply feature spend
The component sums any descendant element with data-capacity-cost="N". Authors typically slot <work-item> children:
<iron-triangle id="shape"></iron-triangle><quality-target id="quality" data-bind-to="shape"></quality-target> <capacity-plan data-bind-triangle="shape" data-bind-quality="quality"> <work-item data-capacity-cost="3">Bulk import</work-item> <work-item data-capacity-cost="2">API webhooks</work-item></capacity-plan>
For server-rendered planning surfaces or programmatic flows, set featureSum directly; property override wins over slot inference. Mutation observation re-renders automatically when a slotted child's data-capacity-cost changes.
Attributes
| Attribute | Values | Default | Description |
|---|---|---|---|
data-bind-triangle | string | — | ID of a sibling <iron-triangle> to read capacityPoints from |
data-bind-quality | string | — | ID of a sibling <quality-target> to read criticalSum from |
Properties & events
| Member | Description |
|---|---|
capacityPoints (R) | Live capacity from the bound triangle (or Infinity if absent). |
qualitySum (R) | Live critical sum from the bound quality target (or 0). |
featureSum (R/W) | Sum of data-capacity-cost across descendants, or an explicit number set by the host. |
slack (R) | Computed: capacity − quality − features. |
capacity-plan:overdrawn (event) | Edge-triggered when slack crosses zero. |
Theme tokens
| Token | Default | Purpose |
|---|---|---|
--capacity-plan-max | 32rem | Max inline-size of the ledger container. |
| Bar colors | VB theme tokens (--color-text, --color-interactive, --color-success, --color-error) | Auto-adapt across light/dark and brand themes. |
Accessibility
The ledger is read as labelled rows so the capacity / quality / features / slack breakdown is available without relying on the bar colors alone. Bars adopt VB theme tokens (--color-text, --color-interactive, --color-success, --color-error) so they auto-adapt across light, dark, and brand themes while preserving contrast; the overdrawn state is conveyed by the slack value going negative, not by color alone.
Related
<iron-triangle>— suppliescapacityPointsviadata-bind-triangle.<quality-target>— supplies the Critical-weight sum viadata-bind-quality.<work-item>— the slotted feature element whosedata-capacity-costthe plan sums.<requirement-card>— displays a single quality decision the plan accounts for.