--- description: "Task list for Enterprise Access Boundary & Support Access Governance v1" --- # Tasks: Enterprise Access Boundary & Support Access Governance v1 **Input**: Design documents from `specs/276-support-access-governance/` **Prerequisites**: `specs/276-support-access-governance/spec.md`, `specs/276-support-access-governance/plan.md`, `specs/276-support-access-governance/checklists/requirements.md`, `specs/276-support-access-governance/research.md`, `specs/276-support-access-governance/data-model.md`, `specs/276-support-access-governance/quickstart.md`, `specs/276-support-access-governance/contracts/workspace-support-access-governance.logical.openapi.yaml` **Tests**: REQUIRED (Pest). Keep proof bounded to one new `Unit` family under `tests/Unit/System/` plus focused extensions to existing `Feature` families for system, auth, settings, monitoring, and access-log behavior. **Operations**: No new `OperationRun` family. Support-access lifecycle is DB-backed and audit-backed only. **RBAC**: Wrong-plane and non-member access remain `404`; in-scope actors missing capability remain `403`. `/system` owns request or end; `/admin` owns approval and workspace-visible history. **Shared Pattern Reuse**: Reuse `ViewWorkspace`, `WorkspaceSettings`, `AuditLog`, `AccessLogs`, `BreakGlassSession`, and existing audit infrastructure. Do not create a second support console. **Filament / Panel Guardrails**: Filament remains v5 on Livewire v4. Provider registration remains unchanged in `apps/platform/bootstrap/providers.php`. No new panel, no new globally searchable resource, and no new asset strategy are allowed. **Organization**: Tasks are grouped by user story so request flow, approval and recovery boundary, and customer-visible history remain independently implementable and testable. This package is a bounded follow-through over current support seams, not an IAM rewrite. **Review Outcome**: `acceptable-special-case` **Workflow Outcome**: `keep` **Test-governance Outcome**: `keep` ## Test Governance Checklist - [x] Lane assignment stays `fast-feedback` and `confidence` and remains the narrowest sufficient proof. - [x] New or changed tests stay in `apps/platform/tests/Unit/System/`, `apps/platform/tests/Feature/System/`, `apps/platform/tests/Feature/Auth/`, `apps/platform/tests/Feature/Filament/Settings/`, `apps/platform/tests/Feature/Monitoring/`, and one narrow `apps/platform/tests/Browser/` smoke file required by the implementation-loop gate. - [x] Shared helpers stay cheap by default; only one new grant factory is expected. - [x] Planned validation commands cover grant lifecycle, request flow, approval, recovery boundary, history export, and one narrow browser smoke without widening into heavy-governance lanes. - [x] The declared surface test profile remains `standard-native-filament`, `shared-detail-family`, `monitoring-state-page`, and `exception-coded-surface` only. - [x] Any drift toward impersonation, SCIM, or a second support console resolves as `reject-or-split`, not hidden scope. ## Phase 1: Setup (Shared Context) **Purpose**: Confirm the current support and recovery seams before any implementation change. - [x] T001 Review `specs/276-support-access-governance/spec.md`, `specs/276-support-access-governance/plan.md`, `specs/276-support-access-governance/checklists/requirements.md`, `specs/276-support-access-governance/research.md`, `specs/276-support-access-governance/data-model.md`, `specs/276-support-access-governance/quickstart.md`, `docs/audits/2026-03-09-enterprise-rbac-scope-audit.md`, and `docs/HANDOVER.md` together so the slice stays on current support seams. - [x] T002 [P] Confirm the current request and recovery surfaces in `apps/platform/app/Filament/System/Pages/Directory/ViewWorkspace.php`, `apps/platform/app/Filament/System/Pages/RepairWorkspaceOwners.php`, and `apps/platform/app/Services/Auth/BreakGlassSession.php`. - [x] T003 [P] Confirm the current customer-visible history seams in `apps/platform/app/Filament/Pages/Settings/WorkspaceSettings.php` and `apps/platform/app/Filament/Pages/Monitoring/AuditLog.php`. - [x] T004 [P] Confirm the current system security history seams in `apps/platform/app/Filament/System/Pages/Security/AccessLogs.php`, `apps/platform/app/Services/SystemConsole/SystemConsoleAuditLogger.php`, and `apps/platform/app/Support/Audit/AuditActionId.php`. --- ## Phase 2: Foundational (Blocking Prerequisites) **Purpose**: Lock the new grant truth, audit action family, and shared resolver before surface changes begin. **Critical**: No user-story work should begin until this phase is complete. - [x] T005 [P] Add failing unit coverage in `apps/platform/tests/Unit/System/SupportAccessGrantResolverTest.php` to prove scope validation, dedupe rules, approval-mode selection, active summary output, and expiry behavior. - [x] T006 [P] Add or extend feature coverage in `apps/platform/tests/Feature/System/SupportAccessRequestFlowTest.php` and `apps/platform/tests/Feature/System/Spec114/AccessLogsTest.php` to lock request, end, and system history behavior. - [x] T007 [P] Add or extend feature coverage in `apps/platform/tests/Feature/Auth/BreakGlassModeTest.php` and `apps/platform/tests/Feature/Auth/BreakGlassWorkspaceOwnerRecoveryTest.php` to lock break-glass separation and the combined recovery boundary. Existing `BreakGlassModeTest.php` required no edit; it was re-run, while combined boundary regression coverage was added around recovery. - [x] T008 [P] Add or extend feature coverage in `apps/platform/tests/Feature/Filament/Settings/WorkspaceSupportAccessApprovalTest.php` and `apps/platform/tests/Feature/Monitoring/AuditLogSupportAccessHistoryTest.php` to lock owner approval and workspace-scoped history export. - [x] T009 Create `apps/platform/database/migrations/*_create_support_access_grants_table.php`, `apps/platform/app/Models/SupportAccessGrant.php`, and `apps/platform/database/factories/SupportAccessGrantFactory.php` for workspace-owned grant history. - [x] T010 Implement `apps/platform/app/Services/Auth/SupportAccessGrantResolver.php` and `apps/platform/app/Services/Auth/SupportAccessGrantManager.php` to own request, approval, denial, activation, expiry, end, and dedupe behavior. - [x] T011 Extend `apps/platform/app/Support/Audit/AuditActionId.php`, `apps/platform/app/Support/Auth/PlatformCapabilities.php`, `apps/platform/app/Services/Audit/WorkspaceAuditLogger.php`, and `apps/platform/app/Services/SystemConsole/SystemConsoleAuditLogger.php` for stable support-access audit actions and the new platform capability. Repo truth: the existing audit loggers already accept stable action IDs, so no direct logger edit was required. **Checkpoint**: One workspace-owned support-access truth exists and all affected surfaces can depend on the same grant state. --- ## Phase 3: User Story 1 - Request and activate bounded workspace support access (Priority: P1) **Goal**: Authorized platform users can request or end workspace-scoped support access from the existing system workspace detail page. **Independent Test**: Open `ViewWorkspace`, request `audit_view`, confirm the active summary and system audit trail update, then end the grant again. ### Tests for User Story 1 - [x] T012 [P] [US1] Extend `apps/platform/tests/Feature/System/SupportAccessRequestFlowTest.php` to prove request validation, immediate activation for `audit_view`, early end, ownerless waiver activation, and wrong-plane or wrong-capability denials. - [x] T013 [P] [US1] Extend `apps/platform/tests/Feature/System/Spec114/AccessLogsTest.php` to prove support-access events appear in the existing system access log family. ### Implementation for User Story 1 - [x] T014 [US1] Update `apps/platform/app/Filament/System/Pages/Directory/ViewWorkspace.php` so the page renders current support-access posture and owns `Request support access` plus `End support access` actions. - [x] T015 [US1] Update `apps/platform/app/Filament/System/Pages/Security/AccessLogs.php` so support-access lifecycle events are included in the existing system security history scope with the new stable audit action family. - [x] T016 [US1] Add any bounded summary presenter or helper needed so the system detail page shows scope, requester, reason, approval state, and expiry without duplicating grant logic. **Checkpoint**: The system workspace detail page becomes the one ordinary support-access entry point. --- ## Phase 4: User Story 2 - Approve risky recovery and keep break-glass separate (Priority: P1) **Goal**: Workspace owners approve high-risk recovery requests, and the existing owner-repair utility requires both support access and break-glass. **Independent Test**: Request `workspace_recovery`, approve it from workspace settings, activate break-glass, and confirm `RepairWorkspaceOwners` only succeeds when both prerequisites are active. ### Tests for User Story 2 - [x] T017 [P] [US2] Extend `apps/platform/tests/Feature/Filament/Settings/WorkspaceSupportAccessApprovalTest.php` to prove pending recovery requests, owner approval, owner denial, and ownerless waiver messaging. - [x] T018 [P] [US2] Extend `apps/platform/tests/Feature/System/SupportAccessRecoveryBoundaryTest.php` and `apps/platform/tests/Feature/Auth/BreakGlassWorkspaceOwnerRecoveryTest.php` to prove recovery requires the correct workspace-scoped grant plus active break-glass and that `audit_view` never satisfies the recovery path. ### Implementation for User Story 2 - [x] T019 [US2] Update `apps/platform/app/Filament/Pages/Settings/WorkspaceSettings.php` so workspace owners can approve or deny pending `workspace_recovery` requests and inspect the current support-access summary. - [x] T020 [US2] Update `apps/platform/app/Filament/System/Pages/RepairWorkspaceOwners.php` so the header action and warning copy reflect the combined recovery boundary. - [x] T021 [US2] Keep `BreakGlassSession` separate and ensure the recovery page consumes support-access state without turning break-glass into ordinary support access. **Checkpoint**: Risky recovery support becomes explicitly approved and visibly distinct from ordinary support access. --- ## Phase 5: User Story 3 - Inspect and export customer-visible support-access history (Priority: P2) **Goal**: Workspace actors can inspect and export support-access history from existing admin audit surfaces. **Independent Test**: Open the admin audit log in a workspace with support-access events, filter to support access, and export the filtered history. ### Tests for User Story 3 - [x] T022 [P] [US3] Extend `apps/platform/tests/Feature/Monitoring/AuditLogSupportAccessHistoryTest.php` to prove workspace-scoped filtering, selected-event inspection, and export behavior. ### Implementation for User Story 3 - [x] T023 [US3] Update `apps/platform/app/Filament/Pages/Monitoring/AuditLog.php` so the page supports a support-access filter preset and workspace-scoped export. - [x] T024 [US3] Confirm the new export path reuses current audit-history semantics instead of creating a second support-history surface. **Checkpoint**: Customer-visible support-access history becomes inspectable and exportable from the current admin audit family. --- ## Phase 6: Polish & Cross-Cutting Validation **Purpose**: Validate the bounded slice and stop before it widens. - [x] T025 [P] Run `export PATH="/bin:/usr/bin:/usr/local/bin:$PATH" && cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Unit/System/SupportAccessGrantResolverTest.php`. - [x] T026 [P] Run `export PATH="/bin:/usr/bin:/usr/local/bin:$PATH" && cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Feature/System/SupportAccessRequestFlowTest.php tests/Feature/System/SupportAccessRecoveryBoundaryTest.php tests/Feature/Auth/BreakGlassModeTest.php tests/Feature/Auth/BreakGlassWorkspaceOwnerRecoveryTest.php tests/Feature/System/Spec114/AccessLogsTest.php`. - [x] T027 [P] Run `export PATH="/bin:/usr/bin:/usr/local/bin:$PATH" && cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Feature/Filament/Settings/WorkspaceSupportAccessApprovalTest.php tests/Feature/Monitoring/AuditLogSupportAccessHistoryTest.php`. - [x] T028 [P] Run `export PATH="/bin:/usr/bin:/usr/local/bin:$PATH" && cd apps/platform && ./vendor/bin/sail bin pint --dirty --format agent`. - [x] T029 [P] Review touched code to confirm Filament stays on Livewire v4, provider registration remains unchanged in `apps/platform/bootstrap/providers.php`, no globally searchable resource is added, no new asset strategy appears, and no impersonation bridge slipped in. - [x] T030 [P] Record the final guardrail and test-governance outcome in the active feature close-out without reopening SCIM, delegated admin browsing, or full IAM scope. --- ## Dependencies & Execution Order ### Phase Dependencies - **Phase 1 (Setup)**: no dependencies; start immediately. - **Phase 2 (Foundational)**: depends on Phase 1 and blocks all user stories. - **Phase 3 (US1)**: depends on Phase 2 and establishes the bounded support-access entry point. - **Phase 4 (US2)**: depends on Phase 2 and should land with US1 so recovery enforcement consumes the finished grant truth. - **Phase 5 (US3)**: depends on Phase 2 and should land after US1 so history export reflects the final grant lifecycle. - **Phase 6 (Polish)**: depends on all desired user stories being complete. ### User Story Dependencies - **US1 (P1)**: independently testable after Phase 2 and delivers the ordinary support-access lifecycle. - **US2 (P1)**: independently testable after Phase 2 and should ship with US1 so recovery uses the same grant truth. - **US3 (P2)**: independently testable after Phase 2 and can follow once support-access events exist. ### Within Each User Story - Write the listed Pest coverage first and make it fail for the intended gap. - Keep implementation inside the current model, resolver, system detail, settings, history, and recovery seams named above. - Re-run the narrowest relevant validation command after each story checkpoint before moving on. --- ## Implementation Strategy ### Suggested MVP Scope - MVP = **US1 + US2 together**. The feature is only valuable when workspace support access exists and the recovery path actually depends on it. ### Incremental Delivery 1. Complete Phase 1 and Phase 2. 2. Deliver US1 so support access can be requested and ended safely. 3. Deliver US2 so risky recovery consumes the same support-access truth. 4. Add US3 for customer-visible history and export. 5. Finish with the focused validation and drift-review tasks in Phase 6. ### Team Strategy 1. Settle persistence and resolver shape first. 2. Parallelize failing tests within each story before runtime edits. 3. Serialize merges around `ViewWorkspace`, `WorkspaceSettings`, `RepairWorkspaceOwners`, and `AuditLog` so support vocabulary and history semantics stay coherent. --- ## Deferred Follow-Ups / Non-Goals - impersonation or delegated admin browsing - SCIM or broader SSO follow-through - support ticket or case integration - broader support scope catalogs beyond `audit_view` and `workspace_recovery`