ahmido
38523814c2
## Summary - restore broad full-suite green-signal coverage across platform governance, operations, onboarding, dashboard/productization, and customer review flows - align related platform tests and supporting behavior with the current expected state for this restoration pass - update the spec-candidates queue as part of the same suite-restoration sweep ## Validation - `cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Browser/Dashboard/TenantDashboardProductizationSmokeTest.php tests/Browser/Reviews/CustomerReviewWorkspaceSmokeTest.php tests/Browser/Spec194GovernanceFrictionSmokeTest.php tests/Browser/Spec265DecisionRegisterSmokeTest.php` Co-authored-by: Ahmed Darrazi <ahmed.darrazi@live.de> Reviewed-on: #351
69 lines
3.5 KiB
Markdown
69 lines
3.5 KiB
Markdown
# Specification Quality Checklist: Full Suite Green Signal Restoration
|
|
|
|
**Purpose**: Validate specification completeness and quality before implementation
|
|
**Created**: 2026-05-11
|
|
**Feature**: [spec.md](/Users/ahmeddarrazi/Documents/projects/wt-plattform/specs/296-full-suite-green-signal-restoration/spec.md)
|
|
|
|
## Content Quality
|
|
|
|
- [x] No application implementation was performed during preparation.
|
|
- [x] Focused on maintainer/operator value: restore or explicitly control the full-suite CI signal.
|
|
- [x] Written for maintainers and reviewers who must execute a stabilization loop.
|
|
- [x] All mandatory Spec Kit sections are completed or explicitly marked N/A.
|
|
|
|
## Requirement Completeness
|
|
|
|
- [x] No unresolved `[NEEDS CLARIFICATION]` markers remain.
|
|
- [x] Requirements are testable and unambiguous.
|
|
- [x] Success criteria are measurable.
|
|
- [x] Success criteria are repo-aware only where validation commands require it.
|
|
- [x] All acceptance scenarios are defined.
|
|
- [x] Edge cases are identified.
|
|
- [x] Scope is clearly bounded.
|
|
- [x] Dependencies and assumptions are identified.
|
|
|
|
## Feature Readiness
|
|
|
|
- [x] All functional requirements have clear acceptance criteria.
|
|
- [x] User scenarios cover baseline inventory, guard lanes, root-cause repairs, lane/browser decisions, and final CI-signal close-out.
|
|
- [x] Feature meets measurable outcomes defined in Success Criteria.
|
|
- [x] No implementation detail expands into new product feature scope.
|
|
|
|
## Spec 296 Specific Checks
|
|
|
|
- [x] `failure-inventory.md` exists and includes the required columns.
|
|
- [x] `fix-log.md` exists and defines per-file fix logging.
|
|
- [x] `lane-decisions.md` exists and defines default/browser/heavy/wrong-lane decisions.
|
|
- [x] `browser-evidence.md` exists and defines screenshot evidence rules.
|
|
- [x] Legacy `/admin/t/...`, TenantPanelProvider restoration, and `/admin/operations` fallback routes are explicitly forbidden.
|
|
- [x] Workspace-first route generation and `OperationRunLinks` are named as current truth.
|
|
- [x] Filament v5 / Livewire v4 compliance is explicitly covered.
|
|
- [x] Provider registration location is explicitly covered as `apps/platform/bootstrap/providers.php`.
|
|
- [x] Globally searchable resource review requirements are covered for any touched resource.
|
|
- [x] Destructive action confirmation and authorization requirements are covered.
|
|
- [x] Asset strategy is documented as unchanged unless unexpected asset registration changes occur.
|
|
- [x] Testing plan covers focused files, affected lanes, full suite, browser when touched, Pint, and `git diff --check`.
|
|
|
|
## Candidate Selection Gate
|
|
|
|
- [x] Selected candidate is directly provided by the user.
|
|
- [x] `specs/296-full-suite-green-signal-restoration/` did not already exist before preparation.
|
|
- [x] No existing completed Spec 296 was modified.
|
|
- [x] Related Specs 293, 294, and 295 were treated as completed/contextual artifacts, not rewritten.
|
|
- [x] Candidate aligns with current repo truth from Spec 295: full suite remains red after classification.
|
|
- [x] Scope is bounded as a stabilization/cleanup pass, not a new product feature.
|
|
|
|
## Spec Readiness Gate
|
|
|
|
- [x] `spec.md`, `plan.md`, and `tasks.md` exist.
|
|
- [x] Required additional artifacts exist.
|
|
- [x] Plan identifies likely affected repo surfaces without requiring broad refactors.
|
|
- [x] Tasks are ordered, small, and verifiable.
|
|
- [x] RBAC, workspace/tenant isolation, provider boundary, OperationRun semantics, browser evidence, and test governance are addressed.
|
|
- [x] No open question blocks implementation.
|
|
|
|
## Notes
|
|
|
|
Preparation analyze found no blocking readiness issue after these artifacts were created.
|
|
|