Chip system
Three distinct chip types. Confusing them is one of the most common UI mistakes.
TL;DR
| Type | Lives where | Multi-active? | Action |
|---|---|---|---|
| Top-level chip-nav | Top of workspace/panel | Yes | Filter / activate workspace sections |
| Sub-chips | Inside a card | No (single-active) | Switch the card's view |
| Sub-nav | Inside a Panel Card | Yes | Create Inner Cards |
| Report-Surface chips | Inside Full Peek | Reorderable | Show specific surfaces |
Confusing them breaks the UI. A "sub-chip" that creates cards is wrong. A "top-level chip" that splits into a card is wrong. Read the rules.
1. Top-level chip-nav
Path in FVS: pact/platform/chip-system/chip-system.md
Rules:
- Lives at top of a workspace/panel.
- Overflow chips collapse into "+" overflow chip → flyout (NOT modal).
- Drag-to-reorder, 150ms ease-out.
- One-word labels.
- Active state via
var(--accent). - Multiple can be active.
- Used in Vibe Hub: project row (main page + anchor panel).
docHub application: docHub's user-face project filter uses this pattern. Chips: getting-started, projects, concepts, reference. Multiple active = filter intersection.
2. Sub-chips
Path in FVS: pact/platform/cards/sub-chip.md
Rules:
- Live INSIDE a card (Report Card / Mavis response card).
- Are view selectors — switch content, never activate or split cards.
- Single-active (mutually exclusive); instant peek update; context highlight.
- Never create cards, never elevate, never appear in panels.
- Used in Vibe Hub: Mavis response chip nav at the bottom of each bubble.
docHub application: the report-card inside a decision (e.g., D-060) uses sub-chips to switch between "summary / full text / pact refs." Single-active, never creates new artifacts.
3. Sub-nav
Path in FVS: pact/platform/cards/sub-nav.md
Rules:
- Activators that create Inner Cards (not switchers).
- Multi-active.
- Only Panel Cards may have sub-nav.
- Vibe Hub doesn't use this (no Inner Card system).
docHub application: not used currently. docHub doesn't have Inner Cards; if added, sub-nav would activate them.
4. Report-Surface chips
Path in FVS: pact/platform/cards/report-surface-chips.md
Rules:
- 10 canonical surfaces:
thinking,checker,audit,task-list,execution-trace,reasoning-trace,previews,metadata,face-plans,tool-logs. - Reorderable INSIDE Full Peek.
- Non-elevatable, card-bound, navigational.
- Vibe Hub simplified version:
response(always),decisions(if any),data(always),image/doc/link(if any).
docHub application: a Mavis response that contains a docHub lookup uses Report-Surface chips for the response: response (the chat text), data (the bootstrap.json), decisions (cited D-NNNs).
Mavis response chip convention
When the operator asks for "chips in Mavis response," use the sub-chip switcher model — content-type labels (response, data, link, decisions, doc, image), not todo categories.
This is from pact/pipeline/codex/codex-overlays/alignment/overlay-question-index.md and the chip-system pact.
Anti-patterns (from INDEX.md §O)
- Treating Blueprint as a chip (it's a layer)
- Treating Settings as a chip (it's a sub-layout)
- Treating Origin as a chip (it's a workspace)
- Putting workspace switcher in dock (use top bar)
- Putting horizontal chips in the side-column (pact says vertical, 3 max)
Full list in doctrine/anti-patterns.md.