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 or Storybook, 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.
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 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, 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 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 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 of the proposed variant alongside its current siblings, attached to the row.
Try Dock for your component library.
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.