ahmido/TenantAtlas
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects 1 Releases Wiki Activity
bf561b867c
TenantAtlas/specs/278-cross-domain-indicator-audit/follow-up-map.md
ahmido bf561b867c Automated: commit from 278-cross-domain-indicator-audit (#334) 
Automated PR created by Copilot: includes all local changes.

Co-authored-by: Ahmed Darrazi <ahmed.darrazi@live.de>
Reviewed-on: #334
2026-05-06 09:21:06 +00:00

8.1 KiB
Raw Blame History

Follow-Up Map: Cross-Domain Progress Indicator Semantics Audit

Package: specs/278-cross-domain-indicator-audit/
Status: Implemented docs-only follow-up map
Out of scope for this slice: all runtime code, tests, migrations, presenters, shared components, UI rewrites, score recalculation, and quality-gate automation

Disposition Rules

  • keep as-is means the current cue is semantically honest enough for this slice.
  • Every other disposition must point to exactly one lane below.
  • These lanes are seed material for later specs. They do not authorize implementation inside Spec 278.

Follow-Up Lanes

Standards Patch Lane

  • Purpose: Patch durable product/UI standards so future specs can distinguish execution progress, activity state, coverage, completion, health, readiness, risk, pressure, usage, capacity, score, and generation state without rereading this inventory.
  • Out of scope for this slice: runtime components, shared contracts, migration, automated checks.
  • Trigger cues: IND-002, IND-005, IND-007, IND-008, IND-009, IND-011, IND-013, IND-018, IND-020, IND-022, IND-025, IND-027, IND-029, IND-033, IND-035, IND-036, IND-037, IND-038.
  • Likely repo surfaces:
    • docs/ui/tenantpilot-enterprise-ui-standards.md
    • .specify/templates/spec-template.md
    • .specify/templates/plan-template.md
    • .specify/templates/tasks-template.md
    • .specify/templates/checklist-template.md
  • Seed questions:
    • Does the cue state what it measures before the operator sees a bar, percentage, status, or score?
    • Is the denominator real, current, and visible enough to support determinate display?
    • Does missing or stale data render as missing/stale instead of as healthy zero?
    • Is the cue provider-owned, tenant-owned, workspace aggregate, or canonical-view output?
    • Is a copy-only correction enough, or does the cue need a contract or migration spec?

Metric/Indicator Contract Foundation

  • Purpose: Define a provider-neutral indicator contract so values carry category, direction, denominator, freshness, source, missing-data treatment, interpretation, and next-action semantics.
  • Out of scope for this slice: implementing the contract, migrating domains to it, or changing current rendering.
  • Trigger cues: IND-006, IND-010, IND-012, IND-014, IND-016, IND-019, IND-021, IND-023, IND-024, IND-028, IND-030, IND-031, IND-032.
  • Likely repo surfaces:
    • apps/platform/app/Support/TenantDashboard/TenantDashboardSummaryBuilder.php
    • apps/platform/app/Filament/Widgets/Inventory/InventoryKpiHeader.php
    • apps/platform/app/Filament/Widgets/Dashboard/RecoveryReadiness.php
    • apps/platform/app/Services/Baselines/SnapshotRendering/BaselineSnapshotPresenter.php
    • apps/platform/app/Filament/Resources/EvidenceSnapshotResource.php
    • apps/platform/app/Filament/Resources/StoredReportResource.php
    • apps/platform/app/Filament/Resources/ProviderConnectionResource.php
  • Seed questions:
    • Which fields are mandatory for every category, and which are category-specific?
    • How does the contract represent direction: higher-is-better, lower-is-better, threshold, neutral, inverted, or non-numeric?
    • How are freshness, missing basis, and unknown denominator represented?
    • How does a provider-owned example avoid becoming platform-core vocabulary?
    • Which existing dashboard/readiness cues must remain derived until the contract is adopted?

Shared Indicator Component System

  • Purpose: Create a small Filament-compatible component family after the contract exists, with visual treatment chosen by semantic category rather than by local Blade styling.
  • Out of scope for this slice: component implementation, Blade refactors, design-system rollout, asset registration, or browser smoke coverage.
  • Trigger cues: IND-017, IND-026, plus downstream adopters from IND-001, IND-002, IND-006, IND-010, IND-014, IND-031, and IND-032 once the contract exists.
  • Likely repo surfaces:
    • apps/platform/resources/views/livewire/bulk-operation-progress.blade.php
    • apps/platform/resources/views/filament/widgets/dashboard/tenant-dashboard-overview.blade.php
    • apps/platform/resources/views/filament/widgets/dashboard/recovery-readiness.blade.php
    • apps/platform/resources/views/filament/forms/components/restore-run-checks.blade.php
    • apps/platform/resources/views/filament/forms/components/restore-run-preview.blade.php
    • future shared view components or Filament primitives selected by a later spec
  • Seed questions:
    • Which categories deserve bars, badges, KPI cards, summary rows, or text-only treatment?
    • How does the component prevent health, risk, usage, score, or generation state from masquerading as execution progress?
    • Which categories need ARIA progress semantics, and which must avoid role="progressbar"?
    • How does the component keep Filament-native style and avoid ad-hoc card/button/badge systems?

Quality Gate Lane

  • Purpose: Make new or changed indicator drift visible through review guidance, static scans, focused tests, and browser smoke obligations where runtime UI changes justify them.
  • Out of scope for this slice: CI or guard-test implementation.
  • Trigger cues: all non-keep as-is entries, especially IND-002, IND-020, IND-026, IND-031, IND-032, IND-035, IND-036, and IND-037.
  • Likely repo surfaces:
    • .specify/templates/tasks-template.md
    • .specify/templates/checklist-template.md
    • future guard tests under apps/platform/tests/
    • future static scans for role="progressbar", inline width: {{ ... }}%, posture_score, score, health, readiness, and ambiguous Active operations copy
  • Seed questions:
    • Which static patterns are reliable enough to warn without blocking unrelated CRUD badges?
    • Which runtime indicator changes require Pest coverage, browser smoke, or both?
    • What is the failure message when a new progress bar lacks real denominator/freshness/category evidence?
    • How do legacy advisory findings differ from new hard-stop rules?

Domain Migration Lane

  • Purpose: Migrate existing domains in bounded passes after standards, contract, component, and quality-gate foundations exist.
  • Out of scope for this slice: any domain migration or runtime cleanup.
  • Trigger cues: all entries with copy-only clarification, standards clarification, contract follow-up, shared-component follow-up, product decision, or migration follow-up.
  • Likely repo surfaces:
    • dashboard and tenant dashboard: IND-016 through IND-029
    • inventory: IND-005 through IND-009
    • operations: IND-001 through IND-004, IND-038
    • backup/restore: IND-010, IND-011, IND-035, IND-036
    • baseline compare/snapshots: IND-012, IND-013, IND-021, IND-022, IND-037
    • evidence/reports/provider posture: IND-031, IND-032, IND-033, IND-034
    • workspace triage: IND-030
  • Seed questions:
    • Which cue can be fixed by copy only without changing behavior?
    • Which cue must wait for the indicator contract or shared component?
    • Which domain owns the source truth and migration proof?
    • Which migrated surfaces need browser smoke because they change visible operator flows?
    • Which ambiguities should be deferred because they need a product decision?

Required Follow-Up Candidate Sync

The product backlog should keep the five lanes separate:

  1. standards patch lane
  2. metric/indicator contract foundation
  3. shared indicator component system
  4. quality gate lane
  5. domain migration lane

The active audit does not collapse these into one broad "indicator cleanup" program.

Residual Risks

  • The inventory can become stale as new dashboard, report, provider, commercial, or customer-health cues land.
  • Platform /system customer-health indicators were deliberately excluded from this active scope; they should be re-audited if a platform-plane health-score spec is promoted.
  • Some labels are customer-readable today but derive from operator-facing data. Later migration work must keep audience mode explicit.