ahmido/TenantAtlas
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects 1 Releases Wiki Activity
7c87a19317
TenantAtlas/specs/383-baseline-result-semantics/checklists/requirements.md
Ahmed Darrazi 7c87a19317
Some checks failed
PR Fast Feedback / fast-feedback (pull_request) Failing after 4m7s
Details
feat(baselines): implement baseline compare result semantics 
Implemented deterministic Baseline Result Semantics (Spec 383), introducing CompareSubjectResult and CompareEvidenceResult. Replaced generic arrays with strict Data Transfer Objects for Baseline engine output.
2026-06-16 22:19:10 +02:00

4.6 KiB
Raw Blame History

Requirements Checklist: Spec 383 - Baseline Compare Result Semantics and Gap Classification v1

Purpose: Validate that the preparation artifacts define a bounded, implementable, constitution-aligned runtime/result-semantics slice. Created: 2026-06-16 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 Specs 381 and 382.
  • CHK002 Related completed specs are treated as historical/dependency context only.
  • CHK003 The spec excludes resolution UI, final evidence/review readiness mapping, customer-facing Review Pack wording, report/PDF runtime work, and generic workflow engine scope.
  • CHK004 The spec states no new persisted entity/table/artifact is approved.
  • CHK005 The spec explicitly rejects old result-code compatibility readers, mappers, aliases, and historical OperationRun context readers.

UI And Filament

  • CHK010 The spec includes a UI Surface Impact decision for existing status/evidence presentation changes.
  • CHK011 The plan states no new route, navigation entry, Filament panel/provider, action, modal, drawer, wizard, Livewire component, Blade layout, or asset is planned.
  • CHK012 The plan requires UI coverage artifacts only if implementation changes route, layout, navigation, action hierarchy, or archetype rather than existing labels/groups.
  • CHK013 Browser screenshots/smoke are not required by default and become required only if implementation changes rendered layout/navigation/action behavior.
  • CHK014 The Filament v5 output contract is present for later implementation reporting.

Provider Boundary And Result Truth

  • CHK020 The provider/platform boundary is classified with platform-core result semantics and provider-owned proof metadata.
  • CHK021 Top-level result terms are provider-neutral and avoid Microsoft/Intune/policy-only semantics.
  • CHK022 Spec 382 MatchingOutcome mapping is explicit.
  • CHK023 Low-trust, display-label-only, unresolved, duplicate, unsupported, excluded, accepted-limitation, and missing-evidence outcomes cannot produce clean no drift.
  • CHK024 Missing provider resource and missing local evidence are distinct states with distinct actionability.
  • CHK025 Foundation outcomes use limitation/unsupported semantics rather than policy-backed or missing-policy semantics.

Proportionality And Bloat Control

  • CHK030 The new status/reason/category/actionability/readiness/trust family has a proportionality review.
  • CHK031 The plan explains why a narrow classifier/mapper is needed now.
  • CHK032 The plan rejects broad UI presenter, badge, workflow, report, provider, and evidence readiness frameworks.
  • CHK033 The plan requires spec/plan updates before adding persistence, new UI workflows, customer-facing readiness mapping, or compatibility readers.

RBAC, Isolation, Audit, And OperationRun

  • CHK040 Existing workspace and managed-environment scope enforcement remains required before exposing compare results.
  • CHK041 Non-member access remains deny-as-not-found and member-without-capability remains forbidden through existing policies.
  • CHK042 Structured 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.
  • CHK045 Any new summary count keys must update OperationSummaryKeys::all() and tests.

Test Readiness

  • CHK050 Unit and feature lanes are explicitly named as the narrowest proof.
  • CHK051 PostgreSQL and browser lanes are conditional and tied to concrete implementation triggers.
  • CHK052 Tasks include tests for result mapping, clean-success rules, matching outcome mapping, missing-provider versus missing-evidence, foundation limitations, OperationRun payloads, run summary aggregation, existing surface labels/groups, and evidence/review regressions.
  • CHK053 Tasks require validation commands, Pint, and git diff --check.
  • CHK054 Tasks require old authoritative reason strings to be removed or explicitly bounded outside final compare result truth.

Preparation Gate Outcome

  • CHK060 Candidate Selection Gate result: PASS.
  • CHK061 Spec Readiness Gate preparation status: ready after preparation analysis.
  • CHK062 Workflow outcome: keep as narrowed Core Enterprise runtime/result-semantics slice.