Files
pad/web
xarmian 0b16be492b fix(web): wrap the settings tab bar so no tab is hidden at phone width (TASK-2245 / C82) (#1306)
* fix(web): wrap the settings tab bar so no tab is hidden at phone width (TASK-2245 / C82)

The five owner tabs are 562px intrinsic and the bar's box is the viewport
minus the page's 48px of padding, so below ~610px the row overflowed. With
`overflow-x:auto` plus `scrollbar-width:none` it overflowed INVISIBLY: the
row ended after a tab with clean trailing whitespace and looked complete.
Measured at 390x844 on the unfixed build, Storage was 9.3% visible and
Danger Zone 0% — workspace export and deletion reachable only by a swipe
nothing advertised. At 320/360 three tabs were clipped.

No single-row shape can hold the full labels: 562px does not fit 342px, and
dropping the tab padding to 10px still needs two rows. Of the three shapes
the item proposed, an edge fade leaves a tab clipped by construction, and a
picker keeps four of five labels off screen until a tap — which is the
defect itself. Wrapping is the one that makes every label legible at once.

Deliberately not inside a media query: `flex-wrap` is inert while the row
fits. That is measured, not assumed — at 640/768/1024/1280 the bar stays one
row at 35px with the content top unmoved at 184.6, identical to the
scrolling build; only 320-430 wrap, at a cost of +38px of content offset at
390 and +76px at 320.

Two e2e legs, each with a non-vacuity precondition: the mobile leg asserts
nothing is clipped and the bar no longer scrolls, and the desktop leg pins
the inertness claim — it fails if the rule is ever widened into an
unconditional wrap.

Claude-Session: https://claude.ai/code/session_01WS9QAnxk1gA3LBha3PvKVm

* test(web): read horizontal page scroll off the real scroll chain (TASK-2245 / C82)

The spec's "no horizontal page scroll" oracle read
`document.scrollingElement`, but the app scrolls inside `.main-content`,
whose `overflow-y:auto` computes `overflow-x:auto`. Overflow is therefore
contained there and never reaches the document, so that assertion could
not fail — it was inert, not a guard.

It now walks the tab bar's ancestors to <html> and asserts none of them
scroll horizontally. Verified to discriminate rather than assumed: forcing
a 3000px-wide child into `.settings` makes the list
`[div.settings, main.main-content]`, which the previous oracle reported as
clean.

Found by Codex review round 1 (P2).

Claude-Session: https://claude.ai/code/session_01WS9QAnxk1gA3LBha3PvKVm

* test(web): a scroll-chain oracle must check the container, not just overflow (TASK-2245 / C82)

`scrollWidth > clientWidth` is true of any element with a wide descendant,
including one whose `overflow-x` is `visible` and which therefore cannot
scroll at all. The ancestor walk now requires computed `overflow-x` to be
`auto` or `scroll` before treating an element as a scroll container, so a
long settings value can no longer fail the leg spuriously.

My own negative control had already shown the false positive and I read it
as confirmation instead of as the defect it was: forcing a 3000px child into
`.settings` listed BOTH `div.settings` and `main.main-content`, and only the
second is a scroll container. With the filter the same control lists
`main.main-content` alone, which is the claim the comment now makes.

Also narrows an overclaim in the CSS comment: "any scrolling shape leaves a
tab clipped by construction" is broader than anything measured. What was
measured is that a row opening at scrollLeft=0 leaves the later tabs clipped
in the initial view.

Found by Codex review round 2 (P2 + nit).

Claude-Session: https://claude.ai/code/session_01WS9QAnxk1gA3LBha3PvKVm
2026-09-09 14:42:47 -04:00
..
2026-03-26 01:52:36 +00:00
2026-03-26 01:52:36 +00:00
2026-03-26 01:52:36 +00:00
2026-03-26 01:52:36 +00:00

Pad Web UI

SvelteKit 2 + Svelte 5 frontend for Pad, compiled to static files and embedded into the Go binary.

Development

npm install
npm run dev          # Dev server at localhost:5173 (proxies API to localhost:7777)
npm run build        # Production build to build/
npm run check        # Type checking with svelte-check

When developing, run the Go backend separately with make dev from the project root.

Building for Production

Do not build in isolation. Always use make build from the project root — this builds the web frontend, then compiles the Go binary with the build output embedded via //go:embed.

Stack

  • Svelte 5 with runes ($state, $derived, $effect)
  • SvelteKit 2 with adapter-static (SPA mode)
  • Tiptap block editor with markdown round-trip
  • svelte-dnd-action for drag-and-drop in board/list views
  • SSE for real-time updates
  • TypeScript throughout

Structure

src/
  routes/                    SvelteKit pages
    +layout.svelte           App shell (sidebar + main)
    +page.svelte             Landing/redirect
    [workspace]/
      +page.svelte           Dashboard (collections, phases, activity)
      +layout.svelte         SSE connection per workspace
      [collection]/
        +page.svelte         Collection view (board/list)
      [collection]/[item]/
        +page.svelte         Item detail + editor
      conventions/            Purpose-built conventions page
      playbooks/              Purpose-built playbooks page
      settings/               Workspace settings
  lib/
    api/client.ts            HTTP API client
    components/
      layout/                Sidebar, navigation
      editor/                Tiptap editor, raw markdown editor
      fields/                FieldEditor, relation picker
      items/                 ItemCard, ItemDetail
      collections/           BoardView, ListView
      common/                StatusBadge, badges, modals
      search/                CommandPalette
    stores/                  Svelte 5 reactive stores
      workspace.svelte.ts    Workspace state
      collections.svelte.ts  Collection + item state
      ui.svelte.ts           Sidebar, mobile state
    types/index.ts           TypeScript types and constants
  app.css                    Global styles and design tokens