Demo Seed Scripts:
- Updated seed_demo_purchase_orders.py to use structured reasoning_data
* Imports create_po_reasoning_low_stock and create_po_reasoning_supplier_contract
* Generates reasoning_data with product names, stock levels, and consequences
* Removed deprecated reasoning/consequence TEXT fields
- Updated seed_demo_batches.py to use structured reasoning_data
* Imports create_batch_reasoning_forecast_demand and create_batch_reasoning_regular_schedule
* Generates intelligent reasoning based on batch priority and AI assistance
* Adds reasoning_data to all production batches
Backend Services - Error Code Implementation:
- Updated safety_stock_calculator.py with error codes
* Replaced "Lead time or demand std dev is zero or negative" with ERROR:LEAD_TIME_INVALID
* Replaced "Insufficient historical demand data" with ERROR:INSUFFICIENT_DATA
- Updated replenishment_planning_service.py with error codes
* Replaced "Insufficient data for safety stock calculation" with ERROR:INSUFFICIENT_DATA
* Frontend can now translate error codes using i18n
Demo data will now display with translatable reasoning in EN/ES/EU languages.
Backend services return error codes that frontend translates for user's language.
- Updated TypeScript types to support reasoning_data field
- Integrated useReasoningTranslation hook in all dashboard components:
* ActionQueueCard: Translates PO reasoning_data and UI text
* ProductionTimelineCard: Translates batch reasoning_data and UI text
* OrchestrationSummaryCard: Translates all hardcoded English text
* HealthStatusCard: Translates all hardcoded English text
- Added missing translation keys to all language files (EN, ES, EU):
* health_status: never, critical_issues, actions_needed
* action_queue: total, critical, important
* orchestration_summary: ready_to_plan, run_info, took, show_more/less
* production_timeline: Complete rebuild with new keys
- Components now support fallback for deprecated text fields
- Full multilingual support: English, Spanish, Basque
Dashboard is now fully translatable and will display reasoning in user's language.
Created comprehensive multilingual translation system for JTBD dashboard
reasoning fields. Backend generates structured data, frontend translates
using i18n in EN, ES, and EU (Euskara).
Frontend Changes:
1. Created reasoning.json translation files (EN, ES, EU)
- Purchase order reasoning types
- Production batch reasoning types
- Consequence translations
- Severity levels
- Error codes
- All JTBD dashboard UI text
2. Created useReasoningTranslation hook
- translatePOReasonng() - For purchase orders
- translateBatchReasoning() - For production batches
- translateConsequence() - For consequences
- translateSeverity() - For severity levels
- translateError() - For error codes
- useReasoningFormatter() - Higher-level formatting
Translation Examples:
EN: "Low stock for Harinas del Norte. Stock runs out in 3 days."
ES: "Stock bajo para Harinas del Norte. Se agota en 3 días."
EU: "Harinas del Norte-rentzat stock baxua. 3 egunetan amaituko da."
Documentation:
- Created REASONING_I18N_AUDIT.md with full audit of hardcoded text
- Identified all files needing updates
- Documented strategy for backend error codes
Next Steps:
- Update dashboard components to use translations
- Fix demo seed scripts
- Fix backend services to return error codes
Completed the migration to structured reasoning_data for multilingual
dashboard support. Removed hardcoded TEXT fields (reasoning, consequence)
and updated all related code to use JSONB reasoning_data.
Changes:
1. Models Updated (removed TEXT fields):
- PurchaseOrder: Removed reasoning, consequence TEXT columns
- ProductionBatch: Removed reasoning TEXT column
- Both now use only reasoning_data (JSONB/JSON)
2. Dashboard Service Updated:
- Changed to return reasoning_data instead of TEXT fields
- Creates default reasoning_data if missing
- PO actions: reasoning_data with type and parameters
- Production timeline: reasoning_data for each batch
3. Unified Schemas Updated (no separate migration):
- services/procurement/migrations/001_unified_initial_schema.py
- services/production/migrations/001_unified_initial_schema.py
- Removed reasoning/consequence columns from table definitions
- Updated comments to reflect i18n approach
Database Schema:
- purchase_orders: Only reasoning_data (JSONB)
- production_batches: Only reasoning_data (JSON)
Backend now generates:
{
"type": "low_stock_detection",
"parameters": {
"supplier_name": "Harinas del Norte",
"days_until_stockout": 3,
...
},
"consequence": {
"type": "stockout_risk",
"severity": "high"
}
}
Next Steps:
- Frontend: Create i18n translation keys
- Frontend: Update components to translate reasoning_data
- Test multilingual support (ES, EN, CA)
Implemented proper reasoning data generation for purchase orders and
production batches to enable multilingual dashboard support.
Backend Strategy:
- Generate structured JSON with type codes and parameters
- Store only reasoning_data (JSONB), not hardcoded text
- Frontend will translate using i18n libraries
Changes:
1. Created shared/schemas/reasoning_types.py
- Defined reasoning types for POs and batches
- Created helper functions for common reasoning patterns
- Supports multiple reasoning types (low_stock, forecast_demand, etc.)
2. Production Service (services/production/app/services/production_service.py)
- Generate reasoning_data when creating batches from forecast
- Include parameters: product_name, predicted_demand, current_stock, etc.
- Structure supports frontend i18n interpolation
3. Procurement Service (services/procurement/app/services/procurement_service.py)
- Implemented actual PO creation (was placeholder before!)
- Groups requirements by supplier
- Generates reasoning_data based on context (low_stock vs forecast)
- Creates PO items automatically
Example reasoning_data:
{
"type": "low_stock_detection",
"parameters": {
"supplier_name": "Harinas del Norte",
"product_names": ["Flour Type 55", "Flour Type 45"],
"days_until_stockout": 3,
"current_stock": 45.5,
"required_stock": 200
},
"consequence": {
"type": "stockout_risk",
"severity": "high",
"impact_days": 3
}
}
Frontend will translate:
- EN: "Low stock detected for Harinas del Norte. Stock runs out in 3 days."
- ES: "Stock bajo detectado para Harinas del Norte. Se agota en 3 días."
- CA: "Estoc baix detectat per Harinas del Norte. S'esgota en 3 dies."
Next steps:
- Remove TEXT fields (reasoning, consequence) from models
- Update dashboard service to use reasoning_data
- Create frontend i18n translation keys
- Update dashboard components to translate dynamically
Fixed critical React error #306 by adding proper null handling for
reasoning and consequence fields in the dashboard service.
Issue: When database columns (reasoning, consequence) contain NULL
values, Python's .get() method returns None, which becomes undefined
in JavaScript, causing React to throw error #306 when trying to render.
Solution: Changed from `.get("field", "default")` to `.get("field") or "default"`
to properly handle None values throughout the dashboard service.
Changes:
- Purchase order actions: Added null coalescing for reasoning/consequence
- Production timeline: Added null coalescing for reasoning field
- Alert actions: Added null coalescing for description and source
- Onboarding actions: Added null coalescing for title and consequence
This ensures all text fields always have valid string values before
being sent to the frontend, preventing undefined rendering errors.
Consolidated incremental migrations into single unified initial schema files for both procurement and production services. This simplifies database setup and eliminates migration chain complexity.
Changes:
- Procurement: Merged 3 migrations into 001_unified_initial_schema.py
- Initial schema (20251015_1229)
- Add supplier_price_list_id (20251030_0737)
- Add JTBD reasoning fields (20251107)
- Production: Merged 3 migrations into 001_unified_initial_schema.py
- Initial schema (20251015_1231)
- Add waste tracking fields (20251023_0900)
- Add JTBD reasoning fields (20251107)
All new fields (reasoning, consequence, reasoning_data, waste_defect_type, is_ai_assisted, supplier_price_list_id) are now included in the initial schemas from the start.
Updated model files to use deferred() for reasoning fields to prevent breaking queries when running against existing databases.
- Fix frontend import: Change from useAppContext to useTenant store
- Fix backend imports: Use app.core.database instead of shared.database
- Remove auth dependencies from dashboard endpoints
- Add database migrations for reasoning fields in procurement and production
Migrations:
- procurement: Add reasoning, consequence, reasoning_data to purchase_orders
- production: Add reasoning, reasoning_data to production_batches
Implements comprehensive dashboard redesign based on Jobs To Be Done methodology
focused on answering: "What requires my attention right now?"
## Backend Implementation
### Dashboard Service (NEW)
- Health status calculation (green/yellow/red traffic light)
- Action queue prioritization (critical/important/normal)
- Orchestration summary with narrative format
- Production timeline transformation
- Insights calculation and consequence prediction
### API Endpoints (NEW)
- GET /dashboard/health-status - Overall bakery health indicator
- GET /dashboard/orchestration-summary - What system did automatically
- GET /dashboard/action-queue - Prioritized tasks requiring attention
- GET /dashboard/production-timeline - Today's production schedule
- GET /dashboard/insights - Key metrics (savings, inventory, waste, deliveries)
### Enhanced Models
- PurchaseOrder: Added reasoning, consequence, reasoning_data fields
- ProductionBatch: Added reasoning, reasoning_data fields
- Enables transparency into automation decisions
## Frontend Implementation
### API Hooks (NEW)
- useBakeryHealthStatus() - Real-time health monitoring
- useOrchestrationSummary() - System transparency
- useActionQueue() - Prioritized action management
- useProductionTimeline() - Production tracking
- useInsights() - Glanceable metrics
### Dashboard Components (NEW)
- HealthStatusCard: Traffic light indicator with checklist
- ActionQueueCard: Prioritized actions with reasoning/consequences
- OrchestrationSummaryCard: Narrative of what system did
- ProductionTimelineCard: Chronological production view
- InsightsGrid: 2x2 grid of key metrics
### Main Dashboard Page (REPLACED)
- Complete rewrite with mobile-first design
- All sections integrated with error handling
- Real-time refresh and quick action links
- Old dashboard backed up as DashboardPage.legacy.tsx
## Key Features
### Automation-First
- Shows what orchestrator did overnight
- Builds trust through transparency
- Explains reasoning for all automated decisions
### Action-Oriented
- Prioritizes tasks over information display
- Clear consequences for each action
- Large touch-friendly buttons
### Progressive Disclosure
- Shows 20% of info that matters 80% of time
- Expandable details when needed
- No overwhelming metrics
### Mobile-First
- One-handed operation
- Large touch targets (min 44px)
- Responsive grid layouts
### Trust-Building
- Narrative format ("I planned your day")
- Reasoning inputs transparency
- Clear status indicators
## User Segments Supported
1. Solo Bakery Owner (Primary)
- Simple health indicator
- Action checklist (max 3-5 items)
- Mobile-optimized
2. Multi-Location Owner
- Multi-tenant support (existing)
- Comparison capabilities
- Delegation ready
3. Enterprise/Central Bakery (Future)
- Network topology support
- Advanced analytics ready
## JTBD Analysis Delivered
Main Job: "Help me quickly understand bakery status and know what needs my intervention"
Emotional Jobs Addressed:
- Feel in control despite automation
- Reduce daily anxiety
- Feel competent with technology
- Trust system as safety net
Social Jobs Addressed:
- Demonstrate professional management
- Avoid being bottleneck
- Show sustainability
## Technical Stack
Backend: Python, FastAPI, SQLAlchemy, PostgreSQL
Frontend: React, TypeScript, TanStack Query, Tailwind CSS
Architecture: Microservices with circuit breakers
## Breaking Changes
- Complete dashboard page rewrite (old version backed up)
- New API endpoints require orchestrator service deployment
- Database migrations needed for reasoning fields
## Migration Required
Run migrations to add new model fields:
- purchase_orders: reasoning, consequence, reasoning_data
- production_batches: reasoning, reasoning_data
## Documentation
See DASHBOARD_REDESIGN_SUMMARY.md for complete implementation details,
JTBD analysis, success metrics, and deployment guide.
BREAKING CHANGE: Dashboard page completely redesigned with new data structures
- Convert unit_price to Number before calling toFixed() on line 239
- Handles cases where unit_price may be a string, null, or undefined
- Uses fallback to 0 for invalid values to prevent runtime errors
This fixes the error that occurred when displaying supplier product prices in the onboarding supplier step.
CHANGES:
1. **Make suppliers-setup unconditional:**
- Removed isConditional: true and condition
- Suppliers step now ALWAYS appears in onboarding flow
- No longer depends on stockEntryCompleted flag
2. **Make ml-training unconditional:**
- Removed isConditional: true and condition
- ML training step now ALWAYS appears in onboarding flow
- No longer depends on aiAnalysisComplete flag
3. **Completely rewrote CompletionStep content:**
- Changed title: "¡Felicidades! Tu Sistema Está Listo"
- Shows what user HAS ACCOMPLISHED during onboarding:
✓ Información de Panadería
✓ Inventario con IA
✓ Proveedores Agregados
✓ Recetas Configuradas
✓ Calidad Establecida
✓ Equipo Invitado
✓ Modelo IA Entrenado
- REMOVED misleading "One More Thing" section that asked users
to configure things they JUST configured
- Changed next steps to celebrate accomplishments and guide to dashboard
- Updated buttons: "Ir al Panel de Control →" (single clear CTA)
FIXES:
- User frustration: suppliers and ML training steps were hidden
- User confusion: completion message didn't make sense - asking to
configure suppliers, inventory, recipes after they just did it
ONBOARDING FLOW NOW:
1. bakery-type-selection
2. setup
3. smart-inventory-setup
4. product-categorization
5. initial-stock-entry
6. suppliers-setup ✓ ALWAYS SHOWS
7. recipes-setup (conditional on bakery type)
8. production-processes (conditional on bakery type)
9. quality-setup
10. team-setup
11. ml-training ✓ ALWAYS SHOWS
12. setup-review
13. completion (celebrates accomplishments!)
Files Modified:
- frontend/src/components/domain/onboarding/UnifiedOnboardingWizard.tsx
- frontend/src/components/domain/onboarding/steps/CompletionStep.tsx
BUG: Suppliers-setup and ml-training steps were not appearing during onboarding,
even though users completed initial-stock-entry and smart-inventory-setup steps.
ROOT CAUSE:
VISIBLE_STEPS was calculated only once at component mount, not recalculated
when wizard context state changed. When flags like stockEntryCompleted or
aiAnalysisComplete became true, the conditional steps didn't appear because
VISIBLE_STEPS array remained static.
FIXES:
1. Added useMemo import to React imports
2. Converted VISIBLE_STEPS from const to useMemo with dependencies on:
- wizardContext.state
- wizardContext.tenantId
3. Removed obsolete useEffect that tried to handle step recalculation manually
4. Added console logging for debugging visible steps and wizard state
FLOW NOW WORKS:
- User completes smart-inventory-setup → aiAnalysisComplete = true
→ ml-training step becomes visible
- User completes initial-stock-entry → stockEntryCompleted = true
→ suppliers-setup step becomes visible
TESTING:
- Build succeeds with no errors
- Console logs will show when VISIBLE_STEPS recalculates
- Wizard state flags logged for debugging
Files Modified:
- frontend/src/components/domain/onboarding/UnifiedOnboardingWizard.tsx
SECURITY VULNERABILITY FIXED:
Registration form was storing passwords in plain text in localStorage,
creating a severe XSS vulnerability where attackers could steal credentials.
Changes Made:
1. **RegisterForm.tsx:**
- REMOVED localStorage persistence of registration_progress (lines 110-146)
- Password, email, and all form data now kept in memory only
- Added cleanup effect to remove any existing registration_progress data
- Form data is submitted directly to backend via secure API calls
2. **WizardContext.tsx:**
- REMOVED localStorage persistence of wizard state (lines 98-116)
- All onboarding progress now tracked exclusively via backend API
- Added cleanup effect to remove any existing wizardState data
- Updated resetWizard to not reference localStorage
3. **Architecture Change:**
- All user data and progress tracking now uses backend APIs exclusively
- Backend APIs already exist: /api/v1/auth/register, onboarding_progress.py
- No sensitive data stored in browser localStorage
Impact:
- Prevents credential theft via XSS attacks
- Ensures data security and consistency across sessions
- Aligns with security best practices (OWASP guidelines)
Backend Support:
- services/auth/app/api/auth_operations.py handles registration
- services/auth/app/api/onboarding_progress.py tracks wizard progress
- All data persisted securely in PostgreSQL database
Fix multiple onboarding UI issues:
1. **ReviewSetupStep interpolation fix:**
- Change single braces {suppliers} to double braces {{suppliers}}
- Fix {ingredients} and {recipes} interpolation to {{ingredients}}, {{recipes}}
- This resolves the issue where raw placeholders were displayed instead of actual values
2. **CompletionStep i18n translations:**
- Add useTranslation hook import
- Replace all hardcoded Spanish text with translation keys
- Add translation support for: welcome message, bakery info, inventory,
AI training, setup guide, next steps sections, and help text
- Properly interpolate bakery name using {{name}} syntax
- Ensures widget works in all 3 supported languages (ES, EN, PT)
3. **Confirmed onboarding steps presence:**
- suppliers-setup step exists (conditional on stockEntryCompleted)
- ml-training step exists (conditional on aiAnalysisComplete)
- Both steps are properly configured in UnifiedOnboardingWizard
These changes ensure proper variable interpolation in i18next and
complete internationalization support for the onboarding completion flow.
Add max_stock_level field to templateToIngredientCreate function to prevent
template ingredients from being created with max_stock_level = 0, which
causes 422 validation errors from the backend API.
The function now calculates realistic stock levels:
- low_stock_threshold: 10
- reorder_point: 20
- reorder_quantity: 50
- max_stock_level: 100 (reorderQty * 2, always > 0)
This ensures all template ingredients created through batch creation
(essential, common, and packaging ingredients) have valid max_stock_level
values that meet backend validation requirements.
**Issue:** When clicking "Edit" on an ingredient in the list, the edit form
appeared at the bottom of the page after all ingredients, forcing users to
scroll down. This was poor UX especially with 10+ ingredients.
**Solution:** Moved edit form to appear inline directly below the ingredient
being edited.
**Changes Made:**
1. **Inline Edit Form Display**
- Edit form now renders inside the ingredient map loop
- Shows conditionally when `editingId === item.id`
- Appears immediately below the specific ingredient being edited
- Location: frontend/src/components/domain/onboarding/steps/UploadSalesDataStep.tsx:834-1029
2. **Hide Ingredient Card While Editing**
- Ingredient card (with stock lots) hidden when that ingredient is being edited
- Condition: `{editingId !== item.id && (...)}`
- Prevents duplication of information
- Location: lines 629-832
3. **Separate Add Manually Form**
- Bottom form now only shows when adding new ingredient (not editing)
- Condition changed from `{isAdding ? (` to `{isAdding && !editingId ? (`
- Title simplified to "Agregar Ingrediente Manualmente"
- Button label simplified to "Agregar a Lista"
- Location: lines 1042-1237
**User Experience:**
Before: Edit button → scroll to bottom → edit form → scroll back up
After: Edit button → form appears right there → edit → save → continues
**Structure:**
```jsx
{inventoryItems.map((item) => (
<div key={item.id}>
{editingId !== item.id && (
<>
{/* Ingredient card */}
{/* Stock lots section */}
</>
)}
{editingId === item.id && (
{/* Inline edit form */}
)}
</div>
))}
{isAdding && !editingId && (
{/* Add manually form at bottom */}
)}
```
**Build Status:** ✓ Successful in 20.61s
## Architectural Changes
**1. Remove Manual Entry Path**
- Deleted data-source-choice step (DataSourceChoiceStep)
- Removed manual inventory-setup step (InventorySetupStep)
- Removed all manual path conditions from wizard flow
- Set dataSource to 'ai-assisted' by default in WizardContext
Files modified:
- frontend/src/components/domain/onboarding/UnifiedOnboardingWizard.tsx:11-28,61-162
- frontend/src/components/domain/onboarding/context/WizardContext.tsx:64
**2. Add Inventory Lots UI to AI Inventory Step**
Added full stock lot management with expiration tracking to UploadSalesDataStep:
**Features Added:**
- Inline stock lot entry form after each AI-suggested ingredient
- Multi-lot support - add multiple lots per ingredient with different expiration dates
- Fields: quantity*, expiration date, supplier, batch/lot number
- Visual list of added lots with expiration dates
- Delete individual lots before completing
- Smart validation with expiration date warnings
- FIFO help text
- Auto-select supplier if only one exists
**Technical Implementation:**
- Added useAddStock and useSuppliers hooks (lines 5,7,102-103)
- Added stock state management (lines 106-114)
- Stock handler functions (lines 336-428):
- handleAddStockClick - Opens stock form
- handleCancelStock - Closes and resets form
- validateStockForm - Validates quantity and expiration
- handleSaveStockLot - Saves to local state, supports "Add Another Lot"
- handleDeleteStockLot - Removes from list
- Modified handleNext to create stock lots after ingredients (lines 490-533)
- Added stock lots UI section in ingredient rendering (lines 679-830)
**UI Flow:**
1. User uploads sales data
2. AI suggests ingredients
3. User reviews/edits ingredients
4. **NEW**: User can optionally add stock lots with expiration dates
5. Click "Next" creates both ingredients AND stock lots
6. FIFO tracking enabled from day one
**Benefits:**
- Addresses JTBD: waste prevention, expiration tracking from onboarding
- Progressive disclosure - optional but encouraged
- Maintains simplicity of AI-assisted path
- Enables inventory best practices from the start
Files modified:
- frontend/src/components/domain/onboarding/steps/UploadSalesDataStep.tsx:1-12,90-114,335-533,679-830
**Build Status:** ✓ Successful in 20.78s
Removed duplicate const declaration of canContinue on line 50 which was
already declared as a prop on line 17, causing build error:
ERROR: The symbol "canContinue" has already been declared
The component already passes the calculated value to parent via onUpdate
on line 53, so the local const was redundant.
Build now completes successfully.
Implements Phases 1 & 2 from proposal-inventory-lots-onboarding.md:
**Phase 1 - MVP (Inline Stock Entry):**
- Add stock lots immediately after creating ingredients
- Fields: quantity (required), expiration date, supplier, batch/lot number
- Smart validation with expiration date warnings
- Auto-select supplier if only one exists
- Optional but encouraged with clear skip option
- Help text about FIFO and waste prevention
**Phase 2 - Multi-Lot Support:**
- "Add Another Lot" functionality for multiple lots per ingredient
- Visual list of all lots added with expiration dates
- Delete individual lots before completing setup
- Lot count badge on ingredients with stock
**JTBD Alignment:**
- Addresses "Set up foundational data correctly" (lines 100-104)
- Reduces waste and inefficiency (lines 159-162)
- Enables real-time inventory tracking from day one (lines 173-178)
- Mitigates anxiety about complexity with optional, inline approach
**Technical Implementation:**
- Reuses existing useAddStock hook and StockCreate/StockResponse types
- Production stage defaulted to RAW_INGREDIENT
- Quality status defaulted to 'good'
- Local state management for added lots display
- Inline forms show contextually after each ingredient
Related: frontend/src/components/domain/setup-wizard/steps/InventorySetupStep.tsx:52-322
Created comprehensive proposal document analyzing how to add product lots with
expiration dates to the InventorySetupStep during onboarding.
Key recommendations:
- Use inline stock entry approach after each ingredient
- Support multiple lots per ingredient with different expiration dates
- Include smart features: auto-suggest expiration, validation warnings
- Phase 1 MVP: basic lot entry with quantity, expiration, supplier
- Phase 2: Multi-lot support
- Phase 3: Smart features and auto-suggestions
Document includes:
- Current state analysis of inventory system
- JTBD alignment with detailed references
- 3 detailed UI/UX options with mockups
- Implementation recommendations with code examples
- Success metrics and risk mitigation
- 4-phase rollout plan
This addresses critical gap where users complete onboarding with zero
actual stock in system, preventing immediate value from FIFO, expiration
alerts, and waste prevention features.
Fixed the navigation architecture to follow proper onboarding patterns:
**ARCHITECTURE CHANGE:**
- REMOVED: External navigation footer from UnifiedOnboardingWizard (Back + Continue buttons at wizard level)
- ADDED: Internal Continue buttons inside each setup wizard step component
**WHY THIS MATTERS:**
1. Onboarding should NEVER show Back buttons (users cannot go back)
2. Each step should be self-contained with its own Continue button
3. Setup wizard steps are reused in both contexts:
- SetupWizard (/app/setup): Uses external StepNavigation component
- UnifiedOnboardingWizard: Steps now render their own buttons
**CHANGES MADE:**
1. UnifiedOnboardingWizard.tsx:
- Removed navigation footer (lines 548-588)
- Now passes canContinue prop to steps
- Steps are responsible for their own navigation
2. All setup wizard steps updated:
- QualitySetupStep: Added onComplete, canContinue props + Continue button
- SuppliersSetupStep: Modified existing button to call onComplete
- InventorySetupStep: Added onComplete, canContinue props + Continue button
- RecipesSetupStep: Added canContinue prop + Continue button
- TeamSetupStep: Added onComplete, canContinue props + Continue button
- ReviewSetupStep: Added onComplete, canContinue props + Continue button
3. Continue button pattern:
- Only renders when onComplete prop exists (onboarding context)
- Disabled based on canContinue prop from parent
- Styled consistently across all steps
- Positioned at bottom with border-top separator
**RESULT:**
- Clean separation: onboarding steps have internal buttons, no external navigation
- No Back button in onboarding (as required)
- Setup wizard still works with external StepNavigation
- Consistent UX across all steps
Fixed issue where setup wizard steps (QualitySetupStep, SuppliersSetupStep, etc.)
used in the UnifiedOnboardingWizard didn't show navigation buttons:
1. **Added canContinue state tracking**:
- Added canContinue state to track whether Continue button should be enabled
- Initialized to true (optimistic default)
2. **Updated handleStepUpdate to handle canContinue**:
- Setup wizard steps call onUpdate({ canContinue: true/false })
- handleStepUpdate now receives and sets canContinue state
- Allows steps to dynamically enable/disable Continue button
3. **Added navigation footer for setup wizard steps**:
- Conditionally renders navigation buttons for setup wizard steps only
- Includes Back button (when not first step)
- Includes Continue button (disabled based on canContinue state)
- Shows loading state during step completion
- Only applies to: suppliers-setup, inventory-setup, recipes-setup,
quality-setup, team-setup, setup-review
This fixes the issue where QualitySetupStep and other setup wizard steps
appeared in the onboarding flow without any way to proceed to the next step,
even though they were optional.
Note: ConfigurationProgressWidget navigation buttons are already correctly
implemented and should work as expected.
Fixed two critical issues in the setup wizard:
1. **Missing onUpdate callback**:
- Added onUpdate prop to SetupStepProps interface
- Created handleStepUpdate callback in SetupWizard to receive canContinue updates
- Passed onUpdate to all step components
- Added onUpdate implementation in SuppliersSetupStep (was missing)
- This fixes the issue where Continue/Skip buttons were incorrectly disabled for optional steps
2. **Button interaction issues in QualitySetupStep**:
- Added explicit e.preventDefault() and e.stopPropagation() to Check Type buttons
- Added explicit e.preventDefault() and e.stopPropagation() to Applicable Stages buttons
- Added cursor-pointer class for better UX
- This fixes the issue where buttons weren't responding to clicks
The Quality Setup and Suppliers Setup steps now properly:
- Show enabled Continue button when requirements are met
- Show Skip button for optional steps
- Allow clicking Check Type and Applicable Stages buttons without form submission interference
Reverted changes from commit 71759dc:
- Restored imagePullPolicy: Always
- Restored image: bakery/dashboard:latest
- Restored health check paths to /
- Restored original health check timings
Back to original Kubernetes configuration.
Fixed the issue where Tilt would get stuck after building the frontend image:
1. Changed imagePullPolicy from 'Always' to 'IfNotPresent'
- Prevents Kubernetes from trying to pull from a remote registry
- Uses locally built images for development
2. Removed ':latest' tag from image reference
- Now uses 'bakery/dashboard' without explicit tag
- Allows Skaffold/Tilt to inject the correct tag ('dev')
3. Optimized health check configuration:
- Use dedicated /health endpoint instead of /
- Reduced readiness probe initialDelaySeconds from 20s to 5s
- Reduced liveness probe initialDelaySeconds from 60s to 15s
- Faster pod startup and readiness detection
These changes ensure Kubernetes can find and use the locally built image,
and the pod becomes ready much faster, preventing Tilt from hanging during deployment.
Fixed multiple TypeScript type errors that were preventing the build from working properly:
1. Fixed infinite query type issue in forecasting.ts by excluding 'select' from options
2. Fixed Card variant type errors by changing contentPadding="default" to contentPadding="md"
3. Fixed router export issues by removing non-existent exports (ROUTE_CONFIGS, getRoutesForRole, etc.)
4. Fixed router readonly array type issues by updating RouteConfig interface
5. Fixed ProtectedRoute requiredRoles prop issue by removing invalid prop usage
6. Fixed auth store User type compatibility by allowing null for tenant_id
7. Fixed missing useToasts export from ui.store by removing from exports
8. Fixed permissions utility boolean type issues by wrapping expressions in Boolean()
The frontend build now completes successfully.
🎯 PROBLEM SOLVED:
Users were blocked when needing ingredients that weren't in inventory during:
- Recipe creation (couldn't add missing ingredients)
- Supplier setup (couldn't associate missing products)
This broke the user flow and forced context switching, resulting in lost progress
and frustration. JTBD Analysis revealed users don't remember ALL ingredients upfront—
they discover missing items while building recipes and configuring suppliers.
✨ SOLUTION: Inline Quick-Add Pattern
Never block the user—allow adding missing data inline without losing context.
📦 NEW COMPONENT: QuickAddIngredientModal (438 lines)
Lightweight modal for fast ingredient creation with minimal friction:
**Minimum Required Fields** (3 fields to unblock):
- Name (required)
- Category (required)
- Unit of Measure (required)
**Optional Fields** (collapsible section):
- Stock Quantity, Cost Per Unit, Shelf Life Days
- Low Stock Threshold, Reorder Point
- Refrigeration/Freezing/Seasonal checkboxes
- Notes
**Smart Features**:
- Context-aware messaging (recipe vs supplier)
- Auto-closes and auto-selects created ingredient
- Tracks creation context (metadata for incomplete items)
- Beautiful animations (fadeIn, slideUp, slideDown)
- Full validation with error messages
- Loading states with spinner
🔧 RECIPES STEP INTEGRATION:
- Added "+ Add New Ingredient" option in BOTH dropdowns:
* Finished Product selector
* Recipe ingredient selectors
- On selection → Modal opens
- On create → Ingredient auto-selected in form
- Handles both finished products (index -1) and ingredients (index N)
🔧 SUPPLIERS STEP INTEGRATION:
- Added "+ Add New Product" button in product picker
- Below existing product checkboxes
- On create → Product auto-selected for supplier
- Price entry form appears immediately
📊 UX FLOW COMPARISON:
**BEFORE (Blocked)**:
```
User adding recipe → Needs "French Butter"
→ Not in list → STUCK 🚫
→ Must exit recipe form
→ Go to inventory
→ Add ingredient
→ Return to recipes
→ Lose form context
```
**AFTER (Inline)**:
```
User adding recipe → Needs "French Butter"
→ Click "+ Add New Ingredient" ⚡
→ Modal: Fill 3 fields (10 seconds)
→ Click "Add and Use in Recipe"
→ ✅ Created + Auto-selected
→ Continue recipe seamlessly
```
🎨 UI/UX FEATURES:
- Smooth modal animations
- Semi-transparent backdrop (context visible)
- Auto-focus on name field
- Collapsible optional fields
- Info box: "Complete details later in inventory management"
- Context-specific CTAs ("Add and Use in Recipe" vs "Add and Associate")
- Error handling with icons
- Loading states
- Cancel button
💾 DATA INTEGRITY:
- Tracks creation context in metadata
- Marks items as potentially incomplete (needs_review flag)
- Future: Dashboard alert for incomplete items
- Smart duplicate detection (future enhancement)
📁 FILES:
- QuickAddIngredientModal.tsx: NEW (438 lines)
- RecipesSetupStep.tsx: +50 lines (modal integration)
- SupplierProductManager.tsx: +29 lines (modal integration)
Build: ✅ Success (21.10s)
Pattern: Follows best practices for inline creation
UX: Zero context loss, minimal friction, instant gratification
✅ RECIPES STEP FIX:
- Add onComplete prop handling to RecipesSetupStep.tsx
- Add "Next" button when recipes.length >= 1
- Show success message with recipe count
- Button hidden when in adding mode
🎯 AI INVENTORY STEP - COMPLETE REDESIGN:
Following suppliers/recipes pattern with list-based management and deferred creation.
**NEW DATA MODEL**:
- InventoryItemForm interface with isSuggested tracking
- Items stored in list (NOT created in database yet)
- Support both AI suggestions and manual entries
**NEW UI PATTERN**:
- List view with expandable cards showing AI confidence badges
- Edit/Delete buttons per item (like suppliers)
- "Add Ingredient Manually" button with full form
- Next button creates ALL items at once (deferred creation)
**KEY CHANGES**:
1. Items added to list first (not created immediately)
2. Can edit/delete both AI and manual items before creation
3. Manual ingredient addition form with full validation
4. All items created when clicking "Next" button
5. Progress indicator during creation
6. Sales data import happens after inventory creation
**UI IMPROVEMENTS**:
- "Why This Matters" info box explaining workflow
- Ingredient cards show: name, category, stock, cost, shelf life, sales data
- AI confidence badges (e.g., "IA 95%")
- Visual success indicator when minimum met
- Gradient form section matching recipe template pattern
**FILES**:
- UploadSalesDataStep.tsx: Completely rewritten (963 lines)
- RecipesSetupStep.tsx: Added Next button (2 lines)
- REDESIGN_SUMMARY.md: Complete documentation of changes
Build: ✅ Success (21.46s)
Pattern: Now matches suppliers/recipes workflow exactly
Creation: Deferred until "Next" click (user can review/edit first)
🔧 Recipes Step Fix:
- Add onComplete prop handling to RecipesSetupStep
- Add "Next" button when minimum requirement met (recipes.length >= 1)
- Show success indicator with recipe count
- Button only visible when not in adding mode
🚧 AI Inventory Step Redesign (In Progress):
- Updated InventoryItem interface to support both AI suggestions and manual entries
- Added new fields: id, isSuggested, isExpanded, low_stock_threshold, reorder_point
- Modified AI suggestion mapper to calculate inventory management defaults
- Next: Need to redesign UI from checkbox-grid to expandable-card list
- Next: Add manual ingredient addition form
- Next: Move inventory creation from button to onComplete/onNext handler
This is work in progress - UI redesign not yet complete.
✨ Complete UI redesign of UploadSalesDataStep to match beautiful recipe step pattern:
- Add "Why This Matters" info box with icon and explanation
- Replace summary section with clean progress indicator showing count and success state
- Change product list from vertical layout to responsive 2-column grid
- Implement custom checkboxes with visual checkmark instead of native inputs
- Separate edit form into gradient-background section (matching recipe templates)
- Update file format guide colors from hardcoded blue to CSS variables
- Clean up actions sections and remove unnecessary comments
- Add emojis for visual interest (❄️ refrigeration, 🧊 freezing, 🌿 seasonal, 📊 sales)
- Improve spacing, hierarchy, and overall visual consistency throughout
The AI suggestions step now has the same beautiful, modern, and easy-to-use
UI/UX as the recipe step, providing a consistent onboarding experience.
Document comprehensive plan for implementing critical missing feature:
- Supplier-product associations with pricing
- Required for automatic Purchase Order (PO) creation
- Backend SupplierPriceList model already exists
- Frontend implementation needed
Plan includes:
- UI/UX design for product selection
- Price entry forms
- API hooks needed
- Data flow diagrams
- Implementation checklist
This addresses the critical gap preventing automatic PO functionality.
FIXES:
✅ Fixed SuppliersSetupStep to use correct SetupStepProps interface
✅ Added Previous, Next, and Skip buttons with proper props
✅ Added minimum requirement tracking (1 supplier needed)
✅ Navigation buttons now functional - can proceed after adding supplier
✅ Warning message when minimum not met
✅ Skip button available when no suppliers added
Changes:
- Updated component props: onUpdate → onNext, onPrevious, onComplete, onSkip
- Added canContinue state tracking (suppliers.length >= 1)
- Added navigation buttons section with conditional rendering
- Added warning text for minimum requirement
- Build successful: 22.30s, no errors
CRITICAL TODO - Product/Price Association:
⚠️ NEXT STEP: Add product/ingredient association with pricing
- Users need to associate products with suppliers
- Must capture unit prices for each product
- This is CRITICAL for automatic Purchase Order (PO) creation
- Without prices, the PO system cannot function
- Backend support already exists (SupplierPriceList model)
- Need to implement UI for product selection and price entry
This commit resolves the navigation issue. Product association will be
implemented in the next commit to enable automatic PO creation.
- Updated OnboardingPage to use UnifiedOnboardingWizard instead of old OnboardingWizard
- Added UnifiedOnboardingWizard export to onboarding index
- New onboarding now fully functional after registration
The new unified onboarding provides a comprehensive setup flow:
✓ Bakery type selection (production/retail/mixed)
✓ Data source choice (AI-assisted vs manual)
✓ Tenant registration
✓ AI-assisted path with categorization and stock entry
✓ Manual path with all setup steps
✓ Suppliers, inventory, recipes, processes setup
✓ Quality and team configuration
✓ ML training
✓ Completion and tour launch
This replaces the old 4-step onboarding with a complete, contextual flow that adapts based on user choices.
