@boopkit/cap-web 0.4.1 → 0.5.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@boopkit/cap-web",
-  "version": "0.4.1",
+  "version": "0.5.0",
   "description": "Express view engine configuration, Handlebars helpers, and static asset middleware",
   "main": "dist/index.js",
   "types": "dist/index.d.ts",

package/skills/boop-web-web-ui-design/SKILL.md

@@ -193,3 +193,18 @@ See also:
 - [development.skill.md](development.skill.md) for Spartan Code Philosophy
 - [../reference/web-development.ref.md](../reference/web-development.ref.md) for current implementation examples
 - [../reference/boop-guide.ref.md](../reference/boop-guide.ref.md) for CSS extension model (`@theme` tokens, package styles, cascade overrides)
+
+## Visually verify before declaring done
+
+When your work changes a rendered surface — views, CSS, controllers that produce view-models, layout primitives — visually verify before declaring done. The structural tests assert that the view-model has the right fields and that the markup renders; they do not catch layout regressions. A change can pass every test and still ship with a stale CSS bundle, a label and value stacked where they should sit inline, or a column collapsed at a narrow width. The only thing that catches that is looking at the rendered page.
+
+The flow:
+
+1. **Build the CSS bundle.** `npm run tailwind:build` (or the project's equivalent). Semantic classes compiled via `@apply` do not exist in the served bundle until it is rebuilt.
+2. **Restart the dev server if it caches the bundle at boot.** Many dev servers read the compiled CSS once at startup and a file watcher that ignores CSS will not pick up the rebuild.
+3. **Capture the affected page** at desktop (1280px) and mobile (390px) widths via a headless capture tool — for example the `scripts/ux-eval-capture.ts` script `cap-ux` ships, or the project's equivalent.
+4. **Read the captures.** Confirm the new fields appear, the layout reads coherently, and nothing collapsed or stacked in a way the structural tests cannot see.
+
+If the capture surfaces a layout issue, fix it before closing the issue, even if all unit tests pass. A green test suite is not evidence that the surface looks right; only the capture is.
+
+This is the UI-specific instance of a general discipline: before declaring done, exercise the part of the change that the unit tests structurally cannot see. Other domains carry their own equivalent — a migration verifies row counts against a backed-up copy of the seed DB; a service confirms the domain boundary is honest. Here, the unseen part is what the page looks like.