LWLT-AIBOT/.project-docs/30-worklog/tasks/20260903-dashboard-refresh-no-data-b4e82f1a.md

Task: Diagnose local dashboard refresh with no data

Identity

• Task ID: 20260903-dashboard-refresh-no-data-b4e82f1a
• Mode: Feature
• Branch: codex/20260903-dashboard-refresh-no-data-b4e82f1a-dashboard-refresh-no-data
• Worktree: /Users/inmanx/Documents/lwltAPI-dashboard-refresh-no-data-b4e82f1a
• Base commit: 69ea6d2517
• Owner: codex
• Status: Ready for Integration

Scope

• Reproduce the signed-in local 127.0.0.1:8786 leadership-dashboard refresh failure without changing accounts, tasks, database state, ERP state, or the running service.
• Trace the frontend request, HTTP response, structured service diagnostics, and dashboard candidate-query projection.
• Keep the accepted administrator/team-lead read-only visibility and 30-day default range unchanged while removing the pre-pagination full-operation payload read that exhausts the dashboard statement timeout.
• Add focused regression coverage and run repository verification from this isolated worktree; do not restart or deploy the service without separate authorization.

Intent And Constraints

• Preserve the concurrently inspected team-lead dashboard scope and the integrated account-scoped execution/deletion decisions; this task changes dashboard read performance only.
• Keep complete instruction/result projection limited to the current page and keep legacy business classification deterministic from the minimum required operation fields.
• Do not read .env, credentials, cookies, browser storage, plaintext database business inputs, or customer payloads. Runtime observations must remain aggregate- or error-code-only.
• Keep the occupied main worktree and its running 8786 service untouched. All repository edits remain rooted in this task worktree and its recorded base; current origin/main f52d9d7 was compared read-only and has the same dashboard candidate query.

Outcome

• Reproduced the default 30-day refresh as HTTP 503 operations_dashboard_query_timeout; the matching service diagnostic reports PostgreSQL cancellation code 57014 before the candidates stage completes.
• Confirmed the same authenticated dashboard succeeds for seven days in about 0.7 seconds and returns 13 aggregate task records, proving the service, database readiness, session, permissions, and underlying data are present.
• Root cause: the candidate query selects the complete t.operation JSON for every matching task before applying the 20-row page, so the default range exceeds the 5-second SQL statement timeout as payload volume grows.
• Evidence record: Local dashboard candidate-query timeout.
• Confirmed current origin/main f52d9d7 has the same dashboard candidate query, then kept the final feature commit on the task's recorded 69ea6d2 base so project-document drift is measured only against this task's changes.
• Removed full t.operation from the normal pre-pagination candidate projection. The candidate pass now reads lightweight metadata plus encrypted input only for legacy unclassified rows.
• Preserved legacy classification by hydrating only still-unresolved rows with a compact operation object containing the exact action, passenger kind, and arrangement mode fields used by the existing classifier.
• Kept full operation and result fields in the current-page detail and keyword-search projections, preserving visible input/output and search behavior.
• Added focused regression checks proving the base/candidate projections cannot reintroduce a full operation read and that legacy classification remains targeted.

Verification

• Runtime read-only reproduction: 30-day request returned HTTP 503 after about 8.9 seconds; seven-day request returned HTTP 200 and 13 records.
• node --test LianSyn-platform/app-operations-dashboard.test.mjs passed: 5/5.
• node --test --import tsx control-plane/test/account-authorization.test.ts passed: 11/11.
• node --run check:repo passed: 10/10.
• node --run check passed.
• node --run test:control-plane passed: 159/159.
• node --run test:legacy passed: 268/268.
• node --run build passed.
• Post-change 30-day runtime timing was not claimed because applying the code requires integrating it and separately authorizing a restart of the occupied 8786 service.

Follow-ups

• Integrate this feature branch, then restart the local 8786 service only with explicit authorization and repeat the authenticated 30-day dashboard request. Compare aggregate totals with the working seven-day baseline and confirm the candidates, optional legacy_classification, and page_details stage timings.

Promotion Candidates

• Target canonical documents: .project-docs/30-worklog/current-state.md and .project-docs/50-evidence/evidence-index.md during Integration Gate review.
• Proposal: record that dashboard range queries must keep full operation/result payloads out of the pre-pagination candidate projection; only unresolved legacy classification may load its minimal action/kind/mode shape, while full detail remains page-scoped.
• Evidence: the authenticated 30-day/7-day comparison, PostgreSQL 57014 diagnostic, source diff, focused regression, and full repository verification above.
• Future impact: prevents normal dashboard growth from turning a valid non-empty result into a misleading timeout/empty board while preserving role scope, filters, business classification, and business-facing detail.
• Semantic conflicts: none; the change preserves AUTH-001, AUTH-002, the 30-day default, and the concurrent team-lead visibility inspection.
• Human confirmation required: not for the repository performance correction; still required before service restart or rollout.