Complete the first Operations Home dashboard

[alexeygrigorev]

Complete the first Operations Home dashboard

Status: pending
Tags: enhancement, portal, frontend, backend, work-engine, testing, P0
Depends on: None
Blocks: #9, #30, #31, #35

Scope

Complete issue #10 as the first workflow-first Operations Home for the DataOps V1 workspace. This is the operator's daily landing page, not a docs browser. It should answer the four questions from .goal-v1.md and docs/operations-manager-platform-jtbd.md:

1. What must I do today?
2. What is late or blocked?
3. Who needs a follow-up because they have not replied or provided an asset?
4. Which active workflows are at risk because a required link, file, approval, or status update is missing?

The work lives primarily in the portal dashboard surface in frontend/src/app.js, its Python frontend tests in tests/docs_app/, and any small work-engine/API changes needed to support dashboard behavior. The dashboard should continue using same-origin /work/api/* calls into the private work-engine instead of introducing a separate dashboard data source.

Several slices have already shipped on this issue: live /work/api/* dashboard data, today/overdue/waiting/active bundle lanes, task action panel, required proof blockers, recurring operations controls, local /work/api smoke coverage, and starting workflows from template cards. This issue should close only when the remaining dashboard experience is coherent as one daily operating loop and the acceptance criteria below are verified together.

For inbox, assistant jobs, and process quality warnings, #10 should provide integrated dashboard placement and honest empty/not-connected states only. The durable models and full widgets belong to #31, #30, and #35 respectively.

• Operations Home is the default post-login operational landing screen and presents work before process docs.
• The dashboard uses same-origin /work/api/* runtime data for tasks, bundles, templates, recurring configs, and notifications where available; it does not call bare /api/* from the portal frontend.
• The dashboard groups work into clear daily sections: Today, Overdue, Waiting / Follow-ups, Active Workflows, Recurring Operations, and Workflow Templates.
• Today includes tasks assigned to the current operator and unassigned urgent work due today; empty states distinguish "clear" from "live work data unavailable".
• Overdue tasks are visually separate from normal today tasks and cannot be hidden merely by dismissing a notification.
• Waiting tasks remain visible, and waiting tasks with followUpAt today or earlier are presented as follow-up due work, not only as generic overdue work.
• Each task card shows enough context for the next click: task title, due/follow-up date, status, workflow or ad-hoc source, required proof state, and one obvious next action such as complete, add link, upload/attach file, follow up, mark response received, or open workflow.
• Clicking a task opens the task action panel in context and supports the V1 operating actions already available in the platform: save required link, inspect required files, mark done, mark waiting, record follow-up sent, and mark response received.
• A task cannot be completed from the dashboard when required proof is missing; the UI states the specific missing proof, for example the missing required link or file.
• Active workflow cards show stage, progress, next due task if known, overdue count, waiting/follow-up count, and missing required link/file risk where the current data model supports it.
• Clicking an active workflow opens the workflow/bundle detail instead of sending the operator into a disconnected docs view.
• Recurring Operations shows enabled and paused schedules, allows generating today's due recurring tasks, and keeps pause/resume/create controls in the same daily operating surface.
• Workflow Template cards make "Start workflow" the primary action and keep process docs as secondary contextual help.
• Inbox, Assistant Jobs, and Process Quality areas are represented as integrated dashboard sections or states without fake data; if the backing model is not implemented yet, the section clearly shows that it is not connected yet and points future implementation to Implement raw intake inbox for operational inputs #31, Implement assistant job model and lifecycle #30, or Add process quality dashboard for runnable workflows #35.
• The dashboard degrades smoothly when work-engine data is unavailable: the operator sees an explicit runtime-data error or fallback state, and docs/templates remain contextual rather than becoming the primary experience.
• The implementation is covered by focused tests for frontend URL contracts, dashboard model building/rendering, task action helpers, /work/api broker behavior, and work-engine behavior touched by this issue.

Scenario: Operator opens the dashboard with live work data

Given: work-engine returns tasks, bundles, templates, recurring configs, and notifications through /work/api/*.
When: the operator opens Operations Home after login.
Then: the page shows Today, Overdue, Waiting / Follow-ups, Active Workflows, Recurring Operations, and Workflow Templates with live counts and actionable cards.

Scenario: Missing proof blocks completion

Given: a dashboard task requires a link or file and the proof is missing.
When: the operator tries to mark the task done from the dashboard task panel.
Then: completion is blocked, the missing proof is named, and the task remains active.

Scenario: Follow-up due is actionable

Given: a task has status=waiting, waitingFor, and followUpAt today or earlier.
When: the dashboard loads.
Then: the task appears in Waiting / Follow-ups as follow-up due work, and the operator can record follow-up sent, set the next follow-up date, or mark response received.

Scenario: Workflow risk is visible

Given: an active bundle has incomplete tasks, overdue tasks, waiting tasks, or missing required links/files.
When: the operator views Active Workflows.
Then: the workflow card shows progress and risk counts, and clicking it opens the workflow detail with the checklist and links.

Scenario: Start a workflow from a template

Given: work-engine exposes workflow templates and the portal has matching template cards.
When: the operator clicks Start workflow on a template card.
Then: the workflow creation modal opens with the matching live template selected when the match is exact and unique, and creating the workflow calls /work/api/bundles.

Scenario: Recurring work is generated from the daily surface

Given: recurring configs are present.
When: the operator clicks Generate today.
Then: the dashboard calls /work/api/recurring/generate, reports generated/skipped tasks, and refreshes the daily work view.

Scenario: Work-engine is unavailable or auth fails

Given: /work/api/* returns an error, HTML login response, or unavailable work-engine response.
When: Operations Home loads.
Then: the dashboard does not silently render an empty queue; it shows a clear runtime-data problem and keeps contextual docs/templates available as fallback content.

Scenario: Future dashboard sections have honest empty states

Given: inbox, assistant job, or process quality backing models are not implemented yet.
When: Operations Home renders their areas.
Then: the dashboard shows an integrated not-connected/empty state without fake counts, fake jobs, or links to disconnected tools.

Out of Scope

• Building the durable inbox model for Telegram, email, manual notes, files, and assistant-ready inputs; that belongs to Implement raw intake inbox for operational inputs #31.
• Defining or implementing the assistant job lifecycle, retry model, logs, approvals, or storage; that belongs to Implement assistant job model and lifecycle #30 and assistant-specific follow-ups.
• Building the full process quality dashboard for broken links, TODOs, missing validation, or doc-health analytics; that belongs to Add process quality dashboard for runnable workflows #35.
• Migrating live Trello cards, spreadsheet TODOs, or production historical state; those belong to Migrate active Trello cards into integrated operations-manager work #41 and Migrate spreadsheet TODOs into integrated operations-manager work #42.
• Creating the broader design system and component token refactor; that belongs to Create shared DataOps design system and component tokens #46, though this issue should not make visual consistency worse.
• Reworking the repository structure, AWS infrastructure, OIDC deployment, or DynamoDB backup/export policy unless a narrow change is required for this dashboard behavior.
• Modifying source repositories outside dataops.

Dependencies

• Use the current DataOps portal and work-engine code in this repository as the implementation base.
• Keep /work/api/* as the portal-to-work-engine integration boundary.
• Use existing work-engine concepts where possible: tasks, bundles, templates, recurring configs, notifications, required links, required files, status=waiting, waitingFor, and followUpAt.
• Use .goal-v1.md and docs/operations-manager-platform-jtbd.md as product acceptance references.
• Expected verification commands should include the relevant subset of:
  • node --check frontend/src/app.js
  • uv run --project lambda-functions --extra search --with pytest python -m pytest tests/docs_app
  • npm --prefix work-engine test
  • npm --prefix work-engine run typecheck
  • Playwright or screenshot verification for visible UI changes when the local environment supports it.

[alexeygrigorev]

Implemented the first live dashboard slice in d981f47. Deployment succeeded in run https://github.com/DataTalksClub/dataops/actions/runs/28292994354.

What shipped:

• Operations Home now loads runtime data from the private work-engine through same-origin /work/api/*.
• Dashboard lanes now use live tasks and bundles for Today, Overdue, Waiting / Follow-Ups, and Active Bundles.
• Active bundles show progress and risk from their tasks, including overdue and waiting counts.
• Docs/templates remain available as contextual sections and as fallback when live work data is unavailable.
• Work-engine now supports status=waiting, waitingFor, and followUpAt; waiting tasks require both fields on create/update.
• API request handling now rejects non-JSON responses so login HTML cannot silently render as an empty dashboard.

Verification:

• node --check frontend/src/app.js
• pytest tests/docs_app/test_frontend_routes_and_links.py - 8 passed
• NODE_ENV=test SKIP_AUTH=true node --import tsx --test tests/api-tasks.test.ts - 51 passed
• npm run typecheck in work-engine
• npm test in work-engine - 599 passed
• uv run --extra search --with pytest python -m pytest ../tests/docs_app/test_backend_full_app_search_auth.py from lambda-functions - 14 passed
• CI/CD deploy run passed, including private work-engine smoke test

Keep this issue open. Remaining #10 scope still includes richer dashboard actions, workflow-detail navigation from the portal surface, inbox (#31), assistant jobs (#30), process-quality warnings (#35), follow-up reminder generation (#50), and local/smoke coverage for the /work/api integration (#51).