TenantAtlas/specs/246-support-request-context/tasks.md

description
Task list for In-App Support Request with Context

Tasks: In-App Support Request with Context

Input: Design documents from /Users/ahmeddarrazi/Documents/projects/wt-plattform/specs/246-support-request-context/
Prerequisites: /Users/ahmeddarrazi/Documents/projects/wt-plattform/specs/246-support-request-context/plan.md (required), /Users/ahmeddarrazi/Documents/projects/wt-plattform/specs/246-support-request-context/spec.md (required), /Users/ahmeddarrazi/Documents/projects/wt-plattform/specs/246-support-request-context/checklists/requirements.md (required)

Tests (TEST-GOV-001): REQUIRED (Pest) for all runtime behavior changes in this slice. Keep proof in focused unit plus feature lanes only.
Operations: This slice must not create, queue, resume, or complete an OperationRun. Support-request creation stays DB-only and audited.
RBAC: Workspace membership, tenant entitlement, and support_requests.create remain authoritative. support_diagnostics.view controls only whether the redacted diagnostic snapshot can be attached.
Organization: Tasks are grouped by user story so tenant-context creation, run-context creation, and safety hardening remain independently verifiable once the shared foundation exists.

Phase 1: Setup (Shared Infrastructure)

Purpose: Lock the first-slice scope and verify the existing support-aware seams before runtime edits begin.

• T001 Review the first-slice scope, attachment modes, and validation commands in /Users/ahmeddarrazi/Documents/projects/wt-plattform/specs/246-support-request-context/spec.md, /Users/ahmeddarrazi/Documents/projects/wt-plattform/specs/246-support-request-context/plan.md, and /Users/ahmeddarrazi/Documents/projects/wt-plattform/specs/246-support-request-context/checklists/requirements.md
• T002 [P] Verify the current tenant dashboard, canonical operation detail viewer, support-diagnostics bundle builder, tenant capability map, and workspace audit logger seams that this slice must reuse in apps/platform/app/Filament/Pages/TenantDashboard.php, apps/platform/app/Filament/Pages/Operations/TenantlessOperationRunViewer.php, apps/platform/app/Support/SupportDiagnostics/SupportDiagnosticBundleBuilder.php, apps/platform/app/Support/Auth/Capabilities.php, apps/platform/app/Services/Auth/RoleCapabilityMap.php, and apps/platform/app/Services/Audit/WorkspaceAuditLogger.php

---

Phase 2: Foundational (Blocking Prerequisites)

Purpose: Add the persisted support-request truth and shared capture path required by both entry contexts before surface wiring begins.

Critical: No user story work should start until this phase is complete.

• T003 Create the tenant-owned support_requests migration, model, and factory with required not-null workspace_id and tenant_id, immutable internal reference, primary context type, severity constrained to low, normal, high, or blocking, required summary, optional reproduction notes, optional contact name and contact email, creator metadata, and redacted context JSON in apps/platform/database/migrations/, apps/platform/app/Models/SupportRequest.php, and apps/platform/database/factories/SupportRequestFactory.php
• T004 [P] Register support_requests.create in the canonical tenant capability registry and tenant role map without widening system-plane access in apps/platform/app/Support/Auth/Capabilities.php and apps/platform/app/Services/Auth/RoleCapabilityMap.php
• T005 [P] Add the bounded support-request context builder and internal reference generator in apps/platform/app/Support/SupportRequests/SupportRequestContextBuilder.php and apps/platform/app/Support/SupportRequests/SupportRequestReferenceGenerator.php, reusing SupportDiagnosticBundleBuilder for attachment-mode decisions and machine-readable context shaping while emitting SR-<ULID> references only
• T006 [P] Add the support-request audit action identifier and workspace audit logger path for redacted request-creation metadata in apps/platform/app/Support/Audit/AuditActionId.php and apps/platform/app/Services/Audit/WorkspaceAuditLogger.php

Checkpoint: Foundation ready - both entry contexts can create the same immutable support-request truth through one shared capture path.

---

Phase 3: User Story 1 - Submit A Tenant-Scoped Support Request (Priority: P1) 🎯 MVP

Goal: An entitled operator can request support from the tenant dashboard without manually rebuilding the current case.

Independent Test: Seed a tenant with provider, run, finding, review, report, and audit truth, submit a request from the tenant dashboard, and verify persisted request context plus returned internal reference.

Tests for User Story 1

• T007 [P] [US1] Add tenant-context feature coverage for created support reference, persisted tenant primary context, persisted severity and optional reproduction/contact fields, reduced-attachment mode, and 404 versus 403 semantics in apps/platform/tests/Feature/SupportRequests/TenantSupportRequestActionTest.php

Implementation for User Story 1

• T008 [US1] Add the native Filament Request support action form to apps/platform/app/Filament/Pages/TenantDashboard.php with required severity and summary fields, optional reproduction notes, contact name and contact email defaults, attachment summary, and success notification carrying the internal support reference
• T009 [US1] Implement tenant-context request capture in apps/platform/app/Support/SupportRequests/SupportRequestContextBuilder.php so the request stores canonical tenant references and attaches the redacted support-diagnostics snapshot only when allowed
• T010 [US1] Ensure tenant-context submission persists the explicit canonical_context_only attachment mode instead of blocking the request when diagnostic attachment is unavailable

Checkpoint: User Story 1 is independently functional when a tenant-context request can be submitted safely and the creator receives a stable internal support reference.

---

Phase 4: User Story 2 - Submit A Run-Scoped Support Request (Priority: P1)

Goal: An entitled operator already inspecting one run can request support directly from the canonical operation detail surface.

Independent Test: Seed a failed or degraded run with related context, submit a support request from the operation viewer, and verify the saved request uses the run as primary context without breaking the viewer contract.

Tests for User Story 2

• T011 [P] [US2] Add run-context feature coverage for entitled-tenant resolution, persisted run primary context, persisted severity and optional reproduction/contact fields, reduced-attachment mode, and canonical viewer authorization boundaries in apps/platform/tests/Feature/SupportRequests/OperationRunSupportRequestActionTest.php

Implementation for User Story 2

• T012 [US2] Add the native Filament operation-viewer support actions in grouped secondary header placement on apps/platform/app/Filament/Pages/Operations/TenantlessOperationRunViewer.php, keeping both Open support diagnostics and Request support under More so they stay secondary to the viewer's primary navigation and utility actions
• T013 [US2] Implement run-context request capture through the shared support-request context builder so the request uses the current run plus entitled tenant context only after authorization has resolved safely
• T014 [US2] Keep run-context request copy and attachment wording aligned with the existing operation viewer and support-diagnostics vocabulary rather than introducing a second run-summary dialect

Checkpoint: User Story 2 is independently functional when the operation viewer can create the same support-request truth with run-centered context and correct tenant-safe boundaries.

---

Phase 5: User Story 3 - Keep Support Intake Redacted, Auditable, And Bounded (Priority: P2)

Goal: The same authorized input always produces the same safe context shape and the feature stays free of ticket-provider, lifecycle, and OperationRun sprawl.

Independent Test: Verify deterministic context-envelope generation, correct attachment modes, correct audit logging, and absence of outbound HTTP or OperationRun side effects.

Tests for User Story 3

• T015 [P] [US3] Add unit coverage for deterministic context-envelope generation, explicit missing and inaccessible markers, internal support-reference formatting, and the absence of raw provider payload content in persisted context envelopes in apps/platform/tests/Unit/Support/SupportRequests/SupportRequestContextBuilderTest.php and apps/platform/tests/Unit/Support/SupportRequests/SupportRequestReferenceTest.php
• T016 [P] [US3] Add shared feature coverage for authorization boundaries and attachment-mode behavior in apps/platform/tests/Feature/SupportRequests/SupportRequestAuthorizationTest.php
• T017 [P] [US3] Add feature coverage for support-request audit entries, duplicate submissions creating two distinct records and support references, and the absence of outbound HTTP or OperationRun side effects in apps/platform/tests/Feature/SupportRequests/SupportRequestAuditTest.php

Implementation for User Story 3

• T018 [US3] Finalize immutable persistence rules, explicit omission markers, explicit missing and inaccessible related-record markers, explicit exclusion of raw provider payload content from persisted context, and redacted audit payload shape in apps/platform/app/Models/SupportRequest.php, apps/platform/app/Support/SupportRequests/SupportRequestContextBuilder.php, apps/platform/app/Support/SupportRequests/SupportRequestReferenceGenerator.php, apps/platform/app/Support/Audit/AuditActionId.php, and apps/platform/app/Services/Audit/WorkspaceAuditLogger.php
• T019 [US3] Ensure the first slice introduces no edit flow, status workflow, external ticket reference, or support inbox surface while completing the create path on the two approved surfaces only

Checkpoint: User Story 3 is independently functional when support-request creation is deterministic, redacted, audited, and still bounded to the v1 create-only contract.

---

Phase 6: Polish & Cross-Cutting Concerns

Purpose: Align wording, formatting, and the final validation suite before implementation close-out.

• T020 [P] Confirm that Request support, Support reference, attachment-mode copy, omission markers, and redaction notes stay aligned across apps/platform/app/Support/SupportRequests/, apps/platform/app/Filament/Pages/TenantDashboard.php, and apps/platform/app/Filament/Pages/Operations/TenantlessOperationRunViewer.php
• T021 Run formatting on touched platform files with export PATH="/bin:/usr/bin:/usr/local/bin:$PATH" && cd apps/platform && ./vendor/bin/sail bin pint --dirty --format agent
• T022 Run the focused unit validation suite with export PATH="/bin:/usr/bin:/usr/local/bin:$PATH" && cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Unit/Support/SupportRequests/SupportRequestContextBuilderTest.php tests/Unit/Support/SupportRequests/SupportRequestReferenceTest.php
• T023 Run the focused feature validation suite with export PATH="/bin:/usr/bin:/usr/local/bin:$PATH" && cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Feature/SupportRequests/TenantSupportRequestActionTest.php tests/Feature/SupportRequests/OperationRunSupportRequestActionTest.php tests/Feature/SupportRequests/SupportRequestAuthorizationTest.php tests/Feature/SupportRequests/SupportRequestAuditTest.php
• T024 Record the final guardrail close-out and any bounded document-in-feature note for attachment-mode wording or tenant-dashboard exemption handling in /Users/ahmeddarrazi/Documents/projects/wt-plattform/specs/246-support-request-context/plan.md and /Users/ahmeddarrazi/Documents/projects/wt-plattform/specs/246-support-request-context/checklists/requirements.md

---

Dependencies & Execution Order

Phase Dependencies

• Phase 1 starts immediately.
• Phase 2 depends on Phase 1 and blocks all user stories.
• Phase 3 depends on Phase 2 and establishes the MVP tenant-context request flow.
• Phase 4 depends on Phase 2 and is safest after Phase 3 because both stories extend the same shared support-request capture path.
• Phase 5 depends on Phase 3 and Phase 4 because deterministic attachment, authorization, and audit behavior must cover both approved contexts.
• Phase 6 depends on every implemented story.

User Story Dependencies

• US1 is the MVP and first independently shippable increment.
• US2 is independently testable but shares the same support-request capture path, so merge order should favor US1 first.
• US3 depends on both P1 stories because deterministic context and audit proof must cover the shared request contract across both contexts.

Within Each User Story

• Write the listed Pest coverage first and ensure it fails before implementation.
• Complete shared capture-path changes before the final surface wiring pass when both are required.
• Re-run the narrowest affected unit or feature suite after each story checkpoint before moving to the next story.

---

Parallel Opportunities

Phase 1

• T001 and T002 can run in parallel if one person confirms the feature package while another confirms the existing support-aware code seams.

Phase 2

• T004 and T006 can run in parallel after T003 and T005 define the persisted support-request truth and shared capture shape.

User Story 1

• T007 can start before runtime edits.
• T008 and T009 can overlap once the shared capture path exists.

User Story 2

• T011 can start before runtime edits.
• T012 and T013 can overlap once the shared capture path exists.

User Story 3

• T015, T016, and T017 can run in parallel.
• T018 and T019 should stay sequential because both finalize the shared persistence and guardrail boundaries.

---

Implementation Strategy

MVP First

1. Complete Phase 1.
2. Complete Phase 2.
3. Complete Phase 3 (US1).
4. Re-run the tenant-context suite and stop for review.

Incremental Delivery

1. Deliver US1 to compress tenant-context support intake first.
2. Add US2 so the same request truth can start from the canonical run detail surface.
3. Add US3 to harden deterministic context, authorization, and audit behavior while keeping the slice bounded.

Team Strategy

1. Finish Phase 2 together before splitting work.
2. Parallelize test authoring inside each story.
3. Sequence merges carefully around apps/platform/app/Support/SupportRequests/SupportRequestContextBuilder.php, because every story extends the same shared capture path.