From 994aa9199c10482494046feb591c79aab5ea5e49 Mon Sep 17 00:00:00 2001 From: AstroHan Date: Sat, 29 Aug 2026 01:19:28 +0800 Subject: [PATCH] docs(desktop): record the workbar stories entry #4101 gave Storybook its own `features/workbar/stories` entry and moved `WorkbarSurface` there, but the feature README still said stories share `testing`. Name all three entries and why the split exists, so the next reader does not re-derive it from `workbar-boundary.test.ts`. --- apps/desktop/src/renderer/features/workbar/README.md | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/apps/desktop/src/renderer/features/workbar/README.md b/apps/desktop/src/renderer/features/workbar/README.md index 5fcd47db11..e8c6754ca2 100644 --- a/apps/desktop/src/renderer/features/workbar/README.md +++ b/apps/desktop/src/renderer/features/workbar/README.md @@ -27,7 +27,12 @@ remounted when the active session changes. ## Dependency direction - Consumers import production APIs from `features/workbar`. -- Tests and stories may additionally import `features/workbar/testing`. +- Node test suites may additionally import `features/workbar/testing`. +- Storybook may additionally import `features/workbar/stories`, which exposes + `WorkbarSurface`. It stays out of the production entry because `workbar-host` + reaches the surface through `lazy()`, and out of `testing` because that entry + is loaded by `node --test` against tsc output while the surface and its tool + panels use extensionless relative specifiers only a bundler resolves. - Workbar may use shared renderer primitives, core types and Maka UI. - Workbar must not import shell composition, Desktop bridge, or main-process implementation. - Desktop I/O enters through `WorkbarServices`; tool code does not read