TenantAtlas/specs/419-m365-tcm-workload-registry-expansion/spec.md

Feature Specification: Spec 419 - M365 TCM Workload Registry Expansion

Feature Branch: 419-m365-tcm-workload-registry-expansion Created: 2026-06-26 Status: Draft Input: User-provided "Spec 419 - M365 TCM Workload Registry Expansion" draft plus repo checks against Specs 414, 415, 417, 418, roadmap/candidate queue, constitution, Product Surface Contract, TenantPilot agent gates, and current TenantConfiguration runtime.

Candidate Selection

• Selected candidate: Spec 419 - M365 TCM Workload Registry Expansion.
• Source location: User-provided prompt in this session. The active queue in docs/product/spec-candidates.md explicitly has no automatic next-best-prep target, so this is a direct manual promotion.
• Why selected: Specs 414, 415, 417, and 418 establish the Coverage v2 kernel, generic capture, identity engine, and operator surface. The next safe manually promoted slice is registry-only M365 workload recognition, so future Entra, Exchange, Teams, Security and Compliance, Defender, and Purview packs do not create parallel mini-platforms or premature customer claims.
• Roadmap relationship: Aligns with roadmap themes for Microsoft 365 governance expansion, provider-boundary discipline, workspace/managed-environment ownership, coverage claim safety, and no-legacy cutover. It is not auto-selected from the candidate queue.
• Close alternatives deferred: Management-report PDF runtime validation, artifact lifecycle retention, provider readiness productization, cross-domain indicator follow-through, system-panel browser fixture work, and first governed AI consumer remain manual-promotion backlog items. M365 capture, compare, render, restore, certification, Review Pack/report output, customer-facing M365 claims, and M365 dashboards are deferred to later specs.
• Related completed-spec guardrail: specs/414-tcm-first-coverage-core-cutover/, specs/415-generic-content-backed-capture/, specs/417-canonical-identity-engine/, and specs/418-coverage-v2-operator-surface/ contain completed/validated signals and are read-only dependency context. Do not rewrite them, normalize their close-out history, or strip validation/task/browser/review history.
• Prerequisite gate result: PASS. Repo truth has TenantConfigurationResourceType, TenantConfigurationSupportedScope, Coverage v2 enums, ResourceTypeRegistry, ClaimGuard, capture/evidence services, canonical identity services, and the Spec 418 operator surface. Stop if implementation discovers the Coverage v2 registry or Claim Guard is missing.
• Smallest viable implementation slice: Expand the existing Coverage v2 registry and supported-scope planning metadata so M365 workload families and representative resource types are classified as registry-only/detected internal planning truth. Do not activate capture, compare, render, restore, certification, customer output, runtime docs fetches, or new UI routes.
• Draft-to-repo deviations: The user draft names tenantpilot_internal, detected_only, compare_only, and manual_review_required; current repo truth does not have those enum values. This spec maps the intent to existing conservative states unless implementation amends enum/check constraints with proportionality proof: source_class remains tcm, graph_v1_fallback, or graph_beta_experimental; registry-only support defaults to existing out_of_scope unless a new state is justified; "compare/manual review" restore posture maps to preview_only or not_restorable, never restorable.

Spec Candidate Check (mandatory - SPEC-GATE-001)

• Problem: Coverage v2 is Intune-first. Without one shared M365 workload registry expansion, later Entra, Exchange, Teams, Security and Compliance, Defender, and Purview work can create parallel models, vocabularies, support states, claim rules, evidence semantics, and restore assumptions.
• Today's failure: Operators and implementers cannot distinguish "registry knows this M365 workload/type" from "TenantPilot captures, compares, renders, restores, certifies, or can claim customer coverage for it." That creates a high-risk path to false M365 coverage claims.
• User-visible improvement: Future operator surfaces and implementation reports can classify M365 workload/resource-type readiness honestly as registry-only/detected, with clear "not content-backed, not certified, not restore-ready" defaults.
• Smallest enterprise-capable version: Expand existing Coverage v2 enum/check constraints, registry definitions, metadata, supported scopes, and Claim Guard rules for representative M365 workloads. Use static reviewed manifest data only. No runtime remote calls, no customer output, and no new UI surface.
• Explicit non-goals: No content capture for new workloads, no TCM snapshot ingestion for all workloads, no Graph fallback capture, no live Microsoft documentation scraping, no compare/render/restore/apply, no certification, no customer-facing M365 reports, no Review Pack output, no broad M365 dashboard, no new provider framework, no workload-specific tables, no v1 compatibility, no tenant_id.
• Permanent complexity imported: Additional workload enum/check values, conservative registry entries or static manifest definitions, supported-scope planning rows, metadata conventions for documentation status/source aliases/risk/default restore posture, Claim Guard M365 deny rules, and focused tests. No new core tables are expected.
• Why now: Spec 418 made Coverage v2 inspectable. Before future M365 workload packs begin, the denominator and claim-safety model must be shared and conservative.
• Why not local: A local Entra or Exchange list would immediately create another vocabulary and claim path. The existing Coverage v2 registry is the correct shared contract and must absorb this expansion.
• Approval class: Core Enterprise.
• Red flags triggered: New taxonomy/enum values, registry expansion, and future-oriented workload coverage. Defense: this prevents concrete false coverage/restore/certification claims and uses the existing Coverage v2 registry rather than creating a new framework.
• Score: Nutzen: 2 | Dringlichkeit: 2 | Scope: 2 | Komplexitaet: 1 | Produktnaehe: 1 | Wiederverwendung: 2 | Gesamt: 10/12
• Decision: approve as a strict registry-only expansion with no capture, no customer claim activation, no UI route expansion, no runtime docs fetch, no tenant_id, and no workload-specific mini-platform.

Spec Scope Fields (mandatory)

• Scope: platform registry metadata plus existing workspace/managed-environment boundaries for any future environment-owned evidence. This spec creates product/platform registry definitions, not concrete environment resource evidence.
• Primary Routes: No new route, page, action, navigation entry, customer output, download, or report is in scope. The existing Spec 418 Coverage v2 operator surface may render the expanded registry rows/scopes through its generic data path.
• Data Ownership: tenant_configuration_resource_types and tenant_configuration_supported_scopes remain platform/product registry metadata according to current Coverage v2 design. Concrete resource/evidence rows remain workspace + managed-environment + provider-connection scoped in existing capture specs. No tenant_id is allowed as internal ownership truth.
• RBAC: No new runtime action or UI route is introduced. Existing operator surface authorization from Spec 418 may display new rows if it derives from the registry. If implementation changes rendered UI files, actions, labels, or default operator decisions beyond the data-driven registry display described here, stop and amend Product Surface/RBAC sections before runtime edits.

For canonical-view specs:

• Default filter behavior when tenant-context is active: N/A - no canonical view or route change. Existing Coverage v2 operator surface behavior remains the only possible consumer.
• Explicit entitlement checks preventing cross-tenant leakage: Registry definitions are not tenant-owned. Any future evidence/resource rows must remain scoped by workspace, managed environment, and same-scope provider connection.

No Legacy / No Backward Compatibility Constraint (mandatory)

TenantPilot is pre-production unless this spec explicitly records a compatibility exception.

• Compatibility posture: canonical Coverage v2 registry expansion; no compatibility exception.
• Legacy aliases, fallback readers, hidden routes, duplicate UI, old labels, or historical fixtures kept?: no.
• Why clean replacement is safe now: This is registry metadata only. No production/customer data or external contract requires v1 coverage compatibility. The implementation must not create v1-to-v2 adapters, old gap taxonomy, dual writes, fallback readers, old snapshot promotion, old support-state aliases, or customer-facing dual truth.

UI Surface Impact (mandatory - UI-COV-001)

Does this spec add, remove, rename, or materially change any reachable UI surface?

• No UI surface impact
• Existing page changed
• New page/route added
• Navigation changed
• Filament panel/provider surface changed
• New modal/drawer/wizard/action added
• New table/form/state added
• Customer-facing surface changed
• Dangerous action changed
• Status/evidence/review presentation changed
• Workspace/environment context presentation changed

No runtime UI file, route, navigation, action, table/form, or rendered label change is planned. The impact is data-driven: existing Spec 418 registry/readiness surfaces may show new rows, workload filters, scope options, and registry-only states because they already read active Coverage v2 registry data. If implementation requires runtime UI edits, stop and amend spec.md, plan.md, and tasks.md before editing runtime UI.

UI/Productization Coverage (mandatory when UI Surface Impact is not "No UI surface impact"; otherwise write N/A - no reachable UI surface impact plus rationale)

Existing Coverage v2 operator surface data may change without UI code edits. Productization coverage is limited to the existing Spec 418 Coverage v2 readiness/resource-type registry surface. No new route, navigation entry, action, customer surface, report, download, or primary dashboard is allowed. Registry-only wording, no-customer-claim semantics, and no capture/restore/certify affordances must remain visible-safe on that existing surface.

Product Surface Impact (mandatory for UI-affecting specs; otherwise write N/A - no rendered product surface changed plus rationale)

Reference: docs/product/standards/product-surface-contract.md.

• Product Surface Contract applies?: yes, for data-driven changes on the existing Spec 418 Coverage v2 operator surface. No UI code or route expansion is planned.
• Page archetype: existing internal/operator readiness and registry inspection surface.
• Primary user question: Which Coverage v2 registry entries and supported scopes are known, and which are registry-only rather than content-backed/customer-claimable?
• Primary action: inspect existing registry rows only. No capture, restore, certify, publish, export, or customer-output action.
• Surface budget result: existing table/filter/modal budget only; no new primary navigation, dashboard, page, action family, or customer report.
• Technical Annex / deep-link demotion: Registry metadata must avoid customer-facing raw payload/proof semantics. Any source URLs, catalog review notes, aliases, and uncertainty remain internal registry metadata.
• Canonical status vocabulary: Use existing Coverage v2 enum/status vocabulary and explicit registry-only/detected wording. Do not introduce page-local M365 coverage status truth.
• Visible complexity impact: slightly broader existing registry table/filter data; no new surface family.
• Product Surface exceptions: none.

Browser Verification Plan (mandatory)

• Browser proof required?: yes, if new active registry rows/scopes are visible through the existing Spec 418 Coverage v2 operator surface. If the implementation keeps new planning rows inactive and proves no rendered output changes, document that proof instead.
• No-browser rationale: N/A only when implementation proves no new rows/scopes render in the existing operator surface.
• Focused path when required: existing Spec 418 Coverage v2 readiness/operator route.
• Primary interaction to execute: load the existing page, inspect the resource type registry table/filter/scope selector, and verify registry-only M365 rows/scopes do not create broad claims or actions.
• Console, Livewire, Filament, network, and 500-error checks: required for the focused path when rendered data changes.
• Full-suite failure triage: If runtime UI files, labels, routes, actions, or navigation change, stop and amend this spec before continuing.

Human Product Sanity Check (mandatory)

• Required?: yes, when new registry rows/scopes render on the existing operator surface.
• No-human-sanity rationale: N/A only when implementation proves no rendered output changes.
• Reviewer questions: Does the existing Coverage v2 surface still read as internal/operator registry truth, not M365 customer coverage? Are registry-only, not content-backed, not restore-ready, and not certified boundaries clear enough without adding a new page?
• Planned result location: specs/419-m365-tcm-workload-registry-expansion/implementation-report.md.

Product Surface Merge Gate Checklist (mandatory)

• No-legacy posture or approved exception recorded.
• Product Surface Impact is completed for data-driven existing-surface impact.
• Browser proof is required if new active rows/scopes render, or N/A must be justified by proof that no rendered output changed.
• Human Product Sanity is required if new active rows/scopes render, or N/A must be justified by proof that no rendered output changed.
• Product Surface exceptions are documented or none.
• Implementation report will state Livewire v4 compliance, provider registration location, global search posture, destructive/high-impact action posture, asset strategy, tests/browser result, deployment impact, visible complexity outcome, and no completed-spec rewrite assertion.

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?: existing Coverage v2 registry/readiness interaction family may receive new data only. Registry and Claim Guard contracts are shared domain contracts, not a new UI interaction contract.
• Interaction class(es): N/A.
• Systems touched: Coverage v2 resource type registry, supported scopes, enum/check constraints, Claim Guard, static manifest/registry definitions, focused tests.
• Existing pattern(s) to extend: existing ResourceTypeRegistry, TenantConfigurationResourceType, TenantConfigurationSupportedScope, Coverage v2 enum classes, and ClaimGuard.
• Shared contract / presenter / builder / renderer to reuse: existing Coverage v2 registry and Claim Guard services. Do not create a new M365 registry service unless existing registry structure cannot support static manifest grouping after proportionality review.
• Why the existing shared path is sufficient or insufficient: Current registry already owns resource type/source/support/claim defaults. It is sufficient for M365 workload recognition when carefully expanded.
• Allowed deviation and why: none.
• Consistency impact: M365 workload packs must use the same Coverage v2 source/support/coverage/evidence/identity/claim vocabulary.
• Review focus: Verify no mini-platform registry, no old v1 vocabulary, no customer claims, and no new UI interaction family.

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.
• Delegated start/completion UX behaviors: N/A.
• Local surface-owned behavior that remains: none.
• 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. Workload/source classification is platform-core registry truth; Microsoft TCM catalog names and source URLs are provider-owned metadata.
• Seams affected: workload enum/check constraints, resource type canonical names, source classes, metadata source aliases, supported-scope keys, Claim Guard forbidden/allowed wording.
• Neutral platform terms preserved or introduced: workload, resource type, source class, support state, coverage level, evidence state, identity state, claim state, supported scope, restore tier, documentation status metadata.
• Provider-specific semantics retained and why: Microsoft workload names and TCM catalog metadata are retained because this spec is explicitly M365 TCM registry expansion. They must remain registry/source metadata and must not become tenant ownership truth.
• Why this does not deepen provider coupling accidentally: No new provider framework, provider connection model, tenant ownership key, runtime Graph/TCM calls, or workload-specific tables are introduced. Provider-native IDs stay metadata only.
• Follow-up path: later workload packs for capture/compare/render/restore/certification must use this registry and amend specs before adding customer claims.

UI / Surface Guardrail Impact (mandatory when operator-facing surfaces are changed; otherwise write N/A)

Existing Spec 418 Coverage v2 operator surfaces may show new active registry rows/scopes through existing data queries. No new route, page, navigation, action, table/form definition, Blade view, Livewire component, Filament provider, customer surface, report, or download is in scope.

Decision-First Surface Role (mandatory when operator-facing surfaces are changed)

The existing surface role remains internal operator readiness and registry inspection. New data must answer "known in registry and registry-only" rather than implying capture, content-backed evidence, certification, restore readiness, or customer coverage.

Audience-Aware Disclosure (mandatory when operator-facing surfaces are changed)

Internal/operator only. Registry metadata and workload status may be visible to authorized operators through the existing surface, but no customer-facing claim, report, Review Pack output, or public M365 coverage statement is activated.

UI/UX Surface Classification (mandatory when operator-facing surfaces are changed)

Existing page, data-only impact. No new page archetype, action family, primary navigation, modal type, wizard, or dashboard is introduced.

Operator Surface Contract (mandatory when operator-facing surfaces are changed)

The existing Spec 418 operator surface must remain read-only and claim-safe: no capture/start, restore/apply, certify, publish, export, report/download, or customer-output action; no broad M365 coverage label; no 100% M365 coverage wording; and no default scope change unless it is explicitly covered by Product Surface/browser proof.

Proportionality Review (mandatory when structural complexity is introduced)

• New source of truth?: yes, expanded registry definitions become product/platform metadata for M365 workload recognition.
• New persisted entity/table/artifact?: no new core table expected. Static registry definitions and/or existing tenant_configuration_resource_types and tenant_configuration_supported_scopes rows are the artifact. Existing JSONB metadata is preferred for documentation status, source aliases, catalog source, review date, risk tier, default restore posture notes, and is_full_catalog.
• New abstraction?: no new abstraction by default. Use existing ResourceTypeRegistry/supported-scope paths. A static config/manifest may be introduced only if it replaces scattered arrays and remains reviewed local code, not runtime docs sync.
• New enum/state/reason family?: yes, workload enum/check values must expand beyond intune. tenantpilot is included only as an internal/platform workload bucket from the user draft so future TenantPilot-owned registry rows do not overload unknown; this spec does not require TenantPilot resource entries. Additional documentation status may be metadata first. Do not add new source/support/restore enum values unless implementation proves existing values cannot express the conservative defaults.
• New cross-domain UI framework/taxonomy?: no.
• Current operator problem: Future M365 packs need one denominator and claim-safety contract so "known in registry" is not misread as "captured/certified/restorable/customer-claimable."
• Existing structure is insufficient because: Current repo truth only supports Workload::Intune and initial Intune Coverage v2 resource types. It cannot classify M365 workload families without expanding allowed workload values and registry metadata.
• Narrowest correct implementation: Add workload values and representative registry entries/scopes using existing tables/services, with conservative default coverage/evidence/claim/restore states and tests proving no overclaiming.
• Ownership cost: Maintain M365 workload/resource type manifests, conservative defaults, Claim Guard phrases, and tests as later workload packs mature.
• Alternative intentionally rejected: Per-workload models, tables, engines, dashboards, capture jobs, or customer reports. Rejected because they fragment Coverage v2 and create false product maturity.
• Release truth: current-release registry/planning truth required before later M365 evidence and compare packs.

Compatibility posture

This feature assumes a pre-production environment. Backward compatibility, legacy aliases, migration shims, historical fixtures, v1 adapters, fallback readers, and dual writes are out of scope.

Testing / Lane / Runtime Impact (mandatory for runtime behavior changes)

• Test purpose / classification: Unit for enum/default manifest/Claim Guard behavior; Feature for persisted registry/supported-scope seed behavior, no-overclaim, no-runtime-capture, no-mini-platform, no-tenant-id guards.
• Validation lane(s): fast-feedback and confidence. PostgreSQL lane required if check constraints, JSONB constraints, unique indexes, or migrations are changed. Focused browser lane required if active rows/scopes render on the existing Spec 418 operator surface.
• Why this classification and these lanes are sufficient: Registry expansion is service/config/persistence truth. Unit and feature tests prove classification, default-scope safety, and claim safety; focused browser proof is needed only for the existing rendered surface when active registry rows/scopes become visible.
• New or expanded test families: focused Spec 419 TenantConfiguration unit/feature tests, plus a focused existing-surface browser smoke when rendered rows/scopes change. No broad heavy-governance browser family by default.
• Fixture / helper cost impact: keep fixtures local or opt-in; do not broaden default TenantConfiguration factories or browser setup.
• Heavy-family visibility / justification: none.
• Special surface test profile: focused existing Coverage v2 operator-surface proof if active rows/scopes render.
• Standard-native relief or required special coverage: Browser proof may be N/A only when implementation proves no rendered output changed.
• Reviewer handoff: Reviewers must verify lane fit, exact conservative defaults, default-scope safety, Product Surface data-impact proof, no runtime remote calls, no tenant_id, no mini-platforms, and no customer claims.
• Budget / baseline / trend impact: none expected; document if focused registry tests materially widen confidence lane runtime.
• Escalation needed: document-in-feature for contained enum/metadata expansion; follow-up-spec if implementation requires full catalog import tooling, UI, capture, or new persistent registry tables.
• Active feature PR close-out entry: Guardrail / Exception / Smoke Coverage with focused existing-surface proof or explicit proof that no rendered output changed.
• Planned validation commands:
  • cd apps/platform && ./vendor/bin/sail bin pint --dirty --format agent
  • cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Unit/Support/TenantConfiguration/Spec419M365WorkloadRegistryTest.php tests/Unit/Support/TenantConfiguration/Spec419M365ResourceTypeManifestTest.php tests/Unit/Support/TenantConfiguration/Spec419M365ClaimGuardTest.php tests/Unit/Support/TenantConfiguration/Spec419M365RestoreTierDefaultTest.php tests/Unit/Support/TenantConfiguration/Spec419M365DocumentationStatusTest.php
  • cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Feature/TenantConfiguration/Spec419M365RegistryExpansionTest.php tests/Feature/TenantConfiguration/Spec419M365SupportedScopesTest.php tests/Feature/TenantConfiguration/Spec419M365NoOverclaimTest.php tests/Feature/TenantConfiguration/Spec419M365NoRuntimeCaptureTest.php tests/Feature/TenantConfiguration/Spec419M365NoMiniPlatformTest.php tests/Feature/TenantConfiguration/Spec419M365NoTenantIdTest.php
  • cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Browser/Spec419M365RegistryOperatorSurfaceSmokeTest.php if active rows/scopes render on the existing operator surface, or the repo-equivalent focused browser smoke path
  • cd apps/platform && ./vendor/bin/sail php vendor/bin/pest -c phpunit.pgsql.xml tests/Feature/TenantConfiguration/Spec419M365RegistryExpansionTest.php tests/Feature/TenantConfiguration/Spec419M365SupportedScopesTest.php if migrations/check constraints/indexes change
  • git diff --check

User Scenarios & Testing (mandatory)

User Story 1 - Classify M365 Workloads In Coverage v2 (Priority: P1)

As a platform reviewer, I need Coverage v2 to recognize M365 workload families under one shared registry so future domain packs do not invent their own models or vocabulary.

Independent Test: Focused registry tests assert workloads entra, exchange, teams, security_compliance, defender, and purview are accepted/classified without creating workload-specific tables.

Acceptance Scenarios:

1. Given the registry defaults are synchronized, When workload values are inspected, Then Intune plus the new M365 workload values are available under the shared Coverage v2 registry.
2. Given Defender and Purview do not have separate mapped resource catalogs in this spec, When workload metadata is inspected, Then they are represented as overview-only or combined-catalog planning status without fake certified resource entries.

User Story 2 - Seed Representative Registry-Only Resource Types (Priority: P1)

As a release reviewer, I need representative Entra, Exchange, Teams, and Security and Compliance resource types seeded with conservative defaults so later packs start from honest denominator metadata.

Independent Test: Feature tests assert required representative canonical types exist with source_class = tcm, default_coverage_level = detected, default_evidence_state = not_captured, default_claim_state = internal_only or claim_blocked, and no default certified/restorable/customer claim state.

Acceptance Scenarios:

1. Given the registry contains Entra seed entries, When conditionalAccessPolicy, securityDefaults, application, servicePrincipal, roleDefinition, and administrativeUnit are inspected, Then they are registry-only/detected and not auto-restorable.
2. Given the registry contains Exchange seed entries, When transportRule, acceptedDomain, sharedMailbox, remoteDomain, mailboxPlan, and organizationConfig are inspected, Then mailflow/org defaults are conservative and no restore-ready claim is possible.
3. Given the registry contains Teams seed entries, When appPermissionPolicy, appSetupPolicy, meetingPolicy, messagingPolicy, teamsUpdateManagementPolicy, and voiceRoute are inspected, Then entries are registry-only/detected and manual-review/preview-only at most.
4. Given the registry contains Security and Compliance seed entries, When labelPolicy, retentionCompliancePolicy, dlpCompliancePolicy or a repo-canonical equivalent, autoSensitivityLabelPolicy, protectionAlert, and complianceTag are inspected, Then high-risk defaults block restore/certified claims.

User Story 3 - Block Broad M365 Claims (Priority: P1)

As a product reviewer, I need Claim Guard to block broad M365, certified, restore-ready, and "100%" claims unless the statement is explicitly registry-only and denominator-scoped.

Independent Test: Claim Guard tests assert broad M365 phrases are blocked and internal scoped registry-only phrases are allowed only with explicit seeded denominator wording.

Acceptance Scenarios:

1. Given a claim says "100% Microsoft 365 coverage", When Claim Guard evaluates it, Then the claim is blocked.
2. Given a claim says "Certified M365 coverage" or "Restore-ready M365 coverage", When Claim Guard evaluates it, Then the claim is blocked.
3. Given a claim says "100% registry coverage for seeded Entra resource type entries" and remains internal/operator-only, When Claim Guard evaluates it, Then the claim may be allowed or limited according to exact scope metadata.

User Story 4 - Prove Registry-Only Boundaries (Priority: P1)

As an implementation reviewer, I need tests proving Spec 419 does not add runtime capture, customer output, UI activation, tenant_id, or workload-specific mini-platforms.

Independent Test: Guard tests inspect changed files/schema/service registrations and assert no Graph/TCM runtime calls, no capture job/action, no concrete resource/evidence rows created by registry seed, no tenant_id, and no entra_*, exchange_*, teams_*, purview_*, defender_*, or security_compliance_* tables/classes.

Acceptance Scenarios:

1. Given the implementation diff is reviewed, When runtime code is inspected, Then no Graph/TCM/provider remote call path or runtime Microsoft docs fetch is added.
2. Given the implementation diff is reviewed, When schema/classes are inspected, Then no workload-specific mini-platform table/class namespace is introduced.
3. Given registry seeds run, When concrete Coverage v2 resource/evidence tables are inspected, Then no concrete environment-owned evidence rows are created by registry expansion.

Functional Requirements (mandatory)

• FR-419-001: The implementation MUST expand or confirm Coverage v2 workload support for intune, entra, exchange, teams, security_compliance, defender, purview, tenantpilot, and unknown, using existing enum/check-constraint patterns.
• FR-419-002: The implementation MUST keep intune existing entries intact and MUST NOT duplicate existing Intune defaults.
• FR-419-003: The implementation MUST record documentation status for workload/resource catalog entries using existing JSONB metadata first unless a dedicated column is proven necessary.
• FR-419-004: Documentation status values MUST include documented_resource_catalog, documented_overview_only, combined_catalog, graph_only, internal, and unknown as metadata or a justified enum/constraint.
• FR-419-005: New M365 representative entries MUST default to registry-only/detected: default_coverage_level = detected, default_evidence_state = not_captured, and default_claim_state = internal_only or claim_blocked.
• FR-419-006: New M365 representative entries MUST NOT default to content_backed, comparable, renderable, restorable, certified, or claim_allowed.
• FR-419-007: New M365 representative entries MUST use source_class = tcm when they are TCM-documented.
• FR-419-008: Source class values MUST remain limited to current repo values unless implementation amends the enum/check constraints with proportionality proof. tenantpilot_internal is not required for this M365 TCM slice.
• FR-419-009: If a resource is not TCM-documented and is included only as future Graph fallback, it MUST default to graph_v1_fallback, default_coverage_level = detected, default_evidence_state = not_captured, default_claim_state = claim_blocked, and no customer claim.
• FR-419-010: Beta/experimental resources, if any are added, MUST use graph_beta_experimental, support_state = experimental, default_coverage_level = detected, default_evidence_state = not_captured or schema_unknown, default_claim_state = claim_blocked, and no beta/certified claims.
• FR-419-011: Entra representative entries MUST include conditionalAccessPolicy, securityDefaults, application, servicePrincipal, roleDefinition, and administrativeUnit.
• FR-419-012: Exchange representative entries MUST include transportRule, acceptedDomain, sharedMailbox, remoteDomain, mailboxPlan, and organizationConfig.
• FR-419-013: Teams representative entries MUST include appPermissionPolicy, appSetupPolicy, meetingPolicy, messagingPolicy, teamsUpdateManagementPolicy, and voiceRoute.
• FR-419-014: Security and Compliance representative entries MUST include labelPolicy, retentionCompliancePolicy, dlpCompliancePolicy or a repo-canonical equivalent with aliases, autoSensitivityLabelPolicy, protectionAlert, and complianceTag.
• FR-419-015: Defender MUST be represented as workload-level overview-only or combined-catalog metadata under tenant_configuration_supported_scopes.metadata.workload_documentation_status.defender on the aggregate M365 planning scope unless repo/current official mapping already ties Defender resource types to shared Security and Compliance entries. Do not invent fake Defender certified resource types.
• FR-419-016: Purview MUST be represented as workload-level overview-only or combined-catalog metadata under tenant_configuration_supported_scopes.metadata.workload_documentation_status.purview on the aggregate M365 planning scope unless repo/current official mapping already ties Purview resource types to shared Security and Compliance entries. Do not invent fake Purview certified resource types.
• FR-419-017: Partial/seeded catalogs MUST be marked explicitly with is_full_catalog = false or equivalent metadata and MUST NOT be displayed or claimed as full workload coverage.
• FR-419-018: Supported-scope planning entries MUST include m365_tcm_registry_detected, entra_tcm_registry_detected, exchange_tcm_registry_detected, teams_tcm_registry_detected, security_compliance_tcm_registry_detected, m365_tcm_generic_future, and m365_tcm_certified_none.
• FR-419-019: Supported-scope planning entries MUST NOT include forbidden broad scopes such as m365_full_coverage, m365_certified, all_microsoft_365_supported, full_tenant_coverage, or full_m365_restore_ready.
• FR-419-020: Claim Guard MUST block broad claims including "100% Microsoft 365 coverage", "Full M365 coverage", "Certified M365 coverage", "Restore-ready M365 coverage", "Complete tenant coverage", "All Microsoft 365 resources supported", and "All TCM resources certified".
• FR-419-021: Claim Guard MAY allow internal registry-only wording only when it is explicitly denominator-scoped, for example "100% registry coverage for seeded Entra resource type entries".
• FR-419-022: Restore posture for high-risk M365 resources MUST use not_restorable or preview_only; it MUST NOT use restorable.
• FR-419-023: The implementation MUST NOT add runtime HTTP fetches, Microsoft Learn scraping, Graph calls, TCM calls, scheduler sync, queue sync, capture jobs, start actions, or customer output for this registry expansion.
• FR-419-024: The implementation MUST NOT create workload-specific tables, domain engines, mini-platform namespaces, or standalone M365 dashboards.
• FR-419-025: The implementation MUST NOT introduce tenant_id as Coverage v2 internal ownership truth.
• FR-419-026: The implementation MUST NOT create concrete environment-owned TenantConfigurationResource or TenantConfigurationResourceEvidence rows as part of registry seed/sync.
• FR-419-027: New supported-scope planning rows MUST NOT accidentally change the existing Coverage v2 operator surface default scope selection. If active planning scopes would sort before current Intune scopes, implementation MUST keep them inactive, introduce an explicit default-ordering contract, or amend Product Surface/browser proof to cover the changed default.
• FR-419-028: Because the existing Spec 418 operator surface reads active Coverage v2 registry data, implementation MUST treat visible new rows/scopes as a data-driven Product Surface impact and provide focused proof that no broad M365 coverage label, customer claim, capture/start action, restore action, certification action, report/download, or new primary navigation appears.
• FR-419-029: If implementation changes any rendered UI file, route, navigation, Filament page/provider, action, report, download, or customer surface beyond the existing data-driven registry display, work MUST stop until Product Surface Impact, Browser Verification Plan, Human Product Sanity, and focused browser proof tasks are amended.

Non-Functional Requirements (mandatory)

• NFR-419-001: Registry sync/seed behavior MUST be deterministic and idempotent.
• NFR-419-002: Static manifest/config data MUST contain no secrets, tenant-specific values, raw provider payloads, or customer data.
• NFR-419-003: Migrations/check constraints MUST be reversible where practical and must avoid long locks.
• NFR-419-004: Tests MUST fail if partial catalogs are treated as full workload coverage.
• NFR-419-005: Tests MUST fail if broad M365/certified/restore-ready claims become allowed.
• NFR-419-006: Tests MUST fail if runtime Graph/TCM/docs-fetch code is added in this spec.
• NFR-419-007: Tests MUST fail if tenant_id or workload-specific mini-platform tables/classes appear in Spec 419 changes.

Key Entities (include if feature involves data)

• TenantConfigurationResourceType: Existing Coverage v2 registry definition for canonical resource type, source class, workload, support state, default coverage/evidence/identity/claim state, restore tier, and metadata.
• TenantConfigurationSupportedScope: Existing supported-scope definition for denominator planning, minimum coverage level, included resource types, beta/fallback allowance, customer claim allowance, and metadata.
• ResourceTypeRegistry: Existing service/static registry path that should be expanded rather than replaced.
• ClaimGuard: Existing service that blocks unsafe coverage claims and must receive M365 broad-claim guard behavior.
• Workload metadata: Existing enum/check values plus metadata representing documentation status and catalog completeness; no separate workload table by default.

Acceptance Criteria (mandatory)

• AC-419-001: Coverage v2 can classify Entra, Exchange, Teams, Security and Compliance, Defender, and Purview workload families.
• AC-419-002: Required representative Entra, Exchange, Teams, and Security and Compliance resource types exist in registry definitions.
• AC-419-003: Defender and Purview are represented safely without fake certified resource entries.
• AC-419-004: Full versus seeded/partial catalog status is explicit.
• AC-419-005: Broad M365, certified, restore-ready, complete-tenant, and all-resource claims are blocked.
• AC-419-006: No M365-wide certified or full-coverage supported scope exists.
• AC-419-007: New non-Intune entries default to detected/not-captured/internal-only or claim-blocked, not content-backed/comparable/renderable/restorable/certified.
• AC-419-008: No Graph/TCM/provider runtime call, capture job, scheduler, docs fetch, or concrete resource/evidence creation is added.
• AC-419-009: No tenant_id, v1 gap taxonomy, v1-to-v2 adapter, dual write, fallback reader, or old snapshot promotion is added.
• AC-419-010: No workload-specific mini-platform table/class/engine is introduced.
• AC-419-011: UI impact is explicitly no-impact, or the spec is amended before any UI change.
• AC-419-012: Focused unit/feature tests and git diff --check pass, with PostgreSQL lane included if check constraints/migrations change.

Success Criteria (mandatory)

• SC-419-001: Implementation report includes workload matrix with documentation status, entries added, full catalog decision, default support, and claim state.
• SC-419-002: Implementation report includes representative resource type matrix with source class, support state, coverage level, restore tier, and claim state.
• SC-419-003: Claim Guard proof shows forbidden broad claims blocked and scoped internal registry-only wording handled safely.
• SC-419-004: Static/no-runtime-capture proof shows no remote calls, no docs fetch, no capture jobs, and no concrete evidence rows.
• SC-419-005: Product Surface proof records focused existing-surface browser/Human Product Sanity results when active rows/scopes render, or records exact proof that no rendered output changed.

Assumptions

• Specs 414, 415, 417, and 418 remain completed/validated dependency context.
• Microsoft TCM catalog names in the user draft are accepted as planning input for representative entries; implementation must keep source metadata explicit and reviewable.
• The initial implementation may use seeded/partial representative catalogs instead of a full static manifest if full catalog import is too large for a bounded review.
• Existing metadata JSONB is sufficient for documentation status, catalog source, aliases, review date, risk tier, and full-vs-partial marker unless implementation proves a queryable column is required.
• Existing preview_only restore tier is the repo-real conservative equivalent for compare/manual-review planning posture; no auto-restore claim is allowed.
• Existing Spec 418 operator surfaces may render active registry rows/scopes generically; implementation must either keep new planning rows from changing rendered output or run the focused existing-surface proof required by this spec.
• tenantpilot is included as an internal/platform workload value only; no TenantPilot-owned resource types or customer claims are required in this spec.

Open Questions

None blocking. Implementation must make three bounded choices and record them in the implementation report:

1. Whether to use representative seeded entries only or a full static reviewed manifest for documented Entra, Exchange, Teams, and Security and Compliance resource catalogs.
2. Whether documentation status stays in metadata or needs a narrow column/constraint because tests or query paths require it.
3. Whether new planning scopes are inactive, explicitly ordered, or otherwise guarded so the existing Coverage v2 operator surface default scope does not accidentally switch away from the current Intune default.

Risks

Risk	Severity	Mitigation
Registry expansion becomes capture implementation	High	No remote calls, no capture jobs, no OperationRun, guard tests
Partial catalog presented as full	High	is_full_catalog = false, documentation status, tests
Broad M365 overclaim	High	Claim Guard tests and forbidden scope checks
Restore overclaim for high-risk domains	High	not_restorable or preview_only, never restorable
Domain mini-platforms appear	High	shared Coverage v2 registry only, static guards
Defender/Purview ambiguity	Medium	overview-only/combined metadata, no fake certified resource types
Provider coupling leaks into platform core	High	source metadata only, no tenant_id, no provider-native IDs as ownership
Enum/check constraint expansion causes drift	Medium	proportionality review, focused tests, PostgreSQL lane if constraints change

Follow-Up Spec Candidates

• M365 Generic Evidence Coverage Pack.
• Entra Core Comparable/Renderable Pack.
• Exchange and Teams Comparable Pack.
• Security and Compliance Readiness Pack.
• Entra Certified Compare Pack.
• Exchange/Teams Certified Pack.
• Security and Compliance Compare Pack.
• Customer-facing M365 coverage/reporting only after evidence, compare/render, and certification truth exists.