Please review the current state of things in terms of the Avg Turnaround card on the /admin dashboard in the context of our recently updated/fixed/backfilled/added order lifecycle timestamps; received_at, shipped_at, uploaded_at, etc and how they rel

next steps

• Compile findings into a clear summary for the user, noting which timestamps are real vs. proxy.
• If needed, re-run the tinker query with error suppression to get actual population counts.
• Confirm whether the 'uses_received_proxy' flag is still active in the current checkout's code.

key decisions

• Kept the review read-only; no edits were made to any files.
• Used Flower recall to gather prior context on received_at, shipped_at, uploaded_at, and the Dashboard component.
• Examined both the Livewire component code and the sync commands to understand the timestamp sources and fallback logic.
• Attempted a live database query to check population of timestamps, though output was truncated by deprecation warnings.

open questions

• Whether the local database has received_at populated enough for the card to use real timestamps (the tinker query did not produce clear output).
• Whether the 'uses_received_proxy' note is still showing on the card (the code suggests it will show when received_at is null).
• Whether the Uploaded→Shipped turnaround chart should remain disabled or be enabled now that shipped_at is backfilled.

next steps

—

key decisions

• Use only strict received_at, uploaded_at, shipped_at in the new metric service, excluding fallback timestamps entirely.
• Cache the aggregate metrics via a scheduled command rather than computing on every Livewire poll.

open questions

—

next steps

—

key decisions

• Cache key format: 'dashboard:turnaround:{window}' with 10-minute TTL.
• Scheduled at every 5 minutes to keep the dashboard fresh without live aggregate scans.
• Exclude rows where received_at > uploaded_at or uploaded_at > shipped_at (negative turnaround).

open questions

—

next steps

—

key decisions

• Remove the old 5,000-row sample cap entirely; the cached service returns all matching rows.
• Display excluded counts so operators know when rows are omitted due to missing or out-of-order timestamps.

open questions

—

next steps

—

key decisions

• Test uses future-dated timestamps to avoid interference with existing production data.
• Multi-row insert must have consistent column lists across all rows.

open questions

—

next steps

• Deploy the new files to production and run the cache command once to populate the initial cache.
• Monitor the dashboard after deployment to verify the card shows accurate strict-timestamp averages.

key decisions

—

open questions

—

next steps

—

key decisions

• Used CACHE_DRIVER=array to bypass Redis mutex for schedule:list inspection

open questions

—

next steps

—

key decisions

• Promoted the shipped-before-upload exclusion count from a small line to an amber note inside the card for visibility

open questions

—

next steps

—

key decisions

• Staged all modified and new files together after user OK'd including the other session's admin-orders work
• Excluded raw Labworks dump files (_labworks_overview.html etc.) from the commit to avoid whitespace warnings
• Pushed to new remote branch with --set-upstream

open questions

—

next steps

• Determine if backfilling uploaded_at from order_ready_webhook_sent_at is acceptable for the 188,955 rows that have that timestamp
• Consider the 140 rows with only dropbox_sync_finished_at
• Write and run a backfill command if approved
• Perform git reset --soft HEAD~1
• Unstage the documentation files (ADMIN_RESTYLE_PLAN.md, DESIGN.md, HANDOFF.md, XML_*.md, _labworks_replacement_docs/)
• Recommit with only source/test changes
• Force-push with lease

key decisions

—

open questions

• Is order_ready_webhook_sent_at a reliable proxy for uploaded_at for historical rows?
• Should dropbox_sync_finished_at be used for the 140 rows without order_ready_webhook_sent_at?

next steps

—

key decisions

• Remove doc/reference files from the commit to keep the branch tip source-only
• Remove solo.yml from the commit as requested by user
• Force-push with lease to replace the earlier branch tip

open questions

—

next steps

—

key decisions

• Stage and commit only the three pending view-refine files (app.css, admin-orders.blade.php, dashboard.blade.php)
• Use fast-forward merge to avoid a merge bubble
• Run focused tests before pushing master

open questions

—

next steps

• Fix the two failing tests in AdminOrdersTest (testFlaggedOrdersCanFilterOrdersStillInQcAfterShipping and another) to match the new implementation

key decisions

• Add a new FILTER_QC_SHIPPED constant and corresponding flag logic in FlaggedOrdersReport
• Remove the 30-day window and 500-candidate limit for FOS import scanning; scan full history
• Move FOS scan behind a cached report with a scheduled refresh command (CacheFlaggedOrdersReport) to avoid expensive queries on every render
• Increase default FOS chunk size from 1,000 to 5,000
• Update views to remove the partial-scan warning and add the new filter tab

open questions

—

next steps

—

key decisions

• Exclude QC-shipped orders from the generic 'Overdue in QC' flag to avoid duplicate flag rows
• Remove the 500-row cap on FOS import scan; now scans all candidates in chunks
• Cache FOS import results under key 'dashboard:flagged-orders:fos-import:v2' and schedule refresh every 10 minutes via tdr:cache-flagged-orders

open questions

—

next steps

—

key decisions

• Sort by the underlying timestamp (occurred_at) rather than computed age (days) to achieve newest-first order

open questions

—