docs: comprehensive cleanup and restructuring of project documentation
This commit is contained in:
@@ -1,76 +0,0 @@
|
||||
# TFM aInventory — Project Plan & Roadmap
|
||||
|
||||
**Current Version**: v1.14.22
|
||||
**Status**: MILESTONE 7 SHIPPED | 🟢 PHASE 8 START
|
||||
**Last Updated**: 2026-04-23
|
||||
|
||||
---
|
||||
|
||||
## 1. Project Mission
|
||||
A unified inventory management system that eliminates manual data entry through AI-powered label extraction, works offline in the field, and provides immutable audit trails for enterprise security.
|
||||
|
||||
---
|
||||
|
||||
## 2. Current State (v1.14.22)
|
||||
- **Architecture**: Domain-driven YAML configuration (`config/`).
|
||||
- **Management**: Unified Python management suite (`scripts/`).
|
||||
- **UI Fidelity**: High (Normal weight only, Lucide icons, contextual CTAs).
|
||||
- **Core Engine**: Stable Item CRUD, AI extraction, and PWA offline sync.
|
||||
|
||||
---
|
||||
|
||||
## 3. Active Roadmap
|
||||
|
||||
### Phase 7.1: Frontend UI/UX Overhaul (Industrial Precision) [COMPLETED]
|
||||
- **Design System Integration**: Apply the "Industrial Precision" system from `DESIGN.md`.
|
||||
- **Component Refactoring**: Update all UI components to use sharp corners (0px) and bold borders.
|
||||
- **Color Palette Update**: Implement the high-contrast Caution Orange and tiered black surface system.
|
||||
- **Typography Alignment**: Apply Space Grotesk while strictly adhering to the "NO BOLD" and "NO UPPERCASE" rules from AI_RULES.md.
|
||||
- **Glanceability Optimization**: Increase information density in StatCards and Data Tables.
|
||||
|
||||
### Phase 8: Hardening & Release (PLANNED)
|
||||
- **Production Runbook**: Finalized guide for production deployment.
|
||||
- **Stress Testing**: Verify system performance with 10k+ items and multiple users.
|
||||
- **E2E Validation**: Verify data consistency in multi-page Excel exports.
|
||||
- **Final Polish**: Performance audit and accessibility sweep.
|
||||
|
||||
---
|
||||
|
||||
## 4. Milestone History
|
||||
- [v1.14.22: Config Consolidation & Infrastructure](.planning/milestones/v1.14.22-ROADMAP.md) (2026-04-23)
|
||||
- <details><summary>Previous Phases (Legacy Environment)</summary>
|
||||
|
||||
### Phase 4: Field Validation (COMPLETED ✓)
|
||||
### Phase 5: Core V2 Features (COMPLETED ✓)
|
||||
### Phase 6: Deployment & Scale (COMPLETED ✓)
|
||||
</details>
|
||||
|
||||
---
|
||||
|
||||
## 5. Design & Operational Constraints
|
||||
- **Tech Stack**: FastAPI (Python), SQLite, Next.js (TypeScript), Tailwind CSS.
|
||||
<<<<<<< HEAD
|
||||
- **UI Fidelity**: Premium density, Lucide icons, **NO UPPERCASE**, **NO BOLD FONTS**.
|
||||
- **Security**: Mandatory auth, immutable audit logs.
|
||||
=======
|
||||
- **UI Fidelity**: Premium density, Lucide icons, **NO UPPERCASE**, **NO BOLD FONTS** (normal weight only).
|
||||
- **StatCard Rule**: Numeric values MUST match label text size for balanced density.
|
||||
- **Database**: Single-instance SQLite (WAL mode). Multi-instance is v3+.
|
||||
- **Security**: Mandatory auth, no bypasses, immutable audit logs.
|
||||
- **AI**: Multi-provider resilience (Gemini primary, Claude fallback).
|
||||
|
||||
---
|
||||
|
||||
## 5. Decision Log Summary
|
||||
- **Reset Planning (2026-04-22)**: Refocused on v2 stable release, deferred complex analytics to v3.
|
||||
- **Image Handling (2026-04-22)**: Simplified to rotation-only adjustment; removed complex cropping to improve stability.
|
||||
- **SQLite Choice**: Selected for zero-ops overhead; proven sufficient for 10K item scale.
|
||||
>>>>>>> dev
|
||||
|
||||
---
|
||||
|
||||
## 6. Backlog (V3+)
|
||||
- Advanced analytics & turnover trends.
|
||||
- Multi-warehouse federation.
|
||||
- Localization (Portuguese, Spanish).
|
||||
- Custom field schemas.
|
||||
56
dev_docs/archive/7-UI-REVIEW.md
Normal file
56
dev_docs/archive/7-UI-REVIEW.md
Normal file
@@ -0,0 +1,56 @@
|
||||
# Phase 7 — UI Review
|
||||
|
||||
**Audited:** 2026-04-23
|
||||
**Baseline:** AI_RULES.md & PROJECT_ARCHITECTURE.md
|
||||
**Screenshots:** Captured to `.planning/ui-reviews/07-20260423-160359/`
|
||||
|
||||
## Pillar Scores
|
||||
|
||||
| Pillar | Score | Key Finding |
|
||||
|--------|-------|-------------|
|
||||
| 1. Copywriting | 3/4 | Descriptive labels used ("Discard", "Subtract"), but generic "Cancel" buttons remain. |
|
||||
| 2. Visuals | 4/4 | Excellent adherence to `max-w-7xl` and Lucide icons. Unified headers implemented. |
|
||||
| 3. Color | 4/4 | Good 60/30/10 split. No arbitrary hex codes in UI layers. |
|
||||
| 4. Typography | 2/4 | **CRITICAL:** `globals.css` uses `font-weight: 600` for headers; `font-medium` (500) used in several components. Rule requires `font-normal` (400) only. |
|
||||
| 5. Spacing | 4/4 | Consistent use of responsive `space-y-` and `p-` scales as per architecture. |
|
||||
| 6. Experience Design | 4/4 | Strong sync indicators, loading states, and confirmation safeguards. |
|
||||
|
||||
**Overall Score:** 21/24
|
||||
|
||||
---
|
||||
|
||||
## Detailed Findings
|
||||
|
||||
### Pillar 4: Typography (2/4)
|
||||
- **Violation:** `frontend/app/globals.css:26` defines `h1-h6` with `font-weight: 600`.
|
||||
- **Violation:** `frontend/components/admin/DatabaseManager.tsx:141` and others use `font-medium`.
|
||||
- **Requirement:** AI_RULES.md Section 3 explicitly forbids bold fonts and requires `font-normal` throughout.
|
||||
|
||||
### Pillar 1: Copywriting (3/4)
|
||||
- **Pro:** UI uses descriptive actions: "Force Backup", "Save LDAP Policy", "Subtract 1 from Stock".
|
||||
- **Improvement:** "DELETE" (uppercase) is used in confirmation modals. While good for safety, it technically bypasses the "NO UPPERCASE" rule. Consider using Title Case "Delete" with a specific background color instead.
|
||||
|
||||
### Pillar 2: Visuals (4/4)
|
||||
- **Success:** Main pages correctly utilize `max-w-7xl` with `mx-auto`.
|
||||
- **Success:** Unified headers with icon boxes found in `admin/page.tsx` and `page.tsx`.
|
||||
|
||||
### Pillar 6: Experience Design (4/4)
|
||||
- **Success:** Offline/Online status indicators are prominent and animated.
|
||||
- **Success:** Destructive actions like "Delete Item" and "Logout" utilize `window.confirm` or high-fidelity modals as required.
|
||||
|
||||
---
|
||||
|
||||
### Top 3 Priority Fixes
|
||||
1. **Remove Font Weights** — Remove `font-weight: 600` from `globals.css` (headers) and replace all `font-medium` with `font-normal`. Hierarchy must rely on size and color only.
|
||||
2. **Contextual CTA Labels** — Replace generic "Cancel" and "OK" with contextual verbs (e.g., "Keep Item", "Discard Changes") to improve copywriting fidelity.
|
||||
3. **Focus State Consistency** — Ensure all interactive elements (buttons, inputs) have consistent `focus-visible:ring-2` styling for accessibility.
|
||||
|
||||
---
|
||||
**Files Audited:**
|
||||
- `frontend/app/globals.css`
|
||||
- `frontend/app/page.tsx`
|
||||
- `frontend/app/admin/page.tsx`
|
||||
- `frontend/components/PageShell.tsx`
|
||||
- `frontend/components/admin/DatabaseManager.tsx`
|
||||
- `frontend/components/admin/LdapManager.tsx`
|
||||
---
|
||||
267
dev_docs/archive/COLOR_SYSTEM_ARCHITECTURE.md
Normal file
267
dev_docs/archive/COLOR_SYSTEM_ARCHITECTURE.md
Normal file
@@ -0,0 +1,267 @@
|
||||
# Color System Architecture: Single Source of Truth
|
||||
|
||||
**Status**: ✅ IMPLEMENTED
|
||||
**Commit**: e715afd8
|
||||
**Date**: 2026-04-25
|
||||
|
||||
---
|
||||
|
||||
## Problem Solved
|
||||
|
||||
Color definitions were previously duplicated in two locations:
|
||||
- `frontend/tailwind.config.ts` — Tailwind CSS utility classes (e.g., `bg-primary`)
|
||||
- `frontend/app/globals.css` — CSS custom properties (e.g., `--primary`)
|
||||
|
||||
This created a **DRY violation** where changing a color required edits in 2 places, with high risk of inconsistency.
|
||||
|
||||
---
|
||||
|
||||
## New Architecture
|
||||
|
||||
### 1. Single Source of Truth: `frontend/colors.mjs`
|
||||
|
||||
```javascript
|
||||
// frontend/colors.mjs — The authoritative color definitions
|
||||
export const colors = {
|
||||
background: "#131313",
|
||||
primary: {
|
||||
DEFAULT: "#ffb781",
|
||||
container: "#f58618",
|
||||
// ... all color variants
|
||||
},
|
||||
// ... 40+ colors from DESIGN.md
|
||||
};
|
||||
|
||||
export const spacing = {
|
||||
unit: "4px",
|
||||
"stack-sm": "8px",
|
||||
// ... spacing tokens
|
||||
};
|
||||
```
|
||||
|
||||
**Key Features:**
|
||||
- Pure JavaScript/ESM format for maximum compatibility
|
||||
- Matches DESIGN.md specification exactly
|
||||
- Single file for all color changes
|
||||
- Comment at top: "Changes here automatically propagate to both files"
|
||||
|
||||
---
|
||||
|
||||
### 2. Automated CSS Generation: `frontend/scripts/generate-css-vars.mjs`
|
||||
|
||||
A build-time script that:
|
||||
1. Reads `colors.mjs`
|
||||
2. Flattens nested color objects (e.g., `primary.DEFAULT` → `--primary-DEFAULT`)
|
||||
3. Generates CSS custom properties organized by category
|
||||
4. Injects into `frontend/app/globals.css` `:root` block
|
||||
5. Preserves all other CSS code unchanged
|
||||
|
||||
**Execution:**
|
||||
```bash
|
||||
node frontend/scripts/generate-css-vars.mjs
|
||||
# Output: ✓ Generated CSS variables in globals.css from colors.mjs
|
||||
```
|
||||
|
||||
**Benefits:**
|
||||
- No manual CSS variable maintenance
|
||||
- Always stays in sync with colors.mjs
|
||||
- Runs automatically before every build
|
||||
|
||||
---
|
||||
|
||||
### 3. Import in Tailwind Config: `frontend/tailwind.config.ts`
|
||||
|
||||
```typescript
|
||||
import { colors as colorsDefinition } from "./colors.mjs";
|
||||
|
||||
const config: Config = {
|
||||
theme: {
|
||||
extend: {
|
||||
colors: colorsDefinition, // ← Single import!
|
||||
// ...
|
||||
},
|
||||
},
|
||||
};
|
||||
```
|
||||
|
||||
**Simplification:**
|
||||
- Removed 80+ lines of duplicated color definitions
|
||||
- Now just imports from colors.mjs
|
||||
- Maintains all Tailwind utility classes (`bg-primary`, `text-secondary`, etc.)
|
||||
|
||||
---
|
||||
|
||||
## Build Integration
|
||||
|
||||
### Frontend Build (`frontend/package.json`)
|
||||
|
||||
```json
|
||||
{
|
||||
"scripts": {
|
||||
"generate-css-vars": "node scripts/generate-css-vars.mjs",
|
||||
"dev": "npm run generate-css-vars && next dev",
|
||||
"build": "npm run generate-css-vars && next build"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**Flow:**
|
||||
1. `npm run dev` or `npm run build` executes
|
||||
2. Automatically runs `generate-css-vars` first
|
||||
3. CSS variables synchronized
|
||||
4. Next.js build proceeds
|
||||
|
||||
### Standalone Deployment (`start_servers.py`)
|
||||
|
||||
```python
|
||||
def setup_frontend(self):
|
||||
# Generate CSS variables from colors.mjs before building
|
||||
self.log("Generating CSS variables from design system...")
|
||||
result = subprocess.run(
|
||||
["node", "scripts/generate-css-vars.mjs"],
|
||||
cwd=str(frontend_dir),
|
||||
capture_output=True
|
||||
)
|
||||
# Then proceed with npm run build
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Workflow: Changing Colors
|
||||
|
||||
**Before (2 files, high risk):**
|
||||
1. Edit hex in `tailwind.config.ts` line 42
|
||||
2. Edit hex in `globals.css` line 26
|
||||
3. Risk: Forget one file, colors diverge
|
||||
4. Build has no validation
|
||||
|
||||
**After (1 file, zero risk):**
|
||||
1. Edit `colors.mjs` (one location)
|
||||
2. Run `npm run build`
|
||||
3. Script auto-generates both Tailwind colors and CSS variables
|
||||
4. No manual sync needed
|
||||
|
||||
**Example:**
|
||||
```javascript
|
||||
// colors.mjs
|
||||
export const colors = {
|
||||
primary: {
|
||||
DEFAULT: "#ffb781", // ← Change here
|
||||
// ...
|
||||
},
|
||||
};
|
||||
```
|
||||
|
||||
Then:
|
||||
- ✅ `npm run build` auto-generates CSS variables
|
||||
- ✅ tailwind.config.ts already imports from colors.mjs
|
||||
- ✅ Both systems use exact same value
|
||||
- ✅ Zero inconsistency
|
||||
|
||||
---
|
||||
|
||||
## CSS Variable Categories
|
||||
|
||||
Generated variables are organized by category in `:root`:
|
||||
|
||||
```css
|
||||
/* Base colors from DESIGN.md */
|
||||
--background: #131313;
|
||||
--on-background: #e5e2e1;
|
||||
|
||||
/* Surface colors from DESIGN.md */
|
||||
--surface-DEFAULT: #131313;
|
||||
--surface-dim: #131313;
|
||||
/* ... 8 more surface variants */
|
||||
|
||||
/* Primary colors from DESIGN.md */
|
||||
--primary-DEFAULT: #ffb781;
|
||||
--primary-container: #f58618;
|
||||
/* ... 7 more primary variants */
|
||||
|
||||
/* Secondary, Tertiary, Error colors... */
|
||||
|
||||
/* Semantic spacing tokens */
|
||||
--spacing-unit: 4px;
|
||||
--spacing-gutter: 16px;
|
||||
/* ... more spacing */
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Design System Compliance
|
||||
|
||||
All colors from `DESIGN.md` are now represented:
|
||||
|
||||
| Category | Count | Source |
|
||||
|----------|-------|--------|
|
||||
| Primary variants | 9 | colors.mjs |
|
||||
| Secondary variants | 8 | colors.mjs |
|
||||
| Tertiary variants | 8 | colors.mjs |
|
||||
| Surface variants | 9 | colors.mjs |
|
||||
| Error variants | 4 | colors.mjs |
|
||||
| Outline/Inverse/Semantic | 7 | colors.mjs |
|
||||
| **Total** | **45** | **Single file** |
|
||||
|
||||
---
|
||||
|
||||
## Build Verification
|
||||
|
||||
```
|
||||
✅ CSS generation: Completes successfully
|
||||
✅ Next.js compile: 5.7s with 0 errors
|
||||
✅ CSS validation: 0 warnings
|
||||
✅ TypeScript: Strict mode, 0 issues
|
||||
✅ All pages: 8/8 generated
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Future Maintenance
|
||||
|
||||
**If colors need updating:**
|
||||
1. Edit `frontend/colors.mjs`
|
||||
2. Run `npm run build` (auto-syncs everything)
|
||||
3. Done!
|
||||
|
||||
**No need to:**
|
||||
- Edit tailwind.config.ts
|
||||
- Edit globals.css
|
||||
- Manually synchronize values
|
||||
- Worry about inconsistency
|
||||
|
||||
---
|
||||
|
||||
## Files Changed
|
||||
|
||||
| File | Change | Status |
|
||||
|------|--------|--------|
|
||||
| `frontend/colors.mjs` | Created | ✅ New SSOT |
|
||||
| `frontend/scripts/generate-css-vars.mjs` | Created | ✅ Auto build step |
|
||||
| `frontend/tailwind.config.ts` | Updated | ✅ Imports from colors.mjs |
|
||||
| `frontend/package.json` | Updated | ✅ Added generate-css-vars script |
|
||||
| `start_servers.py` | Updated | ✅ Runs generate step |
|
||||
| `frontend/app/globals.css` | Generated | ✅ Auto-synced on build |
|
||||
|
||||
---
|
||||
|
||||
## Command Reference
|
||||
|
||||
```bash
|
||||
# One-time generate CSS variables
|
||||
npm run generate-css-vars
|
||||
|
||||
# Development mode (auto-generates on startup)
|
||||
npm run dev
|
||||
|
||||
# Production build (auto-generates before build)
|
||||
npm run build
|
||||
|
||||
# Standalone deployment (auto-generates before build)
|
||||
python3 start_servers.py
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
**Implemented by:** Claude Haiku 4.5
|
||||
**Architecture Decision:** Consolidate to single source of truth with automated CSS generation
|
||||
228
dev_docs/archive/DESIGN-TYPOGRAPHY-HIERARCHY.md
Normal file
228
dev_docs/archive/DESIGN-TYPOGRAPHY-HIERARCHY.md
Normal file
@@ -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
|
||||
<span className="text-lg text-secondary">Item Name</span>
|
||||
<span className="text-lg text-muted">Category</span>
|
||||
|
||||
// NEW: Clear hierarchy
|
||||
<span className="text-lg md:text-xl font-bold text-white">Item Name</span>
|
||||
<span className="text-sm md:text-base font-normal text-muted">Category</span>
|
||||
```
|
||||
|
||||
**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.
|
||||
0
dev_docs/archive/DESIGN_AUDIT_2026-04-25.md
Normal file
0
dev_docs/archive/DESIGN_AUDIT_2026-04-25.md
Normal file
328
dev_docs/archive/DESIGN_COLOR_RULES.md
Normal file
328
dev_docs/archive/DESIGN_COLOR_RULES.md
Normal file
@@ -0,0 +1,328 @@
|
||||
# Design System Color Rules - MANDATORY FOR ALL UI/UX
|
||||
|
||||
**Status:** ACTIVE | **Effective:** 2026-04-25
|
||||
**Owner:** AI Development Team | **Audience:** All Frontend Developers/AI Agents
|
||||
|
||||
> ⚠️ **CRITICAL RULE:** No hardcoded Tailwind colors are permitted. All UI colors MUST come from `DESIGN.md` color system via tailwind.config.ts or globals.css.
|
||||
|
||||
---
|
||||
|
||||
## THE RULE
|
||||
|
||||
**NEVER use arbitrary Tailwind colors like:**
|
||||
- ❌ `bg-green-500`, `text-green-400`
|
||||
- ❌ `bg-red-600`, `text-rose-500`
|
||||
- ❌ `bg-blue-500`, `text-indigo-400`
|
||||
- ❌ `bg-amber-500`, `bg-yellow-400`
|
||||
- ❌ `bg-sky-500`, `text-cyan-400`
|
||||
- ❌ Any other standard Tailwind color names
|
||||
|
||||
**ALWAYS use semantic colors from DESIGN.md:**
|
||||
- ✅ `bg-primary`, `text-primary`
|
||||
- ✅ `bg-secondary`, `text-secondary`
|
||||
- ✅ `bg-tertiary`, `text-tertiary` (for success/healthy states)
|
||||
- ✅ `bg-error`, `text-error`
|
||||
- ✅ `bg-success`, `text-success`
|
||||
- ✅ `bg-warning`, `text-warning`
|
||||
- ✅ `bg-muted`, `text-muted`
|
||||
- ✅ `border-outline`, `border-outline-variant`
|
||||
|
||||
---
|
||||
|
||||
## SEMANTIC COLOR MAPPING
|
||||
|
||||
Use these mappings for ALL UI decisions:
|
||||
|
||||
### **Status Indicators**
|
||||
| Intent | Color | Value | Use Case |
|
||||
|--------|-------|-------|----------|
|
||||
| ✅ Success / Healthy | `tertiary` | #00e639 | "Scanner Ready", quantity +, check-in, online status |
|
||||
| ❌ Error / Destructive | `error` | #ffb4ab | "Delete item", errors, low stock, offline |
|
||||
| ⚠️ Warning / Caution | `primary` | #ffb781 | "Caution Orange", warnings, important actions |
|
||||
| ℹ️ Info / Secondary | `secondary` | #c8c6c5 | Secondary actions, hints, disabled text |
|
||||
| 🔇 Muted / Disabled | `muted` | #474746 | Disabled buttons, placeholder text |
|
||||
|
||||
### **Action Elements**
|
||||
| Element | Color | Example |
|
||||
|---------|-------|---------|
|
||||
| Primary Button | `bg-primary` | "Extract Data", "Create", "Upload" |
|
||||
| Secondary Button | `bg-secondary` | "Cancel", alternative actions |
|
||||
| Destructive Button | `bg-error` | "Delete Item", "Discard", "Remove" |
|
||||
| Button Hover | `hover:opacity-80` | Darken any button on hover |
|
||||
| Button Focus Ring | `focus:ring-{color}` | Use same color as button |
|
||||
|
||||
### **Data Visualization**
|
||||
| Data Type | Color | Context |
|
||||
|-----------|-------|---------|
|
||||
| Quantity Increased | `text-tertiary` | Stock added, items received |
|
||||
| Quantity Decreased | `text-error` | Stock removed, items shipped |
|
||||
| Neutral Change | `text-primary/50` | Muted primary |
|
||||
| Negative Status | `text-error` | Low stock, missing items |
|
||||
| Positive Status | `text-tertiary` | Available, in stock |
|
||||
|
||||
### **Action Log Colors**
|
||||
| Action Type | Color | Rationale |
|
||||
|------------|-------|-----------|
|
||||
| CHECK_IN (receive) | `tertiary` | Success/positive action |
|
||||
| DELETE | `error` | Destructive action |
|
||||
| TRASH/DISCARD | `error` | Destructive action |
|
||||
| CREATE | `primary` | Primary/caution action |
|
||||
| DB (database) | `secondary` | System/info action |
|
||||
| REMOVE | `primary` | Warning/caution |
|
||||
|
||||
---
|
||||
|
||||
## TECHNICAL IMPLEMENTATION
|
||||
|
||||
### ✅ CORRECT Examples
|
||||
|
||||
```tsx
|
||||
// Status indicator - success
|
||||
<div className="w-2 h-2 bg-tertiary animate-pulse" />
|
||||
<span className="text-tertiary">Scanner: Ready</span>
|
||||
|
||||
// Destructive button
|
||||
<button className="bg-error hover:opacity-80 focus:ring-error">
|
||||
Delete Item
|
||||
</button>
|
||||
|
||||
// Data change - quantity increased
|
||||
<span className={log.quantity_change > 0 ? "text-tertiary" : "text-error"}>
|
||||
{log.quantity_change}
|
||||
</span>
|
||||
|
||||
// Conditional logic using design system
|
||||
className={`
|
||||
${item.quantity <= minQty ? "text-error" : "text-primary"}
|
||||
${isOnline ? "bg-tertiary" : "bg-error"}
|
||||
focus:ring-${isDestructive ? "error" : "primary"}
|
||||
`}
|
||||
|
||||
// From globals.css variables
|
||||
const statusColor = {
|
||||
"success": "var(--tertiary)",
|
||||
"error": "var(--error)",
|
||||
"warning": "var(--primary)"
|
||||
}
|
||||
```
|
||||
|
||||
### ❌ WRONG Examples (DO NOT USE)
|
||||
|
||||
```tsx
|
||||
// ❌ Hardcoded arbitrary colors
|
||||
<div className="w-2 h-2 bg-green-500 animate-pulse" />
|
||||
<button className="bg-red-600 hover:bg-red-700">Delete</button>
|
||||
|
||||
// ❌ Arbitrary Tailwind color names
|
||||
className="text-amber-500 bg-indigo-500/10 border border-rose-500/20"
|
||||
|
||||
// ❌ Hex colors in className
|
||||
className="bg-[#4b0082] text-[#ff6b6b]"
|
||||
|
||||
// ❌ Mixing design system with arbitrary colors
|
||||
className="bg-primary hover:bg-green-500 text-error"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## COLOR AVAILABILITY IN TAILWIND
|
||||
|
||||
All DESIGN.md colors are available in `tailwind.config.ts`:
|
||||
|
||||
```typescript
|
||||
// frontend/tailwind.config.ts - ALREADY CONFIGURED
|
||||
colors: {
|
||||
primary: { DEFAULT: "#ffb781", foreground: "#4e2600", ... },
|
||||
secondary: { DEFAULT: "#c8c6c5", foreground: "#303030", ... },
|
||||
tertiary: { DEFAULT: "#00e639", foreground: "#003907", ... },
|
||||
error: { DEFAULT: "#ffb4ab", foreground: "#690005", ... },
|
||||
success: { DEFAULT: "#00e639", foreground: "#003907" },
|
||||
warning: "#ffb781",
|
||||
muted: { DEFAULT: "#474746", foreground: "#a48c7c" },
|
||||
outline: "#a48c7c",
|
||||
"outline-variant": "#564335",
|
||||
// ... all surface, border, background colors
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## CSS VARIABLES (globals.css)
|
||||
|
||||
For custom CSS or dynamic color assignment:
|
||||
|
||||
```css
|
||||
/* All available in :root */
|
||||
--primary: #ffb781;
|
||||
--secondary: #c8c6c5;
|
||||
--tertiary: #00e639;
|
||||
--error: #ffb4ab;
|
||||
--on-error: #690005;
|
||||
--error-container: #93000a;
|
||||
--on-error-container: #ffdad6;
|
||||
--muted: #474746;
|
||||
--outline: #a48c7c;
|
||||
--outline-variant: #564335;
|
||||
/* ... 50+ more */
|
||||
```
|
||||
|
||||
```tsx
|
||||
// Usage in React
|
||||
const statusColor = `var(--${isError ? 'error' : 'tertiary'})`
|
||||
<div style={{ color: statusColor }} />
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## ENFORCEMENT RULES FOR AI AGENTS
|
||||
|
||||
**BEFORE writing any color-related code:**
|
||||
|
||||
1. ✅ **Check DESIGN.md** for the semantic intent
|
||||
2. ✅ **Map intent to color** using the Semantic Color Mapping table above
|
||||
3. ✅ **Use design system color** from tailwind.config.ts
|
||||
4. ✅ **Reference this file** if uncertain about color choice
|
||||
5. ❌ **Never** use `bg-green`, `text-red`, `border-blue`, etc.
|
||||
|
||||
**During code review:**
|
||||
- ❌ Flag any hardcoded Tailwind colors (green-*, red-*, blue-*, etc.)
|
||||
- ✅ Require fixes before merge
|
||||
|
||||
---
|
||||
|
||||
## 🔒 MANDATORY: All Color Definition Changes → `frontend/colors.mjs` ONLY
|
||||
|
||||
**SINGLE SOURCE OF TRUTH RULE (Updated 2026-04-25):**
|
||||
|
||||
When adding, updating, or modifying ANY color from DESIGN.md:
|
||||
|
||||
### ✅ CORRECT WORKFLOW:
|
||||
1. Edit ONLY: `frontend/colors.mjs` (the authoritative color source)
|
||||
2. Update the color definition in the `colors` export object
|
||||
3. Run: `npm run build` or `npm run dev`
|
||||
4. Build script AUTOMATICALLY:
|
||||
- Generates CSS variables in `globals.css` `:root`
|
||||
- Syncs with `tailwind.config.ts` (which imports from colors.mjs)
|
||||
- Zero manual sync required
|
||||
|
||||
### ❌ INCORRECT WORKFLOWS (DO NOT DO):
|
||||
- ❌ Editing `tailwind.config.ts` color definitions directly
|
||||
- ❌ Manually adding CSS variables to `globals.css`
|
||||
- ❌ Updating colors in multiple files
|
||||
- ❌ Assuming changes in one file will propagate to another
|
||||
|
||||
### Why This Matters:
|
||||
| Before | After (colors.mjs SSOT) |
|
||||
|--------|------------------------|
|
||||
| 2 files to edit | 1 file (colors.mjs) |
|
||||
| High sync risk | Zero sync risk |
|
||||
| Manual duplication | Auto-generated |
|
||||
| Easy to break | Build validates |
|
||||
|
||||
### Example: Adding a New Color Variant
|
||||
```javascript
|
||||
// ✅ CORRECT: Edit frontend/colors.mjs ONLY
|
||||
export const colors = {
|
||||
primary: {
|
||||
DEFAULT: "#ffb781",
|
||||
// ← Add new variant here
|
||||
"subtle": "#f5c5a3", // ← NEW
|
||||
},
|
||||
};
|
||||
|
||||
// Then: npm run build
|
||||
// Result: Automatic sync to all systems
|
||||
```
|
||||
|
||||
### Reference Documentation:
|
||||
- **CLAUDE.md** — Mandatory rule entry point
|
||||
- **COLOR_SYSTEM_ARCHITECTURE.md** — Technical implementation details
|
||||
- **colors.mjs** — The authoritative source (keep comments updated)
|
||||
- ✅ Reference DESIGN_COLOR_RULES.md in comments
|
||||
|
||||
**For TypeScript/Linting:**
|
||||
Add to `.eslintrc.json` if possible:
|
||||
```json
|
||||
{
|
||||
"rules": {
|
||||
"no-restricted-syntax": [
|
||||
"error",
|
||||
{
|
||||
"selector": "CallExpression[callee.name='className'][arguments.0.value=/bg-(green|red|blue|amber|sky|rose|indigo|emerald|cyan|purple|pink)/]",
|
||||
"message": "Use DESIGN.md colors (primary, secondary, tertiary, error) instead of arbitrary Tailwind colors"
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## EXCEPTION CASES (VERY RARE)
|
||||
|
||||
**Only use arbitrary colors for:**
|
||||
1. **Third-party libraries** (e.g., vitest UI, dev tools) - in node_modules only
|
||||
2. **Debug/Development tools** - prefixed with `// debug-only`
|
||||
3. **Dynamic user themes** - explicitly documented with reason
|
||||
|
||||
**If you encounter a design need NOT covered by DESIGN.md colors:**
|
||||
- ❌ Do NOT use arbitrary Tailwind colors
|
||||
- ✅ Request new color be added to DESIGN.md
|
||||
- ✅ Create GitHub issue with screenshot and use case
|
||||
- ✅ Await approval before implementing
|
||||
|
||||
---
|
||||
|
||||
## CHECKLIST FOR NEW FEATURES
|
||||
|
||||
Before writing UI code, answer:
|
||||
|
||||
- [ ] Have I read DESIGN.md colors section?
|
||||
- [ ] Have I reviewed the Semantic Color Mapping in this file?
|
||||
- [ ] Have I identified the intent: success/error/warning/info?
|
||||
- [ ] Have I used the correct semantic color from design system?
|
||||
- [ ] Have I avoided ALL arbitrary Tailwind colors (green-*, red-*, etc.)?
|
||||
- [ ] Have I tested the color contrast meets WCAG AA (7:1 ratio)?
|
||||
- [ ] Have I verified the color looks correct on both light and dark surfaces?
|
||||
|
||||
---
|
||||
|
||||
## QUICK REFERENCE
|
||||
|
||||
**If you need to color something:**
|
||||
|
||||
```
|
||||
Status = Success/Healthy? → Use tertiary (#00e639)
|
||||
Status = Error/Failed? → Use error (#ffb4ab)
|
||||
Action = Warning/Caution? → Use primary (#ffb781)
|
||||
Action = Secondary/Info? → Use secondary (#c8c6c5)
|
||||
Text = Muted/Disabled? → Use muted (#474746)
|
||||
Border = Regular? → Use outline (#a48c7c)
|
||||
Border = Subtle variant? → Use outline-variant (#564335)
|
||||
Data change = Increase/Positive? → Use tertiary
|
||||
Data change = Decrease/Negative? → Use error
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## RELATED DOCUMENTS
|
||||
|
||||
- 📋 **DESIGN.md** - Full color palette, typography, spacing rules
|
||||
- 📋 **DESIGN_COMPLIANCE_FIX_PLAN.md** - Detailed fix plan for all hardcoded colors
|
||||
- 📋 **AI_RULES.md** - Section 3: UI/UX Premium Fidelity Standards
|
||||
- 📋 **PROJECT_ARCHITECTURE.md** - Section 2.2: Styling specification
|
||||
|
||||
---
|
||||
|
||||
## VERSION HISTORY
|
||||
|
||||
| Date | Change | Author |
|
||||
|------|--------|--------|
|
||||
| 2026-04-25 | Created rule document | AI Development Team |
|
||||
| 2026-04-25 | Fixed 44+ hardcoded colors | Phase 8 Remediation |
|
||||
|
||||
---
|
||||
|
||||
**Last Reviewed:** 2026-04-25
|
||||
**Next Review:** 2026-05-25
|
||||
**Owner:** AI Development Team
|
||||
Reference in New Issue
Block a user