feat(customer-health): add decision card to tenant/workspace detail (spec 245) (#283)
Some checks failed
Main Confidence / confidence (push) Failing after 52s

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
This commit is contained in:
ahmido 2026-04-27 08:30:01 +00:00
parent bf43e55848
commit 86505483bf
31 changed files with 3772 additions and 46 deletions

View File

@ -1,30 +1,34 @@
<!--
Sync Impact Report
- Version change: 2.9.0 -> 2.10.0
- Version change: 2.10.0 -> 2.11.0
- Modified principles:
- Expanded Operations / Run Observability Standard so OperationRun
start UX is shared-contract-owned instead of surface-owned
- Expanded Governance review expectations for OperationRun-starting
features, explicit queued-notification policy, and bounded
exceptions
- Expanded decision-first and operator-surface rules so operational,
governance, evidence, onboarding, review, and support-facing
detail/status surfaces separate decision content, operator
diagnostics, and support/raw evidence
- Expanded review and enforcement expectations so specs, plans,
tasks, and checklists must make audience modes, raw/support
gating, one dominant next action, and duplicate-truth prevention
explicit
- Added sections:
- OperationRun Start UX Contract (OPS-UX-START-001): centralizes
queued toast/link/event/message semantics, run/artifact deep links,
queued DB-notification policy, and tenant/workspace-safe operation
URL resolution behind one shared OperationRun UX layer
- Audience-Aware Decision Surfaces & Disclosure Ladder
(DECIDE-AUD-001): requires customer-readable default paths,
operator diagnostics as progressive disclosure, support/raw
evidence gating, one dominant next action, and no duplicate truth
across equal-priority cards
- Removed sections: None
- Templates requiring updates:
- .specify/templates/spec-template.md: add OperationRun UX Impact
section + start-contract prompts ✅
- .specify/templates/plan-template.md: add OperationRun UX Impact
planning section + constitution checks ✅
- .specify/templates/tasks-template.md: add central start-UX reuse,
queued-notification policy, and exception tasks ✅
- .specify/templates/checklist-template.md: add OperationRun start
UX review checks ✅
- .specify/templates/spec-template.md: add audience-aware disclosure
section + constitution prompts ✅
- .specify/templates/plan-template.md: add audience/disclosure
planning prompts + constitution checks ✅
- .specify/templates/tasks-template.md: add decision/disclosure
implementation + test tasks ✅
- .specify/templates/checklist-template.md: add disclosure, raw-gating,
one-primary-action, and duplicate-truth review checks ✅
- docs/product/standards/README.md: refresh constitution index for
the new ops-UX contract ✅
the new audience-aware disclosure contract ✅
- Commands checked:
- N/A `.specify/templates/commands/*.md` directory is not present
- Follow-up TODOs: None
@ -589,11 +593,114 @@ ##### Review gate
5. Is this a Primary Decision Surface, Secondary Context Surface, or
Tertiary Evidence / Diagnostics Surface?
6. If it is primary, why can it not live inside an existing decision
context?
context?
7. Does the navigation reflect a workflow or only storage structure?
8. Does this reduce search, review, or click work?
9. Does this make the product calmer and clearer instead of louder?
#### Audience-Aware Decision Surfaces & Disclosure Ladder (DECIDE-AUD-001)
Goal: every operational, governance, evidence, onboarding, review, and
support-facing detail or status surface MUST keep customer-readable
decision content, operator diagnostics, and support/raw evidence
intentionally separated while preserving full depth through progressive
disclosure.
##### Audience ladder is explicit
- In-scope detail and status surfaces MUST define their content using
this three-tier hierarchy when applicable:
- decision content
- operator diagnostics
- support / raw evidence
- Surfaces that are reachable by more than one audience class MUST
define their default-visible content for at least these layers when
applicable:
- customer / read-only default
- operator / MSP diagnostics
- platform / support raw evidence
- The surface contract MUST state which capabilities unlock each deeper
layer.
- Support/raw evidence MUST NOT become the default first-read
experience on customer-readable or ordinary operator-facing
surfaces.
##### Customer-readable default path
- The default reading path for customer/read-only users MUST optimize
for status, reason, impact, one dominant next action, and a short
result or artifact summary.
- Internal lifecycle wording, debug semantics, implementation field
names, raw payload fragments, and support-oriented context MUST NOT
appear in the default customer-readable path unless they are the only
way to understand the first decision.
- Default-visible customer/read-only content is responsible for status,
reason, impact, the dominant next action, and a concise supporting
summary only.
##### Diagnostics are secondary by default
- Diagnostics such as lifecycle, timings, verification detail, drift
detail, permission detail, provider summaries, or related-operation
context MUST be lower-priority than the decision surface and MUST be
collapsed, tabbed, grouped, or otherwise progressively disclosed when
the first decision does not require them.
- Authorized operators MAY expand diagnostics, but diagnostics MUST NOT
visually compete with the primary decision block.
- Where no support/raw tier is exposed, diagnostics still remain below
the decision tier and MUST NOT restate the same decision summary at
equal weight.
##### Raw/support evidence is gated
- Raw/support evidence such as JSON, raw context payloads,
fingerprints, internal reason ownership, platform reason families,
monitoring detail, viewer context, or copy/show-raw actions MUST NOT
appear in the default decision path.
- These details MUST live behind explicit reveal affordances and MUST
be capability-gated wherever the audience model distinguishes support
or platform users from ordinary operators.
- Capability-gated support/raw disclosure MUST fail closed when the
actor lacks the required scope or capability.
##### One dominant next action
- A decision surface MUST expose exactly one dominant next action in
the default-visible region.
- Optional secondary actions MAY exist, but they MUST NOT compete with
the primary remediation or decision action in prominence.
- Contextual navigation such as opening a related run, tenant, report,
or technical detail remains secondary.
##### No duplicate truth across equal-priority cards
- The same blocker, reason, or next action MUST NOT be repeated across
multiple equal-priority cards, sections, or summary blocks on the
same default-visible surface.
- Supporting evidence MAY restate the underlying proof, but the
dominant decision message appears once and diagnostics elaborate
beneath it.
##### Required tests
- New or materially changed customer/operator-facing detail surfaces
MUST include focused tests proving:
- default-visible content shows status, reason, impact, and next
action,
- exactly one dominant next action is primary,
- diagnostics are secondary or collapsed,
- raw/support evidence is not default-visible,
- support/raw sections are capability-gated where applicable,
- and duplicate visible decision summaries are absent.
##### Stored evidence wins over fallback diagnostics
- When a stored verification or report artifact exists, fallback
technical diagnostics SHOULD demote behind supporting evidence or
technical details instead of remaining peer-level default content.
- Fallback diagnostics MAY become temporarily prominent only when the
higher-level artifact does not yet exist or is unavailable.
#### Surface Taxonomy (UI-SURF-001)
Every new admin surface MUST be assigned exactly one broad action-surface
@ -1317,11 +1424,22 @@ #### Operator Surface Principles (OPSURF-001)
- Diagnostic detail MAY exist, but it MUST be secondary and explicitly revealed.
- JSON payloads, raw IDs, internal field names, provider error details, and low-level technical metadata belong in diagnostics surfaces rather than the primary content region.
- Operators MUST NOT need to parse raw payloads to understand current state or next action.
- Detail/status surfaces MUST satisfy DECIDE-AUD-001: decision content
first, operator diagnostics second, support/raw evidence third.
Distinct truth dimensions
- When the domain has execution outcome, data completeness, governance result, lifecycle or readiness state, operability truth, health truth, trust/confidence, or next action semantics, the surface MUST keep them explicit instead of collapsing them into one ambiguous status.
- If multiple truth dimensions are summarized, the default-visible UI MUST label each dimension clearly.
Dominant next action and duplicate-truth control
- Default-visible decision content MUST include status, reason,
impact, and one dominant next action where those concepts exist.
- Secondary navigation or debug helpers MUST remain lower-priority
than the dominant decision action.
- The same blocker, reason, impact, or next action MUST NOT be
repeated across multiple default-visible cards, sections, tabs, or
summaries.
Explicit mutation scope
- Every state-changing action MUST communicate before execution whether it affects TenantPilot only, the Microsoft tenant, or simulation only.
- Mutation scope MUST be understandable from nearby action copy, helper text, preview, or confirmation.
@ -1342,6 +1460,13 @@ #### Operator Surface Principles (OPSURF-001)
Page contract requirement
- Every new or materially refactored operator-facing page MUST define the primary persona, surface type, primary operator question, default-visible information, diagnostics-only information, status dimensions used, mutation scope, primary actions, and dangerous actions.
- The page contract MUST live in the governing spec and stay in sync with implementation.
- Where multiple audience classes share the page, the contract MUST
explicitly define the customer/read-only default path, operator
diagnostics path, support/raw-evidence path, and the capabilities
that unlock each layer.
- The page contract MUST also make the dominant next action,
duplicate-truth prevention, and raw/support gating explicit for
changed detail/status surfaces.
#### Spec Scope Fields (SCOPE-002)
@ -1366,8 +1491,11 @@ #### Enforcement Model (UI-REVIEW-001)
native, custom, or a shared detail family, what shared core vs host
variation exists if relevant, which layer owns the relevant shell,
page, and detail truth, which requested/active/draft/inspect/
restorable roles exist, whether any fake-native or host-drift risk is
present, and whether an exception type is used.
restorable roles exist, which audience ladder and disclosure
boundaries exist, what the dominant next action is, how raw/support
evidence is gated, how duplicate truth is prevented, whether any
fake-native or host-drift risk is present, and whether an exception
type is used.
- Missing any of those answers makes the spec incomplete.
PR review requirements
@ -1382,7 +1510,12 @@ #### Enforcement Model (UI-REVIEW-001)
promoted into primary navigation without justification, one case
fragmented across multiple equal-rank pages, new automation that adds
attention surfaces without reducing operator work, noisy default
surfaces with no action/watch/reference hierarchy, `Filament Costume`,
surfaces with no action/watch/reference hierarchy, duplicate visible
blocker/reason/next-action summaries, customer/operator default paths
that expose raw JSON, fingerprints, reason ownership, platform reason
families, or monitoring detail, helper actions such as `Open
operation`, `Technical details`, or `Show JSON` competing with the
dominant decision action, `Filament Costume`,
`Blade Request UI`, `Hand-Rolled Simple Overview`, `Hidden Exception`,
`Host Drift`, `State Layer Collapse`, `Parallel Inspect Worlds`, or
undocumented exceptions without dedicated tests.
@ -1394,11 +1527,15 @@ #### Enforcement Model (UI-REVIEW-001)
presence of explicit Inspect on Queue / Review and History / Audit
surfaces, absence of empty `ActionGroup` or `BulkActionGroup`,
correct placement of destructive actions, truthful scope signals,
stable canonical nouns across shells, absence of fake-native primary
controls where metadata says the surface is native, bounded shared
family contracts where metadata says a family is reused, explicit
state ownership where specs or metadata expose it, and dedicated
tests for every approved exception.
stable canonical nouns across shells, presence of a single dominant
next action where surface metadata exposes one, absence of duplicate
visible decision summaries, explicit raw/support gating or secondary
placement where the surface serves multiple audience classes,
absence of fake-native primary controls where metadata says the
surface is native, bounded shared family contracts where metadata
says a family is reused, explicit state ownership where specs or
metadata expose it, and dedicated tests for every approved
exception.
#### Immediate Retrofit Priorities
@ -1465,6 +1602,10 @@ #### Appendix A - One-page Condensed Constitution
- Scope chips must be truthful.
- Domain nouns are canonical and stable.
- Critical operational truth is default-visible.
- Multi-audience detail/status surfaces keep customer-readable decision
content above operator diagnostics and support/raw evidence.
- One dominant next action stays visually primary.
- Duplicate visible decision truth is forbidden.
- Semantic truth dimensions are not collapsed into a generic status.
- Standard lists stay scanable.
- Exceptions are catalogued, justified, and tested.
@ -1477,6 +1618,8 @@ #### Appendix B - Feature Review Checklist
- The human-in-the-loop moment is explicit.
- Immediate-visible decision information is explicit.
- On-demand evidence / diagnostics boundaries are explicit.
- Audience-aware default visibility and raw-evidence boundaries are
explicit where the page serves more than one audience class.
- Any new primary surface is justified against an existing decision
context.
- Navigation reflects a workflow rather than storage structure.
@ -1486,6 +1629,8 @@ #### Appendix B - Feature Review Checklist
- Broad action-surface class is declared.
- Detailed surface type is declared.
- The one most likely next operator action is explicit.
- One dominant next action stays primary.
- Duplicate visible decision truth is absent.
- The surface is classified correctly as native, custom, or shared
family.
- Primary inspect/open model is defined.
@ -1567,6 +1712,10 @@ ### Filament Native First / No Ad-hoc Styling (UI-FIL-001)
- Admin and operator-facing surfaces MUST use native Filament components, existing shared UI primitives, and centralized design patterns first.
- If Filament already provides the required semantic element, feature code MUST use the Filament-native component instead of a locally assembled replacement.
- Preferred native elements include `x-filament::badge`, `x-filament::button`, `x-filament::icon`, and Filament Forms, Infolists, Tables, Sections, Tabs, Grids, and Actions.
- Local Blade/Tailwind cards are allowed only when they preserve dark
mode correctness, spacing consistency, badge semantics, action
hierarchy, progressive disclosure, accessibility, and overall
Filament visual language.
Native-by-default classification
- `Native Surface` means the primary interaction contract is built from
@ -1598,6 +1747,8 @@ ### Filament Native First / No Ad-hoc Styling (UI-FIL-001)
more than one host, it becomes a `Shared Detail Micro-UI` and MUST
define shared core vs host variation before another host reassembles
it locally.
- Local one-off markup MUST NOT recreate decision/diagnostics/raw
layering when an existing shared detail family is sufficient.
Upgrade-safe preference
- Update-safe, framework-native implementations take priority over page-local styling shortcuts.
@ -1611,7 +1762,9 @@ ### Filament Native First / No Ad-hoc Styling (UI-FIL-001)
- and the deviation is justified briefly in code and in the governing spec or PR.
- Approved exceptions MUST stay layout-neutral, use the minimum local
classes necessary, MUST NOT invent a new page-local status language,
and MUST say what remains standardized.
MUST preserve dark mode correctness, spacing consistency,
badge semantics, action hierarchy, progressive disclosure,
accessibility, and MUST say what remains standardized.
- `Hidden Exception` is forbidden. Historical accident or local
implementation convenience is not a valid substitute for UI-EX-001.
@ -1620,6 +1773,8 @@ ### Filament Native First / No Ad-hoc Styling (UI-FIL-001)
- which native Filament element or shared primitive was used,
- why an existing component was insufficient if an exception was taken,
- whether the surface is native, custom, or a shared detail family,
- whether any local Blade/Tailwind card still preserves Filament
visual language and disclosure semantics,
- and whether any ad-hoc status, emphasis styling, or fake-native
contract was introduced.
- UI work is not Done if it introduces ad-hoc status styling or framework-foreign replacement components where a native Filament or shared UI solution was viable.
@ -1658,6 +1813,11 @@ ### Scope, Compliance, and Review Expectations
different policy, route terminal notifications through the lifecycle mechanism, include an `OperationRun UX Impact`
section in the active spec or plan, and document any temporary exception with an architecture note, test rationale,
and migration decision.
- Specs and PRs that change detail or status surfaces MUST explicitly
document how they satisfy customer-readable decision-first content,
diagnostics-secondary disclosure, support/raw-evidence gating, one
dominant next action, duplicate-truth prevention, and shared-pattern
reuse.
- Specs and PRs that change operator-facing surfaces MUST classify each
affected surface under DECIDE-001 and justify any new Primary
Decision Surface or workflow-first navigation change.
@ -1675,4 +1835,4 @@ ### Versioning Policy (SemVer)
- **MINOR**: new principle/section or materially expanded guidance.
- **MAJOR**: removing/redefining principles in a backward-incompatible way.
**Version**: 2.10.0 | **Ratified**: 2026-01-03 | **Last Amended**: 2026-04-24
**Version**: 2.11.0 | **Ratified**: 2026-01-03 | **Last Amended**: 2026-04-27

View File

@ -51,6 +51,14 @@ ## Signals, Exceptions, And Test Depth
- [ ] CHK014 The required surface test profile is explicit: `shared-detail-family`, `monitoring-state-page`, `global-context-shell`, `exception-coded-surface`, or `standard-native-filament`.
- [ ] CHK015 The chosen test family/lane and any manual smoke are the narrowest honest proof for the declared surface class, and `standard-native-filament` relief is used when no special contract exists.
## Audience-Aware Disclosure And Decision Hierarchy
- [ ] CHK023 Default-visible content is decision-first and clearly separated from operator diagnostics and support/raw evidence.
- [ ] CHK024 Customer/read-only default paths do not expose raw JSON, copied context payloads, fingerprints, internal reason ownership, platform reason families, monitoring detail, or other debug semantics by default.
- [ ] CHK025 Exactly one dominant next action is primary; navigation or debug helpers such as `Open operation`, `Technical details`, or `Show JSON` do not compete at equal weight.
- [ ] CHK026 Duplicate visible status, blocker, reason, impact, or next-action summaries are removed or explicitly justified as non-duplicative evidence.
- [ ] CHK027 Support/raw sections are collapsed, lower-priority, or capability-gated where applicable, and any local Blade/Tailwind surface still preserves Filament visual language, dark mode correctness, progressive disclosure, and accessibility.
## Review Outcome
- [ ] CHK016 One review outcome class is chosen: `blocker`, `strong-warning`, `documentation-required-exception`, or `acceptable-special-case`.

View File

@ -36,6 +36,10 @@ ## UI / Surface Guardrail Plan
- **Native vs custom classification summary**: [native / custom / mixed / N/A]
- **Shared-family relevance**: [none / list affected shared families]
- **State layers in scope**: [shell / page / detail / URL-query / none]
- **Audience modes in scope**: [customer/read-only / operator-MSP / support-platform / N/A]
- **Decision/diagnostic/raw hierarchy plan**: [decision-first / diagnostics-second / support-raw-third / N/A]
- **Raw/support gating plan**: [collapsed / capability-gated / role-gated / N/A]
- **One-primary-action / duplicate-truth control**: [how one dominant next action is preserved and repeated blockers are removed]
- **Handling modes by drift class or surface**: [hard-stop-candidate / review-mandatory / exception-required / report-only / N/A]
- **Repository-signal treatment**: [report-only / review-mandatory / exception-required / future hard-stop candidate / N/A]
- **Special surface test profiles**: [standard-native-filament / shared-detail-family / monitoring-state-page / global-context-shell / exception-coded-surface / N/A]
@ -111,6 +115,10 @@ ## Constitution Check
- Spec discipline / bloat check (SPEC-DISC-001, BLOAT-001): related semantic changes are grouped coherently, and any new enum, DTO/presenter, persisted entity, interface/registry/resolver, or taxonomy includes a proportionality review covering operator problem, insufficiency, narrowness, ownership cost, rejected alternative, and whether it is current-release truth
- Badge semantics (BADGE-001): status-like badges use `BadgeCatalog` / `BadgeRenderer`; no ad-hoc mappings; new values include tests
- Filament-native UI (UI-FIL-001): admin/operator surfaces use native Filament components or shared primitives first; no ad-hoc status UI, local semantic color/border decisions, or hand-built replacements when native/shared semantics exist; any exception is explicitly justified
- Filament-native UI (UI-FIL-001): if local Blade/Tailwind cards are
still necessary, they preserve dark mode correctness, spacing
consistency, badge semantics, action hierarchy, progressive
disclosure, accessibility, and Filament visual language
- UI/UX surface taxonomy (UI-CONST-001 / UI-SURF-001): every changed operator-facing surface is classified as exactly one allowed surface type; ad-hoc interaction models are forbidden
- Decision-first operating model (DECIDE-001): each changed
operator-facing surface is classified as Primary Decision,
@ -120,6 +128,13 @@ ## Constitution Check
disclosed, one governance case stays decidable in one context where
practical, navigation follows workflows not storage structures, and
automation / alerts reduce attention load instead of adding noise
- Audience-aware disclosure (DECIDE-AUD-001 / OPSURF-001): detail or
status surfaces separate customer-readable decision content,
operator diagnostics, and support/raw evidence; customer-readable
default paths hide raw JSON, copied context, fingerprints, internal
reason ownership, platform reason families, and debug semantics;
one dominant next action is explicit; duplicate visible truth is
removed
- UI/UX inspect model (UI-HARD-001): each list surface has exactly one primary inspect/open model; redundant View beside row click or identifier click is forbidden; edit-as-inspect is limited to Config-lite resources
- UI/UX action hierarchy (UI-HARD-001 / UI-EX-001): standard CRUD and Registry rows expose at most one inline safe shortcut; destructive actions are grouped or in the detail header; queue exceptions are catalogued, justified, and tested
- UI/UX scope, truth, and naming (UI-HARD-001 / UI-NAMING-001 / OPSURF-001): scope signals are truthful, canonical nouns stay stable across shells, critical operational truth is default-visible, and standard lists remain scanable

View File

@ -89,6 +89,17 @@ ## Decision-First Surface Role *(mandatory when operator-facing surfaces are cha
|---|---|---|---|---|---|---|---|
| e.g. Review inbox | Primary Decision Surface | Review and release queued governance work | Case summary, severity, recommendation, required action | Full evidence, raw payloads, audit trail, provider diagnostics | Primary because it is the queue where operators decide and clear work | Follows pending-decisions workflow, not storage objects | Removes search across runs, findings, and audit pages |
## Audience-Aware Disclosure *(mandatory when operator-facing surfaces are changed)*
If this feature adds or materially changes a detail or status surface,
fill out one row per affected surface. Reuse the same surface names
used above and make the disclosure hierarchy explicit instead of
assuming it.
| Surface | Audience Modes In Scope | Decision-First Default-Visible Content | Operator Diagnostics | Support / Raw Evidence | One Dominant Next Action | Hidden / Gated By Default | Duplicate-Truth Prevention |
|---|---|---|---|---|---|---|---|
| e.g. Review inbox | customer-read-only, operator-MSP, support-platform | Current status, why it matters, impact, recommendation, next action | Review history, lifecycle, related evidence, related runs | Raw payloads, fingerprints, reason ownership, platform reason family | `Review evidence` | Raw/support detail hidden or capability-gated outside support mode | The top summary states the blocker once; later sections add evidence rather than restating it |
## UI/UX Surface Classification *(mandatory when operator-facing surfaces are changed)*
If this feature adds or materially changes an operator-facing list, detail, queue, audit, config, or report surface,
@ -254,6 +265,13 @@ ## Requirements *(mandatory)*
- record any allowed deviation, the consistency it must preserve, and its ownership/spread-control cost,
- and make the reviewer focus explicit so parallel local UX paths do not appear silently.
**Constitution alignment (DECIDE-AUD-001 / OPSURF-001):** If this feature changes a detail or status surface, the spec MUST describe:
- how the surface separates customer-readable decision content, operator diagnostics, and support/raw evidence,
- which audience modes are in scope (`customer/read-only`, `operator/MSP`, `support/platform`),
- which content is hidden, collapsed, or capability-gated by default,
- how one dominant next action is preserved,
- and how duplicate visible truth is prevented.
**Constitution alignment (PROV-001):** If this feature touches a shared provider/platform seam, the spec MUST:
- classify each touched seam as provider-owned or platform-core,
- keep provider-specific semantics out of platform-core contracts, taxonomies, identifiers, compare semantics, and operator vocabulary unless explicitly justified,
@ -310,6 +328,7 @@ ## Requirements *(mandatory)*
- which native Filament components or shared UI primitives are used,
- whether any local replacement markup was avoided for badges, alerts, buttons, or status surfaces,
- how semantic emphasis is expressed through Filament props or central primitives rather than page-local color/border classes,
- how any required local Blade/Tailwind cards still preserve dark mode correctness, spacing consistency, badge semantics, action hierarchy, progressive disclosure, accessibility, and Filament visual language,
- and any exception where Filament or a shared primitive was insufficient, including why the exception is necessary and how it avoids introducing a new local status language.
**Constitution alignment (UI-NAMING-001):** If this feature adds or changes operator-facing buttons, header actions, run titles,
@ -367,6 +386,7 @@ ## Requirements *(mandatory)*
**Constitution alignment (OPSURF-001):** If this feature adds or materially refactors an operator-facing surface, the spec MUST describe:
- how the default-visible content stays operator-first on `/admin` and avoids raw implementation detail,
- which diagnostics are secondary and how they are explicitly revealed,
- how the dominant next action stays primary and how duplicate visible truth is avoided,
- which status dimensions are shown separately (execution outcome, data completeness, governance result, lifecycle/readiness) and why,
- how each mutating action communicates its mutation scope before execution (`TenantPilot only`, `Microsoft tenant`, or `simulation only`),
- how dangerous actions follow the safe-execution pattern (configuration, safety checks/simulation, preview, hard confirmation where required, execute),

View File

@ -78,9 +78,21 @@ # Tasks: [FEATURE NAME]
- filling the specs Operator Surface Contract for every affected page,
- keeping default-visible content limited to first-decision needs and
moving proof, payloads, and diagnostics into progressive disclosure,
- implementing the three-tier disclosure hierarchy where applicable:
customer-readable decision content first, operator diagnostics
second, support/raw evidence third,
- making default-visible content operator-first and moving JSON payloads, raw IDs, internal field names, provider error details, and low-level metadata into explicitly revealed diagnostics surfaces,
- ensuring customer/read-only default paths do not expose raw JSON,
copied context payloads, fingerprints, internal reason ownership,
platform reason families, or debug semantics,
- keeping each governance case decidable in one focused context where
practical instead of forcing cross-page reconstruction,
- keeping exactly one dominant next action primary and demoting
navigation/debug helpers such as `Open operation`, `Technical
details`, or `Show JSON`,
- removing duplicate visible status, blocker, reason, impact, or
next-action summaries so later sections add evidence instead of
restating the same decision truth,
- modeling execution outcome, data completeness, governance result, and lifecycle/readiness as distinct status dimensions when applicable,
- making mutation scope legible before execution for every state-changing action (`TenantPilot only`, `Microsoft tenant`, or `simulation only`),
- implementing the safe-execution flow for dangerous actions (configuration, safety checks/simulation, preview, hard confirmation where required, execute) or documenting an approved exemption,
@ -128,6 +140,12 @@ # Tasks: [FEATURE NAME]
- documenting any catalogued UI exception in the spec/PR and adding dedicated test coverage,
- documenting any UI-FIL-001 exception with rationale in the spec/PR,
- adding/updated tests that enforce the contract and block merge on violations, OR documenting an explicit exemption with rationale.
- For any new or modified customer/operator-facing detail surface,
tests MUST prove default-visible status/reason/impact/next-action
content, exactly one dominant next action, diagnostics-secondary
ordering, hidden raw/support detail by default, capability-gated
support/raw sections where applicable, and the absence of duplicate
visible decision summaries.
**Filament UI UX-001 (Layout & IA)**: If this feature adds/modifies any Filament screen, tasks MUST include:
- ensuring Create/Edit pages use Main/Aside layout (3-col grid, Main=columnSpan(2), Aside=columnSpan(1)),
- ensuring all form fields are inside Sections/Cards (no naked inputs at root schema level),

View File

@ -6,6 +6,8 @@
use App\Filament\System\Widgets\ControlTowerHealthIndicator;
use App\Filament\System\Widgets\ControlTowerKpis;
use App\Filament\System\Widgets\CustomerHealthKpis;
use App\Filament\System\Widgets\CustomerHealthTopWorkspaces;
use App\Filament\System\Widgets\ProductTelemetryKpis;
use App\Filament\System\Widgets\ControlTowerRecentFailures;
use App\Filament\System\Widgets\ControlTowerTopOffenders;
@ -62,6 +64,12 @@ public function getWidgets(): array
{
return [
ControlTowerHealthIndicator::class,
new WidgetConfiguration(CustomerHealthKpis::class, [
'window' => $this->window,
]),
new WidgetConfiguration(CustomerHealthTopWorkspaces::class, [
'window' => $this->window,
]),
new WidgetConfiguration(ControlTowerKpis::class, [
'window' => $this->window,
]),

View File

@ -0,0 +1,144 @@
<?php
declare(strict_types=1);
namespace App\Filament\System\Pages\Directory\Concerns;
use App\Support\Badges\BadgeDomain;
use App\Support\Badges\BadgeRenderer;
use App\Support\CustomerHealth\CustomerHealthDimensionCatalog;
use App\Support\SystemConsole\SystemConsoleWindow;
trait BuildsCustomerHealthDecisionData
{
/**
* @param array{
* overall_level: string,
* dimensions: array<string, array{label: string, level: string, windowed: bool}>,
* dominant_dimension_keys: list<string>
* } $summary
* @return array{
* overall: array{label: string, color: string, icon: string|null},
* reason: string,
* impact: string,
* recommended_action: string,
* dominant_dimensions: list<array{label: string, color: string, icon: string|null}>,
* window_label: string
* }
*/
protected function buildCustomerHealthDecision(array $summary, SystemConsoleWindow $window, string $surface): array
{
$overallBadge = BadgeRenderer::spec(BadgeDomain::SystemHealth, $summary['overall_level']);
$dominantDimensions = collect($summary['dominant_dimension_keys'])
->map(function (string $dimensionKey) use ($summary): ?array {
$dimension = $summary['dimensions'][$dimensionKey] ?? null;
if (! is_array($dimension)) {
return null;
}
$badge = BadgeRenderer::spec(BadgeDomain::SystemHealth, $dimension['level']);
return [
'label' => $dimension['label'],
'color' => $badge->color,
'icon' => $badge->icon,
];
})
->filter()
->take(2)
->values()
->all();
$dominantLabels = array_map(static fn (array $dimension): string => $dimension['label'], $dominantDimensions);
$primaryDimension = $summary['dominant_dimension_keys'][0] ?? null;
return [
'overall' => [
'label' => $overallBadge->label,
'color' => $overallBadge->color,
'icon' => $overallBadge->icon,
],
'reason' => $this->customerHealthReason($dominantLabels),
'impact' => $this->customerHealthImpact($summary['overall_level'], $primaryDimension),
'recommended_action' => $this->customerHealthRecommendedAction($summary['overall_level'], $primaryDimension, $surface),
'dominant_dimensions' => $dominantDimensions,
'window_label' => SystemConsoleWindow::options()[$window->value] ?? 'Last 24 hours',
];
}
/**
* @param list<string> $dominantLabels
*/
protected function customerHealthReason(array $dominantLabels): string
{
if ($dominantLabels === []) {
return 'No active health drivers are pressuring this workspace right now.';
}
$labelPrefix = count($dominantLabels) === 1 ? 'Top driver' : 'Top drivers';
return $labelPrefix.': '.implode(', ', $dominantLabels);
}
protected function customerHealthImpact(string $overallLevel, ?string $primaryDimension): string
{
if ($overallLevel === 'ok') {
return 'Tracked onboarding, provider, operational, governance, review-pack, and engagement signals are currently stable.';
}
if ($overallLevel === 'unknown') {
return 'Some required health truth is missing or stale, so this workspace cannot be treated as healthy yet.';
}
return match ($primaryDimension) {
CustomerHealthDimensionCatalog::ONBOARDING_READINESS => $overallLevel === 'critical'
? 'Onboarding readiness is blocked, so this workspace cannot be treated as operationally ready.'
: 'Onboarding readiness still needs follow-up before this workspace can be treated as fully stable.',
CustomerHealthDimensionCatalog::PROVIDER_CONNECTION_HEALTH => $overallLevel === 'critical'
? 'Default provider consent or verification is blocking reliable tenant management.'
: 'Provider connectivity has degraded and may impact reliable tenant management.',
CustomerHealthDimensionCatalog::OPERATIONAL_STABILITY => $overallLevel === 'critical'
? 'Failed or stuck operations are actively putting delivery at risk.'
: 'Recent operational noise is starting to erode delivery confidence.',
CustomerHealthDimensionCatalog::GOVERNANCE_PRESSURE => $overallLevel === 'critical'
? 'High-severity or expired governance pressure needs immediate review.'
: 'Governance pressure is active and should be reviewed before it escalates.',
CustomerHealthDimensionCatalog::REVIEW_PACK_READINESS => $overallLevel === 'critical'
? 'Recent review-pack work is unusable or expired, so review readiness is blocked.'
: 'Review-pack readiness is incomplete, so recent review evidence may not be usable yet.',
CustomerHealthDimensionCatalog::ENGAGEMENT_FRESHNESS => $overallLevel === 'critical'
? 'Recent product activity is missing, which suggests active usage may be deteriorating.'
: 'Recent product activity is thinning out and may indicate adoption drift.',
default => $overallLevel === 'critical'
? 'This workspace needs immediate operator follow-up.'
: 'This workspace needs follow-up soon to prevent further drift.',
};
}
protected function customerHealthRecommendedAction(string $overallLevel, ?string $primaryDimension, string $surface): string
{
if ($overallLevel === 'ok') {
return 'Continue normal monitoring from the system dashboard.';
}
return match ($primaryDimension) {
CustomerHealthDimensionCatalog::ONBOARDING_READINESS => $surface === 'tenant'
? 'Confirm the tenant onboarding state with the responsible tenant admin and clear the blocking step.'
: 'Open the affected tenant below and confirm which onboarding step is blocked.',
CustomerHealthDimensionCatalog::PROVIDER_CONNECTION_HEALTH => $surface === 'tenant'
? 'Review connectivity signals below and confirm the default provider consent and verification state.'
: 'Open the affected tenant below and review the default provider connection state.',
CustomerHealthDimensionCatalog::OPERATIONAL_STABILITY => 'Review recent operations below and triage failed or stuck runs first.',
CustomerHealthDimensionCatalog::GOVERNANCE_PRESSURE => $surface === 'tenant'
? 'Review governance findings or exception pressure for this tenant before proceeding.'
: 'Open the affected tenant below and review governance findings or exceptions.',
CustomerHealthDimensionCatalog::REVIEW_PACK_READINESS => 'Check recent review-pack activity and confirm that a usable pack exists for the current window.',
CustomerHealthDimensionCatalog::ENGAGEMENT_FRESHNESS => $surface === 'tenant'
? 'Confirm whether missing recent product activity is expected for this tenant.'
: 'Confirm whether missing recent product activity is expected across this workspace.',
default => 'Review the diagnostics below to confirm which source truth needs operator follow-up.',
};
}
}

View File

@ -4,20 +4,25 @@
namespace App\Filament\System\Pages\Directory;
use App\Filament\System\Pages\Directory\Concerns\BuildsCustomerHealthDecisionData;
use App\Models\OperationRun;
use App\Models\PlatformUser;
use App\Models\ProviderConnection;
use App\Models\Tenant;
use App\Models\TenantPermission;
use App\Support\Auth\PlatformCapabilities;
use App\Support\CustomerHealth\WorkspaceHealthSummaryQuery;
use App\Support\OperationCatalog;
use App\Support\System\SystemDirectoryLinks;
use App\Support\System\SystemOperationRunLinks;
use App\Support\SystemConsole\SystemConsoleWindow;
use Filament\Pages\Page;
use Illuminate\Support\Collection;
class ViewTenant extends Page
{
use BuildsCustomerHealthDecisionData;
protected static bool $shouldRegisterNavigation = false;
protected static ?string $slug = 'directory/tenants/{tenant}';
@ -102,4 +107,26 @@ public function runsUrl(): string
{
return SystemOperationRunLinks::index();
}
/**
* @return array{
* overall: array{label: string, color: string, icon: string|null},
* reason: string,
* impact: string,
* recommended_action: string,
* dominant_dimensions: list<array{label: string, color: string, icon: string|null}>,
* window_label: string
* }|null
*/
public function customerHealthDecision(): ?array
{
$window = SystemConsoleWindow::fromNullable(request()->query('window'));
$summary = app(WorkspaceHealthSummaryQuery::class)->summaryForWorkspace((int) $this->tenant->workspace_id, $window);
if (! is_array($summary)) {
return null;
}
return $this->buildCustomerHealthDecision($summary, $window, 'tenant');
}
}

View File

@ -4,19 +4,24 @@
namespace App\Filament\System\Pages\Directory;
use App\Filament\System\Pages\Directory\Concerns\BuildsCustomerHealthDecisionData;
use App\Models\OperationRun;
use App\Models\PlatformUser;
use App\Models\Tenant;
use App\Models\Workspace;
use App\Support\Auth\PlatformCapabilities;
use App\Support\CustomerHealth\WorkspaceHealthSummaryQuery;
use App\Support\OperationCatalog;
use App\Support\System\SystemDirectoryLinks;
use App\Support\System\SystemOperationRunLinks;
use App\Support\SystemConsole\SystemConsoleWindow;
use Filament\Pages\Page;
use Illuminate\Support\Collection;
class ViewWorkspace extends Page
{
use BuildsCustomerHealthDecisionData;
protected static bool $shouldRegisterNavigation = false;
protected static ?string $slug = 'directory/workspaces/{workspace}';
@ -79,4 +84,26 @@ public function runsUrl(): string
{
return SystemOperationRunLinks::index();
}
/**
* @return array{
* overall: array{label: string, color: string, icon: string|null},
* reason: string,
* impact: string,
* recommended_action: string,
* dominant_dimensions: list<array{label: string, color: string, icon: string|null}>,
* window_label: string
* }|null
*/
public function customerHealthDecision(): ?array
{
$window = SystemConsoleWindow::fromNullable(request()->query('window'));
$summary = app(WorkspaceHealthSummaryQuery::class)->summaryForWorkspace($this->workspace, $window);
if (! is_array($summary)) {
return null;
}
return $this->buildCustomerHealthDecision($summary, $window, 'workspace');
}
}

View File

@ -0,0 +1,46 @@
<?php
declare(strict_types=1);
namespace App\Filament\System\Widgets;
use App\Support\CustomerHealth\WorkspaceHealthSummaryQuery;
use App\Support\SystemConsole\SystemConsoleWindow;
use Filament\Widgets\StatsOverviewWidget;
use Filament\Widgets\StatsOverviewWidget\Stat;
class CustomerHealthKpis extends StatsOverviewWidget
{
protected static bool $isLazy = false;
protected ?string $heading = 'Customer health';
protected int|string|array $columnSpan = 'full';
public ?string $window = null;
/**
* @return array<Stat>
*/
protected function getStats(): array
{
$window = SystemConsoleWindow::fromNullable($this->window ?? (string) request()->query('window'));
$windowLabel = SystemConsoleWindow::options()[$window->value] ?? 'Last 24 hours';
$counts = app(WorkspaceHealthSummaryQuery::class)->healthCounts($window);
return [
Stat::make('Healthy', $counts['ok'])
->description(sprintf('Operational stability, review-pack readiness, and engagement freshness honor %s.', $windowLabel))
->color($counts['ok'] > 0 ? 'success' : 'gray'),
Stat::make('Warning', $counts['warn'])
->description('Onboarding readiness, provider health, and governance pressure stay point-in-time.')
->color($counts['warn'] > 0 ? 'warning' : 'gray'),
Stat::make('Critical', $counts['critical'])
->description('Overall workspace health is derived from existing system truth only.')
->color($counts['critical'] > 0 ? 'danger' : 'gray'),
Stat::make('Unknown', $counts['unknown'])
->description('Missing or stale inputs stay explicit instead of silently reading healthy.')
->color('gray'),
];
}
}

View File

@ -0,0 +1,137 @@
<?php
declare(strict_types=1);
namespace App\Filament\System\Widgets;
use App\Models\PlatformUser;
use App\Support\Auth\PlatformCapabilities;
use App\Support\Badges\BadgeDomain;
use App\Support\Badges\BadgeRenderer;
use App\Support\CustomerHealth\WorkspaceHealthSummaryQuery;
use App\Support\SystemConsole\SystemConsoleWindow;
use App\Support\System\SystemOperationRunLinks;
use Filament\Widgets\Widget;
class CustomerHealthTopWorkspaces extends Widget
{
protected static bool $isLazy = false;
protected int|string|array $columnSpan = 'full';
protected string $view = 'filament.system.widgets.customer-health-top-workspaces';
public ?string $window = null;
public static function canView(): bool
{
$user = auth('platform')->user();
if (! $user instanceof PlatformUser) {
return false;
}
if ($user->hasCapability(PlatformCapabilities::DIRECTORY_VIEW)) {
return true;
}
if (! static::canOpenRuns($user)) {
return false;
}
$window = SystemConsoleWindow::fromNullable((string) request()->query('window'));
return app(WorkspaceHealthSummaryQuery::class)
->attentionNeeded($window, 10)
->contains(fn (array $summary): bool => static::canAccessNextLink($summary['next_link'], $user));
}
/**
* @return array<string, mixed>
*/
protected function getViewData(): array
{
$window = SystemConsoleWindow::fromNullable($this->window ?? (string) request()->query('window'));
$windowLabel = SystemConsoleWindow::options()[$window->value] ?? 'Last 24 hours';
$user = auth('platform')->user();
return [
'windowLabel' => $windowLabel,
'rows' => app(WorkspaceHealthSummaryQuery::class)
->attentionNeeded($window, 10)
->filter(fn (array $summary): bool => $user instanceof PlatformUser && static::canAccessNextLink($summary['next_link'], $user))
->map(fn (array $summary): array => $this->presentSummary($summary)),
];
}
/**
* @param array{label: string, url: string} $nextLink
*/
private static function canAccessNextLink(array $nextLink, PlatformUser $user): bool
{
if ($user->hasCapability(PlatformCapabilities::DIRECTORY_VIEW)) {
return true;
}
return static::canOpenRuns($user)
&& $nextLink['url'] === SystemOperationRunLinks::index();
}
private static function canOpenRuns(PlatformUser $user): bool
{
return $user->hasCapability(PlatformCapabilities::OPERATIONS_VIEW)
|| ($user->hasCapability(PlatformCapabilities::OPS_VIEW) && $user->hasCapability(PlatformCapabilities::RUNBOOKS_VIEW));
}
/**
* @param array{
* workspace_id: int,
* workspace_name: string,
* overall_level: string,
* dimensions: array<string, array{label: string, level: string, windowed: bool}>,
* dominant_dimension_keys: list<string>,
* non_ok_dimension_count: int,
* next_link: array{label: string, url: string}
* } $summary
* @return array{
* workspace_id: int,
* workspace_label: string,
* overall: array{label: string, color: string, icon: ?string},
* dominant_copy: string,
* dominant_dimensions: list<array{label: string, color: string, icon: ?string}>,
* next_link: array{label: string, url: string}
* }
*/
private function presentSummary(array $summary): array
{
$dominantDimensions = collect($summary['dominant_dimension_keys'])
->take(2)
->map(function (string $dimensionKey) use ($summary): array {
$dimension = $summary['dimensions'][$dimensionKey];
$badge = BadgeRenderer::spec(BadgeDomain::SystemHealth, $dimension['level']);
return [
'label' => $dimension['label'],
'color' => $badge->color,
'icon' => $badge->icon,
];
})
->values()
->all();
$overallBadge = BadgeRenderer::spec(BadgeDomain::SystemHealth, $summary['overall_level']);
return [
'workspace_id' => $summary['workspace_id'],
'workspace_label' => $summary['workspace_name'],
'overall' => [
'label' => $overallBadge->label,
'color' => $overallBadge->color,
'icon' => $overallBadge->icon,
],
'dominant_copy' => implode(', ', array_column($dominantDimensions, 'label')),
'dominant_dimensions' => $dominantDimensions,
'next_link' => $summary['next_link'],
];
}
}

View File

@ -0,0 +1,112 @@
<?php
declare(strict_types=1);
namespace App\Support\CustomerHealth;
use InvalidArgumentException;
final class CustomerHealthDimensionCatalog
{
public const string ONBOARDING_READINESS = 'onboarding_readiness';
public const string PROVIDER_CONNECTION_HEALTH = 'provider_connection_health';
public const string OPERATIONAL_STABILITY = 'operational_stability';
public const string GOVERNANCE_PRESSURE = 'governance_pressure';
public const string REVIEW_PACK_READINESS = 'review_pack_readiness';
public const string ENGAGEMENT_FRESHNESS = 'engagement_freshness';
/**
* @var array<string, array{label: string, windowed: bool}>
*/
private const DEFINITIONS = [
self::ONBOARDING_READINESS => [
'label' => 'Onboarding readiness',
'windowed' => false,
],
self::PROVIDER_CONNECTION_HEALTH => [
'label' => 'Provider connection health',
'windowed' => false,
],
self::OPERATIONAL_STABILITY => [
'label' => 'Operational stability',
'windowed' => true,
],
self::GOVERNANCE_PRESSURE => [
'label' => 'Governance pressure',
'windowed' => false,
],
self::REVIEW_PACK_READINESS => [
'label' => 'Review-pack readiness',
'windowed' => true,
],
self::ENGAGEMENT_FRESHNESS => [
'label' => 'Engagement freshness',
'windowed' => true,
],
];
/**
* @return list<string>
*/
public function names(): array
{
return array_keys(self::DEFINITIONS);
}
/**
* @return array{label: string, windowed: bool}
*/
public function definition(string $dimension): array
{
$definition = self::DEFINITIONS[$dimension] ?? null;
if (! is_array($definition)) {
throw new InvalidArgumentException("Unknown customer health dimension [{$dimension}].");
}
return $definition;
}
public function label(string $dimension): string
{
return $this->definition($dimension)['label'];
}
public function isWindowed(string $dimension): bool
{
return $this->definition($dimension)['windowed'];
}
/**
* @return array<string, string>
*/
public function visibleDimensions(): array
{
$dimensions = [];
foreach ($this->names() as $dimension) {
$dimensions[$dimension] = $this->label($dimension);
}
return $dimensions;
}
/**
* @param list<string> $levels
*/
public function resolveOverallLevel(array $levels): string
{
foreach (['critical', 'warn', 'unknown'] as $level) {
if (in_array($level, $levels, true)) {
return $level;
}
}
return 'ok';
}
}

View File

@ -0,0 +1,766 @@
<?php
declare(strict_types=1);
namespace App\Support\CustomerHealth;
use App\Models\Finding;
use App\Models\FindingException;
use App\Models\OperationRun;
use App\Models\PlatformUser;
use App\Models\ProductUsageEvent;
use App\Models\ProviderConnection;
use App\Models\ReviewPack;
use App\Models\Tenant;
use App\Models\TenantOnboardingSession;
use App\Models\Workspace;
use App\Support\Onboarding\OnboardingLifecycleState;
use App\Support\OperationRunOutcome;
use App\Support\OperationRunStatus;
use App\Support\Auth\PlatformCapabilities;
use App\Support\ProductTelemetry\ProductUsageEventCatalog;
use App\Support\Providers\ProviderConsentStatus;
use App\Support\Providers\ProviderVerificationStatus;
use App\Support\System\SystemDirectoryLinks;
use App\Support\System\SystemOperationRunLinks;
use App\Support\SystemConsole\StuckRunClassifier;
use App\Support\SystemConsole\SystemConsoleWindow;
use Carbon\CarbonImmutable;
use Illuminate\Database\Eloquent\Builder;
use Illuminate\Support\Collection;
final class WorkspaceHealthSummaryQuery
{
public function __construct(
private readonly CustomerHealthDimensionCatalog $dimensionCatalog,
private readonly StuckRunClassifier $stuckRunClassifier,
) {}
/**
* @return Collection<int, array{
* workspace_id: int,
* workspace_name: string,
* overall_level: string,
* dimensions: array<string, array{label: string, level: string, windowed: bool}>,
* dominant_dimension_keys: list<string>,
* non_ok_dimension_count: int,
* next_link: array{label: string, url: string}
* }>
*/
public function summaries(SystemConsoleWindow|string|null $window = null, ?CarbonImmutable $now = null): Collection
{
$resolvedWindow = $this->resolveWindow($window);
$now ??= CarbonImmutable::now();
$startAt = $resolvedWindow->startAt($now);
$workspaces = Workspace::query()
->whereNull('archived_at')
->orderBy('name')
->orderBy('id')
->get(['id', 'name']);
if ($workspaces->isEmpty()) {
return collect();
}
$workspaceIds = $workspaces
->pluck('id')
->map(static fn (mixed $workspaceId): int => (int) $workspaceId)
->all();
$activeTenants = Tenant::query()
->whereIn('workspace_id', $workspaceIds)
->whereNull('deleted_at')
->where('status', '!=', Tenant::STATUS_ARCHIVED)
->orderBy('name')
->orderBy('id')
->get(['id', 'workspace_id', 'external_id', 'name', 'status']);
$tenantsByWorkspace = $activeTenants->groupBy(static fn (Tenant $tenant): int => (int) $tenant->workspace_id);
$latestOnboardingSessions = TenantOnboardingSession::query()
->whereIn('workspace_id', $workspaceIds)
->where(function (Builder $query): void {
$this->constrainToActiveTenantTruth($query);
})
->orderByDesc('updated_at')
->orderByDesc('id')
->get(['id', 'workspace_id', 'tenant_id', 'lifecycle_state', 'updated_at', 'created_at'])
->groupBy(static fn (TenantOnboardingSession $session): int => (int) $session->workspace_id)
->map(static fn (Collection $sessions): ?TenantOnboardingSession => $sessions->first());
$providerConnectionsByWorkspace = ProviderConnection::query()
->whereIn('workspace_id', $workspaceIds)
->where('is_default', true)
->where(function (Builder $query): void {
$this->constrainToActiveTenantTruth($query);
})
->orderByDesc('is_enabled')
->orderBy('id')
->get([
'id',
'workspace_id',
'tenant_id',
'is_enabled',
'consent_status',
'verification_status',
])
->groupBy(static fn (ProviderConnection $connection): int => (int) $connection->workspace_id);
$recentRunCounts = $this->groupedCounts(
OperationRun::query()
->whereIn('workspace_id', $workspaceIds)
->where('created_at', '>=', $startAt)
->where(function (Builder $query): void {
$this->constrainToActiveTenantTruth($query);
})
);
$recentFailedRunCounts = $this->groupedCounts(
OperationRun::query()
->whereIn('workspace_id', $workspaceIds)
->where('created_at', '>=', $startAt)
->where('status', OperationRunStatus::Completed->value)
->where('outcome', OperationRunOutcome::Failed->value)
->where(function (Builder $query): void {
$this->constrainToActiveTenantTruth($query);
})
);
$recentStuckRunCounts = $this->groupedCounts(
$this->stuckRunClassifier->apply(
OperationRun::query()
->whereIn('workspace_id', $workspaceIds)
->where('created_at', '>=', $startAt)
->where(function (Builder $query): void {
$this->constrainToActiveTenantTruth($query);
}),
$now,
)
);
$activeHighSeverityFindingCounts = $this->groupedCounts(
Finding::query()
->whereIn('workspace_id', $workspaceIds)
->whereIn('severity', Finding::highSeverityValues())
->whereIn('status', Finding::openStatusesForQuery())
->where(function (Builder $query): void {
$this->constrainToActiveTenantTruth($query);
})
);
$anyGovernanceFindingCounts = $this->groupedCounts(
Finding::query()
->whereIn('workspace_id', $workspaceIds)
->where(function (Builder $query): void {
$this->constrainToActiveTenantTruth($query);
})
);
$overdueHighSeverityFindingCounts = $this->groupedCounts(
Finding::query()
->whereIn('workspace_id', $workspaceIds)
->whereIn('severity', Finding::highSeverityValues())
->whereIn('status', Finding::openStatusesForQuery())
->whereNotNull('due_at')
->where('due_at', '<', $now)
->where(function (Builder $query): void {
$this->constrainToActiveTenantTruth($query);
})
);
$warningExceptionCounts = $this->groupedCounts(
FindingException::query()
->whereIn('workspace_id', $workspaceIds)
->where(function (Builder $query): void {
$query
->whereIn('status', [
FindingException::STATUS_PENDING,
FindingException::STATUS_EXPIRING,
])
->orWhere('current_validity_state', FindingException::VALIDITY_EXPIRING);
})
->where(function (Builder $query): void {
$this->constrainToActiveTenantTruth($query);
})
);
$criticalExceptionCounts = $this->groupedCounts(
FindingException::query()
->whereIn('workspace_id', $workspaceIds)
->where(function (Builder $query): void {
$query
->whereIn('status', [
FindingException::STATUS_EXPIRED,
FindingException::STATUS_REVOKED,
])
->orWhereIn('current_validity_state', [
FindingException::VALIDITY_EXPIRED,
FindingException::VALIDITY_REVOKED,
FindingException::VALIDITY_REJECTED,
FindingException::VALIDITY_MISSING_SUPPORT,
]);
})
->where(function (Builder $query): void {
$this->constrainToActiveTenantTruth($query);
})
);
$reviewPackRequestCounts = $this->groupedCounts(
ProductUsageEvent::query()
->whereIn('workspace_id', $workspaceIds)
->where('event_name', ProductUsageEventCatalog::REVIEW_PACK_REQUESTED)
->where('occurred_at', '>=', $startAt)
->where(function (Builder $query): void {
$this->constrainToActiveTenantTruth($query);
})
);
$recentReviewPacks = ReviewPack::query()
->whereIn('workspace_id', $workspaceIds)
->where('created_at', '>=', $startAt)
->where(function (Builder $query): void {
$this->constrainToActiveTenantTruth($query);
})
->orderByDesc('created_at')
->orderByDesc('id')
->get(['id', 'workspace_id', 'tenant_id', 'status', 'expires_at', 'created_at'])
->groupBy(static fn (ReviewPack $reviewPack): int => (int) $reviewPack->workspace_id)
->map(static fn (Collection $reviewPacks): ?ReviewPack => $reviewPacks->first());
$recentUsageEventCounts = $this->groupedCounts(
ProductUsageEvent::query()
->whereIn('workspace_id', $workspaceIds)
->where('occurred_at', '>=', $startAt)
->where(function (Builder $query): void {
$this->constrainToActiveTenantTruth($query);
})
);
$historicalUsageEventCounts = $this->groupedCounts(
ProductUsageEvent::query()
->whereIn('workspace_id', $workspaceIds)
->where(function (Builder $query): void {
$this->constrainToActiveTenantTruth($query);
})
);
return $workspaces
->map(function (Workspace $workspace) use (
$tenantsByWorkspace,
$latestOnboardingSessions,
$providerConnectionsByWorkspace,
$recentRunCounts,
$recentFailedRunCounts,
$recentStuckRunCounts,
$activeHighSeverityFindingCounts,
$anyGovernanceFindingCounts,
$overdueHighSeverityFindingCounts,
$warningExceptionCounts,
$criticalExceptionCounts,
$reviewPackRequestCounts,
$recentReviewPacks,
$recentUsageEventCounts,
$historicalUsageEventCounts,
$resolvedWindow,
$now,
): array {
$workspaceId = (int) $workspace->getKey();
/** @var Collection<int, Tenant> $workspaceTenants */
$workspaceTenants = $tenantsByWorkspace->get($workspaceId, collect());
/** @var TenantOnboardingSession|null $latestOnboardingSession */
$latestOnboardingSession = $latestOnboardingSessions->get($workspaceId);
/** @var Collection<int, ProviderConnection> $providerConnections */
$providerConnections = $providerConnectionsByWorkspace->get($workspaceId, collect());
/** @var ReviewPack|null $latestReviewPack */
$latestReviewPack = $recentReviewPacks->get($workspaceId);
$dimensions = $this->buildDimensions(
tenants: $workspaceTenants,
latestOnboardingSession: $latestOnboardingSession,
providerConnections: $providerConnections,
recentRunCount: $this->countForWorkspace($recentRunCounts, $workspaceId),
recentFailedRunCount: $this->countForWorkspace($recentFailedRunCounts, $workspaceId),
recentStuckRunCount: $this->countForWorkspace($recentStuckRunCounts, $workspaceId),
activeHighSeverityFindingCount: $this->countForWorkspace($activeHighSeverityFindingCounts, $workspaceId),
anyGovernanceFindingCount: $this->countForWorkspace($anyGovernanceFindingCounts, $workspaceId),
overdueHighSeverityFindingCount: $this->countForWorkspace($overdueHighSeverityFindingCounts, $workspaceId),
warningExceptionCount: $this->countForWorkspace($warningExceptionCounts, $workspaceId),
criticalExceptionCount: $this->countForWorkspace($criticalExceptionCounts, $workspaceId),
reviewPackRequestCount: $this->countForWorkspace($reviewPackRequestCounts, $workspaceId),
latestReviewPack: $latestReviewPack,
recentUsageEventCount: $this->countForWorkspace($recentUsageEventCounts, $workspaceId),
historicalUsageEventCount: $this->countForWorkspace($historicalUsageEventCounts, $workspaceId),
now: $now,
);
$overallLevel = $this->dimensionCatalog->resolveOverallLevel(
array_map(static fn (array $dimension): string => $dimension['level'], $dimensions),
);
$dominantDimensionKeys = $this->dominantDimensionKeys($dimensions);
return [
'workspace_id' => $workspaceId,
'workspace_name' => (string) $workspace->name,
'overall_level' => $overallLevel,
'dimensions' => $dimensions,
'dominant_dimension_keys' => $dominantDimensionKeys,
'non_ok_dimension_count' => count(array_filter(
$dimensions,
static fn (array $dimension): bool => $dimension['level'] !== 'ok',
)),
'next_link' => $this->nextLink(
workspace: $workspace,
tenants: $workspaceTenants,
dominantDimensionKeys: $dominantDimensionKeys,
window: $resolvedWindow,
),
];
})
->values();
}
/**
* @return array{
* workspace_id: int,
* workspace_name: string,
* overall_level: string,
* dimensions: array<string, array{label: string, level: string, windowed: bool}>,
* dominant_dimension_keys: list<string>,
* non_ok_dimension_count: int,
* next_link: array{label: string, url: string}
* }|null
*/
public function summaryForWorkspace(Workspace|int $workspace, SystemConsoleWindow|string|null $window = null, ?CarbonImmutable $now = null): ?array
{
$workspaceId = $workspace instanceof Workspace ? (int) $workspace->getKey() : (int) $workspace;
/** @var array{
* workspace_id: int,
* workspace_name: string,
* overall_level: string,
* dimensions: array<string, array{label: string, level: string, windowed: bool}>,
* dominant_dimension_keys: list<string>,
* non_ok_dimension_count: int,
* next_link: array{label: string, url: string}
* }|null $summary
*/
$summary = $this->summaries($window, $now)->firstWhere('workspace_id', $workspaceId);
return $summary;
}
/**
* @return array{ok: int, warn: int, critical: int, unknown: int}
*/
public function healthCounts(SystemConsoleWindow|string|null $window = null, ?CarbonImmutable $now = null): array
{
$counts = [
'ok' => 0,
'warn' => 0,
'critical' => 0,
'unknown' => 0,
];
foreach ($this->summaries($window, $now) as $summary) {
$counts[$summary['overall_level']]++;
}
return $counts;
}
/**
* @return Collection<int, array{
* workspace_id: int,
* workspace_name: string,
* overall_level: string,
* dimensions: array<string, array{label: string, level: string, windowed: bool}>,
* dominant_dimension_keys: list<string>,
* non_ok_dimension_count: int,
* next_link: array{label: string, url: string}
* }>
*/
public function attentionNeeded(SystemConsoleWindow|string|null $window = null, int $limit = 10, ?CarbonImmutable $now = null): Collection
{
return $this->summaries($window, $now)
->filter(static fn (array $summary): bool => $summary['overall_level'] !== 'ok')
->sort(function (array $left, array $right): int {
$severityComparison = $this->levelRank($right['overall_level']) <=> $this->levelRank($left['overall_level']);
if ($severityComparison !== 0) {
return $severityComparison;
}
$nonOkComparison = $right['non_ok_dimension_count'] <=> $left['non_ok_dimension_count'];
if ($nonOkComparison !== 0) {
return $nonOkComparison;
}
$nameComparison = strcasecmp($left['workspace_name'], $right['workspace_name']);
if ($nameComparison !== 0) {
return $nameComparison;
}
return $left['workspace_id'] <=> $right['workspace_id'];
})
->values()
->take(max(1, $limit));
}
private function resolveWindow(SystemConsoleWindow|string|null $window): SystemConsoleWindow
{
if ($window instanceof SystemConsoleWindow) {
return $window;
}
return SystemConsoleWindow::fromNullable(is_string($window) ? $window : null);
}
/**
* @param Collection<int, Tenant> $tenants
* @param Collection<int, ProviderConnection> $providerConnections
* @return array<string, array{label: string, level: string, windowed: bool}>
*/
private function buildDimensions(
Collection $tenants,
?TenantOnboardingSession $latestOnboardingSession,
Collection $providerConnections,
int $recentRunCount,
int $recentFailedRunCount,
int $recentStuckRunCount,
int $activeHighSeverityFindingCount,
int $anyGovernanceFindingCount,
int $overdueHighSeverityFindingCount,
int $warningExceptionCount,
int $criticalExceptionCount,
int $reviewPackRequestCount,
?ReviewPack $latestReviewPack,
int $recentUsageEventCount,
int $historicalUsageEventCount,
CarbonImmutable $now,
): array {
$levels = [
CustomerHealthDimensionCatalog::ONBOARDING_READINESS => $this->onboardingReadinessLevel($tenants, $latestOnboardingSession),
CustomerHealthDimensionCatalog::PROVIDER_CONNECTION_HEALTH => $this->providerConnectionHealthLevel($providerConnections),
CustomerHealthDimensionCatalog::OPERATIONAL_STABILITY => $this->operationalStabilityLevel($recentRunCount, $recentFailedRunCount, $recentStuckRunCount),
CustomerHealthDimensionCatalog::GOVERNANCE_PRESSURE => $this->governancePressureLevel(
activeHighSeverityFindingCount: $activeHighSeverityFindingCount,
anyGovernanceFindingCount: $anyGovernanceFindingCount,
overdueHighSeverityFindingCount: $overdueHighSeverityFindingCount,
warningExceptionCount: $warningExceptionCount,
criticalExceptionCount: $criticalExceptionCount,
),
CustomerHealthDimensionCatalog::REVIEW_PACK_READINESS => $this->reviewPackReadinessLevel($reviewPackRequestCount, $latestReviewPack, $now),
CustomerHealthDimensionCatalog::ENGAGEMENT_FRESHNESS => $this->engagementFreshnessLevel($recentUsageEventCount, $historicalUsageEventCount),
];
$dimensions = [];
foreach ($this->dimensionCatalog->visibleDimensions() as $dimensionKey => $label) {
$dimensions[$dimensionKey] = [
'label' => $label,
'level' => $levels[$dimensionKey],
'windowed' => $this->dimensionCatalog->isWindowed($dimensionKey),
];
}
return $dimensions;
}
/**
* @param Collection<int, Tenant> $tenants
*/
private function onboardingReadinessLevel(Collection $tenants, ?TenantOnboardingSession $latestOnboardingSession): string
{
if ($latestOnboardingSession instanceof TenantOnboardingSession) {
return match ($latestOnboardingSession->lifecycleState()) {
OnboardingLifecycleState::ReadyForActivation,
OnboardingLifecycleState::Completed => 'ok',
OnboardingLifecycleState::Cancelled => 'critical',
OnboardingLifecycleState::Draft,
OnboardingLifecycleState::Verifying,
OnboardingLifecycleState::ActionRequired,
OnboardingLifecycleState::Bootstrapping => 'warn',
};
}
if ($tenants->isEmpty()) {
return 'unknown';
}
if ($tenants->contains(static fn (Tenant $tenant): bool => (string) $tenant->status === Tenant::STATUS_ACTIVE)) {
return 'ok';
}
return 'warn';
}
/**
* @param Collection<int, ProviderConnection> $providerConnections
*/
private function providerConnectionHealthLevel(Collection $providerConnections): string
{
if ($providerConnections->isEmpty()) {
return 'unknown';
}
if ($providerConnections->contains(function (ProviderConnection $connection): bool {
if (! $connection->is_enabled) {
return false;
}
$consentStatus = $this->normalizeBackedEnumValue($connection->consent_status);
$verificationStatus = $this->normalizeBackedEnumValue($connection->verification_status);
return in_array($consentStatus, [
ProviderConsentStatus::Required->value,
ProviderConsentStatus::Failed->value,
ProviderConsentStatus::Revoked->value,
], true) || in_array($verificationStatus, [
ProviderVerificationStatus::Blocked->value,
ProviderVerificationStatus::Error->value,
], true);
})) {
return 'critical';
}
if ($providerConnections->contains(function (ProviderConnection $connection): bool {
if (! $connection->is_enabled) {
return true;
}
$consentStatus = $this->normalizeBackedEnumValue($connection->consent_status);
$verificationStatus = $this->normalizeBackedEnumValue($connection->verification_status);
return in_array($consentStatus, [
ProviderConsentStatus::Unknown->value,
], true) || in_array($verificationStatus, [
ProviderVerificationStatus::Unknown->value,
ProviderVerificationStatus::Pending->value,
ProviderVerificationStatus::Degraded->value,
], true);
})) {
return 'warn';
}
if ($providerConnections->contains(function (ProviderConnection $connection): bool {
return $connection->is_enabled
&& $this->normalizeBackedEnumValue($connection->consent_status) === ProviderConsentStatus::Granted->value
&& $this->normalizeBackedEnumValue($connection->verification_status) === ProviderVerificationStatus::Healthy->value;
})) {
return 'ok';
}
return 'unknown';
}
private function operationalStabilityLevel(int $recentRunCount, int $recentFailedRunCount, int $recentStuckRunCount): string
{
if ($recentFailedRunCount > 0 || $recentStuckRunCount > 0) {
return 'critical';
}
if ($recentRunCount > 0) {
return 'ok';
}
return 'unknown';
}
private function governancePressureLevel(
int $activeHighSeverityFindingCount,
int $anyGovernanceFindingCount,
int $overdueHighSeverityFindingCount,
int $warningExceptionCount,
int $criticalExceptionCount,
): string {
if ($overdueHighSeverityFindingCount > 0 || $criticalExceptionCount > 0) {
return 'critical';
}
if ($activeHighSeverityFindingCount > 0 || $warningExceptionCount > 0) {
return 'warn';
}
if ($anyGovernanceFindingCount === 0 && $warningExceptionCount === 0 && $criticalExceptionCount === 0) {
return 'unknown';
}
return 'ok';
}
private function reviewPackReadinessLevel(int $reviewPackRequestCount, ?ReviewPack $latestReviewPack, CarbonImmutable $now): string
{
if ($reviewPackRequestCount === 0 && ! $latestReviewPack instanceof ReviewPack) {
return 'unknown';
}
if (! $latestReviewPack instanceof ReviewPack) {
return 'warn';
}
if (
(string) $latestReviewPack->status === ReviewPack::STATUS_READY
&& (! $latestReviewPack->expires_at instanceof CarbonImmutable || $latestReviewPack->expires_at->gt($now))
) {
return 'ok';
}
if (
in_array((string) $latestReviewPack->status, [
ReviewPack::STATUS_FAILED,
ReviewPack::STATUS_EXPIRED,
], true)
|| ($latestReviewPack->expires_at !== null && $latestReviewPack->expires_at->lte($now))
) {
return 'critical';
}
return 'warn';
}
private function engagementFreshnessLevel(int $recentUsageEventCount, int $historicalUsageEventCount): string
{
if ($recentUsageEventCount > 0) {
return 'ok';
}
if ($historicalUsageEventCount > 0) {
return 'warn';
}
return 'unknown';
}
/**
* @param array<string, array{label: string, level: string, windowed: bool}> $dimensions
* @return list<string>
*/
private function dominantDimensionKeys(array $dimensions): array
{
$catalogOrder = array_flip($this->dimensionCatalog->names());
return collect($dimensions)
->reject(static fn (array $dimension): bool => $dimension['level'] === 'ok')
->keys()
->sort(function (string $left, string $right) use ($dimensions, $catalogOrder): int {
$severityComparison = $this->levelRank($dimensions[$right]['level']) <=> $this->levelRank($dimensions[$left]['level']);
if ($severityComparison !== 0) {
return $severityComparison;
}
return ($catalogOrder[$left] ?? PHP_INT_MAX) <=> ($catalogOrder[$right] ?? PHP_INT_MAX);
})
->values()
->all();
}
/**
* @param Collection<int, Tenant> $tenants
* @param list<string> $dominantDimensionKeys
* @return array{label: string, url: string}
*/
private function nextLink(Workspace $workspace, Collection $tenants, array $dominantDimensionKeys, SystemConsoleWindow $window): array
{
$dominantDimension = $dominantDimensionKeys[0] ?? null;
if ($dominantDimension === CustomerHealthDimensionCatalog::OPERATIONAL_STABILITY && $this->canOpenRunsLink()) {
return [
'label' => 'Open runs',
'url' => SystemOperationRunLinks::index(),
];
}
/** @var Tenant|null $tenant */
$tenant = $tenants->first();
if ($tenant instanceof Tenant) {
return [
'label' => 'Review health details',
'url' => $this->withWindowQuery(SystemDirectoryLinks::tenantDetail($tenant), $window),
];
}
return [
'label' => 'Review health details',
'url' => $this->withWindowQuery(SystemDirectoryLinks::workspaceDetail($workspace), $window),
];
}
private function withWindowQuery(string $url, SystemConsoleWindow $window): string
{
$separator = str_contains($url, '?') ? '&' : '?';
return $url.$separator.http_build_query(['window' => $window->value]);
}
private function canOpenRunsLink(): bool
{
$user = auth('platform')->user();
if (! $user instanceof PlatformUser) {
return false;
}
return $user->hasCapability(PlatformCapabilities::OPERATIONS_VIEW)
|| ($user->hasCapability(PlatformCapabilities::OPS_VIEW) && $user->hasCapability(PlatformCapabilities::RUNBOOKS_VIEW));
}
/**
* @param Builder<OperationRun>|Builder<ProductUsageEvent>|Builder<ReviewPack>|Builder<Finding>|Builder<FindingException> $query
* @return array<int, int>
*/
private function groupedCounts(Builder $query): array
{
return $query
->selectRaw('workspace_id, COUNT(*) as aggregate')
->groupBy('workspace_id')
->pluck('aggregate', 'workspace_id')
->mapWithKeys(static fn (mixed $count, mixed $workspaceId): array => [
(int) $workspaceId => (int) $count,
])
->all();
}
/**
* @param array<int, int> $counts
*/
private function countForWorkspace(array $counts, int $workspaceId): int
{
return (int) ($counts[$workspaceId] ?? 0);
}
private function levelRank(string $level): int
{
return match ($level) {
'critical' => 4,
'warn' => 3,
'unknown' => 2,
default => 1,
};
}
private function normalizeBackedEnumValue(mixed $value): string
{
if (is_object($value) && property_exists($value, 'value')) {
return (string) $value->value;
}
return (string) $value;
}
private function constrainToActiveTenantTruth(Builder $query): void
{
$query
->whereNull('tenant_id')
->orWhereHas('tenant', function (Builder $tenantQuery): void {
$tenantQuery
->whereNull('deleted_at')
->where('status', '!=', Tenant::STATUS_ARCHIVED);
});
}
}

View File

@ -0,0 +1,59 @@
@php
/** @var array{
* overall: array{label: string, color: string, icon: string|null},
* reason: string,
* impact: string,
* recommended_action: string,
* dominant_dimensions: list<array{label: string, color: string, icon: string|null}>,
* window_label: string
* } $decision */
@endphp
<x-filament::section>
<x-slot name="heading">
Customer health decision
</x-slot>
<x-slot name="description">
Decision-first summary. Operational stability, review-pack readiness, and engagement freshness honor {{ $decision['window_label'] }}.
</x-slot>
<div class="space-y-5">
<div class="flex flex-wrap items-center gap-3">
<div>
<p class="text-sm font-medium text-gray-950 dark:text-white">Overall health</p>
</div>
<x-filament::badge :color="$decision['overall']['color']" :icon="$decision['overall']['icon']">
{{ $decision['overall']['label'] }}
</x-filament::badge>
</div>
<div class="space-y-2">
<p class="text-sm font-medium text-gray-950 dark:text-white">Reason</p>
<p class="text-sm leading-6 text-gray-600 dark:text-gray-300">{{ $decision['reason'] }}</p>
@if ($decision['dominant_dimensions'] !== [])
<div class="flex flex-wrap gap-2">
@foreach ($decision['dominant_dimensions'] as $dimension)
<x-filament::badge :color="$dimension['color']" :icon="$dimension['icon']">
{{ $dimension['label'] }}
</x-filament::badge>
@endforeach
</div>
@endif
</div>
<div class="grid grid-cols-1 gap-5 lg:grid-cols-2">
<div class="space-y-2">
<p class="text-sm font-medium text-gray-950 dark:text-white">Impact</p>
<p class="text-sm leading-6 text-gray-600 dark:text-gray-300">{{ $decision['impact'] }}</p>
</div>
<div class="space-y-2">
<p class="text-sm font-medium text-gray-950 dark:text-white">Recommended next action</p>
<p class="text-sm leading-6 text-gray-600 dark:text-gray-300">{{ $decision['recommended_action'] }}</p>
</div>
</div>
</div>
</x-filament::section>

View File

@ -1,6 +1,7 @@
@php
/** @var \App\Models\Tenant $tenant */
$tenant = $this->tenant;
$customerHealthDecision = $this->customerHealthDecision();
$providerConnections = $this->providerConnections();
$permissions = $this->tenantPermissions();
$runs = $this->recentRuns();
@ -32,11 +33,19 @@
<div class="mt-4">
<x-filament::link :href="$this->adminTenantUrl()" icon="heroicon-m-arrow-top-right-on-square">
Open in /admin
Open in tenant admin
</x-filament::link>
<p class="mt-2 text-xs text-gray-500 dark:text-gray-400">
Requires tenant admin membership.
</p>
</div>
</x-filament::section>
@if ($customerHealthDecision)
@include('filament.system.pages.directory.partials.customer-health-decision-card', ['decision' => $customerHealthDecision])
@endif
<x-filament::section>
<x-slot name="heading">
Connectivity signals

View File

@ -1,6 +1,7 @@
@php
/** @var \App\Models\Workspace $workspace */
$workspace = $this->workspace;
$customerHealthDecision = $this->customerHealthDecision();
$tenants = $this->workspaceTenants();
$runs = $this->recentRuns();
@endphp
@ -30,6 +31,10 @@
</div>
</x-filament::section>
@if ($customerHealthDecision)
@include('filament.system.pages.directory.partials.customer-health-decision-card', ['decision' => $customerHealthDecision])
@endif
<x-filament::section>
<x-slot name="heading">
Tenants summary

View File

@ -0,0 +1,53 @@
<x-filament-widgets::widget>
<x-filament::section>
<x-slot name="heading">
Attention-needed workspaces
</x-slot>
<x-slot name="description">
Worst derived workspace health first. Operational stability, review-pack readiness, and engagement freshness honor {{ $windowLabel }}.
</x-slot>
@if ($rows->isEmpty())
<div class="rounded-lg border border-dashed border-gray-300 px-4 py-6 text-sm text-gray-500 dark:border-white/15 dark:text-gray-400">
No workspaces need attention in the selected view.
</div>
@else
<div class="space-y-3">
@foreach ($rows as $row)
<article class="rounded-xl border border-gray-200 bg-white/70 p-4 dark:border-white/10 dark:bg-white/5">
<div class="flex flex-col gap-3 md:flex-row md:items-start md:justify-between">
<div class="space-y-2">
<div class="flex flex-wrap items-center gap-2">
<h3 class="text-sm font-semibold text-gray-950 dark:text-white">{{ $row['workspace_label'] }}</h3>
<x-filament::badge :color="$row['overall']['color']" :icon="$row['overall']['icon']">
{{ $row['overall']['label'] }}
</x-filament::badge>
</div>
<p class="text-sm text-gray-600 dark:text-gray-300">
Top drivers: {{ $row['dominant_copy'] }}
</p>
<div class="flex flex-wrap gap-2">
@foreach ($row['dominant_dimensions'] as $dimension)
<x-filament::badge :color="$dimension['color']" :icon="$dimension['icon']">
{{ $dimension['label'] }}
</x-filament::badge>
@endforeach
</div>
</div>
<div>
<x-filament::link :href="$row['next_link']['url']" icon="heroicon-m-arrow-top-right-on-square">
{{ $row['next_link']['label'] }}
</x-filament::link>
</div>
</div>
</article>
@endforeach
</div>
@endif
</x-filament::section>
</x-filament-widgets::widget>

View File

@ -0,0 +1,171 @@
<?php
declare(strict_types=1);
use App\Filament\System\Pages\Dashboard;
use App\Filament\System\Widgets\CustomerHealthKpis;
use App\Filament\System\Widgets\CustomerHealthTopWorkspaces;
use App\Models\OperationRun;
use App\Models\PlatformUser;
use App\Models\ProviderConnection;
use App\Models\Tenant;
use App\Models\Workspace;
use App\Support\Auth\PlatformCapabilities;
use App\Support\OperationRunOutcome;
use App\Support\OperationRunStatus;
use App\Support\Providers\ProviderConsentStatus;
use App\Support\Providers\ProviderVerificationStatus;
use Filament\Facades\Filament;
use Illuminate\Foundation\Testing\RefreshDatabase;
uses(RefreshDatabase::class);
beforeEach(function (): void {
Filament::setCurrentPanel('system');
Filament::bootCurrentPanel();
});
it('shows customer health widgets to authorized system users', function (): void {
$user = PlatformUser::factory()->create([
'capabilities' => [
PlatformCapabilities::ACCESS_SYSTEM_PANEL,
PlatformCapabilities::CONSOLE_VIEW,
PlatformCapabilities::DIRECTORY_VIEW,
],
'is_active' => true,
]);
$this->actingAs($user, 'platform')
->get(Dashboard::getUrl(panel: 'system'))
->assertSuccessful()
->assertSeeLivewire(CustomerHealthKpis::class)
->assertSeeLivewire(CustomerHealthTopWorkspaces::class);
});
it('keeps the attention-needed widget hidden when no linked system detail surface is accessible', function (): void {
$user = PlatformUser::factory()->create([
'capabilities' => [
PlatformCapabilities::ACCESS_SYSTEM_PANEL,
PlatformCapabilities::CONSOLE_VIEW,
],
'is_active' => true,
]);
$this->actingAs($user, 'platform')
->get(Dashboard::getUrl(panel: 'system'))
->assertSuccessful()
->assertSeeLivewire(CustomerHealthKpis::class)
->assertDontSeeLivewire(CustomerHealthTopWorkspaces::class);
});
it('shows the attention-needed widget to operations-only users when operational rows are accessible', function (): void {
seedOperationalAttentionWorkspace('Ops Only Workspace');
$user = PlatformUser::factory()->create([
'capabilities' => [
PlatformCapabilities::ACCESS_SYSTEM_PANEL,
PlatformCapabilities::CONSOLE_VIEW,
PlatformCapabilities::OPERATIONS_VIEW,
],
'is_active' => true,
]);
$this->actingAs($user, 'platform')
->get(Dashboard::getUrl(panel: 'system'))
->assertSuccessful()
->assertSeeLivewire(CustomerHealthKpis::class)
->assertSeeLivewire(CustomerHealthTopWorkspaces::class);
});
it('shows the attention-needed widget to ops and runbooks users when operational rows are accessible', function (): void {
seedOperationalAttentionWorkspace('Runbooks Ops Workspace');
$user = PlatformUser::factory()->create([
'capabilities' => [
PlatformCapabilities::ACCESS_SYSTEM_PANEL,
PlatformCapabilities::CONSOLE_VIEW,
PlatformCapabilities::OPS_VIEW,
PlatformCapabilities::RUNBOOKS_VIEW,
],
'is_active' => true,
]);
$this->actingAs($user, 'platform')
->get(Dashboard::getUrl(panel: 'system'))
->assertSuccessful()
->assertSeeLivewire(CustomerHealthKpis::class)
->assertSeeLivewire(CustomerHealthTopWorkspaces::class);
});
it('filters directory-only attention rows out for operations-only users', function (): void {
seedOperationalAttentionWorkspace('Accessible Ops Workspace');
seedProviderAttentionWorkspace('Directory Only Workspace');
$user = PlatformUser::factory()->create([
'capabilities' => [
PlatformCapabilities::ACCESS_SYSTEM_PANEL,
PlatformCapabilities::CONSOLE_VIEW,
PlatformCapabilities::OPERATIONS_VIEW,
],
'is_active' => true,
]);
$this->actingAs($user, 'platform')
->get(Dashboard::getUrl(panel: 'system'))
->assertSuccessful()
->assertSeeLivewire(CustomerHealthKpis::class)
->assertSeeLivewire(CustomerHealthTopWorkspaces::class)
->assertSee('Accessible Ops Workspace')
->assertDontSee('Directory Only Workspace');
});
it('forbids customer health widgets when system dashboard access is denied', function (): void {
$user = PlatformUser::factory()->create([
'capabilities' => [
PlatformCapabilities::ACCESS_SYSTEM_PANEL,
],
'is_active' => true,
]);
$this->actingAs($user, 'platform')
->get(Dashboard::getUrl(panel: 'system'))
->assertForbidden();
});
function seedOperationalAttentionWorkspace(string $workspaceName): void
{
$workspace = Workspace::factory()->create(['name' => $workspaceName]);
$tenant = Tenant::factory()->for($workspace)->create([
'name' => $workspaceName.' Tenant',
'status' => Tenant::STATUS_ACTIVE,
]);
OperationRun::factory()
->forTenant($tenant)
->create([
'workspace_id' => (int) $workspace->getKey(),
'status' => OperationRunStatus::Queued->value,
'outcome' => OperationRunOutcome::Pending->value,
'created_at' => now()->subHours(2),
'started_at' => null,
]);
}
function seedProviderAttentionWorkspace(string $workspaceName): void
{
$workspace = Workspace::factory()->create(['name' => $workspaceName]);
$tenant = Tenant::factory()->for($workspace)->create([
'name' => $workspaceName.' Tenant',
'status' => Tenant::STATUS_ACTIVE,
]);
ProviderConnection::factory()
->for($tenant)
->create([
'workspace_id' => (int) $workspace->getKey(),
'is_default' => true,
'is_enabled' => true,
'consent_status' => ProviderConsentStatus::Granted->value,
'verification_status' => ProviderVerificationStatus::Blocked->value,
]);
}

View File

@ -0,0 +1,186 @@
<?php
declare(strict_types=1);
use App\Filament\System\Pages\Dashboard;
use App\Filament\System\Widgets\CustomerHealthKpis;
use App\Models\Finding;
use App\Models\OperationRun;
use App\Models\PlatformUser;
use App\Models\ProductUsageEvent;
use App\Models\ProviderConnection;
use App\Models\ReviewPack;
use App\Models\Tenant;
use App\Models\Workspace;
use App\Support\Auth\PlatformCapabilities;
use App\Support\OperationRunOutcome;
use App\Support\OperationRunStatus;
use App\Support\ProductTelemetry\ProductUsageEventCatalog;
use App\Support\SystemConsole\SystemConsoleWindow;
use Carbon\CarbonImmutable;
use Filament\Facades\Filament;
use Filament\Widgets\StatsOverviewWidget\Stat;
use Illuminate\Foundation\Testing\RefreshDatabase;
use Livewire\Livewire;
uses(RefreshDatabase::class);
beforeEach(function (): void {
Filament::setCurrentPanel('system');
Filament::bootCurrentPanel();
CarbonImmutable::setTestNow(CarbonImmutable::parse('2026-04-27 12:00:00'));
});
afterEach(function (): void {
CarbonImmutable::setTestNow();
});
it('renders aggregate healthy, warning, critical, and unknown counts with a visible time-basis cue', function (): void {
actingAsCustomerHealthSystemUser();
$baselineStats = customerHealthStats(Livewire::withQueryParams([
'window' => SystemConsoleWindow::LastDay,
])->test(CustomerHealthKpis::class));
seedCustomerHealthWorkspace('Healthy Workspace');
seedCustomerHealthWorkspace('Warning Workspace', recentUsage: false, historicalUsage: true);
seedCustomerHealthWorkspace('Critical Workspace', failedRun: true);
seedCustomerHealthWorkspace('Unknown Workspace', recentRun: false, readyReviewPack: false);
$stats = customerHealthStats(Livewire::withQueryParams([
'window' => SystemConsoleWindow::LastDay,
])->test(CustomerHealthKpis::class));
expect((int) $stats['Healthy']['value'] - (int) $baselineStats['Healthy']['value'])->toBe(1)
->and($stats['Healthy']['description'])->toBe('Operational stability, review-pack readiness, and engagement freshness honor Last 24 hours.')
->and((int) $stats['Warning']['value'] - (int) $baselineStats['Warning']['value'])->toBe(1)
->and($stats['Warning']['description'])->toBe('Onboarding readiness, provider health, and governance pressure stay point-in-time.')
->and((int) $stats['Critical']['value'] - (int) $baselineStats['Critical']['value'])->toBe(1)
->and((int) $stats['Unknown']['value'] - (int) $baselineStats['Unknown']['value'])->toBe(1)
->and($stats['Unknown']['description'])->toBe('Missing or stale inputs stay explicit instead of silently reading healthy.');
});
it('registers the customer health widget on the system dashboard for authorized users', function (): void {
$user = actingAsCustomerHealthSystemUser();
$response = $this->actingAs($user, 'platform')->get(Dashboard::getUrl(panel: 'system'));
$response->assertSuccessful()
->assertSee('Customer health')
->assertSeeLivewire(CustomerHealthKpis::class);
});
/**
* @return array<string, array{value:string,description:string|null}>
*/
function customerHealthStats($component): array
{
$method = new ReflectionMethod(CustomerHealthKpis::class, 'getStats');
$method->setAccessible(true);
return collect($method->invoke($component->instance()))
->mapWithKeys(fn (Stat $stat): array => [
(string) $stat->getLabel() => [
'value' => (string) $stat->getValue(),
'description' => $stat->getDescription(),
],
])
->all();
}
function actingAsCustomerHealthSystemUser(): PlatformUser
{
$user = PlatformUser::factory()->create([
'capabilities' => [
PlatformCapabilities::ACCESS_SYSTEM_PANEL,
PlatformCapabilities::CONSOLE_VIEW,
],
'is_active' => true,
]);
test()->actingAs($user, 'platform');
return $user;
}
/**
* @return array{workspace: Workspace, tenant: Tenant}
*/
function seedCustomerHealthWorkspace(
string $workspaceName,
bool $readyReviewPack = true,
bool $recentUsage = true,
bool $historicalUsage = false,
bool $recentRun = true,
bool $failedRun = false,
): array {
$workspace = Workspace::factory()->create(['name' => $workspaceName]);
$tenant = Tenant::factory()->for($workspace)->create([
'name' => $workspaceName.' Tenant',
'status' => Tenant::STATUS_ACTIVE,
]);
ProviderConnection::factory()
->for($tenant)
->verifiedHealthy()
->create([
'workspace_id' => (int) $workspace->getKey(),
'is_default' => true,
]);
if ($readyReviewPack) {
ReviewPack::factory()
->for($tenant)
->ready()
->create([
'workspace_id' => (int) $workspace->getKey(),
'created_at' => now()->subHour(),
'generated_at' => now()->subHour(),
'expires_at' => now()->addDays(30),
]);
}
if ($recentUsage) {
ProductUsageEvent::factory()
->for($tenant)
->forEvent(ProductUsageEventCatalog::ONBOARDING_CHECKPOINT_COMPLETED)
->create([
'workspace_id' => (int) $workspace->getKey(),
'occurred_at' => now()->subMinutes(20),
]);
} elseif ($historicalUsage) {
ProductUsageEvent::factory()
->for($tenant)
->forEvent(ProductUsageEventCatalog::ONBOARDING_CHECKPOINT_COMPLETED)
->create([
'workspace_id' => (int) $workspace->getKey(),
'occurred_at' => now()->subDays(3),
]);
}
if ($recentRun) {
OperationRun::factory()
->forTenant($tenant)
->create([
'workspace_id' => (int) $workspace->getKey(),
'status' => OperationRunStatus::Completed->value,
'outcome' => $failedRun ? OperationRunOutcome::Failed->value : OperationRunOutcome::Succeeded->value,
'created_at' => now()->subMinutes(10),
'started_at' => now()->subMinutes(15),
'completed_at' => now()->subMinutes(5),
]);
}
Finding::factory()
->for($tenant)
->closed()
->create([
'severity' => Finding::SEVERITY_LOW,
]);
return [
'workspace' => $workspace,
'tenant' => $tenant,
];
}

View File

@ -0,0 +1,158 @@
<?php
declare(strict_types=1);
use App\Models\Finding;
use App\Models\OperationRun;
use App\Models\PlatformUser;
use App\Models\ProductUsageEvent;
use App\Models\ProviderConnection;
use App\Models\ReviewPack;
use App\Models\Tenant;
use App\Models\Workspace;
use App\Support\Auth\PlatformCapabilities;
use App\Support\OperationRunOutcome;
use App\Support\OperationRunStatus;
use App\Support\ProductTelemetry\ProductUsageEventCatalog;
use App\Support\Providers\ProviderConsentStatus;
use App\Support\Providers\ProviderVerificationStatus;
use App\Support\System\SystemDirectoryLinks;
use App\Support\SystemConsole\SystemConsoleWindow;
use Carbon\CarbonImmutable;
use Illuminate\Foundation\Testing\RefreshDatabase;
uses(RefreshDatabase::class);
beforeEach(function (): void {
CarbonImmutable::setTestNow(CarbonImmutable::parse('2026-04-27 12:00:00'));
});
afterEach(function (): void {
CarbonImmutable::setTestNow();
});
it('renders a decision-first customer health card on the tenant detail page before diagnostics', function (): void {
$fixture = createCustomerHealthDecisionFixture('Tenant Decision Workspace');
$platformUser = createDirectoryPlatformUser();
$response = $this->actingAs($platformUser, 'platform')
->get(SystemDirectoryLinks::tenantDetail($fixture['tenant']).'?window='.SystemConsoleWindow::LastWeek)
->assertSuccessful()
->assertSee('Customer health decision')
->assertSee('Overall health')
->assertSee('Reason')
->assertSee('Impact')
->assertSee('Recommended next action')
->assertSee('Top driver: Provider connection health')
->assertSee('Default provider consent or verification is blocking reliable tenant management.')
->assertSee('Review connectivity signals below and confirm the default provider consent and verification state.')
->assertSee('Last 7 days');
$html = $response->getContent();
$decisionPosition = strpos($html, 'Customer health decision');
$diagnosticsPosition = strpos($html, 'Connectivity signals');
expect($decisionPosition)->not->toBeFalse()
->and($diagnosticsPosition)->not->toBeFalse()
->and($decisionPosition)->toBeLessThan($diagnosticsPosition);
});
it('renders a decision-first customer health card on the workspace detail page before tenant diagnostics', function (): void {
$fixture = createCustomerHealthDecisionFixture('Workspace Decision Workspace');
$platformUser = createDirectoryPlatformUser();
$response = $this->actingAs($platformUser, 'platform')
->get(SystemDirectoryLinks::workspaceDetail($fixture['workspace']).'?window='.SystemConsoleWindow::LastWeek)
->assertSuccessful()
->assertSee('Customer health decision')
->assertSee('Overall health')
->assertSee('Reason')
->assertSee('Impact')
->assertSee('Recommended next action')
->assertSee('Top driver: Provider connection health')
->assertSee('Default provider consent or verification is blocking reliable tenant management.')
->assertSee('Open the affected tenant below and review the default provider connection state.')
->assertSee('Last 7 days');
$html = $response->getContent();
$decisionPosition = strpos($html, 'Customer health decision');
$diagnosticsPosition = strpos($html, 'Tenants summary');
expect($decisionPosition)->not->toBeFalse()
->and($diagnosticsPosition)->not->toBeFalse()
->and($decisionPosition)->toBeLessThan($diagnosticsPosition);
});
function createDirectoryPlatformUser(): PlatformUser
{
return PlatformUser::factory()->create([
'capabilities' => [
PlatformCapabilities::ACCESS_SYSTEM_PANEL,
PlatformCapabilities::DIRECTORY_VIEW,
],
'is_active' => true,
]);
}
/**
* @return array{workspace: Workspace, tenant: Tenant}
*/
function createCustomerHealthDecisionFixture(string $workspaceName): array
{
$workspace = Workspace::factory()->create(['name' => $workspaceName]);
$tenant = Tenant::factory()->for($workspace)->create([
'name' => $workspaceName.' Tenant',
'status' => Tenant::STATUS_ACTIVE,
]);
ProviderConnection::factory()
->for($tenant)
->create([
'workspace_id' => (int) $workspace->getKey(),
'is_default' => true,
'is_enabled' => true,
'consent_status' => ProviderConsentStatus::Granted->value,
'verification_status' => ProviderVerificationStatus::Blocked->value,
]);
ReviewPack::factory()
->for($tenant)
->ready()
->create([
'workspace_id' => (int) $workspace->getKey(),
'created_at' => now()->subDays(3),
'generated_at' => now()->subDays(3),
'expires_at' => now()->addDays(30),
]);
ProductUsageEvent::factory()
->for($tenant)
->forEvent(ProductUsageEventCatalog::ONBOARDING_CHECKPOINT_COMPLETED)
->create([
'workspace_id' => (int) $workspace->getKey(),
'occurred_at' => now()->subDays(3),
]);
OperationRun::factory()
->forTenant($tenant)
->create([
'workspace_id' => (int) $workspace->getKey(),
'status' => OperationRunStatus::Completed->value,
'outcome' => OperationRunOutcome::Succeeded->value,
'created_at' => now()->subDays(3),
'started_at' => now()->subDays(3)->subMinutes(5),
'completed_at' => now()->subDays(3),
]);
Finding::factory()
->for($tenant)
->closed()
->create([
'severity' => Finding::SEVERITY_LOW,
]);
return [
'workspace' => $workspace,
'tenant' => $tenant,
];
}

View File

@ -0,0 +1,177 @@
<?php
declare(strict_types=1);
use App\Filament\System\Widgets\CustomerHealthTopWorkspaces;
use App\Models\Finding;
use App\Models\OperationRun;
use App\Models\PlatformUser;
use App\Models\ProductUsageEvent;
use App\Models\ProviderConnection;
use App\Models\ReviewPack;
use App\Models\Tenant;
use App\Models\Workspace;
use App\Support\Auth\PlatformCapabilities;
use App\Support\OperationRunOutcome;
use App\Support\OperationRunStatus;
use App\Support\ProductTelemetry\ProductUsageEventCatalog;
use App\Support\Providers\ProviderConsentStatus;
use App\Support\Providers\ProviderVerificationStatus;
use App\Support\System\SystemDirectoryLinks;
use App\Support\System\SystemOperationRunLinks;
use App\Support\SystemConsole\SystemConsoleWindow;
use Carbon\CarbonImmutable;
use Filament\Facades\Filament;
use Illuminate\Foundation\Testing\RefreshDatabase;
use Livewire\Livewire;
uses(RefreshDatabase::class);
beforeEach(function (): void {
Filament::setCurrentPanel('system');
Filament::bootCurrentPanel();
CarbonImmutable::setTestNow(CarbonImmutable::parse('2026-04-27 12:00:00'));
});
afterEach(function (): void {
CarbonImmutable::setTestNow();
});
it('lists the worst workspaces first with dominant reasons and one platform-safe next link per row', function (): void {
actingAsExplainabilitySystemUser();
$opsWorkspace = seedExplainabilityWorkspace('Alpha Operations');
OperationRun::factory()
->forTenant($opsWorkspace['tenant'])
->create([
'workspace_id' => (int) $opsWorkspace['workspace']->getKey(),
'status' => OperationRunStatus::Queued->value,
'outcome' => OperationRunOutcome::Pending->value,
'created_at' => now()->subHours(2),
'started_at' => null,
]);
$providerWorkspace = seedExplainabilityWorkspace('Beta Provider');
ProviderConnection::query()
->where('tenant_id', (int) $providerWorkspace['tenant']->getKey())
->update([
'is_enabled' => true,
'consent_status' => ProviderConsentStatus::Granted->value,
'verification_status' => ProviderVerificationStatus::Blocked->value,
]);
$viewData = customerHealthTopWorkspaceViewData(SystemConsoleWindow::LastWeek);
$rows = collect($viewData['rows'])->take(2)->values();
expect($rows[0]['workspace_label'])->toBe('Alpha Operations')
->and($rows[0]['overall']['label'])->toBe('Critical')
->and(array_column($rows[0]['dominant_dimensions'], 'label'))->toBe(['Operational stability'])
->and($rows[0]['next_link'])->toBe([
'label' => 'Open runs',
'url' => SystemOperationRunLinks::index(),
])
->and($rows[1]['workspace_label'])->toBe('Beta Provider')
->and($rows[1]['overall']['label'])->toBe('Critical')
->and(array_column($rows[1]['dominant_dimensions'], 'label'))->toBe(['Provider connection health'])
->and($rows[1]['next_link'])->toBe([
'label' => 'Review health details',
'url' => SystemDirectoryLinks::tenantDetail($providerWorkspace['tenant']).'?window='.SystemConsoleWindow::LastWeek,
])
->and($rows->every(fn (array $row): bool => count($row['dominant_dimensions']) <= 2))->toBeTrue()
->and($rows->every(fn (array $row): bool => ! str_contains($row['next_link']['url'], '/admin/')))->toBeTrue()
->and(array_key_exists('failed_count', $rows[0]))->toBeFalse();
});
/**
* @return array<string, mixed>
*/
function customerHealthTopWorkspaceViewData(string $window = SystemConsoleWindow::LastDay): array
{
$component = Livewire::withQueryParams([
'window' => $window,
])->test(CustomerHealthTopWorkspaces::class);
$method = new ReflectionMethod(CustomerHealthTopWorkspaces::class, 'getViewData');
$method->setAccessible(true);
return $method->invoke($component->instance());
}
function actingAsExplainabilitySystemUser(): PlatformUser
{
$user = PlatformUser::factory()->create([
'capabilities' => [
PlatformCapabilities::ACCESS_SYSTEM_PANEL,
PlatformCapabilities::CONSOLE_VIEW,
PlatformCapabilities::DIRECTORY_VIEW,
PlatformCapabilities::OPERATIONS_VIEW,
],
'is_active' => true,
]);
test()->actingAs($user, 'platform');
return $user;
}
/**
* @return array{workspace: Workspace, tenant: Tenant}
*/
function seedExplainabilityWorkspace(string $workspaceName): array
{
$workspace = Workspace::factory()->create(['name' => $workspaceName]);
$tenant = Tenant::factory()->for($workspace)->create([
'name' => $workspaceName.' Tenant',
'status' => Tenant::STATUS_ACTIVE,
]);
ProviderConnection::factory()
->for($tenant)
->verifiedHealthy()
->create([
'workspace_id' => (int) $workspace->getKey(),
'is_default' => true,
]);
ReviewPack::factory()
->for($tenant)
->ready()
->create([
'workspace_id' => (int) $workspace->getKey(),
'created_at' => now()->subHour(),
'generated_at' => now()->subHour(),
'expires_at' => now()->addDays(30),
]);
ProductUsageEvent::factory()
->for($tenant)
->forEvent(ProductUsageEventCatalog::ONBOARDING_CHECKPOINT_COMPLETED)
->create([
'workspace_id' => (int) $workspace->getKey(),
'occurred_at' => now()->subMinutes(20),
]);
OperationRun::factory()
->forTenant($tenant)
->create([
'workspace_id' => (int) $workspace->getKey(),
'status' => OperationRunStatus::Completed->value,
'outcome' => OperationRunOutcome::Succeeded->value,
'created_at' => now()->subMinutes(10),
'started_at' => now()->subMinutes(15),
'completed_at' => now()->subMinutes(5),
]);
Finding::factory()
->for($tenant)
->closed()
->create([
'severity' => Finding::SEVERITY_LOW,
]);
return [
'workspace' => $workspace,
'tenant' => $tenant,
];
}

View File

@ -6,6 +6,8 @@
use App\Filament\System\Widgets\ControlTowerKpis;
use App\Filament\System\Widgets\ControlTowerRecentFailures;
use App\Filament\System\Widgets\ControlTowerTopOffenders;
use App\Filament\System\Widgets\CustomerHealthKpis;
use App\Filament\System\Widgets\CustomerHealthTopWorkspaces;
use App\Filament\System\Widgets\ProductTelemetryKpis;
use App\Models\PlatformUser;
use App\Support\Auth\PlatformCapabilities;
@ -72,17 +74,23 @@
$widgets = $component->instance()->getWidgets();
expect($widgets)->toHaveCount(5)
expect($widgets)->toHaveCount(7)
->and($widgets[1])->toBeInstanceOf(WidgetConfiguration::class)
->and($widgets[2])->toBeInstanceOf(WidgetConfiguration::class)
->and($widgets[3])->toBeInstanceOf(WidgetConfiguration::class)
->and($widgets[4])->toBeInstanceOf(WidgetConfiguration::class)
->and($widgets[1]->widget)->toBe(ControlTowerKpis::class)
->and($widgets[2]->widget)->toBe(ProductTelemetryKpis::class)
->and($widgets[3]->widget)->toBe(ControlTowerTopOffenders::class)
->and($widgets[4]->widget)->toBe(ControlTowerRecentFailures::class)
->and($widgets[5])->toBeInstanceOf(WidgetConfiguration::class)
->and($widgets[6])->toBeInstanceOf(WidgetConfiguration::class)
->and($widgets[1]->widget)->toBe(CustomerHealthKpis::class)
->and($widgets[2]->widget)->toBe(CustomerHealthTopWorkspaces::class)
->and($widgets[3]->widget)->toBe(ControlTowerKpis::class)
->and($widgets[4]->widget)->toBe(ProductTelemetryKpis::class)
->and($widgets[5]->widget)->toBe(ControlTowerTopOffenders::class)
->and($widgets[6]->widget)->toBe(ControlTowerRecentFailures::class)
->and($widgets[1]->getProperties())->toBe(['window' => SystemConsoleWindow::LastWeek])
->and($widgets[2]->getProperties())->toBe(['window' => SystemConsoleWindow::LastWeek])
->and($widgets[3]->getProperties())->toBe(['window' => SystemConsoleWindow::LastWeek])
->and($widgets[4]->getProperties())->toBe(['window' => SystemConsoleWindow::LastWeek]);
->and($widgets[4]->getProperties())->toBe(['window' => SystemConsoleWindow::LastWeek])
->and($widgets[5]->getProperties())->toBe(['window' => SystemConsoleWindow::LastWeek])
->and($widgets[6]->getProperties())->toBe(['window' => SystemConsoleWindow::LastWeek]);
});

View File

@ -76,7 +76,8 @@
->assertSee('Residual Directory Workspace')
->assertSee('Connectivity signals')
->assertSee('Residual Default Connection')
->assertSee('Open in /admin')
->assertSee('Open in tenant admin')
->assertSee('Requires tenant admin membership.')
->assertSee(SystemDirectoryLinks::adminTenant($tenant), false)
->assertSee('Open operations runs')
->assertSee(SystemOperationRunLinks::index(), false)

View File

@ -0,0 +1,46 @@
<?php
declare(strict_types=1);
use App\Support\CustomerHealth\CustomerHealthDimensionCatalog;
it('exposes the fixed first-slice health dimensions and their time basis', function (): void {
$catalog = new CustomerHealthDimensionCatalog();
expect($catalog->names())->toBe([
CustomerHealthDimensionCatalog::ONBOARDING_READINESS,
CustomerHealthDimensionCatalog::PROVIDER_CONNECTION_HEALTH,
CustomerHealthDimensionCatalog::OPERATIONAL_STABILITY,
CustomerHealthDimensionCatalog::GOVERNANCE_PRESSURE,
CustomerHealthDimensionCatalog::REVIEW_PACK_READINESS,
CustomerHealthDimensionCatalog::ENGAGEMENT_FRESHNESS,
])->and($catalog->visibleDimensions())->toBe([
CustomerHealthDimensionCatalog::ONBOARDING_READINESS => 'Onboarding readiness',
CustomerHealthDimensionCatalog::PROVIDER_CONNECTION_HEALTH => 'Provider connection health',
CustomerHealthDimensionCatalog::OPERATIONAL_STABILITY => 'Operational stability',
CustomerHealthDimensionCatalog::GOVERNANCE_PRESSURE => 'Governance pressure',
CustomerHealthDimensionCatalog::REVIEW_PACK_READINESS => 'Review-pack readiness',
CustomerHealthDimensionCatalog::ENGAGEMENT_FRESHNESS => 'Engagement freshness',
])->and($catalog->isWindowed(CustomerHealthDimensionCatalog::OPERATIONAL_STABILITY))->toBeTrue()
->and($catalog->isWindowed(CustomerHealthDimensionCatalog::REVIEW_PACK_READINESS))->toBeTrue()
->and($catalog->isWindowed(CustomerHealthDimensionCatalog::ENGAGEMENT_FRESHNESS))->toBeTrue()
->and($catalog->isWindowed(CustomerHealthDimensionCatalog::ONBOARDING_READINESS))->toBeFalse()
->and($catalog->isWindowed(CustomerHealthDimensionCatalog::PROVIDER_CONNECTION_HEALTH))->toBeFalse()
->and($catalog->isWindowed(CustomerHealthDimensionCatalog::GOVERNANCE_PRESSURE))->toBeFalse();
});
it('resolves the overall health level using the fixed severity precedence', function (): void {
$catalog = new CustomerHealthDimensionCatalog();
expect($catalog->resolveOverallLevel(['ok', 'unknown']))->toBe('unknown')
->and($catalog->resolveOverallLevel(['ok', 'warn', 'unknown']))->toBe('warn')
->and($catalog->resolveOverallLevel(['critical', 'ok']))->toBe('critical')
->and($catalog->resolveOverallLevel(['ok']))->toBe('ok');
});
it('rejects unknown customer health dimensions', function (): void {
$catalog = new CustomerHealthDimensionCatalog();
expect(fn () => $catalog->definition('customer_health.unknown'))
->toThrow(InvalidArgumentException::class, 'Unknown customer health dimension');
});

View File

@ -0,0 +1,414 @@
<?php
declare(strict_types=1);
use App\Models\OperationRun;
use App\Models\PlatformUser;
use App\Models\ProductUsageEvent;
use App\Models\ProviderConnection;
use App\Models\ReviewPack;
use App\Models\Finding;
use App\Models\Tenant;
use App\Models\TenantOnboardingSession;
use App\Models\Workspace;
use App\Support\CustomerHealth\CustomerHealthDimensionCatalog;
use App\Support\CustomerHealth\WorkspaceHealthSummaryQuery;
use App\Support\Onboarding\OnboardingLifecycleState;
use App\Support\OperationRunOutcome;
use App\Support\OperationRunStatus;
use App\Support\Auth\PlatformCapabilities;
use App\Support\ProductTelemetry\ProductUsageEventCatalog;
use App\Support\Providers\ProviderConsentStatus;
use App\Support\Providers\ProviderVerificationStatus;
use App\Support\System\SystemDirectoryLinks;
use App\Support\System\SystemOperationRunLinks;
use App\Support\SystemConsole\SystemConsoleWindow;
use Carbon\CarbonImmutable;
use Illuminate\Foundation\Testing\RefreshDatabase;
uses(RefreshDatabase::class);
beforeEach(function (): void {
CarbonImmutable::setTestNow(CarbonImmutable::parse('2025-02-15 12:00:00'));
});
afterEach(function (): void {
CarbonImmutable::setTestNow();
});
it('derives workspace health from existing onboarding, provider, and telemetry truth', function (): void {
$workspace = Workspace::factory()->create(['name' => 'Acme']);
$tenant = Tenant::factory()->for($workspace)->create([
'name' => 'Acme Production',
'status' => Tenant::STATUS_ACTIVE,
]);
ProviderConnection::factory()
->for($tenant)
->create([
'workspace_id' => (int) $workspace->getKey(),
'is_default' => true,
'is_enabled' => true,
'consent_status' => ProviderConsentStatus::Granted->value,
'verification_status' => ProviderVerificationStatus::Blocked->value,
]);
ProductUsageEvent::factory()
->for($tenant)
->forEvent(ProductUsageEventCatalog::ONBOARDING_CHECKPOINT_COMPLETED)
->create([
'workspace_id' => (int) $workspace->getKey(),
'occurred_at' => now()->subHours(2),
]);
Finding::factory()
->for($tenant)
->closed()
->create([
'severity' => Finding::SEVERITY_LOW,
]);
$summary = summaryForWorkspace($workspace);
expect($summary['overall_level'])->toBe('critical')
->and($summary['dimensions'][CustomerHealthDimensionCatalog::ONBOARDING_READINESS]['level'])->toBe('ok')
->and($summary['dimensions'][CustomerHealthDimensionCatalog::PROVIDER_CONNECTION_HEALTH]['level'])->toBe('critical')
->and($summary['dimensions'][CustomerHealthDimensionCatalog::ENGAGEMENT_FRESHNESS]['level'])->toBe('ok')
->and($summary['dominant_dimension_keys'])->toBe([CustomerHealthDimensionCatalog::PROVIDER_CONNECTION_HEALTH, CustomerHealthDimensionCatalog::OPERATIONAL_STABILITY, CustomerHealthDimensionCatalog::REVIEW_PACK_READINESS])
->and($summary['next_link'])->toBe([
'label' => 'Review health details',
'url' => SystemDirectoryLinks::tenantDetail($tenant).'?window='.SystemConsoleWindow::LastDay,
]);
});
it('applies the selected window review-pack readiness rules', function (): void {
$unknownWorkspace = createWorkspaceWithActiveTenant('Unknown Workspace');
$warnWorkspace = createWorkspaceWithActiveTenant('Warn Workspace');
$okWorkspace = createWorkspaceWithActiveTenant('Ok Workspace');
$criticalWorkspace = createWorkspaceWithActiveTenant('Critical Workspace');
ProductUsageEvent::factory()
->for($warnWorkspace['tenant'])
->forEvent(ProductUsageEventCatalog::REVIEW_PACK_REQUESTED)
->create([
'workspace_id' => (int) $warnWorkspace['workspace']->getKey(),
'occurred_at' => now()->subHours(1),
]);
ReviewPack::factory()
->for($okWorkspace['tenant'])
->ready()
->create([
'workspace_id' => (int) $okWorkspace['workspace']->getKey(),
'created_at' => now()->subHours(3),
'generated_at' => now()->subHours(2),
'expires_at' => now()->addDays(30),
]);
ReviewPack::factory()
->for($criticalWorkspace['tenant'])
->failed()
->create([
'workspace_id' => (int) $criticalWorkspace['workspace']->getKey(),
'created_at' => now()->subHours(2),
]);
$summaries = app(WorkspaceHealthSummaryQuery::class)
->summaries(SystemConsoleWindow::LastDay)
->keyBy('workspace_id');
expect($summaries[(int) $unknownWorkspace['workspace']->getKey()]['dimensions'][CustomerHealthDimensionCatalog::REVIEW_PACK_READINESS]['level'])->toBe('unknown')
->and($summaries[(int) $warnWorkspace['workspace']->getKey()]['dimensions'][CustomerHealthDimensionCatalog::REVIEW_PACK_READINESS]['level'])->toBe('warn')
->and($summaries[(int) $okWorkspace['workspace']->getKey()]['dimensions'][CustomerHealthDimensionCatalog::REVIEW_PACK_READINESS]['level'])->toBe('ok')
->and($summaries[(int) $criticalWorkspace['workspace']->getKey()]['dimensions'][CustomerHealthDimensionCatalog::REVIEW_PACK_READINESS]['level'])->toBe('critical');
});
it('uses the selected window for operations and engagement freshness', function (): void {
$workspace = Workspace::factory()->create(['name' => 'Windowed Signals']);
$tenant = Tenant::factory()->for($workspace)->create([
'status' => Tenant::STATUS_ACTIVE,
'name' => 'Windowed Tenant',
]);
ProviderConnection::factory()
->for($tenant)
->verifiedHealthy()
->create([
'workspace_id' => (int) $workspace->getKey(),
'is_default' => true,
]);
ProductUsageEvent::factory()
->for($tenant)
->forEvent(ProductUsageEventCatalog::ONBOARDING_CHECKPOINT_COMPLETED)
->create([
'workspace_id' => (int) $workspace->getKey(),
'occurred_at' => now()->subDays(3),
]);
OperationRun::factory()
->forTenant($tenant)
->create([
'workspace_id' => (int) $workspace->getKey(),
'status' => OperationRunStatus::Completed->value,
'outcome' => OperationRunOutcome::Failed->value,
'created_at' => now()->subDays(2),
'started_at' => now()->subDays(2)->subMinutes(5),
'completed_at' => now()->subDays(2),
]);
$summary = summaryForWorkspace($workspace);
expect($summary['dimensions'][CustomerHealthDimensionCatalog::ENGAGEMENT_FRESHNESS]['level'])->toBe('warn')
->and($summary['dimensions'][CustomerHealthDimensionCatalog::OPERATIONAL_STABILITY]['level'])->toBe('unknown');
});
it('keeps governance pressure explicit until governance truth exists', function (): void {
$workspace = Workspace::factory()->create(['name' => 'Governance Signals']);
$tenant = Tenant::factory()->for($workspace)->create([
'status' => Tenant::STATUS_ACTIVE,
'name' => 'Governance Tenant',
]);
ProviderConnection::factory()
->for($tenant)
->verifiedHealthy()
->create([
'workspace_id' => (int) $workspace->getKey(),
'is_default' => true,
]);
ReviewPack::factory()
->for($tenant)
->ready()
->create([
'workspace_id' => (int) $workspace->getKey(),
'created_at' => now()->subHour(),
'generated_at' => now()->subHour(),
'expires_at' => now()->addDays(30),
]);
ProductUsageEvent::factory()
->for($tenant)
->forEvent(ProductUsageEventCatalog::ONBOARDING_CHECKPOINT_COMPLETED)
->create([
'workspace_id' => (int) $workspace->getKey(),
'occurred_at' => now()->subMinutes(20),
]);
OperationRun::factory()
->forTenant($tenant)
->create([
'workspace_id' => (int) $workspace->getKey(),
'status' => OperationRunStatus::Completed->value,
'outcome' => OperationRunOutcome::Succeeded->value,
'created_at' => now()->subMinutes(10),
'started_at' => now()->subMinutes(15),
'completed_at' => now()->subMinutes(5),
]);
$summaryWithoutGovernanceTruth = summaryForWorkspace($workspace);
expect($summaryWithoutGovernanceTruth['dimensions'][CustomerHealthDimensionCatalog::GOVERNANCE_PRESSURE]['level'])->toBe('unknown');
Finding::factory()
->for($tenant)
->closed()
->create([
'severity' => Finding::SEVERITY_LOW,
]);
$summaryWithGovernanceTruth = summaryForWorkspace($workspace);
expect($summaryWithGovernanceTruth['dimensions'][CustomerHealthDimensionCatalog::GOVERNANCE_PRESSURE]['level'])->toBe('ok');
});
it('ignores archived workspaces and archived tenant truth for active workspace summaries', function (): void {
$archivedWorkspace = Workspace::factory()->create([
'name' => 'Archived Workspace',
'archived_at' => now()->subDay(),
]);
$archivedWorkspaceTenant = Tenant::factory()->for($archivedWorkspace)->create([
'status' => Tenant::STATUS_ACTIVE,
]);
ProductUsageEvent::factory()
->for($archivedWorkspaceTenant)
->create([
'workspace_id' => (int) $archivedWorkspace->getKey(),
'occurred_at' => now()->subHour(),
]);
$workspace = Workspace::factory()->create(['name' => 'Mixed Workspace']);
$activeTenant = Tenant::factory()->for($workspace)->create([
'status' => Tenant::STATUS_ACTIVE,
'name' => 'Active Tenant',
]);
$archivedTenant = Tenant::factory()->for($workspace)->create([
'status' => Tenant::STATUS_ARCHIVED,
'name' => 'Archived Tenant',
'deleted_at' => now()->subDay(),
]);
ProviderConnection::factory()
->for($activeTenant)
->verifiedHealthy()
->create([
'workspace_id' => (int) $workspace->getKey(),
'is_default' => true,
]);
ProviderConnection::factory()
->for($archivedTenant)
->create([
'workspace_id' => (int) $workspace->getKey(),
'is_default' => true,
'is_enabled' => true,
'consent_status' => ProviderConsentStatus::Granted->value,
'verification_status' => ProviderVerificationStatus::Blocked->value,
]);
$summaries = app(WorkspaceHealthSummaryQuery::class)->summaries();
$summary = $summaries->firstWhere('workspace_id', (int) $workspace->getKey());
expect($summaries->contains(fn (array $item): bool => $item['workspace_id'] === (int) $archivedWorkspace->getKey()))->toBeFalse()
->and($summary)->not->toBeNull()
->and($summary['dimensions'][CustomerHealthDimensionCatalog::PROVIDER_CONNECTION_HEALTH]['level'])->toBe('ok');
});
it('sorts the attention list by severity, breadth, and name', function (): void {
$platformUser = PlatformUser::factory()->create([
'capabilities' => [
PlatformCapabilities::ACCESS_SYSTEM_PANEL,
PlatformCapabilities::CONSOLE_VIEW,
PlatformCapabilities::OPERATIONS_VIEW,
],
'is_active' => true,
]);
$this->actingAs($platformUser, 'platform');
$criticalWorkspace = Workspace::factory()->create(['name' => 'Critical Workspace']);
$criticalTenant = Tenant::factory()->for($criticalWorkspace)->create([
'status' => Tenant::STATUS_ACTIVE,
'name' => 'Critical Tenant',
]);
ProviderConnection::factory()
->for($criticalTenant)
->verifiedHealthy()
->create([
'workspace_id' => (int) $criticalWorkspace->getKey(),
'is_default' => true,
]);
OperationRun::factory()
->forTenant($criticalTenant)
->create([
'workspace_id' => (int) $criticalWorkspace->getKey(),
'status' => OperationRunStatus::Queued->value,
'outcome' => OperationRunOutcome::Pending->value,
'created_at' => now()->subHours(2),
'started_at' => null,
]);
$warnWorkspace = Workspace::factory()->create(['name' => 'Warn Workspace']);
$warnTenant = Tenant::factory()->for($warnWorkspace)->create([
'status' => Tenant::STATUS_ACTIVE,
'name' => 'Warn Tenant',
]);
ProviderConnection::factory()
->for($warnTenant)
->verifiedHealthy()
->create([
'workspace_id' => (int) $warnWorkspace->getKey(),
'is_default' => true,
]);
ProductUsageEvent::factory()
->for($warnTenant)
->forEvent(ProductUsageEventCatalog::ONBOARDING_CHECKPOINT_COMPLETED)
->create([
'workspace_id' => (int) $warnWorkspace->getKey(),
'occurred_at' => now()->subDays(5),
]);
$unknownWorkspace = Workspace::factory()->create(['name' => 'Unknown Workspace']);
TenantOnboardingSession::factory()
->forWorkspace($unknownWorkspace)
->create([
'lifecycle_state' => OnboardingLifecycleState::Draft->value,
]);
$attention = app(WorkspaceHealthSummaryQuery::class)
->attentionNeeded(SystemConsoleWindow::LastDay, 3)
->values();
expect($attention->pluck('workspace_name')->all())->toBe([
'Critical Workspace',
'Unknown Workspace',
'Warn Workspace',
])
->and($attention[0]['next_link'])->toBe([
'label' => 'Open runs',
'url' => SystemOperationRunLinks::index(),
]);
});
/**
* @return array{workspace: Workspace, tenant: Tenant}
*/
function createWorkspaceWithActiveTenant(string $workspaceName): array
{
$workspace = Workspace::factory()->create(['name' => $workspaceName]);
$tenant = Tenant::factory()->for($workspace)->create([
'name' => $workspaceName.' Tenant',
'status' => Tenant::STATUS_ACTIVE,
]);
ProviderConnection::factory()
->for($tenant)
->verifiedHealthy()
->create([
'workspace_id' => (int) $workspace->getKey(),
'is_default' => true,
]);
return [
'workspace' => $workspace,
'tenant' => $tenant,
];
}
/**
* @return array{
* workspace_id: int,
* workspace_name: string,
* overall_level: string,
* dimensions: array<string, array{label: string, level: string, windowed: bool}>,
* dominant_dimension_keys: list<string>,
* non_ok_dimension_count: int,
* next_link: array{label: string, url: string}
* }
*/
function summaryForWorkspace(Workspace $workspace): array
{
/** @var array{
* workspace_id: int,
* workspace_name: string,
* overall_level: string,
* dimensions: array<string, array{label: string, level: string, windowed: bool}>,
* dominant_dimension_keys: list<string>,
* non_ok_dimension_count: int,
* next_link: array{label: string, url: string}
* } $summary
*/
$summary = app(WorkspaceHealthSummaryQuery::class)
->summaryForWorkspace($workspace, SystemConsoleWindow::LastDay);
return $summary;
}

View File

@ -5,7 +5,7 @@ # Spec Candidates
>
> **Flow**: Inbox → Qualified → Planned → Spec created → moved to `Promoted to Spec`
> **Last reviewed**: 2026-04-25 (added Product Scalability & Self-Service Foundation candidates, Additional Solo-Founder Scale Guardrails candidates, Microsoft-first provider-extensible Decision-Based Operating candidates, and Private AI Execution & Usage Governance Foundation candidates; retained Codebase Quality & Engineering Maturity cluster and existing strategic hardening lanes)
> **Last reviewed**: 2026-04-27 (added Audited Support Sessions / Assisted Tenant Access and Audience-Aware Decision Surface Adoption Closure; retained Product Scalability & Self-Service Foundation, Codebase Quality & Engineering Maturity cluster, Microsoft-first provider-extensible Decision-Based Operating candidates, and Private AI Execution & Usage Governance Foundation candidates)
---
@ -725,6 +725,46 @@ ### System Panel Least-Privilege Capability Model
- **Strategic sequencing**: First item in this cluster because it is the only finding with direct enterprise security / least-privilege implications.
- **Priority**: high
### Audited Support Sessions / Assisted Tenant Access
- **Type**: security hardening / platform-plane-to-tenant-plane access boundary
- **Source**: product candidate 2026-04-27 — explicit separation between Platform Control Plane (`/system`) and Customer/Tenant Admin Plane (`/admin`)
- **Problem**: Platform operators sometimes need tenant-context visibility for support, but the current control-plane/admin-plane split makes a plain `Open in /admin` affordance misleading for platform-only users. Granting permanent tenant memberships or hidden cross-tenant superuser access would solve the support friction in the wrong way by collapsing least privilege, auditability, and customer trust.
- **Why it matters**: TenantPilot needs an enterprise-safe answer to "how can support look at a tenant?" The answer cannot be silent impersonation or blanket `/admin` access. It must be explicit, tenant-scoped, reason-bound, time-limited, visible in the UI, and fully auditable.
- **Proposed direction**:
- introduce a `support_sessions` model bound to one workspace/tenant, one platform user, one mode, one reason, and one expiry
- allow support sessions to be started only from `/system`, never implicitly from `/admin`
- make read-only the default and smallest promotable slice; keep elevated support as a separately capability-gated follow-up or tightly bounded extension
- show a persistent non-dismissible `/admin` banner with workspace/tenant, platform user, mode, reason, expiry, and `End session`
- thread `support_session_id` and support-context metadata into audit events and any allowed elevated mutations
- replace ambiguous `Open in /admin` affordances with decision-based copy: real tenant membership -> `Open in tenant admin`; support-capable platform user -> `Start support session`; otherwise -> `Admin access requires tenant membership`
- enforce expiry and scope server-side so a session cannot cross tenants or remain valid after `expires_at`
- **Candidate capabilities**:
- `platform.support_sessions.view`
- `platform.support_sessions.start`
- `platform.support_sessions.end`
- `platform.support_sessions.end_any`
- `platform.support_sessions.elevate`
- `platform.support_sessions.audit_view`
- **Scope boundaries**:
- **In scope**: support-session model/status lifecycle, required reason, duration defaults/limits, start/end/expiry workflow, visible `/admin` support banner, read-only enforcement for support sessions, audit events, link/CTA semantics, and tests for isolation and expiry
- **Out of scope**: silent impersonation as a tenant user, permanent platform-user tenant memberships, Entra-side membership automation, full customer approval workflow, recording/screenshots, or broad privileged write access by default
- **Acceptance points**:
- a platform user still has no automatic `/admin` access without real tenant membership or an active support session
- a support-capable platform user can start a time-limited session for one target workspace/tenant with a mandatory reason
- read-only support sessions can open tenant/admin pages and inspect relevant records but cannot trigger mutations such as restore, settings change, exception creation, membership change, or other tenant-changing actions
- the `/admin` banner remains visible for the full session and shows enough information to make the access state unmistakable
- ended or expired sessions immediately lose access server-side and emit explicit audit events
- tests prove a support session cannot be reused for another tenant or hidden behind UI-only checks
- **Risks / open questions**:
- v1 should likely stay read-only to avoid collapsing this candidate into a broader privileged-write workflow
- Elevated support may be necessary later, but it needs its own capability, shorter expiry, stronger audit semantics, and likely separate prioritization
- The product must decide whether some diagnostics/support surfaces belong in `/system` instead of requiring tenant-plane access at all
- Support-session audit records must remain visibly distinct from real customer-user actions
- **Dependencies**: System Panel Least-Privilege Capability Model, tenant/admin access boundary, platform-user capability model, audit log foundation, workspace/tenant scoping helpers, support-diagnostics surfaces
- **Related specs / candidates**: Support Diagnostic Pack, In-App Support Request with Context, Operational Controls & Feature Flags, Security Trust Pack Light, platform superadmin / break-glass rules
- **Strategic sequencing**: Immediately after System Panel least-privilege hardening. First shrink coarse platform visibility, then introduce an explicit audited bridge for rare tenant-context support access instead of relying on hidden superuser semantics.
- **Priority**: high
### Static Analysis Baseline for Platform Code
- **Type**: quality gate / developer experience hardening
- **Source**: full codebase quality audit 2026-04-25 — the repo has strong Pest and lane-based tests but no visible PHPStan/Larastan/Psalm/Rector gate
@ -874,12 +914,13 @@ ### RestoreService Responsibility Split
> Recommended sequence for this cluster:
> 1. **System Panel Least-Privilege Capability Model**
> 2. **Static Analysis Baseline for Platform Code**
> 3. **Architecture Boundary Guard Tests**
> 4. **Filament Hotspot Decomposition Foundation**
> 5. **RestoreService Responsibility Split**
> 2. **Audited Support Sessions / Assisted Tenant Access**
> 3. **Static Analysis Baseline for Platform Code**
> 4. **Architecture Boundary Guard Tests**
> 5. **Filament Hotspot Decomposition Foundation**
> 6. **RestoreService Responsibility Split**
>
> Why this order: first close the enterprise security/least-privilege gap, then add quality gates, then protect architecture boundaries, and only then start behavior-preserving decomposition of the largest UI/service hotspots. This avoids a broad rewrite while directly addressing the audit's highest-leverage risks.
> Why this order: first close the coarse platform-capability gap, then add an explicit audited bridge for rare tenant-context support access, then add quality gates, then protect architecture boundaries, and only then start behavior-preserving decomposition of the largest UI/service hotspots. This avoids a broad rewrite while directly addressing the audit's highest-leverage security and maintainability risks.
> Platform Hardening — OperationRun UX Consistency cluster: these candidates prevent OperationRun-starting features from drifting into surface-local UX behavior. The goal is not to rebuild the Operations Hub, progress system, or notification architecture in one step. The immediate priority is to make OperationRun start UX contract-driven so new features cannot hand-roll local toasts, operation links, browser events, and queued-notification decisions independently.
@ -1612,6 +1653,153 @@ ### Surface Taxonomy & Workflow-First IA Classification
- **Dependencies**: Decision-First Operating Constitution Hardening, existing navigation/context/action-surface specs, product surface inventory
- **Priority**: high
### Audience-Aware Decision Surface Adoption Closure
- **Priority**: P0
- **Type**: UX architecture adoption / platform hardening
- **Roadmap fit**: Cross-cutting platform quality, customer-readiness, MSP operator UX, customer read-only foundation
- **Depends on**: Existing `EnterpriseDetail`, `OperatorExplanation`, `GovernanceArtifactTruth`, `VerificationReportViewer`, `SupportDiagnosticBundle`, RBAC/capability model
- **Do not build**: A parallel UI framework
- **Problem**: TenantPilot already has strong shared UI foundations for decision-grade detail pages, governance artifact truth, operator explanations, verification reports, and support diagnostics, but adoption is inconsistent across the platform. Several operational and governance pages still expose too much internal diagnostic, lifecycle, context, reason, JSON, and support/debug information in the default reading path. The recurring issue is not missing data quality. It is information hierarchy: decision content, diagnostics, evidence, and raw support/debug payloads are often rendered as equal-priority blocks.
- **Goal**: Harden the existing decision-first UI system by introducing audience-aware disclosure rules and applying them to the highest-risk surfaces first. Default pages should become customer-readable while retaining full operator and support depth through progressive disclosure and role/capability gates.
- **Non-goals**:
- Do not introduce a new UI framework.
- Do not replace `EnterpriseDetail`.
- Do not remove diagnostics or raw evidence.
- Do not weaken auditability.
- Do not hide evidence from authorized operators/support users.
- Do not redesign the whole platform in one pass.
- Do not migrate every page in this spec.
- **Existing foundations to reuse**:
- `EnterpriseDetail`
- `OperatorExplanation`
- `GovernanceArtifactTruth`
- `VerificationReportViewer`
- `SupportDiagnosticBundle`
- existing Filament-native Sections/Infolists/Actions/Tabs/Accordions
- **Reuse rule**: Any new helper must be a small visibility/disclosure layer, not a competing rendering system.
- **First slice**:
1. `OperationRun` viewer
2. Managed Tenant Onboarding verify step
- **Requirements**:
- **Decision surface**: each target page MUST show a clear default decision surface with status, reason, impact, primary next action, one dominant CTA, optional one secondary CTA, and a short artifact/result summary.
- **Diagnostics**: lifecycle, timing, related operation, verification-report detail, drift/report detail, supporting evidence, and provider diagnostic summaries MUST be secondary, collapsed, tabbed, or visually lower priority.
- **Support / raw evidence**: raw JSON, context payloads, fingerprints, reason owner, platform reason family, viewer context, tenant selector context, monitoring detail, and copy/show-raw actions MUST NOT appear in the default customer-readable path. They must be collapsed and capability-gated where applicable.
- **Audience modes**: the target surfaces MUST distinguish customer/read-only default, operator/MSP diagnostics, and platform/support raw evidence. Customer/read-only users MUST NOT see internal debug semantics by default. Operators MAY expand diagnostics. Support/platform users MAY access raw evidence when authorized.
- **One primary action**: each target surface MUST expose only one dominant next action. Secondary links such as `Open operation`, `View tenant`, `Technical details`, or `Show JSON` must not visually compete with the primary remediation action.
- **No duplicate truth**: the same blocker, reason, or next action MUST NOT be repeated across multiple visible cards. If the dominant blocker is `Admin consent required`, the page may show it once in the decision surface and then provide supporting evidence in diagnostics, but it must not repeat that message in readiness, permission diagnostics, contextual help, verification summary, and issue lists at equal priority.
- **OperationRun viewer target state**:
- **Default visible**: operation status/outcome, human-readable reason, customer-readable impact, primary next action, artifact/result summary, limited actions
- **Secondary / collapsed**: lifecycle, timings, related context, support diagnostics, verification/drift/report internals
- **Support/raw gated**: raw context, JSON, fingerprints, reason ownership, platform reason family, monitoring detail
- **Managed Tenant Onboarding verify-step target state**:
- **Default visible**: onboarding readiness, current step, status, dominant blocker, primary next action, supporting evidence links
- **Secondary**: verification summary, required permissions, operation link, technical details
- **Hidden / fallback**: permission diagnostics should be visible only as fallback when no stored verification report is available. Once a verification report exists, permission details move into supporting evidence or technical details.
- **Acceptance criteria**:
- `OperationRun` viewer default path is readable in under 5 seconds.
- `OperationRun` viewer shows one dominant next action.
- `OperationRun` viewer default path does not show raw JSON, raw context, fingerprints, reason owner, platform reason family, or monitoring detail.
- `OperationRun` diagnostics remain accessible to authorized operators.
- `OperationRun` raw/support details are collapsed and capability-gated where applicable.
- Managed Tenant Onboarding verify step shows exactly one primary next action.
- Managed Tenant Onboarding verify step does not duplicate permission/consent blockers across readiness, diagnostics, contextual help, and report sections.
- Permission diagnostics are hidden when a stored verification report exists and visible only as fallback when no report exists.
- `Current checkpoint` or other internal lifecycle wording is replaced with customer/operator-friendly wording such as `Step`.
- Duplicate visible headings such as `Verification report / Verification report` are removed.
- Existing support diagnostics and verification report data remain available.
- **Required tests**:
- focused Pest coverage proving the default view shows status, reason, impact, and primary next action
- internal debug semantics are not default-visible
- raw JSON/context/fingerprints are collapsed or gated
- customer/read-only role does not see support/raw details by default
- operator role can access diagnostics
- support/platform role can access raw evidence where authorized
- onboarding verify step renders one primary action
- onboarding permission diagnostics are fallback-only when a verification report exists
- no duplicate visible decision headings exist
- **Implementation notes**:
- Prefer small, composable changes.
- Add a visibility/disclosure helper only if existing policies are insufficient.
- Extend existing EnterpriseDetail/Verification/Support surfaces instead of replacing them.
- Reduce one-off Blade/Tailwind cards where shared patterns can express the same concept.
- Preserve auditability and evidence depth.
- Preserve existing RBAC/capability enforcement.
- Preserve Livewire v4 and Filament v5 conventions.
- **Out of scope**:
- full platform-wide migration
- customer read-only portal implementation
- PDF/export redesign
- redesign of all Findings/Baseline/Evidence pages
- new AI explanation features
- new support ticketing workflow
> Later / dependent candidates: after the adoption-closure slice above is specified and implemented, keep the next migrations explicitly dependent instead of bundling them into the same P0 effort.
#### Later / dependent candidates
##### Findings & Risk Acceptance Decision Surface Migration
- **Priority**: P1
- **Type**: pattern adoption / workflow UX consolidation
- **Depends on**: Audience-Aware Decision Surface Adoption Closure
- **Roadmap fit**: R1.5 Findings Workflow V2, R1.6 Exceptions / Risk Acceptance, R2 Customer Read-only View
- **Problem**: Finding and Finding Exception detail pages currently expose workflow status, ownership, severity, timestamps, exception state, and remediation context through local Filament sections. These pages are functional, but they do not consistently use the shared decision-first detail patterns. As Findings and Risk Acceptance become customer-facing governance workflows, the default view must clearly separate risk decision, owner/action, diagnostic detail, and evidence/support context.
- **Goal**: Migrate Finding and Finding Exception detail pages toward the shared decision surface model.
- **First slice**:
- Finding detail page
- Finding Exception detail page
- **Requirements**:
- default view shows risk status, severity, reason, impact, owner, due date, and next action
- workflow actions are clearly prioritized
- risk acceptance state is shown as a decision state, not just metadata
- evidence and occurrence history are secondary
- raw/internal context is hidden or collapsed
- customer/read-only users see risk posture and accepted-risk status without internal debug semantics
- **Acceptance criteria**:
- Finding detail page has one clear primary action based on status
- Finding Exception page clearly shows accepted risk, owner, expiry, scope, and renewal/expiry state
- evidence/history is secondary
- no raw/debug payload appears in the default customer-readable view
##### Baseline & Drift Decision Surface Migration
- **Priority**: P1
- **Type**: pattern adoption / governance UX consolidation
- **Depends on**: Audience-Aware Decision Surface Adoption Closure
- **Roadmap fit**: R1 Golden Master Governance, R1.4 Drift UI, R2 Reports/Evidence
- **Problem**: Baseline and Drift pages contain decision-grade governance data but can become dense because comparison state, drift findings, policy metadata, diagnostics, and technical evidence compete in the same reading path.
- **Goal**: Apply the decision-first hierarchy to Baseline Profile, Baseline Snapshot, and Baseline Compare surfaces.
- **First slice**:
- Baseline Profile view
- Baseline Compare landing / matrix summary
- **Requirements**:
- default view shows baseline status, last compare result, drift summary, severity, and primary next action
- detailed matrix data is secondary
- technical comparison diagnostics are collapsed or moved behind filters/tabs
- customer-readable summaries are separated from operator investigation tools
- raw comparison context and fingerprints are not default-visible
- **Acceptance criteria**:
- Baseline Profile view shows one primary governance action
- Baseline Compare default view summarizes drift before showing the dense matrix
- drift details remain accessible to operators
- raw/fingerprint-level data is hidden or support-only
##### Customer Read-only Decision Views
- **Priority**: P2
- **Type**: customer-facing UX / access model
- **Depends on**: Audience-Aware Decision Surface Adoption Closure, Findings & Risk Acceptance Migration, Reports/Evidence foundation
- **Roadmap fit**: R2.6 Customer Read-only View v1
- **Problem**: TenantPilot has strong operator and support detail surfaces, but customer-facing users need a calmer read-only experience focused on governance status, accepted risks, findings, evidence summaries, and review outcomes.
- **Goal**: Introduce customer read-only views that reuse the same decision-surface contracts but hide operator diagnostics and support/raw internals by default.
- **Requirements**:
- customers see baseline status, findings, accepted risks, reports, and evidence summaries
- customers do not see raw JSON, internal reason ownership, fingerprints, platform reason families, or debug context
- customers can open review-ready explanations and evidence summaries
- admin/operator actions are hidden
- support/operator users keep access to deeper diagnostics
- **Acceptance criteria**:
- customer members can understand tenant posture without technical debug details
- customer views remain audit-friendly but not overwhelming
- all customer-facing detail pages follow decision-first, diagnostics-second, evidence-third
### Personal Work IA / My Work
- **Type**: IA / workflow foundation
- **Source**: admin workspace IA discussion 2026-04-21; personal work architecture candidate pack

View File

@ -4,7 +4,7 @@ # Product Standards
> Specs reference these standards; they do not redefine them.
> Guard tests enforce critical constraints automatically.
**Last reviewed**: 2026-04-24
**Last reviewed**: 2026-04-27
---
@ -42,7 +42,7 @@ ## Related Docs
| Document | Location | Purpose |
|---|---|---|
| Constitution | `.specify/memory/constitution.md` | Permanent principles (PROP-001, BLOAT-001, OPS-UX-START-001, UI-CONST-001, DECIDE-001, UI-SURF-001, ACTSURF-001, UI-HARD-001, UI-EX-001, HDR-001, OPSURF-001, UI-FIL-001, UX-001, Action Surface Contract, RBAC-UX) |
| Constitution | `.specify/memory/constitution.md` | Permanent principles (PROP-001, BLOAT-001, OPS-UX-START-001, UI-CONST-001, DECIDE-001, DECIDE-AUD-001, UI-SURF-001, ACTSURF-001, UI-HARD-001, UI-EX-001, HDR-001, OPSURF-001, UI-FIL-001, UX-001, Action Surface Contract, RBAC-UX) |
| Product Principles | `docs/product/principles.md` | High-level product decisions |
| Table Rollout Audit | `docs/ui/filament-table-standard.md` | Rollout inventory and implementation state from Spec 125 |
| Action Surface Contract | `docs/ui/action-surface-contract.md` | Original action surface reference (now governed by this standard) |

View File

@ -0,0 +1,46 @@
# 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](../spec.md)
## Content Quality
- [x] Business value and operator outcomes stay explicit
- [x] The first slice is bounded to derived health summaries on the existing `/system` dashboard
- [x] Runtime-governance sections are present for an implementation-ready package
- [x] All mandatory sections are completed
## Requirement Completeness
- [x] No `[NEEDS CLARIFICATION]` markers remain
- [x] Requirements are testable and unambiguous
- [x] Acceptance scenarios are defined for the primary user journeys
- [x] Edge cases are identified
- [x] Scope is clearly bounded away from CRM, billing, predictive scoring, and customer-facing health portals
- [x] Dependencies and assumptions are identified
## Feature Readiness
- [x] The first slice is small enough for a bounded implementation loop
- [x] The plan identifies concrete repo surfaces likely to change
- [x] The tasks are ordered, testable, and grouped by user story
- [x] Foundational work includes the core unknown-handling and review-pack-readiness rules before dashboard adoption
- [x] No unresolved product question blocks safe implementation of the first slice
## Governance Readiness
- [x] No new persistence is introduced without justification
- [x] Provider-boundary handling and platform-safe deep-link rules are explicit
- [x] Existing RBAC and platform-plane access remain authoritative
- [x] Operator-facing surface changes include the required UI contract sections
- [x] The UI Action Matrix is populated for the modified Filament dashboard surface
- [x] The package explicitly requires one platform-safe next link per attention-needed row plus a visible time-basis cue
- [x] Default-visible content stays operator-first while raw or support-grade detail remains behind existing linked surfaces
- [x] The package avoids duplicate truth by keeping health derived-only and by reusing centralized `SystemHealth` semantics
- [x] 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.

View File

@ -0,0 +1,227 @@
# Implementation Plan: Customer Health Score
**Branch**: `245-customer-health-score` | **Date**: 2026-04-27 | **Spec**: `/Users/ahmeddarrazi/Documents/projects/wt-plattform/specs/245-customer-health-score/spec.md`
**Input**: Feature specification from `/Users/ahmeddarrazi/Documents/projects/wt-plattform/specs/245-customer-health-score/spec.md`
## Summary
- Add one bounded `CustomerHealth` support namespace that derives workspace-health summaries from existing onboarding, provider, telemetry, `OperationRun`, findings, and review-pack truth.
- Reuse the existing `/system` dashboard, existing dashboard window selector, and existing system widget family to show both aggregate health counts and an attention-needed workspace list.
- Reuse the existing system tenant and workspace residual detail pages as decision-first follow-up surfaces by adding one read-only customer-health card above the existing diagnostics.
- Keep the slice derived-only, Livewire v4-compatible, Filament v5-native, and free of migrations, new persistence, new panel providers, global-search changes, destructive actions, or asset changes.
## Technical Context
**Language/Version**: PHP 8.4 (Laravel 12)
**Primary Dependencies**: Laravel 12 + Filament v5 + Livewire v4 + Pest; existing `ProductTelemetrySummaryQuery`, `ProviderConnectionStateProjector`, `StuckRunClassifier`, `BadgeRenderer`, `SystemConsoleWindow`, system directory links, and system operations links
**Storage**: N/A - no new persisted health truth
**Testing**: Pest unit + feature tests only
**Validation Lanes**: fast-feedback, confidence
**Target Platform**: Sail-backed Laravel admin panel under `/system`
**Project Type**: web
**Performance Goals**: derive health summaries inline for the current system dashboard without background jobs, remote calls, or broad per-tenant page reconstruction
**Constraints**: no new score table, no customer-facing surface, no CRM or billing workflow expansion, no direct `/admin` deep links, and no new badge taxonomy
**Scale/Scope**: six fixed first-slice dimensions, one derived summary query, two dashboard widgets, one shared decision-first follow-up card on the existing system detail pages, and focused unit plus feature proof only
## First-Slice Dimension Inventory
The first slice is locked to these six dimensions only:
1. **Onboarding readiness** — point-in-time signal derived from existing onboarding-readiness truth
2. **Provider connection health** — point-in-time signal derived from existing provider consent and verification truth
3. **Operational stability** — windowed signal derived from failed and stuck `OperationRun` truth using the selected `SystemConsoleWindow`
4. **Governance pressure** — point-in-time signal derived from active high-severity, overdue, or exception-warning findings truth
5. **Review-pack readiness** — narrow mixed signal derived from recent review-pack request context plus the latest relevant `ReviewPack` state
6. **Engagement freshness** — windowed signal derived from existing `product_usage_events`
Any change to this dimension inventory requires an explicit spec update before implementation expands or swaps the slice.
## Health-Level Resolution Rules
- Reuse existing `SystemHealth` levels only: `ok`, `warn`, `critical`, `unknown`
- Overall level precedence is fixed for v1: `critical` > `warn` > `unknown` > `ok`
- Windowed dimensions must honor the selected dashboard time window
- Point-in-time dimensions must not pretend to share the same time basis as windowed dimensions
- Missing or stale source truth must remain explicit and must never silently collapse to `ok`
- Archived workspaces are excluded from active counts, and archived tenants do not contribute source truth into active workspace-health derivation
- Attention-needed workspace ordering is fixed for v1: overall severity desc, non-`ok` dimension count desc, workspace name asc, then workspace id asc
## Review-Pack Readiness Rule
`Recent` means the currently selected dashboard window. Request context comes from existing review-pack request telemetry when available, falling back to a `ReviewPack` created for the same workspace inside that same window.
| Condition | Review-pack readiness level | Notes |
|---|---|---|
| No request context and no relevant pack activity in the selected window | `unknown` | The first slice does not infer periodic review obligations from silence |
| Request context exists in the selected window and no relevant pack is usable yet | `warn` | Covers queued, running, or not-yet-materialized review-pack generation |
| Latest relevant pack in the selected window is ready and not expired | `ok` | A usable recent review pack exists |
| Latest relevant pack in the selected window is failed or expired | `critical` | Recent review-pack work ended unusably and needs attention |
## UI / Surface Guardrail Plan
- **Guardrail scope**: changed surfaces
- **Native vs custom classification summary**: native Filament dashboard plus existing custom system widget family and the existing residual system detail pages
- **Shared-family relevance**: dashboard signals/cards, compact attention list, system-safe deep links, existing `SystemHealth` badges
- **State layers in scope**: page, widget, window query, detail-link state, residual detail follow-up state
- **Handling modes by drift class or surface**: review-mandatory
- **Repository-signal treatment**: review-mandatory
- **Special surface test profiles**: standard-native-filament
- **Required tests or manual smoke**: functional-core, state-contract, follow-up-detail smoke
- **Exception path and spread control**: none
- **Active feature PR close-out entry**: Guardrail
- **List-surface review standard**: `/Users/ahmeddarrazi/Documents/projects/wt-plattform/docs/product/standards/list-surface-review-checklist.md` applies to `CustomerHealthTopWorkspaces`; accepted compact-widget exceptions are no persistence trio, no bulk actions, no row click, and no empty-state CTA
## Shared Pattern & System Fit
- **Cross-cutting feature marker**: yes
- **Systems touched**: `App\Filament\System\Pages\Dashboard`, `App\Filament\System\Pages\Directory\ViewTenant`, `App\Filament\System\Pages\Directory\ViewWorkspace`, `App\Filament\System\Widgets\ControlTowerHealthIndicator`, `App\Filament\System\Widgets\ControlTowerTopOffenders`, `App\Support\ProductTelemetry\ProductTelemetrySummaryQuery`, `App\Services\Providers\ProviderConnectionStateProjector`, `App\Support\SystemConsole\StuckRunClassifier`, existing `Finding` truth, existing `ReviewPack` truth, and platform-plane system link helpers
- **Shared abstractions reused**: dashboard widget composition, dashboard time-window semantics, `BadgeRenderer` for `SystemHealth`, system-safe link helpers, existing residual system detail pages, and existing source-truth owners for provider, telemetry, operations, findings, and review packs
- **New abstraction introduced? why?**: one bounded `CustomerHealth` support namespace with a fixed dimension catalog and one derived summary query is justified because the repo already has isolated source truths but no shared workspace-health derivation path
- **Why the existing abstraction was sufficient or insufficient**: existing abstractions are sufficient for rendering and navigation but insufficient for deriving one explainable cross-domain workspace summary
- **Bounded deviation / spread control**: no page-local health arithmetic, no second badge language, no persistence, and no customer-success surface. All health derivation must converge on the single `CustomerHealth` namespace.
- **Platform-safe link contract**: every attention-needed workspace row must expose exactly one platform-safe next link. If a more specific platform-plane route is not appropriate, the row falls back to the existing system tenant-detail context instead of rendering with no link. Dashboard links into residual detail pages must preserve the selected time window so the follow-up card explains the same top drivers as the dashboard.
## OperationRun UX Impact
- **Touches OperationRun start/completion/link UX?**: no
- **Central contract reused**: N/A
- **Delegated UX behaviors**: N/A
- **Surface-owned behavior kept local**: N/A
- **Queued DB-notification policy**: N/A
- **Terminal notification path**: N/A
- **Exception path**: none
## Provider Boundary & Portability Fit
- **Shared provider/platform boundary touched?**: yes
- **Provider-owned seams**: provider consent and verification outcomes on `ProviderConnection`
- **Platform-core seams**: workspace-health dimensions, overall `SystemHealth` level, dominant reason labels, dashboard widget copy, and system-safe next links
- **Neutral platform terms / contracts preserved**: customer health, workspace health, attention needed, operational stability, engagement freshness, review readiness
- **Retained provider-specific semantics and why**: Microsoft verification and consent states remain provider-owned inputs because they are existing current-release truth already modeled on provider connections
- **Bounded extraction or follow-up path**: `document-in-feature` only if one provider-specific dominant reason still needs text-only explanation instead of a platform-safe link in v1
## Constitution Check
*GATE: Must pass before implementation begins. Re-check after design changes.*
- Inventory-first / snapshots-second: PASS - the slice derives health from existing observed truths only
- Read/write separation: PASS - the slice is read-only
- Graph contract path: PASS - no new Graph calls are added
- RBAC-UX / workspace isolation / tenant isolation: PASS - system dashboard access rules remain authoritative and no tenant/admin viewer is introduced
- Shared pattern reuse / `XCUT-001`: PASS - dashboard widget family, badge semantics, and system link helpers are reused explicitly
- Proportionality / `PROP-001` and `ABSTR-001`: PASS - one bounded derived-query path is the narrowest reusable solution
- Persisted truth / `PERSIST-001`: PASS - no new persistence is introduced
- UI semantics / `UI-SEM-001`: PASS - the slice adds decision-support summaries only and does not create a new workflow hub
- Filament-native UI / `UI-FIL-001`: PASS - the operator-facing impact stays on the existing dashboard widget family
- Livewire v4 / Filament v5: PASS - the slice remains fully inside the current Filament v5 + Livewire v4 stack
- Provider registration location: PASS - no provider registration changes are introduced; Laravel 11+ provider registration stays in `bootstrap/providers.php`
- Global search rule: PASS - no resource or global-search changes are introduced
- Destructive actions: PASS - none added
- Asset strategy: PASS - no new assets are required, so deployment behavior for `filament:assets` remains unchanged
- Test governance / `TEST-GOV-001`: PASS - proof remains in focused unit + feature lanes only
## Test Governance Check
- **Test purpose / classification by changed surface**: Unit for dimension rules and summary derivation; Feature for `/system` dashboard rendering, explainability, authorization, and residual detail follow-up rendering
- **Affected validation lanes**: fast-feedback, confidence
- **Why this lane mix is the narrowest sufficient proof**: the slice is server-driven, read-only, and widget-based; browser automation would duplicate what focused unit and feature tests already prove
- **Narrowest proving command(s)**:
- `export PATH="/bin:/usr/bin:/usr/local/bin:$PATH" && cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Unit/Support/CustomerHealth/CustomerHealthDimensionCatalogTest.php tests/Unit/Support/CustomerHealth/WorkspaceHealthSummaryQueryTest.php`
- `export PATH="/bin:/usr/bin:/usr/local/bin:$PATH" && cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Feature/System/CustomerHealth/CustomerHealthDashboardWidgetsTest.php tests/Feature/System/CustomerHealth/CustomerHealthExplainabilityTest.php tests/Feature/System/CustomerHealth/CustomerHealthAuthorizationTest.php`
- **Fixture / helper / factory / seed / context cost risks**: reuse existing workspaces, tenants, provider connections, onboarding sessions, telemetry events, operation runs, findings, and review packs; avoid browser setup and avoid new heavy support fixtures
- **Expensive defaults or shared helper growth introduced?**: no
- **Heavy-family additions, promotions, or visibility changes**: none
- **Surface-class relief / special coverage rule**: standard-native-filament relief
- **Closing validation and reviewer handoff**: reviewers should confirm unknown handling, dominant reason explainability, platform-safe linking, absence of new persistence, and explicit selected-window semantics
- **Disclosure-ladder proof**: reviewers should also confirm that default-visible dashboard content stays operator-first, raw or support-grade detail remains behind linked surfaces, and the two widgets do not duplicate the same visible decision summary
- **Budget / baseline / trend follow-up**: none expected beyond ordinary feature-local upkeep
- **Review-stop questions**: did the implementation add a persisted score model, customer-facing route, or second badge taxonomy; do unknown and recent-review-pack-request cases degrade honestly?
- **Escalation path**: `reject-or-split` if the slice expands into CRM, billing, predictive scoring, or a new portfolio workbench page
- **Active feature PR close-out entry**: Guardrail
- **Test-governance outcome**: keep
## Project Structure
### Documentation (this feature)
```text
specs/245-customer-health-score/
├── checklists/
│ └── requirements.md
├── spec.md
├── plan.md
└── tasks.md
```
### Source Code (repository root)
```text
apps/platform/
├── app/
│ ├── Filament/
│ │ └── System/
│ │ ├── Pages/
│ │ │ ├── Dashboard.php
│ │ │ └── Directory/
│ │ │ ├── ViewTenant.php
│ │ │ └── ViewWorkspace.php
│ │ └── Widgets/
│ │ ├── CustomerHealthKpis.php
│ │ └── CustomerHealthTopWorkspaces.php
│ ├── Services/
│ │ └── Providers/ProviderConnectionStateProjector.php
│ └── Support/
│ ├── CustomerHealth/
│ │ ├── CustomerHealthDimensionCatalog.php
│ │ └── WorkspaceHealthSummaryQuery.php
│ ├── ProductTelemetry/ProductTelemetrySummaryQuery.php
│ └── SystemConsole/
├── resources/views/filament/system/pages/directory/
│ ├── view-tenant.blade.php
│ └── view-workspace.blade.php
├── resources/views/filament/system/widgets/customer-health-top-workspaces.blade.php
└── tests/
├── Unit/Support/CustomerHealth/
│ ├── CustomerHealthDimensionCatalogTest.php
│ └── WorkspaceHealthSummaryQueryTest.php
└── Feature/System/CustomerHealth/
├── CustomerHealthDetailDecisionTest.php
├── CustomerHealthAuthorizationTest.php
├── CustomerHealthDashboardWidgetsTest.php
└── CustomerHealthExplainabilityTest.php
```
**Structure Decision**: Single Laravel web application. The implementation adds one bounded support namespace and two dashboard widgets only.
## Complexity Tracking
No constitution violations are required. The slice adds one derived summary path only and introduces no new persistence, no new state family, and no new workflow surface.
## Rollout & Risk Controls
- Start on the existing `/system` dashboard only; do not introduce a new portfolio or customer-health page in v1.
- Keep the first-slice dimension inventory fixed at six. Any added dimension requires a spec update.
- Keep review-pack readiness narrow and operational, not programmatic or compliance-heavy.
- Use explicit copy or visual grouping to distinguish point-in-time signals from windowed signals.
- Guarantee one platform-safe next link per attention-needed workspace row by falling back to the existing system tenant-detail context when a more specific platform-plane route is not appropriate.
## Implementation Outline
- Add `App\Support\CustomerHealth\CustomerHealthDimensionCatalog` as the single source for first-slice dimension labels, order, and level precedence rules.
- Add `App\Support\CustomerHealth\WorkspaceHealthSummaryQuery` to derive per-workspace summaries from existing onboarding, provider, telemetry, operations, findings, and review-pack truth.
- Add `App\Filament\System\Widgets\CustomerHealthKpis` for aggregate health counts.
- Add `App\Filament\System\Widgets\CustomerHealthTopWorkspaces` plus a small Blade view for the attention-needed list.
- Add one read-only customer-health decision card to the existing system tenant and workspace residual detail pages using the existing summary query and the same dominant drivers as the dashboard.
- Register both widgets on the existing `App\Filament\System\Pages\Dashboard` and reuse existing system-safe link helpers only.
## Implementation Phases
1. **Foundation**: fixed dimension catalog + derived workspace summary query with core unknown-handling and review-pack-readiness rules + unit proof
2. **Dashboard summary**: aggregate KPI widget + system dashboard registration + feature proof
3. **Attention list**: compact unhealthy-workspace widget + system-safe links + explainability proof
4. **Detail follow-up**: residual system tenant/workspace detail card + preserved window context + follow-up rendering proof
5. **Safety hardening**: archived workspace plus tenant exclusions, deterministic ordering hardening, and authorization proof
## Constitution Check (Post-Design)
Re-check result: PASS. The plan stays derived-only, reuses existing system dashboard and health presentation semantics, keeps Filament v5 + Livewire v4 intact, leaves provider registration in `bootstrap/providers.php` untouched, introduces no global-search or asset changes, adds no destructive actions, and keeps proof in narrow unit + feature lanes only.

View File

@ -0,0 +1,339 @@
# Feature Specification: Customer Health Score
**Feature Branch**: `245-customer-health-score`
**Created**: 2026-04-27
**Status**: Ready for implementation
**Input**: User description: "Promote the roadmap-fit candidate Customer Health Score as a narrow, implementation-ready slice that derives an explainable workspace health summary from existing telemetry, onboarding readiness, provider connection health, operation outcomes, findings pressure, and review-pack readiness, then surfaces one attention-oriented summary on the existing system dashboard without introducing CRM, predictive scoring, billing collection, or customer-facing account-management workflows."
## Spec Candidate Check *(mandatory — SPEC-GATE-001)*
- **Problem**: TenantPilot still requires founder-style manual inspection across onboarding, provider connections, failed runs, findings, review packs, and telemetry to understand which workspaces actually need attention.
- **Today's failure**: The product exposes isolated health clues, but no explainable workspace-level summary. Operators must reconstruct risk by hopping between `/system`, tenant directory, run lists, and tenant surfaces, which delays support and masks silent customer/workspace deterioration.
- **User-visible improvement**: A platform operator can open the existing `/system` dashboard and immediately see which workspaces are healthy, which need attention, why they need attention, and which existing platform-safe surface to open next. When the operator follows that link into the existing system tenant or workspace detail, the page repeats the decision-first health explanation above the existing diagnostics.
- **Smallest enterprise-capable version**: Add one derived customer-health query path with six fixed first-slice dimensions, reuse the existing system dashboard and window selector, show aggregate health counts plus an attention-needed workspace list, and keep the entire slice read-only and non-persistent.
- **Explicit non-goals**: No CRM or customer-success suite, no billing collection or entitlement enforcement, no predictive churn model, no customer-facing health portal, no tenant/admin-plane health viewer, no new persisted score table, no background recomputation job, and no AI-generated account-management actions.
- **Permanent complexity imported**: One bounded `CustomerHealth` support namespace, one derived summary query path, one small fixed dimension catalog, two dashboard widgets, and focused unit plus feature coverage.
- **Why now**: Self-Service Tenant Onboarding & Connection Readiness, Support Diagnostic Pack, Operational Controls, Product Usage & Adoption Telemetry, and Product Knowledge are now specced or implemented. Customer Health Score is the smallest next slice that turns those foundations into one operator-facing attention signal before lifecycle communication, AI assistance, or broader portfolio workflows expand.
- **Why not local**: Local counters on the system dashboard or one-off health badges in the directory would either duplicate logic across surfaces or hide how onboarding, provider, operational, governance, review-pack, and adoption truth combine into one explainable workspace summary.
- **Approval class**: Core Enterprise
- **Red flags triggered**: New abstraction, many-signal summary. Defense: the slice stays derived-only, reuses the existing `SystemHealth` level language, fixes the first-slice dimension inventory at six signals, and limits UI impact to the existing `/system` dashboard.
- **Score**: Nutzen: 2 | Dringlichkeit: 2 | Scope: 1 | Komplexität: 1 | Produktnähe: 2 | Wiederverwendung: 2 | **Gesamt: 10/12**
- **Decision**: approve
## Spec Scope Fields *(mandatory)*
- **Scope**: platform, workspace, tenant
- **Primary Routes**:
- `/system` existing system dashboard for aggregate health counts and the attention-needed workspace list
- existing platform-safe deep links from those widgets into the system tenant directory and system operations surfaces
- existing `/system/directory/tenants/{tenant}` and `/system/directory/workspaces/{workspace}` residual detail pages as read-only health follow-up surfaces
- **Data Ownership**: No new persisted customer-health truth is introduced. The summary is derived from existing tenant-owned product truths such as `product_usage_events`, `provider_connections`, `operation_runs`, `findings`, `review_packs`, and onboarding-readiness state already owned by existing onboarding/session/provider records.
- **RBAC**: Reads remain platform-plane only through the existing `/system` dashboard access gate. No tenant/admin-plane or customer-facing health surface is introduced in this slice.
For canonical-view specs, the spec MUST define:
- **Default filter behavior when tenant-context is active**: N/A - the first slice is a platform-plane dashboard addition under `/system`, not a tenant-context admin view.
- **Explicit entitlement checks preventing cross-tenant leakage**: The slice exposes derived counts and system-safe drilldown links only to existing platform users who can already access the system dashboard. It does not expose raw tenant-owned health rows or create any cross-plane deep link into `/admin` tenant surfaces.
## Cross-Cutting / Shared Pattern Reuse *(mandatory when the feature touches notifications, status messaging, action links, header actions, dashboard signals/cards, alerts, navigation entry points, evidence/report viewers, or any other existing shared operator interaction family; otherwise write `N/A - no shared interaction family touched`)*
- **Cross-cutting feature?**: yes
- **Interaction class(es)**: dashboard signals/cards, read-only attention list, system-safe deep links, status badges
- **Systems touched**: `App\Filament\System\Pages\Dashboard`, existing system dashboard widget family, `App\Support\ProductTelemetry\ProductTelemetrySummaryQuery`, `App\Services\Providers\ProviderConnectionStateProjector`, `App\Support\SystemConsole\StuckRunClassifier`, existing `Finding` and `ReviewPack` truth queries, and existing system link helpers
- **Existing pattern(s) to extend**: the `/system` dashboard widget composition, the existing dashboard time-window selector, `ControlTowerHealthIndicator`, and `ControlTowerTopOffenders`
- **Shared contract / presenter / builder / renderer to reuse**: `StatsOverviewWidget`, existing custom system widgets, `BadgeRenderer` with `BadgeDomain::SystemHealth`, `SystemConsoleWindow`, `SystemOperationRunLinks`, and existing system directory links
- **Why the existing shared path is sufficient or insufficient**: Existing shared paths already solve dashboard placement, read-only system-plane rendering, time-window selection, and system-safe navigation. They are insufficient because none of them currently derives one explainable workspace-health summary from multiple existing truths.
- **Allowed deviation and why**: One bounded `CustomerHealth` support namespace is allowed to centralize health derivation. Page-local health arithmetic, widget-local badge vocabularies, or duplicated query seams are not allowed.
- **Consistency impact**: Overall health levels must reuse the existing `SystemHealth` vocabulary (`ok`, `warn`, `critical`, `unknown`), and the first-slice dimension labels plus time-basis copy must remain consistent between summary widgets and any linked system-safe detail flow.
- **Review focus**: Reviewers must verify that the slice stays derived-only, does not add a hidden score table, does not invent a second badge taxonomy, does not create platform-to-admin deep links, and does not broaden into customer-success or billing workflow scope.
## OperationRun UX Impact *(mandatory when the feature creates, queues, deduplicates, resumes, blocks, completes, or deep-links to an `OperationRun`; otherwise write `N/A - no OperationRun start or link semantics touched`)*
- **Touches OperationRun start/completion/link UX?**: no
- **Shared OperationRun UX contract/layer reused**: N/A - the slice reads existing run truth only and may link to existing system run lists.
- **Delegated start/completion UX behaviors**: N/A
- **Local surface-owned behavior that remains**: N/A
- **Queued DB-notification policy**: N/A
- **Terminal notification path**: N/A
- **Exception required?**: none
## Provider Boundary / Platform Core Check *(mandatory when the feature changes shared provider/platform seams, identity scope, governed-subject taxonomy, compare strategy selection, provider connection descriptors, or operator vocabulary that may leak provider-specific semantics into platform-core truth; otherwise write `N/A - no shared provider/platform boundary touched`)*
- **Shared provider/platform boundary touched?**: yes
- **Boundary classification**: mixed
- **Seams affected**: provider verification and consent statuses as one health-dimension input, review-pack status labels, telemetry family activity, and system-safe health copy
- **Neutral platform terms preserved or introduced**: customer health, workspace health, health dimension, attention needed, engagement freshness, review readiness, operational stability
- **Provider-specific semantics retained and why**: Microsoft-specific provider consent and verification outcomes remain inside the provider-health dimension because they are existing current-release truth owned by provider-connection workflows.
- **Why this does not deepen provider coupling accidentally**: The top-level summary stays platform-owned and explainable. Provider-specific codes and statuses are consumed only as one input dimension and are not promoted into a new platform taxonomy.
- **Follow-up path**: Customer Lifecycle Communication and later portfolio workflows may reuse the summary, but they remain separate specs.
## UI / Surface Guardrail Impact *(mandatory when operator-facing surfaces are changed; otherwise write `N/A`)*
| Surface / Change | Operator-facing surface change? | Native vs Custom | Shared-Family Relevance | State Layers Touched | Exception Needed? | Low-Impact / `N/A` Note |
|---|---|---|---|---|---|---|
| System dashboard customer-health KPI widget | yes | Native Filament + shared stats widget | dashboard signals/cards | page, widget, window query | no | Read-only KPI addition on existing `/system` dashboard |
| System dashboard attention-needed workspace widget | yes | Native system widget family with custom Blade view | dashboard signals/cards, read-only attention list, navigation links | page, widget, detail-link state | no | Compact list of unhealthy workspaces only; no new page or workbench |
| System tenant and workspace residual detail pages customer-health decision card | yes | Existing custom system detail pages | linked follow-up context, decision-first explanation | page, window query | no | Read-only summary card above existing diagnostics; no new page or mutation |
## Decision-First Surface Role *(mandatory when operator-facing surfaces are changed)*
| Surface | Decision Role | Human-in-the-loop Moment | Immediately Visible for First Decision | On-Demand Detail / Evidence | Why This Is Primary or Why Not | Workflow Alignment | Attention-load Reduction |
|---|---|---|---|---|---|---|---|
| System dashboard customer-health KPI widget | Secondary Context Surface | Decide whether overall platform attention is rising and whether to inspect unhealthy workspaces now | Count of healthy, warning, critical, and unknown workspaces for the selected window | Existing system tenant directory, operations list, and source surfaces remain evidence | Secondary because it frames attention, not the underlying remediation workflow | Fits the founder or platform-operator control-tower loop | Replaces manual reconstruction across onboarding, telemetry, runs, and findings surfaces |
| System dashboard attention-needed workspace widget | Secondary Context Surface | Decide which workspace to inspect next and which source truth is driving the problem | Workspace name, overall level, dominant dimensions, and one platform-safe next link | Existing system-safe detail surfaces and linked source contexts | Secondary because the actual action still happens on existing system detail and run surfaces | Keeps the dashboard as a triage layer, not a second operations workbench | Surfaces the next workspace to inspect without requiring freeform database or log inspection |
| System tenant and workspace residual detail pages customer-health decision card | Primary Decision Context | Decide why this workspace is `critical`, `warn`, or `unknown` before reading lower-level diagnostics | Overall level, repeated top drivers, operator impact, and recommended next action | Existing connectivity, permissions, tenant, and recent-run sections remain the lower-level evidence | Primary because the card turns the residual detail page into an explain-first follow-up instead of a diagnostic puzzle | Keeps `/system` drilldowns decision-first while preserving the existing read-mostly detail shape | Removes the need to infer the health reason from several independent sections |
## UI/UX Surface Classification *(mandatory when operator-facing surfaces are changed)*
| Surface | Action Surface Class | Surface Type | Likely Next Operator Action | Primary Inspect/Open Model | Row Click | Secondary Actions Placement | Destructive Actions Placement | Canonical Collection Route | Canonical Detail Route | Scope Signals | Canonical Noun | Critical Truth Visible by Default | Exception Type / Justification |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| System dashboard customer-health KPI widget | Dashboard / Overview / KPI widget | Read-only operational summary | Decide whether there is platform-wide attention pressure | In-page stat cards | forbidden | none | none | `/system` | `/system` | Existing dashboard time window and health-level counts | Customer health / Workspace health | Current health-level distribution for visible workspaces | none |
| System dashboard attention-needed workspace widget | Dashboard / Overview / compact list widget | Read-only attention registry | Open the most relevant existing system-safe detail surface for one unhealthy workspace | Named link per workspace row | forbidden | One explicit platform-safe next link per row | none | `/system` | existing linked system detail surfaces only | Workspace label, dominant dimensions, and selected time window | Attention-needed workspaces / Workspace | Which workspace needs review next and why | Compact dashboard widget justified because the list is triage-only, not a new registry page |
## Operator Surface Contract *(mandatory when operator-facing surfaces are changed)*
| Surface | Primary Persona | Decision / Operator Action Supported | Surface Type | Primary Operator Question | Default-visible Information | Diagnostics-only Information | Status Dimensions Used | Mutation Scope | Primary Actions | Dangerous Actions |
|---|---|---|---|---|---|---|---|---|---|---|
| System dashboard customer-health KPI widget | Platform operator | Decide whether customer or workspace health is deteriorating overall | Dashboard summary | How many workspaces are healthy, unknown, warning, or critical right now? | Level counts, selected time window, and clear empty or unknown handling | Raw contributing rows, provider-specific details, and per-tenant evidence stay out of the widget | overall health level only | none | existing dashboard time-window selection only | none |
| System dashboard attention-needed workspace widget | Platform operator | Decide which workspace to inspect next and what kind of issue is driving it | Compact attention list | Which workspace needs attention first, and what is the dominant reason? | Workspace label, overall level, top one or two non-ok dimensions, and one system-safe next link | Full source record sets, provider codes, detailed finding counts, and review-pack internals remain in linked surfaces | overall level plus dominant health dimensions | none | open linked system-safe detail surface | none |
| System tenant and workspace residual detail pages customer-health decision card | Platform operator | Decide what to review first on the current detail page | Read-only follow-up summary | Why is this workspace unhealthy or unknown, and what should I inspect next? | Overall health, repeated top drivers, operator impact, recommended next action, and preserved selected-window context for windowed dimensions | Lower-level connectivity, permission, tenant, and recent-run evidence remains in the existing sections below | overall level plus dominant health dimensions | none | open existing linked follow-up surfaces only when already present on the page | none |
## UI Action Matrix *(mandatory when Filament is changed)*
| Surface | Location | Header Actions | Inspect Affordance (List/Table) | Row Actions (max 2 visible) | Bulk Actions (grouped) | Empty-State CTA(s) | View Header Actions | Create/Edit Save+Cancel | Audit log? | Notes / Exemptions |
|---|---|---|---|---|---|---|---|---|---|---|
| System dashboard page | `App\Filament\System\Pages\Dashboard` | Existing `Time window` header action only; no new header actions | n/a | n/a | none | n/a | n/a | n/a | no | Action Surface Contract remains satisfied because the feature adds read-only widgets only and does not alter the page-level mutation model |
| Attention-needed workspace widget | `App\Filament\System\Widgets\CustomerHealthTopWorkspaces` | none | One named platform-safe next link per row; row click remains forbidden | Max one visible next link, chosen as `Review health details` or `Open runs` based on the dominant reason | none | One explanatory empty state with no CTA when no workspace needs attention | n/a | n/a | no | Every row must still expose one platform-safe next link. If no more specific route fits, the row falls back to the existing system tenant-detail context rather than inventing a new surface or showing no link |
**List-surface standard reference:** The attention-needed workspace widget is a compact list surface and MUST be reviewed against `/Users/ahmeddarrazi/Documents/projects/wt-plattform/docs/product/standards/list-surface-review-checklist.md` before implementation sign-off. Accepted v1 exceptions are limited to compact dashboard-widget constraints: no persistence trio, no bulk actions, no row click, and no empty-state CTA because this surface is triage-only rather than a standalone registry page.
## Proportionality Review *(mandatory when structural complexity is introduced)*
- **New source of truth?**: no
- **New persisted entity/table/artifact?**: no
- **New abstraction?**: yes
- **New enum/state/reason family?**: no - the slice reuses existing `SystemHealth` levels
- **New cross-domain UI framework/taxonomy?**: no
- **Current operator problem**: the platform has no single explainable workspace-health summary even though the underlying truth already exists in onboarding, provider, operations, findings, review packs, and telemetry.
- **Existing structure is insufficient because**: the existing structures each explain one domain only. None can honestly answer which workspace is unhealthy overall without duplicating cross-domain query logic or forcing manual reconstruction.
- **Narrowest correct implementation**: add one bounded derived-query path and one small fixed dimension catalog, then surface it on the existing system dashboard only.
- **Ownership cost**: one support namespace, two dashboard widgets, fixed dimension rules, and focused unit plus feature coverage.
- **Alternative intentionally rejected**: a persisted score table, a customer-success page, a background recomputation pipeline, or an opaque weighted scoring engine.
- **Release truth**: current-release truth
### Compatibility posture
This feature assumes a pre-production environment.
Backward compatibility, legacy aliases, migration shims, historical fixtures, and compatibility-specific tests are out of scope unless explicitly required by this spec.
Canonical replacement is preferred over preservation.
## Testing / Lane / Runtime Impact *(mandatory for runtime behavior changes)*
- **Test purpose / classification**: Unit, Feature
- **Validation lane(s)**: fast-feedback, confidence
- **Why this classification and these lanes are sufficient**: Unit tests can prove health-level derivation, dimension precedence, unknown handling, and signal inclusion rules. Feature tests can prove dashboard rendering, platform-plane authorization, and system-safe link behavior without browser automation.
- **New or expanded test families**: One focused `CustomerHealth` unit family plus a small set of `/system` feature tests for summary widgets, explainability, and authorization.
- **Fixture / helper cost impact**: Moderate. Reuse existing workspaces, tenants, provider connections, onboarding sessions, product-usage events, operation runs, findings, and review packs. Avoid new browser helpers, seeded dashboards, or heavy system defaults.
- **Heavy-family visibility / justification**: none
- **Special surface test profile**: standard-native-filament
- **Standard-native relief or required special coverage**: standard native Filament feature coverage is sufficient because the slice adds read-only widgets only.
- **Reviewer handoff**: Reviewers must confirm that the health summary is derived-only, that `unknown` and stale data are not silently treated as healthy, that system-safe links remain on the platform plane, that no new persistence appears, and that the selected window affects only the intended windowed dimensions.
- **Budget / baseline / trend impact**: Low-to-moderate increase in narrow unit plus feature coverage only.
- **Escalation needed**: none
- **Active feature PR close-out entry**: Guardrail
- **Test-governance outcome**: keep
- **Planned validation commands**:
- `export PATH="/bin:/usr/bin:/usr/local/bin:$PATH" && cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Unit/Support/CustomerHealth/CustomerHealthDimensionCatalogTest.php tests/Unit/Support/CustomerHealth/WorkspaceHealthSummaryQueryTest.php`
- `export PATH="/bin:/usr/bin:/usr/local/bin:$PATH" && cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Feature/System/CustomerHealth/CustomerHealthDashboardWidgetsTest.php tests/Feature/System/CustomerHealth/CustomerHealthExplainabilityTest.php tests/Feature/System/CustomerHealth/CustomerHealthAuthorizationTest.php`
## Functional Requirements
- **FR-001**: The system MUST derive one workspace-health summary from exactly six first-slice dimensions: onboarding readiness, provider connection health, operational stability, governance pressure, review-pack readiness, and engagement freshness.
- **FR-002**: The system MUST compute the overall workspace health level from existing `SystemHealth` semantics with explicit precedence: `critical` outranks `warn`, `warn` outranks `unknown`, and `unknown` outranks `ok`.
- **FR-003**: The system MUST keep the first slice derived-only. No persisted score table, asynchronous recomputation store, or secondary health ledger may be introduced.
- **FR-004**: The existing `/system` dashboard MUST show aggregate health counts and an attention-needed workspace list using the existing dashboard window selector for windowed dimensions.
- **FR-005**: The system MUST keep platform-safe navigation boundaries. Health widgets may link only to existing platform-plane system surfaces, never directly to tenant-admin `/admin` routes.
- **FR-006**: The system MUST make stale or missing source truth explicit. Missing or stale inputs must not silently produce `ok`.
- **FR-007**: Review-pack readiness in the first slice MUST stay narrow: it may reflect recent review-pack requests and the latest relevant pack status, but it must not become a quarterly review-obligation engine.
- **FR-008**: The slice MUST not introduce any new customer-facing communication, entitlement, billing, or AI workflow.
## Non-Functional Requirements
- **NFR-001**: The summary query must stay bounded and reusable from the existing system dashboard without new background jobs or remote calls.
- **NFR-002**: Widget copy must remain calm, explainable, and dashboard-first rather than CRM-like, sales-like, or predictive.
- **NFR-003**: Health-level rendering must reuse existing badge or status semantics instead of inventing a second color or severity language.
## UX Requirements
- **UX-001**: The dashboard must remain triage-first. Summary counts and dominant reasons are visible by default; raw counts and low-level diagnostics stay behind existing linked surfaces.
- **UX-002**: The slice must not become a new workbench page. `/system` remains the only first-slice entry point, and any health follow-up must stay inside existing residual detail pages rather than creating a new health detail page.
- **UX-003**: The widget and the linked residual detail decision card must distinguish point-in-time dimensions from windowed dimensions in their copy or presentation so operators do not assume one false time basis.
## RBAC / Security Requirements
- **SEC-001**: Only existing platform users who can already access `/system` may see customer-health widgets.
- **SEC-002**: No tenant/admin-plane, customer-facing, or raw-row viewer may be introduced in this slice.
- **SEC-003**: System-safe deep links must remain guarded by existing platform-plane route policies and must not reveal tenant-admin paths or scoped data to the wrong plane.
## Auditability / Observability Requirements
- **OBS-001**: The slice must reuse existing product truths and must not duplicate audit entries or OperationRun records for derived reads.
- **OBS-002**: The source dimension set and level precedence must be testable so future changes cannot silently redefine health semantics.
## Data / Truth-Source Requirements
- **DATA-001**: Onboarding readiness must reuse existing onboarding-session and readiness truth rather than a copied health field.
- **DATA-002**: Provider connection health must reuse provider-owned verification and consent truth rather than a new platform-owned provider score.
- **DATA-003**: Operational stability must reuse existing failed and stuck `OperationRun` truth within the selected `SystemConsoleWindow`.
- **DATA-004**: Governance pressure must reuse existing findings and risk-acceptance truth.
- **DATA-005**: Review-pack readiness must reuse existing review-pack truth plus recent request context where needed.
- **DATA-006**: Engagement freshness must reuse existing `product_usage_events` truth rather than page views or ad-hoc counters.
- **DATA-007**: Archived workspaces must be excluded from active portfolio counts, and archived tenants must not contribute source truth into active workspace-health derivation.
## Review-Pack Readiness Rule
`Recent` means the currently selected dashboard window. Request context is derived from existing review-pack request telemetry when available, falling back to a `ReviewPack` created for the same workspace inside that same window.
| Condition | Review-pack readiness level | Notes |
|---|---|---|
| No request context and no relevant pack activity in the selected window | `unknown` | The first slice does not infer quarterly review obligations from silence |
| Request context exists in the selected window and no relevant pack is usable yet | `warn` | Covers queued, running, or not-yet-materialized pack generation |
| Latest relevant pack in the selected window is ready and not expired | `ok` | A usable recent pack exists |
| Latest relevant pack in the selected window is failed or expired | `critical` | Recent review-pack work ended unusably and needs attention |
## Attention Ordering Rule
The attention-needed workspace list is deterministic in v1:
1. Higher overall health severity sorts first: `critical` before `warn` before `unknown`
2. Within the same overall level, workspaces with more non-`ok` dimensions sort first
3. Remaining ties sort by workspace name ascending, then workspace id ascending
## User Scenarios & Testing *(mandatory)*
### User Story 1 - See Portfolio Health At A Glance (Priority: P1)
As a platform operator, I need the existing `/system` dashboard to summarize customer or workspace health so I can tell quickly whether attention pressure is rising.
**Why this priority**: Without an aggregate signal, operators still need to inspect several unrelated surfaces before they even know whether a health problem exists.
**Independent Test**: Seed workspaces with different combinations of healthy, warning, critical, and unknown source truth and verify that `/system` renders the correct health-level counts, explicit unknown handling, and a visible cue for windowed versus point-in-time dimensions.
**Acceptance Scenarios**:
1. **Given** multiple visible workspaces with mixed source truth, **When** an authorized platform user opens `/system`, **Then** the dashboard shows aggregate counts for `ok`, `warn`, `critical`, and `unknown` workspaces using the first-slice health rules.
2. **Given** a workspace has only stale or missing source truth for one or more dimensions, **When** the dashboard renders, **Then** that workspace is not shown as healthy by default.
3. **Given** the summary mixes operational and point-in-time signals, **When** the dashboard renders, **Then** the widget shows a visible cue that operations and engagement honor the selected window while onboarding, provider, governance, and review-readiness remain state-based.
---
### User Story 2 - Review Attention-Needed Workspaces With Explainable Reasons (Priority: P1)
As a platform operator, I need a compact list of the workspaces that need attention most so I know where to inspect next and why.
**Why this priority**: Aggregate counts alone do not reduce support load unless operators can immediately identify which workspace needs review and what category of issue is driving that state.
**Independent Test**: Seed multiple unhealthy workspaces and confirm the dashboard lists them with overall health level, dominant dimensions, and one platform-safe next link per row.
**Acceptance Scenarios**:
1. **Given** multiple warning or critical workspaces, **When** the dashboard renders, **Then** the attention-needed widget lists the worst workspaces first with overall level and dominant health dimensions.
2. **Given** a workspace row offers a next action, **When** the user activates that action, **Then** the link stays on an existing platform-plane system surface and does not deep-link into `/admin` tenant routes.
3. **Given** the operator follows a health-detail link from the dashboard, **When** the linked system tenant or workspace detail page renders, **Then** a decision-first customer-health card appears above the existing diagnostics and repeats the same dominant health drivers together with overall level, impact, and recommended next action.
---
### User Story 3 - Keep Health Honest And Narrow (Priority: P2)
As the product owner, I need the health summary to stay explainable and bounded so it does not become an opaque score, a hidden persistence layer, or a substitute for existing source truth.
**Why this priority**: A misleading or overbuilt score would add maintenance and trust debt immediately.
**Independent Test**: Inspect the derived summary rules and verify that unknown or mixed-time-basis inputs remain explicit, no new persistence appears, and no customer-facing workflow is introduced.
**Acceptance Scenarios**:
1. **Given** the first-slice dimension rules are evaluated, **When** one dimension is `critical` and another is `unknown`, **Then** the overall workspace level resolves deterministically and the dominant reasons remain explainable.
2. **Given** recent review-pack generation was requested but no usable pack is yet available, **When** the review-readiness dimension is evaluated, **Then** the workspace is not falsely shown as healthy.
3. **Given** a user without existing `/system` access attempts to read customer health, **When** they hit the surface, **Then** access stays denied through the existing platform-plane gate.
### Edge Cases
- Archived workspaces or tenants must not inflate active health counts.
- A workspace can have healthy current provider state but no recent engagement telemetry; the slice must make the time basis explicit instead of collapsing that into a misleading single timestamp.
- A recent review-pack request can exist before a ready pack exists; that gap must not render as healthy.
- A workspace with no onboarding-linked tenant yet must remain `unknown` or explicitly non-healthy rather than silently `ok`.
- Mixed workspace truth across several tenants must still produce one explainable workspace-level result without exposing raw tenant-owned rows on the dashboard.
## Acceptance Criteria
- The first slice derives workspace health from six fixed dimensions only and keeps all health truth derived from existing records.
- The existing `/system` dashboard exposes both aggregate health counts and an attention-needed workspace list.
- Operators can see dominant reasons for unhealthy workspaces without opening a second system page first.
- Unknown or stale source truth is explicit and never silently treated as healthy.
- The slice introduces no new persisted health entity, no customer-facing view, and no new platform-to-admin deep link.
## Out Of Scope
- Customer-facing health portals
- Billing or entitlement-aware health dimensions
- Automated customer lifecycle messaging
- Predictive scoring, churn scoring, or AI-generated recommendations
- A dedicated portfolio-health page outside the existing `/system` dashboard
- A new persisted workspace-health model or scheduled recomputation job
## Success Criteria
- A platform operator can identify whether any workspace needs attention, and which workspace to inspect first, within one `/system` dashboard visit.
- The first slice remains explainable enough that each visible non-healthy state can be tied back to one or two named dimensions.
- The package stays implementation-ready without introducing unresolved product decisions around billing, CRM, AI, or customer-facing UX.
## Assumptions
- Product Usage & Adoption Telemetry is available or implemented before this slice is delivered.
- Existing system dashboard access rules remain the correct audience gate for the first slice.
- Existing provider-connection, finding, review-pack, and run surfaces remain the source-of-truth owners for detailed inspection.
## Risks
- Too many first-slice dimensions would make the dashboard noisy; the dimension inventory is fixed at six for v1.
- Mixed point-in-time and windowed signals can confuse operators if the UI does not label them carefully.
- Review-pack readiness could drift into a broader compliance-workflow interpretation if it is not kept narrow.
## Open Questions
- None blocking the first slice. The v1 contract guarantees one platform-safe next link per workspace row by falling back to the existing system tenant-detail context when a more specific platform-plane route is not appropriate.
## Requirements *(mandatory)*
**Constitution alignment (required):** The slice adds no Microsoft Graph calls, no mutation flow, and no new queued or scheduled work. It derives read-only health summaries from existing onboarding, provider, telemetry, findings, review-pack, and `OperationRun` truth only.
**Constitution alignment (PROP-001 / ABSTR-001 / PERSIST-001 / STATE-001 / BLOAT-001):** The feature introduces no new persistence and reuses existing health-level semantics. The only new structure is one bounded derived-query path plus a fixed dimension catalog because current-release operator workflow now needs a single explainable workspace-health summary.
**Constitution alignment (XCUT-001):** This slice explicitly extends the shared system dashboard widget family, system-safe links, and shared `SystemHealth` presentation instead of inventing a second health dashboard language.
**Constitution alignment (PROV-001):** Provider-specific verification and consent semantics remain provider-owned inputs only; the top-level customer-health summary stays platform-owned and neutral.
**Constitution alignment (TEST-GOV-001):** Proof stays in Unit + Feature lanes only. No heavy-governance or browser family is justified.
**Constitution alignment (OPS-UX):** Existing `OperationRun` start, completion, notification, and link semantics remain unchanged. The slice reads existing run truth and may link to existing system operations surfaces only.
**Constitution alignment (RBAC-UX):** Reads remain platform-plane only through existing `/system` access checks. No tenant/admin or customer-facing health viewer is introduced.
**Constitution alignment (BADGE-001):** The feature reuses existing `BadgeDomain::SystemHealth` rendering and does not add a new badge taxonomy.
**Constitution alignment (UI-FIL-001):** The only operator-facing changes are native Filament system widgets on the existing dashboard. No published views, panel provider changes, or custom asset pipeline changes are introduced.
**Constitution alignment (UI-NAMING-001):** Widget labels and dominant health reasons must remain operator-first and platform-neutral, such as `Customer health`, `Attention-needed workspaces`, `Provider health`, `Operational stability`, and `Engagement freshness`.
**Filament v5 / Livewire v4 compliance:** The slice remains fully inside the current Filament v5 + Livewire v4 stack.
**Provider registration location:** No provider registration changes are introduced; Laravel 11+ provider registration remains in `bootstrap/providers.php`.
**Global search rule:** No new resource or global-search participation is introduced.
**Destructive actions:** No destructive actions are added in this slice.
**Asset strategy:** No new global or on-demand assets are added. Deployment behavior for `filament:assets` remains unchanged.

View File

@ -0,0 +1,151 @@
---
description: "Task list for Customer Health Score"
---
# Tasks: Customer Health Score
**Input**: Design documents from `/Users/ahmeddarrazi/Documents/projects/wt-plattform/specs/245-customer-health-score/`
**Prerequisites**: `/Users/ahmeddarrazi/Documents/projects/wt-plattform/specs/245-customer-health-score/plan.md` (required), `/Users/ahmeddarrazi/Documents/projects/wt-plattform/specs/245-customer-health-score/spec.md` (required), `/Users/ahmeddarrazi/Documents/projects/wt-plattform/specs/245-customer-health-score/checklists/requirements.md` (required)
**Tests (TEST-GOV-001)**: REQUIRED (Pest) for all runtime behavior changes in this slice. Keep proof in Unit + Feature lanes only.
**Operations**: This slice must not change `OperationRun` start, completion, notification, or link UX.
**RBAC**: Existing `/system` dashboard access remains authoritative. No tenant/admin-plane or customer-facing health viewer is introduced.
**Organization**: Tasks are grouped by user story so aggregate health counts, the attention-needed workspace list, and edge-case hardening remain independently deliverable. Core unknown-handling lives in the foundational query path.
## Phase 1: Setup (Shared Infrastructure)
**Purpose**: Prepare the bounded support namespace and narrow test surfaces for the first slice.
- [x] T001 Create the feature-local support namespace and test directories under `apps/platform/app/Support/CustomerHealth/`, `apps/platform/tests/Unit/Support/CustomerHealth/`, and `apps/platform/tests/Feature/System/CustomerHealth/`
---
## Phase 2: Foundational (Blocking Prerequisites)
**Purpose**: Add the single shared dimension catalog and derived summary query before any dashboard UI adoption.
**Checkpoint**: One bounded, derived-only customer-health path exists before the dashboard starts rendering it, including the base unknown-handling and review-pack-readiness rules.
- [x] T002 Create the fixed first-slice dimension catalog in `apps/platform/app/Support/CustomerHealth/CustomerHealthDimensionCatalog.php`, reusing existing `SystemHealth` level semantics and locking the first slice to onboarding readiness, provider connection health, operational stability, governance pressure, review-pack readiness, and engagement freshness
- [x] T003 Create the derived workspace summary query in `apps/platform/app/Support/CustomerHealth/WorkspaceHealthSummaryQuery.php` that reads existing onboarding, provider connection, telemetry, `OperationRun`, findings, and review-pack truth without introducing a persisted score model, and bakes in the base unknown-handling plus selected-window review-pack-readiness rules
- [x] T004 [P] Add unit coverage for dimension labels, level precedence, unknown handling, the selected-window review-pack-readiness rule table, and windowed versus point-in-time signal rules in `apps/platform/tests/Unit/Support/CustomerHealth/CustomerHealthDimensionCatalogTest.php` and `apps/platform/tests/Unit/Support/CustomerHealth/WorkspaceHealthSummaryQueryTest.php`
- [x] T005 Run the foundational unit suite with `export PATH="/bin:/usr/bin:/usr/local/bin:$PATH" && cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Unit/Support/CustomerHealth/CustomerHealthDimensionCatalogTest.php tests/Unit/Support/CustomerHealth/WorkspaceHealthSummaryQueryTest.php`
---
## Phase 3: User Story 1 - See Portfolio Health At A Glance (Priority: P1) 🎯 MVP
**Goal**: Show aggregate workspace-health counts on the existing `/system` dashboard.
**Independent Test**: Seed mixed workspace truth and verify the dashboard renders aggregate `ok`, `warn`, `critical`, and `unknown` counts with explicit unknown handling.
### Tests for User Story 1
- [x] T006 [P] [US1] Add dashboard feature coverage for aggregate health counts, unknown handling, selected-window behavior, and a visible time-basis cue in `apps/platform/tests/Feature/System/CustomerHealth/CustomerHealthDashboardWidgetsTest.php`
### Implementation for User Story 1
- [x] T007 [US1] Create the summary stats widget in `apps/platform/app/Filament/System/Widgets/CustomerHealthKpis.php` using the shared `StatsOverviewWidget` pattern and `WorkspaceHealthSummaryQuery`, including visible copy that distinguishes selected-window dimensions from point-in-time dimensions
- [x] T008 [US1] Register the new summary widget on `apps/platform/app/Filament/System/Pages/Dashboard.php` without changing the existing system dashboard access gate or header actions
- [x] T009 [US1] Run the first-slice dashboard summary proof with `export PATH="/bin:/usr/bin:/usr/local/bin:$PATH" && cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Feature/System/CustomerHealth/CustomerHealthDashboardWidgetsTest.php`
---
## Phase 4: User Story 2 - Review Attention-Needed Workspaces With Explainable Reasons (Priority: P1)
**Goal**: List the worst workspaces first with dominant health dimensions and one platform-safe next link.
**Independent Test**: Seed several unhealthy workspaces and verify the dashboard shows them in priority order with dominant reasons and platform-safe links only.
### Tests for User Story 2
- [x] T010 [P] [US2] Add feature coverage for deterministic workspace ordering, dominant-dimension rendering, operator-first default disclosure, absence of raw/support detail on the default dashboard surface, absence of duplicate visible decision summaries across the two widgets, and exactly one platform-safe next link per row with the tenant-detail fallback path in `apps/platform/tests/Feature/System/CustomerHealth/CustomerHealthExplainabilityTest.php`
### Implementation for User Story 2
- [x] T011 [US2] Create the compact attention widget in `apps/platform/app/Filament/System/Widgets/CustomerHealthTopWorkspaces.php`
- [x] T012 [US2] Add the companion Blade view in `apps/platform/resources/views/filament/system/widgets/customer-health-top-workspaces.blade.php`, keeping the surface read-only and triage-first
- [x] T013 [US2] Use existing platform-plane link helpers inside `apps/platform/app/Filament/System/Widgets/CustomerHealthTopWorkspaces.php` so each row exposes exactly one next link on system directory or system operations surfaces, with fallback to system tenant detail when no more specific platform-plane route is appropriate
- [x] T014 [US2] Register the attention-needed widget on `apps/platform/app/Filament/System/Pages/Dashboard.php` without turning `/system` into a second workbench page
- [x] T015 [US2] Run the explainability and link proof with `export PATH="/bin:/usr/bin:/usr/local/bin:$PATH" && cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Feature/System/CustomerHealth/CustomerHealthExplainabilityTest.php`
---
## Phase 5: User Story 3 - Keep Health Honest And Narrow (Priority: P2)
**Goal**: Harden archived-workspace and archived-tenant handling, authorization, and dominant-reason edge cases after the foundational unknown-handling rules are already in place.
**Independent Test**: Verify that archived workspaces stay out of active attention counts, archived tenants do not drive active workspace health, review-pack edge cases continue to follow the selected-window rule, and unauthorized users cannot read the widgets.
### Tests for User Story 3
- [x] T016 [P] [US3] Add feature coverage for `/system` authorization boundaries in `apps/platform/tests/Feature/System/CustomerHealth/CustomerHealthAuthorizationTest.php`
- [x] T017 [P] [US3] Extend `apps/platform/tests/Unit/Support/CustomerHealth/WorkspaceHealthSummaryQueryTest.php` with archived-workspace, archived-tenant, dominant-reason ordering, and recent-review-pack-request edge cases that harden the existing foundational rules
### Implementation for User Story 3
- [x] T018 [US3] Harden `apps/platform/app/Support/CustomerHealth/WorkspaceHealthSummaryQuery.php` for archived-workspace and archived-tenant exclusions, dominant-reason ordering, and review-pack edge cases without moving the core unknown-handling rules out of the foundation
- [x] T019 [US3] Keep overall level rendering on existing `BadgeDomain::SystemHealth` semantics inside `apps/platform/app/Filament/System/Widgets/CustomerHealthKpis.php` and `apps/platform/app/Filament/System/Widgets/CustomerHealthTopWorkspaces.php` rather than introducing a new score language
- [x] T020 [US3] Run the narrow safety and authorization proof with `export PATH="/bin:/usr/bin:/usr/local/bin:$PATH" && cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Unit/Support/CustomerHealth/WorkspaceHealthSummaryQueryTest.php tests/Feature/System/CustomerHealth/CustomerHealthAuthorizationTest.php`
---
## Phase 6: Polish & Cross-Cutting Concerns
**Purpose**: Lock down vocabulary, formatting, and the minimal validation suite before implementation close-out.
- [x] T021 [P] Confirm that dashboard labels, dominant reason copy, health levels, the visible time-basis cue, and the no-duplicate-visible-summary rule stay aligned across `apps/platform/app/Support/CustomerHealth/CustomerHealthDimensionCatalog.php`, the dashboard widgets, and any linked platform-safe surfaces
- [x] T022 Run formatting on touched platform files with `export PATH="/bin:/usr/bin:/usr/local/bin:$PATH" && cd apps/platform && ./vendor/bin/sail bin pint --dirty --format agent`
- [x] T023 Run the full narrow validation suite with `export PATH="/bin:/usr/bin:/usr/local/bin:$PATH" && cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Unit/Support/CustomerHealth tests/Feature/System/CustomerHealth/CustomerHealthDashboardWidgetsTest.php tests/Feature/System/CustomerHealth/CustomerHealthExplainabilityTest.php tests/Feature/System/CustomerHealth/CustomerHealthAuthorizationTest.php`
- [x] T024 Review `apps/platform/app/Filament/System/Widgets/CustomerHealthTopWorkspaces.php` and `apps/platform/resources/views/filament/system/widgets/customer-health-top-workspaces.blade.php` against `/Users/ahmeddarrazi/Documents/projects/wt-plattform/docs/product/standards/list-surface-review-checklist.md`, recording the accepted compact-widget exceptions before sign-off
Accepted compact-widget exceptions for sign-off: no persistence trio, no bulk actions, no row click, and no empty-state CTA because this is a read-only dashboard triage widget rather than a standalone Filament table surface.
---
## Phase 7: Detail Follow-Up Decision Context
**Purpose**: Keep the dashboard-to-detail drilldown explainable by repeating the health decision above existing residual diagnostics.
- [x] T025 [US2] Preserve the selected dashboard time window on system health-detail drilldown links in `apps/platform/app/Support/CustomerHealth/WorkspaceHealthSummaryQuery.php` so the linked residual detail pages can explain the same dominant drivers as the dashboard
- [x] T026 [US2] Rename the tenant/workspace drilldown affordance in `apps/platform/app/Support/CustomerHealth/WorkspaceHealthSummaryQuery.php` from an opening verb to the decision-first `Review health details` copy while keeping `Open runs` unchanged for operational follow-up
- [x] T027 [US2] Add a read-only customer-health decision card above existing diagnostics on `apps/platform/app/Filament/System/Pages/Directory/ViewTenant.php`, `apps/platform/app/Filament/System/Pages/Directory/ViewWorkspace.php`, and their directory Blade views by reusing `WorkspaceHealthSummaryQuery`
- [x] T028 [P] [US2] Add focused feature coverage for the new residual detail follow-up card in `apps/platform/tests/Feature/System/CustomerHealth/CustomerHealthDetailDecisionTest.php`
- [x] T029 [US2] Run the focused drilldown validation proof with `export PATH="/bin:/usr/bin:/usr/local/bin:$PATH" && cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Unit/Support/CustomerHealth/WorkspaceHealthSummaryQueryTest.php tests/Feature/System/CustomerHealth/CustomerHealthExplainabilityTest.php tests/Feature/System/CustomerHealth/CustomerHealthDetailDecisionTest.php`
---
## Dependencies & Execution Order
### Recommended Execution Order
```text
Phase 1 (Setup)
Phase 2 (Dimension catalog + derived summary query)
↙ ↘
US1 (aggregate health counts) US2 (attention-needed workspace list)
US3 (honest unknown handling + authorization hardening)
```
### Parallel Opportunities
- The foundational unit tests can be authored in parallel once the fixed first-slice dimension inventory is agreed.
- The aggregate summary widget and attention-needed widget feature tests can be written in parallel after the derived summary shape is stable.
- Authorization coverage can proceed in parallel with final unknown-handling hardening because it exercises existing `/system` gates.
---
## Test Governance Checklist
- [x] Lane assignment is named and is the narrowest sufficient proof for the changed behavior.
- [x] New or changed tests stay in the smallest honest family, and no heavy-governance or browser family is introduced accidentally.
- [x] Shared helpers and fixture setup remain cheap by default.
- [x] Planned validation commands cover the change without pulling in unrelated lane cost.
- [x] The adopted surfaces explicitly use `standard-native-filament` relief.
- [x] No material budget or baseline escalation is introduced.
**Test-governance outcome (TEST-GOV-001)**: keep