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

Requirements Checklist: Spec 419 - M365 TCM Workload Registry Expansion

Preparation Checklist

• Candidate is user-provided, not auto-selected from the empty active candidate queue.
• Spec 414 is completed/validated dependency context only.
• Spec 415 is completed/validated dependency context only.
• Spec 417 is completed/validated dependency context only.
• Spec 418 is completed/validated dependency context only.
• No existing specs/419-* package was found before creation.
• Existing Coverage v2 registry, supported scopes, enums, ResourceTypeRegistry, and ClaimGuard were verified as repo truth.
• Draft-to-repo deviations are documented.
• No application implementation was performed during preparation.

Scope Checklist

• Scope is registry expansion only.
• No capture implementation is in scope.
• No compare/render/restore/certification is in scope.
• No customer-facing claims are in scope.
• No new primary navigation or UI route is in scope.
• No domain-specific mini-platform is in scope.
• No runtime Microsoft docs fetch is in scope.

Product Surface Checklist

• UI Surface Impact records existing Spec 418 operator-surface data impact without runtime UI code scope.
• Product Surface Impact covers data-driven existing-surface impact.
• Browser proof is required if active rows/scopes render, or N/A only with proof that no rendered output changed.
• Human Product Sanity is required if active rows/scopes render, or N/A only with proof that no rendered output changed.
• Product Surface exceptions are none.
• Stop-and-amend rule exists for any runtime UI file, route, navigation, action, report, download, or rendered label change beyond data-driven existing registry display.

Workload Requirements Specified

• Entra workload registration is required.
• Exchange workload registration is required.
• Teams workload registration is required.
• Security and Compliance workload registration is required.
• Defender safe overview/combined representation is required.
• Purview safe overview/combined representation is required.
• Defender/Purview representation uses aggregate supported-scope metadata, not fake certified resource types.
• tenantpilot and unknown workload posture is covered.

Resource Type Requirements Specified

• Entra representative entries are listed.
• Exchange representative entries are listed.
• Teams representative entries are listed.
• Security and Compliance representative entries are listed.
• Defender/Purview uncertainty is explicit.
• Full vs seeded/partial catalog decision is explicit.
• Partial list must not be presented as full.

Source / Support State Requirements Specified

• TCM entries use source_class = tcm.
• Current repo source classes remain authoritative unless amended with proportionality proof.
• New non-Intune entries default to detected/registry-only.
• No new entry defaults to content-backed.
• No new entry defaults to comparable.
• No new entry defaults to renderable.
• No new entry defaults to certified.
• No new entry defaults to restore-ready.
• Existing repo restore tiers are mapped safely: not_restorable or preview_only, never restorable.

Supported Scope Requirements Specified

• Registry-only M365 detected scope is required.
• Per-workload registry detected scopes are required.
• Future generic scope is clearly future-only.
• Certified M365 scope is explicitly none.
• Broad full/certified M365 scope names are forbidden.

Claim Guard Requirements Specified

• Broad M365 coverage claims must be blocked.
• Certified M365 claims must be blocked.
• Restore-ready M365 claims must be blocked.
• Registry-only claims are internal/operator and denominator-scoped.
• Percent claims require explicit denominator and registry-only wording.

No Runtime Capture Requirements Specified

• No Graph/TCM calls may be added.
• No runtime Microsoft docs fetch may be added.
• No capture job/action may be added.
• No concrete resources/evidence may be created by registry expansion.
• No OperationRun-producing workflow is planned.

No Legacy / Ownership Requirements Specified

• No tenant_id.
• No old gap taxonomy.
• No v1-to-v2 adapter.
• No fallback reader.
• No dual writes.
• Provider-native tenant/directory/account IDs remain metadata only.

Test Requirements Specified

• Unit tests cover workloads, manifest/defaults, claims, restore tiers, documentation status, and partial-vs-full catalog behavior.
• Feature/static guards cover registry/scopes/no-overclaim/no-capture/no-mini-platform/no-tenant-id.
• No real Graph/TCM/provider calls are allowed.
• Test lane impact is documented.
• Browser proof is required if active rows/scopes render on the existing Spec 418 operator surface.

Future Implementation Gate

• M365 workload registry expansion exists.
• New workload entries are registry-only/detected by default.
• Representative resource types exist.
• Full vs partial catalog status is explicit.
• Claim Guard blocks broad M365/certified/restore claims.
• No runtime capture is added.
• No customer-facing claim is activated.
• No tenant_id is introduced.
• No mini-platform tables/classes are introduced.
• Focused tests pass.
• Product Surface data-impact decision is confirmed, including browser/Human Product Sanity proof or exact N/A proof.

Spec Readiness Gate

• spec.md exists.
• plan.md exists.
• tasks.md exists.
• Requirements are bounded and testable.
• Plan identifies likely affected repo surfaces.
• Tasks are ordered, small, verifiable, and include validation.
• Product Surface, RBAC/no-UI, workspace/provider isolation, OperationRun/no-run, evidence/result truth, provider boundary, no-legacy, and test governance are addressed.
• No open question blocks safe implementation.

Gate Results

• Candidate Selection Gate: PASS.
• Spec Readiness Gate: PASS for preparation; implementation must still follow tasks.md.