TenantAtlas/specs/278-cross-domain-indicator-audit/follow-up-map.md

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