DottaandPaperclip
c8efdbfba4
## Thinking Path > - Paperclip manages AI agents and their work. > - The feature map records the user-facing capabilities. > - Storybook uses the same feature index. > - Step 2 found 49 UI capabilities with no authored examples. > - This pull request adds shipped-component examples with isolated fixtures. > - The catalog records each example's states and remaining production checks. ## Linked Issues or Issue Description Refs: #16167. The verification inventory is merged; this follow-up now targets master. ## What Changed - Add 37 suites and 257 scenarios for all 49 UI capabilities from the step-2 inventory. Keep existing stories and IDs. - Use shipped pages and components. Simulate API replies, sockets, props, and callbacks at their boundaries. - Activate story API fixtures before the application providers read data. Block unregistered API mutations and restore owned storage/fetch state. - Add browser checks for rendering, declared play assertions, fixture reset, and selected mobile/theme states. Update the catalog and verification inventory. ## Verification - `pnpm -r typecheck`: passed. - `pnpm build`: passed. - UI Vitest suite: 730 files and 8,208 tests passed. Fixture boundary tests: 4 passed. - Map/catalog checks, 27 generator/map tests, and token gates: passed. - `pnpm build-storybook`: passed. All 2,248 previous built entry IDs remain present. - Pre-reconciliation static browser suite: 260 checks passed (257 scenarios, token fixture reset, and two mobile/theme cases). All non-play stories assert an explicit subject state; 129 play functions passed. - `pnpm test:run` could not complete on this Mac. Embedded PostgreSQL exhausted host shared-memory allocation. The run also reported native-runner test timeouts. Only this task's verified runner was stopped; other jobs and host settings were preserved. - Reconciled onto merged master `252d9b5077`. The six draft stories and new same-browser reset regression passed (7 checks); 16 draft-persistence tests and UI typecheck passed. Static merge verification: 32 affected-subject/draft checks passed, including same-browser reset. Rebuilt Storybook retains all 2,248 original IDs in its 2,517-entry index. Four additional play-result checks passed: visible onboarding reset, pending probe, filtered-empty runs, and optimistic queued-response removal. UI typecheck and 27 catalog/map tests also passed. Final static browser suite on `3fab35df8d912935fa86ce0de7d32d07e2b5f4c3`: all 261 checks passed (257 scenarios plus fixture-reset and mobile checks). Latest head `3fab35df8d912935fa86ce0de7d32d07e2b5f4c3`: all 55 CI/status checks passed; the two optional Storybook workflow jobs were skipped. Greptile 5/5 with no unresolved threads. - No pinned Linux visual-baseline comparison or real provider journey is claimed. ## Risks Fixtures can drift from production contracts. The catalog records inspected sources and their fingerprints. Capability links provide initial isolated UI coverage; they do not certify every recipe variant, real permissions, persistence, or provider behavior. The new examples expose existing UI limits. Plugin discovery failure stays on Loading. Document and environment-list reads lack dedicated failure feedback; Cases and Inbox fall back to empty views after errors. Goal alignment has display views but no assignment control. These findings remain visible in the inventory. ## Model Used OpenAI GPT-6 via Codex. The exact runtime deployment ID and context window are not exposed in this session. Used code generation, shell execution, and browser verification. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] All Paperclip CI gates are green - [x] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge --------- Co-authored-by: Paperclip <noreply@paperclip.ing>
Storybook map
The feature index connects the existing Storybook to stable capability
IDs from the upstream feature map. Story files remain
in ui/storybook/. The feature map and its maintenance skill do not depend on
this catalog. New capabilities or upstream recipe drift are reported to their
maintainer; this catalog does not redefine product behavior or permissions.
Ownership
- maintain-storybook owns story alignment, fixture corrections, classification, and this catalog.
- review-storybook consumes it to select and exercise examples, then reports evidence and drift.
- DESIGN.md governs design. Production verification remains with the existing product recipes and verification tools.
Catalog contract
catalog.json is the maintained inventory, with one entry per authored story file.
INDEX.md is generated from it, the upstream feature map, and the installed Storybook CSF parser. Titles,
export filtering, story counts and IDs come from source, not filename guesses.
All examples are retained, including historical suites. A file's first capability
is its primary home; remaining capabilities are lookup references, not copies.
Shared foundations may declare home: "foundations" to retain their folder and
sidebar while linking related capabilities. This override requires an exception
reason; it is not available for arbitrary feature homes.
Foundations/guides and proposals without a mapped capability need an exception
reason. An absent story is not automatically a feature gap.
Verification routes classifies the currently unassociated capabilities: UI examples to add, CLI/operator operations, and real browser checks. It records source review and existing test starting points, not executed proof. Update its rows/counts and source revision when associations or upstream capabilities change. A capability with a story still needs production verification for permissions, persistence, execution and provider behavior.
Folders and sidebar
Story files live in ui/storybook/stories/<primary-feature-area>/, using the first
capability's area slug. Related capabilities still point to the same story. Shared
fixture modules and assets live in ui/storybook/support/; production wrappers in
ui/storybook/prototypes/ retain their existing ownership.
The sidebar follows the section and feature names in the feature-map README, then
retains each suite's useful scenario grouping. Foundations contains shared component
examples with no primary product capability. Overview contains the catalog guide.
Every indexed feature has an Overview page, even when it has no cataloged examples.
The main guide and these pages use the same section, feature, and capability order
as the upstream map. Related suite links cross primary homes without copying stories.
Sidebar labels replace / with , because Storybook treats slashes as folders;
the index and page heading retain the original feature name.
Missing examples are explicit; historical examples and guides do not imply current
behavioral coverage.
ui/storybook/generated/ contains the derived index and one CSF Overview per
feature. The inline storySort.order in the preview config is also generated:
Storybook's indexer requires a literal there. Regenerate these outputs with the catalog command; do not edit
them or add them to the authored inventory. Their stable IDs use
feature-map-<area>--overview. Generated pages are explanatory guides and do not
increase example-suite counts. Storybook start/build checks this output for drift.
The generator fails on unexpected files rather than silently deleting them.
Each suite declares an explicit CSF id, recorded as stableId in the catalog.
The sidebarTitle can change without changing that identity. Existing story and
autodocs URLs and screenshot names remain valid. Do not derive a replacement ID
from a newly organized title. The checker rejects missing or changed explicit IDs,
incorrect feature folders, and sidebar titles outside their primary feature home.
Each entry records purpose, capability references, review sources/date/fingerprint, notes, and three independent dimensions:
| Dimension | Values |
|---|---|
| Product status | current: source comparison supports the named subject; proposed: intentional alternate design; historical: superseded reference retained for its original purpose; mixed: suite combines these; unreviewed: parity has not been established |
| Implementation | production: shipped subject with fixture/layout wrappers; prototype: locally implemented subject, even if it uses shared primitives; mixed: both subjects; guide: explanatory documentation |
| Data boundary | fixtures: props, callbacks, caches or API responses are simulated; fixture-server: requires a separately owned local API/database fixture with simulated upstream providers; static: explanatory/static examples |
current is a source-review classification, not a promise that every state renders
or that APIs, gates, persistence and providers passed live tests. unreviewed
entries still have an inventory/classification review; notes explain the deeper
parity work outstanding. Mixed files retain a note naming the important split.
Production components can legitimately use mock data. A prototype directory name
does not establish implementation: some wrappers there re-export shipped UI.
Review sources include the story, relevant local support and production subjects. Include directly rendered subjects regardless of import spelling, and primitives when the suite demonstrates them. Do not truncate the list to a fixed source count. Fingerprints make changes to those declared dependencies visible. They do not follow every transitive production import or infer semantic correctness. Shared preview/config/fixture changes have a separate fingerprint and require reviewing affected callers. Update fingerprints only after reviewing the change, and add missing dependencies when discovered. Date/revision context for the initial pass and executed evidence belong in REVIEW.md.
Maintenance commands
After installing workspace dependencies:
node scripts/storybook-catalog.mjs
node scripts/storybook-catalog.mjs --write
node --test scripts/storybook-catalog.test.mjs scripts/storybook-feature-index.test.mjs
The checker rejects unaccounted or deleted stories, invalid capability references,
duplicate entries/IDs, missing review sources, changed fingerprints and a stale
generated indexes and feature pages. --write only regenerates these outputs; it never refreshes review
fingerprints or blesses drift. Preserve IDs when changing titles or moving files;
compare the existing built Storybook index before and after such changes.
Feature outputs are regenerated before fingerprints are checked. If those writes
change a review source, the command fails with the affected review entries. Inspect
the generated change before updating those fingerprints and rerunning the command.
Use the existing Storybook workflow for builds,
browser review, and visual tests. Report source inspection, rendering, play
assertions, visual comparisons and production acceptance separately. Do not publish
new visual baselines just to make catalog maintenance pass.