TenantAtlas/specs/382-baseline-matching-canonicalization/checklists/requirements.md

Requirements Checklist: Spec 382 - Baseline Matching Pipeline and Canonicalization v1

Purpose: Validate that the preparation artifacts define a bounded, implementable, constitution-aligned runtime slice for baseline matching and canonicalization. Created: 2026-06-15 Feature: spec.md

Note: This checklist covers preparation quality only. It does not mark implementation work complete.

Applicability And Scope

• CHK001 The selected candidate is user-provided and directly follows completed Spec 381.
• CHK002 Related completed specs are treated as historical/dependency context only.
• CHK003 The spec excludes resolution UI, result semantics rewrite, evidence/review readiness, customer-facing report changes, and generic workflow engine scope.
• CHK004 The spec states no new persisted entity/table/artifact is approved.

UI And Filament

• CHK010 The spec includes exactly one UI Surface Impact decision: checked No UI surface impact with rationale.
• CHK011 The plan states no Filament Resource, Page, RelationManager, action, route, navigation, Livewire component, Blade view, or asset change is planned.
• CHK012 Browser screenshots and page reports are not required because no reachable UI surface changes.

Provider Boundary And Matching Truth

• CHK020 The provider/platform boundary is classified as mixed.
• CHK021 Core matching is required to stay provider-neutral and avoid Microsoft/Intune display-label hardcoding.
• CHK022 Fake-provider tests are required to prove the canonicalization seam.
• CHK023 Active provider resource bindings are required to resolve before canonical/provider identity matching.
• CHK024 Display names are UI/descriptive labels only and are not matching, canonical-key, or binding lookup inputs.
• CHK025 Tenant-owned duplicate provider-resource identity candidates without binding remain unresolved ambiguity.

Proportionality And Bloat Control

• CHK030 The new pipeline/registry/outcome abstractions have a proportionality review.
• CHK031 The plan rejects a generic provider workflow engine and broad multi-provider framework.
• CHK032 The plan requires spec/plan updates before any new persistence, UI, broad result taxonomy, or evidence/review behavior is added.
• CHK033 Foundation coverage must reuse existing metadata before introducing a new classification source.

RBAC, Isolation, Audit, And OperationRun

• CHK040 Matching and binding reads are scoped by workspace and managed environment.
• CHK041 Non-member access is deny-as-not-found and member-without-capability remains forbidden where relevant.
• CHK042 Matching proof metadata must be sanitized and exclude secrets/raw sensitive provider payloads.
• CHK043 Existing baseline compare OperationRun lifecycle is reused without new start/completion/link UX.
• CHK044 No direct OperationRun.status or OperationRun.outcome transitions are approved.

Test Readiness

• CHK050 Unit and feature lanes are explicitly named as the narrowest proof.
• CHK051 PostgreSQL-backed validation is required because Spec 382 drops the committed legacy_subject_key column.
• CHK052 Tasks include tests for binding-first matching, duplicate ambiguity, fake-provider canonicalization, foundation coverage, canonical-key rejection, and compare strategy preservation.
• CHK053 Tasks require validation commands, Pint, and git diff --check.

Preparation Gate Outcome

• CHK060 Candidate Selection Gate result: PASS.
• CHK061 Spec Readiness Gate preparation status: ready pending analyze.
• CHK062 Workflow outcome: keep as narrowed Core Enterprise runtime slice.