Every page on ten emulated phones and tablets: 190 loads, 21 blocking and 530 high findings, on pages that had passed Batch 11 and Batch 16. #214 was fixed in v0.9.5 and released still broken. The check was a desktop window sized to 768, which has a scrollbar, so the layout viewport was ~753px and the md breakpoint the fix was about never engaged. At a true 768 the brand, six nav links and the CTA want 787px against 736px of container, so no amount of gap tightening closes it. The desktop row now starts at lg, and 768 to 1023 gets the Sheet menu, which is the better tablet experience regardless: 44px rows instead of 17px ones, and submenus that do not depend on hover. The CTA takes shrink-0 and whitespace-nowrap, so the next row that does not fit overflows visibly instead of being squeezed past the edge while the total still measures as fitting. The Cisco mark fills 66% of its 700x700 canvas, so both tiles scaled it up inside overflow-hidden and cut 13px off the trademark on / and 24px on /about. Cropping the viewBox to the artwork renders it at 62x46 on /, the same size as the 8x8 logo beside it, unscaled and unclipped. 491 standalone links were 17 to 26px tall. .tap-target grows the hit box and takes it back out of the layout, and every list using it moves to space-y-4: at space-y-2 neighbouring boxes overlap and measure 33px while not being there. Footer links also take block, so the row is the target. A 39x36 word is judged as a compact target wanting 44px; a 200x36 row wants 32. scripts/device-sweep.mjs and scripts/lib/css-audit.js are the instrument. They stay out of verify.sh: playwright is global here and the sweep needs a running server, and a guard that cannot run on a clean clone is one that gets skipped. After the fixes: zero blocking, zero high across all ten devices. Each defect was then re-introduced and reported again (clipped x1, media_overflow x1, past_viewport x19, touch_target x342). closes #238 closes #239 closes #240 closes #241 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| OVERHAUL_PLAN.md | ||
| README.md | ||
| REDESIGN_REVIEW.md | ||
README.md
Design — Queue North Website
Status: Current
Owner: _null
Last reviewed: 2026-08-18
Governs: docs/design/**
Review trigger: Any new user-facing surface, or a change to the product's tone
Documents here
Two, and they answer different questions. Both predate the template and both are this project's own writing.
| Document | Owns |
|---|---|
OVERHAUL_PLAN.md |
what it looks like — Tailwind theme tokens, the numeric-typography rule (Georgia for all numeric content), the type scale, section spacing and container sizes, radius/shadow/border rules, which shadcn-style primitives to use, the per-page layout blueprints, and the explicit anti-patterns. Its earlier Migration Phases and Agent Plan sections are history; the brief onward is live |
REDESIGN_REVIEW.md |
what it sounds like — the B2B positioning argument, the messaging shift from "interesting technical person" to "reliable communications and IT partner", and the anti-patterns of tone. The eleven open content issues in Batch 12 are defects measured against this |
The single most load-bearing sentence across both: business buyers purchase risk reduction, not technology. Copy that reads as clever costs trust here in a way it would not on a developer-facing product.
What belongs here
What it should feel like, and the decisions behind that:
- Product decisions — what the user can do, in what order, and what happens when they get it wrong. The error states are design, not an afterthought.
- UI plans — screens, states, and what each one is for. Include the empty state and the loading state; they are the two most people see first and the two most often left undesigned.
- Copy — the actual words. Interface text is a design surface, and writing it late means writing it badly.
- Tone — how this product talks. One paragraph is enough, and it settles a hundred small arguments.
What does not belong here
- How it is built — that is
docs/architecture/ - Scope and audience — that is
docs/planning/PROJECT_PLAN.md
Include the rejected version
For any decision that was genuinely close, record what was not chosen and why. Without it, the same option gets proposed every few months and re-argued from nothing.