ahmido
2bf5de4663
Summary Consolidates the “Tenant Operate Hub” work (Spec 085) and the follow-up adjustments from the 086 session merge into a single branch ready to merge into dev. Primary focus: stabilize Ops/Operate Hub UX flows, tighten/align authorization semantics, and make the full Sail test suite green. Key Changes Ops UX / Verification Readonly members can view verification operation runs (reports) while starting verification remains restricted. Normalized failure reason-code handling and aligned UX expectations with the provider reason-code taxonomy. Onboarding wizard UX “Start verification” CTA is hidden while a verification run is active; “Refresh” is shown during in-progress runs. Treats provider_permission_denied as a blocking reason (while keeping legacy compatibility). Test + fixture hardening Standardized use of default provider connection fixtures in tests where sync/restore flows require it. Fixed multiple Filament URL/tenant-context test cases to avoid 404s and reduce tenancy routing brittleness. Policy sync / restore safety Enrollment configuration type collision classification tests now exercise the real sync path (with required provider connection present). Restore edge-case safety tests updated to reflect current provider-connection requirements. Testing vendor/bin/sail artisan test --compact (green) vendor/bin/sail bin pint --dirty (green) Notes Includes merged 086 session work already (no separate PR needed). Co-authored-by: Ahmed Darrazi <ahmeddarrazi@ebc83aaa-d947-4a08-b88e-bd72ac9645f7.fritz.box> Co-authored-by: Ahmed Darrazi <ahmeddarrazi@MacBookPro.fritz.box> Co-authored-by: Ahmed Darrazi <ahmeddarrazi@adsmac.fritz.box> Reviewed-on: #103
35 lines
1.3 KiB
Markdown
35 lines
1.3 KiB
Markdown
# Specification Quality Checklist: Retire Legacy Runs Into Operation Runs
|
|
|
|
**Purpose**: Validate specification completeness and quality before proceeding to planning
|
|
**Created**: 2026-02-09
|
|
**Feature**: [../spec.md](../spec.md)
|
|
|
|
## Content Quality
|
|
|
|
- [x] No implementation details (languages, frameworks, APIs)
|
|
- [x] Focused on user value and business needs
|
|
- [x] Written for non-technical stakeholders
|
|
- [x] All mandatory sections completed
|
|
|
|
## Requirement Completeness
|
|
|
|
- [x] No [NEEDS CLARIFICATION] markers remain
|
|
- [x] Requirements are testable and unambiguous
|
|
- [x] Success criteria are measurable
|
|
- [x] Success criteria are technology-agnostic (no implementation details)
|
|
- [x] All acceptance scenarios are defined
|
|
- [x] Edge cases are identified
|
|
- [x] Scope is clearly bounded
|
|
- [x] Dependencies and assumptions identified
|
|
|
|
## Feature Readiness
|
|
|
|
- [x] All functional requirements have clear acceptance criteria
|
|
- [x] User scenarios cover primary flows
|
|
- [x] Feature meets measurable outcomes defined in Success Criteria
|
|
- [x] No implementation details leak into specification
|
|
|
|
## Notes
|
|
|
|
- The spec uses product-specific terms (e.g., 404 vs 403 semantics) to make authorization behavior testable, but avoids naming specific frameworks or code-level implementation choices.
|