Build Labworks replacement order intake system with dashboard, backfill, restyle

next steps

• Deploy to production and run migration
• Build Woo/FOS order sync to populate customer and financial data
• Build intake write-up screen per order-write-up.html mockup
• Build ship tracking integration (ShipStation?)
• Address open questions from QUESTIONS_FOR_OWNERSHIP.md

key decisions

• Pipeline stages are derived from existing status + COALESCE of lifecycle timestamps — no second status column added to avoid sync complexity
• Lifecycle timestamps stored alongside existing operational timestamps as nullable columns; existing flows untouched
• Use FOS DB tunnel or Woo REST API for data sync (not direct Woo DB) to insulate from upcoming HPOS migration
• Administrative revenue section guarded by isAdmin() (currently permissive)
• Uploaded-pending-ship window capped at 14 days to avoid unbounded pipeline counts
• Config-driven overdue day thresholds with env overrides

open questions

• What are the exact overdue day thresholds? (Q15)
• Net revenue formula — total_amount minus discounts/shipping/tax? (Q19)
• Should revenue be visible to non-admin employees? (Q24)
• How to handle orders that never arrive (age-out)? (Q5)

next steps

• Continue examining framework-updates and other branches for additional unmerged QC/design changes
• Possibly merge or cherry-pick relevant changes into current branch
• Review stash contents for any QC work

key decisions

—

open questions

• Are there additional design changes on framework-updates branch not yet on master?
• Any stashes containing relevant QC view modifications?

next steps

—

key decisions

—

open questions

—

next steps

• Committed and pushed as dde91d2 after the woo migration, but the work itself is complete.

key decisions

• Removed expansionEnabled property, expandedRollId tracking, overlay div, and associated event dispatches.
• Kept existing pass-collapse behavior and auto-scroll on QC check.

open questions

—

next steps

• Run php artisan migrate on production to apply the change.

key decisions

• Use unsignedBigInteger to match WooCommerce BIGINT order IDs.
• Follow cross-app convention woo_id over woo_order_id.

open questions

—

next steps

• User review of DESIGN.md.
• If approved, task the same agent with /admin routes/views restyle review.
• Consider committing the dependency update after UI verification.

key decisions

• Stay on Flux 2.x and Livewire 3.x since Laravel 10 is incompatible with Livewire 4.
• Agent must avoid context-mode tools after stall; use Read/Grep/WebFetch.
• Timer set at 10-minute interval with stall detection for agent monitoring.

open questions

• Should the composer.lock change be committed now or after restyle work?
• Verify the DESIGN.md accurately captures thedarkroom.com branding.

next steps

—

key decisions

• Crimson demoted to destructive-only use in DAP, teal remains sole primary-action color.
• Contrast question (accent 600 vs 700) deferred until applied and visible.
• Worker instructed to avoid context-mode plugin tools due to prior stalls.

open questions

—

next steps

—

key decisions

• Hybrid approach: apply brand theme globally (Step 0) then targeted fixes per view, not a full re-style.
• Employee Report warrants rebuild; other views are surgical corrections.
• Three distinct status-to-color schemes across views must be unified.

open questions

—

next steps

—

key decisions

• Batches 0+1 only; no QC blade markup changes and no batch 2+ work in this segment.
• No commits or pushes; orchestrator reviews before committing.

open questions

—

next steps

• When resuming: git switch admin-restyle, push branch, open PR.
• Batch 2 (shared chrome) can be started in the same branch.

key decisions

• Commits are local-only; not pushed to origin.
• DESIGN.md and ADMIN_RESTYLE_PLAN.md kept untracked per 'never commit plan files' rule.

open questions

—

next steps

• Worktree is ready for fresh agent session to continue Batch 2 or unrelated admin dashboard work.
• Main checkout remains on master, clean for other tasks.

key decisions

• Worktree based on admin-restyle branch to carry the three restyle commits.
• Solo.yml generated with conservative profile (Logs, npm watch, Reverb).
• Build skip required because default build_command is npm run build but this project uses npm run dev.
• auth.json manually copied from main checkout to authenticate flux-pro during composer install.

open questions

—

next steps

—

key decisions

• Use global composer auth for fluxui credentials to avoid per-worktree setup failures.

open questions

—

next steps

• Answer orchestrator's questions in its session to start build.
• Monitor orchestrator progress and review its output.

key decisions

• Rebased dap-ops-health worktree onto admin-restyle so the brand theme is available.
• OPS_HEALTH_PLAN.md and ORCHESTRATOR_BRIEF.md placed in worktree for self-sufficiency.
• Checks probe whatever is actually configured; failures are acceptable.

open questions

• Precise canary host for VPN detection?
• FOS API health endpoint vs base URL probe?
• Should v1 include any historical data beyond current status?

next steps

• Implement time-window selector in the dashboard header (currently only shipped count uses the turnaround window).
• Review and act on shipped_at investigation: decide on backfill strategy and implementation approach.
• Consider adding a separate filter for auto-uploaded orders in /log view for the auto-upload badge links.
• Possibly add a 'run now' button for the turnaround window section.

key decisions

• Uploaded and Shipped cards shown as N/A until shipped_at is populated (no stopgap cap).
• Turnaround window drives shipped count as interim measure.
• Helper text on cards mirrors ownership's mockup (dashboard.html).
• Overdue badges on Received/In-QC cards link to #flagged-orders anchor.
• Placed→/log/new, Received→/log/processing, In QC→/log/quality_control.

open questions

• Exact implementation of time-window selector: position in header, UI component, which cards it affects?
• How to surface Codex findings: implement shipped_at population now or wait for ShipStation?
• Should the auto-uploaded badge link to a filtered /log view or remain informational?

next steps

—

key decisions

• Use ActualShipmentDateTime rather than ShipmentDateTime (scheduled) or last_modified_on; gate on ShipmentStatusID=8 not on tracking number; join on OrderID (not OrderReference which can be null).

open questions

—

next steps

• Address user feedback: fix modal copy (remove 'stand-in' wording, move thresholds to per-stage, rephrase 'failing that' to 'fallback'), restructure modal with visual hierarchy (colored dots, section dividers), add stronger card hover effects (glow or bg animation).
• After review, commit modal and push branch.

key decisions

• Keep uploaded_at as distinct milestone, do not replace with photos_cached_at (deferred to separate todo).
• Disable Uploaded-to-Shipped turnaround as unreliable because shipping can precede upload.
• Do not store tracking number from Labworks; only shipped_at.
• Flagged list caps at 50 items; badge shows true total.
• Modal stays uncommitted for review before final commit.

open questions

—

next steps

—

key decisions

• Whole card becomes click target via stretched link pattern with overdue badges in a relative z-10 layer above
• Modal uses colored dots matching card accents (slate/amber/violet) for visual hierarchy

open questions

—

next steps

—

key decisions

• Two-step merge (admin-restyle first, then dap-ops-health) to keep history linear and avoid cherry-picking unthemed code
• Conflict resolved by placing health badge above the metric-definitions trigger + timestamp in the header
• Not merging into master yet — user wanted to keep working first

open questions

—

next steps

• If the issue recurs, inspect journalctl -u ssh on the server to identify the cause of sshd exit

key decisions

• Determined that 'Connection refused' (TCP RST) vs 'timeout' proves the firewall allows port 22 but nothing is listening

open questions

• What caused sshd to stop? Was it a process crash, OOM killer, or fail2ban ban?

next steps

• User will trigger deploy via Forge Deploy Now button
• After deploy, validate shipped_at backfill on production

key decisions

• Merged into master (not just feature branch) since master is the Forge-deployed branch
• Remote must be updated to The-Darkroom/thedarkroom-automation

open questions

—

next steps

• Run tdr:sync-shipped-at --dry-run against orders known to have shipped (e.g., by labworks_id range or older creation dates) to confirm the ShipmentInfo.OrderID join works
• If join validates, run the full dry-run with --all, then the real backfill

key decisions

• Deploy notes in CLAUDE.md must state 'button press in Forge UI, NOT push-to-deploy'
• The 0-match dry-run is a sampling artifact of --limit=100 (newest orders first) — not a broken command

open questions

• Does the join key labworks_id = ShipmentInfo.OrderID need any normalization (zero-padding, integer casting)?

next steps

—

key decisions

• Use DB::table()->update() instead of saveQuietly() to avoid touching updated_at.
• Accept that the first 9,232 rows had updated_at bumped; no restoration needed.
• Re-run scoped to shipped_at IS NULL to avoid double-writing already-shipped orders.

open questions

—

next steps

—

key decisions

• Use activeNonBlankRollsCount() condition to mirror auto-upload logic.
• Add withCount to avoid N+1 on the index query.
• Use blue shade to distinguish from cyan Single Use badge.

open questions

—

next steps

—

key decisions

• Hide Single Roll badge when single_use_only to avoid redundancy.
• Use --candidates filter with qc/uploading/complete statuses for incremental sync.
• Limit incremental sync to 2000 most recent candidates per run.
• Delegate dashboard pagination to background agent to parallelize work.
• Use named paginator and aggregate stats to handle large shipped dataset efficiently.

open questions

—

next steps

—

key decisions

• Push all changes together after each is independently committed.
• Create Solo backlog todo for uploaded_at work to track separately.

open questions

—

next steps

• Commit and deploy the dashboard lighting changes.
• Backfill historical uploaded_at = COALESCE(order_ready_webhook_sent_at, dropbox_sync_finished_at) via direct DB update (no updated_at bump).

key decisions

• Set uploaded_at at the same gate as order_ready_webhook_sent_at (after both clouds synced).
• Only set when null to avoid moving on retries.
• Auto-upload breakdown shown as badges on the Uploaded card.

open questions

• Whether to use notify-time vs sync-complete-time for uploaded_at (now uses notify-time, which is effectively same moment).

next steps

—

key decisions

• Added hourly sweep to catch stragglers not in post-processing statuses
• Limit hourly sweep to newest 20k unshipped to avoid scanning 81k permanent never-shipped orders
• 0-matches join warning only fires on unlimited runs to avoid false alarms on scheduled slices

open questions

—

next steps

—

key decisions

• Shipped_at not added to revision log because it's written via direct DB update to avoid bloat on backfill
• Timeline milestones are independent (no gating on predecessors)

open questions

—

next steps

—

key decisions

—

open questions

—

next steps

—

key decisions

—

open questions

—

next steps

—

key decisions

• Used grouped revisions query scoped to sample IDs to avoid full table scan
• Falls back to received_at/created_at for orders without processing-status revision

open questions

—

next steps

—

key decisions

—

open questions

—

next steps

• Continue reviewing health check classes and compare with actual storage usage (filesystem disks, SFTP connections, etc.)
• Determine which health checks are obsolete due to changes in storage infrastructure
• Remove or update health checks for unused services

key decisions

—

open questions

• Are Scanner Storage (SFTP), Dropbox Storage Server (SFTP), and Labworks XML Drop Mount still in use? Or have they been replaced?
• Are the failing health checks due to misconfiguration or because the services are no longer active?

next steps

• Deploy to production; flip XML_DELIVERY_ENABLED when DAP->Labworks flow goes live.

key decisions

• Use device-ID comparison (stat) rather than Flysystem ops for mount detection because directoryExists passes on empty mountpoints.
• Gate new XML check behind config flag to avoid false down.
• Keep class names unchanged so config/health.php needs no update.

open questions

—

next steps

• Deploy to production to stop hourly error.

key decisions

• Reuse chunk(500) on the Collection to keep batch size consistent with chunkById.

open questions

—

next steps

• Deploy to production.

key decisions

• Split unknown into its own pill count for clarity.

open questions

—

next steps

• Run tdr:sync-received-at --dry-run on production.
• Then run full backfill.
• Update turnaroundMetrics() to prefer received_at over scanning-start proxy.
• Consider caching and removing the 5000 limit.

key decisions

• Use InvoiceInfo.InvoiceDateTime as authoritative timestamp for received_at (not OrderInfo.ReceiveDateTime which is set at Open).
• Mirror the shipped-at command pattern.
• Document source definitions in LABWORKS_DB_NOTES.md.

open questions

—

next steps

• Review how received_at and shipped_at are represented on the dashboard (filed as todo 684)
• Address todo 521 for full-set turnaround computation with caching and CPA-grade UX

key decisions

• Received_at anchor chain: real received_at (invoiced/intake) > scanning-start revision proxy > created_at, coherent both before and after backfill
• Committed separately from scheduling to keep the anchor change independently deployable

open questions

—

next steps

• Push 17da36b when user is ready
• Deploy via Forge to activate the schedule

key decisions

• Mirror the shipped_at schedule pattern exactly (5-min fast-path + hourly wider sweep) for consistency
• No status filter on received_at sync since invoicing is early in lifecycle and not tied to a DAP status

open questions

—

next steps

• Deploy the pipeline fixes (timeout raise + cache TTL fix) and verify mounts recover to sub-100ms latency
• Monitor batch-uploads queue drain trend after deploy
• Re-drive the 35 timeout-errored orders via Auto-Resolve after deploy

key decisions

—

open questions

—

next steps

• User to deploy via Forge (config:cache + horizon:terminate) to activate all three fixes
• Verify QC jobs churn through without timing out even on degraded mount
• Monitor batch-uploads queue (9,565) for drain after deploy
• Re-drive the 35 errored orders via Auto-Resolve

key decisions

• All three pipeline supervisors (quality-control, network-copy, photo-import) moved together to redis-long with 300s timeout — raising only quality-control would still fail the batch when network-copy copy jobs time out at 60s
• 1.5s threshold for degraded mount: chosen because healthy CIFS is single-digit ms but 2-5s was observed during NAS load
• The scanner-storage cache regression explanation (Laravel 5.8 minutes-to-seconds change) is the most likely cause given the app's age and upgrade history

open questions

• Was the duplicate-roll-name lookup returning the first match (not newest) ever a correctness issue in practice?

next steps

—

key decisions

• Used Cache::has(Roll::SCANNER_STORAGE_CACHE_KEY) to detect warm cache.
• Placed ScannerCacheCheck under Storage/Network health group.

open questions

—

next steps

• Wait for NAS to recover and verify cache warms automatically.
• Consider making Dropbox parsed-month state durable (addressed later in segment 4).

key decisions

• Confirmed mapDropbox uses dropbox cloud disk, not NAS mount.
• Noted that cache:clear on deploy wipes Dropbox month flags.

open questions

—

next steps

—

key decisions

• Extended auto-resolve condition to include CopyRollToQCBatch and ImportRollPhotosFromQCBatch timeouts because recovery logic is identical.
• Created todo 687 for Dropbox parsed-month state durability.

open questions

—

next steps

• Review commit fda4f57 and consider escaping underscore in LIKE pattern for robustness.
• Consider adding index on folder_path if table grows large.
• Remove cache:clear line from Forge deploy script as recommended.

key decisions

• Chose Option A: determine if an old month is fully parsed by checking existing DB rows with folder_path LIKE prefix instead of Cache::forever flag.
• Delegated implementation to Codex agent for efficiency.

open questions

• Whether to escape underscore in LIKE query to avoid single-character wildcard matching.
• Whether to add an index on folder_path for performance.