@momoi-labs/kiso 0.7.1 → 0.9.0

package/kiso/docs/components/README.md

@@ -11,6 +11,7 @@ behavioral reference where one exists.
 - [Button](button.md): Triggers a visible, text-labeled action without changing the URL.
 - [Card](card.md): Groups related content and actions with visual separation.
 - [Checkbox](checkbox.md): Toggles an option in a list or selects multiple values.
+- [ChipInput](chip-input.md): Collects several structured values in one field, each with its own options.
 - [FormField](form-field.md): Composes Label, a form control, HelperText, and ValidationMessage with consistent ID and ARIA wiring.
 - [HelperText](helper-text.md): Provides persistent, non-error context for a form control.
 - [IconButton](icon-button.md): Triggers a compact icon-only action with a required accessible name.
@@ -35,12 +36,13 @@ behavioral reference where one exists.
 - [KV](kv.md): Describes one object through named facts.
 - [LogView](log-view.md): Displays scrollable log output with follow-tail behavior.
 - [Search](search.md): Filters visible content such as a list or table.
+- [Sparkline](sparkline.md): Draws the shape of one metric series at cell size.
 - [Stat](stat.md): Presents a named metric with optional change and context.
 - [Table / DataTable](table.md): Presents structured records with optional sorting, selection, filtering, and pagination.
 
 ## Navigation and structure
 
-- [AppShell / ApplicationShell](app-shell.md): Provides low-level columns or the complete shared application frame.
+- [AppShell / ApplicationShell](app-shell.md): Provides low-level columns or the complete shared application frame (sidebar console or top-bar surface).
 - [BrandMark](brand-mark.md): Decorative letter or icon beside a product name.
 - [Breadcrumb](breadcrumb.md): Shows the current location within a hierarchy.
 - [Header](header.md): Composes persistent application navigation and global actions.
@@ -62,7 +64,7 @@ behavioral reference where one exists.
 ## Required compositions
 
 - [FormField](form-field.md) composes [Label](label.md) + [Input](input.md) (or another form control) + [HelperText](helper-text.md) + [ValidationMessage](validation-message.md).
-- [ApplicationShell](app-shell.md) composes [Sidebar](sidebar.md) + [Navigation](navigation.md) + [Header](header.md) + page content.
+- [ApplicationShell](app-shell.md) composes [Sidebar](sidebar.md) + [Navigation](navigation.md) + [Header](header.md) + page content, or a top-bar-only frame with brand in [Header](header.md).
 - [Header](header.md) composes [Link](link.md) + [IconButton](icon-button.md) + optional [DropdownMenu](dropdown-menu.md).
 - [Table / DataTable](table.md) composes [EmptyState](empty-state.md), [Skeleton](skeleton.md), and [Pagination](pagination.md) for empty, loading, and paged states.
 - [PageHeader](page-header.md) composes a title + optional subtitle + [Buttons](button.md).

package/kiso/docs/components/app-shell.md

@@ -4,11 +4,13 @@
 
 AppShell places persistent [Sidebar](sidebar.md) navigation beside the main
 application content. It owns the page columns, not navigation state.
-ApplicationShell composes the standard Sidebar, Navigation, Header, and main
-column when a product wants the complete frame.
+ApplicationShell composes the standard frame when a product wants the complete
+shared chrome — either a console with a rail, or a single-surface top bar.
 
 ## Anatomy
 
+Console with rail (default):
+
 ```
 AppShell
 ├── Sidebar
@@ -17,15 +19,25 @@ AppShell
     └── page content
 ```
 
-The two slots are direct children. AppShell is a `div`; AppShellMain is a
+Single-surface top bar (`layout="topbar"`):
+
+```
+AppShell[data-layout="topbar"]
+└── AppShellMain
+    ├── Header (brand, primaryAction, header)
+    └── page content
+```
+
+The console slots are direct children. AppShell is a `div`; AppShellMain is a
 `main` with `min-width: 0`, so wide tables and log lines cannot push the
 Sidebar off screen. Sidebar owns its header, body, and footer.
 
-ApplicationShell takes `brand`, optional `primaryAction`, navigation groups,
-optional `footer`, optional `header`, and page content. A destination contains
-`href`, `label`, optional `active`, optional `onClick`, and optional leading or
-trailing content. The caller still decides the current destination and whether
-a destination follows its link or changes a view in place.
+ApplicationShell takes `brand`, optional `primaryAction`, optional `header`,
+and page content. The default `layout="sidebar"` also takes navigation groups
+and optional `footer`. A destination contains `href`, `label`, optional
+`active`, optional `onClick`, and optional leading or trailing content. The
+caller still decides the current destination and whether a destination follows
+its link or changes a view in place.
 
 ```tsx
 <ApplicationShell
@@ -46,6 +58,17 @@ a destination follows its link or changes a view in place.
 </ApplicationShell>
 ```
 
+```tsx
+<ApplicationShell
+  layout="topbar"
+  brand={<ProductBrand />}
+  primaryAction={<CreateProject />}
+  header={<BoardChrome />}
+>
+  {page}
+</ApplicationShell>
+```
+
 When `onClick` is present, ApplicationShell prevents link navigation and calls
 it. Without `onClick`, the destination remains a normal link. Use
 `navigationLabel` to distinguish this navigation landmark when the default
@@ -53,17 +76,28 @@ it. Without `onClick`, the destination remains a normal link. Use
 
 ## Variants
 
-One layout. No variant prop. Compose [Header](header.md) and
-[PageHeader](page-header.md) inside the main slot as the page requires.
+`layout="sidebar"` (default) mounts Sidebar with brand and primary action in
+SidebarHeader, navigation in SidebarBody, and optional footer. The optional
+`header` slot stays in the main column.
+
+`layout="topbar"` omits Sidebar entirely. Brand, optional primary action, and
+the optional `header` slot render together in Header. Do not pass `navigation`
+or `footer` in this mode — there is no rail to host them.
+
+Compose [Header](header.md) and [PageHeader](page-header.md) inside the main
+slot as the page requires when using AppShell directly.
 
 ## Sizes
 
 The Sidebar column uses `--size-sidebar`; the main column takes the remaining
 width with a zero minimum. The shell has a minimum height of one viewport.
-At widths of 1023px or less, the layout becomes one column and Sidebar is
+At widths of 1023px or less, a sidebar layout becomes one column and Sidebar is
 hidden. The product must provide access to navigation at that width, for
 example through a [Drawer](drawer.md).
 
+`layout="topbar"` is a single main column at every width. It does not rely on
+the 1023px media query to collapse a sidebar track.
+
 ## States
 
 The shell stays in place while page content loads, fails, or becomes empty.
@@ -77,6 +111,8 @@ Those states belong inside AppShellMain. There is no disabled or active shell.
   the main content.
 - Keep navigation available when the Sidebar is hidden. AppShell does not
   create a mobile menu or manage its focus.
+- A top-bar layout has no Sidebar navigation landmark; put destinations in the
+  Header or elsewhere in the product chrome.
 
 ### Keyboard
 
@@ -87,13 +123,16 @@ retain their own keyboard behavior.
 
 - An application with persistent navigation beside a changing page.
 - A console containing tables, detail panes, and logs in its main column.
-- Use ApplicationShell when the product follows the standard complete frame.
+- A single-surface product whose chrome is one top bar (`layout="topbar"`).
+- Use ApplicationShell when the product follows one of the two standard frames.
 - Use AppShell directly when its Sidebar or Header composition differs.
 
 ## When NOT to use
 
 - A standalone login or centered form. Use [Card](card.md) within the page.
 - Two resizable content panes. Use [Split](split.md) inside the main content.
+- Hiding a required rail with CSS. Prefer `layout="topbar"` or AppShell
+  composed without Sidebar.
 
 ## Radix/shadcn mapping
 

package/kiso/docs/components/chip-input.md

@@ -0,0 +1,194 @@
+# ChipInput
+
+One field that collects several structured values. Each value is a chip: a
+name, an optional editable value, and optional named options that belong to
+that chip alone.
+
+## Purpose
+
+ChipInput is for a list that a person builds by typing, where every item
+carries more than a label. A dependency list is the case that produced it:
+`node = latest`, `npm:t3 = latest` with `allow_builds = node-pty`,
+`apt:libssl-dev = latest`. The alternative is one form section per item, which
+grows without limit and buries the list itself.
+
+The component owns the box, the chips, the suggestion list, and the keyboard.
+The product owns what a chip means, which suggestions match the query, and
+which options a chip accepts. ChipInput never parses.
+
+### Choose the right multi-value control
+
+| Need | Control | Why |
+| --- | --- | --- |
+| Several values, each with its own options | **ChipInput** | Options stay attached to the value they configure. |
+| Several values from a known, short list | [Select](select.md) with multiple, or [Checkbox](checkbox.md) group | No free text, no per-value options. |
+| One value from a known set | [Select](select.md) | Single choice. |
+| Free text that is not a list | [Input](input.md) or [Textarea](textarea.md) | Nothing to chip. |
+| Filtering what is already on screen | [Search](search.md) | A query, not stored values. |
+| Running a global action | [CommandPalette](command-palette.md) | Commands, not data. |
+
+## Anatomy
+
+```
+ChipInput
+├── ChipInputBox (the field; a border, chips, and the caret)
+│   ├── Chip (repeated)
+│   │   ├── ChipScope (optional; what kind of value this is)
+│   │   ├── ChipName (required; the identity of the value)
+│   │   ├── ChipValue (optional; edits in place)
+│   │   ├── ChipOption (repeated; one option as name=value)
+│   │   ├── ChipOptionAdd (optional; the segment that takes a new option)
+│   │   └── ChipRemove (required when the chip can be removed)
+│   └── ChipInputField (the input; always last, always present)
+└── ChipInputList (optional; suggestions for the current query)
+    ├── ChipInputOption (repeated)
+    └── ChipInputEmpty (no match)
+```
+
+The box needs a name: a [Label](label.md) bound to `ChipInputField`, or
+`aria-label` on it. Explain the syntax in [HelperText](helper-text.md), not in
+the placeholder.
+
+A chip reads left to right like a call: `npm` installs `t3` at `latest` with
+`allow_builds=node-pty`. Its segments are divided the way [Button](button.md)
+groups divide buttons, and the two segments people press, the value and the
+options, carry the raised card fill. Use ChipScope only when the kind is a
+separate fact from the name; a tool with no backend is one segment, not an
+empty one.
+
+Each option is its own segment, written the way the configuration file writes
+it: `name=value`, and `name=[a, b]` when the value is a list. The brackets are
+the only difference between the two, so both read as the same kind of fact.
+Committing an option with an empty value removes it, and `ChipOptionAdd` sits
+last as a `+`. The cost is discovery: name the accepted options in
+[HelperText](helper-text.md), because the chip will not list them.
+
+Chips are content, not chrome. Do not put an action that leaves the field
+inside a chip.
+
+## Variants
+
+| Variant | Behavior |
+| --- | --- |
+| `open` (default) | Any typed entry can become a chip. Suggestions help but do not restrict. |
+| `restricted` | Only a suggestion becomes a chip. A typed entry with no match stays text until it matches. |
+
+Both render the same. The product enforces the difference when it turns a
+query into a chip.
+
+Do not add a "read-only chips" variant. Values that cannot change are
+[KV](kv.md) or [Badge](badge.md).
+
+## Sizes
+
+One size. The box is `--size-control-md` tall when empty and grows by row as
+chips wrap; chips are `--size-control-sm`. Width is a layout concern: fill the
+form column.
+
+## States
+
+| State | Behavior | Tokens / notes |
+| --- | --- | --- |
+| default | Chips and a caret ready for the next value. Rules run the height of the chip between segments, and the version segment sits raised on the card surface. | `--color-card`, `--color-input`, `--color-border`. |
+| hover | Quiet border emphasis on the box. A hovered version segment deepens its fill. | `--color-border-strong`, `--color-accent-surface`. |
+| focus | One ring around the whole box, never around the bare input. | `--color-ring`. |
+| editing a segment | The value or the options become an input sized to their content; the chip takes an accent border and a confirm control appears. | `--color-primary`, `--color-accent-surface`. |
+| no options | Only the `+` segment remains, in the subtle foreground. | `--color-subtle-foreground`. |
+| chip invalid | The single chip is marked, not the field. Say why next to the field. | `--color-danger-surface`, `--color-danger-border`, `--color-danger`. |
+| field invalid | `aria-invalid` on the box plus [ValidationMessage](validation-message.md). | `--color-danger`. |
+| disabled | The box and every chip control are unavailable; chips stay readable. | `--color-disabled-surface`, `--color-disabled`. |
+| empty | Placeholder in the input showing the shape of one entry. | `--color-subtle-foreground`. |
+
+An invalid chip and an invalid field are different failures. A version that
+does not exist marks the chip; "add at least one dependency" marks the field.
+
+## Accessibility
+
+- `ChipInputField` is the combobox: `role="combobox"`, `aria-expanded`,
+  `aria-controls` on the suggestion list, `aria-activedescendant` on the
+  highlighted option, `aria-autocomplete="list"`. The highlight moves; DOM
+  focus stays in the input.
+- The suggestion list is `role="listbox"` with `role="option"` children and
+  its own accessible name.
+- Every chip control has a name that includes the chip: "Remove npm:t3", "Add
+  npm:t3 options", "Edit npm:t3 version, currently latest". A bare "Remove" is
+  ambiguous once there are six chips.
+- Chip controls are real buttons in tab order. A long list is a long tab path;
+  that is the cost of keeping every control reachable without a roving
+  tabindex, and it is why removal is also on `Backspace`.
+- Removing a chip keeps focus in the field. Confirming an edited segment
+  returns focus to that segment.
+- Announce a chip added or removed through the surrounding status region, not
+  by moving focus.
+
+### Keyboard
+
+| Key | Action |
+| --- | --- |
+| Printable keys | Edit the query in the input. |
+| `ArrowDown` / `ArrowUp` | Move the highlight through the suggestions; wraps. |
+| `Enter` | Commit the highlighted suggestion, or the typed query in the `open` variant. While editing a segment, confirm it. |
+| `Tab` | Commit the highlighted suggestion. With no highlight, leave the field. The box never traps the keyboard. |
+| `Backspace` in an empty input | Remove the last chip. The field keeps focus, so a second press removes the next one. |
+| `Escape` | Close the suggestions. While editing a segment, cancel back to its previous text. |
+| `Shift+Tab` | Move back through the chip controls. |
+
+`Enter` on an empty input does not submit the form. A form with a single
+ChipInput must have an explicit submit Button.
+
+## When to use
+
+- A dependency, package, or tool list where each entry carries a version and
+  installer options.
+- Recipients, labels, or scopes where an entry can be qualified.
+- Any repeated "name plus settings" list a person types rather than picks.
+
+## When NOT to use
+
+- **A fixed, short set of choices.** Checkbox group or Select.
+- **One value.** Input or Select.
+- **Filtering a visible collection.** Search.
+- **Showing a list nobody edits.** KV, Badge, or Table.
+- **More than a few options per chip.** A row of `name=value` segments stops
+  reading at about three. If a chip needs a form, the chip is a record: use a
+  Table row and edit it in a [Modal / Dialog](modal-dialog.md).
+
+## Tokens
+
+Box and input follow [Input](input.md): `--color-card`, `--color-input`,
+`--color-border-strong`, `--color-foreground`, `--color-subtle-foreground`,
+`--color-ring`, `--color-disabled`, `--color-disabled-surface`, `--radius-md`,
+`--shadow-xs`, `--size-control-md`, `--spacing-xs` padding,
+`--motion-duration-fast` and `--motion-easing-standard`.
+
+Chips: `--color-secondary`, `--color-secondary-foreground`, `--radius-sm`,
+`--size-control-sm`, `--type-size-label`, `--font-mono` and
+`--type-size-metadata` for the segments, `--color-muted-foreground` for the
+scope and for an option's name, `--color-subtle-foreground` for the `=`, the
+brackets and the empty `+`, `--color-border` for the rules between segments,
+`--color-card` for the value and option segments with `--color-accent-surface`
+when hovered, `--color-foreground` for an option's value, `--color-link` for
+the version,
+`--color-primary` and `--color-accent-surface` while editing,
+`--color-accent-surface-hover` on chip controls, `--color-danger-surface`,
+`--color-danger-border` and `--color-danger` when a chip is invalid.
+
+Suggestions reuse the menu surface: `--color-popover`, `--color-border`,
+`--radius-lg`, `--shadow-lg`, `--color-selected` and
+`--color-selected-foreground` for the highlight. Label, HelperText, and
+ValidationMessage bring their own tokens. No raw hex/px.
+
+## Radix/shadcn mapping
+
+No Radix combobox primitive and no shadcn tag input.
+
+| Kiso | Reference |
+| --- | --- |
+| Box and field | Native `input` styled like shadcn [Input](https://ui.shadcn.com/docs/components/input), inside a bordered wrapper that owns the focus ring |
+| Suggestions | The [CommandPalette](command-palette.md) listbox pattern: `aria-activedescendant` over `role="option"` children, not a focus-moving menu |
+| Chip options | No reference: one inline segment per option, each swapping to a native `input` like the value |
+| Chip | Kiso chip classes, not [Badge](badge.md): a Badge is not interactive and does not close |
+
+Do not map ChipInput to shadcn [Command](https://ui.shadcn.com/docs/components/command)
+or to a multi-select built on Select. Both fight the free-text entry this
+component exists for.

package/kiso/docs/components/sparkline.md

@@ -0,0 +1,93 @@
+# Sparkline
+
+## Purpose
+
+Shows the shape of one metric series in the space of a table cell or a Stat
+tile. The number beside the line carries the precision; the line carries the
+shape. A Sparkline answers "is this trending up", never "what was the value
+at 09:41".
+
+The evidence that forced the v1 deferral open: the self-host console collects
+metrics in-process, one sample per tick on an evenly spaced window, and needs
+the same shape three times over. A cell trend per application row, context
+under a KPI value, and one series per container in a detail view.
+
+## Anatomy
+
+A single `div` frame around one SVG path. No axis, no grid, no legend, no
+tooltip, no pointer behavior. It is a drawing of a number that is already
+present somewhere nearby, or that names itself when it is not.
+
+## Variants
+
+| Prop | Values | Meaning |
+| --- | --- | --- |
+| `tone` | `neutral` (default), `primary` | Neutral uses `--color-border-strong`, the voice of an incidental series. Primary uses `--color-primary` and marks the series a tile is about. At most one sibling raises its voice. |
+| `fill` | `false` (default), `true` | Draws the area under the line in the same color at 0.12 opacity. The fill is flat; there is no gradient. |
+
+## Sizes
+
+`height` is a number of pixels, default `24`. The known cases: `18` in a
+table cell, `24` in a detail row, `28` under a Stat value. Width is always
+the container; the line stretches with it. Do not place a Sparkline inside a
+fixed-height box that crops it.
+
+## Scale
+
+By default the domain is the data's own extent, so one series fills its box.
+Pass `min` and `max` to make sibling Sparklines share a scale: comparing
+containers in one table only means something if the rows share one domain. A
+flat series (every value equal) is padded automatically so it still draws a
+line.
+
+## States
+
+| State | Behavior |
+| --- | --- |
+| fewer than two samples | Renders nothing. A flat rule across a cell reads as a border, not as a measurement. Keep the cell's number; reserve height with the surrounding layout. |
+| loading | [Skeleton](skeleton.md) at the same height the Sparkline will occupy. |
+| error | Show the last known number as text; the shape is optional, the value is not. |
+
+The component takes plain values and does not model gaps. A series with holes
+is the caller's data problem; interpolate or truncate before passing it in.
+
+## Accessibility
+
+This is the contract, not a guess:
+
+- When the value is readable as text beside the drawing (a table cell, a
+  Stat), omit `label`. The component renders `aria-hidden` and is decoration;
+  the number is the accessible content.
+- When the Sparkline is the only presentation of the series, pass `label`.
+  It renders `role="img"` with that string as `aria-label`. Name the metric
+  and the window: "CPU, last 5 minutes, 10-second ticks". Even then, put the
+  current value in nearby text when any action depends on it.
+- Announcing every refresh of a live series would be noise. The drawing
+  updates silently; rely on the adjacent number for change awareness.
+
+### Keyboard
+
+No keymap and no tab stop. A Sparkline is never an action.
+
+## When to use
+
+- Trend cell in a table row: is this application busier than a minute ago.
+- Context under a [Stat](stat.md) value on a dashboard.
+- One series per container in a detail view, rows sharing a scale.
+
+## When NOT to use
+
+- Analysis that needs an axis, a legend, or crosshair reading. A framed,
+  interactive chart is a separate, still-deferred contract.
+- Multi-series overlays. Stack several Sparklines only as separate rows with
+  their own labels, never as one drawing with a homemade legend.
+- A single value with no history. Use [Stat](stat.md) alone.
+
+## Recharts mapping
+
+No Radix primitive exists for this. The component composes Recharts
+`ResponsiveContainer`, `AreaChart`, and `Area` with animation, dots, and
+axes off. Color reaches the path through `currentColor` from the
+`.sparkline` rules in `ui.css`; never pass a hex value or invent a
+categorical palette. The framed `.chart` rules in `ui.css` stay reserved for
+the later interactive chart contract.

package/kiso/docs/components/table.md

@@ -218,7 +218,9 @@ Alert.
   or PageHeader — not a one-row table.
 - **Hierarchical location.** Breadcrumb (navigation slice).
 - **Free-form layout.** Cards or a custom panel; tables imply comparison.
-- **Charts.** Deferred to v2; do not stretch Table into a graph.
+- **Charts.** Do not stretch Table into a graph. A per-row
+  [Sparkline](sparkline.md) trend inside one cell is fine; the table itself
+  stays a table.
 - **Global actions / jump-to.** [CommandPalette](command-palette.md), not a
   table of commands.
 - **Filtering UI embedded as magic columns.** Use Search + filters in the

package/kiso/docs/evolution.md

@@ -10,7 +10,7 @@ the system needs them. This is the honest roadmap for those choices.
 | --- | --- | --- |
 | **Component implementation code** | V1 ships Markdown contracts and tokens, not React components. Keeping the specification separate lets product needs shape an implementation instead of freezing an assumed API. This boundary was set in [epic #3](https://github.com/momoi-labs/blueprint/issues/3). | When repeated product implementations make a stable reference API evident. Build it as Kiso v2 or in a separate `kiso-ui` repository, using shadcn/Radix behavior adapted to Kiso rather than copied unchanged. |
 | **Radio / RadioGroup** | Select and Switch cover the v1 choice cases, so [epic #3](https://github.com/momoi-labs/blueprint/issues/3) did not add another selection primitive without a product need. | When a product genuinely needs mutually exclusive selection from a small, fixed set whose options should remain visible. |
-| **Charts and graphs** | V1 has no chart component or data-visualization pattern because [epic #3](https://github.com/momoi-labs/blueprint/issues/3) had no concrete visualization case to design for. | When a product needs metric visualization, likely a DB or infrastructure tool with a dashboard. Start from that product's data, tasks, and accessibility requirements. |
+| **Interactive framed charts** | [#84](https://github.com/momoi-labs/blueprint/issues/84) shipped [Sparkline](components/sparkline.md) for the single-series metric shapes products actually had. No product has yet needed an axis, a legend, or crosshair reading. | When a product needs exploratory reading of a series: axes, multi-series overlays, or hover inspection. Settle the framed `.chart` contract then. |
 | **Figma Tokens Studio integration** | [Epic #2](https://github.com/momoi-labs/blueprint/issues/2) kept the token pipeline focused on its committed outputs. Tokens Studio is a Figma plugin workflow built through Style Dictionary and `@tokens-studio/sd-transforms`, not a standalone emitter. | When design-to-code synchronization through Figma becomes a real team workflow rather than a hypothetical integration. |
 | **DTCG 2025.10 Resolver module** | The multiple-context and theme Resolver considered in [epic #2](https://github.com/momoi-labs/blueprint/issues/2) is a preview draft marked “do not implement.” V1 uses an explicit, stable theme model instead. | When the Resolver module reaches stable status and Kiso has a concrete context or theme problem it would solve. |
 | **`--shadow-lg`** | The elevation scale intentionally stops at `--shadow-sm` and `--shadow-md`; [#25](https://github.com/momoi-labs/blueprint/issues/25) fixed component references without inventing a larger elevation. | When a real overlay or hierarchy cannot be expressed clearly with `--shadow-md`. Propose the token in the source, then regenerate its outputs. |
@@ -19,6 +19,15 @@ the system needs them. This is the honest roadmap for those choices.
 | **Additional components** | The roughly 28-component cut from [epic #3](https://github.com/momoi-labs/blueprint/issues/3) covers the intended v1 product surface. Adding primitives in anticipation would enlarge the interface before their contracts are understood. | When a need recurs across products. Propose a component and its contract; do not invent one locally or copy one in unchanged. |
 | **Heavy governance** | A two-person lab does not need a contribution bureaucracy or design-review board. For v1, the propose-don't-copy rule in [`kiso/AGENTS.md`](../AGENTS.md) is the governance mechanism, as scoped by [epic #5](https://github.com/momoi-labs/blueprint/issues/5). | When more contributors, products, or incompatible proposals make ownership and decision-making unclear. Add only the process needed to resolve an observed coordination problem. |
 
+## Accepted additions
+
+The growth model below is not theory. What it has produced so far:
+
+| What | Evidence | Where |
+| --- | --- | --- |
+| **[ChipInput](components/chip-input.md)** | A self-hosted console had to collect a development image's dependencies: a list a person types, where every entry carries a backend, a version, and installer options. One form section per entry grew without limit and buried the list. | Added as a component contract with the segmented chip, the in-place value, and one segment per option. |
+| **[Sparkline](components/sparkline.md)** | The self-host console collects metrics in-process, one sample per tick on an evenly spaced window, and needed the same shape three times over: a trend cell per application row, context under a KPI value, and one series per container. [#84](https://github.com/momoi-labs/blueprint/issues/84) records the evidence. | Added as a component contract and a Recharts-based component, single series, neutral by default, primary only for the series a tile is about. |
+
 ## Growth model: grow with real products
 
 Kiso is not an abstract design-system project. It evolves through product work:

package/kiso/docs/patterns/dashboard.md

@@ -35,8 +35,9 @@ Tokens: page canvas `--color-background`, widgets `--color-surface` with
 semantic colors, focus `--color-focus`. Prefer quiet surfaces and strong
 hierarchy ([principles](../principles.md)).
 
-Charts are out of scope for this epic; when charts exist later, they sit inside
-Card like any other widget payload.
+[Sparkline](../components/sparkline.md) carries metric shape inside Cards and
+table cells; it composes like any other widget payload. An interactive framed
+chart remains deferred.
 
 ## Flow
 

package/kiso/docs/patterns/settings.md

@@ -19,6 +19,7 @@ immediate vs deferred persistence, and unambiguous save feedback.
 | Section nav | [Tabs](../components/tabs.md) or Sidebar sub-nav [Link](../components/link.md)s | Split General / Notifications / API, etc. |
 | Groups | [Card](../components/card.md) | One settings group per Card |
 | Text / choice fields | [FormField](../components/form-field.md) | [Label](../components/label.md) + [Input](../components/input.md) / [Select](../components/select.md) / [Textarea](../components/textarea.md) + [HelperText](../components/helper-text.md) + [ValidationMessage](../components/validation-message.md) |
+| Repeated values with their own options | [ChipInput](../components/chip-input.md) | One field for a list a person types, such as dependencies or scopes, instead of a form section per entry |
 | Booleans | [Switch](../components/switch.md) (immediate) or [Checkbox](../components/checkbox.md) inside FormField (part of a saved form) | Switch for single immediate preferences; Checkbox when the value submits with Save |
 | Actions | [Button](../components/button.md) | Save (primary), Reset/Cancel (secondary) for explicit-save sections |
 | Feedback | [Toast](../components/toast.md), [Alert](../components/alert.md), [ValidationMessage](../components/validation-message.md) | Saved confirmation; section errors; field errors |