Automated PR created by Codex via Gitea API. Co-authored-by: Ahmed Darrazi <ahmed.darrazi@live.de> Reviewed-on: #468
85 lines
5.9 KiB
Markdown
85 lines
5.9 KiB
Markdown
# Requirements Checklist: Spec 397 - Receipt Page Reduction Pass v1
|
|
|
|
**Purpose**: Validate specification and preparation quality before implementation.
|
|
**Created**: 2026-06-22
|
|
**Feature**: `specs/397-receipt-page-reduction/spec.md`
|
|
|
|
## Candidate Selection
|
|
|
|
- [x] CHK001 Selected candidate exists in user-provided source material and is not invented.
|
|
- [x] CHK002 Selected candidate is supported by repo truth: Spec 395 explicitly deferred a Receipt Page Reduction Pass.
|
|
- [x] 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.
|
|
- [x] CHK004 Related specs were checked as context and are not being rewritten or converted back to preparation state.
|
|
- [x] CHK005 Close alternatives are deferred because they are manual-promotion only, already spec-backed, or outside the selected receipt-reduction scope.
|
|
- [x] CHK006 The selected slice is bounded to existing receipt-style surfaces and excludes new dashboards, adapters, persisted truth, and broad framework work.
|
|
|
|
## Content Quality
|
|
|
|
- [x] CHK007 Spec states the concrete operator problem and current failure mode.
|
|
- [x] CHK008 Spec explains user-visible improvement and business/product value.
|
|
- [x] CHK009 Primary users/operators are identified.
|
|
- [x] CHK010 User stories are prioritized and independently testable.
|
|
- [x] CHK011 Functional requirements are testable and use stable IDs.
|
|
- [x] CHK012 Non-functional, UX, RBAC/security, auditability/observability, and data/truth requirements are present.
|
|
- [x] CHK013 Out-of-scope boundaries are explicit and prevent scope creep.
|
|
- [x] CHK014 Acceptance criteria and success criteria are measurable enough for implementation close-out.
|
|
- [x] CHK015 Assumptions and open questions are documented, with no blocking open question.
|
|
|
|
## Product Surface Contract
|
|
|
|
- [x] CHK016 Spec references `docs/product/standards/product-surface-contract.md`.
|
|
- [x] CHK017 No-legacy posture is explicit: canonical replacement, no duplicate old/new receipt UI, no compatibility toggle.
|
|
- [x] CHK018 Product Surface Impact names Receipt Page archetype, primary user question, one-primary-action rule, surface budgets, technical demotion, status vocabulary, visible complexity outcome, and exceptions.
|
|
- [x] CHK019 Browser proof is required because rendered UI changes are expected.
|
|
- [x] CHK020 Human Product Sanity is required and has concrete review questions.
|
|
- [x] CHK021 Product Surface exceptions are `none planned`; any exception is a stop condition requiring spec/plan update.
|
|
- [x] CHK022 Completed historical specs must not be rewritten, normalized, reopened, or stripped of validation/browser/task history.
|
|
- [x] CHK049 UI Action Matrix names primary, secondary, technical/audit, dangerous/high-impact actions, and mutation scope for each target surface.
|
|
- [x] CHK050 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
|
|
|
|
- [x] CHK023 Spec has a completed Spec Candidate Check with approval class, score, red flags, and decision.
|
|
- [x] CHK024 Proportionality review confirms no new persisted entity, enum/status family, abstraction, registry, resolver, taxonomy, or broad UI framework is approved.
|
|
- [x] CHK025 Plan states no Graph calls, migrations, queues, env vars, storage changes, or package changes are expected.
|
|
- [x] CHK026 Plan names likely affected repo surfaces without requiring application edits during preparation.
|
|
- [x] CHK027 Workspace/tenant isolation and deny-as-not-found requirements are preserved.
|
|
- [x] CHK028 RBAC/security requirements state UI visibility is not authorization.
|
|
- [x] CHK029 OperationRun remains execution truth and no OperationRun lifecycle or notification behavior is changed.
|
|
- [x] CHK030 Data/truth-source requirements distinguish execution truth, artifact truth, backup/snapshot truth, recovery/evidence truth, and operator next action.
|
|
|
|
## Filament / Livewire / Actions
|
|
|
|
- [x] CHK031 Plan states Filament v5 / Livewire v4.1.4 compliance.
|
|
- [x] CHK032 Plan states Laravel 12 provider registration location: `apps/platform/bootstrap/providers.php`.
|
|
- [x] CHK033 Global search posture must remain safe for any changed resource.
|
|
- [x] CHK034 Destructive/high-impact actions must keep `->action(...)`, confirmation, authorization, audit where mutating, and tests if touched.
|
|
- [x] CHK035 Asset strategy is recorded: no new assets expected, `filament:assets` only if implementation registers assets.
|
|
- [x] CHK036 UI implementation must reuse native Filament and existing shared primitives before local Blade/CSS.
|
|
|
|
## Test Governance
|
|
|
|
- [x] CHK037 Test lanes are named: Unit only for pure helpers, Feature/Filament for page/action visibility, Browser for focused rendered receipt proof.
|
|
- [x] CHK038 Browser proof is focused and fixture-bounded, not a broad visual regression suite.
|
|
- [x] CHK039 Planned validation commands are narrow and implementation must choose exact filters after discovery.
|
|
- [x] CHK040 Fixture/helper cost must stay explicit and minimal.
|
|
- [x] CHK041 Implementation report fields are specified in `plan.md`.
|
|
- [x] CHK051 Requirement coverage map includes both FR and NFR coverage.
|
|
|
|
## Readiness
|
|
|
|
- [x] CHK042 `spec.md` exists and is complete enough for planning.
|
|
- [x] CHK043 `plan.md` exists and identifies likely affected surfaces, constraints, risks, phases, tests, rollout, and stop conditions.
|
|
- [x] CHK044 `tasks.md` exists or must be generated before implementation.
|
|
- [x] CHK045 Scope is small enough for a bounded implementation loop.
|
|
- [x] CHK046 No open question blocks safe implementation.
|
|
|
|
## Review Outcome
|
|
|
|
- [x] CHK047 Review outcome class: `acceptable-special-case`.
|
|
- [x] CHK048 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.
|