TenantAtlas/specs/273-tenant-dashboard-active-operations-summary-card/tasks.md
Ahmed Darrazi 163738c14c
Some checks failed
PR Fast Feedback / fast-feedback (pull_request) Failing after 1m33s
feat: polish tenant dashboard operations attention UX
2026-05-07 18:51:03 +02:00

5.0 KiB

description
Task list for Tenant Dashboard Operations Curation & Decision-First UX

Tasks: Tenant Dashboard Operations Curation & Decision-First UX

  • T001 Refresh the active local spec scope so the Tenant Dashboard slice is explicitly attention-only and no longer describes a recent-operations surface on the dashboard.
  • T002 Update the focused dashboard tests to the new contract: no recent-operations section, attention-only KPI copy, operations attention recommended action, and Operations requiring attention card with Review operation / Open operations hub.
  • T003 Re-run the focused dashboard test slice to capture the exact implementation failures against the new contract.
  • T004 Refactor TenantDashboardSummaryBuilder to centralize a tenant/workspace-scoped attention query and reuse it for KPI counts, recommended action visibility, and the operations attention card.
  • T005 Replace the old single highlighted-run payload with a curated 1-3 item attention-card payload that exposes title, outcome sentence, reason, impact, relative time, and canonical review links.
  • T006 Update dashboard localization so KPI and recommended-action copy match the new decision-first operations wording in EN and DE.
  • T007 Remove the recent-operations section from the tenant dashboard overview Blade and render the new attention-card layout with one card-level hub CTA and per-item review CTAs.
  • T008 Keep the dashboard navigation and RBAC contract canonical: no new route strings, no cross-tenant leakage, no destructive actions, and no dashboard-owned operations history surface.
  • T009 Run export PATH="/bin:/usr/bin:/usr/local/bin:$PATH" && cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Feature/Dashboard/TenantDashboardProductizationSummaryTest.php tests/Feature/Dashboard/TenantDashboardProductizationActionsTest.php tests/Feature/Filament/TenantDashboardDbOnlyTest.php tests/Browser/Dashboard/TenantDashboardProductizationSmokeTest.php.
  • T010 Run export PATH="/bin:/usr/bin:/usr/local/bin:$PATH" && cd apps/platform && ./vendor/bin/sail bin pint --dirty --format agent.
  • T011 Review the changed slice against Filament v5 / Livewire v4 guardrails, canonical Operations Hub ownership, and dashboard decision-first UX boundaries.

Dependencies & Execution Order

Phase Dependencies

  • Phase 1 (Setup): no dependencies; start immediately.
  • Phase 2 (Foundational): depends on Phase 1 and blocks user-story work.
  • Phase 3 (US1): depends on Phase 2 and establishes the compact summary payload plus render slice.
  • Phase 4 (US2): depends on US1 because the attention-first priority rule refines the highlighted summary already introduced there.
  • Phase 5 (US3): depends on US1 and should land with US2 so the summary stays both truthful and quiet.
  • Phase 6 (Polish): depends on all desired user stories being complete.

User Story Dependencies

  • US1 (P1): independently testable after Phase 2 and delivers the core compact-summary contract.
  • US2 (P1): independently testable after US1 and delivers the follow-up-first attention ordering that makes the summary trustworthy.
  • US3 (P1): independently testable after US1 and closes the no-signal or no-visibility calmness contract.

Within Each User Story

  • Extend the listed Pest coverage first and make it fail for the intended gap.
  • Keep runtime edits inside the current summary builder, current overview view, and current shared OperationRun helpers rather than introducing new dashboard infrastructure.
  • Re-run the narrowest affected validation command after each story checkpoint before moving on.

Implementation Strategy

Suggested MVP Scope

  • MVP = US1 + US2 + US3 together. The dashboard slice is only truthful once it appears when warranted, prioritizes stale or follow-up-needed work, and disappears when no qualifying or visible signal exists.

Incremental Delivery

  1. Complete Phase 1 and Phase 2.
  2. Deliver US1 so the compact summary payload and card exist.
  3. Deliver US2 so the highlighted run stays attention-first.
  4. Deliver US3 so the no-signal and no-visibility behavior stays calm and leak-free.
  5. Finish with focused validation and the review-artifact close-out checks.

Team Strategy

  1. Settle the proof owner first.
  2. Parallelize Feature and browser proof updates while keeping runtime changes local to the current summary builder and overview view.
  3. Serialize merges around TenantDashboardSummaryBuilder.php and tenant-dashboard-overview.blade.php so the compact card contract stays coherent.

Deferred Follow-Ups / Non-Goals

  • full shell activity banner rollout on the Tenant Dashboard
  • dashboard-native operations console or a new dashboard widget framework
  • counted, phased, or composite progress rollout work already owned by Specs 270 through 272
  • new OperationRun lifecycle, queue, or notification-policy changes
  • new persistence, cached summary projection, or raw-diagnostics expansion on the dashboard
  • route-family, panel, provider, asset, or global-search changes