chore: commit all changes (automated)

2026-05-06 10:46:22 +02:00 · 2026-05-06 10:46:22 +02:00 · 0fa5be8d9d
commit 0fa5be8d9d
parent c44f683aa6
16 changed files with 2150 additions and 3 deletions
--- a/.github/agents/copilot-instructions.md
+++ b/.github/agents/copilot-instructions.md
@ -274,6 +274,8 @@ ## Active Technologies
 - PostgreSQL via existing tenant-owned findings, exceptions, operation runs, evidence snapshots, review packs, tenant reviews, backup or restore evidence records, memberships, and audit logs; no new persistence planned (266-tenant-dashboard-productization-v1)
 - PHP 8.4, Laravel 12 + Filament v5, Livewire v4, Laravel translator, existing `App\Services\Localization\LocaleResolver`, `App\Http\Controllers\LocalizationController`, current `localization.review.*` and locale feedback catalogs, `CustomerReviewWorkspace`, `TenantReviewResource`, `ViewTenantReview`, current review-pack and evidence resource paths, shared RBAC and audit helpers (275-customer-facing-localization-adoption)
 - PostgreSQL via existing `users.preferred_locale`, existing workspace localization setting, existing `tenant_reviews`, `review_packs`, `evidence_snapshots`, memberships, and `audit_logs`; translation catalogs in `apps/platform/lang/en` and `apps/platform/lang/de`; no new persistence planned (275-customer-facing-localization-adoption)
+- Markdown and YAML planning artifacts over PHP 8.4 / Laravel 12 source anchors + `spec.md`, `docs/product/spec-candidates.md`, `docs/product/roadmap.md`, `docs/ui/tenantpilot-enterprise-ui-standards.md`, nearby Specs `270`, `275`, and `277`, and repo-real source anchors such as `OperationUxPresenter`, `InventoryKpiHeader`, `RecoveryReadiness`, `BaselineSnapshotPresenter`, `ReviewPackService`, and `TenantDashboardSummaryBuilder` (278-cross-domain-indicator-audit)
+- Repository files only; no database or runtime persistence changes (278-cross-domain-indicator-audit)

 - PHP 8.4.15 (feat/005-bulk-operations)

@ -308,9 +310,9 @@ ## Code Style
 PHP 8.4.15: Follow standard conventions

 ## Recent Changes
+- 278-cross-domain-indicator-audit: Added Markdown and YAML planning artifacts over PHP 8.4 / Laravel 12 source anchors + `spec.md`, `docs/product/spec-candidates.md`, `docs/product/roadmap.md`, `docs/ui/tenantpilot-enterprise-ui-standards.md`, nearby Specs `270`, `275`, and `277`, and repo-real source anchors such as `OperationUxPresenter`, `InventoryKpiHeader`, `RecoveryReadiness`, `BaselineSnapshotPresenter`, `ReviewPackService`, and `TenantDashboardSummaryBuilder`
 - 275-customer-facing-localization-adoption: Added PHP 8.4, Laravel 12 + Filament v5, Livewire v4, Laravel translator, existing `App\Services\Localization\LocaleResolver`, `App\Http\Controllers\LocalizationController`, current `localization.review.*` and locale feedback catalogs, `CustomerReviewWorkspace`, `TenantReviewResource`, `ViewTenantReview`, current review-pack and evidence resource paths, shared RBAC and audit helpers
 - 266-tenant-dashboard-productization-v1: Added PHP 8.4, Laravel 12 + Filament v5, Livewire v4, Tailwind v4, Pest v4, existing dashboard widgets, `TenantGovernanceAggregateResolver`, `RestoreSafetyResolver`, `BackupHealthDashboardSignal`, `OperationRunLinks`, `RequiredPermissionsLinks`, `TenantRequiredPermissionsViewModelBuilder`, tenant review/evidence/review-pack resources, shared badge rendering, and capability helpers
- 260-governance-service-packaging: Added PHP 8.4, Laravel 12 + Filament v5, Livewire v4, Pest v4, existing `TenantReviewComposer`, `TenantReviewSectionFactory`, `ComplianceEvidenceMappingV1`, `ReviewPackService`, `ArtifactTruthPresenter`, capability helpers, localization copy, and shared audit infrastructure
 <!-- MANUAL ADDITIONS START -->

 ### Pre-production compatibility check
--- a/docs/product/implementation-ledger.md
+++ b/docs/product/implementation-ledger.md
@ -219,6 +219,7 @@ ## Open Gaps & Blockers
 | Gap | Type | Impact | Roadmap Area | Recommended Spec |
 |---|---|---|---|---|
 | No safe automatic next-best-prep target is currently active | Planning boundary | `docs/product/spec-candidates.md` now keeps the active queue empty, so the next slice must be promoted deliberately instead of selected automatically | Product planning / queue hygiene | none - require explicit manual promotion |
+| Workspace-first / ManagedEnvironment core cutover is not started | Strategic architecture blocker | The repo still centers many governance, support, and portfolio surfaces on `Tenant` semantics, so future multi-provider work would otherwise accumulate more tenant- and Microsoft-centric core coupling | Platform core / provider-neutral posture | `Workspace-first / ManagedEnvironment Core Cutover` pack in `docs/product/spec-candidates.md` (planned as Specs 279-287) |
 | Auditor-ready executive export is still missing | Productization blocker | Review truth remains short of auditor-/executive-ready delivery, even though the dedicated follow-through is now spec-backed | R2 review delivery | `specs/263-auditor-pack-executive-export/spec.md` |
 | Cross-tenant promotion execution is still missing | Product blocker | Compare preview and preflight are repo-real, but the actual portfolio action remains absent even though the execution package is now spec-backed | MSP Portfolio & Operations | `specs/264-cross-tenant-promotion-execution/spec.md` |
 | Decision register and approval workflow is still missing | Product blocker | Decision-based operating still lacks a bounded approval-ready closure and decision-record package with audit trail | Decision-based operating | `Decision Register & Approval Workflow v1` |
@ -234,6 +235,7 @@ ## Open Gaps & Blockers
 ## Recommended Manual Promotions

 - `Cross-Domain Progress / Indicator Semantics candidate group` -> anchored by `specs/268-operationrun-activity-feedback/spec.md`, `specs/270-operationrun-progress-contract/spec.md`, `specs/271-counted-progress-rollout/spec.md`, `specs/272-operationrun-phase-composite-progress/spec.md`, `docs/ui/tenantpilot-enterprise-ui-standards.md`, and the current progress-like UI seams called out in `docs/product/spec-candidates.md`
+- `Workspace-first / ManagedEnvironment Core Cutover` pack -> anchored by `docs/product/spec-candidates.md`, `docs/product/roadmap.md`, `docs/product/implementation-ledger.md`, and the tenant-centric platform seams already visible across review, support, portfolio, and governance surfaces; keep it as a clean development-stage cutover pack rather than a compatibility-layer program
 - `Decision Register & Approval Workflow v1` -> anchored by `specs/250-decision-governance-inbox/spec.md`, `specs/257-governance-decision-convergence/spec.md`, and `docs/product/roadmap.md`
 - `Governance Artifact Lifecycle & Retention v1` -> anchored by `specs/158-artifact-truth-semantics/spec.md`, `specs/262-lifecycle-governance-taxonomy/spec.md`, and `docs/product/standards/lifecycle-governance.md`
 - `Billing & Subscription Truth Layer v1` -> anchored by `specs/247-plans-entitlements-billing-readiness/spec.md` and `specs/251-commercial-entitlements-billing-state/spec.md`
--- a/docs/product/roadmap.md
+++ b/docs/product/roadmap.md
@ -65,7 +65,7 @@ ### UI & Product Maturity Polish
 Empty state consistency, list-expand parity, workspace chooser refinement, navigation semantics.
 Goal: Every surface feels intentional and guided for first-run evaluation.

-Parallel manual-promotion guardrail: `docs/product/spec-candidates.md` now carries a dedicated Cross-Domain Progress / Indicator Semantics candidate group so progress, coverage, readiness, risk, usage, score, and generation-state surfaces do not keep drifting behind OperationRun-specific rules.
+Parallel manual-promotion guardrail: `docs/product/spec-candidates.md` now carries a dedicated Cross-Domain Progress / Indicator Semantics candidate group so progress, coverage, readiness, risk, usage, score, and generation-state surfaces do not keep drifting behind OperationRun-specific rules. Spec 278 is the docs-first audit slice; its follow-up lanes stay split into standards patch, metric/indicator contract foundation, shared indicator component system, quality gate, and domain migration.

 **Active specs**: 122, 121, 112

@ -121,6 +121,46 @@ ### Product Scalability & Self-Service Foundation

 ## Planned (Next Quarter)

+### Workspace-first / ManagedEnvironment Core Cutover Pack
+Development-stage clean-cutover architecture lane for moving TenantPilot away from a `Tenant`-centric core before more multi-provider, portfolio, and package surfaces accumulate additional tenant- and Microsoft-specific coupling.
+**Goal**: keep `Workspace` as the primary SaaS context, introduce `ManagedEnvironment` as the secondary managed target context, and perform the cutover without legacy compatibility burden.
+
+**Roadmap posture**: manual-promotion-only spec pack, not auto-prep, and explicitly not a "rename Tenant" initiative.
+
+**Hard cutover rules**:
+
+- no legacy `Tenant` compatibility layer
+- no `/admin/t/{tenant}` compatibility route
+- no dual-read from `tenant_id` and `managed_environment_id`
+- no dual-write
+- no production-data backfill
+- no deprecated `Tenant` model left behind as an active domain model
+- no Microsoft-specific identity, Graph, or Intune fields on `ManagedEnvironment`
+- `tenant` remains allowed only in Microsoft-provider copy, payload metadata, or external terminology such as `Microsoft Entra Tenant ID`
+- Filament tenant context must be `Workspace`
+- `ManagedEnvironment` remains a secondary domain context inside a `Workspace`
+
+**Recommended spec order**:
+
+1. `279 Workspace-first Managed Environment Core Cutover`
+2. `280 Filament Workspace Tenancy & Environment Routing Cutover`
+3. `281 Provider Connection, Provider Scope & Microsoft Profile Extraction`
+4. `282 Governance Artifact Retargeting to ManagedEnvironment`
+5. `283 Provider Capability Registry v1`
+6. `284 Provider-neutral Artifact Source Taxonomy v1`
+7. `285 Workspace-first RBAC & Environment Access Scoping`
+8. `286 UI Copy, IA & Localization Neutralization`
+9. `287 Cutover Quality Gates & No-Legacy Enforcement`
+
+**Sequencing note**: Specs 279-282 are the hard cutover. Specs 283-284 make the new core provider-neutral and package-ready. Specs 285-287 keep RBAC, copy, and quality gates from drifting back toward tenant- or Microsoft-centric core assumptions.
+
+**Follow-on series after the cutover pack**:
+
+1. `288 Package Execution Contract v1`
+2. `289 Guided Operations Recommendation Layer v1`
+3. `290 Microsoft Governance Package Starter Pack v1`
+4. `291 Virtual Consultant / External Portal Guidance v1`
+
 ### R2.0 Canonical Control Catalog Foundation
 Framework-neutral canonical control core that bridges the shipped governance engine and later readiness or reporting overlays.
 **Goal**: Give baselines, drift, findings, exceptions, evidence, and reports one shared control object before framework-specific mappings land.
@ -424,7 +464,7 @@ ## Priority Ranking (Current Manual Promotion Order)

 This ranking applies only to still-unspecced or still-manual follow-through items. Auditor-ready delivery and cross-tenant promotion execution already have spec packages and therefore no longer belong in the manual-promotion ordering list.

-Parallel immediate guardrail lane: the Cross-Domain Progress / Indicator Semantics candidate group in `docs/product/spec-candidates.md` should be promoted alongside OperationRun maturity when UI semantic drift is the active concern. It stays outside the main sellability ordering below because it is a cross-cutting semantics and standards package rather than a standalone customer-facing delivery lane.
+Parallel immediate guardrail lane: the Cross-Domain Progress / Indicator Semantics candidate group in `docs/product/spec-candidates.md` should be promoted alongside OperationRun maturity when UI semantic drift is the active concern. Spec 278 provides the audit inventory and standards-delta input; the remaining follow-up remains split across contract, component, quality-gate, and migration lanes. It stays outside the main sellability ordering below because it is a cross-cutting semantics and standards package rather than a standalone customer-facing delivery lane.

 1. Decision Register & Approval Workflow v1
 2. Governance Artifact Lifecycle & Retention v1
--- a/docs/product/spec-candidates.md
+++ b/docs/product/spec-candidates.md
@ -468,6 +468,12 @@ ### Cross-Domain Progress / Indicator Semantics candidate group
  2. **Candidate 10 — Shared Progress / Indicator Component System**
  3. **Candidate 12 — Progress / Indicator Quality Gates**
  4. **Candidate 11 — Domain Progress Cleanup & Migration Pass**
+- **Spec 278 audit output**: `specs/278-cross-domain-indicator-audit/inventory.md`, `follow-up-map.md`, and `standards-delta.md` are the repo-based input for the follow-up lanes. Later work must reuse the five lane names from the map instead of opening a broad catch-all cleanup:
+  - `standards patch lane`: patch product/UI standards and spec templates so each new indicator states category, denominator, freshness, missing-data behavior, provider boundary, and customer-safe wording.
+  - `metric/indicator contract foundation`: define the provider-neutral contract fields and direction/freshness semantics before component or migration work.
+  - `shared indicator component system`: create Filament-compatible renderers only after the contract exists, with category-specific visuals rather than one universal progress bar.
+  - `quality gate lane`: add review checks, scans, tests, and browser-smoke obligations for new/changed indicator surfaces.
+  - `domain migration lane`: migrate current domains from the audit inventory in bounded passes, starting with copy-only ambiguities and dashboard/readiness surfaces.

 ##### Candidate 8 — Cross-Domain Progress Indicator Semantics Audit

@ -611,6 +617,259 @@ ##### Candidate 13 — Cross-Domain UI Standards & Constitution Patch
  - `apps/platform/app/Services/ReviewPackService.php`
  - `docs/ui/tenantpilot-enterprise-ui-standards.md`

+### Workspace-first / ManagedEnvironment Core Cutover candidate pack
+
+- **Priority posture**: deliberate manual-promotion cutover pack, sequenced as one architecture series rather than reopened through local compatibility slices
+- **Positioning**: this is explicitly not a "rename Tenant" candidate. It is a workspace-first / managed-environment core cutover series.
+- **Repo truth**: current repo language, pages, reviews, supportability, portfolio, and governance surfaces still rely heavily on `Workspace` plus `Tenant` as the central managed boundary. There is no repo-real `ManagedEnvironment` core yet, while the roadmap and backlog already point toward broader provider-neutral evolution.
+- **Why promotable now**: the platform is still in development, with no promised production-data migration or compatibility guarantees, so a clean cutover is safer now than after more tenant-centric and Microsoft-specific core seams accumulate.
+- **Why manual promotion only**: this is a strategic architecture pack. It must be promoted deliberately from docs and backlog, not auto-prepped as one giant implementation umbrella or fragmented into dual-read, dual-write, alias, or compatibility-route work.
+- **Numbering note**: spec slots 279-287 are currently free and are reserved here for this pack.
+- **Anchors**:
+  - `docs/product/roadmap.md`
+  - `docs/product/implementation-ledger.md`
+  - `specs/043-cross-tenant-compare-and-promotion/spec.md`
+  - `specs/247-plans-entitlements-billing-readiness/spec.md`
+  - `specs/248-private-ai-policy-foundation/spec.md`
+  - `specs/251-commercial-entitlements-billing-state/spec.md`
+  - `specs/252-platform-localization-v1/spec.md`
+  - `specs/262-lifecycle-governance-taxonomy/spec.md`
+  - `specs/264-cross-tenant-promotion-execution/spec.md`
+
+#### Global Cutover Rules
+
+This candidate pack is allowed to perform a clean development-stage cutover.
+
+Hard rules:
+
+- No legacy `Tenant` compatibility layer.
+- No `/admin/t/{tenant}` compatibility route.
+- No dual-read from `tenant_id` and `managed_environment_id`.
+- No dual-write.
+- No production-data backfill.
+- No deprecated `Tenant` model left behind as active domain model.
+- No new Microsoft-specific fields on `ManagedEnvironment`.
+- The term `tenant` may only remain in provider-specific Microsoft copy, payload metadata, or external terminology such as `Microsoft Entra Tenant ID`.
+- Filament tenant context MUST be `Workspace`.
+- `ManagedEnvironment` MUST be a secondary domain context inside a `Workspace`.
+
+#### Recommended promotion order
+
+1. `279 Workspace-first Managed Environment Core Cutover`
+2. `280 Filament Workspace Tenancy & Environment Routing Cutover`
+3. `281 Provider Connection, Provider Scope & Microsoft Profile Extraction`
+4. `282 Governance Artifact Retargeting to ManagedEnvironment`
+5. `283 Provider Capability Registry v1`
+6. `284 Provider-neutral Artifact Source Taxonomy v1`
+7. `285 Workspace-first RBAC & Environment Access Scoping`
+8. `286 UI Copy, IA & Localization Neutralization`
+9. `287 Cutover Quality Gates & No-Legacy Enforcement`
+
+#### Follow-on candidates after the cutover pack
+
+1. `288 Package Execution Contract v1`
+2. `289 Guided Operations Recommendation Layer v1`
+3. `290 Microsoft Governance Package Starter Pack v1`
+4. `291 Virtual Consultant / External Portal Guidance v1`
+
+#### 279 — Workspace-first Managed Environment Core Cutover
+
+- **Goal**: replace the current `Tenant`-centric core with a provider-agnostic `ManagedEnvironment` core while keeping `Workspace` as the primary SaaS and organization context.
+- **Scope**:
+  - introduce `App\Models\ManagedEnvironment`
+  - introduce the `managed_environments` table with `workspace_id`, `external_id` or `slug`, `name`, `display_name`, `kind`, `lifecycle_status`, `metadata`, timestamps
+  - establish `Workspace -> ManagedEnvironment` as the new core relationship
+  - replace or remove the active `Tenant` core model, table, factories, policies, route bindings, and Filament tenancy usage
+  - move core relations from `tenant_id` to `managed_environment_id`
+  - keep Microsoft-specific identity, Graph, and Intune fields out of `ManagedEnvironment`
+- **Non-goals**:
+  - no package execution engine
+  - no guided operations engine
+  - no virtual consultant
+  - no new providers beyond re-homing the current Microsoft integration into the new core shape
+  - no legacy backfill, compatibility routes, dual-schema support, or tenant alias model
+- **Acceptance criteria**:
+  - no active `App\Models\Tenant` remains
+  - no core `tenants` table remains
+  - core tables reference `managed_environment_id` instead of `tenant_id`
+  - `ManagedEnvironment` has no Microsoft-specific identity, Graph, or Intune fields
+  - tests, factories, policies, and seeders use `ManagedEnvironment`
+  - repo search for `tenant_id` finds no active core use
+
+#### 280 — Filament Workspace Tenancy & Environment Routing Cutover
+
+- **Goal**: make the Filament admin panel consistently workspace-first, with `Workspace` as the Filament tenant and `ManagedEnvironment` as a nested domain context.
+- **Scope**:
+  - switch Filament tenant context to `Workspace`
+  - remove the `/admin/t/{tenant}` route family
+  - introduce workspace-first environment routing such as `/admin/workspaces/{workspace}/environments/{environment}`
+  - add a workspace dashboard for workspace-wide signals
+  - add a managed-environment dashboard for environment-scoped signals
+  - make `/admin/workspaces/{workspace}/operations` the canonical operations route and link environment pages into it via filters
+  - align navigation and breadcrumbs to `Workspace -> Managed Environment -> domain page`
+- **Non-goals**:
+  - no customer portal cutover
+  - no package engine
+  - no guided operations rollout
+  - no legacy `/admin/t` route
+  - no second Filament tenancy on the environment level
+- **Acceptance criteria**:
+  - Filament tenant context is `Workspace`
+  - `ManagedEnvironment` is not used as the Filament tenant
+  - `/admin/t/{tenant}` no longer exists
+  - all environment pages live under a workspace path
+  - operations hub is workspace-level canonical
+  - breadcrumbs show `Workspace -> Managed Environment -> domain page`
+
+#### 281 — Provider Connection, Provider Scope & Microsoft Profile Extraction
+
+- **Goal**: move provider-specific identity, scope, permission, and portal semantics out of the core and bind them to provider-aware connection and profile surfaces.
+- **Scope**:
+  - replace `provider_connections.tenant_id` with `provider_connections.managed_environment_id`
+  - standardize a generic provider-scope contract with `provider_key`, `target_scope_kind`, `target_scope_identifier`, `external_account_id`, and `provider_metadata`
+  - extract Microsoft-specific data such as `entra_tenant_id`, domains, consent state, Graph client identifiers, portal links, and required permissions out of the core
+  - allow those Microsoft-specific details only in provider metadata, provider credentials, or dedicated Microsoft provider profiles
+  - update `OperationRun` start context to use `workspace_id`, `managed_environment_id`, `provider_connection_id`, `provider_key`, `target_scope_kind`, and `target_scope_identifier`
+- **Non-goals**:
+  - no new package engine
+  - no new provider implementations
+  - no UI polish pass
+  - no fallback on `tenant_id`
+  - no backfill
+- **Acceptance criteria**:
+  - `ProviderConnection` references `ManagedEnvironment`
+  - provider-specific identity does not live on `ManagedEnvironment`
+  - `OperationRun` context contains provider-neutral scope fields
+  - Microsoft-specific scope logic sits in Microsoft provider code
+  - the provider-scope contract can later absorb AWS, Google, or Okta without core changes
+
+#### 282 — Governance Artifact Retargeting to ManagedEnvironment
+
+- **Goal**: move governance-relevant artifacts from tenant semantics to managed-environment semantics while keeping explicit workspace-level artifacts on `workspace_id` only.
+- **Scope**:
+  - move `operation_runs` to `workspace_id` required and `managed_environment_id` nullable
+  - retarget inventory, policies, policy versions, backup sets, backup items, restore runs, findings, evidence snapshots, reviews, review packs, and stored reports to `managed_environment_id` where environment-scoped
+  - rename tenant-scoped review concepts toward governance- or environment-aware review naming where the current table names are still tenant-bound
+  - update link builders and URL resolvers to workspace-first and environment-aware routes
+  - remove remaining links to `/admin/t`
+- **Non-goals**:
+  - no legacy review type carry-over
+  - no `tenant_id` aliases
+  - no dual relations
+  - no historical data migration
+  - no new report engine
+- **Acceptance criteria**:
+  - governance artifacts use `managed_environment_id` or intentionally only `workspace_id`
+  - no active `tenant_id` foreign keys remain in core governance tables
+  - operation detail pages work workspace-first
+  - reviews, evidence, findings, and reports are environment-aware
+  - canonical URLs contain workspace and optional environment context
+
+#### 283 — Provider Capability Registry v1
+
+- **Goal**: model provider requirements through provider-neutral capability keys so later packages and guided operations do not depend directly on Microsoft permission constants.
+- **Scope**:
+  - introduce a provider capability contract with `provider_capability_key`, `status`, `reason_code`, `provider_requirement_key`, `last_checked_at`, and `metadata`
+  - use statuses `supported`, `missing`, `blocked`, `unknown`, and `not_applicable`
+  - define business-facing capability keys such as `endpoint_inventory_read`, `endpoint_configuration_read`, `identity_access_policy_read`, `identity_admin_role_read`, `evidence_snapshot_write`, `review_publish`, and `provider_permission_check`
+  - evaluate capabilities through provider-specific adapters
+  - make `OperationRun` start gates check capability keys instead of raw Microsoft permissions
+  - show a provider-neutral capability plus a provider-specific remediation hint in the UI
+- **Non-goals**:
+  - no package engine
+  - no user RBAC rewrite
+  - no end-user permission management layer
+  - no AWS or Google implementation yet
+  - no auto-consent flow
+- **Acceptance criteria**:
+  - provider operations can declare business-facing capability keys
+  - Microsoft Graph permissions remain mapping details
+  - capability results are audit-friendly
+  - later package execution can depend on capability keys instead of provider-specific constants
+
+#### 284 — Provider-neutral Artifact Source Taxonomy v1
+
+- **Goal**: give findings, evidence, stored reports, inventory, and later package outputs a provider-neutral source, detector, and control taxonomy.
+- **Scope**:
+  - standardize `source_family`, `source_kind`, `provider_key`, `provider_connection_id`, `managed_environment_id`, `source_target_kind`, `source_target_identifier`, `detector_key`, `control_key`, and optional `package_run_id`
+  - stop treating Entra or Intune type names as core-domain truth in findings and evidence
+  - represent Microsoft-specific detector details as provider keys, provider object types, or detector keys
+  - separate canonical domain type, provider object type, and provider display type for inventory metadata
+  - align stored reports to source-family semantics
+- **Non-goals**:
+  - no new compliance engine
+  - no full control-catalog expansion
+  - no historical backfill
+  - no UI-polish-first scope
+- **Acceptance criteria**:
+  - findings, evidence, and reports can be interpreted provider-neutrally
+  - Microsoft types remain provider object types or detector keys, not core truth
+  - later package execution can build on `source_family`, `canonical_type`, and `control_key`
+  - existing Microsoft outputs remain valid as Microsoft provider sources
+
+#### 285 — Workspace-first RBAC & Environment Access Scoping
+
+- **Goal**: align RBAC with workspace-first tenancy and optional managed-environment scoping.
+- **Scope**:
+  - make `WorkspaceMembership` the primary access truth
+  - route workspace access through workspace membership
+  - prepare optional environment access scopes without requiring environment-level ACL complexity in v1
+  - update capability resolution for workspace context, optional managed-environment context, and provider capability context
+  - retarget policies for `ManagedEnvironment`, `ProviderConnection`, `OperationRun`, `Finding`, `EvidenceSnapshot`, and governance review surfaces
+  - keep future customer-safe roles such as `Workspace Admin`, `Governance Operator`, `Reviewer`, `Customer Viewer`, `Support Operator`, and `Billing Admin` feasible
+- **Non-goals**:
+  - no full role productization
+  - no customer portal RBAC migration
+  - no mandatory environment-level ACL in v1
+  - no legacy `TenantMembership`
+- **Acceptance criteria**:
+  - `TenantMembership` is removed or fully replaced by `WorkspaceMembership`
+  - Filament access is based on `WorkspaceMembership`
+  - policies use managed-environment context where appropriate
+  - later environment scoping can be added without rebuilding the core model
+
+#### 286 — UI Copy, IA & Localization Neutralization
+
+- **Goal**: neutralize generic platform copy, information architecture, and localization keys around workspace-first and provider-neutral vocabulary.
+- **Scope**:
+  - use `Workspace`, `Managed Environment`, `Provider Connection`, `Inventory`, `Evidence`, `Review`, `Operation`, `Finding`, and `Governance` across generic platform surfaces
+  - keep `Tenant`, `Intune`, `Microsoft Graph`, and `Entra` only inside Microsoft-provider-specific contexts
+  - align workspace and environment navigation to workspace-first information architecture
+  - replace localization keys such as `tenant`, `tenant_review`, `tenant_dashboard`, and `managed_tenant` with managed-environment or governance-review language
+  - rewrite empty states toward provider-neutral wording
+- **Non-goals**:
+  - no new design-system spec
+  - no customer portal redesign
+  - no new guided operations UX
+  - no legacy translation-key aliases
+- **Acceptance criteria**:
+  - core UI uses provider-neutral language
+  - Microsoft-specific terms appear only in Microsoft provider contexts
+  - navigation is workspace-first
+  - localization keys no longer carry old tenant-core terminology
+  - empty states support multi-provider positioning
+
+#### 287 — Cutover Quality Gates & No-Legacy Enforcement
+
+- **Goal**: protect the cutover with tests, static searches, and architecture guardrails so tenant- and Microsoft-core legacy cannot silently return.
+- **Scope**:
+  - add static search gates for `App\Models\Tenant`, `tenant_id`, `/admin/t`, `TenantResource`, `TenantMembership`, Microsoft-specific fields on `ManagedEnvironment`, and Microsoft permission constants inside future package or guidance core code
+  - keep a narrow allowlist for Microsoft provider adapters, Microsoft translations, external payload metadata, test fixtures, and docs about removed legacy
+  - add architecture tests for workspace-first tenancy, managed-environment ownership, provider-connection ownership, workspace plus optional environment run scoping, and Microsoft-field exclusion from core models
+  - add route tests for workspace dashboards, environment dashboards, workspace-level operations, and `/admin/t/{tenant}` returning `404`
+  - add policy tests for workspace membership, managed-environment access, and cross-workspace denial
+  - add provider-boundary tests so capability keys stay provider-neutral and Microsoft permission constants remain mapping details
+- **Non-goals**:
+  - no new feature delivery
+  - no UI polish pass
+  - no package engine
+  - no compatibility tests for legacy routes beyond asserting they are gone
+- **Acceptance criteria**:
+  - CI fails when tenant-core terms re-enter the platform core
+  - CI fails when `/admin/t` reappears
+  - CI fails when Microsoft-specific fields land on `ManagedEnvironment`
+  - architecture tests document workspace-first and managed-environment-first as the new platform boundary
+
 ### Decision Register & Approval Workflow v1

 - **Priority**: 1
--- a/docs/ui/tenantpilot-enterprise-ui-standards.md
+++ b/docs/ui/tenantpilot-enterprise-ui-standards.md
@ -366,6 +366,45 @@ # TenantPilot Enterprise UI Standards**Status:** Active  **Owner:** Product / En
 <div class="space-y-1.5">    <div class="flex items-center justify-between gap-3 text-sm">        <span class="text-gray-600">Findings with outcome</span>        <span class="font-medium text-gray-900">2/3 (67%)</span>    </div>    <div        class="w-full overflow-hidden rounded-full bg-gray-100"        style="height: 8px;"    >        <div            class="h-full rounded-full"            style="width: 67%; background-color: var(--primary-500);"            role="progressbar"            aria-valuenow="67"            aria-valuemin="0"            aria-valuemax="100"            aria-valuetext="2/3 (67%)"        ></div>    </div></div>
 For custom progress bars, fixed inline height MAY be used when Tailwind height utilities are not reliably present in the loaded Filament theme.

+11A. Cross-Domain Indicator Semantics
+Indicator-like cues are not interchangeable. A bar, percentage, score, KPI count, status badge, readiness label, health label, risk count, usage/capacity value, or generation-state hint MUST state what it measures and must not borrow execution-progress language unless it measures active execution.
+
+Allowed indicator categories:
+
+- execution progress
+- activity state
+- coverage
+- completion
+- health
+- readiness
+- risk
+- pressure
+- usage
+- capacity
+- score
+- generation state
+- unknown/ambiguous
+
+Rules:
+
+- each indicator gets one primary category at the cue level
+- execution progress is only active work progress
+- coverage, completion, health, readiness, risk, pressure, usage, capacity, score, and generation state MUST NOT look or read like execution progress
+- determinate progress UI requires truthful numerator/denominator or percent values plus visible text and ARIA
+- unknown, stale, or missing source truth MUST stay visible and MUST NOT default to calm, ready, healthy, complete, or zero
+- scores MUST expose direction, scale, freshness, and source before they are treated as customer-safe or decision-ready
+- usage and capacity indicators MUST NOT use success-progress styling unless the copy makes clear that they measure consumption or remaining allowance
+- provider-owned health and permission-posture cues remain provider examples; they MUST NOT define platform-core health, readiness, score, or success semantics by default
+- dashboard rollups MUST keep execution outcome, data completeness, governance result, lifecycle/readiness, risk pressure, and customer handoff maturity distinct enough for the first operator decision
+
+Forbidden:
+
+- fake percentages or demo progress
+- outcome counters reused as progress counters
+- provider health, risk, pressure, usage, score, readiness, or generation-state bars with no real denominator
+- stale or missing basis shown as current truth
+- generic labels such as Progress, Score, Health, Ready, Active, or Complete when the source truth measures something narrower
+
 12. Context Chip Pattern
 Context chips provide lightweight environment context.
 Examples:
--- a/specs/278-cross-domain-indicator-audit/checklists/requirements.md
+++ b/specs/278-cross-domain-indicator-audit/checklists/requirements.md
@ -0,0 +1,57 @@
+# Specification Quality Checklist: Cross-Domain Progress Indicator Semantics Audit
+
+**Purpose**: Validate specification completeness, boundedness, implementation evidence, and manual-review readiness  
+**Created**: 2026-05-06  
+**Feature**: [spec.md](../spec.md)
+
+## Content Quality
+
+- [x] The package stays repo-based and docs/governance-first instead of widening into runtime contract, component, migration, analytics, or UI rewrite work.
+- [x] The spec and plan remain product- and behavior-oriented rather than reading like a low-level code diff.
+- [x] The package explicitly names the repo-real standards and source anchors it builds on: `docs/ui/tenantpilot-enterprise-ui-standards.md`, `OperationUxPresenter`, `InventoryKpiHeader`, `RecoveryReadiness`, `BaselineSnapshotPresenter`, `ReviewPackService`, and `TenantDashboardSummaryBuilder`.
+- [x] Mandatory repo sections for scope, RBAC, shared-pattern reuse, testing, proportionality, and candidate rationale are completed.
+
+## Requirement Completeness
+
+- [x] No `[NEEDS CLARIFICATION]` markers remain.
+- [x] Requirements are testable and bounded to one docs-only audit bundle: inventory, classification, risk/disposition notes, standards delta, and follow-up map.
+- [x] The package explicitly forbids shared indicator component implementation, runtime contract rollout, quality-gate code, domain migration, analytics, charting, score recalculation, and application rewrites.
+- [x] Canonical implementation proof commands match across `spec.md`, `plan.md`, `quickstart.md`, and `tasks.md`, including the implemented audit outputs and bounded documentation destinations.
+
+## Repo Truth Anchoring
+
+- [x] The package reflects the candidate and roadmap posture from `docs/product/spec-candidates.md` and `docs/product/roadmap.md`.
+- [x] The package treats `docs/ui/tenantpilot-enterprise-ui-standards.md` as the standards-delta target and adds only distilled rules, not the full inventory.
+- [x] The package treats the named runtime anchors as source surfaces only and does not assume they will be rewritten in this slice.
+- [x] Related Specs `266`, `268`, `270`, `271`, and `272` are carried forward as context-only guardrails and not reopened.
+
+## Feature Readiness
+
+- [x] The package keeps Filament on Livewire v4, provider registration unchanged in `apps/platform/bootstrap/providers.php`, global search unchanged, and assets unchanged.
+- [x] The package introduces no destructive actions, no panel changes, and no runtime authorization or scope changes.
+- [x] Later follow-up work is explicitly split into the standards patch lane, metric/indicator contract foundation, shared indicator component system, quality gate lane, and domain migration lane.
+- [x] The implementation of this slice is constrained to repository artifacts and documentation targets, not app code.
+- [x] `inventory.md`, `follow-up-map.md`, and `standards-delta.md` exist as the package-local implementation outputs.
+- [x] `docs/product/spec-candidates.md` and `docs/product/roadmap.md` reference the five-lane follow-up posture without promoting runtime work into this slice.
+
+## Test Governance
+
+- [x] Proof stays bounded to docs review plus diff and grep validation.
+- [x] No new runtime, heavy-governance, or browser lane is introduced.
+- [x] Fixture, helper, factory, seed, and context growth stays `none` because the package does not touch runtime code.
+- [x] The review outcome, workflow outcome, and test-governance outcome are carried into `plan.md` and this checklist.
+
+## Notes
+
+- Reviewed against `.specify/memory/constitution.md`, `docs/product/spec-candidates.md`, `docs/product/roadmap.md`, `docs/ui/tenantpilot-enterprise-ui-standards.md`, and nearby Specs `270`, `275`, and `277` on 2026-05-06.
+- Confirmed the named source anchors exist under `apps/platform` and are suitable as audit inputs.
+- No application implementation was performed while preparing or implementing this package.
+- Implementation output review on 2026-05-06 confirmed the inventory, standards delta, follow-up map, UI standards delta, product candidates, and roadmap references remain docs/governance-only.
+
+## Review Outcome
+
+- **Outcome class**: `acceptable-special-case`
+- **Workflow outcome**: `keep`
+- **Test-governance outcome**: `keep`
+- **Reason**: The package prepares one bounded repo audit foundation over real existing cues, keeps runtime follow-up work explicitly separate, and uses honest docs-only proof instead of pretending application behavior changed.
+- **Implementation result**: Ready for manual review.
--- a/specs/278-cross-domain-indicator-audit/contracts/cross-domain-indicator-audit.logical.openapi.yaml
+++ b/specs/278-cross-domain-indicator-audit/contracts/cross-domain-indicator-audit.logical.openapi.yaml
@ -0,0 +1,335 @@
+openapi: 3.0.3
+info:
+  title: TenantPilot Repo Governance - Cross-Domain Indicator Semantics Audit (Conceptual)
+  version: 0.1.0
+  description: |
+    Conceptual contract for the repository-governance outputs produced by the
+    cross-domain indicator semantics audit package.
+
+    NOTE: These are planning and documentation artifacts inside the spec package,
+    not application runtime endpoints. The paths below model the logical bundle
+    shape that later reviewers and follow-up specs consume.
+paths:
+  /repository-governance/cross-domain-indicator-semantics/inventory:
+    get:
+      summary: Review the indicator inventory bundle
+      description: |
+        Logical artifact containing one entry per current indicator-like cue in
+        the bounded repo scope. Each entry records the source seam, visible cue,
+        semantic category, misunderstanding risk, and one bounded disposition.
+      responses:
+        '200':
+          description: Indicator inventory bundle available for review
+          content:
+            application/json:
+              schema:
+                $ref: '#/components/schemas/IndicatorInventoryBundle'
+      x-repository-artifact: true
+  /repository-governance/cross-domain-indicator-semantics/standards-delta:
+    get:
+      summary: Review the derived standards delta
+      description: |
+        Logical artifact describing the standards guidance that should later be
+        applied to docs/ui/tenantpilot-enterprise-ui-standards.md without
+        turning this audit package into a runtime implementation pass.
+      responses:
+        '200':
+          description: Standards-delta bundle available for review
+          content:
+            application/json:
+              schema:
+                $ref: '#/components/schemas/StandardsDeltaBundle'
+      x-repository-artifact: true
+  /repository-governance/cross-domain-indicator-semantics/follow-up-map:
+    get:
+      summary: Review the bounded follow-up map
+      description: |
+        Logical artifact mapping ambiguous or risky cues to explicit later lanes.
+        V1 lanes are separated intentionally so the audit package does not imply
+        one broad runtime rewrite.
+      responses:
+        '200':
+          description: Follow-up map bundle available for review
+          content:
+            application/json:
+              schema:
+                $ref: '#/components/schemas/FollowUpMapBundle'
+      x-repository-artifact: true
+components:
+  schemas:
+    IndicatorInventoryBundle:
+      type: object
+      required:
+        - review_scope
+        - entries
+        - related_spec_guardrails
+      properties:
+        review_scope:
+          type: object
+          required:
+            - package
+            - standards_target
+            - bounded_domains
+          properties:
+            package:
+              type: string
+              example: specs/278-cross-domain-indicator-audit
+            standards_target:
+              type: string
+              example: docs/ui/tenantpilot-enterprise-ui-standards.md
+            bounded_domains:
+              type: array
+              items:
+                type: string
+        entries:
+          type: array
+          items:
+            $ref: '#/components/schemas/IndicatorInventoryEntry'
+        related_spec_guardrails:
+          type: array
+          items:
+            $ref: '#/components/schemas/RelatedSpecGuardrail'
+    IndicatorInventoryEntry:
+      type: object
+      required:
+        - entry_id
+        - source_anchor
+        - surface
+        - domain
+        - visible_cue
+        - visual_pattern
+        - data_source
+        - calculation_basis
+        - semantic_category
+        - determinism
+        - scope_mode
+        - likely_user_reading
+        - misunderstanding_risk
+        - disposition
+      properties:
+        entry_id:
+          type: string
+        source_anchor:
+          $ref: '#/components/schemas/IndicatorSourceAnchor'
+        surface:
+          type: string
+        domain:
+          type: string
+        visible_cue:
+          type: string
+        visual_pattern:
+          type: string
+        data_source:
+          type: string
+        calculation_basis:
+          type: string
+        semantic_category:
+          type: string
+          enum:
+            - execution progress
+            - activity state
+            - coverage
+            - completion
+            - health
+            - readiness
+            - risk
+            - pressure
+            - usage
+            - capacity
+            - score
+            - generation state
+            - unknown/ambiguous
+        determinism:
+          type: string
+          enum:
+            - determinate
+            - indeterminate
+            - unknown
+        scope_mode:
+          type: string
+          enum:
+            - tenant-prefiltered
+            - tenantless-aggregate
+            - workspace-aggregate
+            - supporting-context
+        audience_mode:
+          type: string
+          nullable: true
+          enum:
+            - customer-readable
+            - operator-msp
+            - support-platform
+            - mixed
+            - not-applicable
+        likely_user_reading:
+          type: string
+        misunderstanding_risk:
+          type: string
+        disposition:
+          type: string
+          enum:
+            - keep as-is
+            - copy-only clarification
+            - standards clarification
+            - product decision
+            - contract follow-up
+            - shared-component follow-up
+            - migration follow-up
+            - defer
+        follow_up_lane:
+          type: string
+          nullable: true
+          enum:
+            - standards patch lane
+            - metric/indicator contract foundation
+            - shared indicator component system
+            - quality gate lane
+            - domain migration lane
+        related_guardrails:
+          type: array
+          items:
+            type: string
+        notes:
+          type: string
+          nullable: true
+    IndicatorSourceAnchor:
+      type: object
+      required:
+        - repo_path
+        - source_type
+        - surface_name
+        - domain
+      properties:
+        repo_path:
+          type: string
+        source_type:
+          type: string
+          enum:
+            - standard
+            - spec
+            - presenter
+            - widget
+            - service
+            - builder
+            - blade
+            - other-code
+        surface_name:
+          type: string
+        domain:
+          type: string
+        route_context:
+          type: string
+          nullable: true
+        notes:
+          type: string
+          nullable: true
+    StandardsDeltaBundle:
+      type: object
+      required:
+        - target_doc
+        - rules
+      properties:
+        target_doc:
+          type: string
+          example: docs/ui/tenantpilot-enterprise-ui-standards.md
+        rules:
+          type: array
+          items:
+            $ref: '#/components/schemas/StandardsDeltaRule'
+    StandardsDeltaRule:
+      type: object
+      required:
+        - rule_id
+        - area
+        - current_gap
+        - proposed_guidance
+        - target_doc
+      properties:
+        rule_id:
+          type: string
+        area:
+          type: string
+          enum:
+            - allowed-categories
+            - determinate-progress
+            - freshness
+            - wording
+            - dashboard
+            - anti-pattern
+            - provider-boundary
+        current_gap:
+          type: string
+        proposed_guidance:
+          type: string
+        target_doc:
+          type: string
+        follow_up_lane:
+          type: string
+          nullable: true
+          enum:
+            - standards patch lane
+            - metric/indicator contract foundation
+            - shared indicator component system
+            - quality gate lane
+            - domain migration lane
+    FollowUpMapBundle:
+      type: object
+      required:
+        - lanes
+      properties:
+        lanes:
+          type: array
+          items:
+            $ref: '#/components/schemas/FollowUpLane'
+    FollowUpLane:
+      type: object
+      required:
+        - lane
+        - purpose
+        - out_of_scope_for_this_slice
+        - likely_repo_surfaces
+      properties:
+        lane:
+          type: string
+          enum:
+            - standards patch lane
+            - metric/indicator contract foundation
+            - shared indicator component system
+            - quality gate lane
+            - domain migration lane
+        purpose:
+          type: string
+        out_of_scope_for_this_slice:
+          type: boolean
+        trigger_cues:
+          type: array
+          items:
+            type: string
+        likely_repo_surfaces:
+          type: array
+          items:
+            type: string
+        seed_questions:
+          type: array
+          items:
+            type: string
+    RelatedSpecGuardrail:
+      type: object
+      required:
+        - spec_id
+        - relation
+        - note
+        - out_of_scope_for_this_slice
+      properties:
+        spec_id:
+          type: string
+        relation:
+          type: string
+          enum:
+            - context-only
+            - guardrail
+            - follow-up dependency
+        note:
+          type: string
+        out_of_scope_for_this_slice:
+          type: boolean
--- a/specs/278-cross-domain-indicator-audit/data-model.md
+++ b/specs/278-cross-domain-indicator-audit/data-model.md
@ -0,0 +1,205 @@
+# Data Model: Cross-Domain Progress Indicator Semantics Audit
+
+**Date**: 2026-05-06  
+**Branch**: `278-cross-domain-indicator-audit`
+
+## Overview
+
+This slice introduces no runtime persistence, no new application DTO layer, and no new state family. The package defines documentation-only audit artifacts over existing repo-real cues so later specs can build on one explicit inventory and standards delta.
+
+## Reused Source Truth
+
+### 1. Indicator Source Anchor
+
+**Persistence**: none, repo source reference only  
+**Owner**: current documentation and code seams already present in the monorepo
+
+| Field | Type | Required | Notes |
+|-------|------|----------|-------|
+| `repo_path` | string | yes | Absolute or repo-relative file path to the source seam |
+| `source_type` | string | yes | `standard`, `spec`, `presenter`, `widget`, `service`, `builder`, `blade`, or `other-code` |
+| `surface_name` | string | yes | Human-readable surface or seam name |
+| `domain` | string | yes | Ops, inventory, backup, review, baseline, provider posture, tenant summary, or similar |
+| `route_context` | string | no | Known current route or shell context when relevant |
+| `notes` | string | no | Why this anchor matters to the audit |
+
+**Behavior rules**:
+
+- Source anchors are audit evidence only in this slice.
+- Adding an anchor to the audit does not imply that the file will be changed.
+- The audit must capture enough anchors to explain the current cross-domain drift without widening into unrelated domains.
+
+### 2. Related Spec Guardrail
+
+**Persistence**: none, repo context only  
+**Owner**: current spec package
+
+| Field | Type | Required | Notes |
+|-------|------|----------|-------|
+| `spec_id` | string | yes | Existing adjacent spec number |
+| `relation` | string | yes | `context-only`, `guardrail`, or `follow-up dependency` |
+| `note` | string | yes | What the audit must preserve or avoid reopening |
+| `out_of_scope_for_this_slice` | boolean | yes | Always `true` for this package |
+
+**Required rows**:
+
+- `266`
+- `268`
+- `270`
+- `271`
+- `272`
+
+## Derived Audit Artifacts
+
+### 3. Indicator Inventory Entry
+
+**Persistence**: none, documentation artifact only  
+**Owner**: audit inventory bundle
+
+| Field | Type | Required | Notes |
+|-------|------|----------|-------|
+| `entry_id` | string | yes | Stable audit-local identifier |
+| `source_anchor_ref` | string | yes | Link to the source anchor entry |
+| `surface` | string | yes | The visible surface or seam where the cue appears |
+| `domain` | string | yes | Product domain owning the cue |
+| `visible_cue` | string | yes | Label, wording, or short description of the cue |
+| `visual_pattern` | string | yes | Badge, percentage, bar, KPI stat, helper text, summary row, empty-state signal, or similar |
+| `data_source` | string | yes | Current repo-real truth feeding the cue |
+| `calculation_basis` | string | yes | How the cue is currently derived, or `not explicit` when unclear |
+| `semantic_category` | string | yes | Exactly one allowed category from the list below |
+| `determinism` | string | yes | `determinate`, `indeterminate`, or `unknown` |
+| `scope_mode` | string | yes | `tenant-prefiltered`, `tenantless-aggregate`, `workspace-aggregate`, or `supporting-context` |
+| `audience_mode` | string | no | `customer-readable`, `operator-msp`, `support-platform`, `mixed`, or `not-applicable` |
+| `likely_user_reading` | string | yes | What an operator or reviewer is likely to infer from the cue |
+| `misunderstanding_risk` | string | yes | Risk note describing why the cue may mislead |
+| `disposition` | string | yes | Exactly one bounded recommendation from the disposition set below |
+| `follow_up_lane` | string | no | Required for every disposition except `keep as-is`; values come from the follow-up map lane set |
+| `related_guardrails` | array | no | Adjacent specs or standards rules that constrain follow-up work |
+| `notes` | string | no | Extra explanation or uncertainty |
+
+**Validation rules**:
+
+- One cue gets exactly one inventory entry unless the surface shows multiple visibly separate cues.
+- One inventory entry gets exactly one semantic category.
+- One inventory entry gets exactly one disposition.
+- `follow_up_lane` is required when `disposition` is anything other than `keep as-is`.
+- `unknown/ambiguous` is the fallback category when the current repo truth cannot support a more precise category safely.
+
+### 4. Semantic Category
+
+**Persistence**: none, documentation-only enum  
+**Owner**: audit vocabulary
+
+Allowed values:
+
+- `execution progress`
+- `activity state`
+- `coverage`
+- `completion`
+- `health`
+- `readiness`
+- `risk`
+- `pressure`
+- `usage`
+- `capacity`
+- `score`
+- `generation state`
+- `unknown/ambiguous`
+
+**Behavior rules**:
+
+- Categories are documentation-only in this slice and do not create new runtime state.
+- Categories must remain mutually exclusive at the cue level.
+- A visually similar pattern on two surfaces may map to different categories when the underlying truth differs.
+
+### 5. Recommendation Disposition
+
+**Persistence**: none, documentation-only enum  
+**Owner**: audit recommendation layer
+
+Allowed values:
+
+- `keep as-is`
+- `copy-only clarification`
+- `standards clarification`
+- `product decision`
+- `contract follow-up`
+- `shared-component follow-up`
+- `migration follow-up`
+- `defer`
+
+**Behavior rules**:
+
+- Dispositions describe the next bounded action, not the full implementation plan.
+- `keep as-is` is allowed only when the cue is already semantically honest.
+- `copy-only clarification` and `standards clarification` should normally route to the `standards patch lane`.
+- `contract follow-up`, `shared-component follow-up`, and `migration follow-up` must map to their matching follow-up lanes.
+
+### 6. Standards Delta Rule
+
+**Persistence**: none, documentation artifact only  
+**Owner**: standards-delta bundle
+
+| Field | Type | Required | Notes |
+|-------|------|----------|-------|
+| `rule_id` | string | yes | Stable rule identifier inside the audit package |
+| `area` | string | yes | `allowed-categories`, `determinate-progress`, `freshness`, `wording`, `dashboard`, `anti-pattern`, or `provider-boundary` |
+| `current_gap` | string | yes | What the current repo does not state clearly enough |
+| `proposed_guidance` | string | yes | Intended standards delta wording |
+| `target_doc` | string | yes | Expected future standards target, normally `docs/ui/tenantpilot-enterprise-ui-standards.md` |
+| `follow_up_lane` | string | no | Usually `standards patch lane`, but may point elsewhere when the gap cannot be solved by documentation alone |
+
+### 7. Follow-Up Map Entry
+
+**Persistence**: none, documentation artifact only  
+**Owner**: follow-up map bundle
+
+| Field | Type | Required | Notes |
+|-------|------|----------|-------|
+| `lane` | string | yes | One of the bounded lane names below |
+| `purpose` | string | yes | What this lane exists to solve |
+| `out_of_scope_for_this_slice` | boolean | yes | Always `true` in this package |
+| `trigger_cues` | array | yes | Inventory entries or cue families that justify the lane |
+| `likely_repo_surfaces` | array | yes | Docs or code anchors the later spec will probably need |
+| `seed_questions` | array | no | Questions the later spec must answer before implementation |
+
+**Required lane values**:
+
+- `standards patch lane`
+- `metric/indicator contract foundation`
+- `shared indicator component system`
+- `quality gate lane`
+- `domain migration lane`
+
+### 8. Audit Bundle
+
+**Persistence**: none, documentation artifact only  
+**Owner**: current spec package
+
+| Field | Type | Required | Notes |
+|-------|------|----------|-------|
+| `inventory` | array | yes | List of `Indicator Inventory Entry` objects |
+| `standards_delta` | array | yes | List of `Standards Delta Rule` objects |
+| `follow_up_map` | array | yes | List of `Follow-Up Map Entry` objects |
+| `related_spec_guardrails` | array | yes | Context-only guardrails from existing adjacent specs |
+| `review_outcome_class` | string | yes | Current prep convention outcome class |
+| `workflow_outcome` | string | yes | Current prep convention workflow outcome |
+| `test_governance_outcome` | string | yes | Current prep convention test-governance outcome |
+
+## Derived Rules
+
+| Rule | Derived Behavior |
+|------|------------------|
+| One cue, one meaning | Every visible cue must map to exactly one semantic category |
+| One cue, one next action | Every visible cue must map to exactly one disposition |
+| Scope is first-class | Every cue must record whether it looks tenant-prefiltered, tenantless aggregate, workspace aggregate, or only supporting context |
+| Ambiguity is explicit | Unknown denominator, freshness, or scope becomes risk documentation, not a guessed category |
+| Follow-up work stays separate | Contract, component, quality-gate, and migration work remain distinct later lanes |
+| Audit outputs stay docs-only | No runtime table, code path, or presenter becomes part of this slice |
+
+## Boundaries Explicitly Preserved
+
+- No new runtime source of truth is introduced.
+- No shared runtime contract, component, migration, chart, or score engine is introduced.
+- No existing presenter, widget, service, or Blade surface is rewritten in this slice.
+- Product backlog docs may be referenced by the follow-up map, but the audit bundle itself remains the primary output.
--- a/specs/278-cross-domain-indicator-audit/follow-up-map.md
+++ b/specs/278-cross-domain-indicator-audit/follow-up-map.md
@ -0,0 +1,123 @@
+# 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.
--- a/specs/278-cross-domain-indicator-audit/inventory.md
+++ b/specs/278-cross-domain-indicator-audit/inventory.md
@ -0,0 +1,130 @@
+# Indicator Inventory: Cross-Domain Progress Indicator Semantics Audit
+
+**Package**: `specs/278-cross-domain-indicator-audit/`  
+**Branch**: `278-cross-domain-indicator-audit`  
+**Status**: Implemented docs-only audit artifact  
+**Last updated**: 2026-05-06
+
+## Scope And Method
+
+This inventory is repository evidence only. It does not change runtime code, routes, assets, authorization, tests, persisted state, or UI behavior.
+
+The audit used the named source anchors from `spec.md` and `plan.md`, then ran bounded searches under `apps/platform/app/`, `apps/platform/resources/views/filament/`, and the already-mounted `apps/platform/resources/views/livewire/` operation feedback view for current progress-like, readiness-like, health-like, score-like, coverage-like, usage/capacity, and generation-state cues.
+
+### Confirmed Source Anchors
+
+| Anchor | Source type | Surface | Domain | Route or shell context | Notes |
+|---|---:|---|---|---|---|
+| `apps/platform/app/Support/OpsUx/OperationUxPresenter.php` | presenter | OperationRun feedback copy | Ops | `/admin/t/{tenant}` shell feedback, `/admin/operations`, run detail | Defines queued, active, stale, terminal, and next-step wording. |
+| `apps/platform/app/Support/OpsUx/OperationRunProgressContract.php` | presenter | OperationRun progress contract | Ops | active shell feedback and run consumers | Defines counted vs activity/phased/composite/none progress capability. |
+| `apps/platform/resources/views/livewire/bulk-operation-progress.blade.php` | blade | In-shell operation activity banner | Ops | tenant panel shell | Renders determinate and indeterminate operation progress/activity feedback. |
+| `apps/platform/app/Filament/Widgets/Inventory/InventoryKpiHeader.php` | widget | Inventory KPI header | Inventory | tenant inventory/dashboard context | Renders total items, covered types, follow-up, coverage basis, and active ops. |
+| `apps/platform/app/Filament/Widgets/Dashboard/RecoveryReadiness.php` | widget | Recovery readiness widget | Backup/restore | tenant dashboard | Renders backup posture and recovery evidence cards. |
+| `apps/platform/app/Services/Baselines/SnapshotRendering/BaselineSnapshotPresenter.php` | service | Baseline snapshot detail rendering | Baseline | baseline snapshot detail | Renders outcome, fidelity, gap, coverage, lifecycle, current-truth, and count summaries. |
+| `apps/platform/app/Services/ReviewPackService.php` | service | Review pack generation and entitlement decision | Review/export | tenant review pack flows | Supplies generation-state and usage/capacity input. |
+| `apps/platform/app/Support/TenantDashboard/TenantDashboardSummaryBuilder.php` | builder | Tenant dashboard overview | Tenant summary | `/admin/t/{tenant}` | Builds posture, KPIs, governance rows, readiness cards, and recent operations. |
+| `apps/platform/resources/views/filament/widgets/dashboard/tenant-dashboard-overview.blade.php` | blade | Tenant dashboard overview | Tenant summary | `/admin/t/{tenant}` | Renders dashboard badges, progress bars, KPI charts, and readiness cards. |
+| `apps/platform/resources/views/filament/widgets/tenant/tenant-review-pack-card.blade.php` | blade | Review pack card | Review/export | tenant dashboard/review context | Renders no-pack, queued/generating, ready, failed, and expired states. |
+| `apps/platform/resources/views/filament/widgets/workspace/workspace-needs-attention.blade.php` | blade | Workspace needs-attention widget | Workspace monitoring | `/admin` workspace context | Renders triage review progress and pressure links. |
+| `apps/platform/resources/views/filament/widgets/dashboard/baseline-compare-now.blade.php` | blade | Baseline governance widget | Baseline compare | tenant dashboard | Renders summary-state badges and finding-count cues. |
+| `apps/platform/app/Filament/Pages/BaselineCompareLanding.php` | page | Baseline compare landing | Baseline compare | `/admin/t/{tenant}/baseline-compare` | Carries coverage, gap, freshness, and summary-assessment truth into Blade. |
+| `apps/platform/app/Filament/Resources/EvidenceSnapshotResource.php` | resource | Evidence snapshot detail | Evidence | tenant evidence snapshots | Renders permission posture score and evidence completeness/generation state. |
+| `apps/platform/app/Filament/Resources/StoredReportResource.php` | resource | Stored report detail | Reports | tenant stored reports | Renders retained report lifecycle and permission posture score. |
+| `apps/platform/app/Filament/Resources/ProviderConnectionResource.php` | resource | Provider connection list/detail | Provider posture | `/admin/provider-connections` | Renders provider lifecycle, consent, verification, and last health check. |
+| `apps/platform/resources/views/filament/forms/components/restore-run-checks.blade.php` | blade | Restore safety checks | Restore | restore run form/detail | Renders safety, technical startability, and check-count badges. |
+| `apps/platform/resources/views/filament/forms/components/restore-run-preview.blade.php` | blade | Restore preview | Restore | restore run form/detail | Renders preview decision, readiness suppression, and changed-item counters. |
+
+### Related Spec Guardrails
+
+| Spec | Relation | Out of scope here | Guardrail |
+|---:|---|---:|---|
+| `266` | context-only | yes | Tenant dashboard productization remains runtime owner for dashboard layout and action behavior. |
+| `268` | context-only guardrail | yes | OperationRun activity feedback already owns shell activity behavior. This audit only classifies it. |
+| `270` | context-only guardrail | yes | OperationRun progress contract remains the execution-progress authority. |
+| `271` | context-only guardrail | yes | Counted progress rollout remains a separate runtime adoption lane. |
+| `272` | context-only guardrail | yes | Phase/composite OperationRun progress remains separate from this cross-domain audit. |
+| `275` | nearby context | yes | Localization/customer-safe review wording is context only. No translation catalog changes are made here. |
+| `277` | nearby context | yes | Stored reports are audited as current indicator surfaces; stored-report runtime behavior is not reopened. |
+
+### Search Boundary And Exclusions
+
+Confirmed additional in-scope search hits were included when they represented execution progress, coverage, completion, health, readiness, risk, pressure, usage, capacity, score, or generation state on tenant, workspace, canonical operations, evidence, review/export, provider, restore, or baseline surfaces.
+
+Excluded search hits:
+
+- console-only progress bars in Artisan commands, because they are not operator-facing product surfaces
+- generic CRUD lifecycle badges with no progress/indicator ambiguity beyond ordinary table state
+- diff row status badges, because they are direct diff semantics rather than cross-domain progress or readiness indicators
+- platform `/system` customer-health widgets, because this active spec scope is workspace + tenant + canonical-view and not a platform-plane health-score rollout
+- raw support diagnostic fields where the visible surface explicitly states diagnostics-only context and not operator progress/readiness
+
+## Inventory Entries
+
+Allowed semantic categories: `execution progress`, `activity state`, `coverage`, `completion`, `health`, `readiness`, `risk`, `pressure`, `usage`, `capacity`, `score`, `generation state`, `unknown/ambiguous`.
+
+Allowed dispositions: `keep as-is`, `copy-only clarification`, `standards clarification`, `product decision`, `contract follow-up`, `shared-component follow-up`, `migration follow-up`, `defer`.
+
+| ID | Source | Surface / Domain | Visible cue and pattern | Data source and calculation basis | Category | Determinism | Scope / audience | Likely reading and risk | Disposition / lane |
+|---|---|---|---|---|---|---|---|---|---|
+| IND-001 | `OperationRunProgressContract.php`; `bulk-operation-progress.blade.php` | Operation activity banner / Ops | `processed / total (percent)` with `role="progressbar"` | `OperationRun.summary_counts.processed` and `summary_counts.total`, normalized and clamped by `OperationRunProgressContract::forRun()` | execution progress | determinate | tenant-prefiltered / operator-msp | Correctly reads as active execution progress when the run is active. Risk is low because terminal and queued runs are excluded from counted progress by the shared contract. | keep as-is |
+| IND-002 | `OperationRunProgressContract.php`; `bulk-operation-progress.blade.php` | Operation activity banner / Ops | Indeterminate bar plus labels such as `Waiting for worker.` or `Progress details pending.` | `OperationRun.status`, run activity, phase/composite hints; no percent is emitted | activity state | indeterminate | tenant-prefiltered / operator-msp | The moving/bar-like pattern can still be mistaken for percentage progress even though it is activity-only. | standards clarification / standards patch lane |
+| IND-003 | `OperationUxPresenter.php`; `bulk-operation-progress.blade.php` | Operation activity banner / Ops | Status pill labels such as `Queued for execution`, `In progress`, `Completed successfully`, `Blocked by prerequisite` | `OperationStatusNormalizer::toUxStatus($status, $outcome)` and terminal guidance from `OperationUxPresenter` | activity state | determinate | tenant-prefiltered / operator-msp | Reads as operation lifecycle state. Risk appears when terminal success and active progress are visually adjacent, but current code separates progress rendering from terminal runs. | keep as-is |
+| IND-004 | `TenantDashboardSummaryBuilder.php`; `tenant-dashboard-overview.blade.php` | Recent operations / Tenant dashboard | Separate operation status and outcome badges in recent-operation rows | `OperationRun.status`, `OperationRun.outcome`, and freshness state through `BadgeRenderer` | completion | determinate | tenant-prefiltered / operator-msp | Reads as run outcome or terminal follow-up. Risk is low if status and outcome remain distinct. | keep as-is |
+| IND-005 | `InventoryKpiHeader.php` | Inventory KPI header / Inventory | `Total items` stat count | `TenantCoverageTruth.observedItemTotal`; direct observed inventory item count | coverage | determinate | tenant-prefiltered / operator-msp | Can be read as tenant inventory completeness, but it only measures observed items across supported types. | standards clarification / standards patch lane |
+| IND-006 | `InventoryKpiHeader.php` | Inventory KPI header / Inventory | `Covered types` as `succeeded / supported` with breakdown badges | `TenantCoverageTruth.succeededTypeCount`, `supportedTypeCount`, failed/skipped/unknown breakdown | coverage | determinate | tenant-prefiltered / operator-msp | Reads as coverage, not execution progress. Missing or unknown types can make the denominator look more complete than the underlying basis. | contract follow-up / metric/indicator contract foundation |
+| IND-007 | `InventoryKpiHeader.php` | Inventory KPI header / Inventory | `Need follow-up` stat and top-priority follow-up summary | `TenantCoverageTruth.followUpTypeCount` and `topPriorityFollowUpRow()` | pressure | determinate | tenant-prefiltered / operator-msp | Reads as operational pressure. Risk is that `0` can be mistaken for overall tenant health when the coverage basis is missing or stale. | standards clarification / standards patch lane |
+| IND-008 | `InventoryKpiHeader.php` | Inventory KPI header / Inventory | `Coverage basis` value `No current result`, completion timestamp, and run outcome badge | `TenantCoverageTruth.basisRun`, basis completion timestamp, `OperationRun.outcome` badge | coverage | unknown | tenant-prefiltered / operator-msp | `No current result` can read as calm/zero result instead of missing basis truth. | copy-only clarification / standards patch lane |
+| IND-009 | `InventoryKpiHeader.php` | Inventory KPI header / Inventory/Ops | `Active ops` count plus `queued or running` description | `ActiveRuns::countForTenantId()` and inventory-sync active query | activity state | determinate | tenant-prefiltered / operator-msp | Reads as active execution activity, but only inventory sync is described in the helper line. | standards clarification / standards patch lane |
+| IND-010 | `RecoveryReadiness.php`; `recovery-readiness.blade.php` | Recovery readiness widget / Backup | `Backup posture` card with colored value and description | `TenantBackupHealthResolver::assess()` and `TenantRecoveryTriagePresentation` label/tone/description | health | determinate | tenant-prefiltered / operator-msp | Reads as backup health/posture, not restore execution progress. Risk is that posture and recovery readiness share one card language. | contract follow-up / metric/indicator contract foundation |
+| IND-011 | `RecoveryReadiness.php`; `recovery-readiness.blade.php` | Recovery readiness widget / Restore | `Recovery evidence` card with colored value and description | `RestoreSafetyResolver::dashboardRecoveryEvidence()` and recovery presentation helpers | readiness | unknown | tenant-prefiltered / operator-msp | Can read as complete restore readiness even when evidence history is absent or latest detail is unavailable. | standards clarification / standards patch lane |
+| IND-012 | `BaselineSnapshotPresenter.php` | Baseline snapshot detail / Baseline | `Outcome`, `Current truth`, `Lifecycle`, `Overall fidelity`, `Evidence gaps`, `Captured items` badges/facts | `ArtifactTruthPresenter`, snapshot lifecycle state, `RenderedSnapshot` groups, fidelity counts, gap summary | coverage | determinate | workspace-aggregate / operator-msp | Reads as baseline snapshot usability and coverage. Risk is multiple badges can look like duplicate status instead of distinct truth dimensions. | contract follow-up / metric/indicator contract foundation |
+| IND-013 | `BaselineSnapshotPresenter.php` | Baseline snapshot coverage sections / Baseline | `Coverage summary`, per-type `coverageHint`, `fidelitySummary` | `FidelityState::aggregate()`, `GapSummary`, per-type rendered snapshot groups | coverage | determinate | workspace-aggregate / operator-msp | Reads as governed-subject coverage/fidelity. Risk is that reference-only fidelity can look like complete evidence if the coverage hint is not read. | standards clarification / standards patch lane |
+| IND-014 | `ReviewPackService.php` | Review-pack entitlement decision / Review/export | `current_usage`, `remaining_capacity`, and `effective_value` returned with generation decision | `WorkspaceCommercialLifecycleResolver::actionDecision()` plus entitlement decision projection | usage | determinate | workspace-aggregate / operator-msp | Reads as plan usage/capacity, not generation readiness. Risk is hidden if later surfaced beside generation buttons without category/freshness. | contract follow-up / metric/indicator contract foundation |
+| IND-015 | `tenant-review-pack-card.blade.php`; `ReviewPackService.php` | Review pack card / Review/export | `Queued`, `Generating`, `Ready`, `Failed`, `Expired`, `Generation in progress...` | `ReviewPack.status`, status badge catalog, generation job/run state via service-created `OperationRun` | generation state | determinate | tenant-prefiltered / operator-msp | Reads as artifact generation state. Risk is low when it stays separate from operation execution progress. | keep as-is |
+| IND-016 | `TenantDashboardSummaryBuilder.php`; `tenant-dashboard-overview.blade.php` | Tenant dashboard top posture / Tenant summary | `Blocked`, `Action needed`, `Calm` posture status and headline | Required permission counts, governance aggregate state, backup posture, recovery evidence, recommended actions | readiness | determinate | tenant-prefiltered / mixed | Reads as whole-tenant readiness. Risk is that a single calm/action label can collapse provider permissions, findings, backup, recovery, and operations into one ambiguous health claim. | contract follow-up / metric/indicator contract foundation |
+| IND-017 | `TenantDashboardSummaryBuilder.php`; `tenant-dashboard-overview.blade.php` | Tenant dashboard KPI row / Findings | `High severity findings` count and optional 7-day chart | Active high/critical findings count and `highSeverityFindingsChart()` | risk | determinate | tenant-prefiltered / operator-msp | Reads as active risk pressure. The small chart can look like trend health rather than event count unless category/direction is explicit. | shared-component follow-up / shared indicator component system |
+| IND-018 | `TenantDashboardSummaryBuilder.php`; `tenant-dashboard-overview.blade.php` | Tenant dashboard KPI row / Findings | `Overdue findings` count | `TenantGovernanceAggregate.overdueOpenFindingsCount` | pressure | determinate | tenant-prefiltered / operator-msp | Reads as workflow pressure, not completion. `0` can look like tenant health if other inputs are missing. | standards clarification / standards patch lane |
+| IND-019 | `TenantDashboardSummaryBuilder.php`; `tenant-dashboard-overview.blade.php` | Tenant dashboard KPI row / Provider permissions | `Missing permissions` count with app/delegated split | Required permissions overview counts from `TenantRequiredPermissionsViewModelBuilder` | risk | determinate | tenant-prefiltered / operator-msp | Reads as provider permission risk. Provider-owned semantics must not become platform-core readiness truth. | contract follow-up / metric/indicator contract foundation |
+| IND-020 | `TenantDashboardSummaryBuilder.php`; `tenant-dashboard-overview.blade.php` | Tenant dashboard KPI row / Operations | `Active operations` count, but value is stale or terminal runs needing follow-up | `OperationRun::dashboardNeedsFollowUp()`, `terminalFollowUp()`, `activeStaleAttention()` | unknown/ambiguous | determinate | tenant-prefiltered / operator-msp | The label reads like active execution count, while the query measures follow-up pressure. This is a confirmed wording ambiguity. | copy-only clarification / standards patch lane |
+| IND-021 | `TenantDashboardSummaryBuilder.php`; `tenant-dashboard-overview.blade.php`; `baseline-compare-now.blade.php` | Governance status / Baseline compare | Baseline compare headline/state badge such as `Aligned`, `Needs review`, `Refresh recommended`, `Action required`, `In progress` | `TenantGovernanceAggregate`, `BaselineCompareSummaryAssessment`, and latest compare stats | readiness | determinate | tenant-prefiltered / operator-msp | Reads as baseline readiness/posture. `In progress` must remain activity state, while aligned/needs review are governance results. | contract follow-up / metric/indicator contract foundation |
+| IND-022 | `TenantDashboardSummaryBuilder.php`; `BaselineCompareLanding.php` | Governance status / Evidence coverage | `Evidence coverage` value and coverage warning badge/section | Latest `EvidenceSnapshot.completeness_state`, baseline compare `coverageStatus`, uncovered types, evidence gap counts | coverage | unknown | tenant-prefiltered / mixed | Can read as complete evidence coverage even when latest compare coverage is unproven, warning, stale, or gap-limited. | standards clarification / standards patch lane |
+| IND-023 | `TenantDashboardSummaryBuilder.php` | Governance status / Review freshness | `Review freshness` value and timestamp description | Latest `TenantReview.status`, published/generated/updated timestamps | readiness | unknown | tenant-prefiltered / mixed | Reads as current review readiness. Risk is that status and freshness are mixed without a dedicated stale-data contract. | contract follow-up / metric/indicator contract foundation |
+| IND-024 | `TenantDashboardSummaryBuilder.php` | Governance status / Provider permissions | `Provider permissions` as `Ready`, `Blocked`, or `Needs attention` | Required permissions overview `overall`, missing counts, freshness | risk | unknown | tenant-prefiltered / operator-msp | Reads as provider readiness. Risk is stale permission snapshots can make the state look current. | contract follow-up / metric/indicator contract foundation |
+| IND-025 | `TenantDashboardSummaryBuilder.php`; `RecoveryReadiness.php` | Governance status / Backup posture | `Backup posture` value and tone | `TenantBackupHealthAssessment` posture, recovery triage copy | health | unknown | tenant-prefiltered / operator-msp | Reads as backup health. Risk is health/posture can be mistaken for restore readiness or successful backup execution. | standards clarification / standards patch lane |
+| IND-026 | `TenantDashboardSummaryBuilder.php`; `tenant-dashboard-overview.blade.php` | Readiness card / Current review | `Findings with outcome` progress bar and `Review completion` progress bar | `TenantReview.summary.finding_count`, `finding_report_buckets`, `section_count`, `section_state_counts`; percent from `current / total` | completion | determinate | tenant-prefiltered / mixed | Correctly reads as review completion, not execution progress. Risk is customer-safe readers may treat review completion as evidence completeness. | shared-component follow-up / shared indicator component system |
+| IND-027 | `TenantDashboardSummaryBuilder.php`; `tenant-dashboard-overview.blade.php` | Readiness card / Risk exceptions | `Need action`, `Accepted risks`, `Expiring soon`, `Pending approval` stats | Tenant-scoped `FindingException` status counts plus governance aggregate lapsed/expiring counts | risk | determinate | tenant-prefiltered / operator-msp | Reads as risk-governance pressure. It should not be displayed as progress toward safety. | standards clarification / standards patch lane |
+| IND-028 | `TenantDashboardSummaryBuilder.php`; `tenant-dashboard-overview.blade.php`; `ProviderConnectionResource.php` | Readiness card / Provider Health | Provider verification status, missing permission count, last check, permissions snapshot | `ProviderConnection.verification_status`, `last_health_check_at`, required-permissions freshness/counts | health | unknown | tenant-prefiltered / operator-msp | Provider-owned health can be mistaken for platform-core health if it is not labeled as provider-specific. | contract follow-up / metric/indicator contract foundation |
+| IND-029 | `TenantDashboardSummaryBuilder.php`; `tenant-dashboard-overview.blade.php`; `tenant-review-pack-card.blade.php` | Readiness card / Customer-safe output | Review pack or evidence availability status, evidence snapshot time, review pack generated time | Latest `ReviewPack.status`, `ReviewPack.generated_at`, latest `EvidenceSnapshot.generated_at` | generation state | unknown | tenant-prefiltered / customer-readable | Reads as handoff/export readiness. Risk is evidence availability can be mistaken for a generated customer-safe package. | copy-only clarification / standards patch lane |
+| IND-030 | `workspace-needs-attention.blade.php` | Workspace needs attention / Triage | `Reviewed x/y`, `Follow-up needed`, `Changed since review`, `Current affected set` | `triageReviewProgress` affected-total and review-state counts | completion | determinate | workspace-aggregate / operator-msp | Reads as review completion over a dynamic affected set. Risk is denominator freshness and scope can shift between reviews. | product decision / metric/indicator contract foundation |
+| IND-031 | `EvidenceSnapshotResource.php` | Evidence snapshot permission posture / Evidence | `Posture score` plus granted/required permission counts | Stored permission-posture payload fields `posture_score`, `required_count`, `granted_count` | score | unknown | tenant-prefiltered / operator-msp | Score direction, scale, and freshness are not self-describing in the current summary. | contract follow-up / metric/indicator contract foundation |
+| IND-032 | `StoredReportResource.php` | Stored report detail / Reports | `Posture score`, `Required`, `Granted`, `Missing` highlights | `StoredReport.payload` permission-posture report fields | score | unknown | tenant-prefiltered / operator-msp | Same score can be read as success percentage or risk score without category/direction. | contract follow-up / metric/indicator contract foundation |
+| IND-033 | `ProviderConnectionResource.php` | Provider connection list/detail / Provider posture | `Lifecycle`, `Consent`, `Verification`, `Last check` badges and freshness | `ProviderConnection.is_enabled`, `consent_status`, `verification_status`, `last_health_check_at` | health | unknown | workspace-aggregate / support-platform | Reads as provider connection health. Provider-specific labels such as `Healthy` must stay provider-owned examples, not platform-core truth. | standards clarification / standards patch lane |
+| IND-034 | `tenant-verification-report.blade.php` | Tenant verification report / Provider posture | `Verification is currently in progress` and operation link | Stored latest provider verification `OperationRun` state and report availability | activity state | indeterminate | tenant-prefiltered / operator-msp | Reads as verification activity, not permission posture completion. Risk is low because copy says stored operation state. | keep as-is |
+| IND-035 | `restore-run-checks.blade.php` | Restore safety checks / Restore | `Safety checks`, `Technically startable` / `Technical blocker present`, `Ready`, `Ready with caution`, blocking/warning/safe counts | Restore run check integrity, execution readiness, safety assessment, check severity counts | readiness | determinate | tenant-prefiltered / operator-msp | Reads as execution readiness and safety proof. Risk is `Ready` can be mistaken for safe to execute without preview context. | standards clarification / standards patch lane |
+| IND-036 | `restore-run-preview.blade.php` | Restore preview / Restore | Preview decision, `Checks current`, `Calm readiness suppressed`, `x/y policies changed`, assignment/scope-tag change counts | Preview integrity, checks integrity, safety assessment, restore preview summary counts | risk | determinate | tenant-prefiltered / operator-msp | Reads as preview impact and readiness suppression, not operation progress. `x/y policies changed` uses a ratio but measures impact, not completion. | standards clarification / standards patch lane |
+| IND-037 | `BaselineCompareLanding.php`; `baseline-compare-landing.blade.php` | Baseline compare landing / Baseline | Coverage warning badges/sections, evidence gap counts, `No findings` explanation | `BaselineCompareStats.coverageStatus`, evidence-gap details, reason presenter | coverage | unknown | tenant-prefiltered / operator-msp | `No findings` can be misread as success when coverage warnings or evidence gaps exist. | copy-only clarification / standards patch lane |
+| IND-038 | `OperationRunResource.php`; `inventory-coverage-truth.blade.php` | Operation run detail / Inventory coverage | Inventory sync coverage rows and succeeded/failed/skipped type counts | `OperationRun.inventoryCoverage()` rows and computed counts | coverage | determinate | canonical-view / operator-msp | Reads as result coverage for an operation run, not live progress. Risk is outcome counters can be mistaken for progress if reused outside detail context. | standards clarification / standards patch lane |
+
+## Summary Matrix
+
+| Category | Entries | Primary risk |
+|---|---:|---|
+| execution progress | 1 | Must remain limited to active runs with trustworthy processed/total truth. |
+| activity state | 4 | Indeterminate bars and `in progress` labels can look like completion progress. |
+| coverage | 8 | Missing, stale, or partial basis can be read as complete coverage. |
+| completion | 3 | Review completion can be mistaken for evidence completeness or customer readiness. |
+| health | 4 | Provider or backup-specific health can leak into platform-core health language. |
+| readiness | 5 | Rollups can collapse safety, evidence, workflow, and provider readiness. |
+| risk | 5 | Risk and preview-impact indicators can look like progress or success. |
+| pressure | 2 | `0` pressure can look like global health when source data is missing. |
+| usage | 1 | Usage/capacity can look like readiness when shown beside generation actions. |
+| capacity | 0 | Capacity appears paired with usage in `IND-014`; no standalone capacity cue was confirmed. |
+| score | 2 | Score direction/scale/freshness is not self-describing. |
+| generation state | 2 | Evidence availability and generated package readiness can blur. |
+| unknown/ambiguous | 1 | `Active operations` currently labels a follow-up-pressure count. |
+
+## Review Outcome
+
+- The inventory covers every named source anchor and the confirmed additional in-scope cues discovered by bounded repo search.
+- No application code, tests, migrations, routes, assets, provider registration, panel wiring, global search, or authorization behavior was changed.
+- Runtime remediation remains out of scope. Every non-`keep as-is` cue routes to exactly one bounded follow-up lane in `follow-up-map.md`.
--- a/specs/278-cross-domain-indicator-audit/plan.md
+++ b/specs/278-cross-domain-indicator-audit/plan.md
@ -0,0 +1,263 @@
+# Implementation Plan: Cross-Domain Progress Indicator Semantics Audit
+
+**Branch**: `278-cross-domain-indicator-audit` | **Date**: 2026-05-06 | **Spec**: [spec.md](./spec.md)
+**Input**: Feature specification from `specs/278-cross-domain-indicator-audit/spec.md`
+
+## Summary
+
+Prepare one repo-governance audit bundle over the product's existing progress-like and indicator-like cues. The narrow implementation path is to inventory current cues from the named repo anchors plus bounded repo search, classify each cue once, record misunderstanding risk and one bounded disposition, derive standards-delta input for `docs/ui/tenantpilot-enterprise-ui-standards.md`, and map later follow-up work into explicit separate lanes. This slice remains documentation-only. It must not widen into runtime contracts, shared indicator components, quality-gate code, migrations, analytics, charting, score recalculation, or UI rewrites.
+
+Filament remains v5 on Livewire v4, no panel or provider registration change is planned (`apps/platform/bootstrap/providers.php` remains authoritative), no globally searchable resource changes are involved, no destructive actions are introduced, and no asset registration or `filament:assets` deployment work is expected.
+
+## Inherited Baseline / Explicit Delta
+
+### Inherited baseline
+
+- The current UI standard already defines a progress-bar pattern and anti-fake-progress posture.
+- Specs `268`, `270`, `271`, and `272` already own OperationRun activity and progress semantics and remain context-only guardrails.
+- `docs/product/spec-candidates.md` and `docs/product/roadmap.md` already define the candidate queue and roadmap posture for this manual promotion.
+- The named runtime anchors already express domain-local truth for execution progress, readiness, coverage, review/export generation, and dashboard summary cues.
+
+### Explicit delta in this plan
+
+- create one docs-only indicator inventory schema
+- create one docs-only risk, disposition, and follow-up-lane map
+- create one standards-delta contract targeted at `docs/ui/tenantpilot-enterprise-ui-standards.md`
+- keep later follow-up work split into separate candidates or specs for the standards patch lane, metric/indicator contract foundation, shared indicator component system, quality gate lane, and domain migration lane
+- keep all runtime code, tests, routes, assets, and provider wiring out of scope
+
+## Technical Context
+
+**Language/Version**: Markdown and YAML planning artifacts over PHP 8.4 / Laravel 12 source anchors  
+**Primary Dependencies**: `spec.md`, `docs/product/spec-candidates.md`, `docs/product/roadmap.md`, `docs/ui/tenantpilot-enterprise-ui-standards.md`, nearby Specs `270`, `275`, and `277`, and repo-real source anchors such as `OperationUxPresenter`, `InventoryKpiHeader`, `RecoveryReadiness`, `BaselineSnapshotPresenter`, `ReviewPackService`, and `TenantDashboardSummaryBuilder`  
+**Storage**: Repository files only; no database or runtime persistence changes  
+**Testing**: Docs/governance review plus focused diff and grep validation; no runtime test lane  
+**Validation Lanes**: review, diff-check, grep lane-check  
+**Target Platform**: Repo-based prep package under `specs/278-cross-domain-indicator-audit/` inside the existing Laravel monorepo  
+**Project Type**: Documentation/governance prep package  
+**Performance Goals**: reviewers can validate the audit bundle without running the app, and follow-up spec authors do not need to repeat cross-repo discovery  
+**Constraints**: no app code changes, no test changes, no migrations, no runtime presenter or component rollout, no analytics or charting, no score recalculation, no domain migration, and no asset, panel, or global-search change  
+**Scale/Scope**: one indicator vocabulary, one inventory bundle, one standards-delta bundle, one follow-up map, and one checklist or review outcome set spanning existing operations, dashboard, baseline, review, export, and provider or posture cues only
+
+## Likely Affected Repo Surfaces
+
+### Prep-package and documentation targets
+
+- `specs/278-cross-domain-indicator-audit/spec.md`
+- `specs/278-cross-domain-indicator-audit/plan.md`
+- `specs/278-cross-domain-indicator-audit/research.md`
+- `specs/278-cross-domain-indicator-audit/data-model.md`
+- `specs/278-cross-domain-indicator-audit/quickstart.md`
+- `specs/278-cross-domain-indicator-audit/contracts/cross-domain-indicator-audit.logical.openapi.yaml`
+- `specs/278-cross-domain-indicator-audit/checklists/requirements.md`
+- `docs/ui/tenantpilot-enterprise-ui-standards.md` as the standards-delta destination
+- `docs/product/spec-candidates.md` as the follow-up-candidate sync point for the bounded lanes
+- `docs/product/roadmap.md` as the sequencing reference for the follow-up map posture
+
+### Repo-real source anchors to inventory, not rewrite in this slice
+
+- `apps/platform/app/Support/OpsUx/OperationUxPresenter.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/Services/ReviewPackService.php`
+- `apps/platform/app/Support/TenantDashboard/TenantDashboardSummaryBuilder.php`
+- related Blade, widget, or view seams discovered through repo search during the later docs implementation, but still treated as audit inputs only
+
+## Filament v5 / Panel Notes
+
+- **Livewire v4.0+ compliance**: This prep package introduces no runtime Filament or Livewire behavior. Future docs-only implementation of the audit remains compatible with the current Filament v5 + Livewire v4 baseline.
+- **Provider registration location**: No provider or panel registration change is planned. `apps/platform/bootstrap/providers.php` remains authoritative.
+- **Global search**: No resource or search behavior changes are in scope. This slice must not add, remove, or alter globally searchable resources.
+- **Destructive actions**: None. The audit produces repository artifacts only and must not introduce any action surface.
+- **Asset strategy**: No new asset registration or on-demand loading is planned. Deployment remains unchanged; if later unrelated work registers assets, the normal `cd apps/platform && php artisan filament:assets` path still applies, but not because of this slice.
+
+## Indicator Semantics Audit Fit
+
+- Treat the current repo as the only source corpus. Named presenters, widgets, services, docs, and adjacent specs are evidence, not implementation targets.
+- Keep the audit vocabulary documentation-only in this slice. Each cue gets exactly one semantic category, one misunderstanding-risk note, and one bounded disposition.
+- Record scope and audience assumptions per cue so future work cannot hide tenant or workspace leakage behind neutral-looking indicators.
+- Treat provider-health and permission-posture cues as provider-owned examples inside a neutral platform vocabulary, not as platform-core default semantics.
+- Route unresolved cases to separate follow-up specs rather than ad hoc local fixes.
+
+## UI / Surface Guardrail Plan
+
+- **Guardrail scope**: no operator-facing surface change
+- **Native vs custom classification summary**: `N/A` - this slice does not implement UI
+- **Shared-family relevance**: progress and activity feedback, dashboard signals and cards, KPI rows, readiness blocks, review and evidence summaries, and generation-state cues as audit inputs
+- **State layers in scope**: none
+- **Audience modes in scope**: `N/A` at runtime; captured as audit metadata only
+- **Decision/diagnostic/raw hierarchy plan**: `N/A` - current surfaces are documented, not changed
+- **Raw/support gating plan**: `N/A`
+- **One-primary-action / duplicate-truth control**: the audit may name duplicate-truth risks, but it must not change runtime action hierarchy in this slice
+- **Handling modes by drift class or surface**: report-only now; later runtime adoption becomes review-mandatory per follow-up spec
+- **Repository-signal treatment**: review-mandatory
+- **Special surface test profiles**: `N/A`
+- **Required tests or manual smoke**: `N/A`
+- **Exception path and spread control**: any attempt to add runtime components, presenters, migrations, or UI rewrites resolves as `reject-or-split`
+- **Active feature PR close-out entry**: Guardrail
+
+## Shared Pattern & System Fit
+
+- **Cross-cutting feature marker**: yes
+- **Systems touched**: current UI standards, audit package artifacts, roadmap or candidate docs as follow-up references, and the named runtime anchors as inventory sources
+- **Shared abstractions reused**: existing OperationRun activity-feedback standards, badge semantics, dashboard summary builders, baseline snapshot presentation, review-pack summary logic, and tenant dashboard summary builders as current evidence
+- **New abstraction introduced? why?**: no runtime abstraction. The only new structure is a docs-only audit taxonomy, inventory format, and follow-up map because current repo truth lacks a product-wide semantics layer.
+- **Why the existing abstraction was sufficient or insufficient**: current abstractions are sufficient to express domain-local meaning, but insufficient to state whether visually similar cues across domains mean the same thing.
+- **Bounded deviation / spread control**: none. Ambiguous cues and broad cleanup needs must route to later specs, not hidden runtime work here.
+
+## 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 health and permission-posture cues, plus provider-specific readiness or access examples found during inventory
+- **Platform-core seams**: indicator vocabulary, category rules, standards-delta language, and future cross-domain review criteria
+- **Neutral platform terms / contracts preserved**: `indicator`, `execution progress`, `activity state`, `coverage`, `completion`, `health`, `readiness`, `risk`, `pressure`, `usage`, `capacity`, `score`, and `generation state`
+- **Retained provider-specific semantics and why**: provider-specific examples stay labeled as such because they describe provider posture, not generic platform completion or execution truth
+- **Bounded extraction or follow-up path**: follow-up-spec if runtime contract or component work needs deeper provider or platform boundary normalization
+
+## Constitution Check
+
+*GATE: Must pass before implementation begins and again after the design artifacts are complete.*
+
+- Inventory-first / snapshot truth: PASS. The slice only inventories current repo-real cues and does not create a second runtime source of truth.
+- Read/write separation: PASS. No write, mutation, or runtime action path is introduced.
+- Graph contract path: PASS. No Graph, provider, or remote-call behavior changes are planned.
+- Deterministic capabilities: PASS. No capability or authorization logic changes are introduced.
+- Workspace and tenant isolation: PASS. The audit records scope assumptions but must not alter route or entitlement behavior.
+- RBAC-UX plane separation: PASS. No admin/system plane or tenant-route behavior is changed.
+- Destructive confirmation standard: PASS by non-use.
+- Global search safety: PASS. No resource or search change enters scope.
+- OperationRun / Ops-UX: PASS by non-use. Specs `268`, `270`, `271`, and `272` stay context only.
+- Data minimization: PASS. The output is repo documentation only.
+- Test governance (TEST-GOV-001): PASS. Proof stays in docs review and focused diff validation with explicit outcome recording.
+- Proportionality / no premature abstraction: PASS. The audit vocabulary is docs-only and bounded by explicit follow-up lanes for all runtime work.
+- Persisted truth (PERSIST-001): PASS. No new table, entity, projection, or stored runtime artifact is added.
+- Behavioral state (STATE-001): PASS. Categories remain documentation-only audit labels in this slice.
+- UI semantics / shared pattern first / Filament-native UI: PASS. The slice documents current surfaces and standards gaps without inventing a parallel UI framework.
+- Provider boundary (PROV-001): PASS. Mixed seams are named explicitly, and provider-owned examples remain outside platform-core truth.
+- Filament / Laravel planning contract: PASS. Filament stays v5 on Livewire v4, provider registration remains in `apps/platform/bootstrap/providers.php`, and no panel, asset, or global-search change is planned.
+
+**Gate evaluation**: PASS.
+
+**Post-design re-check**: PASS. `research.md`, `data-model.md`, `quickstart.md`, `contracts/cross-domain-indicator-audit.logical.openapi.yaml`, `checklists/requirements.md`, `inventory.md`, `follow-up-map.md`, and `standards-delta.md` are present and aligned with this docs-only package.
+
+## Test Governance Check
+
+- **Test purpose / classification by changed surface**: `N/A` - docs and governance only
+- **Affected validation lanes**: review, diff-check, grep lane-check
+- **Why this lane mix is the narrowest sufficient proof**: the package changes only repository artifacts, so structural diff validation and checklist review are the honest proof instead of runtime or browser lanes
+- **Narrowest implementation proving command(s)**:
+
+```bash
+export PATH="/bin:/usr/bin:/usr/local/bin:$PATH" && git diff --check -- specs/278-cross-domain-indicator-audit/spec.md specs/278-cross-domain-indicator-audit/plan.md specs/278-cross-domain-indicator-audit/research.md specs/278-cross-domain-indicator-audit/data-model.md specs/278-cross-domain-indicator-audit/quickstart.md specs/278-cross-domain-indicator-audit/checklists/requirements.md specs/278-cross-domain-indicator-audit/contracts/cross-domain-indicator-audit.logical.openapi.yaml specs/278-cross-domain-indicator-audit/tasks.md specs/278-cross-domain-indicator-audit/inventory.md specs/278-cross-domain-indicator-audit/follow-up-map.md specs/278-cross-domain-indicator-audit/standards-delta.md docs/ui/tenantpilot-enterprise-ui-standards.md docs/product/spec-candidates.md docs/product/roadmap.md
+
+export PATH="/bin:/usr/bin:/usr/local/bin:$PATH" && git diff -- specs/278-cross-domain-indicator-audit docs/ui/tenantpilot-enterprise-ui-standards.md docs/product/spec-candidates.md docs/product/roadmap.md
+
+export PATH="/bin:/usr/bin:/usr/local/bin:$PATH" && rg -n -- "standards patch lane|metric/indicator contract foundation|shared indicator component system|quality gate lane|domain migration lane" specs/278-cross-domain-indicator-audit/spec.md specs/278-cross-domain-indicator-audit/plan.md specs/278-cross-domain-indicator-audit/research.md specs/278-cross-domain-indicator-audit/data-model.md specs/278-cross-domain-indicator-audit/quickstart.md specs/278-cross-domain-indicator-audit/checklists/requirements.md specs/278-cross-domain-indicator-audit/tasks.md specs/278-cross-domain-indicator-audit/inventory.md specs/278-cross-domain-indicator-audit/follow-up-map.md specs/278-cross-domain-indicator-audit/standards-delta.md docs/ui/tenantpilot-enterprise-ui-standards.md docs/product/spec-candidates.md docs/product/roadmap.md
+```
+
+- **Fixture / helper / factory / seed / context cost risks**: none
+- **Expensive defaults or shared helper growth introduced?**: no
+- **Heavy-family additions, promotions, or visibility changes**: none
+- **Surface-class relief / special coverage rule**: `N/A`
+- **Closing validation and reviewer handoff**: rerun the exact implementation commands above, verify the package stays docs and governance first, verify the standards-delta target and follow-up lanes are explicit, and verify no runtime contract, component, migration, or app or test edits were pulled into the slice.
+- **Budget / baseline / trend follow-up**: none
+- **Review-stop questions**: did the package stay repo-based and docs-only, are the four future runtime lanes plus the standards patch lane explicit, did any runtime implementation hide inside the plan, and do the validation commands remain identical across the prep artifacts
+- **Escalation path**: `reject-or-split` for any drift into runtime code, tests, migrations, or UI implementation
+- **Active feature PR close-out entry**: Guardrail
+- **Why no dedicated follow-up spec is needed**: this package is itself the bounded prep artifact; the runtime follow-up lanes remain intentionally separate specs
+- **Test-governance outcome**: keep
+
+## Review Checklist Status
+
+- **Review checklist artifact**: `checklists/requirements.md`
+- **Review outcome class**: `acceptable-special-case`
+- **Workflow outcome**: `keep`
+- **Test-governance outcome**: `keep`
+- **Escalation rule**: if follow-up implementation derived from this package changes app code, tests, routes, assets, panels, or provider wiring, or if it collapses the follow-up lanes into one broad runtime rewrite, create a separate spec and resolve the spillover as `split` or `reject-or-split` before continuing
+
+## Rollout & Risk Controls
+
+- Keep this implementation on repo artifacts only: inventory, risk or disposition matrix, standards delta, and follow-up map.
+- Use the named runtime anchors as inventory sources only. Do not patch those anchors inside this audit slice.
+- When a cue cannot prove a truthful denominator, direction, freshness, or scope, classify it as ambiguous or risky and route it to one bounded follow-up lane instead of forcing a local semantic answer.
+- Keep later follow-up work split into separate candidates or specs:
+  - standards patch lane
+  - metric/indicator contract foundation
+  - shared indicator component system
+  - quality gate lane
+  - domain migration lane
+- Do not reopen Specs `266`, `268`, `270`, `271`, or `272` inside this package.
+
+## Research & Design Outputs
+
+- `research.md` records the repo-based scope decision, output artifact shape, vocabulary decision, standards-delta target, follow-up-lane split, and docs-only validation posture.
+- `data-model.md` captures the docs-only inventory, standards-delta, and follow-up-map entities and their required fields.
+- `quickstart.md` provides the bounded reviewer flow and the canonical docs-only validation commands.
+- `contracts/cross-domain-indicator-audit.logical.openapi.yaml` captures the conceptual repository-artifact contract for the inventory, standards delta, and follow-up map.
+- `checklists/requirements.md` carries the prep review outcome, workflow outcome, and test-governance outcome.
+- `inventory.md` contains the completed repo-based cue inventory and one-category/one-disposition classification.
+- `follow-up-map.md` groups non-keep recommendations into the five bounded later lanes.
+- `standards-delta.md` records the distilled standards rules applied to the UI standards document.
+
+## Project Structure
+
+### Documentation (this feature)
+
+```text
+specs/278-cross-domain-indicator-audit/
+├── checklists/
+│   └── requirements.md
+├── contracts/
+│   └── cross-domain-indicator-audit.logical.openapi.yaml
+├── data-model.md
+├── follow-up-map.md
+├── inventory.md
+├── plan.md
+├── quickstart.md
+├── research.md
+├── spec.md
+├── standards-delta.md
+└── tasks.md
+```
+
+### Repo reference surfaces audited as evidence
+
+```text
+docs/product/spec-candidates.md
+docs/product/roadmap.md
+docs/ui/tenantpilot-enterprise-ui-standards.md
+apps/platform/app/Support/OpsUx/OperationUxPresenter.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/Services/ReviewPackService.php
+apps/platform/app/Support/TenantDashboard/TenantDashboardSummaryBuilder.php
+```
+
+**Structure Decision**: keep the prep package and its later docs implementation inside spec artifacts plus explicit documentation targets. Runtime presenters, widgets, and services are source anchors only and remain untouched in this slice.
+
+## Complexity Tracking
+
+| Violation | Why Needed | Simpler Alternative Rejected Because |
+|-----------|------------|-------------------------------------|
+| Documentation-only taxonomy and audit bundle | The repo has multiple visually similar cues but no product-wide semantics inventory or bounded follow-up map | A cue-by-cue local cleanup would miss cross-domain drift and would still force later specs to repeat discovery |
+
+## Proportionality Review
+
+- **Current operator problem**: reviewers and operators can misread similar progress-like cues as equivalent even when they represent different product truth.
+- **Existing structure is insufficient because**: current presenters, widgets, services, and standards describe local meaning only and do not inventory or classify cross-domain semantics.
+- **Narrowest correct implementation**: one docs-only audit bundle, one standards-delta input, and one explicit follow-up map grounded in current repo surfaces.
+- **Ownership cost created**: maintenance of the vocabulary, audit matrix, and follow-up discipline in future specs and reviews.
+- **Alternative intentionally rejected**: immediate runtime contract, shared component, quality-gate implementation, or domain migration work was rejected because it would widen scope before the audit exists.
+- **Release truth**: current-release docs and governance groundwork with explicit future follow-up specs for runtime work.
--- a/specs/278-cross-domain-indicator-audit/quickstart.md
+++ b/specs/278-cross-domain-indicator-audit/quickstart.md
@ -0,0 +1,93 @@
+# Quickstart: Cross-Domain Progress Indicator Semantics Audit
+
+**Date**: 2026-05-06  
+**Branch**: `278-cross-domain-indicator-audit`
+
+This quickstart is the intended reviewer flow after implementation of the audit package. It stays bounded to repository audit artifacts, standards-delta input, and follow-up-lane separation. No application code, migrations, runtime tests, or UI implementation belong in this slice.
+
+## Prerequisites
+
+1. Work from the `278-cross-domain-indicator-audit` branch with the package artifacts under `specs/278-cross-domain-indicator-audit/` present.
+2. Treat `docs/product/spec-candidates.md`, `docs/product/roadmap.md`, `docs/ui/tenantpilot-enterprise-ui-standards.md`, and the named code anchors as the only source corpus for the audit.
+3. Keep the slice docs and governance first. Do not change files under `apps/platform/tests/`, do not add app code, and do not widen into runtime component or migration work.
+4. Keep related Specs `266`, `268`, `270`, `271`, and `272` as context-only guardrails.
+5. Review the implemented outputs: `inventory.md`, `follow-up-map.md`, and `standards-delta.md`.
+
+## Scenario 1: Review inventory coverage across the named anchors
+
+1. Open `specs/278-cross-domain-indicator-audit/inventory.md`.
+2. Confirm it covers the named source anchors from the spec and any additional indicator-like cues found through bounded repo search.
+3. Confirm every visible cue records:
+   - source path or anchor
+   - surface and domain
+   - visible wording or pattern
+   - data basis and calculation basis
+   - semantic category
+   - determinism, scope mode, and audience mode when relevant
+   - misunderstanding risk
+   - one bounded disposition
+4. Confirm visually similar cues are allowed to land in different categories when the underlying truth differs.
+
+## Scenario 2: Review the derived standards delta
+
+1. Open `specs/278-cross-domain-indicator-audit/standards-delta.md`.
+2. Confirm it states the allowed categories and the anti-patterns that should not pass future review.
+3. Confirm it explicitly covers:
+   - determinate-progress eligibility
+   - freshness and direction rules
+   - customer-safe wording constraints
+   - dashboard and summary-surface constraints
+   - provider-boundary notes where provider-owned cues are examples, not platform-core defaults
+4. Confirm the standards delta targets `docs/ui/tenantpilot-enterprise-ui-standards.md` without pretending to implement runtime UI in the same slice.
+
+## Scenario 3: Review follow-up-lane separation
+
+1. Open `specs/278-cross-domain-indicator-audit/follow-up-map.md`.
+2. Confirm later work is split into the following separate lanes:
+   - standards patch lane
+   - metric/indicator contract foundation
+   - shared indicator component system
+   - quality gate lane
+   - domain migration lane
+3. Confirm no cue is left with a vague "future cleanup" recommendation.
+4. Confirm the package does not collapse these lanes into one broad runtime rewrite.
+
+## Scenario 4: Verify docs-only boundaries
+
+1. Confirm the package outputs live in `specs/278-cross-domain-indicator-audit/` and point to future documentation targets where needed.
+2. Confirm the named runtime anchors are treated as source surfaces only.
+3. Confirm no app code, tests, routes, assets, panel wiring, global-search behavior, or provider registration changes were introduced.
+4. Confirm the package does not reopen Specs `266`, `268`, `270`, `271`, or `272` as implementation scope.
+
+## Targeted Validation Commands
+
+Use this implementation-phase command set after the audit outputs are created.
+
+```bash
+export PATH="/bin:/usr/bin:/usr/local/bin:$PATH" && git diff --check -- specs/278-cross-domain-indicator-audit/spec.md specs/278-cross-domain-indicator-audit/plan.md specs/278-cross-domain-indicator-audit/research.md specs/278-cross-domain-indicator-audit/data-model.md specs/278-cross-domain-indicator-audit/quickstart.md specs/278-cross-domain-indicator-audit/checklists/requirements.md specs/278-cross-domain-indicator-audit/contracts/cross-domain-indicator-audit.logical.openapi.yaml specs/278-cross-domain-indicator-audit/tasks.md specs/278-cross-domain-indicator-audit/inventory.md specs/278-cross-domain-indicator-audit/follow-up-map.md specs/278-cross-domain-indicator-audit/standards-delta.md docs/ui/tenantpilot-enterprise-ui-standards.md docs/product/spec-candidates.md docs/product/roadmap.md
+
+export PATH="/bin:/usr/bin:/usr/local/bin:$PATH" && git diff -- specs/278-cross-domain-indicator-audit docs/ui/tenantpilot-enterprise-ui-standards.md docs/product/spec-candidates.md docs/product/roadmap.md
+
+export PATH="/bin:/usr/bin:/usr/local/bin:$PATH" && rg -n -- "standards patch lane|metric/indicator contract foundation|shared indicator component system|quality gate lane|domain migration lane" specs/278-cross-domain-indicator-audit/spec.md specs/278-cross-domain-indicator-audit/plan.md specs/278-cross-domain-indicator-audit/research.md specs/278-cross-domain-indicator-audit/data-model.md specs/278-cross-domain-indicator-audit/quickstart.md specs/278-cross-domain-indicator-audit/checklists/requirements.md specs/278-cross-domain-indicator-audit/tasks.md specs/278-cross-domain-indicator-audit/inventory.md specs/278-cross-domain-indicator-audit/follow-up-map.md specs/278-cross-domain-indicator-audit/standards-delta.md docs/ui/tenantpilot-enterprise-ui-standards.md docs/product/spec-candidates.md docs/product/roadmap.md
+```
+
+## Implemented Output Checklist
+
+- `inventory.md` inventories named anchors and confirmed additional in-scope cues from bounded search.
+- `follow-up-map.md` keeps standards, contract, component, quality-gate, and migration lanes separate.
+- `standards-delta.md` records the distilled rules applied to the UI standards document.
+- `docs/product/spec-candidates.md` and `docs/product/roadmap.md` reference the five-lane follow-up posture.
+- No runtime Laravel, Filament, Livewire, provider, asset, migration, route, authorization, or test files are implementation targets for this slice.
+
+## Out-of-Scope Confirmations
+
+While reviewing this package, confirm that it does not add or imply:
+
+- application-code changes under `apps/platform/`
+- test additions or changes under `apps/platform/tests/`
+- a shared metric or indicator contract implementation
+- a shared indicator component implementation
+- quality-gate code or guard-test implementation
+- domain migration work
+- analytics, charting, or score recalculation work
+- panel, provider, asset, route, or global-search changes
--- a/specs/278-cross-domain-indicator-audit/research.md
+++ b/specs/278-cross-domain-indicator-audit/research.md
@ -0,0 +1,64 @@
+# Research — Cross-Domain Progress Indicator Semantics Audit
+
+**Date**: 2026-05-06  
+**Branch**: `278-cross-domain-indicator-audit`
+
+## Decision 1 — Keep the slice repo-based and docs/governance-first
+
+- **Decision**: Treat this package as a repository-governance audit only. The later implementation of this slice should create or update inventory, standards-delta, and follow-up artifacts without changing application code, tests, routes, assets, or panel wiring.
+- **Rationale**: The spec frames the current gap as semantic drift and missing inventory, not a missing runtime component. The smallest safe correction is therefore a repo-based audit bundle.
+- **Alternatives considered**: Starting with shared indicator components, contract code, dashboard rewrites, or score cleanup was rejected because each option widens scope before the product has one explicit inventory of what current cues actually mean.
+
+## Decision 2 — Keep the implementation outputs in the feature package first and target the UI standard as derived delta
+
+- **Decision**: Keep the main audit outputs inside `specs/278-cross-domain-indicator-audit/` and treat `docs/ui/tenantpilot-enterprise-ui-standards.md` as the future standards-delta destination rather than the first place where the full inventory lives.
+- **Rationale**: The feature package is the narrowest place to hold the full audit bundle, risk matrix, and follow-up map. The UI standard should receive the distilled rule delta later, not absorb the whole research inventory.
+- **Alternatives considered**: Writing the full inventory straight into `docs/ui/tenantpilot-enterprise-ui-standards.md` was rejected because it would mix durable standards with audit evidence and make follow-up review harder.
+
+## Decision 3 — Inventory named anchors plus bounded repo search, not isolated local surfaces
+
+- **Decision**: Use the named source anchors from the spec and a bounded repo search for additional indicator-like cues in the same scope. Treat anchors such as `OperationUxPresenter`, `InventoryKpiHeader`, `RecoveryReadiness`, `BaselineSnapshotPresenter`, `ReviewPackService`, and `TenantDashboardSummaryBuilder` as source surfaces only.
+- **Rationale**: The spec already names representative seams, but it also requires repo-based discovery beyond those anchors. A mixed anchor-plus-search approach keeps the audit grounded while still finding additional cues that share the same drift risk.
+- **Alternatives considered**: Auditing only the named files was rejected because it could miss nearby Blade or widget seams. Searching the entire repo without anchor guidance was rejected because it would widen discovery beyond the bounded slice.
+
+## Decision 4 — Keep one documentation-only category vocabulary and assign exactly one category per cue
+
+- **Decision**: Reuse the spec's category set as the only allowed semantics vocabulary in this slice: `execution progress`, `activity state`, `coverage`, `completion`, `health`, `readiness`, `risk`, `pressure`, `usage`, `capacity`, `score`, `generation state`, and `unknown/ambiguous`.
+- **Rationale**: The spec already defines the bounded vocabulary and requires exactly one category per cue. Reusing that set keeps the package consistent and prevents a second ad hoc taxonomy from appearing during planning.
+- **Alternatives considered**: Adding secondary category tags, subcategories, or a new risk-severity enum was rejected because the current-release need is classification clarity, not another semantic framework.
+
+## Decision 5 — Capture scope, audience, determinism, and data-basis metadata alongside meaning
+
+- **Decision**: Every inventory entry should carry scope mode, audience mode, determinism, visible pattern, and data-basis notes in addition to the semantic category and disposition.
+- **Rationale**: The same visual cue can be misleading for different reasons: fake progress, stale data, hidden tenant scope, or customer-safe wording drift. Category alone is not enough to explain why a cue is safe or risky.
+- **Alternatives considered**: A slimmer inventory with only label, category, and recommendation was rejected because it would not preserve the tenant, audience, and determinism context the spec explicitly calls out.
+
+## Decision 6 — Treat provider-owned cues as examples inside a neutral platform vocabulary
+
+- **Decision**: Record provider-health and permission-posture cues as provider-owned examples while keeping the audit's category language platform-neutral.
+- **Rationale**: The constitution and spec both require shared platform vocabulary to avoid becoming Microsoft-shaped truth. The audit needs to show that some examples remain provider-specific without letting those examples define the whole taxonomy.
+- **Alternatives considered**: Generalizing provider-specific examples into platform-core semantics was rejected because it would deepen provider coupling. Excluding them entirely was rejected because they are real current cues and part of the product's ambiguity problem.
+
+## Decision 7 — Split later work into five explicit follow-up lanes
+
+- **Decision**: Keep later work separated into the standards patch lane, metric/indicator contract foundation, shared indicator component system, quality gate lane, and domain migration lane.
+- **Rationale**: The spec explicitly forbids one giant cleanup program. Separate lanes keep later implementation reviewable and stop this audit from being read as permission for an immediate runtime rewrite.
+- **Alternatives considered**: One generic "indicator cleanup" follow-up was rejected because it hides architecture, migration, and governance costs behind a single vague bucket.
+
+## Decision 8 — Reuse the current prep convention for checklist and validation handling
+
+- **Decision**: Create a package-local checklist artifact and keep one canonical docs-only validation command set across `spec.md`, `plan.md`, `quickstart.md`, and the checklist.
+- **Rationale**: Nearby Specs `275` and `277` both carry explicit review outcome, workflow outcome, and test-governance outcome handling in addition to the plan. This slice needs the same prep discipline even though the proving lane is docs-only.
+- **Alternatives considered**: Relying only on prose review notes in `plan.md` was rejected because the repo's current prep convention expects a dedicated checklist artifact and explicit outcome language.
+
+## Decision 9 — Use docs-only validation rather than runtime tests
+
+- **Decision**: Validate this package with focused diff and grep commands plus reviewer checklist verification, not runtime tests or browser smoke.
+- **Rationale**: This slice changes only preparation artifacts. Running Sail, Pint, or app tests would not prove anything about the correctness of the audit package itself.
+- **Alternatives considered**: Adding runtime tests or browser checks was rejected because they would imply application behavior changed, which is explicitly out of scope.
+
+## Decision 10 — Lock the implementation outputs and lane handoff
+
+- **Decision**: Treat `inventory.md`, `follow-up-map.md`, and `standards-delta.md` as the completed package-local implementation outputs. The target UI standards document receives a concise indicator-semantics delta, while `docs/product/spec-candidates.md` and `docs/product/roadmap.md` receive only follow-up-lane references.
+- **Rationale**: The inventory needs enough detail for future specs, but product standards and backlog documents should not absorb the whole audit table. Separating the detailed audit from distilled standards and roadmap handoff keeps the current slice reviewable and prevents runtime cleanup from hiding inside documentation work.
+- **Alternatives considered**: Copying the full inventory into the standards document, creating new spec candidates as separate files, or updating application source comments were rejected because each would widen the docs-only audit beyond the bounded package.
--- a/specs/278-cross-domain-indicator-audit/spec.md
+++ b/specs/278-cross-domain-indicator-audit/spec.md
@ -0,0 +1,291 @@
+# Feature Specification: Cross-Domain Progress Indicator Semantics Audit
+
+**Feature Branch**: `278-cross-domain-indicator-audit`  
+**Created**: 2026-05-06  
+**Status**: Implemented docs-only audit artifact; ready for manual review  
+**Input**: Manual promotion of `docs/product/spec-candidates.md` section `Cross-Domain Progress / Indicator Semantics candidate group`, specifically `Candidate 8 - Cross-Domain Progress Indicator Semantics Audit`, into the active package at `specs/278-cross-domain-indicator-audit/`. This slice is repository-governance and standards groundwork only. Related specs `266`, `268`, `270`, `271`, and `272` remain context only and are not reopened.
+
+## Spec Candidate Check *(mandatory - SPEC-GATE-001)*
+
+- **Problem**: TenantPilot already exposes multiple progress-like cues across execution, coverage, readiness, health, review/export generation, and tenant summary surfaces, but the product does not yet maintain one repo-based inventory that states what those cues actually measure.
+- **Today's failure**: The same bar, percentage, or status-like cue can be read as execution progress on one surface and as coverage, readiness, risk, usage, score, or generation state on another. That invites false trust signals, wrong follow-up priorities, and future UI drift when later work reuses the same visual language without shared semantics.
+- **User-visible improvement**: Product, design, and engineering reviewers get one explicit audit foundation that tells them what each indicator-like cue means, where it is misleading, and which bounded follow-up lane owns the correction. This makes later runtime work faster, safer, and more honest.
+- **Smallest enterprise-capable version**: perform a repo-based audit of current indicator-like cues, classify each cue into one semantic category, record ambiguity and misunderstanding risk, define the standards-delta input for future governance rules, and name explicit follow-up candidates for contract, component, quality-gate, and migration work. No application behavior changes are included.
+- **Explicit non-goals**: no shared component implementation, no runtime contract or presenter rollout, no domain migration pass, no charting or analytics program, no score recalculation, no runtime UI rewrite, no asset change, no data migration, and no reopening of the OperationRun progress specs as part of this slice.
+- **Permanent complexity imported**: one repository-scoped indicator inventory vocabulary, one audit table format, one risk and disposition matrix, one standards-delta outline, and one explicit follow-up map. No runtime models, services, states, or test families are introduced.
+- **Why now**: the OperationRun progress lane is already being formalized in related specs, which makes the broader cross-domain ambiguity easier to see and cheaper to fix before more surfaces drift further. This is also the smallest safe unspecced slice in the current backlog.
+- **Why not local**: the ambiguity already spans multiple domains and shared operator surfaces. Local cleanup in one widget or one presenter would not prevent the same misread from recurring elsewhere.
+- **Approval class**: Core Enterprise
+- **Red flags triggered**: `many surfaces, little value` risk, `sounds like foundation`, and `new taxonomy`. Defense: this slice stays docs-first, repo-based, and explicitly stops before any runtime framework, component system, or migration program.
+- **Score**: Nutzen: 2 | Dringlichkeit: 2 | Scope: 2 | Komplexitaet: 1 | Produktnaehe: 1 | Wiederverwendung: 2 | **Gesamt: 10/12**
+- **Decision**: approve
+
+## Spec Scope Fields *(mandatory)*
+
+- **Scope**: workspace + tenant + canonical-view
+- **Primary Routes**:
+  - existing tenant dashboard and tenant-scoped widget surfaces such as `/admin/t/{tenant}`
+  - existing canonical operations and activity surfaces such as `/admin/operations` and `/admin/operations/{run}`
+  - existing baseline, review, evidence, and export-related surfaces already represented by current presenters and builders
+  - no new routes and no route behavior changes in this slice
+- **Data Ownership**: no runtime workspace-owned or tenant-owned tables change. The only new output in scope is repository-governance material such as an indicator inventory, risk matrix, standards-delta input, and follow-up map.
+- **RBAC**: no membership or capability changes are introduced. The audit must record audience mode and entitlement assumptions for each inventoried cue where those assumptions affect likely interpretation or leakage risk.
+
+**Implemented repository outputs**:
+
+- `specs/278-cross-domain-indicator-audit/inventory.md`
+- `specs/278-cross-domain-indicator-audit/follow-up-map.md`
+- `specs/278-cross-domain-indicator-audit/standards-delta.md`
+- bounded updates to `docs/ui/tenantpilot-enterprise-ui-standards.md`, `docs/product/spec-candidates.md`, and `docs/product/roadmap.md`
+
+For canonical-view specs, the spec MUST define:
+
+- **Default filter behavior when tenant-context is active**: no runtime filter changes are allowed in this slice. The audit must record whether each canonical-view cue is tenant-prefiltered, tenantless aggregate, or workspace aggregate today, so future work does not blur tenant scope accidentally.
+- **Explicit entitlement checks preventing cross-tenant leakage**: no entitlement behavior changes are allowed in this slice. If an inventoried cue appears to communicate tenant-specific truth on a canonical surface without clear scope signals or entitlement assumptions, the audit must flag that cue for follow-up rather than silently fixing it here.
+
+## 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)**: status messaging, progress and activity feedback, KPI rows, dashboard signals and readiness blocks, evidence and review summaries, and generation-state cues
+- **Systems touched**: `docs/ui/tenantpilot-enterprise-ui-standards.md`, `App\Support\OpsUx\OperationUxPresenter`, `App\Filament\Widgets\Inventory\InventoryKpiHeader`, `App\Filament\Widgets\Dashboard\RecoveryReadiness`, `App\Services\Baselines\SnapshotRendering\BaselineSnapshotPresenter`, `App\Services\ReviewPackService`, `App\Support\TenantDashboard\TenantDashboardSummaryBuilder`, and existing badge and summary primitives already used by those seams
+- **Existing pattern(s) to extend**: the current OperationRun activity-feedback pattern in the UI standards, current badge semantics, current dashboard summary and readiness builders, and current governance-artifact summary surfaces
+- **Shared contract / presenter / builder / renderer to reuse**: the audit must treat the existing standards document plus the named presenters and builders as repo-real source surfaces to inventory, not as targets to rewrite in this slice
+- **Why the existing shared path is sufficient or insufficient**: those paths are sufficient as current evidence of real product cues, but insufficient as a product-wide semantics layer because they explain only domain-local meaning and do not classify cross-domain indicator language above those domains
+- **Allowed deviation and why**: none. If an existing cue does not fit the allowed categories cleanly, it must be marked `unknown/ambiguous` and routed to a product decision or follow-up spec rather than hidden behind a new ad hoc label
+- **Consistency impact**: the audit must preserve a hard semantic separation between execution progress, activity state, coverage, completion, health, readiness, risk, pressure, usage, capacity, score, and generation state. Customer-safe wording must not imply execution progress when a cue actually measures a different category
+- **Review focus**: reviewers must verify that the audit is repo-based, categories are mutually exclusive at the cue level, recommendations stay bounded, and future work is split into explicit follow-up candidates rather than bundled into this slice
+
+## 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` - OperationRun semantics are audited as one existing category input only
+- **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**: product-wide indicator vocabulary in standards and audit artifacts, provider-health and permission-posture cues, and platform-core dashboard, review, baseline, and execution summary language
+- **Neutral platform terms preserved or introduced**: `indicator`, `execution progress`, `activity state`, `coverage`, `completion`, `health`, `readiness`, `risk`, `pressure`, `usage`, `capacity`, `score`, and `generation state`
+- **Provider-specific semantics retained and why**: provider health and permission posture remain provider-owned examples because they describe provider readiness or access posture, not generic platform success or execution completion
+- **Why this does not deepen provider coupling accidentally**: the audit classifies what a cue means, not which provider produced it. Provider-specific cues remain labeled as provider-owned examples inside a neutral platform-wide semantics vocabulary
+- **Follow-up path**: follow-up-spec for any later runtime contract or component work that needs stronger provider/platform boundary rules
+
+## UI / Surface Guardrail Impact *(mandatory when operator-facing surfaces are changed; otherwise write `N/A`)*
+
+`N/A - no operator-facing surface change. This slice audits and documents existing repo-real surfaces only.`
+
+## Decision-First Surface Role *(mandatory when operator-facing surfaces are changed)*
+
+`N/A - no operator-facing surface change. Existing surfaces are audit inputs only.`
+
+## Audience-Aware Disclosure *(mandatory when operator-facing surfaces are changed)*
+
+`N/A - no operator-facing surface change. Audience-mode concerns are captured as audit fields and follow-up risk notes only.`
+
+## UI/UX Surface Classification *(mandatory when operator-facing surfaces are changed)*
+
+`N/A - no operator-facing surface change. This slice does not add or reclassify a list, detail, queue, audit, config, or report surface.`
+
+## Operator Surface Contract *(mandatory when operator-facing surfaces are changed)*
+
+`N/A - no operator-facing surface change. This slice does not create or refactor an operator-facing page contract.`
+
+**UI Action Matrix**: `N/A - no Filament Resource, RelationManager, or Page action surface is added or changed in this slice.`
+
+## Proportionality Review *(mandatory when structural complexity is introduced)*
+
+- **New source of truth?**: no runtime source of truth. Existing domain truth remains authoritative. The audit only documents current repo-real cues and their meaning
+- **New persisted entity/table/artifact?**: yes - repository-governance artifacts only, such as an indicator inventory, risk matrix, standards-delta input, and follow-up map. No application persistence is introduced
+- **New abstraction?**: no runtime abstraction
+- **New enum/state/reason family?**: no runtime state family. The allowed categories are documentation-only audit vocabulary in this slice
+- **New cross-domain UI framework/taxonomy?**: yes - a documentation-only indicator classification taxonomy and audit vocabulary that future specs may later operationalize
+- **Current operator problem**: operators and reviewers can currently see the same visual language used for incompatible meanings, which undermines trust and makes later corrections harder to scope safely
+- **Existing structure is insufficient because**: current presenters, widgets, services, and UI standards capture local domain truth, but none inventory or classify indicator meaning across the product above those local seams
+- **Narrowest correct implementation**: audit the current repo, classify each cue once, record risk and recommendation, define standards-delta input, and map bounded follow-up candidates without changing runtime code
+- **Ownership cost**: ongoing maintenance of the inventory vocabulary, risk matrix, and standards guidance plus review discipline to keep future work aligned; no runtime code burden is added yet
+- **Alternative intentionally rejected**: immediate shared contract and component work, local cue-by-cue cleanup, and broad dashboard or design-system rewrites were rejected because they would widen scope before the product knows which cues actually exist and what they mean
+- **Release truth**: current-release truth and future-release preparation. The audit is grounded in current repo-real surfaces and is intentionally the preparation layer for later runtime follow-up work
+
+### 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 a later follow-up spec explicitly requires them.
+
+Canonical clarification and follow-up planning are preferred over preserving ambiguous indicator language.
+
+## Testing / Lane / Runtime Impact *(mandatory for runtime behavior changes)*
+
+- **Test purpose / classification**: `N/A` - docs and governance only
+- **Validation lane(s)**: `N/A`
+- **Why this classification and these lanes are sufficient**: this slice changes only repository-spec guidance and follow-up planning. It does not change runtime behavior, data, tests, routes, assets, or authorization
+- **New or expanded test families**: none
+- **Fixture / helper cost impact**: none
+- **Heavy-family visibility / justification**: none
+- **Special surface test profile**: `N/A`
+- **Standard-native relief or required special coverage**: `N/A`
+- **Reviewer handoff**: reviewers must confirm that the package remains docs/governance-first, that no runtime migration or shared component work is hidden inside the scope, and that related specs remain context only
+- **Budget / baseline / trend impact**: none
+- **Escalation needed**: follow-up-spec for later contract, component, quality-gate, and migration work
+- **Active feature PR close-out entry**: Guardrail
+- **Implementation validation commands**:
+
+```bash
+export PATH="/bin:/usr/bin:/usr/local/bin:$PATH" && git diff --check -- specs/278-cross-domain-indicator-audit/spec.md specs/278-cross-domain-indicator-audit/plan.md specs/278-cross-domain-indicator-audit/research.md specs/278-cross-domain-indicator-audit/data-model.md specs/278-cross-domain-indicator-audit/quickstart.md specs/278-cross-domain-indicator-audit/checklists/requirements.md specs/278-cross-domain-indicator-audit/contracts/cross-domain-indicator-audit.logical.openapi.yaml specs/278-cross-domain-indicator-audit/tasks.md specs/278-cross-domain-indicator-audit/inventory.md specs/278-cross-domain-indicator-audit/follow-up-map.md specs/278-cross-domain-indicator-audit/standards-delta.md docs/ui/tenantpilot-enterprise-ui-standards.md docs/product/spec-candidates.md docs/product/roadmap.md
+
+export PATH="/bin:/usr/bin:/usr/local/bin:$PATH" && git diff -- specs/278-cross-domain-indicator-audit docs/ui/tenantpilot-enterprise-ui-standards.md docs/product/spec-candidates.md docs/product/roadmap.md
+
+export PATH="/bin:/usr/bin:/usr/local/bin:$PATH" && rg -n -- "standards patch lane|metric/indicator contract foundation|shared indicator component system|quality gate lane|domain migration lane" specs/278-cross-domain-indicator-audit/spec.md specs/278-cross-domain-indicator-audit/plan.md specs/278-cross-domain-indicator-audit/research.md specs/278-cross-domain-indicator-audit/data-model.md specs/278-cross-domain-indicator-audit/quickstart.md specs/278-cross-domain-indicator-audit/checklists/requirements.md specs/278-cross-domain-indicator-audit/tasks.md specs/278-cross-domain-indicator-audit/inventory.md specs/278-cross-domain-indicator-audit/follow-up-map.md specs/278-cross-domain-indicator-audit/standards-delta.md docs/ui/tenantpilot-enterprise-ui-standards.md docs/product/spec-candidates.md docs/product/roadmap.md
+```
+
+## User Scenarios & Testing *(mandatory)*
+
+### User Story 1 - Classify existing indicator cues (Priority: P1)
+
+As a product or engineering lead, I need one repo-based audit that tells me what each progress-like cue actually measures, so execution progress is not conflated with coverage, readiness, risk, usage, score, or generation state.
+
+**Why this priority**: this is the core trust and scope-control problem. Without one inventory and semantic category per cue, later cleanup or component work will still miss ambiguous surfaces and repeat drift.
+
+**Independent Test**: review the finished audit against the named repo anchors and current surface search results, then confirm each inventoried cue records its visible pattern, meaning, data basis, misunderstanding risk, and recommendation.
+
+**Acceptance Scenarios**:
+
+1. **Given** a repo-real cue in `OperationUxPresenter`, `InventoryKpiHeader`, `RecoveryReadiness`, `BaselineSnapshotPresenter`, `ReviewPackService`, or `TenantDashboardSummaryBuilder`, **When** the audit is completed, **Then** that cue has an inventory entry with surface, label, pattern, data source, category, determinism, likely user reading, risk, and recommendation.
+2. **Given** two cues that use a similar visual pattern but represent different product truth, **When** they are inventoried, **Then** they are assigned different semantic categories with explicit notes about why they must not share one meaning.
+
+---
+
+### User Story 2 - Prepare bounded follow-up work (Priority: P1)
+
+As a maintainer preparing later runtime work, I need each audited cue mapped to a bounded disposition and next lane, so future contract, component, quality-gate, or migration work can start without repeating discovery or widening scope accidentally.
+
+**Why this priority**: the audit only creates value if it compresses the next decision and prevents one giant cleanup spec.
+
+**Independent Test**: inspect the audit recommendations and follow-up map, then verify that every ambiguous or risky cue points to exactly one bounded next action such as standards patch, product decision, contract follow-up, component follow-up, migration follow-up, or defer.
+
+**Acceptance Scenarios**:
+
+1. **Given** an audited cue that is ambiguous or misleading, **When** the recommendation is recorded, **Then** it is routed to exactly one bounded follow-up class instead of being left as a generic TODO.
+2. **Given** a cue that is already semantically honest, **When** the audit is completed, **Then** the recommendation can explicitly keep it as-is rather than forcing unnecessary migration work.
+
+---
+
+### User Story 3 - Feed future standards review consistently (Priority: P2)
+
+As a design or review owner, I need the audit to produce standards-delta input above individual domains, so future indicator work can be reviewed against one product-wide language instead of local interpretation.
+
+**Why this priority**: the standards delta is how this docs-first slice prevents the next round of drift without pretending to solve everything in code immediately.
+
+**Independent Test**: review the standards input derived from the audit and confirm it defines allowed categories, anti-patterns, and future follow-up ownership without changing runtime UI in the same slice.
+
+**Acceptance Scenarios**:
+
+1. **Given** the audit package is complete, **When** a reviewer checks the standards-delta input, **Then** they can see which indicator categories are allowed and which ambiguous patterns are forbidden or deferred.
+2. **Given** a future indicator proposal, **When** it is compared against this package, **Then** the reviewer can decide whether it belongs to an existing category, needs a product decision, or belongs in a later follow-up spec.
+
+### Edge Cases
+
+- One surface may expose more than one indicator-like cue, with each cue requiring its own category rather than one surface-wide label.
+- A cue may use a percentage or progress-bar pattern but have no truthful denominator, direction, or freshness guarantee.
+- A `0`, empty state, or `No current result` label may mean missing data rather than healthy completion and must not be classified as success by default.
+- A score, readiness signal, risk level, or usage meter may visually resemble execution progress and therefore needs explicit disambiguation.
+- Service-level or telemetry-adjacent signals discovered during the audit may not yet be directly visible on a user-facing surface; those signals must be marked as supporting context or out of scope rather than treated as shipped UI truth automatically.
+
+## Requirements *(mandatory)*
+
+**Constitution alignment summary**: This slice introduces no Microsoft Graph calls, no write behavior, no `OperationRun` start/completion logic, no runtime UI implementation, no provider contract changes, and no application persistence. It is an audit and standards foundation over existing repo-real indicator surfaces only.
+
+### Functional Requirements
+
+- **FR-001**: The package MUST inventory every current indicator-like cue in the agreed repo scope, including at minimum the repo anchors named in this spec and any additional current cues discovered through repo-based search.
+- **FR-002**: Each inventory entry MUST capture, at minimum, the source file or component, surface, domain, visible label or wording, visual pattern, data source, calculation basis, semantic category, determinism, likely user interpretation, misunderstanding risk, and recommended disposition.
+- **FR-003**: Each inventoried cue MUST be assigned exactly one of these categories: `execution progress`, `activity state`, `coverage`, `completion`, `health`, `readiness`, `risk`, `pressure`, `usage`, `capacity`, `score`, `generation state`, or `unknown/ambiguous`.
+- **FR-004**: The audit MUST explicitly separate OperationRun execution progress and activity semantics from coverage, readiness, risk, usage, score, and generation-state cues, and it MUST record related Specs `268`, `270`, `271`, and `272` as context-only guardrails rather than reopening them.
+- **FR-005**: Any cue whose wording, visual treatment, or calculation basis can plausibly mislead an operator MUST be marked with an explicit risk note and exactly one disposition from this set: `keep as-is`, `copy-only clarification`, `standards clarification`, `product decision`, `contract follow-up`, `shared-component follow-up`, `migration follow-up`, or `defer`.
+- **FR-006**: The audit MUST record when missing data, stale data, or unknown denominators can make a cue misleading, even if the cue is otherwise valid in its own domain.
+- **FR-007**: The package MUST produce standards-delta input for `docs/ui/tenantpilot-enterprise-ui-standards.md` that defines allowed indicator categories, determinate-progress eligibility, direction and freshness rules, customer-safe wording constraints, dashboard constraints, and forbidden anti-patterns.
+- **FR-008**: The package MUST produce explicit follow-up candidates or follow-up ownership notes for later work, including the standards patch lane, metric/indicator contract foundation, shared indicator component system, quality gate lane, and domain migration lane.
+- **FR-009**: The package MUST remain repository-based and docs/governance-first. It MUST NOT introduce runtime shared components, new presenters, UI rewrites, charts, analytics, score recalculation, migrations, or application code changes.
+- **FR-010**: The package MUST document the repo anchors and related-spec guardrails needed for later work so a future spec author does not need to repeat cross-repo discovery to begin the next bounded slice.
+- **FR-011**: The audit MUST preserve provider and platform boundary clarity by marking provider-owned cues as provider-specific examples rather than defaulting product-wide semantics to Microsoft-shaped language.
+- **FR-012**: The package MUST state explicitly that this slice is an audit and standards foundation over existing repo-real indicator surfaces, not a runtime implementation pass.
+
+### Authorization and Safety Requirements
+
+- **AR-001**: No RBAC, membership, entitlement, or route-access behavior may change in this slice.
+- **AR-002**: If the audit discovers a cue that appears to hide or blur workspace or tenant scope, the package MUST record that as a follow-up risk or product decision rather than silently changing runtime behavior here.
+- **AR-003**: No destructive action, confirmation flow, global search behavior, or audit-log behavior is introduced or changed in this slice.
+
+### Non-Functional Requirements
+
+- **NFR-001**: The package MUST remain compatible with the current Filament v5 and Livewire v4 baseline by not introducing any runtime Filament, Livewire, or panel wiring changes.
+- **NFR-002**: Provider registration remains unchanged in `apps/platform/bootstrap/providers.php`; this slice must not alter provider registration or panel configuration.
+- **NFR-003**: No global search resource, asset registration, polling behavior, or runtime page layout may change in this slice.
+- **NFR-004**: The audit outputs MUST be reviewable as repository artifacts without requiring a running application, migrations, or seed data.
+- **NFR-005**: Future runtime work derived from this package must remain bounded and must treat this package as the classification and standards input layer, not as permission to do a broad design-system rewrite.
+
+## Non-Goals
+
+- Implementing a shared metric or indicator contract in application code
+- Building shared progress or indicator components
+- Migrating existing domains to a new component family
+- Rewriting tenant dashboard, recovery, inventory, baseline, review, or operations UI in this slice
+- Adding charts, analytics dashboards, score engines, or usage accounting
+- Recalculating any existing score, readiness, or coverage truth
+- Changing authorization, routes, notifications, or OperationRun behavior
+- Reopening related specs that already own OperationRun execution semantics
+
+## Assumptions
+
+- The active auto-prep queue is empty, so this manual promotion is the explicit product decision needed to prepare the next safe slice.
+- Existing specs `266`, `268`, `270`, `271`, and `272` remain valid context and guardrails; they are not rewritten by this package.
+- The repo anchors named in this spec are representative current seams, and the implemented inventory also includes confirmed additional indicator-like cues found through bounded search within the agreed scope.
+- The artifact files produced by this implementation are `inventory.md`, `follow-up-map.md`, and `standards-delta.md`; they remain documentation, standards, inventory, and audit outputs rather than runtime code.
+- Because this slice is docs-only, no production compatibility or deployment migration behavior is required.
+
+## Risks
+
+- The audit could widen into a pseudo-framework or shared component design exercise if the follow-up boundaries are not enforced.
+- Some cues may legitimately require product judgment because their visible wording or denominator is not deterministically recoverable from current repo truth.
+- The inventory may become stale if new indicator-like cues land before the follow-up standards patch or quality gate is in place.
+- Provider-specific readiness or health cues may tempt future work to leak provider semantics into platform-core vocabulary if follow-up scopes are not kept narrow.
+
+## UI Action Matrix *(mandatory when Filament is changed)*
+
+`N/A - no Filament Resource, RelationManager, or Page is added or modified in this slice.`
+
+### Key Entities *(include if feature involves data)*
+
+- **Indicator Inventory Entry**: one audited cue in a current repo-real surface, recording what the cue looks like, what it measures, where it appears, and why it may mislead.
+- **Indicator Category**: the semantic class assigned to one cue, such as execution progress, coverage, readiness, risk, usage, score, or generation state.
+- **Recommendation Disposition**: the bounded next action for an inventoried cue, such as keep as-is, copy-only clarification, standards clarification, product decision, contract follow-up, component follow-up, migration follow-up, or defer.
+- **Standards Delta Input**: the repository-governance guidance derived from the audit that later work can apply to `docs/ui/tenantpilot-enterprise-ui-standards.md`.
+- **Follow-Up Map**: the explicit set of later spec lanes that consume this audit, including standards, contract, component, quality-gate, and migration work.
+
+## Success Criteria *(mandatory)*
+
+### Measurable Outcomes
+
+- **SC-001**: Every indicator-like cue discovered in the agreed repo scope has exactly one inventory entry, exactly one semantic category, and exactly one recommendation disposition.
+- **SC-002**: Every audited cue that could plausibly be mistaken for execution progress while measuring something else is explicitly flagged with a misunderstanding risk and a bounded follow-up path.
+- **SC-003**: Product and engineering review can trace every follow-up item produced by this package to one bounded lane without reopening unrelated runtime specs or repeating cross-repo discovery.
+- **SC-004**: The completed package clearly separates execution progress from coverage, readiness, health, risk, usage, score, and generation-state semantics in all audited examples.
+- **SC-005**: The package is accepted without any application-code, route, asset, data, or runtime UI changes in the same slice.
+
+## Candidate Selection Rationale
+
+- **Selected candidate**: `Candidate 8 - Cross-Domain Progress Indicator Semantics Audit`
+- **Source location**: `docs/product/spec-candidates.md`, section `Cross-Domain Progress / Indicator Semantics candidate group`
+- **Why selected**: this is the smallest safe unspecced slice that can reduce enterprise UX and trust drift immediately without widening into runtime implementation. It sits above the already-specced OperationRun progress lane and prevents future execution-progress semantics from being conflated with other indicator meanings across the product.
+- **Why close alternatives were deferred**:
+  - `Workspace & Tenant Closure Lifecycle v1` is broader and higher-risk than this audit slice
+  - `273 - Tenant Dashboard Active Operations Summary Card` remains conditional on visible post-268 dashboard drift
+  - a first governed AI runtime consumer is later and less immediate than current indicator trust drift
+  - shared contract, component, quality-gate, and migration work are explicitly deferred to later follow-up candidates
+- **Roadmap relationship**: near-term enterprise UX and trust guardrail sitting above the OperationRun progress semantics lane; it constrains future indicator work across dashboards, evidence, readiness, review, and generation-state surfaces
+- **Related-spec guardrail check**: there was no existing `specs/273-*` or `specs/278-*` package at preparation time. Existing specs `266`, `268`, `270`, `271`, and `272` already cover adjacent or lower-level execution semantics and therefore remain context only
--- a/specs/278-cross-domain-indicator-audit/standards-delta.md
+++ b/specs/278-cross-domain-indicator-audit/standards-delta.md
@ -0,0 +1,50 @@
+# Standards Delta: Cross-Domain Progress Indicator Semantics Audit
+
+**Target document**: `docs/ui/tenantpilot-enterprise-ui-standards.md`  
+**Source inventory**: `specs/278-cross-domain-indicator-audit/inventory.md`  
+**Follow-up map**: `specs/278-cross-domain-indicator-audit/follow-up-map.md`  
+**Status**: Applied as bounded standards input, not runtime implementation
+
+## Standards Delta Rules
+
+| Rule ID | Area | Current gap | Proposed guidance | Target doc | Follow-up lane |
+|---|---|---|---|---|---|
+| IND-STD-001 | allowed-categories | Current standards mostly discuss progress bars and OperationRun progress, not the product-wide indicator category set. | Every indicator-like cue must name exactly one semantic category: execution progress, activity state, coverage, completion, health, readiness, risk, pressure, usage, capacity, score, generation state, or unknown/ambiguous. | `docs/ui/tenantpilot-enterprise-ui-standards.md` | standards patch lane |
+| IND-STD-002 | determinate-progress | Some ratios and percentages outside OperationRun can look like execution progress. | Determinate progress UI is allowed only when a real numerator and denominator or real percent exists, the measured category is explicit, and the cue does not imply execution progress unless it measures active execution. | `docs/ui/tenantpilot-enterprise-ui-standards.md` | standards patch lane |
+| IND-STD-003 | freshness | Coverage, provider permissions, evidence, and review states can look current even when their basis is missing or stale. | Indicators must expose missing, stale, or unknown basis as state or supporting copy. Missing data must not render as healthy zero, calm, complete, or ready by default. | `docs/ui/tenantpilot-enterprise-ui-standards.md` | standards patch lane |
+| IND-STD-004 | wording | Labels such as `Active operations`, `No current result`, `Posture score`, and customer-safe output states can invite the wrong reading. | Labels must state the measured thing, not just a generic status noun. Avoid `progress`, `score`, `health`, `ready`, or `active` unless the source truth supports that exact meaning. | `docs/ui/tenantpilot-enterprise-ui-standards.md` | standards patch lane |
+| IND-STD-005 | dashboard | Tenant dashboard rollups combine provider permissions, findings, recovery, backup, evidence, reviews, and operations. | Dashboard indicators must remain decision-first and must not collapse execution outcome, data completeness, governance result, lifecycle/readiness, risk pressure, and customer handoff maturity into one unexplained status. | `docs/ui/tenantpilot-enterprise-ui-standards.md` | metric/indicator contract foundation |
+| IND-STD-006 | anti-pattern | Bars, counts, scores, badges, and colored cards can reuse the same visual language for incompatible meanings. | Forbidden: fake percentages; progress bars for provider health, risk, pressure, usage, score, or readiness without real denominator; outcome counters reused as progress; score values with no scale/direction; stale data shown as current truth; usage/capacity shown as success progress. | `docs/ui/tenantpilot-enterprise-ui-standards.md` | standards patch lane |
+| IND-STD-007 | provider-boundary | Provider health and permission posture can leak Microsoft-shaped terms into platform-core semantics. | Provider-owned cues must be labeled as provider posture or provider readiness examples. They must not define platform-core health, readiness, score, or success semantics by default. | `docs/ui/tenantpilot-enterprise-ui-standards.md` | metric/indicator contract foundation |
+| IND-STD-008 | quality-gate | Future contributors can add local progress-like UI without category/freshness/denominator review. | New or changed indicator surfaces should include a review note answering: what is measured, which category applies, whether direction is higher/lower/neutral, how fresh the source is, what missing data means, and what action the operator should take. | `.specify/templates/*` later, plus active specs | quality gate lane |
+
+## Applied Target-Doc Delta
+
+The standards target should now include a product-wide "Indicator Semantics" rule block near the existing Progress Bar Pattern. The block must stay concise and not copy the full inventory.
+
+Minimum applied guidance:
+
+- Indicators are not interchangeable. A bar, percentage, score, KPI count, status badge, readiness label, health label, risk count, usage/capacity value, or generation-state hint must state what it measures.
+- Execution progress is only active work progress. Coverage, review completion, provider health, backup posture, risk pressure, usage/capacity, scores, and generation state must not borrow execution-progress language.
+- Determinate bars require truthful numerator/denominator or percent values and accessible visible text.
+- Unknown, stale, or missing source truth must remain visible and must not default to calm, ready, healthy, complete, or zero.
+- Provider-owned health and permission posture stay provider examples, not platform-core default semantics.
+- Future runtime work must split into contract, component, quality-gate, and migration lanes instead of treating this audit as permission for broad UI rewrite.
+
+## Anti-Patterns Derived From Inventory
+
+| Anti-pattern | Example inventory entries | Required later disposition |
+|---|---|---|
+| Activity-only bar reads like determinate progress | `IND-002` | Standards language first; component lane later if visual drift persists. |
+| Missing basis reads like calm or zero | `IND-008`, `IND-022`, `IND-037` | Copy-only or standards clarification before contract rollout. |
+| Label promises the wrong metric | `IND-020` | Copy-only clarification; product decision only if label semantics are intentionally retained. |
+| Score has no direction or scale | `IND-031`, `IND-032` | Contract follow-up before shared component or migration. |
+| Provider health becomes platform health | `IND-028`, `IND-033` | Provider-boundary standards and contract fields. |
+| Review completion reads like evidence completeness | `IND-026`, `IND-029` | Component/contract distinction between completion and generation/readiness. |
+| Preview-impact ratio reads like progress | `IND-036` | Standards clarification and later component categorization. |
+
+## Review Outcome
+
+- The standards delta is applied at a documentation level only.
+- No runtime component, contract, migration, quality gate, or test family is introduced by this slice.
+- Later specs may quote this delta as input, but must still define their own implementation scope and proof lane.
--- a/specs/278-cross-domain-indicator-audit/tasks.md
+++ b/specs/278-cross-domain-indicator-audit/tasks.md
@ -0,0 +1,194 @@
+---
+description: "Task list for Cross-Domain Progress Indicator Semantics Audit"
+---
+
+# Tasks: Cross-Domain Progress Indicator Semantics Audit
+
+**Input**: Design documents from `specs/278-cross-domain-indicator-audit/`  
+**Prerequisites**: `specs/278-cross-domain-indicator-audit/spec.md`, `specs/278-cross-domain-indicator-audit/plan.md`, `specs/278-cross-domain-indicator-audit/checklists/requirements.md`, `specs/278-cross-domain-indicator-audit/research.md`, `specs/278-cross-domain-indicator-audit/data-model.md`, `specs/278-cross-domain-indicator-audit/quickstart.md`, `specs/278-cross-domain-indicator-audit/contracts/cross-domain-indicator-audit.logical.openapi.yaml`
+
+**Review Artifact**: `specs/278-cross-domain-indicator-audit/checklists/requirements.md` is the outcome-of-record for the review outcome class, workflow outcome, and test-governance outcome. If implementation widens into shared indicator components, runtime contract code, presenter refactors, migrations, analytics, score recalculation, quality-gate code, or domain cleanup beyond inventory/classification and documented follow-up recommendations, update that artifact and resolve the spillover as `split` or `reject-or-split` before continuing.
+
+**Tests**: No runtime tests. Keep proof in repository-artifact review plus focused `diff-check` and `rg` validation only.
+**Operations**: No `OperationRun`, queue, remote call, or background processing is introduced.
+**RBAC**: No membership, capability, route, or panel-access behavior changes are allowed. Record scope, audience, and leakage risks as audit metadata only.
+**Shared Pattern Reuse**: Treat `docs/ui/tenantpilot-enterprise-ui-standards.md`, `docs/product/spec-candidates.md`, `docs/product/roadmap.md`, and the named presenter/widget/service anchors as inventory sources only. Do not rewrite runtime surfaces in this slice.
+**Filament / Panel Guardrails**: Filament remains v5 on Livewire v4. Provider registration remains unchanged in `apps/platform/bootstrap/providers.php`. No globally searchable resource, destructive action, or asset-strategy change is allowed.
+**Organization**: Tasks are grouped by user story so inventory/classification, follow-up mapping, and standards-delta work remain separate docs-governance increments with explicit reviewer checkpoints.
+**Review Outcome**: `acceptable-special-case`
+**Workflow Outcome**: `keep`
+**Test-governance Outcome**: `keep`
+
+## Test Governance Checklist
+
+- `N/A` Runtime lanes remain unchanged; proof stays in `review` and `diff-check` only.
+- `N/A` No Pest, browser, or heavy-governance test family is added because no runtime behavior changes.
+- `N/A` No fixtures, helpers, factories, seeds, or support defaults change because no application or test files are touched.
+- `N/A` Surface-profile coverage remains docs-only; no operator-facing runtime surface is implemented here.
+- `N/A` Planned validation commands cover only the spec package plus bounded documentation targets.
+- `N/A` Any drift into runtime implementation resolves as `reject-or-split`, not as silent scope expansion.
+
+## Phase 1: Setup (Shared Context)
+
+**Purpose**: Lock the bounded audit corpus, package-local output targets, and outcome-of-record handling before repository-doc edits begin.
+
+- [x] T001 Review `specs/278-cross-domain-indicator-audit/spec.md`, `specs/278-cross-domain-indicator-audit/plan.md`, `specs/278-cross-domain-indicator-audit/research.md`, `specs/278-cross-domain-indicator-audit/data-model.md`, `specs/278-cross-domain-indicator-audit/quickstart.md`, `specs/278-cross-domain-indicator-audit/checklists/requirements.md`, and `specs/278-cross-domain-indicator-audit/contracts/cross-domain-indicator-audit.logical.openapi.yaml` together so the slice stays docs-only, inventory-first, and explicitly split from runtime work.
+- [x] T002 [P] Confirm the bounded source corpus in `docs/ui/tenantpilot-enterprise-ui-standards.md`, `docs/product/spec-candidates.md`, `docs/product/roadmap.md`, `apps/platform/app/Support/OpsUx/OperationUxPresenter.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/Services/ReviewPackService.php`, and `apps/platform/app/Support/TenantDashboard/TenantDashboardSummaryBuilder.php` so later inventory work uses repo truth only.
+- [x] T003 Create `specs/278-cross-domain-indicator-audit/inventory.md`, `specs/278-cross-domain-indicator-audit/follow-up-map.md`, and `specs/278-cross-domain-indicator-audit/standards-delta.md` as the package-local audit outputs referenced by later story work.
+
+---
+
+## Phase 2: Foundational (Blocking Prerequisites)
+
+**Purpose**: Translate the prep artifacts into concrete audit schemas and reviewer rules before any user-story drafting begins.
+
+**Critical**: No user-story work should begin until these package-local schemas and validation boundaries are in place.
+
+- [x] T004 [P] Translate the `Indicator Inventory Entry`, `Recommendation Disposition`, `Standards Delta Rule`, and `Follow-Up Map Entry` fields from `specs/278-cross-domain-indicator-audit/data-model.md` and `specs/278-cross-domain-indicator-audit/contracts/cross-domain-indicator-audit.logical.openapi.yaml` into concrete section or table templates inside `specs/278-cross-domain-indicator-audit/inventory.md`, `specs/278-cross-domain-indicator-audit/follow-up-map.md`, and `specs/278-cross-domain-indicator-audit/standards-delta.md`.
+- [x] T005 [P] Update `specs/278-cross-domain-indicator-audit/quickstart.md` with the concrete reviewer flow for `specs/278-cross-domain-indicator-audit/inventory.md`, `specs/278-cross-domain-indicator-audit/follow-up-map.md`, and `specs/278-cross-domain-indicator-audit/standards-delta.md`, keeping proof in docs-only validation.
+- [x] T006 Update `specs/278-cross-domain-indicator-audit/plan.md` and `specs/278-cross-domain-indicator-audit/checklists/requirements.md` so the review outcome fields and scope guardrails mention the concrete package outputs and restate the `reject-or-split` boundary for any runtime spillover.
+
+**Checkpoint**: The audit bundle shape, review artifact, and reviewer flow are fixed before cue-by-cue work begins.
+
+---
+
+## Phase 3: User Story 1 - Classify existing indicator cues (Priority: P1)
+
+**Goal**: Build one repo-based inventory that states what each in-scope indicator-like cue actually measures.
+
+**Independent Test**: Review `specs/278-cross-domain-indicator-audit/inventory.md` against the named repo anchors and the bounded search results, then confirm every cue has exactly one entry with source path, visible pattern, data basis, category, determinism, scope, likely reading, and risk note.
+
+- [x] T007 [P] [US1] Inventory the named cue sources in `apps/platform/app/Support/OpsUx/OperationUxPresenter.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/Services/ReviewPackService.php`, and `apps/platform/app/Support/TenantDashboard/TenantDashboardSummaryBuilder.php` into `specs/278-cross-domain-indicator-audit/inventory.md`, recording one row per visible cue with source path, surface, domain, visible cue, visual pattern, data source, and calculation basis.
+- [x] T008 [P] [US1] Run bounded repository search from `apps/platform/app/` and `apps/platform/resources/views/filament/` to capture additional in-scope indicator-like cues and append only the confirmed entries to `specs/278-cross-domain-indicator-audit/inventory.md`.
+- [x] T009 [US1] Classify every entry in `specs/278-cross-domain-indicator-audit/inventory.md` with exactly one semantic category, determinism, scope mode, audience mode, likely user reading, and misunderstanding risk using the allowed values from `specs/278-cross-domain-indicator-audit/data-model.md`.
+- [x] T010 [US1] Reconcile `specs/278-cross-domain-indicator-audit/inventory.md`, `specs/278-cross-domain-indicator-audit/spec.md`, and `specs/278-cross-domain-indicator-audit/contracts/cross-domain-indicator-audit.logical.openapi.yaml` so the inventory covers the named anchors, preserves the docs-only boundary, and contains no duplicate or unclassified cues.
+
+**Checkpoint**: The package has one bounded, fully classified inventory of existing indicator-like cues.
+
+---
+
+## Phase 4: User Story 2 - Prepare bounded follow-up work (Priority: P1)
+
+**Goal**: Map every risky or ambiguous cue to one bounded next lane so future runtime work does not need to repeat discovery or collapse into a single cleanup program.
+
+**Independent Test**: Inspect `specs/278-cross-domain-indicator-audit/inventory.md` and `specs/278-cross-domain-indicator-audit/follow-up-map.md`, then confirm every non-`keep as-is` cue has exactly one disposition and, when required, exactly one follow-up lane.
+
+- [x] T011 [P] [US2] Add one disposition and, when required, one follow-up lane to each entry in `specs/278-cross-domain-indicator-audit/inventory.md`, keeping `keep as-is` as the only lane-less disposition.
+- [x] T012 [US2] Materialize the grouped follow-up ownership in `specs/278-cross-domain-indicator-audit/follow-up-map.md` for the five required lanes: `standards patch lane`, `metric/indicator contract foundation`, `shared indicator component system`, `quality gate lane`, and `domain migration lane`.
+- [x] T013 [P] [US2] Update `docs/product/spec-candidates.md` with the bounded follow-up candidates and seed questions sourced from `specs/278-cross-domain-indicator-audit/follow-up-map.md`, keeping contract, component, quality-gate, and migration work as separate candidates.
+- [x] T014 [P] [US2] Update `docs/product/roadmap.md` only where `specs/278-cross-domain-indicator-audit/follow-up-map.md` changes sequencing or dependency notes, preserving this audit as the current docs-first slice and leaving related runtime specs context-only.
+
+**Checkpoint**: Every risky or ambiguous cue now points to one bounded follow-up lane instead of a vague cleanup bucket.
+
+---
+
+## Phase 5: User Story 3 - Feed future standards review consistently (Priority: P2)
+
+**Goal**: Produce one standards-delta layer above individual domains so future indicator proposals can be reviewed against shared product language.
+
+**Independent Test**: Review `specs/278-cross-domain-indicator-audit/standards-delta.md` and `docs/ui/tenantpilot-enterprise-ui-standards.md`, then confirm they define the allowed categories, determinate-progress rules, wording constraints, dashboard constraints, provider-boundary notes, and anti-patterns without implying runtime implementation in this slice.
+
+- [x] T015 [P] [US3] Derive `specs/278-cross-domain-indicator-audit/standards-delta.md` from `specs/278-cross-domain-indicator-audit/inventory.md` and `specs/278-cross-domain-indicator-audit/follow-up-map.md`, covering allowed categories, determinate-progress eligibility, freshness or direction rules, customer-safe wording, dashboard constraints, provider-boundary notes, and forbidden anti-patterns.
+- [x] T016 [US3] Update `docs/ui/tenantpilot-enterprise-ui-standards.md` with the bounded indicator-semantics delta from `specs/278-cross-domain-indicator-audit/standards-delta.md` without copying the full inventory or introducing runtime implementation commitments.
+- [x] T017 [US3] Align `specs/278-cross-domain-indicator-audit/research.md` and `specs/278-cross-domain-indicator-audit/quickstart.md` with the finished standards-delta and follow-up ownership so later reviewers and spec authors can reuse this package without repeating cross-repo discovery.
+
+**Checkpoint**: The package now has a durable standards-delta layer and reviewer handoff above individual domains.
+
+---
+
+## Phase 6: Polish & Cross-Cutting Validation
+
+**Purpose**: Reconcile review outcomes, run the canonical docs-only validation commands, and prove the slice stayed out of application code.
+
+- [x] T018 [P] Update `specs/278-cross-domain-indicator-audit/checklists/requirements.md`, `specs/278-cross-domain-indicator-audit/plan.md`, and `specs/278-cross-domain-indicator-audit/quickstart.md` with the final review outcome class, workflow outcome, test-governance outcome, actual artifact paths, and any explicit `reject-or-split` note for runtime spillover.
+- [x] T019 [P] Run `export PATH="/bin:/usr/bin:/usr/local/bin:$PATH" && git diff --check -- specs/278-cross-domain-indicator-audit/spec.md specs/278-cross-domain-indicator-audit/plan.md specs/278-cross-domain-indicator-audit/research.md specs/278-cross-domain-indicator-audit/data-model.md specs/278-cross-domain-indicator-audit/quickstart.md specs/278-cross-domain-indicator-audit/checklists/requirements.md specs/278-cross-domain-indicator-audit/contracts/cross-domain-indicator-audit.logical.openapi.yaml specs/278-cross-domain-indicator-audit/tasks.md specs/278-cross-domain-indicator-audit/inventory.md specs/278-cross-domain-indicator-audit/follow-up-map.md specs/278-cross-domain-indicator-audit/standards-delta.md docs/ui/tenantpilot-enterprise-ui-standards.md docs/product/spec-candidates.md docs/product/roadmap.md`.
+- [x] T020 [P] Run `export PATH="/bin:/usr/bin:/usr/local/bin:$PATH" && git diff -- specs/278-cross-domain-indicator-audit docs/ui/tenantpilot-enterprise-ui-standards.md docs/product/spec-candidates.md docs/product/roadmap.md` and `export PATH="/bin:/usr/bin:/usr/local/bin:$PATH" && rg -n -- "standards patch lane|metric/indicator contract foundation|shared indicator component system|quality gate lane|domain migration lane" specs/278-cross-domain-indicator-audit/spec.md specs/278-cross-domain-indicator-audit/plan.md specs/278-cross-domain-indicator-audit/research.md specs/278-cross-domain-indicator-audit/data-model.md specs/278-cross-domain-indicator-audit/quickstart.md specs/278-cross-domain-indicator-audit/checklists/requirements.md specs/278-cross-domain-indicator-audit/tasks.md specs/278-cross-domain-indicator-audit/inventory.md specs/278-cross-domain-indicator-audit/follow-up-map.md specs/278-cross-domain-indicator-audit/standards-delta.md docs/ui/tenantpilot-enterprise-ui-standards.md docs/product/spec-candidates.md docs/product/roadmap.md`.
+- [x] T021 Review the final diff to confirm no files under `apps/platform/` or `apps/platform/tests/` changed for implementation purposes and record final preparation-validation completion in `specs/278-cross-domain-indicator-audit/checklists/requirements.md`.
+
+---
+
+## Dependencies & Execution Order
+
+### Phase Dependencies
+
+- **Phase 1 (Setup)**: no dependencies; start immediately.
+- **Phase 2 (Foundational)**: depends on Phase 1 and blocks all user-story work.
+- **Phase 3 (US1)**: depends on Phase 2 because classification requires the concrete audit templates and reviewer flow.
+- **Phase 4 (US2)**: depends on US1 because dispositions and follow-up lanes require the completed inventory.
+- **Phase 5 (US3)**: depends on US1 and US2 because the standards delta should reflect both the classified cues and their bounded follow-up ownership.
+- **Phase 6 (Polish)**: depends on all desired stories being complete.
+
+### User Story Dependencies
+
+- **US1 (P1)**: first independently reviewable increment once the package-local audit templates are in place.
+- **US2 (P1)**: depends on US1 and becomes independently reviewable once every classified cue has one bounded disposition and follow-up lane.
+- **US3 (P2)**: depends on US1 and US2 and becomes independently reviewable once the shared standards delta lands in both the package and the standards document.
+
+### Within Each User Story
+
+- Finish the concrete artifact scaffolding before cue-level editing begins.
+- Keep all edits inside `specs/278-cross-domain-indicator-audit/`, `docs/ui/tenantpilot-enterprise-ui-standards.md`, `docs/product/spec-candidates.md`, and `docs/product/roadmap.md`.
+- Treat application files under `apps/platform/` as evidence sources only, not as implementation targets.
+- Re-run the narrowest docs-only validation command after each story checkpoint before moving on.
+
+---
+
+## Parallel Execution Examples
+
+### Phase 1
+
+- `T002` and `T003` can run in parallel after `T001` confirms the bounded slice.
+
+### Phase 2
+
+- `T004` and `T005` can run in parallel once `T003` creates the package-local output files.
+
+### User Story 1
+
+- `T007` and `T008` can run in parallel because one inventories the named anchors while the other handles bounded repo search.
+
+### User Story 2
+
+- `T013` and `T014` can run in parallel once `T011` and `T012` establish the final follow-up-lane map.
+
+### User Story 3
+
+- `T016` and `T017` can run in parallel once `T015` finishes the package-local standards delta.
+
+### Polish
+
+- `T019` and `T020` can run in parallel after `T018` finalizes the review and outcome fields.
+
+---
+
+## Implementation Strategy
+
+### Suggested MVP Scope
+
+- MVP = **US1 + US2**. The audit becomes actionable once the product has both the classified inventory and the bounded follow-up map. US3 can then land as the shared standards-review layer.
+
+### Incremental Delivery
+
+1. Complete Phase 1 and Phase 2 to lock the package-local artifact structure and reviewer flow.
+2. Deliver US1 by building the full cue inventory and category classification.
+3. Deliver US2 by assigning dispositions, producing the follow-up map, and syncing the candidate or roadmap references.
+4. Deliver US3 by distilling the standards delta into the package and `docs/ui/tenantpilot-enterprise-ui-standards.md`.
+5. Finish with Phase 6 validation and explicit preparation close-out.
+
+### Team Strategy
+
+1. Keep the package-local documents as the main working surface and avoid application-code edits entirely.
+2. Parallelize corpus review and audit drafting where tasks touch different repository artifacts.
+3. Serialize merges around `docs/ui/tenantpilot-enterprise-ui-standards.md`, `docs/product/spec-candidates.md`, and `docs/product/roadmap.md` because those files are likely conflict hotspots.
+
+---
+
+## Explicit Non-Goals
+
+- runtime shared indicator component implementation
+- runtime metric or indicator contract code
+- migrations, persistence changes, or score recalculation
+- presenter or widget refactors beyond using them as audit evidence
+- analytics, charting, or quality-gate code
+- broad domain cleanup outside inventory/classification and documented follow-up recommendations
+- application or test changes under `apps/platform/`