@invisibleloop/pulse 0.20.10 → 0.20.19

package/src/ui/ui.test.js

@@ -31,11 +31,9 @@ import { stack }       from './stack.js'
 import { cluster }     from './cluster.js'
 import { divider }     from './divider.js'
 import { media }       from './media.js'
-import { fieldset }    from './fieldset.js'
 import { slider }     from './slider.js'
 import { toggle }     from './switch.js'
 import { radio, radioGroup } from './radio.js'
-import { segmented }  from './segmented.js'
 import { fileUpload } from './fileupload.js'
 import { modal, modalTrigger } from './modal.js'
 import { uiImage }             from './uiimage.js'
@@ -806,40 +804,6 @@ test('media: gap lg adds modifier class', () => {
   assert.match(media({ image: '', content: '', gap: 'lg' }), /ui-media--gap-lg/)
 })
 
-// ---------------------------------------------------------------------------
-// fieldset
-// ---------------------------------------------------------------------------
-
-test('fieldset: renders fieldset element', () => {
-  assert.match(fieldset({ legend: 'Address', content: '<p>fields</p>' }), /<fieldset/)
-})
-
-test('fieldset: renders legend', () => {
-  assert.match(fieldset({ legend: 'Billing', content: '' }), /ui-fieldset-legend/)
-  assert.match(fieldset({ legend: 'Billing', content: '' }), /Billing/)
-})
-
-test('fieldset: no legend element when omitted', () => {
-  assert.doesNotMatch(fieldset({ content: 'fields' }), /ui-fieldset-legend/)
-})
-
-test('fieldset: renders content in body', () => {
-  assert.match(fieldset({ content: '<input>' }), /ui-fieldset-body/)
-  assert.match(fieldset({ content: '<input>' }), /<input>/)
-})
-
-test('fieldset: gap lg adds modifier class', () => {
-  assert.match(fieldset({ gap: 'lg', content: '' }), /ui-fieldset--gap-lg/)
-})
-
-test('fieldset: no gap modifier for default md', () => {
-  assert.doesNotMatch(fieldset({ content: '' }), /ui-fieldset--gap/)
-})
-
-test('fieldset: escapes legend to prevent XSS', () => {
-  assert.match(fieldset({ legend: '<script>bad</script>', content: '' }), /&lt;script&gt;/)
-})
-
 // ─── slider ──────────────────────────────────────────────────────────────────
 
 test('slider: renders range input with label', () => {
@@ -989,45 +953,6 @@ test('radioGroup: error renders role=alert', () => {
   assert.match(html, /Pick one/)
 })
 
-// ─── segmented ───────────────────────────────────────────────────────────────
-
-test('segmented: renders radio inputs for each option', () => {
-  const html = segmented({ name: 'tab', options: [{ value: 'a', label: 'A' }, { value: 'b', label: 'B' }] })
-  const inputs = [...html.matchAll(/type="radio"/g)]
-  assert.equal(inputs.length, 2)
-  assert.match(html, /name="tab"/)
-})
-
-test('segmented: marks selected value as checked', () => {
-  const html = segmented({ name: 'x', options: [{ value: 'a', label: 'A' }, { value: 'b', label: 'B' }], value: 'b' })
-  assert.match(html, /value="b"[\s\S]*?checked/)
-})
-
-test('segmented: event prop renders data-event on all inputs', () => {
-  const html = segmented({ name: 'x', options: [{ value: 'a', label: 'A' }, { value: 'b', label: 'B' }], event: 'change:setTab' })
-  const matches = [...html.matchAll(/data-event="change:setTab"/g)]
-  assert.equal(matches.length, 2)
-})
-
-test('segmented: no data-event when event not provided', () => {
-  const html = segmented({ name: 'x', options: [{ value: 'a', label: 'A' }] })
-  assert.doesNotMatch(html, /data-event/)
-})
-
-test('segmented: size sm adds modifier class', () => {
-  assert.match(segmented({ name: 'x', options: [], size: 'sm' }), /ui-segmented--sm/)
-})
-
-test('segmented: size lg adds modifier class', () => {
-  assert.match(segmented({ name: 'x', options: [], size: 'lg' }), /ui-segmented--lg/)
-})
-
-test('segmented: disabled applies to all inputs', () => {
-  const html = segmented({ name: 'x', options: [{ value: 'a', label: 'A' }, { value: 'b', label: 'B' }], disabled: true })
-  const matches = [...html.matchAll(/disabled/g)]
-  assert.ok(matches.length >= 2)
-})
-
 // ─── fileUpload ───────────────────────────────────────────────────────────────
 
 test('fileUpload: renders file input with correct name', () => {

package/types/ui.d.ts

@@ -277,14 +277,6 @@ export interface ModalTriggerProps {
 }
 export function modalTrigger(props?: ModalTriggerProps): string
 
-export interface TooltipProps {
-  content?: string
-  trigger?: string
-  position?: 'top' | 'bottom' | 'left' | 'right'
-  class?:   string
-}
-export function tooltip(props?: TooltipProps): string
-
 // ---------------------------------------------------------------------------
 // Data display
 // ---------------------------------------------------------------------------
@@ -407,19 +399,6 @@ export interface SliderProps {
 }
 export function slider(props?: SliderProps): string
 
-export interface SegmentedOption {
-  label: string
-  value: string
-}
-export interface SegmentedProps {
-  name?:    string
-  options?: Array<string | SegmentedOption>
-  value?:   string
-  event?:   string
-  class?:   string
-}
-export function segmented(props?: SegmentedProps): string
-
 export interface RadioOption {
   label: string
   value: string

package/.claude/commands/build-page.md

@@ -1,63 +0,0 @@
-# Build Page
-
-Scaffold a new Pulse page spec, validate it, and visually confirm it renders correctly.
-
-## What to build
-
-$ARGUMENTS
-
-## Steps — follow in order
-
-### 1. Check existing components
-
-Read `src/ui/index.js` to see what UI components are available before writing any HTML. Note which components apply to this page.
-
-### 2. Plan
-
-State before writing any files:
-- The route (e.g. `/dashboard`)
-- The file path (e.g. `src/pages/dashboard.js`)
-- State shape
-- Mutations and/or actions needed
-- Which UI components will be used
-- Whether `server` data fetchers are needed
-- Whether `hydrate` is required (yes, if any mutations/actions)
-
-### 3. Build the spec
-
-Write the spec file. Follow these rules:
-- Use `class` not `className`, template literals not JSX
-- No React imports, hooks, or patterns — see CLAUDE.md "Pulse vs React" table
-- Use components from `src/ui/` — do not hand-write HTML that a component already covers
-- Include `hydrate` if the spec has mutations or actions
-- Use optional chaining (`?.`) on any server data that could be null
-- Escape any user-supplied values interpolated into HTML
-
-### 4. Validate
-
-Use `pulse_validate` on the spec. Fix any errors before continuing.
-
-### 5. Register with the server
-
-Check the project's server entry file (e.g. `src/server.js` or `pulse.config.js`) and add the new spec if needed.
-
-### 6. Screenshot and design approval
-
-Use `mcp__chrome-devtools__navigate_page` to load the page, then `mcp__chrome-devtools__take_screenshot`.
-
-Check for:
-- Page renders without a blank screen or error
-- Layout looks correct
-- No console errors via `mcp__chrome-devtools__list_console_messages`
-
-Then **call `pulse_await_approval`** and ask the user: "Happy with the design and layout, or would you like any changes before I run tests and Lighthouse?" — if your host provides a question tool (e.g. AskUserQuestion), offer the choices `["Yes, looks good — run tests and Lighthouse", "I'd like some changes first"]`; otherwise ask in plain prose. Always call the tool before asking, whichever way you ask: in some hosts (including Claude Code) even a question tool ends the turn and fires the Stop hooks; the marker is harmless if the turn doesn't end. If a `VERIFY REQUIRED` stop-hook block fires while your question is unanswered, that is not permission to continue — call `pulse_await_approval`, re-ask, and end your turn.
-
-**Do not proceed to step 7 until the user explicitly confirms.** If they want changes, make them and return to step 6.
-
-### 7. Run the checklist
-
-Go through `src/agent/checklist.md` and confirm every applicable point passes. Fix anything that fails.
-
-### 8. Report
-
-Summarise what was built, what components were used, and confirm validation + visual check passed.

package/.claude/commands/new-doc-page.md

@@ -1,45 +0,0 @@
-# New Docs Page
-
-Create a new documentation page for the Pulse docs site.
-
-## What to build
-
-$ARGUMENTS
-
-## Steps — follow in order
-
-### 1. Research
-- Read `docs/src/lib/nav.js` to understand the full nav structure and find where the new page fits
-- Read 2–3 adjacent pages (the pages that will be `prev`/`next` neighbours) to match tone, section depth, and helper usage (`h1`, `lead`, `section`, `sub`, `codeBlock`, `callout`, `table`)
-- Read `docs/src/lib/layout.js` exported functions to confirm available helpers
-- If the feature being documented has a source file (e.g. in `src/`), read it to ensure accuracy
-
-### 2. Plan
-Before writing any files, state:
-- The route (e.g. `/request-bodies`)
-- Where it sits in the nav (section, between which two pages)
-- Sections the page will cover (IDs + titles)
-- Any doc pages that need updating to link to or mention this page
-
-Wait for approval if anything is uncertain.
-
-### 3. Implement
-
-**a) Write the page file** at `docs/src/pages/<name>.js`:
-- Import from `../lib/layout.js`, `../lib/nav.js`, `../lib/highlight.js`
-- Use `prevNext('/your-route')` for prev/next links
-- Export a valid Pulse spec as `export default { route, meta, state, view }`
-- `meta.styles` must be `['/docs.css']`
-- Use `renderLayout({ currentHref, prev, next, content })` for the page body
-- All code examples must use `${codeBlock(highlight(\`...\`, 'js'))}` — never raw `<pre>`
-- Tables use `${table(['Col1', 'Col2'], [['val', 'val']])}`
-- Callouts use `${callout('note|tip|warning|info', 'text')}`
-- Section anchors use `${section('anchor-id', 'Section Title')}`
-
-**b) Register in nav** — add the entry to `docs/src/lib/nav.js` in the correct position
-
-**c) Verify syntax** — run `node --check docs/src/pages/<name>.js`
-
-**d) Check neighbours** — read the prev and next pages. If they reference topics this new page covers, add a cross-link.
-
-**e) Final check** — confirm the new route appears in `prevNext` output for its neighbours (the nav order drives prev/next automatically, so adding to NAV is sufficient).

package/.claude/commands/pulse-start.md

@@ -1,11 +0,0 @@
-Start the Pulse production server for this project — **locally, on the production port (dev port + 1, normally 3001)** so it can run alongside the dev server on 3000.
-
-First ensure a build exists (`public/dist/` — run `pulse build` if not). Then:
-
-```bash
-pulse start --port 3001
-```
-
-If `pulse.config.js` sets a custom `port`, use that value + 1 instead.
-
-> **Why the flag:** plain `pulse start` binds the configured port (3000) because in real deployment it is the only server and platforms inject `PORT`. Locally that collides with the dev server and breaks the convention used by `pulse_build`, Lighthouse, and the performance trace — production is always dev port + 1. Never use `--port` in actual deployment.

package/.claude/commands/pulse-stop.md

@@ -1,5 +0,0 @@
-Stop the Pulse servers for this project — both the dev server (port 3000) and the local production server (port 3001, started by `pulse_build` or `/pulse-start`).
-
-```bash
-pulse stop
-```

package/.claude/commands/verify.md

@@ -1,118 +0,0 @@
-# Verify
-
-Run the verification loop on the current page or the page specified in $ARGUMENTS.
-
-**Modes:**
-- `/verify` — full loop including Lighthouse (desktop + mobile), perf trace, and mobile layout check. Use when the user approves the design or signals they're ready to ship.
-- `/verify --quick` — skips Lighthouse and perf trace; just validate → screenshot → console → review → stamp. Use during iterative building: design rounds, debugging visual issues, mid-build checkpoints. Fast enough to run between every change.
-
-If `--quick` appears anywhere in $ARGUMENTS, run in quick mode (steps 6, 7, 8, and 9 are skipped). The route/file path is whatever remains in $ARGUMENTS after removing `--quick`.
-
-## Steps
-
-### 1. Identify the target
-
-If $ARGUMENTS is provided, use it (minus `--quick` if present) as the file path or route. Otherwise, identify the most recently edited spec file from context.
-
-### 2. Design approval (new builds only)
-
-**Skip this step for edits, bug fixes, or "add X to existing Y" tasks.**
-
-If this is a new page build (came through `pulse_intake` or `build-page`):
-
-1. Take a screenshot and describe what you see to the user.
-2. **Call `pulse_await_approval` first**, then ask the user: "Happy with the design and layout, or would you like any changes before I run Lighthouse?" — if your host provides a question tool (e.g. AskUserQuestion), offer the choices `["Yes, looks good — proceed", "I'd like some changes first"]`; otherwise ask in plain prose. Always call the tool before asking, whichever way you ask: in some hosts (including Claude Code) even a question tool ends the turn and fires the Stop hooks. The marker is harmless if the turn doesn't end — it is consumed when the user replies.
-3. **Do not proceed to step 3 until the user explicitly confirms.** If they want changes, stop here, make the changes, then restart from step 2. Lighthouse takes ~90 seconds — do not waste it on a design the user hasn't approved. If a `VERIFY REQUIRED` stop-hook block fires while your question is unanswered, that is not permission to continue — call `pulse_await_approval`, re-ask, and end your turn.
-
-### 3. Validate the spec
-
-Use `pulse_validate` with the spec file content. If validation fails, report every error clearly and stop — do not proceed to screenshot until the spec is valid.
-
-### 4. Check the dev server
-
-Use `pulse_fetch_page` to confirm the server is responding for the route. If it errors, use `pulse_restart_server` and retry once.
-
-### 5. Screenshot
-
-Use `mcp__chrome-devtools__navigate_page` to load the page route, then `mcp__chrome-devtools__take_screenshot` to capture the result. Describe what you see — layout, content, any obvious rendering issues.
-
-### 6. Lighthouse — desktop *(skip in quick mode)*
-
-**Pre-flight (required before every Lighthouse run):**
-1. Call `pulse_build` to produce a production build and start the production server on port 3001.
-2. Call `navigate_page` with `url: "http://localhost:3001/"` so the browser is on the production server.
-
-Then run `mcp__chrome-devtools__lighthouse_audit` with `{ "device": "desktop" }`.
-
-**Pass bar: Accessibility, Best Practices, and SEO must all be 100.** Performance is measured and reported but is not a hard requirement (it varies with machine load). Report the actual scores. If Accessibility, Best Practices, or SEO is below 100, identify the failing audit(s), fix the issue, and restart from step 3.
-
-### 7. Lighthouse — mobile *(skip in quick mode)*
-
-The browser should still be on `http://localhost:3001/` from step 6. Run `mcp__chrome-devtools__lighthouse_audit` with `{ "device": "mobile" }`.
-
-**Same pass bar: Accessibility, Best Practices, and SEO must all be 100.** Fix any failures and restart from step 3.
-
-**Stay on the production server (port 3001)** — steps 8 and 9 use it too. Do not call `pulse_restart_server` yet.
-
-### 8. Mobile layout check *(skip in quick mode)*
-
-Emulate a mobile viewport and take a screenshot to catch wrapping, overflow, and layout issues before they become Lighthouse failures.
-
-```
-mcp__chrome-devtools__emulate  viewport: "390x844x2,mobile,touch"
-mcp__chrome-devtools__navigate_page  url: "http://localhost:3001/"
-mcp__chrome-devtools__take_screenshot
-```
-
-Describe what you see. Look specifically for:
-- Text or buttons overflowing the viewport
-- Content too small to read or tap
-- Navigation that overlaps content
-- Images that break the layout
-
-Fix any issues, then reset to desktop before continuing:
-
-```
-mcp__chrome-devtools__emulate  viewport: "1440x900x1"
-```
-
-### 9. Performance *(skip in quick mode)*
-
-**Run the trace against the production server, not dev.** Navigate to `http://localhost:3001/<route>` first — if the production server is no longer running, run `pulse_build` again. Tracing the dev server (port 3000) reports misleading LCP/CLS. Then run `mcp__chrome-devtools__performance_start_trace` with `reload: true` and `autoStop: true`. Report LCP and CLS. Flag any LCP insight that suggests a fixable problem (render-blocking resources, large image load delay, etc.).
-
-After the trace, call `pulse_restart_server` to return to the dev server.
-
-### 10. Console errors
-
-Use `mcp__chrome-devtools__list_console_messages` — report any errors or unexpected warnings.
-
-### 11. Code review
-
-Call `pulse_review` with the spec file path. This runs a full code review AND atomically writes the `.pulse-verified` stamp server-side, eliminating any race condition with the stop hook.
-
-Work through every item the review returns. Fix anything that fails before proceeding.
-
-### 12. Close extra browser tabs
-
-Use `mcp__chrome-devtools__list_pages` to get all open pages. Close every page **except the last one** — `close_page` refuses to close the final tab. `pageId` must be a number, not a string.
-
-If there is only one page open, skip this step — there is nothing to close.
-
-### 13. Write verification stamp
-
-Call `pulse_stamp`. This writes `.pulse-verified` via the MCP server, which is more reliable than the `date +%s` shell command — the MCP write always lands after all spec edits, avoiding the mtime race condition that can cause the stop hook to block immediately after verification.
-
-**This must be the last operation before stopping.** The stop hook compares each edited spec's mtime against this stamp — if any spec is newer than the stamp, the hook blocks. Do not edit any spec file after calling `pulse_stamp`.
-
-### 14. Report
-
-Summarise:
-- Validation: pass or fail (with errors if any)
-- Visual: desktop screenshot — any issues found and fixed
-- Console: any errors
-- Review: pass or issues found and fixed
-- **Full mode only:** Lighthouse desktop/mobile scores, mobile layout check, LCP and CLS values
-
-In quick mode, end with: "Quick check passed — run `/verify` when you're ready for the full Lighthouse audit."
-
-In full mode, only confirm the page is good when validation passes, both Lighthouse runs are 100/100/100, CLS is 0.00, and there are no console errors. Otherwise, fix and run `/verify` again.

package/.claude/pulse-checklist.md

@@ -1,189 +0,0 @@
-## Spec review checklist
-
-Before finishing any spec, verify every point below. Fix anything that fails.
-
-### Critical
-
-- **`meta` must be a plain object — never a function.** Individual fields (`title`, `description`, `styles`) can be `async (ctx) => value` functions, but `meta` itself is always `{}`.
-
-  ```js
-  // WRONG — meta is not a function factory
-  meta: async (ctx) => ({ title: '...', styles: [...] })
-
-  // CORRECT — meta is a plain object; individual fields are functions
-  meta: {
-    title:       async (ctx) => (await post(ctx)).frontmatter.title,
-    description: async (ctx) => (await post(ctx)).frontmatter.description,
-    styles:      ['/pulse-ui.css', '/app.css'],
-  }
-  ```
-
-- **Do not set `hydrate` in specs.** It is auto-derived by the framework from the URL entry passed to `createServer`. Specs with `mutations`, `actions`, or `persist` are hydrated automatically. Purely server-rendered specs get zero JavaScript — no configuration needed.
-
-- **The default theme is DARK.** When `meta.theme` is unset, the page renders with the dark palette. If the design calls for a light page, set `meta.theme: 'light'` when you **first write the spec** — do not assume light and discover dark at the screenshot, which costs an edit → restart → re-approval cycle. Declare the theme in your plan/build brief, and ask the user if the brief doesn't say.
-
-- **Always restart the server and reload the browser after every file edit — before checking the result.** The dev server restarts on file changes but the browser tab stays stale. The required sequence is: `pulse_restart_server` → `navigate_page`. Never attempt to debug a visual problem without doing both steps first.
-
-### Components first — or creative override
-
-- **Before writing any HTML by hand, check `src/ui/index.js`.** There are 50+ components. Use `button`, `card`, `alert`, `input`, `spinner`, `badge`, `modal`, `nav`, `pagination`, `table`, etc. before writing equivalent HTML from scratch.
-- **Do not reinvent component patterns.** These patterns have dedicated components — never write custom HTML for them unless a creative override applies (see below):
-  - Hero sections → `hero({ title, subtitle, actions, image, ... })`
-  - Product/service cards → `card({ title, body, image, footer, ... })`
-  - Image + text two-column layouts → `media({ image, content, reverse })`
-  - Feature tiles → `feature({ icon, title, description })`
-  - Testimonials → `card({ content, footer })` with quote + avatar/name in the content slot
-  - CTAs → `cta({ title, subtitle, actions })`
-  - Navigation → `nav({ logo, links, actions })`
-  - Footers → `footer({ logo, links, columns, legal, ... })`
-
-- **Creative override — raw HTML throughout is permitted** when the design intent genuinely calls for it: a highly custom visual identity, an asymmetric or typographically-driven layout, a brutalist/editorial/retro/neon/paper vibe where components would constrain the expression, or a layout that requires features a component simply doesn't support (e.g. full-viewport height, custom gradient glows, clamp-scaled display type). This is a deliberate design decision, not a shortcut. When taking this path:
-  - **Declare it in a comment at the top of the spec** so the reviewer recognises it: `// component-free — creative override: <reason>`. This is the signal the review tool reads.
-  - Functional atoms (`button`, `input`, `badge`, `modal`) should still come from components unless there is a specific design reason not to.
-  - `/pulse-ui.css` is always required — it provides the token system your custom CSS will use.
-  - The quality gate replaces the component checklist: **Lighthouse 100 on Accessibility, Best Practices, and SEO — desktop and mobile — plus CLS 0.00 is the pass bar.** (Performance is reported but not gated; it varies with machine load.) A component-free page that passes every audit is correct. A component-heavy page that fails accessibility is not.
-
-- **When reviewing**: before flagging a class name like `.hero` as a violation, first ask whether the `hero()` component could actually reproduce the layout. If the answer is no, it is a creative override — check Lighthouse instead of refactoring. Do not flatten a good custom layout into a generic component just to clear a pattern-match.
-
-- **The review tool auto-detects creative override** from the spec comment. When detected, component pattern checks are shown as advisory (`⚡`) not as failures, and the Lighthouse gate is the stated pass bar.
-
-- **Never write App Store or Google Play download buttons by hand.** Always use `appBadge({ store: 'apple', href })` and `appBadge({ store: 'google', href })`. Raw `<a>` tags with badge images are incorrect — `appBadge` renders the correct accessible, styled badge for each store.
-
-  ```js
-  import { appBadge } from '@invisibleloop/pulse/ui'
-
-  // In a hero() actions slot:
-  ${hero({
-    actions: `
-      ${appBadge({ store: 'apple',  href: 'https://apps.apple.com/...' })}
-      ${appBadge({ store: 'google', href: 'https://play.google.com/...' })}
-    `,
-  })}
-  ```
-
-### Reuse (DRY)
-
-- **Extract a view helper when the same HTML pattern appears 3 or more times in a single spec.** A plain JS function returning an HTML string is sufficient — no framework needed:
-  ```js
-  const card = ({ title, body }) => `<div class="card"><h3>${title}</h3><p>${body}</p></div>`
-  ```
-- **Create a shared component in `src/components/` when the same pattern is needed across 2 or more different specs.** A named export that returns an HTML string — same shape as the `layout()` pattern in the routing guide. Never paste a section's HTML into a second spec: extract it at the second use, then import it from both. (`src/ui/` is the framework's own library inside the package — project-level shared code always goes in `src/components/`.)
-- **Do not abstract a pattern that appears only once.** Duplication is cheaper than the wrong abstraction. Within a single spec, wait until the third use before extracting a helper; across specs, extract at the second use.
-
-### Correctness
-
-- Mutations return plain partial-state objects and have no side effects (no fetch, no DOM access).
-- `persist` contains only serialisable state that should survive a page reload — not ephemeral UI state like a loading flag or temporary selection.
-- `e.target` assumptions in mutations are safe if the element has child nodes — use `e.target.closest('[data-index]')` rather than assuming `e.target` is the element with the attribute.
-- State shape is consistent — avoid a single field that is sometimes `null`, sometimes a string, sometimes a boolean. Use a dedicated `status` field instead.
-- **Never use `state.modalOpen` or conditional modal rendering.** This destroys the `<dialog>` on every render, breaking focus, animation, and native ESC handling. Instead, always render the `<dialog>` in the DOM and use `data-dialog-open="id"` to open it — the runtime handles this without any spec state:
-  ```html
-  <!-- always in the view, never conditional -->
-  ${modal({ id: 'confirm', title: 'Confirm', content: '...' })}
-  <!-- anywhere on the page — opens the dialog, no mutation needed -->
-  ${modalTrigger({ target: 'confirm', label: 'Open' })}
-  <!-- or inline: -->
-  <button data-dialog-open="confirm">Open</button>
-  ```
-  Close is handled natively by `<form method="dialog">` (inside the modal), ESC key, backdrop click, or `data-dialog-close` on any element.
-
-### Defensive data handling
-
-- **Always check `res.ok` before parsing fetch responses.** Never call `res.json()` on a response that may have failed. Never use `await res.text()` as an error message — on a 404 or 500, this returns raw HTML which surfaces directly in toasts and error alerts. The correct pattern:
-  ```js
-  const res = await fetch('/api/...')
-  if (!res.ok) {
-    let message = `Request failed: ${res.status}`
-    try { const j = await res.json(); message = j.message || j.error || message } catch {}
-    throw new Error(message)
-  }
-  return await res.json()
-  ```
-- **Never assume the shape of data from external APIs or server fetchers.** Use optional chaining (`?.`) and nullish coalescing (`??`) at every access point. If a server fetcher can return `null`, the view must handle it — `server.user?.name ?? 'Guest'` not `server.user.name`.
-- **Validate FormData fields before use.** `formData.get('email')` returns `null` if the field is missing. Check for null/empty before passing to an API or database.
-- **Do not trust URL params.** `ctx.params.id` is a raw string from the URL. Validate it before use — check it exists, is the right type, and refers to a real resource. Return a 404 or redirect if it doesn't.
-
-### CSS
-
-- **`app.css` must contain no hex values or raw colour values.** A lint hook enforces this and will block the build. Hex values belong in `public/theme.css` as token definitions; `app.css` references them via `var()` only.
-- **Load order in `meta.styles`:** `pulse-ui.css` → `theme.css` → `app.css`. Theme tokens must be defined before `app.css` references them.
-- **CSS for a shared section lives in the shared `app.css`, once.** Every spec that renders the section lists the same file in `meta.styles`. Never copy a CSS block into a second per-page stylesheet — two copies drift apart. Per-page stylesheets are for styles only one page uses.
-
-### Security
-
-- Any value from user input (URL params, form fields, external APIs) interpolated into view HTML must be escaped.
-- **Every `<form method="POST">` on a `submit` page includes `${server.csrf}`.** CSRF is enforced — a form without the hidden token field gets 403 on submit. Never set `csrf: false` to "fix" a 403; that disables the protection. `csrf: false` is only for endpoints with their own authentication (e.g. signed webhooks).
-- **`submit` returns `{ redirect }` after a successful mutation** (POST-redirect-GET). Rendering success directly from the POST means browser refresh resubmits the form.
-
-### Server-side forms & error pages
-
-- **Forms that must work without JavaScript use `spec.submit`** + `<form method="POST">` with `${server.csrf}` inside. Hydrated `data-action` on the same form is the enhancement, not the requirement.
-- On a validation re-render, show `server.form?.errors` and echo `server.form?.values` back into the inputs via `value=` — failed validation must not wipe what the user typed.
-- **Every site has a custom 404 page** — a spec with `route: '*'`, using the shared `layout()` so it carries the site's nav and footer. Without it, bad URLs show the framework's unbranded default.
-
-### Tests
-
-- Pure logic functions extracted from a spec (e.g. `checkResult`, `validate`, `formatPrice`) must have unit tests in a corresponding `.test.js` file.
-- **When fixing a bug, write a failing test first.** The test must reproduce the bug before the fix is applied, then pass after. This pins the behaviour so the bug cannot silently return. A fix without a regression test is incomplete.
-- **Use `renderSync` / `render` from `@invisibleloop/pulse/testing` to test view HTML output.** Do not test views with raw `html.includes()` — use the query helpers instead:
-  ```js
-  import { renderSync, render } from '@invisibleloop/pulse/testing'
-
-  // Sync — call view directly with mock state/server
-  const result = renderSync(mySpec, { state: { count: 5 }, server: { items: [] } })
-  assert(result.has('button'))
-  assert.equal(result.get('#count').text, '5')
-  assert.equal(result.count('li'), 0)
-
-  // Async — run real server fetchers (integration), or pass server to skip them
-  const result = await render(mySpec, { server: { product: mockProduct } })
-  assert.equal(result.get('h1').text, mockProduct.name)
-  assert.equal(result.attr('img', 'src'), mockProduct.image)
-  ```
-  Supported selectors: `tag`, `.class`, `#id`, `[attr]`, `[attr="value"]`, combinations (`button.primary[disabled]`), and **descendant combinators** (`result.count('.parent li')`, `result.find('tbody tr')`). Descendant selectors match the rightmost token within the ancestor context — they do not return 0 if the ancestor doesn't exist, they simply find no matching descendants.
-
-### Markdown
-
-- **Use `md()` from `@invisibleloop/pulse/md` for `.md` file content.** Never read and parse markdown manually. Pass the result's `html` to `prose()`.
-- **Call the same `md()` fetcher in both `meta` and `server`** — it caches on `ctx._mdCache` so the file is only read once per request. Do not create two separate fetchers for the same file.
-- **Always add `onViewError` on dynamic markdown routes** (routes with `:param` segments loading `.md` files). A missing file throws `{ status: 404 }` which must be caught gracefully.
-
-### View error handling
-
-- **Define `onViewError` on any page where the view could throw due to bad or missing data.** Without it, a runtime view error returns a 500 on the server and shows a generic inline message on the client. With it, the server returns 200 with your fallback HTML instead of a 500, and the client renders your fallback:
-  ```js
-  onViewError: (err, state, serverState) => `
-    <div class="u-p-4 u-text-center">
-      <p>Something went wrong. <a href="">Reload</a></p>
-    </div>
-  `
-  ```
-  Use this on pages that render data from external APIs or user-supplied content — any path where the view can encounter `null`, `undefined`, or unexpected shapes that would cause a crash. It is not required on simple pages with predictable data.
-
-### Store updates from actions
-
-- **Use `_storeUpdate` to push changes to the global store from an action.** Return it from `onSuccess` alongside the local state update — it is stripped from page state and forwarded to the store. All mounted pages that subscribe to the affected keys re-render immediately:
-  ```js
-  onSuccess: (state, theme) => ({
-    saved:        true,
-    _storeUpdate: { settings: { theme } },  // ← merged into store state
-  }),
-  ```
-  `_storeUpdate` only merges into the store — it does not appear in the page's own state. The rest of the return is merged into local state as normal. Use this instead of a full-page reload when a user action changes shared data (theme, cart count, user profile, etc.).
-
-### Accessibility
-
-- Interactive elements without visible text have an `aria-label`.
-- Disabled state is reflected with the `disabled` attribute, not just CSS.
-- The page has a `<main id="main-content">` landmark.
-- **Every element with `data-event`, `data-store-event`, `data-dialog-open`, or `data-dialog-close` is natively interactive (`button`, `a`, `input`, `select`, `textarea`, `summary`) or has `tabindex="0"`.** Non-interactive tags (`div`, `span`, `li`, `td`, etc.) with these attributes are not keyboard reachable. Prefer `<button>` — it is focusable, fires on Enter/Space, and carries the correct ARIA role for free. Only use `tabindex="0"` on a non-interactive element when a `<button>` genuinely cannot be used.
-- **Every interactive element communicates its purpose and state:**
-  - Buttons have visible text or `aria-label`. Links use descriptive text — "click here", "here", "read more" are failures.
-  - Form inputs have an associated `<label for="id">` or `aria-label`. `placeholder` alone is not a label.
-  - Toggle controls (open/close, show/hide, expand/collapse) carry `aria-expanded="true|false"` or `aria-pressed="true|false"`.
-  - While an action is in flight, the trigger button has `aria-busy="true"` or its label changes (e.g. "Saving…"). A spinner alone is not enough.
-  - Active nav items have `aria-current="page"`. Selected items in a list, tab set, or option group have `aria-selected="true"`.
-- **The page has a logical tab order:**
-  - No `tabindex` value greater than 0. Positive tabindex values override the natural DOM order and create a broken tab sequence. Remove them and reorder the DOM instead.
-  - Visually hidden interactive content (off-canvas menus, collapsed panels, `opacity:0` elements) is removed from the tab order with `tabindex="-1"` or the `inert` attribute — CSS alone does not remove an element from tab order.
-  - DOM order matches the visual reading order. When flexbox `order` or CSS grid placement visually reposition elements, the tab sequence still follows the DOM — author the DOM in the order a user would read and interact with the page.

package/.github/workflows/ci.yml

@@ -1,25 +0,0 @@
-name: CI
-
-on:
-  push:
-    branches: [main]
-  pull_request:
-    branches: [main]
-
-permissions:
-  contents: read
-
-jobs:
-  test:
-    runs-on: ubuntu-latest
-    steps:
-      - uses: actions/checkout@v4
-
-      - uses: actions/setup-node@v4
-        with:
-          node-version: 22
-          cache: npm
-
-      - run: npm ci
-
-      - run: npm test

package/.github/workflows/publish.yml

@@ -1,45 +0,0 @@
-name: Release
-
-on:
-  push:
-    branches: [main]
-
-jobs:
-  release:
-    runs-on: ubuntu-latest
-    permissions:
-      contents: write
-      id-token: write
-    steps:
-      - uses: actions/checkout@v4
-        with:
-          token: ${{ secrets.RELEASE_PAT }}
-
-      - uses: actions/setup-node@v4
-        with:
-          node-version: 22
-          cache: npm
-          registry-url: https://registry.npmjs.org
-
-      - run: npm ci
-
-      - run: npm test
-
-      - name: Bump version from conventional commits, then publish
-        env:
-          NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}
-        run: |
-          VERSION=$(node scripts/release-version.js)
-          # Fallback: if this exact version is somehow already on npm, bump patch
-          while npm view @invisibleloop/pulse@$VERSION version 2>/dev/null | grep -q .; do
-            VERSION=$(node -e "const [a,b,c]='$VERSION'.split('.').map(Number);console.log(a+'.'+b+'.'+(c+1))")
-          done
-          npm version $VERSION --no-git-tag-version --allow-same-version
-          echo "$VERSION" > public/.pulse-ui-version
-          git config user.name  "github-actions[bot]"
-          git config user.email "github-actions[bot]@users.noreply.github.com"
-          git add package.json package-lock.json public/.pulse-ui-version
-          git commit -m "chore: release $VERSION [skip ci]" || true
-          git pull --rebase
-          git push
-          npm publish --provenance --access public