diff --git a/.claude/settings.local.json b/.claude/settings.local.json
index e3cd0f1a..4fb5b33c 100644
--- a/.claude/settings.local.json
+++ b/.claude/settings.local.json
@@ -68,7 +68,9 @@
"Bash(sed -i -e 's/\\\\btext-slate-100\\\\b/text-secondary/g' -e s/placeholder:text-slate-700/placeholder:text-muted/g -e s/hover:text-slate-300/hover:text-secondary/g app/page.tsx)",
"Bash(sed -i 's/\\\\btext-slate-300\\\\b/text-secondary/g' app/page.tsx)",
"Bash(npx tsc *)",
- "Bash(python -m pytest backend/tests/ -q)"
+ "Bash(python -m pytest backend/tests/ -q)",
+ "Bash(chmod +x /tmp/update_fonts.sh)",
+ "Bash(/tmp/update_fonts.sh)"
]
}
}
diff --git a/DESIGN-TYPOGRAPHY-HIERARCHY.md b/DESIGN-TYPOGRAPHY-HIERARCHY.md
new file mode 100644
index 00000000..06efa3af
--- /dev/null
+++ b/DESIGN-TYPOGRAPHY-HIERARCHY.md
@@ -0,0 +1,228 @@
+# Design: Typography & Visual Hierarchy Overhaul
+
+Generated by /gstack-office-hours on 2026-04-19
+Branch: dev
+Repo: tfm_ainventory
+Status: DRAFT
+Mode: Builder (Intrapreneurship)
+
+## Problem Statement
+
+The current UI has weak visual hierarchy on tablets and larger screens. While fonts are technically readable, they don't guide the eye — secondary info competes with primary info for attention. Users are forced to hunt for the information they need rather than seeing it immediately.
+
+**Example:** Inventory item name (what you're looking for) is `text-base md:text-lg` (18px). The category label next to it is almost the same size. Which is more important? The UI doesn't say.
+
+## Current State
+
+**Typography scale (Tailwind defaults):**
+- Labels/metadata: `text-xs` to `text-base` (12–16px)
+- Headings: `text-lg` to `text-xl` (18–20px)
+- Values/highlights: `text-2xl` to `text-3xl` (24–30px)
+- Page titles: `text-3xl` to `text-4xl` (30–36px)
+
+**Problem:** This scale flattens on tablets. A 18px label looks like a headline. A 30px value looks like a label. The hierarchy collapses.
+
+## Premises
+
+1. **Font size alone doesn't create hierarchy.** Weight, color, spacing, and contrast matter more than raw pixels.
+2. **Tablet is a first-class device.** The app is used on iPads in warehouses. Design for that, not just mobile.
+3. **Visual hierarchy = faster task completion.** If the user sees the item quantity immediately, they spend 0.5 seconds scanning. If they hunt, it's 3 seconds per item. Over 100 items, that's 4 minutes lost per session.
+4. **We don't need bigger type everywhere.** Secondary info can stay small IF it's visually subordinate (lighter weight, muted color, less prominence).
+
+## Open Questions
+
+- What's the primary use case breakdown? Mostly mobile in the field, mostly tablet in warehouse, or mixed 50/50?
+- Do users ever need to scan and read fine details simultaneously (e.g., zoom control labels)?
+- Is there a standard tablet size we're optimizing for (iPad 10.2", iPad Pro 12.9", or both)?
+
+## Approaches Considered
+
+### Approach A: Scale Everything Proportionally (Simplest)
+
+**Summary:** Increase base font sizes across all Tailwind scales uniformly. `text-base` → `text-lg`, `text-lg` → `text-xl`, etc. On tablets, everything gets bigger, hierarchy stays the same.
+
+**Effort:** S (one config change to tailwind.config.ts, maybe 15 min)
+
+**Risk:** Low
+
+**Pros:**
+- One-line fix in Tailwind config
+- Consistent everywhere
+- Easiest to test and verify
+- No refactoring needed
+
+**Cons:**
+- Doesn't actually improve hierarchy — just makes things bigger
+- Wasteful on mobile (text gets huge, less content per screen)
+- Doesn't address the real problem: weak contrast between important and unimportant info
+- Secondary info still competes for attention, just in a bigger font
+
+**Reuses:** Tailwind's built-in scale
+
+**Implementation:** Extend `fontSize` in tailwind.config.ts:
+```javascript
+extend: {
+ fontSize: {
+ 'xs': '14px', // was 12px
+ 'sm': '15px', // was 14px
+ 'base': '18px', // was 16px
+ 'lg': '21px', // was 18px
+ // ... etc
+ }
+}
+```
+
+---
+
+### Approach B: Responsive Scale + Weight-Based Hierarchy (Recommended)
+
+**Summary:** Keep mobile readable, boost tablet sizes moderately. More importantly, use **font weight** (not just size) to create hierarchy. Primary info is bold/heavy; secondary is regular/light. Add color emphasis (primary color for key values).
+
+**Effort:** M (audit components for hierarchy, add weight/color rules, test on device, ~2 hours)
+
+**Risk:** Medium (changes visual feel, needs design review)
+
+**Pros:**
+- Mobile stays readable (no bloat)
+- Tablets get 20-30% bigger type
+- Weight creates REAL hierarchy instantly (user's eye goes to bold text)
+- Pairs with color (key values in primary color, metadata in muted gray)
+- Feels intentional, not lazy
+- Works across all screen sizes
+
+**Cons:**
+- Requires auditing every component (20+ files)
+- Needs design review to ensure consistency
+- More moving parts to get right
+- Testing on actual tablets essential
+
+**Reuses:** Tailwind's weight classes, existing color system
+
+**Implementation Pattern:**
+```jsx
+// OLD: No hierarchy
+Item Name
+Category
+
+// NEW: Clear hierarchy
+Item Name
+Category
+```
+
+**Tablet-specific rules:** Add responsive weights:
+```javascript
+extend: {
+ fontSize: {
+ 'sm': ['14px', { lineHeight: '1.5' }],
+ 'base': ['16px', { lineHeight: '1.6' }],
+ 'lg': ['18px', { lineHeight: '1.6' }],
+ 'xl': ['20px', { lineHeight: '1.5' }],
+ }
+}
+```
+
+---
+
+### Approach C: Fluid Typography + Dynamic Scaling (Future-proof)
+
+**Summary:** Use CSS custom properties (variables) to scale type fluidly from mobile → tablet → desktop. Type size increases as viewport width increases, without discrete breakpoints. Add hierarchy through weight, spacing, and contrast.
+
+**Effort:** L (requires CSS architecture change, build TypeScript scale generator, test thoroughly, ~4 hours)
+
+**Risk:** High (new tooling, requires testing on 3+ device sizes)
+
+**Pros:**
+- Scales beautifully on ALL viewport sizes (not just mobile/md/lg breakpoints)
+- Future-proof (works on foldables, 5" phones, 27" displays)
+- Hierarchy through weight + color, not just size
+- Professional feel (type gets more generous as screen gets bigger)
+- One source of truth (single scale definition)
+
+**Cons:**
+- Adds build-time complexity (need a script to generate scales)
+- CSS custom properties have limited browser support (but fine for modern browsers)
+- More moving parts, harder to debug
+- Needs comprehensive testing
+- Overkill if app is only mobile + tablet
+
+**Reuses:** Tailwind, but adds custom CSS layer
+
+**Implementation idea:**
+```css
+/* Define fluid scale as CSS variables */
+:root {
+ /* At 375px (mobile), base = 16px. At 1440px (desktop), base = 18px. */
+ --font-base: clamp(16px, 2.5vw, 18px);
+ --font-lg: clamp(18px, 3vw, 20px);
+ --font-xl: clamp(20px, 3.5vw, 24px);
+}
+
+/* Use in components */
+.text-base { font-size: var(--font-base); }
+.text-lg { font-size: var(--font-lg); }
+.text-xl { font-size: var(--font-xl); }
+```
+
+---
+
+## Recommended Approach: B (Responsive Scale + Weight-Based Hierarchy)
+
+**Why:**
+- Solves the real problem (hierarchy, not just size)
+- Effort-to-impact ratio is excellent
+- Works across all devices without bloat
+- Uses tools already in the design system
+- Reviewable component-by-component (low risk of breaking things)
+
+**Concrete next step:**
+1. Audit InventoryTable, StatCard, LogsTable, Scanner controls for hierarchy
+2. Add weight rules: primary data `font-bold`, metadata `font-normal`
+3. Add color: primary values in `text-primary` or `text-white`, secondary in `text-muted`
+4. Test on iPad (actual device or browser dev tools)
+5. Review with user on actual tablet to verify readability
+
+---
+
+## Success Criteria
+
+- **Tablet test (10.2" iPad):** User can read item names, quantities, and key metadata without squinting at normal viewing distance (12-18 inches)
+- **Hierarchy test:** In a list of 20 items, user can identify which is the primary info (name/quantity) in <1 second without searching
+- **Mobile preservation:** iPhone 14 screen still shows useful content (no excessive whitespace)
+- **Consistency:** Same typography rules applied across Scanner, Inventory, Admin, Logs pages
+
+---
+
+## Distribution Plan
+
+No new dependencies or build system changes (unless Approach C chosen).
+Changes ship in the existing `dev` branch → `master` on next release.
+
+---
+
+## Dependencies
+
+- Tailwind CSS (already in use)
+- Design review from user on tablet device (essential)
+- Testing across: iPhone 12+, iPad 10.2", iPad Pro 12.9" (ideally)
+
+---
+
+## The Assignment
+
+**Before next office hours:**
+1. Load the app on an actual tablet (iPad or comparable).
+2. Open the Inventory page, Scanner page, and Admin Dashboard.
+3. Note 3 specific screens or components where you think hierarchy is weakest (e.g., "StatCard mixes label and value with equal prominence").
+4. Bring those examples to the next session — we'll design the weight/color fixes together with visual mockups.
+
+This turns abstract ("fonts are small") into concrete ("here's where I get lost").
+
+---
+
+## What I Noticed About How You Think
+
+- You didn't say "make fonts bigger" — you said "better visual hierarchy." That's a designer's instinct, not an engineer's kneejerk response. You're thinking about information clarity, not pixel counts.
+- You identified the problem on tablets specifically, not mobile. That's precise observation. Most people would have said "everywhere," but you know your actual use case.
+- When asked what success looks like, you said hierarchy, not size. That shows you understand that **hierarchy IS the usability feature.** Big text that's all the same weight is just... big, hard-to-read text.
+
+You're thinking like a product person. Keep that going.
diff --git a/frontend/app/admin/page.tsx b/frontend/app/admin/page.tsx
index 21f452db..57255261 100644
--- a/frontend/app/admin/page.tsx
+++ b/frontend/app/admin/page.tsx
@@ -27,16 +27,16 @@ export default function AdminPage() {
-