TenantAtlas/specs/204-platform-core-vocabulary-hardening/tasks.md

# Tasks: Platform Core Vocabulary Hardening

**Input**: Design documents from `/specs/204-platform-core-vocabulary-hardening/`  
**Prerequisites**: `plan.md`, `spec.md`, `research.md`, `data-model.md`, `contracts/platform-core-vocabulary-hardening.logical.openapi.yaml`, `quickstart.md`

**Tests**: Required. This feature changes runtime vocabulary resolution, operation-run presentation, reason translation, compare and snapshot rendering, and contributor-facing boundary contracts, so Pest unit, feature, Filament, and architecture coverage must be added or extended.
**Operations**: This feature reuses the existing `OperationRun` presentation, monitoring widgets, reporting widgets, and launch surfaces only. No new run type, queued notification channel, lifecycle transition path, workflow hub, or alternate monitoring hub should be introduced; touched run labels, filters, summaries, widget copy, launch labels, and audit prose must continue to resolve through the canonical Monitoring and existing owning surfaces.
**Monitoring Render Contract**: Touched monitoring and review surfaces must remain DB-only at render time; vocabulary hardening must not add provider, Graph, or other external calls as a side effect of rendering, filtering, summarizing, or opening detail pages.
**RBAC**: Existing platform, workspace, and tenant authorization boundaries remain authoritative. Tasks must preserve the current `/system` platform-guard capability semantics, keep `404` versus `403` behavior intact, and ensure clearer labels or explanations do not leak hidden tenant, workspace, or platform-console context.
**Operator Surfaces**: The affected surfaces are the existing monitoring operations list and run detail, the tenant dashboard recent-operations widget, the system Control Tower widgets, tenant baseline compare landing and matrix, evidence snapshot resource and snapshot presentation, tenant review resource, review-pack reporting summaries and widgets, and the existing provider connection, inventory item, backup schedule, and onboarding launch surfaces.
**Filament UI Action Surfaces**: No new action plane, destructive action, or global search behavior is introduced. Existing inspect or open affordances remain primary and touched copy must stay aligned to the current surface roles.
**Proportionality**: Add only the narrow glossary, alias, reason-ownership, and subject-descriptor contracts under the existing governance, operation, compare, and reason-translation seams. Prefer extensions to current files and introduce standalone support types only where the same meaning would otherwise be duplicated across multiple touched surfaces. Do not expand into a repo-wide rename sweep or a second platform vocabulary framework.

**Organization**: Tasks are grouped by user story so each slice stays independently testable. Recommended delivery order is `US1 -> US2 -> US3 -> US4`, with `US1` as the MVP cut after the shared vocabulary foundation is in place.

## Phase 1: Setup (Shared Infrastructure)

**Purpose**: Prepare focused test entry points for the glossary, operation vocabulary resolution, and platform subject normalization.

- [X] T001 Create the platform glossary and registry ownership test scaffolds in `apps/platform/tests/Unit/Support/Governance/PlatformVocabularyGlossaryTest.php` and `apps/platform/tests/Unit/Support/Governance/RegistryOwnershipDescriptorTest.php`
- [X] T002 [P] Create the canonical operation vocabulary and alias resolution test scaffold in `apps/platform/tests/Unit/Support/OperationTypeResolutionTest.php`
- [X] T003 [P] Create the platform subject normalization and vocabulary boundary guard test scaffolds in `apps/platform/tests/Unit/Support/Governance/PlatformSubjectDescriptorNormalizerTest.php` and `apps/platform/tests/Architecture/PlatformVocabularyBoundaryGuardTest.php`

**Checkpoint**: Dedicated Spec 204 test entry points exist and the feature can proceed without mixing the first slice into unrelated suites.

---

## Phase 2: Foundational (Blocking Prerequisites)

**Purpose**: Establish the shared glossary, alias, reason-owner, and subject-descriptor contracts before any story-specific integrations land.

**CRITICAL**: No user story work should start before this phase is complete.

- [X] T004 [P] Add foundational glossary and registry ownership expectations in `apps/platform/tests/Unit/Baselines/GovernanceSubjectTaxonomyRegistryTest.php`, `apps/platform/tests/Unit/Support/Governance/PlatformVocabularyGlossaryTest.php`, and `apps/platform/tests/Unit/Support/Governance/RegistryOwnershipDescriptorTest.php`
- [X] T005 [P] Add foundational canonical operation alias and filter-resolution expectations in `apps/platform/tests/Unit/Support/OperationTypeResolutionTest.php`, `apps/platform/tests/Feature/Filament/OperationRunListFiltersTest.php`, and `apps/platform/tests/Feature/Monitoring/OperationRunResolvedReferencePresentationTest.php`
- [X] T006 [P] Add foundational reason-owner and platform-family expectations in `apps/platform/tests/Unit/Support/ReasonTranslation/ReasonResolutionEnvelopeTest.php`, `apps/platform/tests/Unit/Support/ReasonTranslation/ProviderReasonTranslationTest.php`, and `apps/platform/tests/Unit/Support/ReasonTranslation/RbacReasonTranslationTest.php`
- [X] T007 [P] Add foundational platform-subject normalization and no-leakage guard expectations in `apps/platform/tests/Unit/Support/Governance/PlatformSubjectDescriptorNormalizerTest.php`, `apps/platform/tests/Architecture/PlatformVocabularyBoundaryGuardTest.php`, and `apps/platform/tests/Feature/Authorization/ReasonTranslationScopeSafetyTest.php`
- [X] T008 Implement the minimal glossary, registry ownership, and subject-descriptor support under the existing governance seam in `apps/platform/app/Support/Governance/PlatformVocabularyGlossary.php`, `apps/platform/app/Support/Governance/PlatformVocabularyTerm.php`, `apps/platform/app/Support/Governance/RegistryOwnershipDescriptor.php`, `apps/platform/app/Support/Governance/PlatformSubjectDescriptor.php`, `apps/platform/app/Support/Governance/SubjectDescriptorNormalizationResult.php`, and `apps/platform/app/Support/Governance/PlatformSubjectDescriptorNormalizer.php`
- [X] T009 Implement the minimal canonical operation type, alias, and resolution support under the existing operation seam in `apps/platform/app/Support/CanonicalOperationType.php`, `apps/platform/app/Support/OperationTypeAlias.php`, `apps/platform/app/Support/OperationTypeResolution.php`, `apps/platform/app/Support/OperationCatalog.php`, and `apps/platform/app/Support/OperationRunType.php`
- [X] T010 Implement the minimal platform reason family and reason-ownership metadata under the existing translation seam in `apps/platform/app/Support/ReasonTranslation/PlatformReasonFamily.php`, `apps/platform/app/Support/ReasonTranslation/ReasonOwnershipDescriptor.php`, `apps/platform/app/Support/ReasonTranslation/ReasonResolutionEnvelope.php`, and `apps/platform/app/Support/ReasonTranslation/ReasonTranslator.php`
- [X] T011 Wire foundational ownership and compatibility bootstrap into `apps/platform/app/Support/Governance/GovernanceSubjectTaxonomyRegistry.php`, `apps/platform/app/Support/Baselines/BaselineScope.php`, `apps/platform/app/Support/Providers/ProviderReasonCodes.php`, and `apps/platform/config/tenantpilot.php`

**Checkpoint**: The repo can model canonical platform vocabulary, resolve one canonical operation meaning from legacy values, classify translated reasons by owner and family, and normalize platform-near subject descriptors without changing Intune-owned persistence.

---

## Phase 3: User Story 1 - Remove false-universal Intune language from platform surfaces (Priority: P1) 🎯 MVP

**Goal**: Harden platform-near compare, snapshot, evidence, and filter contracts so they prefer governed-subject descriptors instead of false-universal `policy_type` wording.

**Independent Test**: Baseline compare, evidence, and snapshot surfaces render governed-subject descriptors by default while any Intune-owned fallback data remains secondary and compatibility-only.

### Tests for User Story 1

> **NOTE**: Write these tests first and confirm they fail before implementation.

- [X] T012 [P] [US1] Extend snapshot and evidence rendering coverage in `apps/platform/tests/Unit/Baselines/SnapshotRendering/BaselineSnapshotPresenterTest.php`, `apps/platform/tests/Feature/Filament/BaselineSnapshotStructuredRenderingTest.php`, `apps/platform/tests/Feature/Filament/BaselineSnapshotResolvedReferencePresentationTest.php`, and `apps/platform/tests/Feature/Evidence/EvidenceSnapshotResourceTest.php`
- [X] T013 [P] [US1] Extend compare and review vocabulary coverage in `apps/platform/tests/Feature/Baselines/BaselineCompareDriftEvidenceContractTest.php`, `apps/platform/tests/Feature/Filament/BaselineCompareExplanationSurfaceTest.php`, and `apps/platform/tests/Feature/Filament/BaselineCompareSummaryConsistencyTest.php`

### Implementation for User Story 1

- [X] T014 [US1] Implement governed-subject descriptor normalization for compare and snapshot payloads in `apps/platform/app/Support/Governance/PlatformSubjectDescriptorNormalizer.php`, `apps/platform/app/Support/Baselines/Compare/CompareSubjectProjection.php`, and `apps/platform/app/Support/Baselines/Compare/CompareSubjectResult.php`
- [X] T015 [US1] Replace false-universal `policy_type` presentation in baseline snapshot and evidence surfaces in `apps/platform/app/Services/Baselines/SnapshotRendering/BaselineSnapshotPresenter.php`, `apps/platform/app/Filament/Resources/EvidenceSnapshotResource.php`, and `apps/platform/app/Support/Filament/FilterOptionCatalog.php`
- [X] T016 [US1] Harden compare and review surfaces and normalize platform-owned persisted compare context to prefer governed-subject vocabulary in `apps/platform/app/Jobs/CompareBaselineToTenantJob.php`, `apps/platform/app/Models/OperationRun.php`, `apps/platform/app/Support/Baselines/BaselineCompareStats.php`, `apps/platform/app/Support/Baselines/BaselineCompareEvidenceGapDetails.php`, `apps/platform/app/Support/ReasonTranslation/ReasonPresenter.php`, `apps/platform/app/Filament/Pages/BaselineCompareLanding.php`, and `apps/platform/app/Filament/Pages/BaselineCompareMatrix.php`
- [X] T017 [US1] Keep legacy subject aliases compatibility-only in `apps/platform/app/Support/Baselines/BaselineScope.php`, `apps/platform/app/Support/Governance/PlatformVocabularyGlossary.php`, and `apps/platform/app/Support/Governance/PlatformSubjectDescriptorNormalizer.php`

**Checkpoint**: Platform-near compare, snapshot, and evidence surfaces are independently functional with governed-subject vocabulary and explicit compatibility fallbacks.

---

## Phase 4: User Story 2 - Keep monitoring and review semantics clear during transition (Priority: P1)

**Goal**: Keep canonical operation labels, legacy alias resolution, and platform-versus-domain explanation semantics clear across monitoring, run-detail, review, and reporting surfaces during rollout.

**Independent Test**: Historical and canonical operation types render the same operator meaning across monitoring, review, and reporting summaries, and explanation surfaces separate platform reason families from domain-owned detail without changing access semantics.

### Tests for User Story 2

> **NOTE**: Write these tests first and confirm they fail before implementation.

- [X] T018 [P] [US2] Extend canonical operation label, canonical `operation_type` read-path, DB-only render, query-shape guard, and filter continuity coverage across monitoring widgets and launch surfaces in `apps/platform/tests/Feature/Filament/OperationRunListFiltersTest.php`, `apps/platform/tests/Feature/Filament/OperationRunEnterpriseDetailPageTest.php`, `apps/platform/tests/Feature/Monitoring/OperationRunResolvedReferencePresentationTest.php`, `apps/platform/tests/Feature/Filament/RecentOperationsSummaryWidgetTest.php`, `apps/platform/tests/Feature/System/Spec114/ControlTowerDashboardTest.php`, `apps/platform/tests/Feature/Filament/ProviderConnectionsDbOnlyTest.php`, `apps/platform/tests/Feature/Filament/InventoryItemResourceTest.php`, `apps/platform/tests/Feature/BackupScheduling/BackupScheduleCrudTest.php`, and `apps/platform/tests/Feature/Onboarding/OnboardingEntryPointTest.php`
- [X] T019 [P] [US2] Extend platform-versus-domain explanation layering coverage across review and reporting surfaces in `apps/platform/tests/Feature/ReasonTranslation/GovernanceReasonPresentationTest.php`, `apps/platform/tests/Feature/ReasonTranslation/ReasonTranslationExplanationTest.php`, `apps/platform/tests/Feature/Authorization/ReasonTranslationScopeSafetyTest.php`, `apps/platform/tests/Feature/Filament/OperationRunBaselineTruthSurfaceTest.php`, `apps/platform/tests/Feature/TenantReview/TenantReviewExplanationSurfaceTest.php`, `apps/platform/tests/Feature/TenantReview/TenantReviewExecutivePackTest.php`, `apps/platform/tests/Feature/TenantReview/TenantReviewUiContractTest.php`, `apps/platform/tests/Feature/ReviewPack/ReviewPackGenerationTest.php`, and `apps/platform/tests/Feature/ReviewPack/ReviewPackWidgetTest.php`

### Implementation for User Story 2

- [X] T020 [US2] Wire canonical operation resolution and canonical-code emission into touched run producers and monitoring labels using in-process resolution helpers and without adding remote render-time work in `apps/platform/app/Support/OperationCatalog.php`, `apps/platform/app/Support/OperationRunType.php`, `apps/platform/app/Services/Baselines/BaselineCompareService.php`, `apps/platform/app/Services/Baselines/BaselineCaptureService.php`, `apps/platform/app/Services/Evidence/EvidenceSnapshotService.php`, `apps/platform/app/Services/Inventory/InventorySyncService.php`, `apps/platform/app/Services/ReviewPackService.php`, `apps/platform/app/Services/TenantReviews/TenantReviewService.php`, `apps/platform/app/Services/BackupScheduling/BackupScheduleDispatcher.php`, `apps/platform/app/Services/Directory/EntraGroupSyncService.php`, `apps/platform/app/Filament/Resources/OperationRunResource.php`, `apps/platform/app/Filament/System/Pages/Ops/Runs.php`, and `apps/platform/app/Filament/Widgets/Dashboard/RecentOperations.php`
- [X] T021 [US2] Normalize legacy and canonical operation labels and expose canonical `operation_type` across touched monitoring widgets, summaries, filters, audit prose, launch surfaces, and exports without introducing read-path query fan-out in `apps/platform/app/Filament/System/Widgets/ControlTowerRecentFailures.php`, `apps/platform/app/Filament/System/Widgets/ControlTowerTopOffenders.php`, `apps/platform/app/Services/Audit/AuditEventBuilder.php`, `apps/platform/app/Filament/Resources/ProviderConnectionResource.php`, `apps/platform/app/Filament/Resources/InventoryItemResource/Pages/ListInventoryItems.php`, `apps/platform/app/Filament/Resources/BackupScheduleResource.php`, and `apps/platform/app/Filament/Pages/Workspaces/ManagedTenantOnboardingWizard.php`
- [X] T022 [US2] Add explicit reason-owner and platform-family rendering to translated explanations in `apps/platform/app/Support/ReasonTranslation/ReasonTranslator.php`, `apps/platform/app/Support/ReasonTranslation/ReasonPresenter.php`, `apps/platform/app/Support/ReasonTranslation/ReasonResolutionEnvelope.php`, `apps/platform/app/Support/Providers/ProviderReasonTranslator.php`, and `apps/platform/app/Support/Baselines/BaselineCompareReasonCode.php`
- [X] T023 [US2] Keep review and reporting surface copy and filter semantics canonical during the transition in `apps/platform/app/Support/Filament/FilterOptionCatalog.php`, `apps/platform/app/Filament/Pages/BaselineCompareLanding.php`, `apps/platform/app/Filament/Resources/OperationRunResource.php`, `apps/platform/app/Filament/Resources/TenantReviewResource.php`, and `apps/platform/app/Filament/Widgets/Tenant/TenantReviewPackCard.php`

**Checkpoint**: Monitoring, run detail, and review explanations are independently functional with canonical operation resolution and explicit platform-versus-domain reason semantics.

---

## Phase 5: User Story 3 - Make platform and domain ownership obvious to future contributors (Priority: P2)

**Goal**: Give contributors one maintained boundary reference so they can classify touched registries, terms, and reason families as `platform_core`, `cross_domain_governance`, or `intune_specific` without reverse-engineering historical Intune assumptions.

**Independent Test**: The maintained glossary plus architecture guards are enough to classify touched registries and reason families as `platform_core`, `cross_domain_governance`, or `intune_specific` without relying on historical Intune knowledge.

### Tests for User Story 3

> **NOTE**: Write these tests first and confirm they fail before implementation.

- [X] T024 [P] [US3] Extend glossary and registry ownership contract coverage for explicit three-way boundary classification in `apps/platform/tests/Unit/Support/Governance/PlatformVocabularyGlossaryTest.php`, `apps/platform/tests/Unit/Support/Governance/RegistryOwnershipDescriptorTest.php`, and `apps/platform/tests/Unit/Baselines/GovernanceSubjectTaxonomyRegistryTest.php`
- [X] T025 [P] [US3] Extend contributor-boundary guard coverage in `apps/platform/tests/Architecture/PlatformVocabularyBoundaryGuardTest.php` and `apps/platform/tests/Architecture/ReasonTranslationPrimarySurfaceGuardTest.php`

### Implementation for User Story 3

- [X] T026 [US3] Expose contributor-facing glossary lookup helpers and canonical term inventory from the foundational glossary in `apps/platform/app/Support/Governance/PlatformVocabularyGlossary.php`, `apps/platform/app/Support/Governance/PlatformVocabularyTerm.php`, and `apps/platform/app/Support/Governance/GovernanceSubjectTaxonomyRegistry.php`
- [X] T027 [US3] Expose contributor-facing ownership metadata and canonical noun references from the foundational registries in `apps/platform/app/Support/Governance/RegistryOwnershipDescriptor.php`, `apps/platform/app/Support/OperationCatalog.php`, `apps/platform/app/Support/Providers/ProviderReasonCodes.php`, and `apps/platform/config/tenantpilot.php`
- [X] T028 [US3] Expose contributor-safe three-way boundary helpers for operation, reason, and subject vocabulary classification in `apps/platform/app/Support/Governance/PlatformVocabularyGlossary.php`, `apps/platform/app/Support/ReasonTranslation/ReasonTranslator.php`, `apps/platform/app/Support/RbacReason.php`, and `apps/platform/app/Support/Tenants/TenantOperabilityReasonCode.php`
- [X] T029 [US3] Encode canonical-name and retirement metadata for touched aliases in `apps/platform/app/Support/OperationTypeAlias.php`, `apps/platform/app/Support/OperationCatalog.php`, and `apps/platform/app/Support/Governance/PlatformVocabularyGlossary.php`

**Checkpoint**: Contributors can independently classify touched terms, registries, and reason families using the maintained glossary and guardrails alone.

---

## Phase 6: User Story 4 - Preserve Intune-first behavior while hardening boundaries (Priority: P2)

**Goal**: Keep compatibility mapping and explicit ownership from changing current Intune-first operation, compare, evidence, and review behavior beyond the intended vocabulary hardening.

**Independent Test**: Existing Intune-first flows behave the same except for clearer platform vocabulary, and legacy operation values or policy-type data still resolve correctly during the documented transition.

### Tests for User Story 4

> **NOTE**: Write these tests first and confirm they fail before implementation.

- [X] T030 [P] [US4] Extend Intune-first no-regression coverage for compare and review surfaces in `apps/platform/tests/Feature/Baselines/BaselineCompareWhyNoFindingsReasonCodeTest.php`, `apps/platform/tests/Feature/Filament/BaselineCompareLandingAdminTenantParityTest.php`, and `apps/platform/tests/Feature/Filament/BaselineSnapshotFallbackRenderingTest.php`
- [X] T031 [P] [US4] Extend compatibility and domain-owned vocabulary preservation coverage in `apps/platform/tests/Unit/Support/ReasonTranslation/TenantOperabilityReasonTranslationTest.php`, `apps/platform/tests/Unit/Support/ReasonTranslation/ExecutionDenialReasonTranslationTest.php`, and `apps/platform/tests/Feature/Baselines/BaselineCompareDriftEvidenceContractRbacTest.php`

### Implementation for User Story 4

- [X] T032 [US4] Preserve Intune-owned reason and policy vocabulary where ownership is explicit in `apps/platform/app/Support/Providers/ProviderReasonCodes.php`, `apps/platform/app/Support/RbacReason.php`, `apps/platform/app/Support/Tenants/TenantOperabilityReasonCode.php`, `apps/platform/app/Support/Operations/ExecutionDenialReasonCode.php`, and `apps/platform/app/Support/Baselines/BaselineCompareReasonCode.php`
- [X] T033 [US4] Keep historical operation aliases and legacy subject discriminators readable during rollout across platform-owned context and evidence payloads in `apps/platform/app/Support/OperationCatalog.php`, `apps/platform/app/Support/OperationTypeResolution.php`, `apps/platform/app/Support/Governance/PlatformSubjectDescriptorNormalizer.php`, `apps/platform/app/Models/OperationRun.php`, `apps/platform/app/Support/ReasonTranslation/ReasonPresenter.php`, and `apps/platform/app/Filament/Resources/EvidenceSnapshotResource.php`
- [X] T034 [US4] Recheck Intune-first compare, evidence, monitoring, and reporting continuity in `apps/platform/app/Jobs/CompareBaselineToTenantJob.php`, `apps/platform/app/Services/Baselines/SnapshotRendering/BaselineSnapshotPresenter.php`, `apps/platform/app/Filament/Resources/OperationRunResource.php`, `apps/platform/app/Services/Audit/AuditEventBuilder.php`, `apps/platform/app/Filament/Resources/TenantReviewResource.php`, and `apps/platform/app/Filament/Widgets/Tenant/TenantReviewPackCard.php`

**Checkpoint**: The platform boundary is clearer while current Intune-first operator behavior remains independently functional and compatibility-safe.

---

## Phase 7: Polish & Cross-Cutting Concerns

**Purpose**: Lock the slice down with final copy review, architecture guardrails, and focused Sail verification.

- [X] T035 [P] Recheck operator-facing canonical naming, copy alignment, touched widget and launch-surface semantics, and list-surface checklist compliance in `apps/platform/app/Filament/Resources/OperationRunResource.php`, `apps/platform/app/Filament/Resources/EvidenceSnapshotResource.php`, `apps/platform/app/Filament/Pages/BaselineCompareLanding.php`, `apps/platform/app/Filament/Pages/BaselineCompareMatrix.php`, `apps/platform/app/Filament/System/Widgets/ControlTowerRecentFailures.php`, `apps/platform/app/Filament/System/Widgets/ControlTowerTopOffenders.php`, `apps/platform/app/Filament/Widgets/Dashboard/RecentOperations.php`, `apps/platform/app/Filament/Resources/TenantReviewResource.php`, `apps/platform/app/Filament/Widgets/Tenant/TenantReviewPackCard.php`, `apps/platform/app/Filament/Resources/ProviderConnectionResource.php`, `apps/platform/app/Filament/Resources/InventoryItemResource/Pages/ListInventoryItems.php`, `apps/platform/app/Filament/Resources/BackupScheduleResource.php`, `apps/platform/app/Filament/Pages/Workspaces/ManagedTenantOnboardingWizard.php`, and `docs/product/standards/list-surface-review-checklist.md`
- [X] T036 [P] Extend final vocabulary, in-process resolution, and query-shape guardrails against false-universal platform leakage on touched read paths in `apps/platform/tests/Architecture/PlatformVocabularyBoundaryGuardTest.php`, `apps/platform/tests/Architecture/ReasonTranslationPrimarySurfaceGuardTest.php`, and `apps/platform/tests/Feature/Authorization/ReasonTranslationScopeSafetyTest.php`
- [X] T037 Run the full spec-specific Sail verification pack from `specs/204-platform-core-vocabulary-hardening/quickstart.md` against `apps/platform/tests/Unit/Support/Governance/PlatformVocabularyGlossaryTest.php`, `apps/platform/tests/Unit/Support/Governance/RegistryOwnershipDescriptorTest.php`, `apps/platform/tests/Unit/Baselines/GovernanceSubjectTaxonomyRegistryTest.php`, `apps/platform/tests/Architecture/ReasonTranslationPrimarySurfaceGuardTest.php`, `apps/platform/tests/Architecture/PlatformVocabularyBoundaryGuardTest.php`, `apps/platform/tests/Feature/Authorization/ReasonTranslationScopeSafetyTest.php`, `apps/platform/tests/Unit/Support/ReasonTranslation/ReasonResolutionEnvelopeTest.php`, `apps/platform/tests/Unit/Support/ReasonTranslation/ProviderReasonTranslationTest.php`, `apps/platform/tests/Unit/Support/ReasonTranslation/RbacReasonTranslationTest.php`, `apps/platform/tests/Unit/Support/ReasonTranslation/TenantOperabilityReasonTranslationTest.php`, `apps/platform/tests/Unit/Support/ReasonTranslation/ExecutionDenialReasonTranslationTest.php`, `apps/platform/tests/Feature/ReasonTranslation/GovernanceReasonPresentationTest.php`, `apps/platform/tests/Feature/ReasonTranslation/ReasonTranslationExplanationTest.php`, `apps/platform/tests/Feature/Filament/OperationRunListFiltersTest.php`, `apps/platform/tests/Feature/Filament/OperationRunEnterpriseDetailPageTest.php`, `apps/platform/tests/Feature/Filament/OperationRunBaselineTruthSurfaceTest.php`, `apps/platform/tests/Feature/Monitoring/OperationRunResolvedReferencePresentationTest.php`, `apps/platform/tests/Feature/Filament/RecentOperationsSummaryWidgetTest.php`, `apps/platform/tests/Feature/System/Spec114/ControlTowerDashboardTest.php`, `apps/platform/tests/Unit/Baselines/SnapshotRendering/BaselineSnapshotPresenterTest.php`, `apps/platform/tests/Feature/Filament/BaselineSnapshotStructuredRenderingTest.php`, `apps/platform/tests/Feature/Filament/BaselineSnapshotResolvedReferencePresentationTest.php`, `apps/platform/tests/Feature/Evidence/EvidenceSnapshotResourceTest.php`, `apps/platform/tests/Feature/Baselines/BaselineCompareDriftEvidenceContractTest.php`, `apps/platform/tests/Feature/Filament/BaselineCompareExplanationSurfaceTest.php`, `apps/platform/tests/Feature/Filament/BaselineCompareSummaryConsistencyTest.php`, `apps/platform/tests/Feature/Filament/BaselineCompareLandingAdminTenantParityTest.php`, `apps/platform/tests/Feature/Baselines/BaselineCompareWhyNoFindingsReasonCodeTest.php`, `apps/platform/tests/Feature/Filament/BaselineSnapshotFallbackRenderingTest.php`, `apps/platform/tests/Feature/Baselines/BaselineCompareDriftEvidenceContractRbacTest.php`, `apps/platform/tests/Feature/TenantReview/TenantReviewExplanationSurfaceTest.php`, `apps/platform/tests/Feature/TenantReview/TenantReviewExecutivePackTest.php`, `apps/platform/tests/Feature/TenantReview/TenantReviewUiContractTest.php`, `apps/platform/tests/Feature/ReviewPack/ReviewPackGenerationTest.php`, `apps/platform/tests/Feature/ReviewPack/ReviewPackWidgetTest.php`, `apps/platform/tests/Feature/Filament/ProviderConnectionsDbOnlyTest.php`, `apps/platform/tests/Feature/Filament/InventoryItemResourceTest.php`, `apps/platform/tests/Feature/BackupScheduling/BackupScheduleCrudTest.php`, and `apps/platform/tests/Feature/Onboarding/OnboardingEntryPointTest.php`
- [X] T038 Run formatting and final regression verification in `apps/platform/app/Support/Governance/PlatformVocabularyGlossary.php`, `apps/platform/app/Support/OperationCatalog.php`, `apps/platform/app/Support/ReasonTranslation/ReasonTranslator.php`, and `apps/platform/tests/Architecture/PlatformVocabularyBoundaryGuardTest.php`

---

## Dependencies & Execution Order

### Phase Dependencies

- **Setup (Phase 1)**: No dependencies; can start immediately.
- **Foundational (Phase 2)**: Depends on Setup completion; blocks all user stories.
- **User Story 1 (Phase 3)**: Depends on Foundational completion; this is the recommended MVP cut.
- **User Story 2 (Phase 4)**: Depends on Foundational completion and is easiest to review after US1 proves platform-near vocabulary hardening is stable.
- **User Story 3 (Phase 5)**: Depends on Foundational completion and benefits from US1 plus US2 because the contributor glossary is clearer once subject and operation boundaries are already explicit.
- **User Story 4 (Phase 6)**: Depends on Foundational completion and should follow US1 plus US2 so compatibility work validates the already-hardened platform surfaces.
- **Polish (Phase 7)**: Depends on all desired user stories being complete.

### User Story Dependencies

- **US1**: No dependencies beyond Foundational.
- **US2**: No hard dependency beyond Foundational, but it should follow US1 so monitoring and review semantics build on hardened subject vocabulary.
- **US3**: Depends on the shared glossary, alias, and reason-owner contracts from Foundational.
- **US4**: Depends on the shared contracts from Foundational and should follow US1 plus US2 so compatibility rules validate the final platform-facing behavior.

### Within Each User Story

- Write the story tests first and confirm they fail before implementation.
- Keep glossary, alias, and reason-owner work inside the existing governance, operation, and reason-translation seams; no parallel vocabulary framework should be introduced.
- Finish each story's focused verification before moving to the next priority.

### Parallel Opportunities

- `T002` and `T003` can run in parallel after `T001`.
- `T004`, `T005`, `T006`, and `T007` can run in parallel before `T008` through `T011`.
- Within US1, `T012` and `T013` can run in parallel.
- Within US2, `T018` and `T019` can run in parallel.
- Within US3, `T024` and `T025` can run in parallel.
- Within US4, `T030` and `T031` can run in parallel.
- `T035` and `T036` can run in parallel once implementation is complete.

---

## Parallel Example: User Story 1

```bash
# Parallel test pass for US1
T012 Extend snapshot and evidence rendering coverage
T013 Extend compare and review vocabulary coverage
```

## Parallel Example: User Story 2

```bash
# Parallel test pass for US2
T018 Extend canonical operation label, canonical operation_type read-path, DB-only render, query-shape guard, and filter continuity coverage
T019 Extend platform-versus-domain explanation layering coverage
```

## Parallel Example: User Story 3

```bash
# Parallel test pass for US3
T024 Extend glossary and registry ownership contract coverage
T025 Extend contributor-boundary guard coverage
```

## Parallel Example: User Story 4

```bash
# Parallel test pass for US4
T030 Extend Intune-first no-regression coverage for compare and review surfaces
T031 Extend compatibility and domain-owned vocabulary preservation coverage
```

---

## Implementation Strategy

### MVP First

1. Finish Setup and Foundational work.
2. Deliver US1 to remove false-universal Intune wording from platform-near compare, snapshot, and evidence surfaces.
3. Validate US1 independently before widening the slice.

### Incremental Delivery

1. Add US2 to keep monitoring, run detail, and review semantics stable during the transition.
2. Add US3 to make platform and domain ownership obvious for future contributors.
3. Add US4 to prove compatibility and Intune-first behavior remain intact.
4. Finish with copy review, guardrails, focused Sail verification, and formatting in Phase 7.

### Parallel Team Strategy

1. One contributor completes Setup and Foundational tasks.
2. After Foundation is green:
   - Contributor A takes US1.
   - Contributor B takes US2.
   - Contributor C takes US3.
   - Contributor D prepares US4 compatibility and no-regression work.
3. Merge back for Phase 7 copy review, guardrails, focused verification, and formatting.