feat(frontend): header nav redesign — grouped pill track (Option B)

.claude/agents/engineering/frontend-dev.md

@@ -19,14 +19,15 @@ You are the **frontend specialist**. The tech-lead handed you part of a feature.
 1. Read `CLAUDE.md`, `fofafu_vault/protocols/dispatch.md`, your role file, the feature file.
 2. Spec or implement the frontend slice the tech-lead assigned:
    - **Phase 1**: write a Frontend Spec section listing pages, components, queries, stores, forms with Zod schemas.
-   - **Phase 3 onward**: write actual code under `frontend/src/`. Follow the global rules in `~/.claude/rules.md`:
+   - **Phase 3 onward**: if the change is visually observable (UI/layout/styling), capture `docs/screenshots/<slug>/before.png` against the CURRENT component FIRST, before touching any code — much simpler than reconstructing the old version from git history afterward. Then write actual code under `frontend/src/`. Follow the global rules in `~/.claude/rules.md`:
      - One component per file (PascalCase).
      - Co-locate component + hook + types + tests in same folder.
      - Functional components only — no `React.FC`.
      - Tailwind only — no inline styles, no CSS modules.
      - `cn()` for conditional classes.
-3. Append a log line: `- HH:MM #team/eng/frontend [[features/<slug>]] — <what you did, one line>`
-4. Return:
+3. If you captured a `before.png` in step 2, capture `after.png` now against the finished component (same viewport/demo state as `before.png`) per `fofafu_vault/standards/engineering-standards.md`'s convention, commit both, and note in your `### Frontend` subsection whether you captured them live or couldn't (say why — don't skip silently).
+4. Append a log line: `- HH:MM #team/eng/frontend [[features/<slug>]] — <what you did, one line>`
+5. Return:
    ```
    role: frontend-dev
    deliverable: <files or sections written>

CLAUDE.md

@@ -95,6 +95,7 @@ Only the dispatcher writes the `status` field on a feature file. Leads can reque
 - **Commit convention**: Conventional Commits (`feat(area): …`, `fix:`, `chore:`, `vault:` for vault-only changes).
 - **Branch naming**: `feat/<slug>`, `fix/<slug>`, `vault/<topic>`.
 - **No TODOs without a feature file** — if it's worth a TODO, it's worth a feature file.
+- **Visual changes need before/after screenshots.** Any PR touching UI/layout/styling gets `docs/screenshots/<slug>/{before,after}.png` committed to the branch and linked in the PR body — see `fofafu_vault/standards/engineering-standards.md` for the exact convention. This applies whether or not the work went through a formal `/dispatch`.
 - **All work flows through the dispatcher.** If you find yourself doing work for a human without a feature file, stop and `/new-feature` first.
 
 ## When you (Claude or a subagent) are activated

fofafu_vault/features/auth-user-name-semantics.md

@@ -0,0 +1,74 @@
+---
+slug: auth-user-name-semantics
+title: Auth User Name Semantics
+owner: engineering
+collaborators: []
+status: drafting
+priority: P2
+created: 2026-08-22
+target: null
+links:
+  kanban: "[[kanban/engineering]]"
+  designs: null
+---
+
+# Auth User Name Semantics
+
+## Problem
+
+[[features/header-nav-redesign]] made a pre-existing ambiguity newly visible: `AuthUser.name` (and by extension `user.name` everywhere in the frontend) is populated with household/family-style display names ("The Anderson Family", "The Brooks Family", ...) rather than a person's given name. This was silently fine while `user.name` was always rendered in full; the redesign's new avatar+name chip was speced assuming a personal first name existed (`firstName(user.name)`), which broke visibly (the chip read "The" for every account) until reverted to show the full name instead. Three specialists (frontend-dev, qa-engineer, e2e-test-writer) independently flagged this as a real product/data-model question during that feature's build, not just a one-off bug.
+
+## Acceptance criteria
+
+- [ ] A product decision is made and documented: is `AuthUser.name` meant to be a household name, a person's name, or does the schema need a separate field for each?
+- [ ] If a schema/data change is warranted, a migration + DTO update ships
+- [ ] Every frontend surface that currently assumes `user.name` is a person's first name (search for `firstName(` / similar first-token-extraction helpers) is audited against the decision
+
+## Out of scope
+
+- Re-touching `frontend/src/components/Navbar.tsx`'s current behavior (already fixed to show the full name) unless the product decision above requires a further change there too
+
+## Open questions
+
+- Is this actually worth a schema change, or should the product simply commit to "household name, always shown in full" as the intended behavior, and this ticket just documents that decision? (product/dispatcher call)
+
+<!-- The sections below are written by team-leads during dispatch. -->
+
+## Engineering — Acceptance
+
+### Backend
+*(filled by backend-dev)*
+
+### Frontend
+*(filled by frontend-dev)*
+
+### Test plan
+*(filled by qa-engineer)*
+
+### E2E coverage
+*(filled by e2e-test-writer; "No E2E coverage" if the feature is backend-only)*
+
+### Code review
+*(filled by code-reviewer; populated during building → review, not at speccing time)*
+
+## Design — Spec
+
+### Visual
+*(filled by ui-designer)*
+
+### Microcopy
+*(filled by ux-writer)*
+
+### Accessibility
+*(filled by a11y-auditor)*
+
+## Marketing — Spec
+
+### Launch copy
+*(filled by content-writer)*
+
+### SEO
+*(filled by seo-specialist)*
+
+### Growth
+*(filled by growth-analyst)*