TenantAtlas/specs/421-entra-core-comparable-renderable-pack/checklists/requirements.md

Requirements Checklist: Spec 421 - Entra Core Comparable / Renderable Pack

Purpose: Validate preparation completeness and quality before implementation. This checklist validates spec.md, plan.md, and tasks.md; it does not mark implementation work complete.
Created: 2026-06-27
Feature: specs/421-entra-core-comparable-renderable-pack/spec.md

Preparation Checklist

• Candidate is user-provided, not auto-selected from the empty active candidate queue.
• Spec 421 did not already exist in specs/ before creation.
• No existing local/remote 421-entra-core-comparable-renderable-pack branch was found before creation.
• Specs 414, 415, 417, 418, 419, and 420 are read-only dependency context only.
• Current repo truth for Coverage v2 registry, generic evidence, canonical identity, Claim Guard, redaction, OperationRun, and existing operator surface was checked.
• Draft-to-repo deviations are documented.
• No application implementation was performed during preparation.

Candidate Scope Checklist

• Scope is bounded to selected Entra comparable/renderable support.
• conditionalAccessPolicy is the mandatory evidence-backed first promotion path.
• securityDefaults and optional Entra types are evidence-gated instead of assumed content-backed.
• No capture expansion, source contract creation, restore, certification, customer output, report/download, or new UI start action is in scope.
• No Entra-specific table family, persisted compare history, mini-platform, provider framework, or tenant_id is in scope.

Product Surface Checklist

• UI Surface Impact records existing Coverage v2 operator-surface rendering impact.
• Product Surface Contract is referenced and applied.
• Page archetype, primary question, primary action, surface budget, Technical Annex demotion, canonical vocabulary, visible complexity, and exceptions are recorded.
• Browser proof is required if rendered output changes, or N/A - no rendered UI surface changed must be justified.
• Human Product Sanity is required if rendered output changes, or N/A must be justified.
• Product Surface exceptions are none.
• Stop-and-amend rule exists for any new route, navigation, action, dashboard, customer output, report, download, restore/certify control, or broader UI scope.

OperationRun / RBAC / Scope Checklist

• No new OperationRun type or start/completion/link UX is planned.
• Existing OperationRun references remain diagnostic only if rendered.
• Existing Coverage v2 read authorization applies.
• Non-member or wrong workspace/environment scope denies as not found.
• Established member without capability denies as forbidden.
• Provider connection scope must match workspace and managed environment.

Evidence / Compare / Render Checklist

• Promotion requires content-backed evidence and focused tests.
• Missing-evidence types remain unpromoted with blockers/deferred reasons.
• Compare classifications are explicit and deterministic.
• Derived importance labels are non-persisted compare output only.
• Volatile fields, null/empty handling, stable ordering, redaction, and unsupported fields are addressed.
• Render output hides raw payloads and secrets by default.
• Credential-related values render only as safe summaries if applicable.

Claim / Customer Output Checklist

• Scoped internal comparable/renderable claims are allowed only when proven.
• Certified, restore-ready, customer-ready, full, all-resource, and 100 percent Entra/M365 claims are blocked.
• No customer-facing route, Review Pack, management report, PDF, export, download, or customer-safe proof is in scope.
• Customer output gate remains N/A/no output for this spec.

Testing Checklist

• Unit tests are planned for normalization, compare, render, redaction, and Claim Guard.
• Feature tests are planned for evidence-gated promotion, RBAC/scope, no restore/certification, no tenant_id, no mini-platform, and no overclaim.
• Browser proof is conditional on rendered output changes.
• No live Graph/TCM/provider call is required for tests.
• Validation commands are listed.

Spec Readiness Checklist

• Problem statement, product value, user stories, requirements, acceptance criteria, success criteria, assumptions, risks, and open questions are present.
• Plan identifies likely affected repo surfaces and does not require application implementation during preparation.
• Tasks are ordered, bounded, verifiable, and include validation and close-out tasks.
• RBAC, workspace/managed-environment isolation, OperationRun semantics, evidence/result truth, Product Surface, provider boundary, test governance, and proportionality are addressed.
• No open question blocks the narrowed implementation-ready slice.

Review Outcome

• Review outcome class: acceptable-special-case for preparation.
• Workflow outcome: keep.
• Remaining condition: implementation must document any non-promoted Entra type as a blocker/deferred result instead of expanding capture scope.