acuvo-code 0.2.0

package/skills/css-layout.md

@@ -0,0 +1,85 @@
+---
+name: css-layout
+description: Grid vs flex, spacing that scales, and building layouts that do not break at 320px
+when: When laying out a page or component, or when something overflows or will not centre
+---
+
+# CSS layout
+
+## Grid or flex — the question answers itself
+
+- **Flex** = one dimension. A row of buttons, a nav bar, a card's inner stack.
+- **Grid** = two dimensions, or *"I want the container to decide the shape"*.
+  Page layouts, card galleries, anything with rows AND columns.
+
+If you are writing `flex-wrap` plus width percentages plus negative margins to
+make a gallery, you want grid:
+
+```css
+.gallery {
+  display: grid;
+  grid-template-columns: repeat(auto-fill, minmax(260px, 1fr));
+  gap: 1.5rem;
+}
+```
+
+⭐ That is a responsive gallery with **no media queries at all** — it reflows on
+available width, which is what you actually meant.
+
+## Use `gap`, not margins between children
+
+`gap` puts space *between* items and never before the first or after the last.
+`margin-right` on every child plus `:last-child { margin-right: 0 }` is the old
+workaround, and it is still wrong when the row wraps.
+
+## ⚠️ Test at 320px. That is where layouts break.
+
+Not 1440. The failure modes are always the same:
+
+- a fixed `width` that should be `max-width`
+- a long unbroken string (a URL, an email) forcing horizontal scroll —
+  `overflow-wrap: anywhere` on the container
+- a table with no `overflow-x: auto` wrapper
+- padding that eats the whole viewport
+
+⭐ **The body must never scroll horizontally.** Wide content scrolls inside its
+own container, not the page.
+
+## Centring
+
+```css
+.center { display: grid; place-items: center; }   /* both axes, done */
+```
+
+For a page column: `margin-inline: auto` with a `max-width`. Do not use
+absolute positioning and transforms for something the layout can do.
+
+## Spacing on a scale, not by feel
+
+Pick a scale (4 / 8 / 12 / 16 / 24 / 32 / 48) and use only those values. A
+layout with `13px` here and `17px` there looks unresolved even when nobody can
+say why. Put them in custom properties and reference those.
+
+## The modern tools, in order of how often they help
+
+1. **`clamp()`** — fluid type and spacing without breakpoints:
+   `font-size: clamp(1.5rem, 4vw, 3rem)`
+2. **Container queries** — a component that adapts to ITS box rather than the
+   viewport, which is what a card in a sidebar actually needs:
+   `@container (min-width: 400px) { … }`
+3. **Logical properties** — `padding-inline`, `margin-block`. They do the right
+   thing in every writing direction and cost nothing to adopt.
+4. **`aspect-ratio`** — reserve space for media and stop the reflow.
+
+## ⚠️ z-index is not a ladder to climb
+
+`z-index: 9999` means someone lost an argument with the stacking context. Define
+a small set of layers (base, dropdown, modal, toast) as custom properties and
+use those names. And remember z-index only applies to positioned elements.
+
+## Do not fight the flow
+
+`position: absolute` for something that should be in the document, `height:
+100vh` on a mobile browser whose chrome hides and reappears (use `100dvh`),
+`!important` to beat your own selector — each is a signal that the layout is
+being forced rather than described.

package/skills/data-and-charts.md

@@ -0,0 +1,77 @@
+---
+name: data-and-charts
+description: Picking a chart that answers the question, and the defaults that make a dashboard readable
+when: When building a dashboard, a report, or anything that shows numbers to a person
+---
+
+# Data and charts
+
+## Pick the chart from the QUESTION, not from the data
+
+| the question | the chart |
+|---|---|
+| how has this changed over time? | line |
+| which of these is biggest? | horizontal bar |
+| what is this made of? | stacked bar — **not** a pie |
+| are these two related? | scatter |
+| what is the single number right now? | just print the number, large |
+
+⭐ The last row is the one most often over-built. A metric that is one number
+should be one number. A gauge, a donut and a sparkline around it are decoration
+that makes the number harder to read.
+
+## ⚠️ Never a pie chart for more than five things
+
+People compare angles badly. Past about five slices a pie becomes a legend with
+a picture attached, and the reader has to look things up. A horizontal bar chart
+sorted descending answers "which is biggest" instantly and takes the same space.
+
+Never a pie for values that do not sum to a meaningful whole.
+
+## Sort bars, unless the order means something
+
+Alphabetical is the wrong default — it scatters the answer. Sort descending by
+value. The exceptions are categories with an inherent order: days of the week,
+age bands, survey responses from "never" to "always".
+
+## The axis rules that change conclusions
+
+- **Bar charts start at zero.** Truncating the axis exaggerates differences and
+  is the single most common way a chart misleads.
+- **Line charts need not** start at zero — the shape of the change is the point.
+- Label the units. "Revenue" is not a unit; "Revenue (A$, ex GST)" is.
+
+## ⚠️ Show the empty and loading states
+
+A dashboard with no data yet is the state every user sees FIRST, and it is
+usually the one nobody designed. Say what will appear and why it is empty:
+
+```
+✗ (a blank rectangle)
+✓ "No calls yet. This fills in once your first campaign runs."
+```
+
+And distinguish **empty** from **failed to load** — see `error-handling`. A
+chart that renders zero because the request 500'd is a lie told in pictures.
+
+## Numbers people can read
+
+- Round to the precision that matters: `A$1,284` not `A$1284.3891`
+- Thousands separators, always
+- Percentages need a base: "12% (of 340 calls)"
+- Dates in a form with no ambiguity: `18 Aug 2026`, never `08/09/26`
+
+## Colour carries meaning or it carries nothing
+
+Use one accent for the series that matters and grey for context. A chart where
+every series is a different bright colour has told the reader that everything is
+equally important, which is never true.
+
+⚠️ Never encode meaning in colour ALONE — about 1 in 12 men cannot separate red
+from green. Label the line, or vary the shape.
+
+## Tables are underrated
+
+If the reader's real question is "what exactly was this number", a sorted table
+with aligned right-hand numerals beats every chart. Charts are for shape;
+tables are for values.

package/skills/debugging.md

@@ -0,0 +1,76 @@
+---
+name: debugging
+description: Read the error literally, doubt the check before the code, and change one thing at a time
+when: When something does not work, a test fails, or a fix did not take effect
+---
+
+# Debugging
+
+## ⚠️⚠️ Read the error literally. It is usually telling the truth.
+
+`x is not a function` means `x` is not a function. Not "the import is
+circular", not "the bundler is confused" — **print `x` and look at it.** Most
+time lost to debugging is spent on a theory formed before reading the message.
+
+Ask, in this order:
+
+1. What does the message actually say?
+2. What is the value it is complaining about? Print it.
+3. Which line? Read that line, not the one you assume it means.
+
+## ⚠️⚠️ Doubt the check before you doubt the code
+
+When a test fails on code you believe is correct, one of two things is true, and
+the expensive mistake is assuming it is the first:
+
+- the code is wrong, **or**
+- **the check is wrong** — and a check that fails correct work is worse than no
+  check, because it sends you to rewrite something that already worked.
+
+Prove which: **break the code deliberately and see whether the check notices.**
+A check that stays green when you break the thing it guards was never testing
+it. See `verify-your-own-work`.
+
+## The fix that "did not work"
+
+Before concluding a fix is wrong, prove it ran:
+
+- Are you editing the file that is actually loaded? (Two files with the same
+  name in different directories is the classic.)
+- Did the build/dev server pick it up? Stale cache?
+- Is the branch you edited the branch you ran?
+- Is something later overwriting it?
+
+⭐ Put a deliberate marker in — `throw new Error('REACHED')` — and confirm you
+see it. If you do not, the problem was never the logic.
+
+## Change one thing at a time
+
+Three changes then a test tells you nothing about which mattered — and if it
+still fails you now have four suspects. One change, one observation.
+
+Keep the last known-good state reachable so you can always get back.
+
+## Bisect when you have no theory
+
+If it worked before and does not now, the fastest route is not thinking harder,
+it is **halving the search space**: `git bisect`, comment out half the file,
+disable half the config. Two or three halvings usually beats an hour of staring.
+
+## ⚠️ Reproduce it before you fix it
+
+A bug you cannot reproduce is a bug you cannot confirm you fixed. If it happens
+"sometimes", find the input that makes it happen every time first — that
+usually IS the diagnosis.
+
+## Say what you know and what you assume
+
+"The request 404s" is an observation. "The route is not registered" is a theory.
+Keeping the two apart is what stops you fixing a route that was fine while the
+real fault — a typo in the URL — sits unexamined.
+
+## When you are truly stuck
+
+Explain the problem out loud from the beginning, including the parts you are
+sure about. The wrong assumption is almost always in the part you did not think
+was worth saying.

package/skills/designing-by-looking.md

@@ -0,0 +1,84 @@
+---
+name: designing-by-looking
+description: Render it and LOOK — the see_page loop, not better CSS written blind
+when: After building or restyling any page, component or app, and before telling anyone it is done
+---
+
+# Designing By Looking
+
+## ⚠️⚠️ You cannot judge a page you have not seen
+
+You have `see_page`. It renders an HTML file in a real browser and returns a
+screenshot **plus measured problems** — invisible text, overflow, cramped
+sections. Use it.
+
+**A page you have not looked at is not finished, it is only written.** Markup
+that reads correctly is routinely broken on screen: white text on white,
+a section 500px tall holding one line, a row that overflows on the narrow
+viewport, a delete button stretched across the full width.
+
+Those are the exact defects that shipped in real builds here. Every one of them
+is invisible in the source and obvious in a screenshot.
+
+## ⭐⭐ The loop, in order
+
+1. **Build** the page.
+2. **`see_page`** on the file you just wrote.
+3. **Read the findings first, then look at the screenshot.** The findings are
+   measured; your impression is not.
+4. **Fix the specific thing.** One at a time.
+5. **Look again.** A fix you did not re-check is a hope.
+
+⭐ **Repeat until the screenshot is good, not until the code looks right.** The
+loop is the method. Better prompts are not the method — a page improves because
+someone looked at it, noticed a real defect, and fixed that defect.
+
+## ⚠️ Do not fix blind
+
+The failure mode is reading your own CSS, forming a theory about what it must
+look like, and rewriting it without rendering. That is how a "fix" makes the
+page worse and nobody notices for three rounds.
+
+If `see_page` reports overflow, you do not need a theory about why. Look at the
+screenshot, find the element that is too wide, and constrain that element.
+
+## ⭐ What to actually check when you look
+
+Ask these in this order, because they fail in this order:
+
+1. **Is every piece of text visible?** Contrast, and not clipped.
+2. **Does anything overflow?** Especially tables, code blocks, long words and
+   button rows.
+3. **Is there dead space?** A section far taller than its content reads as
+   broken, not airy.
+4. **Is there ONE clear first thing to look at?** If everything is the same
+   weight, nothing is.
+5. **Do the controls look like controls?** A full-width bar is not a button.
+6. **Is there a real `<h1>`?** Pages ship without one constantly.
+
+## ⭐ `read_image` for anything you generated
+
+`see_page` is for pages. For an image you made with `generate_image`, use
+**`read_image`** — it returns a factual description, and you can ask it a
+question about the file.
+
+**Generating an image and never looking at it is the same mistake as shipping an
+unrendered page.** Text inside generated images is misspelled often enough that
+it must be checked every time, not assumed.
+
+## ⚠️ Looking costs tokens — so look deliberately, not constantly
+
+A screenshot is charged as image tokens (roughly one token per 750 pixels, with
+the long edge capped at 1568). That is cheap, but it is not free.
+
+⭐ **Look after a meaningful change, not after every line.** Build the whole
+page, then look. Fix the three findings, then look again. Two or three passes
+usually settles a page; ten means you are guessing between them.
+
+## The bar
+
+Not "does this render". The bar is: **does it look like someone designed it,
+or does it look like a template with content dropped in?**
+
+Related skills: `acuvo-design-system`, `page-composition`, `typography`,
+`colour-and-contrast`, `verify-your-own-work`.

package/skills/error-handling.md

@@ -0,0 +1,78 @@
+---
+name: error-handling
+description: Empty is not unreadable is not never-instrumented — and why a swallowed error is the expensive one
+when: When writing a catch block, a default value, or anything that reports a result
+---
+
+# Errors
+
+## ⚠️⚠️ The house rule: empty ≠ unreadable ≠ never-instrumented
+
+Three different facts get flattened into one innocent-looking value:
+
+| what happened | what it means | what it must NOT return |
+|---|---|---|
+| we looked, there is nothing | **empty** | — |
+| we looked and could not read it | **failure** | `[]` |
+| nobody ever measured this | **unknown** | `0`, `false`, "fine" |
+
+Returning `[]` for "the query failed" is the bug that hides for months, because
+every caller downstream reads it as "there are none" and behaves perfectly
+sensibly on a false premise.
+
+```js
+✗ try { return await load(); } catch { return []; }
+✓ try { return { ok: true, rows: await load() }; }
+  catch (e) { return { ok: false, error: String(e) }; }
+```
+
+The same rule for a check: a check that could not run reports **unknown**, never
+**pass**. "No problems found" is a real claim and has to be earned.
+
+## A caught error you do nothing with is worse than a crash
+
+A crash tells you where and when. A swallowed error produces a program that is
+subtly wrong later, somewhere else, for reasons nobody can trace.
+
+```js
+✗ catch (e) {}
+✗ catch (e) { console.log('oops'); }
+✓ catch (e) { console.error('loading invoices failed', e); showError(e); }
+```
+
+⭐ If you genuinely want to ignore one, say why in a comment. That comment is
+the difference between a decision and an oversight:
+
+```js
+catch { /* an observation must never break the thing it observes */ }
+```
+
+## Error messages are read by two audiences
+
+- **The user** needs to know what to do: *"Could not save — you are offline.
+  Your changes are kept, try again."*
+- **You** need to know what broke: the stack, the input, the identifiers.
+
+Do not show the user a stack trace, and do not log only "error occurred".
+
+## ⚠️ Fail the whole operation, not half of it
+
+A loop that catches per item and continues quietly produces a half-written
+result nobody knows is half-written. Either:
+
+- collect the failures and report them together at the end, or
+- stop on the first one.
+
+Silently skipping item 7 of 200 is the option that costs the most later.
+
+## Errors at the boundary
+
+Every network call has three outcomes, not two: **success**, **failure**, and
+**still going**. A UI that only models the first two shows nothing at all while
+the request is in flight, and users click again.
+
+## ⚠️ Never let an error string tell you what to do
+
+*"try again"* in a message is not instruction — it is the remote end's guess. A
+retry loop that trusts it can spend an entire budget on a service that is down.
+Retry on a policy you chose, with a ceiling you chose.

package/skills/forms-and-validation.md

@@ -0,0 +1,93 @@
+---
+name: forms-and-validation
+description: Building a form that actually works — validation timing, error copy, and the states people forget
+when: Whenever the thing you are building contains an input, a form, or a submit button
+---
+
+# Forms
+
+The most common thing a generated app contains, and the most commonly half-built.
+
+## The four states every form has
+
+A form is not "empty" and "filled". It is:
+
+1. **empty** — nothing typed, no errors shown yet
+2. **invalid** — the user has been told what is wrong, in words
+3. **submitting** — the button is disabled and says so
+4. **done** — the user can see it worked
+
+Skipping 3 is how a form gets double-submitted. Skipping 4 is how a user fills
+it in twice because nothing appeared to happen.
+
+## ⚠️ Validation timing is the difference between helpful and hostile
+
+- **Do not validate while the user is still typing the first time.** Turning a
+  field red at the third character of an email address is punishing someone for
+  not having finished.
+- **Validate on blur**, and again on submit.
+- **Once a field has errored, re-validate as they type** — so the error clears
+  the moment they fix it, rather than after they leave the field again.
+
+## Error messages say what to do
+
+```
+✗ "Invalid input"
+✗ "Error: field required"
+✓ "Enter an email address — we send the confirmation there"
+✓ "Password needs 8 characters or more"
+```
+
+Put the message next to the field, not in a banner at the top. A banner cannot
+say *which* of nine fields is wrong.
+
+## ⚠️⚠️ Never trust the client
+
+Client validation is a convenience for the user. It is not a check. Anything
+that matters is validated again on the server, because the client is a program
+the user controls.
+
+Marking a field `required` in HTML and nowhere else means the first person to
+open devtools sends whatever they like.
+
+## Accessibility, which is three attributes
+
+```html
+<label for="email">Email</label>
+<input id="email" name="email" type="email" aria-describedby="email-error">
+<p id="email-error" role="alert">Enter an email address</p>
+```
+
+A placeholder is not a label — it disappears exactly when the user needs it,
+and screen readers do not reliably announce it.
+
+## Use the right input type
+
+`type="email"`, `type="tel"`, `type="number"`, `inputmode="numeric"`. On a
+phone this changes the keyboard that appears, which is a real difference in
+whether the form gets completed.
+
+## The submit handler
+
+```js
+form.addEventListener('submit', async (e) => {
+  e.preventDefault();              // or the page reloads and the work is lost
+  if (busy) return;                 // guard the double-click
+  busy = true;
+  button.disabled = true;
+  button.textContent = 'Saving…';
+  try {
+    await save(new FormData(form));
+    showSuccess();
+  } catch (err) {
+    showError(err);                 // tell the user, do not swallow it
+  } finally {
+    busy = false;                   // ⚠️ in finally, or one failure freezes the form forever
+    button.disabled = false;
+    button.textContent = 'Save';
+  }
+});
+```
+
+⚠️ The `finally` is the part that gets left out. Without it, a single failed
+request leaves the button disabled and the user with no way to retry.

package/skills/nextjs-app-router.md

@@ -0,0 +1,75 @@
+---
+name: nextjs-app-router
+description: Next.js App Router — server vs client components, data loading, the mistakes that cost hours
+when: Working in a Next.js project, or any app/ directory with page.tsx
+---
+
+# Next.js App Router
+
+## The rule everything else follows
+
+**Server components fetch. Client components render.** A component is a server
+component unless it says `'use client'`.
+
+Put every read in the page (server), pass results down as props. A child that
+fetches forms its own opinion about a failure the page already has one sentence
+for — and its failure renders as an empty state, which is indistinguishable from
+"nothing happened".
+
+```tsx
+// page.tsx — server. Reads, decides, passes down.
+export default async function Page({ params }: { params: { id: string } }) {
+  const { rows, error } = await read(params.id);
+  if (error) return <Unreadable why={error} />;   // ONE place says "broken"
+  return <Detail rows={rows} />;                   // the child only renders
+}
+```
+
+⚠️ `'use client'` is contagious downward. A client component's children are all
+client. Push it to the leaf that actually needs interactivity — a single
+`<LikeButton />`, not the page.
+
+## What forces 'use client'
+
+`useState` · `useEffect` · `useRef` · event handlers (`onClick`) · browser APIs
+(`window`, `localStorage`, `IntersectionObserver`). Nothing else.
+
+## Params are async in Next 15+
+
+```tsx
+export default async function Page({ params }: { params: Promise<{ id: string }> }) {
+  const { id } = await params;
+}
+```
+⚠️ Getting this wrong gives a confusing runtime error, not a type error.
+
+## Caching, which is where the hours go
+
+- `export const dynamic = 'force-dynamic'` when the page must read fresh data
+  every request. Without it you can ship a dashboard that shows build-time data
+  forever and looks merely "stale" rather than broken.
+- `revalidate = N` for periodic refresh.
+- Mutations use a server action or route handler, then `revalidatePath()`.
+
+## Common failures, in order of how often they bite
+
+1. **A server component imported into a client component** — everything below
+   becomes client and the fetch breaks. Pass it as `children` instead.
+2. **`useSearchParams` without `<Suspense>`** — build error at the very end.
+3. **Env vars.** Only `NEXT_PUBLIC_*` reach the browser. A secret read in a
+   client component is `undefined`, not an error.
+4. **Hydration mismatch** — `Date.now()`, `Math.random()` or `localStorage` in
+   render. Move to `useEffect`.
+5. **Images** — `next/image` needs `width`/`height` or `fill` + a positioned
+   parent.
+
+## Route handlers
+
+```ts
+export async function POST(req: Request) {
+  const body = await req.json();          // throws on bad JSON — catch it
+  return Response.json({ ok: true }, { status: 200 });
+}
+```
+Always validate the body. Never trust `body.tenantId` from the client to decide
+what data to return — derive it from the authenticated session.

package/skills/page-composition.md

@@ -0,0 +1,103 @@
+---
+name: page-composition
+description: Visual hierarchy, whitespace and section anatomy — why a technically correct page still looks generated
+when: Laying out any marketing page, landing page or app screen, or when output looks flat and evenly grey
+---
+
+# Composition
+
+`css-layout` covers the mechanics — grid, flex, gap, breakpoints. This is the
+layer above it: **where things go and how big they are relative to each other.**
+A page can be flawlessly implemented and still look generated, and this is
+almost always why.
+
+## ⚠️ The failure has a shape: everything is the same size
+
+Generated pages tend toward uniformity — three equal cards, then three more,
+each section the same height, the same padding, the same weight. Nothing
+dominates, so the eye has nowhere to land, and the page reads as a list rather
+than a designed thing.
+
+⭐ **Every screen needs ONE dominant element.** In a hero it is the headline. In
+a dashboard it is the number that matters. Make it dominant by **scale
+contrast**, not decoration: 3–4× the body size, not a border and a badge.
+
+## Whitespace is the material, not the gap
+
+- **Space between sections should be 3–5× the space inside them.** That single
+  ratio is most of what separates a designed page from a template. If section
+  padding is `24px`, the space between sections is `96–120px`, not `32px`.
+- ⚠️ **Generated pages are almost always too tight.** When unsure, add more.
+  Cramped reads as cheap; generous reads as confident.
+- Group by proximity. A label 4px from its input and 40px from the next field
+  needs no box drawn around it. **Proximity beats borders** — reach for space
+  before reaching for a card.
+
+```css
+section        { padding-block: clamp(4rem, 10vw, 8rem); }
+.section-inner { display: grid; gap: 1.5rem; max-width: 72rem; margin-inline: auto; padding-inline: 1.5rem; }
+```
+
+## Break the symmetry, deliberately
+
+Three equal columns is the default and the default is what looks generated.
+
+- **Asymmetric splits read as designed**: 7/5, 8/4, 2fr/3fr. A hero with text
+  at 55% and an image at 45% has tension; 50/50 has none.
+- **Vary the rhythm down the page**: full-bleed, then contained, then two-up,
+  then contained. Four identical stacked sections is the problem.
+- ⚠️ **Do not centre everything.** Centred headline, centred paragraph, centred
+  button, section after section — it is the most common generated-page shape
+  there is. Left-align body content; centre only short, deliberate moments.
+
+## Landing page anatomy — what earns its place
+
+In order. Each section answers one question and then gets out of the way.
+
+1. **Hero** — *what is this and who is it for?* One headline (a claim, not a
+   slogan), one sentence of support, one primary action. Optionally one real
+   image. ⚠️ Not three buttons, not a feature list.
+2. **Proof** — *why believe you?* Logos, a number, a testimonial with a real
+   name and role. Immediately after the hero, because it is the first objection.
+3. **What it does** — 3–4 concrete capabilities in the customer's words.
+   Outcomes, not features.
+4. **How it works** — 3 steps. This is where a diagram or screenshot earns
+   its place.
+5. **Objection handling** — pricing, FAQ, guarantee. Whatever the actual
+   hesitation is for that business.
+6. **Close** — the same action as the hero, restated. Someone who read to the
+   bottom is ready; do not make them scroll back up.
+
+⭐ **Cut before adding.** A five-section page where every section does work
+beats a nine-section page padded with "Our Values". If a section does not answer
+one of those questions, delete it.
+
+## Images
+
+- **A real photograph is worth more than any amount of decoration.** Use the
+  image marker so a real one is generated rather than a grey box.
+- **Give images a job.** A hero image should show the thing or the person, not
+  an abstract swoop. For a trade business: the van, the work, the person. For a
+  product: the product in use.
+- Always `object-fit: cover` with a fixed aspect-ratio so layouts do not jump:
+  `aspect-ratio: 16/9; object-fit: cover; width: 100%`.
+- ⚠️ Never a stock-photo handshake, never a generic "team in a meeting". It
+  reads as filler and undercuts everything around it.
+
+## Density is a choice you make once
+
+A marketing page is **spacious** — few elements, large type, lots of air.
+A dashboard is **dense** — small type, tight rows, many things visible.
+
+⚠️ Mixing the two is jarring. A dashboard with hero-sized headings wastes the
+screen; a landing page with dashboard density looks like a spreadsheet. Decide
+which the brief is asking for before setting a single size.
+
+## Before calling it done
+
+- One element on each screen is clearly dominant.
+- Space between sections is several times the space inside them.
+- At least one section breaks the symmetry of the others.
+- Not everything is centred.
+- Every section answers a question a visitor actually has.
+- At 320px it is still one readable column, and nothing overflows sideways.