Pine/deepseek-harness
1
0
Fork 0
Code Issues Pull Requests Actions 1 Packages Projects Releases 1 Wiki Activity

docs: record the plugin-bundle rebuild trap in the scrollbar note

Browse Source 
Verifying browser-visible plugin CSS needs a rebuild build:web does not
perform: WorkspaceBrowser.module.css never reaches apps/web/dist, because
ui-workspace loads as a runtime plugin with its CSS inlined into
lib/client.js by that package's own bundle script. A negative control that
reruns only build:web exercises a stale bundle and passes with the
declaration removed, which reads as a vacuous test rather than an invalid
control. No script in the web lane does this rebuild, so every scroll-region
or plugin-CSS change hits the same trap.
This commit is contained in:
Chinesezjc
2026-07-28 12:09:18 +08:00
parent a031967181
commit 474b88e362
3 changed files with 6 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.agents/notes/implemented/bug-fix/2026-07-28-themed-scrollbars-and-reserved-gutter.md
+2
View File
@@ -55,3 +55,5 @@ Three unit specs read the CSS text on disk. `ui-theme/tests/scrollbar-styles.spe
Confirmed in headless chromium on the built client by reading computed values, which is what distinguishes a working token chain from a syntactically valid one: a scroll container computes the l1 thumb color in each palette, and a container that rebinds the indirection computes the l2 color, proving the rebind reaches the computed value rather than only the custom property.
Headless chromium draws overlay scrollbars, so a reserved gutter there does not shrink `clientWidth`. The reservation shows up as a non-zero `offsetWidth - clientWidth` band on the list; client-area geometry alone does not demonstrate it, and an assertion comparing the time element's right edge against the client-area edge holds with and without the reservation, so it would pass or fail on the platform's scrollbar style rather than on the declaration under test.
Verifying browser-visible plugin CSS needs a rebuild `pnpm run build:web` does not perform. `WorkspaceBrowser.module.css` never reaches `apps/web/dist`: ui-workspace loads as a runtime plugin and its CSS is inlined into `packages/client/ui-workspace/lib/client.js`, built by that package's own `bundle` script. A negative control that reruns only `build:web` therefore exercises a stale bundle and passes with the declaration removed, which reads as a vacuous test rather than as an invalid control. Rebuild with `pnpm --filter @deepseek-ai/dsh-client-ui-workspace run bundle`, confirm the artifact by grepping `lib/client.js` for the declaration, then `build:web`. No script in the web lane does this: `test:web` runs `build:web` alone, so every scroll-region or plugin-CSS change hits the same trap.