ahmido
6e3736a53f
Some checks failed
Main Confidence / confidence (push) Failing after 1m29s
## Summary - add the first in-app support request flow with an immutable `SupportRequest` record, canonical context builder, submission service, and generated internal reference - expose contextual support-request actions from the tenant dashboard and operation run surfaces, including audit logging and support-safe diagnostic capture rules - add Pest coverage plus the `specs/246-support-request-context` artifacts for the new support-request slice ## Testing - `cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Feature/SupportRequests/OperationRunSupportRequestActionTest.php tests/Feature/SupportRequests/SupportRequestAuditTest.php tests/Feature/SupportRequests/SupportRequestAuthorizationTest.php tests/Feature/SupportRequests/TenantSupportRequestActionTest.php tests/Unit/Support/SupportRequests/SupportRequestContextBuilderTest.php tests/Unit/Support/SupportRequests/SupportRequestReferenceTest.php` ## Notes - this PR supersedes the earlier session-branch PR opened from `246-support-request-context-session-1777289015` Co-authored-by: Ahmed Darrazi <ahmed.darrazi@live.de> Reviewed-on: #285
59 lines
3.4 KiB
Markdown
59 lines
3.4 KiB
Markdown
# Specification Quality Checklist: In-App Support Request with Context
|
|
|
|
**Purpose**: Validate specification completeness and implementation readiness before the feature moves into the implementation loop
|
|
**Created**: 2026-04-27
|
|
**Feature**: [spec.md](../spec.md)
|
|
|
|
## Content Quality
|
|
|
|
- [x] Business value and operator outcomes stay explicit
|
|
- [x] The first slice is bounded to two existing support-aware entry surfaces plus one internal support reference only
|
|
- [x] Runtime-governance sections are present for an implementation-ready package
|
|
- [x] All mandatory sections are completed
|
|
|
|
## Requirement Completeness
|
|
|
|
- [x] No `[NEEDS CLARIFICATION]` markers remain
|
|
- [x] Requirements are testable and unambiguous
|
|
- [x] Acceptance scenarios are defined for the primary user journeys
|
|
- [x] Edge cases are identified, including reduced-attachment mode and missing related records
|
|
- [x] Scope is clearly bounded away from external ticketing, support inboxes, request lifecycle workflow, and customer-facing portals
|
|
- [x] Dependencies and assumptions are identified
|
|
|
|
## Feature Readiness
|
|
|
|
- [x] The first slice is small enough for a bounded implementation loop
|
|
- [x] The plan identifies concrete repo surfaces likely to change
|
|
- [x] The tasks are ordered, testable, and grouped by user story
|
|
- [x] Foundational work includes the persisted truth, capability gate, audit path, and shared context builder before surface wiring
|
|
- [x] No unresolved product question blocks safe implementation of the first slice
|
|
|
|
## Governance Readiness
|
|
|
|
- [x] New persisted support-request truth is explicitly justified and bounded
|
|
- [x] `SupportRequest` ownership is explicit as tenant-owned, with required not-null `workspace_id` and `tenant_id`
|
|
- [x] Support-request context remains provider-neutral and redaction-aware
|
|
- [x] Existing `/admin` authorization and tenant-safe 404 versus 403 boundaries remain authoritative
|
|
- [x] Operator-facing surface changes include the required UI contract sections and action matrix
|
|
- [x] External ticketing, status workflow, and support inbox surfaces are explicitly deferred
|
|
- [x] 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
|
|
|
|
## Test Governance Review
|
|
|
|
- [x] Lane fit stays in focused unit plus feature validation only and matches the plan
|
|
- [x] Fixture and helper growth stays local to the `SupportRequests` test namespace
|
|
- [x] No browser or heavy-governance family is introduced implicitly
|
|
- [x] Minimal validation commands are explicit in both the plan and the task list
|
|
- [x] The active feature PR close-out entry remains `Guardrail`
|
|
|
|
## Review Outcome
|
|
|
|
- [x] Review outcome class: `documentation-required-exception`
|
|
- [x] Workflow outcome: `document-in-feature`
|
|
- [x] Final note location: active feature PR close-out entry `Guardrail`
|
|
|
|
## Notes
|
|
|
|
- This checklist completes the implementation-ready package alongside `spec.md`, `plan.md`, and `tasks.md`.
|
|
- The active slice stops at structured request creation and internal reference generation. Any later ticket-provider adapter or lifecycle management remains a separate feature.
|
|
- Guardrail close-out: focused unit and feature validation passed, live browser smoke passed on both approved entry points, the tenant dashboard exemption remained bounded to two support-aware actions, and no provider-registration, global-search, destructive-action, or asset-strategy changes were introduced. |