ahmido/TenantAtlas
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects 1 Releases Wiki Activity
332f6325cb
TenantAtlas/specs/398-decision-page-contract-migration/checklists/requirements.md
ahmido 6da925bd52 feat: migrate decision page contracts to productized flow (#469) 
Automated PR provided by Codex via Gitea API.

Co-authored-by: Ahmed Darrazi <ahmed.darrazi@live.de>
Reviewed-on: #469
2026-06-22 18:16:05 +00:00

6.0 KiB
Raw Blame History

Requirements Checklist: Spec 398 - Decision Page Contract Migration v1

Purpose: Validate specification and preparation quality before implementation. Created: 2026-06-22 Feature: specs/398-decision-page-contract-migration/spec.md

Candidate Selection

  • CHK001 Selected candidate exists in user-provided source material and is not invented.
  • CHK002 Selected candidate is supported by repo truth: Spec 395 explicitly deferred a Decision Page Reduction Pass.
  • CHK003 Active auto-prep queue was checked; docs/product/spec-candidates.md says no safe automatic target remains, so this is treated as a manually provided candidate.
  • CHK004 Related specs were checked as context and are not being rewritten or converted back to preparation state.
  • CHK005 Close alternatives are deferred because they are manual-promotion only, already spec-backed, or outside the selected decision-page migration scope.
  • CHK006 The selected slice is bounded to existing Baseline Compare and Restore Preview / Readiness surfaces, with Risk Exception optional only if narrow.

Content Quality

  • CHK007 Spec states the concrete operator problem and current failure mode.
  • CHK008 Spec explains user-visible improvement and business/product value.
  • CHK009 Primary users/operators are identified through user stories.
  • CHK010 User stories are prioritized and independently testable.
  • CHK011 Functional requirements are testable and use stable IDs.
  • CHK012 Non-functional, UX, RBAC/security, auditability/observability, and data/truth requirements are present.
  • CHK013 Out-of-scope boundaries are explicit and prevent scope creep.
  • CHK014 Acceptance criteria and success criteria are measurable enough for implementation close-out.
  • CHK015 Assumptions and open questions are documented, with no blocking open question.

Product Surface Contract

  • CHK016 Spec references docs/product/standards/product-surface-contract.md.
  • CHK017 No-legacy posture is explicit: canonical replacement, no duplicate old/new decision UI, no compatibility toggle.
  • CHK018 Product Surface Impact names Decision Page / Wizard Page with Decision Sub-Surface archetypes, primary user questions, one-primary-action rule, surface budgets, technical demotion, status vocabulary, visible complexity outcome, and exceptions.
  • CHK019 Browser proof is required because rendered UI changes are expected.
  • CHK020 Human Product Sanity is required and has concrete review questions.
  • CHK021 Product Surface exceptions are none planned; any exception is a stop condition requiring spec/plan update.
  • CHK022 Completed historical specs must not be rewritten, normalized, reopened, or stripped of validation/browser/task history.
  • CHK023 UI Action Matrix names primary, secondary, technical/audit, dangerous/high-impact actions, and mutation scope for each target surface.
  • CHK024 UI coverage registry decision is explicit for route inventory, design coverage matrix, page reports, strategic surfaces, grouped follow-ups, and unresolved pages.

Constitution And Architecture

  • CHK025 Spec has a completed Spec Candidate Check with approval class, score, red flags, and decision.
  • CHK026 Proportionality review confirms no new persisted entity, enum/status family, abstraction, registry, resolver, taxonomy, or broad UI framework is approved.
  • CHK027 Plan states no Graph calls, migrations, queues, env vars, storage changes, or package changes are expected.
  • CHK028 Plan names likely affected repo surfaces without requiring application edits during preparation.
  • CHK029 Workspace/tenant isolation and deny-as-not-found requirements are preserved.
  • CHK030 RBAC/security requirements state UI visibility is not authorization.
  • CHK031 OperationRun remains execution/evidence truth and no OperationRun lifecycle or notification behavior is changed.
  • CHK032 Data/truth-source requirements distinguish execution truth, artifact truth, backup/snapshot truth, recovery/evidence truth, and operator next action.

Filament / Livewire / Actions

  • CHK033 Plan states Filament v5 / Livewire v4.1.4 compliance.
  • CHK034 Plan states Laravel 12 provider registration location: apps/platform/bootstrap/providers.php.
  • CHK035 Global search posture must remain safe for any changed resource.
  • CHK036 Destructive/high-impact actions must keep ->action(...), confirmation, authorization, audit where mutating, and tests if touched.
  • CHK037 Asset strategy is recorded: no new assets expected, filament:assets only if implementation registers assets.
  • CHK038 UI implementation must reuse native Filament and existing shared primitives before local Blade/CSS.

Test Governance

  • CHK039 Test lanes are named: Unit only for pure helpers, Feature/Filament for page/action visibility, Browser for focused rendered decision proof.
  • CHK040 Browser proof is focused and fixture-bounded, not a broad visual regression suite.
  • CHK041 Planned validation commands are narrow and implementation must choose exact filters after discovery.
  • CHK042 Fixture/helper cost must stay explicit and minimal.
  • CHK043 Implementation report fields are specified in plan.md.
  • CHK044 Requirement coverage map includes both FR and NFR coverage.

Readiness

  • CHK045 spec.md exists and is complete enough for implementation planning.
  • CHK046 plan.md exists and identifies likely affected surfaces, constraints, risks, phases, tests, rollout, and stop conditions.
  • CHK047 tasks.md exists and is ordered, scoped, testable, and suitable for a later implementation loop.
  • CHK048 Scope is small enough for a bounded implementation loop.
  • CHK049 No open question blocks safe implementation.

Review Outcome

  • CHK050 Review outcome class: acceptable-special-case.
  • CHK051 Workflow outcome: keep.

Notes

This checklist validates preparation only. It does not claim runtime UI reduction, test execution, browser verification, human product sanity completion, or implementation close-out.