# 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.