ahmido/TenantAtlas
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects 1 Releases Wiki Activity
095-graph-contracts-registry-completeness
TenantAtlas/specs/090-action-surface-contract-compliance/tasks.md
ahmido 90bfe1516e feat(spec-090): action surface contract compliance (#108) 
Implements Spec 090 (Action Surface Contract Compliance & RBAC Hardening).

Highlights:
- Adds/updates action surface declarations and shrinks baseline exemptions.
- Standardizes Filament action grouping/order and empty-state CTAs.
- Enforces RBAC UX semantics (non-member -> 404, member w/o capability -> disabled + tooltip, server-side 403).
- Adds audit logging for successful side-effect actions.
- Fixes Provider Connections list context so header create + row actions resolve tenant correctly.

Tests (focused):
- vendor/bin/sail artisan test --compact tests/Feature/090/
- vendor/bin/sail artisan test --compact tests/Feature/Guards/ActionSurfaceContractTest.php
- vendor/bin/sail bin pint --dirty

Livewire/Filament:
- Filament v5 + Livewire v4 compliant.
- No panel provider registration changes (Laravel 11+ registration remains in bootstrap/providers.php).

Co-authored-by: Ahmed Darrazi <ahmed.darrazi@live.de>
Reviewed-on: #108
2026-02-13 01:30:22 +00:00

9.8 KiB
Raw Permalink Blame History

description
Tasks for Spec 090 implementation

Tasks: Action Surface Contract Compliance & RBAC Hardening (Spec 090)

Input: Design documents from specs/090-action-surface-contract-compliance/

Docs used:

  • spec.md (user stories + acceptance + UI Action Matrix)
  • plan.md (implementation phases + repo paths)
  • research.md, data-model.md, quickstart.md, contracts/

Tests: REQUIRED (Pest) — this spec changes runtime behavior (RBAC + Filament action surfaces).

Phase 1: Setup (Shared Infrastructure)

  • T001 Confirm current plan/spec alignment in specs/090-action-surface-contract-compliance/plan.md
  • T002 Reconcile “View action” vs “inspection affordance” wording in specs/090-action-surface-contract-compliance/spec.md (match constitution: clickable rows OR View action OR primary link)
  • T003 [P] Baseline-run guard tests via specs/090-action-surface-contract-compliance/quickstart.md (ensure current failures are understood)
  • T004 [P] Inventory in-scope exemptions in app/Support/Ui/ActionSurface/ActionSurfaceExemptions.php and list the exact classes to remove in specs/090-action-surface-contract-compliance/research.md

Phase 2: Foundational (Blocking Prerequisites)

⚠️ CRITICAL: No user story work should start until this phase is complete.

  • T005 Update the UI Action Matrix in specs/090-action-surface-contract-compliance/spec.md with the exact intended actions + gating per in-scope surface
  • T006 [P] Identify the canonical capability constants for each hotspot in app/Support/Auth/Capabilities.php and record them in specs/090-action-surface-contract-compliance/spec.md
  • T007 Create Spec 090 test folder tests/Feature/090/ with a short README section in specs/090-action-surface-contract-compliance/quickstart.md describing how to run only Spec 090 tests
  • T008 [P] Add a Spec 090 RBAC semantics test skeleton in tests/Feature/090/RbacSemanticsTest.php (non-member 404 vs member missing capability 403)
  • T009 [P] Add a Spec 090 audit logging test skeleton in tests/Feature/090/AuditLoggingTest.php (successful side-effect → audit entry; denied attempts → no audit required)

Checkpoint: Foundations ready — user stories can now proceed in priority order.

Phase 3: User Story 1 — Safe admin actions (Priority: P1) 🎯 MVP

Goal: Capability-first gating + correct 404/403 semantics + successful audit logging for in-scope side-effect actions.

Independent Test: For one or more representative side-effect actions, verify:

  • non-member cannot access/execute (404 semantics)
  • member without capability cannot execute (403 semantics)
  • member with capability can execute/dispatch and an audit log is written

Tests for User Story 1

  • T010 [P] [US1] Implement “non-member → 404” coverage for a tenant-scoped side-effect action in tests/Feature/090/RbacSemanticsTest.php
  • T011 [P] [US1] Implement “member missing capability → 403” coverage for the same action in tests/Feature/090/RbacSemanticsTest.php
  • T012 [P] [US1] Implement “success → audit log entry created” coverage in tests/Feature/090/AuditLoggingTest.php
  • T013 [P] [US1] Implement “denied/cancelled attempts do not require audits” assertion in tests/Feature/090/AuditLoggingTest.php

Implementation for User Story 1

  • T014 [US1] Add capability-first gating to Policy “Capture snapshot” action in app/Filament/Resources/PolicyResource/Pages/ViewPolicy.php
  • T015 [US1] Add successful audit logging for “Capture snapshot” dispatch using App\Services\Intune\AuditLogger in app/Filament/Resources/PolicyResource/Pages/ViewPolicy.php
  • T016 [US1] Remove misuse of destructive semantics for Policy “Sync from Intune” confirmation in app/Filament/Resources/PolicyResource/Pages/ListPolicies.php (keep confirmation, but non-destructive)
  • T017 [US1] Ensure server-side enforcement (404/403 semantics) for these actions is applied via App\Support\Rbac\UiEnforcement in app/Filament/Resources/PolicyResource/Pages/ViewPolicy.php and app/Filament/Resources/PolicyResource/Pages/ListPolicies.php
  • T018 [US1] Run focused tests for US1 via vendor/bin/sail artisan test --compact tests/Feature/090/RbacSemanticsTest.php
  • T019 [US1] Run focused tests for US1 via vendor/bin/sail artisan test --compact tests/Feature/090/AuditLoggingTest.php

Checkpoint: US1 is fully demonstrable and independently testable.

Phase 4: User Story 2 — Consistent action surfaces (Priority: P2)

Goal: Every in-scope list/table has an inspection affordance and consistent action ordering/grouping; Action Surface Contract exemptions shrink.

Independent Test: Guard tests pass while removing baseline exemptions for the in-scope components; visual review shows consistent “View/Edit/More” ordering.

Tests for User Story 2

  • T020 [P] [US2] Keep tests/Feature/Guards/ActionSurfaceContractTest.php green while removing baseline exemptions (guard is the primary gate)
  • T021 [P] [US2] Add a small regression test in tests/Feature/090/ActionSurfaceSmokeTest.php asserting in-scope resources are no longer baseline-exempt (optional helper to catch accidental re-exemption)

Implementation for User Story 2

  • T022 [US2] Add actionSurfaceDeclaration() to app/Filament/Resources/ProviderConnectionResource.php (satisfy header/row/bulk/empty-state slots or explicit exemptions with reasons)

  • T023 [US2] Add actionSurfaceDeclaration() to app/Filament/Resources/BackupScheduleResource.php (include empty-state CTA slot definition)

  • T024 [US2] Add actionSurfaceDeclaration() to app/Filament/Resources/FindingResource.php

  • T025 [US2] Add actionSurfaceDeclaration() to app/Filament/Resources/TenantResource.php

  • T026 [US2] Add actionSurfaceDeclaration() to app/Filament/Resources/Workspaces/WorkspaceResource.php

  • T027 [US2] Normalize ProviderConnection row action group to match baseline ordering + grouping (keep clickable-row inspection; rename group label to “More”; keep destructive-like actions last; ensure max 2 visible row actions) in app/Filament/Resources/ProviderConnectionResource.php

  • T028 [US2] Reorder Finding row actions so View is first; move secondary actions (e.g., acknowledge) into a “More” ActionGroup in app/Filament/Resources/FindingResource.php

  • T029 [US2] Ensure bulk actions are grouped via BulkActionGroup labelled “More” in app/Filament/Resources/FindingResource.php

  • T030 [US2] Ensure destructive actions are not primary, require confirmation, and appear last in app/Filament/Resources/TenantResource.php

  • T031 [US2] Remove baseline exemptions for the updated components from app/Support/Ui/ActionSurface/ActionSurfaceExemptions.php (only after declarations exist)

  • T032 [US2] Run guard tests via vendor/bin/sail artisan test --compact tests/Feature/Guards/ActionSurfaceContractTest.php

Checkpoint: US2 passes guard tests and provides consistent action surfaces.

Phase 5: User Story 3 — Productive empty states (Priority: P3)

Goal: Empty state CTAs exist for in-scope resources and are capability-gated.

Independent Test: When lists are empty, the “New …” CTA is shown only for users who can create.

Tests for User Story 3

  • T033 [P] [US3] Add empty-state CTA visibility test for Workspaces list in tests/Feature/090/EmptyStateCtasTest.php
  • T034 [P] [US3] Add empty-state CTA visibility test for Backup schedules list in tests/Feature/090/EmptyStateCtasTest.php

Implementation for User Story 3

  • T035 [US3] Add capability-gated empty-state “New workspace” action on the Workspaces list in app/Filament/Resources/Workspaces/WorkspaceResource.php
  • T036 [US3] Add capability-gated empty-state “New backup schedule” action on the Backup schedules list in app/Filament/Resources/BackupScheduleResource.php
  • T037 [US3] Run focused tests via vendor/bin/sail artisan test --compact tests/Feature/090/EmptyStateCtasTest.php

Checkpoint: US3 delivers clear empty states with correct gating.

Phase 6: Polish & Cross-Cutting Concerns

  • T038 [P] Run formatter on modified code in app/, tests/, and specs/090-action-surface-contract-compliance/ via vendor/bin/sail bin pint --dirty
  • T039 Run Spec 090 focused pack: vendor/bin/sail artisan test --compact tests/Feature/090/
  • T040 Run guard pack: vendor/bin/sail artisan test --compact tests/Feature/Guards/ActionSurfaceContractTest.php
  • T041 Update specs/090-action-surface-contract-compliance/quickstart.md with the final minimal commands for: guard tests, Spec 090 tests, and pint
  • T042 [P] Verify global search remains tenant-scoped by confirming app/Filament/Concerns/ScopesGlobalSearchToTenant.php behavior and keeping existing scoping tests green: tests/Feature/Filament/TenantScopingTest.php and tests/Feature/Spec080WorkspaceManagedTenantAdminMigrationTest.php

Dependencies & Execution Order

Phase dependencies

  • Setup (Phase 1) → Foundational (Phase 2) → US1 (Phase 3) → US2 (Phase 4) → US3 (Phase 5) → Polish (Phase 6)

User story dependency graph

  • US1 is the MVP and can ship first.
  • US2 and US3 can start after Foundational, but should be delivered in priority order (P2 then P3).

Parallel execution examples

US1 parallel work

  • [P] T010 + T011 + T012 + T013 can be implemented in parallel (different test sections/files).
  • [P] T014 and T016 can be worked on in parallel (different Filament pages), then converged for T017.

US2 parallel work

  • [P] T022–T026 declarations can be started in parallel (different resources), but exemption removal T031 must be last.
  • [P] T027–T030 action reordering can proceed in parallel after each resource compiles.

US3 parallel work

  • [P] T033 and T034 can be done in parallel (same file, different test blocks).
  • [P] T035 and T036 can be done in parallel (different resources).