ahmido/TenantAtlas
1
0
Fork 0
Code Issues Pull Requests 2 Actions Packages Projects 1 Releases Wiki Activity
86505483bf
TenantAtlas/specs/245-customer-health-score/checklists/requirements.md
ahmido 86505483bf
Some checks failed
Main Confidence / confidence (push) Failing after 52s
Details
feat(customer-health): add decision card to tenant/workspace detail (spec 245) (#283) 
Add Customer Health decision card to tenant & workspace detail pages (spec 245).

What I changed:
- Render a decision-first Customer Health card on tenant and workspace detail pages.
- Reuse `WorkspaceHealthSummaryQuery` and preserve `window` query param.
- Update attention widget link text to "Review health details" and include `?window=`.
- Add/adjust tests to cover new behavior and explainability.
- Run Pint formatting.

Compare URL: https://git.cloudarix.de/ahmido/TenantAtlas/compare/dev...245-customer-health-score

Co-authored-by: Ahmed Darrazi <ahmed.darrazi@live.de>
Reviewed-on: #283
2026-04-27 08:30:01 +00:00

2.6 KiB
Raw Blame History

Specification Quality Checklist: Customer Health Score

Purpose: Validate specification completeness and implementation readiness before the feature moves into the implementation loop
Created: 2026-04-27
Feature: spec.md

Content Quality

  • Business value and operator outcomes stay explicit
  • The first slice is bounded to derived health summaries on the existing /system dashboard
  • Runtime-governance sections are present for an implementation-ready package
  • All mandatory sections are completed

Requirement Completeness

  • No [NEEDS CLARIFICATION] markers remain
  • Requirements are testable and unambiguous
  • Acceptance scenarios are defined for the primary user journeys
  • Edge cases are identified
  • Scope is clearly bounded away from CRM, billing, predictive scoring, and customer-facing health portals
  • Dependencies and assumptions are identified

Feature Readiness

  • The first slice is small enough for a bounded implementation loop
  • The plan identifies concrete repo surfaces likely to change
  • The tasks are ordered, testable, and grouped by user story
  • Foundational work includes the core unknown-handling and review-pack-readiness rules before dashboard adoption
  • No unresolved product question blocks safe implementation of the first slice

Governance Readiness

  • No new persistence is introduced without justification
  • Provider-boundary handling and platform-safe deep-link rules are explicit
  • Existing RBAC and platform-plane access remain authoritative
  • Operator-facing surface changes include the required UI contract sections
  • The UI Action Matrix is populated for the modified Filament dashboard surface
  • The package explicitly requires one platform-safe next link per attention-needed row plus a visible time-basis cue
  • Default-visible content stays operator-first while raw or support-grade detail remains behind existing linked surfaces
  • The package avoids duplicate truth by keeping health derived-only and by reusing centralized SystemHealth semantics
  • Livewire v4 compliance, unchanged provider registration location, no global-search changes, no destructive-action additions, and no asset-strategy changes are explicit in the package

Notes

  • This checklist completes the implementation-ready package alongside spec.md, plan.md, and tasks.md.
  • The active slice stays bounded to one derived customer-health support path, two system dashboard widgets, fixed first-slice dimensions, and focused unit plus feature proof only.