Create state-driven UI templates:
Main Template (ops/order-detail.blade.php):
- Display order summary with status, type, customer, date
- Render QR code SVG for shop-floor access
- Conditionally include state-specific action forms
- Show order items, packing details, shipment info
Action Templates:
- ops/actions/packing.blade.php: Form to input weight/dimensions
- ops/actions/inspection.blade.php: Pass/Fail inspection with optional notes
- ops/actions/read-only.blade.php: Status display for read-only states
Error Pages:
- ops/order-not-found.blade.php: Invalid/expired QR token
- ops/unauthorized.blade.php: Insufficient permissions
All forms use AJAX submission with confirmation dialogs
Phase 1: QR Code Generation
- Create GenerateQrCodeOnOrderCreated listener
- Generate secure random token on order creation
- Create SVG QR codes pointing to /ops/orders/{token}
- Store QR token and generation timestamp on order record
- Register listener in EventServiceProvider
Phase 2: Ops Controller & Routes
- Create OpsController with showOrder() landing page
- Implement confirmPacking() to capture dimensions via form
- Add markInspectionPassed() and flagInspectionIssue() methods
- Implement getAvailableActions() state machine for UI
- Add routes: GET /ops/orders/{token}, POST /ops/orders/{id}/pack, etc.
- Token-gated access, requires auth middleware
Next: Create Blade templates for state-driven UI
- Move all validation (packing, payment, status, duplicates) to CourierService::createShipmentForOrder()
- Move database updates to service layer
- Move document fetching to service layer
- Simplify ShippingController to just handle HTTP concerns (request/response)
- Simplify CreateShipmentOnReadyToShip listener to just dispatch events
- Single source of truth for business logic in CourierService
- Eliminates duplicate validation between controller and listener
- Create new listener that fires on ReadyToShipIntent event
- Register listener in EventServiceProvider
- Fix log statements in ShippingController to use order UUID instead of ID
- Now when Trello card moves to 'Ready to Ship', backend automatically creates shipment
- Parse incoming Trello webhook payloads for card movement actions
- Extract order number from card names (supports both numeric and full formats)
- Look up orders in database (Order or CustomOrder models)
- Emit ReadyToShipIntent event when cards moved to 'Ready to Ship' list
- Validate shipment exists before allowing 'Awaiting Collection' transition
- Add comprehensive logging for all Trello actions
- Handle validation pings and real events identically (both return 200)
- Card moves now trigger backend order processing workflows
- Change print_stocks (plural) to printStock (singular)
- Properly accesses the PrintStock model via OrderItem's belongsTo relationship
- Gets the correct print stock name from the print_stocks table
- Add emoji () and design name to order creation Slack message
- Include print size information (wallpaper length or mural dimensions)
- Extract design/size info once and reuse for both Slack and Trello
- Message format: 'New [type] order: Order #[number]\\nDesign: [name]\\nSize: [dimensions]'
- design_name: Get product name from first order item
- print_size: Calculate from item dimensions (wallpaper: length in m, mural: width x height in cm)
- Add fallback values ('') when items/dimensions unavailable
- Prevents null errors when populating Trello custom fields
- Add fallback env parsing directly from .env file in config/trello.php
- Fixes issue where cached config prevents env() from reading .env values
- Add artisan trello:test command to diagnose Trello configuration
- Test command checks API credentials, board/list IDs, and connectivity
- Test successfully creates and moves a test Trello card
- Add integration fields to Order model: packing_*, courier_*, trello_card_id, qr_token
- Add integration fields to CustomOrder model: packing_*, proof_approved_*, courier_*, trello_card_id, qr_token
- Update Order model fillable array and add relationships (packedBy)
- Update CustomOrder model fillable array, casts, and add relationships (packedBy)
- Add isCustomOrder() method to both models for type checking
- Update OrderController to emit OrderCreated and DepositPaid events on successful payment
- For standard orders: full payment -> prep status, emit events
- For custom orders: deposit -> design status, balance -> printing status, emit respective events
- Add approveProof() method to CustomOrderController (POST /custom-orders/{id}/approve-proof)
- Add requestChanges() method to CustomOrderController (POST /custom-orders/{id}/request-changes)
- Add markBalancePaid() method to CustomOrderController (POST /custom-orders/{id}/pay-balance)
- All new methods emit appropriate events (ProofApproved, ProofRevisionRequested, BalancePaid)
- Add database migration for proof_approved and proof_approved_at fields on custom_orders
- Add routes for new custom order endpoints with UUID binding
- Import all required event classes in both controllers
- Add 14 domain events for order lifecycle (OrderCreated, OrderPacked, ShipmentCreated, ParcelDelivered, etc.)
- Create SlackNotifierService with channels for orders, design, production, shipping, ops-alerts
- Create TrelloService to create cards, move cards between lists, attach files, check items
- Create CourierService to integrate with ShipLogic API for shipment creation and document retrieval
- Create PackingController to explicitly capture packing dimensions and weight
- Create ShippingController with multi-layer guards: packing validation, payment/approval verification, idempotency
- Create TrelloWebhookController to handle incoming Trello webhooks as intent signals
- Create CourierWebhookController to handle Shiplogic status updates
- Create event listeners for Slack notifications and Trello card updates
- Create EventServiceProvider to register all events and listeners
- Add database migration for packing, courier, and Trello data columns
- Create config files for slack, trello, and courier integration
- Update .env with integration secrets placeholders
- Add routes for /orders/{id}/pack, /orders/{id}/ship, /api/webhooks/trello, /api/webhooks/courier
Key architectural decisions:
- Packing is explicit ops action (not automatic from status)
- Shipment creation only after: Trello intent + packing confirmed + payment/approval rules met
- Courier API failures keep order in Ready to Ship state (safe retry)
- Trello and Slack are mirrors of backend state, not decision makers
- All side effects flow through event listeners, maintaining separation of concerns
twotalesanimation