ahmido
bf43e55848
This PR implements the onboarding verify-step changes and ProductKnowledge contextual-help fixes: - Hide the top-level "Permission diagnostics" when a stored verification report exists. - Move permission details to "Supporting evidence" / "View required permissions" and into stored report technical details. - Rename "Current checkpoint" to "Step" in onboarding readiness. - Rename the inner verification card title to "Stored verification details" to avoid duplicate headings. - Keep "Grant admin consent" as primary CTA when admin consent is the dominant blocker by deriving the CTA from the verification primary reason. - Replace the custom Safe Next Action with Filament `Callout` for correct dark-mode styling. - Add/adjust focused feature tests proving the above behaviors. Verification: - Tests: 36 passed (173 assertions) locally. - Pint: pass. Created from local session branch `244-product-knowledge-contextual-help-session-1777248340`. Please review and merge into `dev` when ready. Co-authored-by: Ahmed Darrazi <ahmed.darrazi@live.de> Reviewed-on: #282
2.0 KiB
2.0 KiB
Specification Quality Checklist: Product Knowledge & Contextual Help
Purpose: Validate specification completeness and quality before proceeding to implementation planning
Created: 2026-04-26
Feature: spec.md
Content Quality
- Business value and operator outcomes stay explicit
- Implementation anchors are intentional and bounded to existing repo surfaces
- Runtime-governance sections are present for an implementation-ready spec package
- All mandatory sections completed
Requirement Completeness
- No
[NEEDS CLARIFICATION]markers remain - Requirements are testable and unambiguous
- Success criteria are measurable
- Acceptance scenarios are defined for the primary user journeys
- Edge cases are identified
- Scope is clearly bounded to onboarding and support-diagnostic surface families plus one internal machine-readable knowledge source deliverable
- Dependencies and assumptions are identified
Feature Readiness
- The first slice is small enough for a bounded implementation loop
- The plan identifies the concrete repo surfaces likely to change
- The tasks are ordered, testable, and grouped by user story
- No unresolved product question blocks safe implementation of the first slice
Governance Readiness
- No new persistence is introduced without justification
- Provider-boundary handling and glossary reuse are explicit
- Existing RBAC and tenant/workspace isolation remain authoritative
- Operator-facing surface changes include the required UI contract sections
- Livewire v4 compliance, unchanged provider registration location, no global-search changes, no destructive-action additions, and no asset-strategy changes are explicit in the package
Notes
- This checklist completes the implementation-ready package alongside
spec.md,plan.md, andtasks.md. - The active slice stays bounded to one code-owned help catalog, one resolver, two adopted surface families, and one safe machine-readable knowledge source.