mirror of
https://github.com/paperclipai/paperclip.git
synced 2026-10-22 16:51:28 +02:00
Devin FoleyandPaperclip
5a6d0d08a7
## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - Recovery must preserve files and show the next operator action. > - A stopped run can leave a file repair hold after its recovery action is resolved. > - The task notice shows that hold but has no form to record verified file recovery. > - A chat connection can also replace the file repair instruction with a chat retry instruction. > - This pull request adds a file recovery form and preserves the file repair instruction. > - The form records evidence for the original run and keeps the current task status. ## Linked Issues or Issue Description **What happened?** A retained workspace file hold can block a task after its recovery action is resolved. The task page offers no file recovery form. A chat binding can hide the required file repair instruction. **Expected behavior** An authorized board member can record verified recovery of the original files. The server checks the original stop proof. The task keeps its current status and does not start another run. Chat instructions must not replace file repair instructions. **Steps to reproduce** 1. Create a stopped legacy run with a retained workspace recovery marker and a resolved recovery action. 2. Open its task page, including a task with a chat connection. 3. Observe that the file hold has no supported form to record verified recovery. Refs: #15857, #15824, #16095. Those PRs address shutdown export, native finalization and workspace source isolation. This PR uses the existing file repair API. ## What Changed - Add a board-only file recovery form with evidence and an explicit file verification confirmation. - Preserve the current task status when recording file recovery. - Project whether the original recovery marker supports file recording. - Keep file repair instructions when a task has a chat binding. - Add UI, route and Storybook examples for success, denial and chat-connected file holds. - Document the recovery flow and update the affected Storybook catalog entries. ## Verification - Merged master `c8efdbfba43` and resolved both rounds of catalog/index conflicts. Upstream review notes and classifications are preserved, together with all four retained-file recovery examples and their stable story IDs. Both fix branches also combine without merge conflicts or catalog fingerprint drift. - Passed locally after conflict resolution: 47 tests covering the file recovery UI, execution blocker notice and retained workspace repair route. The earlier ownership-route pass also covered 196 tests. - Passed: UI token gates, the complete Storybook catalog check with no drift errors, feature and agent map structure checks, and all 17 catalog/index script tests. Verification inventory counts match all 262 authored suites and 2,485 story IDs. The upstream production verification obligations remain intact. - Passed: full workspace typecheck, build and Storybook build on latest head `10ac22b35d0a4fe469cf620914845c509046da48`. The built index retains all four file-recovery story IDs. - Latest head `10ac22b35d0a4fe469cf620914845c509046da48` has 54 successful checks and two intentionally skipped Storybook checks. Apex is 5/5 on that exact commit, with no unresolved findings. The full general/serialized suites and all eight browser shards passed in CI. Local tests use the focused suites above. Storybook browser interactions have not been executed locally. - Manual check: open a task with a retained file hold. Verify that evidence and confirmation are required. Record verified file recovery. Confirm that its status stays unchanged and no run starts. Repeat without board runtime access and with an unverified stop receipt. ## Risks - The form records an operator attestation. It does not recover files itself or prove external action outcomes. - A stale source or missing stop proof must remain rejected by the existing server route. - No database migration or automatic task retry is added. ## Model Used OpenAI GPT-6 (`gpt-6`), used through Codex with reasoning, repository tools, code editing and test execution. The exact context window size is not exposed by this environment. ## 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>
60 KiB
60 KiB
Verification routes for Storybook capabilities
Updated 2026-10-13. Production source is reconciled with master 252d9b5077; step-3 story and fixture changes are recorded in the catalog fingerprints.
The catalog has 262 authored suites, 2,485 authored story IDs and 175 feature-map capabilities. The 37 new production-subject suites add 257 scenarios and associate all 49 UI capabilities identified in step 2. 11 capabilities remain without authored examples: 8 CLI/operator operations and 3 real-browser concerns. Generated Overview pages and guides do not count as examples. Existing suites and story IDs are retained. The four retained-file recovery states are preserved alongside the new examples from master c8efdbfba43; this inventory update does not claim an additional production verification run.
These associations provide initial isolated UI coverage, not complete parity with every feature recipe. The original scenario inventory below stays as a maintenance checklist; an association does not mark every listed variant complete. In particular, import examples cover preview, organization archival examples cover the list/restoration side, and custom-image examples cover metadata/configuration rather than a real setup terminal. Existing unreviewed suites remain unreviewed.
A story can establish component rendering, fixture shape and asserted interaction. It cannot establish real authentication, permissions, persisted changes, run continuation, provider delivery or installation. The production journeys listed below have not been run as part of this Storybook pass. Existing test links identify starting points, not exhaustive or passing production acceptance evidence.
New example suites
All subjects use shipped components. APIs, socket messages, callbacks and storage seeds are simulated. Review results and source limitations are recorded in the catalog; the focused browser command is:
pnpm build-storybook
node scripts/serve-storybook-static.mjs --port 6136
# In a second terminal:
pnpm exec playwright test --config tests/storybook-visual/feature-gap-stories.config.ts
The static server must be an owned process serving this checkout. Override the browser target with PAPERCLIP_GAP_STORYBOOK_URL when using another owned port. The browser suite asserts each non-interactive story's expected content, skeleton or documented fallback and waits for declared play assertions; it also checks reset when switching token and uncertain-draft stories in one browser. This is not the pinned Linux visual-baseline comparison.
Production UI limitations exposed
- Plugin contribution discovery errors remain on “Loading…”. The named DiscoveryFailure story exposes this shipped behavior; it does not claim a useful failure state.
- The document section and execution-environment list lack dedicated read-error/loading presentation. Cases and Inbox also fall back to empty views after list errors. Their stories retain the real fallback behavior. Custom-image metadata has its own loading and error states.
- GoalDetail displays aligned projects and children. The current UI has no project goal-assignment control. The stories do not invent one.
- Accepted queued responses disappear optimistically while delivery is pending; the shipped component has no separate visible progress indicator. The Delivering story asserts this presentation.
- Conference Room maps a denied stream to its generic assistant-unavailable message. Real permission enforcement belongs to the separate route verification.
UI scenarios and separate production contracts
These 49 capabilities now have initial shipped-component examples. Keep the requested scenarios below as the target for continued maintenance. Loading, empty, failure, permission and successful states are appropriate only when the production subject supports them. The separate production contracts remain required.
| Capability | UI scenarios to maintain | Separate production evidence | Source and existing test starting points |
|---|---|---|---|
onboarding/resume |
Restored incomplete wizard; invalid or unauthorized saved company; temporarily withheld draft; account switch; storage failure. | Reload company-prefixed onboarding without duplicating company; restore only authorized account/company draft and retain input after recoverable loading failure. | Source: OnboardingWizard.tsx, onboarding-state.ts. Tests: OnboardingWizard.test.tsx, onboarding-state.test.ts, onboarding.spec.ts |
access/login |
Sign-in form, pending and invalid credentials, deployment-mode claim gate, expired claim. | Authenticate and reload company deep link; sign out and confirm session enforcement; reject invalid bootstrap claim. | Source: Auth.tsx, BoardClaim.tsx, board-claim.ts. Tests: Auth.test.tsx, auth-session-route.test.ts, board-claim.test.ts |
access/membership |
Member and join-request lists; editable versus read-only roles; pending change, rejected request, revoked invite. | Persist role/membership changes; enforce actual actor authority, invite replay/expiry and cross-company denial. | Source: CompanyAccess.tsx, authz.ts. Tests: CompanyAccess.test.tsx, invite-accept-replay.test.ts, multi-user-authenticated.spec.ts |
access/cli-auth |
CLI authorization approval, pending, expired/denied and already-authorized states. | Authorize intended CLI identity/context, make scoped request, revoke current server token and retry same bearer; logout alone is insufficient. | Source: CliAuth.tsx. Tests: cli-auth-routes.test.ts, board-auth.test.ts, token.test.ts |
companies/selection |
Company list/create/switcher; empty, loading, error, unavailable company and switched navigation. | Switch and reload between companies; verify tasks/agents/cache/routes remain scoped and unauthorized company requests fail. | Source: Companies.tsx, CompanySwitcher.tsx, CompanyContext.tsx. Tests: Companies.test.tsx, CompanyContext.test.tsx, companies-route-cross-company-authz.test.ts |
companies/archive |
Archive confirmation, pending/error and departure navigation; archived list entry and Unarchive action. | Archive eligible agents/runs without deleting history; restoration handles archival-specific pause and navigates to correct company. | Source: CompanySettings.tsx, Companies.tsx, companies.ts. Tests: CompanySettingsArchive.test.tsx, Companies.test.tsx, companies-service.test.ts |
companies/portability |
Import/export preview, conflict choice, warnings, async progress/failure/success and restricted managed deployment. | Apply real small package to disposable target; inspect counts/references/conflicts, source immutability and credential exclusions; imported task requires separate runnable-account proof. | Source: CompanyImport.tsx, CompanyExport.tsx, companies.ts. Tests: CompanyImport.test.tsx, CompanyExport.test.tsx, company-portability-routes.test.ts, company-import-export-e2e.test.ts |
inbox-search/views |
Mine/Recent/Unread/Blocked and broader task views; combined versus standalone host; loading/empty/error/filter states. | Use persisted personal participation/read data; verify scoped counts and list navigation/reload; automatic read cleanup must not create Mine membership. | Source: Inbox.tsx, Issues.tsx. Tests: Inbox.test.tsx, Issues.test.tsx, issues-service.test.ts |
inbox-search/toasts |
Eligible live task toast, explicit mention, quiet unrelated event, own-action/visible-task suppression, dedupe and company/account switch. | Persisted participation and mentions determine per-viewer socket eligibility; quiet events still refresh caches; reload retains eligibility, unauthorized resources remain denied. | Source: ToastViewport.tsx, ToastContext.tsx, LiveUpdatesProvider.tsx, task-toast-eligibility.ts. Tests: ToastContext.test.tsx, ToastViewport.test.tsx, LiveUpdatesProvider.hook.test.tsx, task-toast-eligibility.test.ts, live-events-toast.test.ts, multi-user-authenticated.spec.ts |
agent-chat/conference-room |
Conference-room flag disabled, empty/history/reply, busy and explicit failure states. | Exercise separate BoardChat route gate, local-trusted deployment and authenticated Claude CLI; send/reload real conversation with responding agent attribution. | Source: BoardChat.tsx, board-chat.ts. Tests: BoardChat.test.tsx, board-chat-route-feature-flag.test.ts |
steering/drafts |
Task-keyed restored draft and attachment receipts; task switch/reload, failed send and uncertain-save recovery. | Retain correct task draft across navigation and reload; inspect authoritative saved receipt before claiming delivery; do not clear storage on every harness mount. | Source: TaskChatComposer.tsx, composer-draft.ts. Tests: TaskChatComposer.test.tsx, issue-queued-comments-routes.test.ts |
steering/approval-queue |
Answered question/accepted approval delivery waiting, eligible steer/interrupt, failed delivery and fresh-session-only approval. | Keep response delivery durable and distinct from editable comments; coalesce once, enforce fresh-session restrictions and deduplicate concurrent/retried continuation. | Source: TaskChatQueuedMessages.tsx, question-response-delivery.ts. Tests: TaskChatQueuedMessages.test.tsx, question-response-delivery.test.ts, issue-queued-comments-routes.test.ts |
documents-artifacts/documents |
Writable/read-only document, save pending/failure/conflict, revision history/historical preview and restore confirmation. | Persist edited body and reload; append-only restore creates new revision; reject stale writes and inaccessible company/task. | Source: IssueDocumentsSection.tsx, TaskDocumentPanel.tsx, documents.ts. Tests: IssueDocumentsSection.test.tsx, document-revisions.test.ts, documents-service.test.ts, issue-document-restore-routes.test.ts |
skills/testing |
Studio test inputs/configuration, running, question/approval, result and failed test states. | Run bounded test of actual saved version with correct selected account/environment; inspect persisted test detail and eligible interaction response. | Source: SkillStudio.tsx, companySkills.ts. Tests: SkillStudio.test.tsx, company-skill-test-runs-service.test.ts |
goals/alignment |
Project/task goal selection, explicit/inherited context and invalid association error. | Persist same-company valid association, reject invalid/cross-company reference, verify explicit versus inherited server context after reload. | Source: ProjectProperties.tsx, GoalDetail.tsx. Tests: project-goal-validation.test.ts, issues-goal-context-routes.test.ts, issue-goal-fallback.test.ts, project-goal.test.ts |
goals/navigation |
Parent/child goal and project/task context links, empty/unavailable context and permitted destination. | Follow actual goal/project/task records and compare explicit versus inherited context; ensure reload and inaccessible destination behavior. | Source: GoalDetail.tsx, GoalProperties.tsx. Tests: GoalDetail.test.tsx, issues-goal-context-routes.test.ts, issue-goal-fallback.test.ts |
workspaces/closure |
Close-readiness checks, pending changes/active runs, blocked/pending/error close, retry close and eligible reopening. | Confirm owned workspace shutdown, preserved files/Git state and permitted lifecycle transition/reopening; Browser Use session closure is unrelated. | Source: ExecutionWorkspaceDetail.tsx, ExecutionWorkspaceCloseDialog.tsx, execution-workspaces.ts. Tests: execution-workspaces-routes.test.ts, execution-workspaces-service.test.ts, execution-workspace-reopen.test.ts |
execution-environments/configuration |
Local/SSH/sandbox editors; unavailable providers, missing credentials, save pending/error and restricted operator. | Persist target configuration and enforce instance-admin/local-operator mutation boundary; target catalog is instance-scoped. | Source: CompanyEnvironments.tsx, environments.ts. Tests: CompanyEnvironments.test.tsx, environment-service.test.ts |
execution-environments/capabilities |
Supported versus unavailable driver/provider controls and interactive-setup/template-capture limitations. | Verify advertised driver/plugin capabilities match operations; unavailable provider cannot become working target; capability discovery must not allocate sandbox. | Source: CompanyEnvironments.tsx, environments.ts. Tests: environment-capability-contract.test.ts, environment-execution-target-capabilities.test.ts, plugin-environment-driver-sandbox-capabilities.test.ts |
execution-environments/probe |
Remote Test pending, success, reachability/auth failure and platform qualification absent/invalidated notice. | Probe actual owned target; verify selected saved immutable config/image/company qualification plus lease cleanup; local API probe proves host/cwd only and has no UI Test button. | Source: CompanyEnvironments.tsx, environment-probe.ts. Tests: CompanyEnvironments.test.tsx, environment-probe.test.ts, environment-live-ssh.test.ts |
execution-environments/images |
Custom-image setup/capture/progress, terminal connect/disconnect/failure, unsupported capability and active-image drift. | Execute owned provider setup/capture/probe/terminal transport with correct saved image identity, authority, cleanup and shutdown; terminal screenshot cannot prove operation. | Source: CompanyEnvironments.tsx, environment-custom-images.ts. Tests: CompanyEnvironments.test.tsx, environment-custom-images-service.test.ts |
recovery/exhaustion |
Exhausted/overdue attempts, operator retry pending/error, blocked authority/gate and specific escalation. | Inspect durable attempt bounds and actual eligible retry/repair; acknowledgment alone does not prove continued execution. | Source: IssueRecoveryActionCard.tsx, DispositionRecoveryNotice.tsx, issue-recovery-actions.ts. Tests: IssueRecoveryActionCard.test.tsx, DispositionRecoveryNotice.test.tsx, issue-recovery-actions.test.ts, recovery.spec.ts |
recovery/unknown-outcome |
Uncertain external outcome, required inspection/evidence and explicit permitted operator decision. | Corroborate provider outcome before authorization; enforce no automatic external side-effect replay and reject stale/unauthorized decisions. | Source: IssueRecoveryActionCard.tsx, issue-recovery-actions.ts. Tests: IssueRecoveryActionCard.test.tsx, issue-recovery-actions.test.ts, recovery.spec.ts |
recovery/user-continuation |
Saved follow-up waiting on stop cleanup, pause/budget gate, one eligible continuation and result/failure. | Confirm previous execution stopped before delivery, preserve message, avoid duplicate wakes and honor actual task/ancestor/budget gate in separate legacy/native paths. | Source: TaskChatQueuedMessages.tsx, legacy-continuation.ts, native-restart-recovery.ts. Tests: legacy-continuation.test.ts, native-restart-recovery.test.ts, issue-queued-comments-routes.test.ts, legacy-failure-continuation.spec.ts |
app-permissions/catalog-change |
Mount PermissionsPanel/AppDetail with quarantined actions, selection/review, refresh pending, empty and failed discovery states. Existing auto-allowed NewToolsAllowed examples are not quarantine review. | Exercise catalog refresh and new-tool review with permitted/denied actors; unreviewed actions stay quarantined, prior Off/Ask choices survive refresh, and approved review persists. | Source: PermissionsPanel.tsx, AppDetail.tsx, tool-access.ts. Tests: AppDetail.test.tsx, tool-access-service.test.ts, tool-access-policy-service.test.ts |
chat-channels/attachments |
Mount TaskChatBubble attachments and ChatEndpointDetail provider-specific consent/upload/delivery failure and unknown-outcome states. Local email attachment dialog remains a prototype. | Transfer a disposable supported file through each affected provider; verify recipient delivery, read scope, duplicate/replay handling and failure/unknown state without treating notification as file-upload proof. | Source: TaskChatBubble.tsx, ChatEndpointDetail.tsx, chatEndpoints.ts, chat-channels.ts. Tests: TaskChatBubble.test.tsx, task-chat-attachments.test.ts, chat-channels.integration.test.ts, issue-attachment-routes.test.ts |
gateways-profiles/tokens |
Mount current TokensPanel with issue controls, once-only token reveal, expiry/actions, revocation confirmation and failures. Old GatewaysTab fixtures and assistant OAuth revocation are insufficient. | Issue bounded token via POST /tool-gateway/gateways/{id}/tokens; call allowed and excluded tools; revoke via /tool-gateway/gateway-tokens/{id}/revoke and verify denial using same client. | Source: TokensPanel.tsx, tool-gateway.ts, tools.ts. Tests: TokensPanel.test.tsx, tool-gateway-service.test.ts, tool-gateway.test.ts |
secrets/proposals |
Mount ProposalsTab pending secret/binding proposals, blocked authority, expired/resolved proposal, approval/rejection pending/error, and redacted metadata. | GET /companies/{id}/secret-proposals and POST approve/reject must enforce company/admin/target authority, durable resolution and redaction; verified run-bound agent proposal creation is separate. | Source: ProposalsTab.tsx, secrets.ts, secret-proposal-authorization.ts. Tests: ProposalsTab.render.test.tsx, secret-proposals-routes.test.ts |
plugins/installation |
Mount PluginManager trusted package and bundled-local choices, pending install, validation/recoverable error and installed status. | POST /plugins/install on a disposable package; enforce instance install authority, trusted path/package validation and correct version. Package and local install are distinct. | Source: PluginManager.tsx, plugins.ts, plugin-install-guard.ts. Tests: plugin-install-route-security.test.ts, plugin-install-autobuild.test.ts, plugin-routes-authz.test.ts |
plugins/configuration |
Mount PluginSettings valid/invalid schema inputs, saved configuration, pending/failure and unavailable plugin. | GET/POST /plugins/{id}/config and POST config/test must preserve validation/company scope and deliver saved config to real plugin worker/startup. | Source: PluginSettings.tsx, plugins.ts, plugin-config-validator.ts. Tests: PluginSettings.test.tsx, plugin-config-startup-delivery.test.ts, plugin-routes-authz.test.ts |
plugins/contributions |
Mount PluginPage and CompanySettingsPluginPage contributed routes/tabs, loading, missing/unavailable plugin and action failures with a known fixture plugin. | Serve real static plugin UI; enforce bridge data/action host capabilities and company boundaries; exercise a harmless action and cold deep link. | Source: PluginPage.tsx, CompanySettingsPluginPage.tsx, plugins.ts, plugin-ui-static.ts. Tests: PluginPage.test.tsx, CompanySettingsPluginPage.test.tsx, plugin-ui-static.test.ts, plugin-tenant-isolation.test.ts |
plugins/lifecycle |
Mount PluginManager active/disabled/uninstall/upgrade pending and failures; distinguish operator controls from developer watcher reload. | POST enable/disable and DELETE /plugins/{id} must stop worker/tool/managed-resource activity and clean owned resources; verify disposable restart/uninstall and developer watcher separately. | Source: PluginManager.tsx, plugins.ts, plugin-lifecycle.ts, plugin-dev-watcher.ts. Tests: plugin-lifecycle-restart.test.ts, plugin-routes-authz.test.ts, plugin-dev-watcher.test.ts |
routines/run-now |
Mount RoutineRunVariablesDialog through actual RoutineDetail with required/default inputs, project/workspace overrides, pending, blocked and failed submission. RunButton-only no-op examples do not supply/run inputs. | POST /routines/{id}/run must validate variables, create one attributed execution/task and obey pause/access/budget gates; inspect actual task outcome separately. | Source: RoutineRunVariablesDialog.tsx, RoutineDetail.tsx, routines.ts. Tests: RoutineRunVariablesDialog.test.tsx, routines-service.test.ts, routines-e2e.test.ts |
pipelines/stages |
Mount PipelineSettings ordered stages, automation assignees/env, invalid transitions, unsaved state, saving and failed save. | POST/PATCH stages and PUT /pipelines/{id}/transitions must persist valid order/configuration, enforce ownership and reject invalid transitions; actual automation execution remains separate. | Source: PipelineSettings.tsx, pipelines.ts. Tests: PipelineSettings.test.ts, pipelines-service.test.ts, pipelines-routes.test.ts |
pipelines/items |
Mount Pipelines/PipelineItemDetailView board grouping, item creation/details, stage/health/work references, empty/loading and failed transition. | GET/POST /pipelines/{id}/cases and POST /cases/{id}/transition must maintain company scope, valid stage changes and linked work; fixture stage state does not prove automation. | Source: Pipelines.tsx, PipelineWorkReferences.tsx, pipelines.ts. Tests: Pipelines.test.tsx, pipelines-service.test.ts, pipelines-routes.test.ts, pipelines-tutorial-flow.spec.ts |
pipelines/review |
Mount ReviewQueue and item review pending output/revision, accept/reject/request-changes, bulk selection, stale/conflicting submission and errors. | POST /cases/{id}/review and /companies/{id}/review-cases/bulk must authorize reviewer, persist correct outcome/transition and reject stale or invalid input. | Source: Pipelines.tsx, pipelines.ts. Tests: Pipelines.test.tsx, pipelines-routes.test.ts, pipelines-service.test.ts, pipelines-tutorial-flow.spec.ts |
pipelines/learnings |
Mount actual Learnings export with filtered case events, review/forced-move entries, source links, empty/loading/error. This is event history, not a separately authored learning-record system. | GET /companies/{id}/case-events in pipelines routes needs existing company/access contract tests; a rendered event cannot establish learning quality. | Source: Pipelines.tsx, pipeline-learnings.ts, pipelines.ts. Tests: Pipelines.test.tsx, pipelines-routes.test.ts, pipelines-service.test.ts |
cases/browse |
Mount Cases search/filter/sort/group/tree, matched-child parent context, persisted view choices, keyboard navigation and empty/loading/error. | GET /companies/{id}/cases scope/filter behavior is production evidence; rendered fixtures establish presentation only. Mutation/permission scenarios need real API checks separately. | Source: Cases.tsx, cases.ts. Tests: Cases.test.tsx, cases-routes.test.ts |
cases/structure |
Mount CaseDetail and CaseFieldsPanel with arbitrary JSON fields and parent/children, matching descendants and unavailable child. Do not invent a general field editor or typed field validation. | GET /cases/{id} and /cases/{id}/children/tree must return permitted company records and correct relationships; changes/persistence require route tests separately. | Source: CaseDetail.tsx, CaseFieldsPanel.tsx, Cases.tsx, cases.ts, pipelines.ts. Tests: CaseFieldsPanel.test.tsx, Cases.test.tsx, CaseDetail.test.tsx, cases-routes.test.ts |
cases/history |
Mount CaseDetail activity and document revisions as distinct views, empty/loading/errors, attribution and source links. | GET /cases/{id}/events and /cases/{id}/documents/{key}/revisions require company/access filtering; a fixture list does not establish durable revision creation or restoration. | Source: CaseDetail.tsx, cases.ts. Tests: CaseDetail.test.tsx, cases-routes.test.ts |
cases/task-links |
Mount CaseDetail and IssueCasesPanel related-task/case links in both directions, missing links and unavailable targets. | GET /issues/{id}/cases and /cases/{id}/issue-links must enforce permitted task/case relationships; production browser cold links verify destination and company context. | Source: CaseDetail.tsx, IssueCasesPanel.tsx, cases.ts, pipelines.ts. Tests: IssueCasesPanel.test.tsx, CaseDetail.test.tsx, cases-routes.test.ts |
status-cards/authoring |
Mount CreateStatusCardDialog and StatusCardSettingsForm prompt, summarizer, refresh options, required/invalid inputs and save errors. | POST /companies/{id}/status-cards and PATCH /status-cards/{id} must enforce gate/author authority, save configuration and start expected compile task when prompt changes. | Source: CreateStatusCardDialog.tsx, StatusCardSettingsForm.tsx, status-cards.ts. Tests: StatusCardSettingsForm.test.tsx, status-cards.test.ts |
status-cards/generation |
Mount card tile/drawer compiling, refreshing, failed, stale existing summary and successful new-summary states with linked task. | POST /status-cards/{id}/recompile and /refresh plus update/finalization engine must persist actual new output/history; compare saved summary with source tasks, not merely successful task status. | Source: StatusCardTile.tsx, StatusCardDetailDrawer.tsx, status-cards.ts, status-card-update-engine.ts. Tests: StatusCardTile.test.tsx, status-cards.test.ts, status-card-update-engine.test.ts |
status-cards/inspection |
Mount StatusCardDetailDrawer summary, watched work, update/revision history, query debug, empty/loading/error and stale summary disclosure. | GET /status-cards/{id}, /updates, /summary-revisions and /dry-run must filter accessible card/source records; fixtures cannot establish summary truth or query authorization. | Source: StatusCardDetailDrawer.tsx, status-cards.ts. Tests: StatusCardTile.test.tsx, status-cards.test.ts |
status-cards/archive |
Mount StatusCards and ArchivedStatusCardRow active/archived list, restore pending/failure and old-summary state. Archive differs from deletion. | PATCH /status-cards/{id} archived true/false must persist and authorize change; restore may enqueue refresh, whose new outcome must be inspected rather than treating old summary as current. | Source: index.tsx, ArchivedStatusCardRow.tsx, status-cards.ts. Tests: status-cards.test.ts, status-card-update-engine.test.ts |
budgets-costs/resolution |
Mount BudgetIncidentCard with entered raised limit, invalid limit, keep-paused, applying, authorized/blocked and error states wired through actual host. Existing matrix handlers are no-ops. | POST /companies/{id}/budget-incidents/{id}/resolve must authorize scope-specific raise, persist resolution and resume eligible work while retaining overlapping budget/manual holds. | Source: BudgetIncidentCard.tsx, Costs.tsx, budgets.ts, costs.ts, budgets.ts. Tests: budgets-service.test.ts, Costs.test.tsx |
activity/runs |
Mount AuditRuns selected status/agent/routine, linked task/agent, empty/loading/error/retry and 200-entry limit. Do not invent pagination. | GET /companies/{id}/heartbeat-runs and /routines/{id}/runs require company/read/privacy checks; real browser follows context links and confirms the referenced execution. | Source: AuditRuns.tsx, heartbeats.ts, routines.ts. Tests: AuditRuns.test.tsx, heartbeat-run-privacy-routes.test.ts, routines-service.test.ts |
navigation-preferences/preferences |
Mount Sidebar using real preference boundary with stars/order/collapse/recents state. Clearly distinguish in-memory section collapse, browser-local recents and server-saved stars/order. | GET/PUT /sidebar-preferences/me and /companies/{id}/sidebar-preferences/me plus stars must retain intended user/company isolation across reload and switch. Section collapse reopens after reload; global collapse is disabled. | Source: Sidebar.tsx, sidebar-preferences.ts, sidebar-preferences.ts. Tests: Sidebar.test.tsx, sidebar-preferences-routes.test.ts |
instance-operations/backup |
Mount shipped InstanceGeneralSettings in CompanySettings with daily/weekly/monthly retention presets, selected values, saving/error/loading and cloud-hidden controls. Backup creation and restore remain separate CLI/operator checks. | PATCH /api/instance/settings/general must enforce instance settings authority and managed hidden fields, persist retention and survive reload. Separately inspect a real backup and restore a known record into a second disposable target; a successful write does not prove restoration. | Source: InstanceGeneralSettings.tsx, CompanySettings.tsx, instance-settings.ts, db-backup.ts. Tests: InstanceGeneralSettings.test.tsx, instance-settings-routes.test.ts, instance-settings-managed-overlay.test.ts, instance-database-backups-routes.test.ts |
CLI and operator capabilities
These eight capabilities do not need an authored Storybook example for their core operation. Keep them in the feature index: their lack of a story is intentional verification scope, not evidence that the product lacks the feature. UI portions of related capabilities remain in the section above.
| Capability | Storybook scope | Required CLI/API/operator evidence | Source and existing test starting points |
|---|---|---|---|
onboarding/instance |
No authored UI story required for host installation and startup. | Configure isolated data directory, start instance, confirm printed URL/identity/health, restart with saved configuration. | Source: onboard.ts, onboard-service.ts. Tests: onboard.test.ts, onboard-service.test.ts, test-drive.test.ts |
instance-operations/install-update |
No authored story required for install, channel selection, update or rollback command execution. | Use an owned managed installation: check/dry-run, installed version, retained payload rollback and failure. Source-checkout guidance is a separate case; rollback does not undo database migrations. | Source: index.ts, install.ts, update.ts. Tests: install-command.test.ts, update-command.test.ts |
instance-operations/diagnostics |
No authored story required for doctor/health command results. | Run doctor against an owned data directory; check readiness and nonzero failures. A listening port alone does not prove readiness; repair requires observing the repaired result. | Source: doctor.ts. Tests: doctor.test.ts |
cli-operations/context |
No authored story required for CLI profile/context selection. | Verify selected API origin, identity and company, JSON output and invalid-token/wrong-company failures. A persona label is not authentication. | Source: context.ts. Tests: context.test.ts, http.test.ts |
cli-operations/domain-commands |
No authored story required for command parsing and domain API execution; corresponding product UI keeps its own story needs. | Discover registered help, use a disposable company, assert persisted mutations and denied operations with the actual actor. Command parity is not every endpoint passing live. | Source: index.ts, issue.ts. Tests: operations-parity.test.ts |
cli-operations/outputs |
No authored story required for CLI document/asset/skill IO or machine-readable output. | Assert payload/schema, exit code, written contents, authorization and file integrity. Open the resulting document/asset in the product for cross-surface acceptance. | Source: issue.ts, asset.ts, skill.ts. Tests: issue-subresources.test.ts, admin-asset-skill-parity.test.ts |
cli-operations/run-controls |
No authored story required for invoke/list/get/cancel/events/log command execution. | Assert the real run ID, event/log output and resulting state, eligible actor and cancellation denial. Printed success does not prove provider completion. | Source: run.ts, heartbeat-run.ts. Tests: operations-parity.test.ts |
cli-operations/worktree-instances |
No authored story required for worktree initialize/seed/repair/cleanup commands. | Use only an owned isolated checkout/instance; verify paths, ports, health, login and seed provenance, then cleanup ownership. Capture evidence before teardown. | Source: worktree.ts, test-drive.ts. Tests: worktree.test.ts, test-drive.test.ts |
Browser verification boundaries
These three capabilities principally require the real browser, router or measurement harness. An isolated story can provide visual context, but does not prove routing, runtime gates or a performance budget. Navigation fallback presentation remains eligible for a small optional story.
| Capability | Storybook scope | Required browser evidence | Source and existing test starting points |
|---|---|---|---|
navigation-preferences/fallbacks |
A NotFound rendering story can help polish, but missing-resource/legacy-deep-link capability principally needs real App/router/browser scenarios preserving company and query intent. | Cold-open invalid company/resource and retired URL; verify explicit fallback or correct canonical redirect without silently targeting a different resource/company. | Source: NotFound.tsx, App.tsx, company-routes.ts. Tests: App.activity-routing.test.tsx, App.cases-routing.test.tsx, App.test.tsx, company-routes.test.ts |
developer-labs/performance |
A screenshot/story is optional context, not the required performance evidence. | Use existing browser performance harnesses. Record build/browser/data size, timing/trace and scrolling. Long-thread fixture has a disabled composer; task-chat HTML harness uses a plain textarea and simulated updates. | Source: IssueChatLongThreadPerf.tsx, README.md, README.md. Tests: scrollback.spec.ts, issue-detail.perf.spec.ts |
developer-labs/route-gates |
No isolated story required to prove actual route registration, redirects or gates; isolated gated-control examples remain useful. | Drive real routes under their actual development, experimental, production and fallback settings. Do not assume every lab is dev-only: global long-thread/lab/design routes also exist in production registration. | Source: App.tsx. Tests: No dedicated test asserted; use the feature recipe. |
Association revisit and retained gaps
No further justified associations were found in this revisit of the 60 gaps. Existing lookalikes remain unlinked for concrete reasons:
inbox-search/toasts:DismissUndoToastis a dismissal receipt;StopWithoutToastsis local visible-task suppression. Neither demonstrates persisted personal participation/mention eligibility. The upstream notification capability is newly mapped by #16153, not an overlooked notification suite.gateways-profiles/tokens: assistant OAuth revocation is a different credential. Existing Gateway-tab token fixtures omit current fields such asallowedActions; inspect and repair their drift before advertising token coverage.app-permissions/catalog-change: automatically allowing new actions with an empty quarantine does not demonstrate review/quarantine.documents-artifacts/documents: the annotation edit mock increments a revision while returning unchanged body; it does not demonstrate saved edits or restoration.steering/drafts: mounting after clearing and seeding storage does not demonstrate draft recovery across task switching or reload.routines/run-nowandbudgets-costs/resolution: supplied dialogs/cards and no-op callbacks are useful presentation references, but do not yet provide the action/result scenarios for these capability links.
These are retained examples and explicit limits, not reasons to delete suites. The prior association corrections remain intact. No suite classifications are promoted by this inventory.
Keeping this record current
This downstream record is maintained with maintain-storybook. When a feature is added or an example is associated, recompute the unassociated IDs from the feature map and non-guide catalog entries; update the rows/counts and source revision. Preserve the CLI/operator and browser reasons while no story exists. A new story removes a capability from this gap inventory only when its actual subject/actions justify the catalog association; it does not remove the production verification obligation.
Use the feature recipes and agent access companions for authoritative journeys, actor restrictions and allowed/denied assertions. This record does not create a new API schema, alter access policy or redefine those maps. Record executed evidence separately in REVIEW.md.
For this pass, regenerate the downstream feature index for inbox-search/toasts and inspect its diff. The five inbox-suite fingerprints changed only through the inspected upstream recipe; the guide/shared fingerprints also follow the regenerated index and upstream README. Those inventory refreshes retain story IDs and unreviewed statuses.