TenantAtlas/specs/193-monitoring-action-hierarchy/plan.md
ahmido bef9020159 feat: implement spec 193 monitoring action hierarchy (#227)
## Summary
- codify Spec 193 as an explicit monitoring/workbench surface inventory with validator and guard coverage
- refactor the Finding Exceptions Queue, Operations landing, and tenantless operation viewer into clearer context, navigation, utility, drilldown, and focused-work lanes
- align Alerts, Audit Log, and Alert Deliveries with quiet origin-context handling while preserving calm reference surfaces and the explicit Tenant Diagnostics exception
- add focused feature coverage, guard coverage, browser smoke coverage, and the full spec artifacts for Spec 193

## Verification
- `cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Feature/Guards/ActionSurfaceContractTest.php tests/Feature/Guards/ActionSurfaceValidatorTest.php tests/Feature/Guards/Spec193MonitoringSurfaceHierarchyGuardTest.php tests/Feature/OpsUx/OperateHubShellTest.php tests/Feature/Operations/TenantlessOperationRunViewerTest.php tests/Feature/Monitoring/FindingExceptionsQueueHierarchyTest.php tests/Browser/Spec193MonitoringSurfaceHierarchySmokeTest.php`
- `cd apps/platform && ./vendor/bin/sail bin pint --dirty --format agent`
- integrated-browser smoke pass over queue, operations, operation detail, alerts, audit log, and tenant diagnostics

## Notes
- Livewire v4 / Filament v5 stack unchanged
- no provider-registration changes; Laravel 11+ provider registration remains in `bootstrap/providers.php`
- no new global-search behavior was introduced
- destructive and governance-changing actions keep their existing confirmation and authorization semantics
- no new assets or migrations were added

Co-authored-by: Ahmed Darrazi <ahmed.darrazi@live.de>
Reviewed-on: #227
2026-04-12 10:48:00 +00:00

23 KiB
Raw Blame History

Implementation Plan: Monitoring Surface Action Hierarchy and Workbench Semantics

Branch: 193-monitoring-action-hierarchy | Date: 2026-04-11 | Spec: /Users/ahmeddarrazi/Documents/projects/TenantAtlas/specs/193-monitoring-action-hierarchy/spec.md Input: Feature specification from /Users/ahmeddarrazi/Documents/projects/TenantAtlas/specs/193-monitoring-action-hierarchy/spec.md

Note: This plan keeps the work inside the existing Filament v5 / Livewire v4 page layer, existing OperateHubShell and CanonicalNavigationContext scope helpers, and the current action-surface guard infrastructure. It explicitly avoids adding a new monitoring-action framework.

Summary

Codify one bounded action-layer contract for monitoring, queue, operations, and workbench surfaces in the admin panel. Reuse existing Filament header actions, ActionGroup, UiEnforcement, OperateHubShell, CanonicalAdminTenantFilterState, and the existing ActionSurfaceValidator extension path to inventory all in-scope surfaces, remediate the three clearly problematic workbench pages, convert the alerts overview into an explicitly declared in-scope monitoring surface, preserve calm bounded-scope pages as references, document TenantDiagnostics as the only special-type exception, and extend guard plus browser regression layers so mixed monitoring headers do not return.

Technical Context

Language/Version: PHP 8.4.15
Primary Dependencies: Laravel 12, Filament v5, Livewire v4, Pest v4, Tailwind CSS v4, existing OperateHubShell, CanonicalNavigationContext, CanonicalAdminTenantFilterState, UiEnforcement, ActionSurfaceValidator, and Filament page or resource action builders
Storage: PostgreSQL through existing workspace-owned and tenant-owned models; no schema change planned
Testing: Pest feature tests, existing guard tests, and Pest browser smoke tests run through Laravel Sail
Target Platform: Laravel monolith web application under apps/platform, with canonical workspace-context monitoring routes under /admin, tenant-context routes under /admin/t/{tenant}/..., and cluster-backed monitoring routes under /admin/alerts
Project Type: web application
Performance Goals: Preserve the 5-second scan rule for monitoring surfaces, keep monitoring renders DB-only with no outbound HTTP or queued jobs at render time, avoid adding new polling beyond existing run-detail behavior, and avoid query churn when separating action layers
Constraints: No new action framework, no new persistence, no route or panel changes, no authorization-plane changes, no new badge taxonomy, no silent surface exemptions, no record-page header rules copied directly onto workbench pages, and no expansion of confirmation depth, reason capture, or run semantics beyond existing actions
Scale/Scope: 11 in-scope surfaces, 3 remediation-required core pages, 3 minor-alignment audits, 4 compliant or no-op bounded-scope references, 1 special-type exception, existing Blade views for monitoring pages, and focused guard plus feature plus browser regression coverage

Constitution Check

GATE: Passed before Phase 0 research. Re-checked after Phase 1 design and still passing.

Principle Pre-Research Post-Design Notes
Inventory-first / snapshots-second PASS PASS The feature does not alter inventory, snapshots, or backup truth. It only reorganizes monitoring surfaces.
Read/write separation PASS PASS Existing write actions such as approve, reject, and tenant repair keep their current confirmation, audit, and test behavior. No new writes are introduced.
Graph contract path N/A N/A No new Microsoft Graph call path or contract-registry change is planned.
Deterministic capabilities PASS PASS Capability checks remain in the canonical registries plus UiEnforcement; regrouping actions does not change entitlement logic.
Workspace + tenant isolation PASS PASS Existing route scopes, OperateHubShell resolution, and tenant-safe drilldown rules remain authoritative.
RBAC-UX authorization semantics PASS PASS Non-members remain 404, member-without-capability remains 403, and server-side checks remain unchanged.
Run observability / Ops-UX PASS PASS Existing OperationRun-backed actions keep their current queued-toast, monitoring-detail, and terminal-status semantics.
Data minimization PASS PASS No new persistence, caches, or cross-surface helper artifacts are introduced.
Proportionality / anti-bloat PASS PASS The work extends the existing inventory and validation layers rather than introducing a new monitoring-action engine.
UI semantics / few layers PASS PASS The feature uses direct action placement and explicit classification, not a new presenter or interpretation layer.
Filament-native UI PASS PASS Native Filament actions, action groups, pages, tables, and shared context bars remain the implementation path.
Surface taxonomy / monitoring-specific hierarchy PASS PASS The plan explicitly distinguishes monitoring/workbench surfaces from Spec 192 record pages and documents the allowed exception.
Filament v5 / Livewire v4 compliance PASS PASS All touched surfaces stay inside the existing Filament v5 + Livewire v4 stack.
Provider registration location PASS PASS No provider change is needed; Laravel 11+ provider registration remains in bootstrap/providers.php.
Global search hard rule PASS PASS No new globally searchable resource is introduced and no resource search settings are changed. Existing searchable resources already have View/Edit pages where needed.
Destructive action safety PASS PASS Existing confirmed actions such as exception approval or rejection and tenant repair actions keep ->requiresConfirmation() plus current authorization.
Asset strategy PASS PASS No new global or on-demand asset registration is needed. Existing deployment handling of cd apps/platform && php artisan filament:assets remains unchanged.

Filament-Specific Compliance Notes

  • Livewire v4.0+ compliance: The plan remains on Filament v5 + Livewire v4 and introduces no legacy or mixed-version API usage.
  • Provider registration location: No panel or provider changes are required; Laravel 11+ panel providers remain registered in bootstrap/providers.php.
  • Global search: The feature does not add a new globally searchable resource and does not alter global-search visibility for existing resources. Touched monitoring pages remain page-level surfaces or reuse existing resource detail pages.
  • Destructive actions: Approve exception, Reject exception, Bootstrap owner, and Merge duplicate memberships remain routed through Action::make(...)->action(...) with ->requiresConfirmation() plus existing authorization and audit semantics.
  • Asset strategy: No new global or lazy-loaded assets are planned. Existing deployment handling of cd apps/platform && php artisan filament:assets remains sufficient.
  • Testing plan: Extend the existing action-surface guard layer, add focused Pest tests for the remediated and exception surfaces, and add a browser smoke suite that proves visible monitoring hierarchy on the remediated pages and no-regression behavior on reference pages.

Phase 0 Research

Research outcomes are captured in /Users/ahmeddarrazi/Documents/projects/TenantAtlas/specs/193-monitoring-action-hierarchy/research.md.

Key decisions:

  • Reuse the existing ActionSurfaceExemptions plus ActionSurfaceValidator inventory pattern from Spec 192 instead of creating a new monitoring-action framework.
  • Keep OperateHubShell and CanonicalNavigationContext as the single scope and return-context sources for canonical /admin monitoring pages.
  • Express hierarchy through native Filament actions, ActionGroup, existing context bars, and targeted Blade adjustments rather than custom header components.
  • Retire the blanket baseline exemption for Alerts and bring it into explicit Spec 193 declaration plus inventory coverage.
  • Build regression protection on top of the existing guard tests, OperateHubShellTest, focused page tests, and one dedicated browser smoke suite.

Phase 1 Design

Design artifacts are created under /Users/ahmeddarrazi/Documents/projects/TenantAtlas/specs/193-monitoring-action-hierarchy/:

  • research.md: decisions and rejected alternatives for monitoring/workbench hierarchy
  • data-model.md: derived surface inventory, action-layer, and regression expectation models
  • contracts/monitoring-action-hierarchy.logical.openapi.yaml: internal logical contract for monitoring-surface action layers and exception handling
  • quickstart.md: implementation and verification sequence for the feature

Design highlights:

  • Keep all classification and action-layer rules derived, not persisted.
  • Represent each in-scope surface through one explicit inventory entry and one explicit regression expectation.
  • Extend the existing action-surface validation layer with a second bounded inventory for monitoring/workbench surfaces.
  • Keep selection-state logic local to the affected pages instead of moving it into a shared runtime resolver.
  • Treat TenantDiagnostics as the only explicit special-type exception and require an exception reason in the guard layer.

Phase 1 — Agent Context Update

Planned command:

  • .specify/scripts/bash/update-agent-context.sh copilot

This feature does not introduce a new technology stack, but the required agent-context refresh still runs after the technical context and design artifacts are complete.

Project Structure

Documentation (this feature)

specs/193-monitoring-action-hierarchy/
├── plan.md
├── research.md
├── data-model.md
├── quickstart.md
├── spec.md
├── contracts/
│   └── monitoring-action-hierarchy.logical.openapi.yaml
└── checklists/
    └── requirements.md

Source Code (repository root)

apps/platform/
├── app/
│   ├── Filament/
│   │   ├── Pages/
│   │   │   ├── Monitoring/
│   │   │   │   ├── FindingExceptionsQueue.php                     # MODIFY
│   │   │   │   ├── Operations.php                                 # MODIFY
│   │   │   │   ├── Alerts.php                                     # MODIFY (add declaration + minor alignment)
│   │   │   │   ├── AuditLog.php                                   # AUDIT / possible minor alignment
│   │   │   │   └── EvidenceOverview.php                           # REFERENCE only
│   │   │   ├── Operations/
│   │   │   │   └── TenantlessOperationRunViewer.php               # MODIFY
│   │   │   ├── Reviews/
│   │   │   │   └── ReviewRegister.php                             # REFERENCE only
│   │   │   ├── BaselineCompareLanding.php                         # REFERENCE only
│   │   │   ├── BaselineCompareMatrix.php                          # REFERENCE only
│   │   │   └── TenantDiagnostics.php                              # AUDIT / special-type exception
│   │   └── Resources/
│   │       ├── AlertDeliveryResource.php                          # REUSE / possible declaration notes
│   │       └── AlertDeliveryResource/
│   │           └── Pages/
│   │               └── ListAlertDeliveries.php                    # AUDIT / possible minor alignment
│   ├── Support/
│   │   ├── OperateHub/
│   │   │   └── OperateHubShell.php                                # REUSE
│   │   ├── Navigation/
│   │   │   └── CanonicalNavigationContext.php                     # REUSE
│   │   ├── Filament/
│   │   │   └── CanonicalAdminTenantFilterState.php                # REUSE
│   │   ├── Rbac/
│   │   │   └── UiEnforcement.php                                  # REUSE
│   │   └── Ui/
│   │       └── ActionSurface/
│   │           ├── ActionSurfaceExemptions.php                    # MODIFY
│   │           ├── ActionSurfaceValidator.php                     # MODIFY
│   │           └── ActionSurfaceProfileDefinition.php             # POSSIBLE MODIFY
├── resources/
│   └── views/
│       └── filament/
│           ├── partials/
│           │   └── context-bar.blade.php                          # REUSE / possible minor alignment
│           └── pages/
│               ├── monitoring/
│               │   ├── finding-exceptions-queue.blade.php         # MODIFY
│               │   ├── operations.blade.php                       # POSSIBLE MODIFY
│               │   ├── alerts.blade.php                           # POSSIBLE MODIFY
│               │   └── audit-log.blade.php                        # POSSIBLE MODIFY
│               ├── operations/
│               │   └── tenantless-operation-run-viewer.blade.php  # MODIFY
│               ├── reviews/
│               │   └── review-register.blade.php                  # REFERENCE only
│               ├── baseline-compare-landing.blade.php             # REFERENCE only
│               ├── baseline-compare-matrix.blade.php              # REFERENCE only
│               └── tenant-diagnostics.blade.php                   # REFERENCE / special-type audit
└── tests/
    ├── Feature/
    │   ├── Guards/
    │   │   ├── ActionSurfaceContractTest.php                      # MODIFY
    │   │   ├── ActionSurfaceValidatorTest.php                     # MODIFY
    │   │   └── Spec193MonitoringSurfaceHierarchyGuardTest.php     # NEW
    │   ├── Monitoring/
    │   │   ├── AuditLogInspectFlowTest.php                        # REUSE / possible extend
    │   │   ├── OperationsCanonicalUrlsTest.php                    # MODIFY or REUSE
    │   │   ├── OperationsDashboardDrillthroughTest.php            # MODIFY or REUSE
    │   │   ├── OperationsRelatedNavigationTest.php                # MODIFY or REUSE
    │   │   ├── FindingExceptionsQueueHierarchyTest.php            # NEW
    │   │   └── OperationsHeaderHierarchyTest.php                  # NEW
    │   ├── Operations/
    │   │   └── TenantlessOperationRunViewerTest.php               # MODIFY
    │   ├── OpsUx/
    │   │   └── OperateHubShellTest.php                            # MODIFY
    │   └── Rbac/
    │       ├── ActionSurfaceRbacSemanticsTest.php                 # REUSE / possible extend
    │       └── TenantActionSurfaceConsistencyTest.php             # REUSE / possible extend
    └── Browser/
        ├── Spec192RecordPageHeaderDisciplineSmokeTest.php         # REUSE for patterns
        └── Spec193MonitoringSurfaceHierarchySmokeTest.php         # NEW

Structure Decision: Keep the work entirely inside the existing Laravel/Filament monolith under apps/platform. Modify only the affected page classes, a small set of monitoring Blade views, the existing action-surface validation layer, and focused tests. Do not create a new runtime resolver or header-framework layer.

Complexity Tracking

Violation Why Needed Simpler Alternative Rejected Because
Cross-page monitoring/workbench taxonomy and explicit exception catalog (BLOAT-001 trigger) The feature must distinguish remediation-required workbench pages, shared-pattern audit pages, calm bounded-scope references, and the single acceptable diagnostic exception in a way CI can validate. Pure local cleanup would reduce visible clutter but would not prevent future drift or explain why some monitoring surfaces are preserved while others are remediated.

Proportionality Review

  • Current operator problem: Monitoring and workbench pages still mix scope, navigation, utility, and active work actions in one header lane, slowing queue review and making next-step semantics ambiguous.
  • Existing structure is insufficient because: The constitution and Spec 192 now govern other action-surface classes, but the repo lacks a bounded implementation inventory and regression hook for this monitoring/workbench surface class.
  • Narrowest correct implementation: Extend the existing action-surface inventory and validation layer with one additional monitoring/workbench inventory, remediate only the three clearly problematic pages, explicitly classify the others, and add focused feature plus browser regression coverage.
  • Ownership cost created: A small extension to the validator and exemption inventory, one new guard test, several focused page tests, one browser smoke suite, and ongoing review discipline for future monitoring surfaces.
  • Alternative intentionally rejected: A new monitoring action-placement engine or registry was rejected because the current repo already has sufficient primitives through Filament actions, OperateHubShell, and the existing action-surface validator.
  • Release truth: current-release operator clarity and action-surface discipline

Implementation Strategy

Phase A — Codify the monitoring inventory and guard contract

Goal: turn the spec inventory into an enforceable project-level contract without introducing a new framework.

Changes:

  • Extend ActionSurfaceExemptions with a spec193MonitoringSurfaceInventory() and per-surface lookup helper.
  • Extend ActionSurfaceValidator with explicit validation of the Spec 193 inventory and its allowed classifications.
  • Add Spec193MonitoringSurfaceHierarchyGuardTest.php to assert completeness, explicit exception reasoning, and bounded reference preservation.
  • Remove the blanket baseline exemption for Alerts and replace it with explicit monitoring-surface coverage.

Tests:

  • Extend ActionSurfaceContractTest.php and ActionSurfaceValidatorTest.php with Spec 193 expectations.
  • Add Spec193MonitoringSurfaceHierarchyGuardTest.php.

Phase B — Remediate the highest-noise workbench surfaces

Goal: implement the core hierarchy wins first on the pages with the clearest mixed-header problem.

Changes:

  • Refactor FindingExceptionsQueue so scope, return, filters, drilldowns, and selected-exception decisions no longer render as flat peers.
  • Refactor TenantlessOperationRunViewer so scope, return, show-all, refresh, related links, and resumable actions render as distinct layers.
  • Refactor Operations so scope and show-all context stay visible but no longer read as the pages primary work surface.

Tests:

  • Add focused page tests for no-selection vs selected-workbench behavior on FindingExceptionsQueue.
  • Extend TenantlessOperationRunViewerTest.php and relevant Monitoring tests with hierarchy and navigation assertions.

Phase C — Tighten shared patterns and classify bounded-scope references

Goal: bring shared monitoring patterns under the same contract without rebuilding calm pages.

Changes:

  • Add an explicit declaration to Alerts and audit its origin-context placement.
  • Review AuditLog and ListAlertDeliveries for minor alignment only, changing them only where real action-layer ambiguity exists.
  • Confirm EvidenceOverview, BaselineCompareLanding, BaselineCompareMatrix, and ReviewRegister remain compliant or no-op references.
  • Keep TenantDiagnostics as the single special-type acceptable exception and codify why it is allowed.

Tests:

  • Extend OperateHubShellTest.php for scope-label and return-affordance expectations that remain relevant after the monitoring refactor.
  • Add focused assertions for the Alerts overview in AlertsHierarchyTest.php, keep alert-delivery minor-alignment coverage in the existing alert-delivery suites, and verify that minor-alignment pages remain calm or declaration-complete.

Phase D — Browser verification and final regression protection

Goal: prove the new hierarchy in a real browser and prevent future mixed monitoring headers from re-entering the repo.

Changes:

  • Add Spec193MonitoringSurfaceHierarchySmokeTest.php covering the three remediated pages, the TenantDiagnostics exception surface, and a no-regression subset of calm reference pages.
  • Ensure the guard layer fails on scope-as-CTA regressions, mixed selection and global header lanes, and undocumented exceptions.
  • Re-run formatting and the focused Sail test pack.

Tests:

  • Browser smoke coverage for visible hierarchy and no JavaScript errors.
  • Focused guard and feature tests for each remediated or exception surface.

Risk Assessment

Risk Impact Likelihood Mitigation
Cleanup grows into a new monitoring-action framework Medium Low Keep all work inside existing pages, views, and validator layers.
Shared-pattern loyalty masks real hierarchy issues High Medium Treat OperateHubShell pages as review targets, not automatic exemptions.
Selection-aware workbench pages become too quiet when no selection exists Medium Medium Add explicit no-selection vs selected-state tests on the queue and viewer surfaces.
Alerts stays outside regression coverage because of the old cluster exemption Medium Medium Convert it to explicit declaration plus inventory coverage in Phase A.
Calm bounded-scope pages get unnecessary churn Medium Low Maintain an explicit compliant/no-op reference set and cover it in browser smoke.

Test Strategy

  • Extend ActionSurfaceContractTest.php and ActionSurfaceValidatorTest.php so Spec 193 becomes an explicit CI-enforced rule instead of a manual review note.
  • Add Spec193MonitoringSurfaceHierarchyGuardTest.php to validate remediation-required pages, minor-alignment pages, calm references, and the explicit diagnostic exception.
  • Add focused feature tests for FindingExceptionsQueue, Operations, and TenantlessOperationRunViewer covering state-driven hierarchy, scope behavior, and preserved authorization semantics.
  • Reuse and extend OperateHubShellTest.php to keep DB-only rendering, tenant-context resolution, and scope-label behavior correct on canonical monitoring pages.
  • Add Spec193MonitoringSurfaceHierarchySmokeTest.php using the existing browser-smoke patterns already present in Spec 192 and other surface smoke tests.
  • Add explicit regression assertions that this feature does not expand confirmation depth, reason capture, provider-dispatch semantics, or record-page header rules.
  • Run the focused Sail verification commands from quickstart.md, then run cd apps/platform && ./vendor/bin/sail bin pint --dirty --format agent.

Constitution Check (Post-Design)

Re-check result: PASS.

  • Livewire v4.0+ compliance remains intact because all touched surfaces stay inside the existing Filament v5 + Livewire v4 stack.
  • Provider registration remains unchanged in bootstrap/providers.php.
  • The plan changes no global-search semantics; affected surfaces are pages or existing resource-backed pages whose search behavior already satisfies the Filament hard rule.
  • Destructive and governance-changing actions keep ->requiresConfirmation() plus existing authorization.
  • No new assets are introduced; existing filament:assets deployment behavior remains sufficient.