ahmido/TenantAtlas
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects 1 Releases Wiki Activity
fc794b67e1
TenantAtlas/specs/204-platform-core-vocabulary-hardening/tasks.md
Ahmed Darrazi fc794b67e1 Spec 204: harden platform core vocabulary
2026-04-14 08:07:40 +02:00

31 KiB
Raw Blame History

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.

  • 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
  • T002 [P] Create the canonical operation vocabulary and alias resolution test scaffold in apps/platform/tests/Unit/Support/OperationTypeResolutionTest.php
  • 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.

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

  • 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
  • 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

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

  • 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
  • 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

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

  • 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
  • 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

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

  • 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
  • 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

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

  • 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
  • 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
  • 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
  • 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

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

Parallel Example: User Story 2

# 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

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

Parallel Example: User Story 4

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