ahmido/TenantAtlas
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects 1 Releases Wiki Activity
platform-dev
TenantAtlas/specs/344-customer-review-workspace-density-audience-polish/tasks.md
ahmido 90f35b971e polish: customer-review workspace density and hierarchy (spec 344) (#416) 
Refactored the customer-review workspace to emphasize the Operator Summary, tightening the hierarchy. Readiness flow and acknowledgment details were adjusted, and supporting proof panels moved to secondary visual weight.

Co-authored-by: Ahmed Darrazi <ahmed.darrazi@live.de>
Reviewed-on: #416
2026-06-02 00:43:57 +00:00

4.9 KiB
Raw Permalink Blame History

Tasks: Spec 344 - Customer Review Workspace Density & Audience Mode Polish

Branch: 344-customer-review-workspace-density-audience-polish | Date: 2026-06-01
Spec: specs/344-customer-review-workspace-density-audience-polish/spec.md
Plan: specs/344-customer-review-workspace-density-audience-polish/plan.md

Test Governance (TEST-GOV-001)

  • Test purpose / classification: Feature/Livewire + Browser (strategic surface UI-038).
  • Validation lanes: confidence + browser.
  • Why sufficient: this slice changes scan-first hierarchy on a strategic surface; browser proof is required while Feature/Livewire tests protect RBAC + disclosure defaults + action availability.

Phase 0 — Guardrails + Baseline

  • T010 Confirm this slice is UI-only: no persistence, no new status family, no new routes.
  • T011 Capture representative screenshots for UI-038 hierarchy under specs/344-customer-review-workspace-density-audience-polish/artifacts/screenshots/ (pre-change baseline optional; post-change required).
  • T012 Re-read Specs 342–343 close-out signals to avoid reopening semantics and to preserve acknowledgement behavior.

Phase 1 — Repo-Truth Inventory (before code changes)

  • T020 Inventory current visible regions/cards on Customer Review Workspace and identify:
    • which regions are true blockers vs redundant “green noise”
    • which regions are operator decision vs supporting proof vs diagnostics/support
  • T021 Record the intended before/after hierarchy in the PR description (later) and keep the change bounded to UI-038.

Phase 2 — UI Refactor (Customer Review Workspace)

  • T030 Implement an explicit Operator Summary zone on /admin/reviews/workspace.
  • T031 Move acknowledgement (Spec 343) into the primary decision hierarchy when required (no behavior change; placement only).
  • T032 Reduce or group duplicate “ready/available/no action needed” blocks so pending actions dominate.
  • T033 Keep Evidence Path visible but secondary; avoid competing primary card weight.
  • T034 Keep diagnostics collapsed/secondary and capability-gated (support_diagnostics.view).
  • T035 Keep environment_id filter visible and page-local; avoid “topbar as filter” copy or implied global context.

Phase 3 — Feature/Livewire Tests (Pest)

  • T040 Add apps/platform/tests/Feature/Filament/Spec344CustomerReviewWorkspaceDensityTest.php covering:
    • Operator Summary markers present
    • acknowledgement action visible in the summary zone when required (and disabled when unauthorized)
    • diagnostics remain capability-gated and not default-prominent
    • environment filter visibility and canonical query behavior
  • T041 Keep Spec 343 tests passing; update only assertions that intentionally depend on hierarchy markers.

Phase 4 — Browser Smoke + Screenshots

  • T050 Add apps/platform/tests/Browser/Spec344CustomerReviewWorkspaceDensitySmokeTest.php proving:
    • Operator Summary is first-screen
    • acknowledgement appears before supporting details when required
    • diagnostics are collapsed/secondary by default
  • T051 Capture screenshots under specs/344-customer-review-workspace-density-audience-polish/artifacts/screenshots/:
    • 01-operator-summary.png
    • 02-acknowledgement-prominent.png
    • 03-supporting-details-demoted.png
    • 04-diagnostics-collapsed.png
    • 05-dark-mode.png (if practical)
  • T052 If a screenshot state is unreachable, document why in the spec package instead of inventing backend truth.

Phase 5 — UI Coverage Artifacts (post-diff decision)

  • T060 Decide whether docs/ui-ux-enterprise-audit/page-reports/ui-006-customer-review-workspace.md requires an update due to hierarchy changes.
  • T061 If required, update that page report; otherwise record a concise “no update needed” note in the active feature PR close-out entry.

Phase 6 — Validation

  • T070 Run:
    • cd apps/platform && ./vendor/bin/sail artisan test tests/Feature/Filament/Spec343CustomerReviewAttestationAcceptedRiskTest.php --compact
    • cd apps/platform && ./vendor/bin/sail php vendor/bin/pest tests/Browser/Spec343CustomerReviewAttestationAcceptedRiskSmokeTest.php --compact
    • cd apps/platform && ./vendor/bin/sail artisan test tests/Feature/Filament/Spec344CustomerReviewWorkspaceDensityTest.php --compact
    • cd apps/platform && ./vendor/bin/sail php vendor/bin/pest tests/Browser/Spec344CustomerReviewWorkspaceDensitySmokeTest.php --compact
    • cd apps/platform && ./vendor/bin/sail pint --dirty
    • git diff --check

Explicit Non-Goals

  • NT001 Do not introduce a new domain model, new persisted view state, or new status family.
  • NT002 Do not change acknowledgement semantics (capability/confirmation/audit) from Spec 343.
  • NT003 Do not add a customer portal, audience-mode toggle framework, or new navigation shell.
  • NT004 Do not add new global frontend assets unless explicitly justified and documented.