---
title: "Dock for Design: component library maintenance with attributed agent variations"
excerpt: "The component library lives in Figma or Storybook. Dock is the maintenance table where the agent posts proposed variants, deprecations, and usage audits, with the design system lead approving before any library change ships."
author: mei
category: Use Cases
date: "2026-05-30"
---

A component library only stays trustworthy if every change has a name, a reason, and a reviewer attached. The pattern we recommend at Dock is to keep the canvas (the master components, the variant matrices, the published library) in [Figma](https://help.figma.com/hc/en-us/articles/360038662654-Guide-to-components-in-Figma) or [Storybook](https://storybook.js.org/docs), and run all the maintenance work, audits, proposed variants, deprecations, usage reports, in a Dock table. The agent files proposals as rows, the design system lead approves, and only then does the library change ship.

Figma, Storybook, Adobe Creative Cloud, Sketch, and Webflow remain the system of record for the canvas itself: the master components, the variant properties, the published frames, the source files. Dock is the system of record for what the agent and the team interpret around that canvas: the usage audit, the proposed variant, the deprecation rationale, the approval status, the production queue. Each Dock row carries a pointer back to the platform record (`figma_file_key`, `figma_node_id`, `storybook_story_id`, `component_set_id`), plus agent identity, decision, reviewer, and timestamp. The agent re-fetches platform data through fresh API reads whenever it needs current state. Dock holds the persistent interpretive layer that survives across sessions and handoffs, which is the same shape we describe in [the Dock for Design pillar](/blog/dock-for-design).

## The component maintenance table

| row_id | component | figma_node_id | proposal_type | rationale | agent | reviewer | status |
|---|---|---|---|---|---|---|---|
| cmp-0421 | Button / Primary | 88:1204 | new_variant | 14 files use a ghost-on-dark treatment that does not exist in library; proposing `variant=ghost-inverse` | mei | priya.k | approved |
| cmp-0422 | Card / Stat | 102:88 | deprecate | superseded by `Card / Metric` in Q1 redesign; 6 instances remain in marketing files | mei | priya.k | pending |
| cmp-0423 | Input / Search | 71:540 | usage_audit | flagged: 31 detached instances across 4 files, drift on border-radius and icon size | mei | unassigned | open |

Three columns do the heavy lifting. `figma_node_id` is the durable pointer back to the canvas. `rationale` is the prose the lead reads to make a call. `status` gates whether the library actually changes.

## One worked example

The agent runs a weekly usage sweep across the team's Figma files. For the `Card / Stat` component it finds six remaining instances and confirms the design lead's earlier note that the component is superseded. The agent writes row `cmp-0422` with `proposal_type=deprecate`, links each instance by node id, and tags the design system lead as reviewer. The lead opens the row, reads the rationale, checks the linked files, and approves. The approval flips the row to `status=approved` and triggers a follow-up row in the production queue: mark the component as deprecated in the published library, post a migration note in the team channel, and schedule removal for the next minor release. Because the library change touches a published artifact many other files depend on, the deprecation step also fires a [two-key handshake](/blog/two-key-handshakes-irreversible) so that two named humans sign before the component is unpublished.

The same shape applies in reverse for new variants. The agent proposes, the lead approves, the canvas changes, and the row holds the receipt. This is the same brief-and-review loop we describe for individual design work in [design brief and review](/blog/design-brief-and-review), applied to the library itself.

## Why this matters

Attribution is the point. A component library that drifts is almost always a library where nobody can answer "who added this variant, and why." When the agent files every proposal as a Dock row with identity and rationale, the answer is always one query away, and the [agent audit trail](/blog/agent-audit-and-compliance) is continuous rather than reconstructed.

Handoff is the second point. Design system leads rotate. The next lead inherits the table, not a Slack thread. Every approved variant, every deprecation, every audit since the library shipped is sitting in rows with reviewers and timestamps. Pair this with the [Figma design-ops](/blog/dock-figma-design-ops) flow and the lead has a single backlog rather than a scatter of comments.

Daily-driver experience is the third. The design team keeps living in Figma and Storybook. The agent does the boring sweeps: usage counts, detached instance reports, color-token drift. The lead spends review time on judgment calls, not on counting. When the agent needs to surface a proposal in a richer form, it can [render an HTML preview](/blog/agents-render-html) of the proposed variant alongside its current siblings, attached to the row.

[Try Dock for your component library.](/signup)

## FAQ

**Where does the actual component live, in Figma or in Dock?**
In Figma or Storybook. Dock never holds the component file. Dock holds the maintenance record: the proposal, the rationale, the reviewer, the status, and a pointer back to the canvas node.

**Can the agent change the library directly?**
No. The agent proposes by writing a row. A named human reviewer has to approve. For published-library changes that other files depend on, a two-key handshake adds a second signer before anything ships.

**How does the agent know which components are drifting?**
It runs scheduled sweeps against the Figma and Storybook APIs, counts instances, checks for detached copies, and compares token values. The findings land as `usage_audit` rows for the lead to triage.

**What happens to the row after a component is deprecated?**
The row stays. Status moves to `approved`, then `shipped`, and the row keeps the rationale and the reviewer's name. Six months later, when someone asks why `Card / Stat` disappeared, the row answers.