TenantAtlas/specs/193-monitoring-action-hierarchy/spec.md

Feature Specification: Monitoring Surface Action Hierarchy and Workbench Semantics

Feature Branch: 193-monitoring-action-hierarchy
Created: 2026-04-11
Status: Proposed
Input: User description: "Spec 193 - Monitoring Surface Action Hierarchy and Workbench Semantics"

Spec Candidate Check (mandatory — SPEC-GATE-001)

• Problem: Several monitoring, queue, operations, and workbench surfaces still present scope context, return navigation, utility controls, and selection-bound work actions as one flat header strip.
• Today's failure: Operators can reach the right surface, but the header often fails to answer four questions quickly enough: where am I, what scope am I in, what is selected, and what action is actually next. On queue and monitoring pages, scope chips read like calls to action, related navigation competes with work actions, and selection logic appears at the same visual weight as global surface controls.
• User-visible improvement: Monitoring and workbench surfaces become easier to scan. Scope reads as context, navigation reads as navigation, utilities read as utilities, and selected-object actions only become prominent when there is an active object or selection.
• Smallest enterprise-capable version: Inventory the in-scope monitoring and workbench surfaces, classify each one, remediate the three clearly problematic core surfaces, lightly align shared-pattern neighbors only where needed, explicitly preserve already calm bounded-scope pages, document the one special-type diagnostic surface, and add lightweight regression protection.
• Explicit non-goals: No record-page header rewrite, no new danger or reason-capture policy, no dispatch or preflight redesign, no general bulk-action framework, no full monitoring redesign, and no forced normalization of already calm pages.
• Permanent complexity imported: A narrow monitoring-surface action hierarchy contract, an explicit classification matrix for this surface class, a documented special-type exception, and focused regression coverage for monitoring and workbench action-layer drift.
• Why now: Spec 192 intentionally excludes this surface class. The repo already contains repeated mixed-header patterns on the canonical monitoring surfaces, so leaving the gap open would keep creating inconsistent operator semantics precisely where operations and queue review need the clearest hierarchy.
• Why not local: Page-by-page cleanup would reduce clutter on one screen at a time but would not define the repo-wide rule for separating scope, navigation, utility, and selection layers on monitoring and workbench surfaces, nor would it explain why some pages are calm references while others need layered remediation.
• Approval class: Core Enterprise
• Red flags triggered: Cross-surface UI taxonomy risk and multi-surface cleanup breadth risk. Defense: the spec is limited to one explicit surface class, introduces no new engine or persisted truth, and preserves no-op pages instead of forcing broad redesign.
• Score: Nutzen: 2 | Dringlichkeit: 2 | Scope: 2 | Komplexität: 1 | Produktnähe: 2 | Wiederverwendung: 2 | Gesamt: 11/12
• Decision: approve

Spec Scope Fields (mandatory)

• Scope: canonical-view
• Primary Routes:
  • Existing workspace queue route for Finding Exceptions Queue
  • Existing workspace Operations landing and tenantless operation detail routes
  • Existing workspace Monitoring routes for Alerts, Audit Log, Evidence Overview, and alert deliveries
  • Existing tenant-bound Baseline Compare landing and compare matrix routes
  • Existing workspace Review Register route and tenant review detail route it opens
  • Existing tenant diagnostics route
• Data Ownership:
  • Workspace-scoped monitoring views remain workspace-scoped and continue to display existing workspace-owned or workspace-visible operational records.
  • Tenant-owned records surfaced through these pages remain tenant-owned: finding exceptions, operation runs, evidence snapshots, tenant reviews, and tenant diagnostics context.
  • This spec introduces no new tables, persisted entities, or route truth. It changes only surface classification, action hierarchy, and visible action placement on existing pages.
• RBAC:
  • Existing workspace membership and capability checks continue to govern workspace monitoring surfaces.
  • Existing tenant membership and tenant capability checks continue to govern tenant-bound monitoring surfaces.
  • Regrouping actions does not change authorization semantics: non-members remain 404, members lacking capability remain 403, and destructive or repair actions keep confirmation plus server-side authorization.

For canonical-view specs, the spec MUST define:

• Default filter behavior when tenant-context is active: Workspace monitoring surfaces may keep an entitled remembered tenant context as a prefilter or scope signal, but the tenant-wide view must remain explicit and reversible. Tenant-bound monitoring pages remain bound to the active tenant and do not broaden scope. Selection-aware work actions must never imply a broader scope than the currently filtered or active tenant context.
• Explicit entitlement checks preventing cross-tenant leakage: Scope labels, return links, row drilldowns, and related-navigation affordances must continue to derive from existing capability-aware helpers and entitled-tenant resolution. Moving actions between layers must not expose inaccessible tenants, inaccessible related records, or cross-tenant operation details.

UI/UX Surface Classification (mandatory when operator-facing surfaces are changed)

Surface	Surface Type	Primary Inspect/Open Model	Row Click	Secondary Actions Placement	Destructive Actions Placement	Canonical Collection Route	Canonical Detail Route	Scope Signals	Canonical Noun	Critical Truth Visible by Default	Exception Type
Finding Exceptions Queue	Workspace queue workbench	Explicit inspect action selects one exception and opens the in-page review state	forbidden	Scope, return, clear filters, and drilldown links move into distinct context, utility, and related layers outside the selected-action lane	Selection-bound review decisions stay in the selected-object action layer only when an exception is selected and pending	Existing Finding Exceptions Queue route	Same queue page with selected exception state and tenant detail drilldown	Workspace or remembered-tenant scope, selected exception summary, queue filters	Finding exceptions / exception request	Whether the queue is scoped, whether an exception is selected, and whether a decision is currently available	remediation required
Tenantless Operation Run Viewer	Workspace monitoring detail viewer	Canonical tenantless operation detail page is the only inspect destination for a selected run	forbidden	Scope, back navigation, show-all, refresh, and related links split into context, navigation, utility, and drilldown layers	No destructive action on the viewer; resumable actions stay isolated from navigation and only appear when actually applicable	Existing Operations landing route	Existing tenantless operation detail route	Scope label, origin context, current tenant context mismatch banner, related-run context	Operations / operation run	What run is being viewed, what scope it belongs to, and whether the current context differs from the run tenant	remediation required
Operations	Workspace monitoring landing	Clickable row opens the tenantless operation detail viewer	required	Scope label, return navigation, and show-all behavior separate from tabs, filters, and list interaction	none	Existing Operations route	Existing tenantless operation detail route	Workspace scope, remembered tenant scope, active tab, explicit show-all reset	Operations / operation run	Whether the view is tenant-prefiltered, which operational state tab is active, and what class of runs needs attention	remediation required
Alerts	Workspace monitoring landing	Page-level overview with drilldown into related alert destinations and deliveries	not applicable	Scope and return navigation stay quiet and distinct from alert overview content and related navigation	none	Existing Alerts overview route	Existing alert delivery and destination drilldowns	Workspace scope, origin context	Alerts	Current alert health and KPI context	minor alignment only
Audit Log	Workspace audit history	Explicit inspect action opens selected event detail without changing the page type	forbidden	Scope and return remain in the header; selected-event inspection and related links remain subordinate to audit history	none	Existing Audit Log route	Same page with selected event inspection state	Workspace or tenant prefilter, audit filters, selected event identity	Audit log / audit event	Which event is selected and whether the list is filtered	minor alignment only
List Alert Deliveries	Workspace delivery history resource list	Existing alert-delivery inspect flow remains the primary open model	allowed	Shared OperateHubShell scope and return actions stay quiet; list-level utilities remain separate from resource inspection	none	Existing alert deliveries resource index	Existing alert-delivery resource detail or inspect path	Workspace or remembered-tenant scope	Alert deliveries / alert delivery	Delivery history and current scope	minor alignment only
Evidence Overview	Workspace bounded-scope monitoring report	Clickable row opens the tenant-scoped evidence snapshot detail	required	Single clear-filters utility stays separate from the report body; no additional layering required	none	Existing Evidence Overview route	Existing tenant evidence snapshot view route	Optional tenant prefilter only	Evidence overview / evidence snapshot	Current active evidence freshness and next step by tenant	compliant / no-op
Baseline Compare Matrix	Tenant focused monitoring matrix	Matrix page itself is the focused inspect surface for a selected baseline profile and subject	forbidden	Existing focused compare actions remain local to the matrix context; no extra header hierarchy is required	none	Existing Baseline Compare landing or profile compare entry	Existing compare matrix route	Active tenant, baseline profile, selected subject	Baseline compare matrix	Compare results for one focused profile and subject	compliant / no-op
Baseline Compare Landing	Tenant bounded-scope monitoring landing	Page-level landing remains the canonical monitoring entry for baseline compare status	not applicable	Existing landing actions remain tied to compare state and diagnostics without introducing competing header layers	none	Existing Baseline Compare landing route	Existing compare matrix and finding drilldowns	Active tenant, current compare state, profile context	Baseline compare	Compare coverage, evidence gaps, and next step	compliant / no-op
Review Register	Workspace bounded-scope review register	Clickable row opens the tenant review detail	required	Single clear-filters utility remains sufficient; register actions stay list-scoped and calm	none	Existing Review Register route	Existing tenant review detail route	Tenant filter and review-state filters	Review register / tenant review	Review truth, publication readiness, and next step	compliant / no-op
Tenant Diagnostics	Tenant singleton diagnostic workbench	The diagnostics page itself is the focused diagnostic surface for the current tenant	forbidden	No quiet navigation layer is required beyond normal tenant context; repair actions remain visible only when inconsistency exists	Repair actions remain capability-gated, confirmed, and isolated to the diagnostics exception surface	Existing tenant diagnostics route	Same page	Active tenant, missing-owner state, duplicate-membership state	Tenant diagnostics / tenant repair	Whether the tenant has repair-needed membership inconsistencies	special-type acceptable

Operator Surface Contract (mandatory when operator-facing surfaces are changed)

Surface	Primary Persona	Surface Type	Primary Operator Question	Default-visible Information	Diagnostics-only Information	Status Dimensions Used	Mutation Scope	Primary Actions	Dangerous Actions
Finding Exceptions Queue	Workspace approver	Queue workbench	What scope am I reviewing, is anything selected, and what decision is available right now?	Queue scope, filters, selected exception summary, request status, governance validity	Deep related finding context and tenant detail drilldowns	queue state, validity, selection state	TenantPilot only	Approve exception or Reject exception only when a pending exception is selected	Review decisions are destructive-like governance actions and stay confirmed in the selected-object layer
Tenantless Operation Run Viewer	Operator or manager monitoring one run	Monitoring detail viewer	What run is this, how does it relate to my current scope, and do I need to refresh, resume, or open something related?	Run identity, current outcome, canonical context banner, lifecycle banner, restore continuation context	Related links, redaction integrity detail, deeper failure explanations	execution outcome, freshness, lifecycle attention, context mismatch	Existing run-linked scopes only	Refresh stays utility; resumable action appears only when applicable	none
Operations	Workspace operator	Monitoring landing	Which run class needs attention, and am I looking at one tenant or all tenants?	KPI widgets, active tab, tenant scope, run table	Deep run detail after drilldown	execution status, outcome, problem class, scope	read-only landing	Tab switch and inspect flow only	none
Alerts	Workspace operator	Monitoring landing	Are alerts healthy, and where should I drill down next?	Alert KPIs and current scope	Delivery-detail drilldowns and destination management live downstream	alert health, delivery activity	Existing alert-management scopes only	Existing quiet overview and related drilldowns	none
Audit Log	Workspace operator or auditor	History and inspection surface	What happened, in which scope, and which event needs inspection?	Audit history, filters, selected event context	Event detail body and related target drilldown	audit outcome, actor type, target type, scope	read-only history	Inspect event remains the inspect affordance	none
List Alert Deliveries	Workspace operator	Delivery history list	Which deliveries succeeded or failed, and what scope am I in?	Delivery history and current scope	Delivery-specific inspection downstream	delivery outcome and scope	read-only history	Existing inspect flow only	none
Evidence Overview	Workspace operator	Read-only registry report	Which tenants have current usable evidence, and what is the next step?	Tenant rows, artifact truth, freshness, next step	Downstream evidence snapshot details	artifact truth, freshness	read-only landing	Clear filters and row drilldown only	none
Baseline Compare Matrix	Tenant operator	Focused monitoring matrix	What does this compare show for the currently focused profile and subject?	Compare matrix content and focused subject	Deeper compare diagnostics already inside the surface	coverage and drift	read-only focused analysis	Existing focused compare affordances only	none
Baseline Compare Landing	Tenant operator	Bounded-scope monitoring landing	Is compare current, trustworthy, and what should I inspect next?	Compare state, profile identity, findings count, evidence-gap summary	Deep diagnostics and matrix/finding drilldowns	compare state, coverage, fidelity, evidence gaps	Existing compare and drilldown scopes only	Existing compare-state actions only	none
Review Register	Workspace reviewer	Read-only register	Which reviews are current, complete, and ready for the next lifecycle step?	Review truth, completeness, publication readiness, next step	Downstream review detail	lifecycle, completeness, publication readiness	Existing review export scope when present	Row drilldown and existing scoped export affordance	none
Tenant Diagnostics	Tenant owner or manager	Diagnostic exception surface	Is this tenant structurally broken, and what repair action is justified right now?	Missing-owner and duplicate-membership state	None beyond the diagnostic evidence already on the page	repair-needed state	TenantPilot only	Repair actions only when a defect exists	Bootstrap owner and Merge duplicate memberships remain confirmed and capability-gated

Proportionality Review (mandatory when structural complexity is introduced)

• New source of truth?: no
• New persisted entity/table/artifact?: no
• New abstraction?: no
• New enum/state/reason family?: no
• New cross-domain UI framework/taxonomy?: yes
• Current operator problem: Monitoring and workbench surfaces currently hide action meaning inside one flat header lane, which slows queue review, weakens scope awareness, and makes it harder to tell whether an action is global, contextual, or selection-bound.
• Existing structure is insufficient because: Spec 192 intentionally governs classic record pages, but monitoring and workbench surfaces have a different interaction model with scope context, selected-object state, and read-mostly utilities. Applying record-page rules directly would either flatten legitimate workbench behavior or leave the current ambiguity untouched.
• Narrowest correct implementation: Define the rule only for the named monitoring and workbench surfaces, remediate only the three clearly problematic pages, allow minor alignment on shared-pattern neighbors, preserve already calm bounded-scope surfaces, and document the single acceptable special type.
• Ownership cost: Ongoing review discipline for this surface class, modest browser and regression-test maintenance, and explicit documentation of exceptions and shared patterns.
• Alternative intentionally rejected: Treating these pages as ordinary record headers or doing only local one-off cleanup was rejected because both options would leave the surface-class semantics undocumented and would not protect new monitoring pages from drifting back into mixed header patterns.
• Release truth: current-release operator clarity and workbench surface discipline

User Scenarios & Testing (mandatory)

User Story 1 - Review a queue without header ambiguity (Priority: P1)

As a workspace approver using a monitoring queue, I want the page to separate scope, utilities, selected-record state, and decision actions so I can immediately see whether there is something actionable right now.

Why this priority: Finding Exceptions Queue is the clearest workbench failure in the current scope. If it remains a flat mixed header, the spec has not solved its primary operator problem.

Independent Test: Open the queue with and without a selected exception and confirm that the page visibly changes from quiet monitoring mode to active workbench mode without leaving scope or navigation actions at the same level as approve or reject.

Acceptance Scenarios:

1. Given the queue has no selected exception, When the page renders, Then scope and utility actions remain visible while selected-object decision actions are not prominent.
2. Given a pending exception is selected, When the page renders, Then selection-bound decision actions become the prominent work actions and scope or drilldown links do not read as peer actions.

---

User Story 2 - Read one operation run without mixed context signals (Priority: P1)

As an operator opening a tenantless operation run, I want return navigation, scope context, refresh, related links, and resumable actions to be visibly separated so the viewer reads as a monitoring detail surface instead of a record-page button bar.

Why this priority: The run viewer is a canonical monitoring detail surface and a common drilldown from Operations. If it keeps mixing navigation and run actions, the repo still lacks a valid pattern for monitoring detail pages.

Independent Test: Open the viewer from Operations and from another origin context, then verify that back navigation stays quieter than refresh or resumable actions and that related links do not crowd the main action lane.

Acceptance Scenarios:

1. Given the viewer has an origin context, When the page renders, Then the back affordance is visually distinct from utility and related work actions.
2. Given the viewed run has no resumable action, When the page renders, Then the header does not reserve equal prominence for a missing action and remains calm.

---

User Story 3 - Preserve calm monitoring pages without forced churn (Priority: P2)

As a product reviewer, I want already calm monitoring pages to be explicitly confirmed as compliant or bounded-scope no-ops so the cleanup does not turn into cosmetic standardization.

Why this priority: The spec should sharpen meaningful hierarchy, not create churn on pages that already convey one clear monitoring question.

Independent Test: Review the bounded-scope reference pages and confirm that they either remain unchanged or receive only documented minor alignment, with no artificial new header structure added.

Acceptance Scenarios:

1. Given a bounded-scope report page such as Evidence Overview or Review Register, When the feature is reviewed, Then it remains calm and is not forced into extra action layers it does not need.
2. Given a page is already sufficiently quiet, When the spec is applied, Then the page is classified as compliant or minor alignment only rather than remediated by default.

---

User Story 4 - Keep special diagnostic surfaces explicit (Priority: P3)

As a reviewer, I want special-type monitoring surfaces to be explicitly marked so necessary diagnostic repair actions can exist without weakening the broader monitoring hierarchy rule.

Why this priority: The spec must allow narrow exceptions without creating silent inconsistency.

Independent Test: Review Tenant Diagnostics and verify that it remains a documented exception whose repair actions appear only when the diagnostic condition exists.

Acceptance Scenarios:

1. Given Tenant Diagnostics shows no repair-needed condition, When the page renders, Then no repair action is promoted.
2. Given a repair-needed state exists, When the page renders, Then the required repair action is available with confirmation and explicit exception documentation.

Edge Cases

• If a monitoring page is in workspace scope with no remembered tenant context, the scope layer must still read clearly and must not imply tenant-specific actionability.
• If a workspace monitoring page is filtered to one tenant, the operator must still be able to understand whether the surface is tenant-prefiltered or truly tenant-bound.
• If no selection exists on a queue or workbench surface, selection-bound actions must not keep placeholder prominence.
• If a selected object becomes unavailable after filters change, the surface must fall back to a calm no-selection state instead of keeping stale focused-object actions visible.
• If a run viewer opens a tenant-owned run while a different tenant is active in context, the page must show the context mismatch clearly without treating the scope banner as a call to action.
• If a shared pattern like OperateHubShell supplies scope and return affordances, those affordances must still be subordinate to the actual work state on the page.
• If a special-type diagnostic surface has no active inconsistency, it must not manufacture work actions just to match other workbench pages.

Requirements (mandatory)

Constitution alignment (required): This feature introduces no new Microsoft Graph contract, no new persistence, and no new queued work. It reorganizes action hierarchy and surface semantics only. Existing mutations such as exception approval, exception rejection, diagnostics repair, compare actions, and run-related resumes keep their current confirmation, audit, and run-observability behavior.

Constitution alignment (PROP-001 / ABSTR-001 / PERSIST-001 / STATE-001 / BLOAT-001): The feature introduces only a bounded surface-class contract and classification matrix for monitoring and workbench pages. It adds no new persistence, no new state family, and no new action framework. The proportionality review above explains why a local-only cleanup is too weak and why a broader framework is intentionally rejected.

Constitution alignment (OPS-UX): Existing operations visible from these surfaces continue to use their current run lifecycle, queued toast, progress surfaces, and terminal notification rules. This spec does not create or rename any operation type, does not alter service-owned OperationRun transitions, and does not change summary count semantics.

Constitution alignment (RBAC-UX): The feature spans workspace monitoring pages and tenant-bound monitoring pages but does not change authorization logic. Non-members remain 404, members lacking capability remain 403, selection-bound or repair actions still enforce server-side authorization, and destructive-like actions continue to require confirmation. At least one positive and one negative authorization regression must verify that moving actions between layers does not loosen access.

Constitution alignment (OPS-EX-AUTH-001): Not applicable. No authentication handshake behavior changes.

Constitution alignment (BADGE-001): This feature does not add or change badge semantics. Existing badge mappings remain centralized and unchanged.

Constitution alignment (UI-FIL-001): The feature must use native Filament actions, action groups, page sections, and existing shared primitives such as OperateHubShell. It must avoid creating page-local button frameworks, ad-hoc status language, or custom visual taxonomies for scope or selection state. The only approved exception is keeping Tenant Diagnostics as a focused diagnostic repair surface with its existing capability-gated actions.

Constitution alignment (UI-NAMING-001): Operator-facing action labels must stay domain-first and consistent while their placement changes. Examples include Approve exception, Reject exception, Refresh, Open, Close details, Show all tenants, Bootstrap owner, and Merge duplicate memberships. Scope labels must read as context rather than as equivalent action verbs.

Constitution alignment (UI-CONST-001 / UI-SURF-001 / UI-HARD-001 / UI-EX-001 / UI-REVIEW-001): This spec classifies each affected surface, defines its single inspect or open model, states whether row click is required, allowed, or forbidden, and assigns secondary, related, and destructive actions to explicit layers. Monitoring and workbench pages must not silently inherit record-page action assumptions.

Constitution alignment (OPSURF-001): Default-visible content remains operator-first. Scope, navigation, selection state, and next action must be legible without revealing raw implementation detail. Diagnostics stay secondary or downstream, dangerous actions keep confirmation and mutation-scope language, and workspace or tenant context remains explicit in navigation and page semantics.

Constitution alignment (UI-SEM-001 / LAYER-001 / TEST-TRUTH-001): The feature does not introduce a new presenter or semantic interpretation layer. It uses direct action placement, state-driven visibility, and explicit page classification instead of a new UI meta-framework. Tests must validate user-visible action hierarchy and authorization continuity rather than thin indirection.

Constitution alignment (Filament Action Surfaces): The Action Surface Contract is satisfied for remediated monitoring and workbench pages when each affected surface has one inspect or open model, no redundant peer navigation buttons, no empty action groups, and destructive-like actions only in the appropriate selected-object or exception layer. Any page that intentionally differs must be catalogued as a documented exception.

Constitution alignment (UX-001 — Layout & Information Architecture): This feature changes action hierarchy and contextual placement only. It does not justify any regression in existing table filters, empty states, infolists, or form layouts. Monitoring tables must keep their current search, sort, filter, and empty-state contracts while the header hierarchy becomes calmer.

Functional Requirements

• FR-193-001 Surface inventory: The repo MUST maintain an explicit inventory of every in-scope monitoring, queue, operations, and workbench surface covered by this spec.
• FR-193-002 Explicit classification: Every in-scope surface MUST be assigned exactly one classification: remediation required, minor alignment only, compliant / no-op, or special-type acceptable.
• FR-193-003 Monitoring surface action layers: Remediated monitoring and workbench surfaces MUST separate actions into clearly distinguishable layers drawn from scope or context, navigation, surface utility, selection or focused-object actions, and related or drilldown actions.
• FR-193-004 Scope-is-context rule: Scope labels, remembered-tenant context, origin context, and active workbench context MUST not appear as peer call-to-action buttons when they are semantically contextual only.
• FR-193-005 Navigation separation rule: Back, return, show-all, and related-open navigation MUST not share the same primary action lane as live work actions when doing so makes the next step ambiguous.
• FR-193-006 Selection prominence rule: Selection-bound or focused-object actions MUST become prominent only when a valid selection or focused object exists.
• FR-193-007 No-selection quiet state: Queue and workbench surfaces MUST render a calm monitoring state when no selection or focused object is active.
• FR-193-008 Work-state transition rule: Remediated workbench surfaces MUST visibly change hierarchy between no-selection, selected-object, global monitoring, and related drilldown states instead of keeping one static header layout.
• FR-193-009 Finding Exceptions Queue hierarchy: Finding Exceptions Queue MUST stop presenting scope, clear filters, close details, drilldown links, and exception decisions as one flat peer row. Scope and utility actions remain globally visible, drilldown links move to a related layer, and Approve exception or Reject exception become prominent only when a pending exception is selected.
• FR-193-010 Queue decision visibility: Finding Exceptions Queue MUST not promote exception decision actions when the selected exception is absent, resolved, or otherwise not decision-ready.
• FR-193-011 Tenantless run viewer hierarchy: Tenantless Operation Run Viewer MUST separate scope context, back navigation, show-all navigation, refresh utility, related links, and resumable run actions into distinct layers so the page reads as a monitoring viewer rather than a record-page action strip.
• FR-193-012 Viewer navigation discipline: Tenantless Operation Run Viewer MUST keep origin or return navigation visually subordinate to refresh and any run-specific follow-up action, and related links MUST not appear as equal peers to scope or refresh.
• FR-193-013 Operations landing hierarchy: Operations MUST stop using the header as a mixed context-navigation strip. Scope context and show-all behavior remain visible but quieter than list filters, tab state, and row inspect flow.
• FR-193-014 Shared-pattern tightening: Shared OperateHubShell patterns may remain in use, but any page using them MUST still subordinate scope and return affordances to the actual work or monitoring state of that page.
• FR-193-015 Minor alignment audit: Alerts, Audit Log, and List Alert Deliveries MUST be reviewed against the same hierarchy but changed only where real action-layer ambiguity exists.
• FR-193-016 Compliant bounded-scope preservation: Evidence Overview, Baseline Compare Matrix, Baseline Compare Landing, and Review Register MUST remain unchanged or receive only minimal documented alignment when their current bounded-scope semantics are already clear.
• FR-193-017 Special-type exception contract: Tenant Diagnostics MUST be explicitly marked as a special-type acceptable surface whose repair actions are allowed because the page is itself a focused diagnostic exception surface, not a general monitoring list.
• FR-193-018 No record-header leakage: Monitoring and workbench surfaces MUST NOT silently inherit classic record-page rules from Spec 192 where those rules would hide workbench state or selection semantics.
• FR-193-019 No governance-friction expansion: This feature MUST NOT change confirmation depth, reason-capture behavior, danger-language policy, dispatch semantics, or provider-start semantics beyond what underlying actions already own.
• FR-193-020 Authorization continuity: Moving, regrouping, or relabeling actions MUST NOT change route scope, capability enforcement, deny-as-not-found behavior, or audit obligations.
• FR-193-021 Vocabulary continuity: Scope, navigation, utility, and work actions MUST keep consistent domain vocabulary across buttons, modal titles, notifications, and audit prose while the hierarchy changes.
• FR-193-022 Regression guard: The repo MUST add a lightweight project-wide guard that prevents future monitoring or workbench surfaces from reintroducing scope-as-CTA patterns, flat global-plus-selection header mixes, or undocumented surface-class exceptions.
• FR-193-023 Browser verification: Browser or UI smoke checks MUST cover every remediated surface, the documented special-type exception, and a no-regression subset of the compliant bounded-scope pages.

Surface Decision Matrix

• Remediation required:
  • Finding Exceptions Queue
  • Tenantless Operation Run Viewer
  • Operations
• Minor alignment only:
  • Alerts
  • Audit Log
  • List Alert Deliveries
• Compliant / no-op:
  • Evidence Overview
  • Baseline Compare Matrix
  • Baseline Compare Landing
  • Review Register
• Special-type acceptable:
  • Tenant Diagnostics

Target Outcomes by Key Surface

• Finding Exceptions Queue: The page no longer reads as one flat strip of scope, close, open, and decision actions. Without a selected exception it behaves like a quiet monitoring queue. With a selected pending exception it becomes a focused review workbench.
• Tenantless Operation Run Viewer: Scope and return context no longer compete with refresh, open-related, or resumable actions. The header reflects a monitoring viewer instead of a record-detail hybrid.
• Operations: Scope and origin context no longer dominate the header. The page reads as a monitoring landing surface where tab state, filters, and inspect flow carry the work.
• Alerts, Audit Log, and List Alert Deliveries: Shared monitoring patterns are checked and tightened only where hierarchy is still ambiguous.
• Evidence Overview, Baseline Compare Matrix, Baseline Compare Landing, and Review Register: Calm bounded-scope monitoring pages are explicitly preserved as references, not cosmetically rebuilt.
• Tenant Diagnostics: Diagnostic repair actions remain available only as a documented exception surface rather than as evidence that every monitoring page may promote repairs in the same way.

Non-Goals

• Applying record-page header rules to monitoring and workbench surfaces
• Introducing a new global danger, confirmation, or reason-capture policy
• Redesigning dispatch, preflight, provider-start, or queue semantics
• Reworking list, row, or bulk action contracts outside this surface class
• Forcing a full monitoring redesign across every page in the admin panel
• Rebuilding calm bounded-scope pages for cosmetic consistency alone

Assumptions

• Spec 192 remains the rule set for classic record detail and edit pages, and this spec is the companion rule set for monitoring and workbench surfaces.
• Existing authorization, audit logging, and run-observability behavior on the underlying actions is already correct and will be preserved.
• OperateHubShell remains a valid shared pattern, but not a blanket exemption from action-hierarchy review.
• The named compliant pages are bounded enough that a stronger multi-layer header would add noise rather than clarity.

Dependencies

• The constitution rule for action-surface discipline and the separation already established by Spec 192
• Existing OperateHubShell scope and return affordances
• Existing Filament action surfaces, tables, empty states, and tenant/workspace scope helpers
• Existing browser-smoke and action-surface regression infrastructure

Risks

• The feature could drift into a generic multi-surface framework if the scope is not kept strictly to monitoring and workbench pages.
• Shared-pattern loyalty could cause real hierarchy issues to be excused as intentional infrastructure.
• Selection-aware pages could hide useful actions too aggressively if the no-selection state is not balanced against active-work state.
• Calm bounded-scope pages could be pulled into unnecessary churn if the no-op classification is not taken seriously.

Review Questions

• Can a reviewer tell within a few seconds which surface state is active: scope only, selected object, or related drilldown?
• Do scope labels now read as context instead of as peer calls to action?
• Are navigation actions clearly calmer than actual work actions on remediated pages?
• Are already calm monitoring pages preserved instead of standardized for their own sake?
• Is Tenant Diagnostics clearly documented as an exception rather than a silent contradiction?

UI Action Matrix (mandatory when Filament is changed)

Surface	Location	Header Actions	Inspect Affordance (List/Table)	Row Actions (max 2 visible)	Bulk Actions (grouped)	Empty-State CTA(s)	View Header Actions	Create/Edit Save+Cancel	Audit log?	Notes / Exemptions
Finding Exceptions Queue	apps/platform/app/Filament/Pages/Monitoring/FindingExceptionsQueue.php	Shared scope and return affordances remain quiet; Clear filters stays utility; Close details, Open tenant detail, and Open finding move out of the same peer lane as Approve exception and Reject exception	Existing explicit inspect or select flow remains the only open model	Existing inspect flow remains; no extra visible row actions are added	none	Existing queue empty-state CTA remains	Header becomes context + utility + related links + selected-object actions instead of one flat row	n/a	Existing exception approval and rejection audit behavior unchanged	Remediation-required workbench page
Tenantless Operation Run Viewer	apps/platform/app/Filament/Pages/Operations/TenantlessOperationRunViewer.php	Scope label, back or origin, show-all, refresh, Open group, and resumable action are reordered into distinct layers rather than equal peers	Page itself is the canonical detail destination	n/a	none	n/a	Viewer header is split into context, navigation, utility, related, and follow-up layers; no redundant peer links	n/a	Existing resume and follow-up audit behavior unchanged	Remediation-required monitoring detail page
Operations	apps/platform/app/Filament/Pages/Monitoring/Operations.php	Scope label, return, and Show all tenants remain quiet and do not act as a mixed primary action strip	recordUrl() and clickable row remain the only inspect model	Existing row click remains primary open affordance	none	Existing table empty state unchanged	Header is reduced to context and scope reset only; tabs and filters remain the work controls	n/a	Read-only landing; no new audit behavior	Remediation-required monitoring landing
Alerts	apps/platform/app/Filament/Pages/Monitoring/Alerts.php	Shared scope and origin affordances remain quiet; only minor tightening if origin link still competes visually with overview behavior	Page-level overview only	n/a	none	Existing overview empty state unchanged	No structural rebuild unless audit finds real ambiguity	n/a	Existing downstream alert-management audit behavior unchanged	Minor alignment only
Audit Log	apps/platform/app/Filament/Pages/Monitoring/AuditLog.php	Shared scope and return remain quiet; selected-event inspection continues downstream rather than being elevated into mixed work actions	Explicit Inspect event remains the inspect model	Inspect event remains the visible row action	none	Clear filters remains the only empty-state CTA	Header remains calm; no new action lane unless minor ambiguity is found	n/a	Read-only audit history; no new audit behavior	Minor alignment only
List Alert Deliveries	apps/platform/app/Filament/Resources/AlertDeliveryResource/Pages/ListAlertDeliveries.php	Shared scope and return affordances remain as quiet context; no added peer actions	Existing resource inspect flow remains unchanged	Existing resource row actions unchanged	Existing resource bulk actions unchanged	Existing resource empty state unchanged	No structural rebuild unless shared pattern still reads as mixed CTA	n/a	Existing delivery-history behavior unchanged	Minor alignment only
Evidence Overview	apps/platform/app/Filament/Pages/Monitoring/EvidenceOverview.php	Single Clear filters utility remains sufficient and unchanged	Clickable row remains the inspect model	Single row drilldown remains	none	Existing clear-filters empty or header CTA remains	No added layering required	n/a	Read-only report	Compliant / no-op reference
Baseline Compare Matrix	apps/platform/app/Filament/Pages/BaselineCompareMatrix.php	Existing focused compare affordances remain local to the matrix context	Matrix page itself remains the inspect surface	n/a	none	Existing matrix empty state unchanged	No header rebuild required	n/a	Read-only focused analysis	Compliant / no-op reference
Baseline Compare Landing	apps/platform/app/Filament/Pages/BaselineCompareLanding.php	Existing compare-state actions remain tied to current compare truth and are not expanded into a layered header unless review finds ambiguity	Page-level landing remains canonical	n/a	none	Existing landing empty or state CTAs remain	No structural rebuild required	n/a	Existing compare-run behavior unchanged	Compliant / no-op reference
Review Register	apps/platform/app/Filament/Pages/Reviews/ReviewRegister.php	Single Clear filters utility remains sufficient; no extra header layering required	Clickable row remains the inspect model	Existing Export executive pack row action remains scoped and subordinate	none	Existing clear-filters empty-state CTA remains	No header rebuild required	n/a	Existing review export audit behavior unchanged	Compliant / no-op reference
Tenant Diagnostics	apps/platform/app/Filament/Pages/TenantDiagnostics.php	Capability-gated repair actions remain on the page only when a defect exists; no extra context buttons are added to mimic other pages	Page itself remains the focused diagnostic surface	n/a	none	n/a	Repair actions remain explicit exception-surface actions with confirmation	n/a	Existing repair audit behavior unchanged	Special-type acceptable exception

Key Entities (include if feature involves data)

• Monitoring Surface Classification: The explicit catalog assigning each in-scope monitoring or workbench page to remediation required, minor alignment only, compliant or no-op, or special-type acceptable.
• Action Layer Contract: The bounded rule that separates scope or context, navigation, surface utility, selection or focused-object work, and related or drilldown behavior on monitoring surfaces.
• Selection State: The operator-visible distinction between no-selection monitoring mode and active-selection workbench mode.
• Scope Signal: The context element that shows workspace or tenant scope, origin, or remembered context without behaving like a peer call to action.
• Special-Type Diagnostic Exception: The documented allowance for a focused diagnostic page to expose repair actions when inconsistency exists without weakening the general monitoring hierarchy rule.

Success Criteria (mandatory)

Measurable Outcomes

• SC-193-001: 100% of in-scope monitoring and workbench surfaces are explicitly classified in the spec and implementation notes.
• SC-193-002: 100% of remediation-required surfaces show visibly separate context or scope, navigation, utility, and selected-object or related-action layers in acceptance review.
• SC-193-003: On remediated queue or workbench surfaces, selected-object actions are absent or clearly subordinate when no valid selection exists and become prominent only when a valid selection exists.
• SC-193-004: During acceptance walkthroughs, reviewers can correctly identify current scope, whether anything is selected, and the next actionable step on each remediated surface within 5 seconds.
• SC-193-005: No compliant or no-op reference page receives a structural rebuild unless a documented minor-alignment finding exists.
• SC-193-006: Regression coverage fails any newly introduced monitoring surface that treats scope as a peer CTA, mixes selection-bound actions with global surface controls in one flat lane, or introduces an undocumented exception.

Definition of Done

This feature is complete when:

• every in-scope monitoring and workbench surface is classified,
• every remediated surface shows explicit action layers instead of a flat mixed header,
• scope and context no longer read as peer CTAs on remediated pages,
• selection-bound work actions only become prominent in an active work state,
• navigation and work actions are clearly separated,
• shared monitoring patterns are either confirmed or intentionally tightened,
• calm bounded-scope pages are explicitly preserved,
• a lightweight regression guard exists for this surface class,
• and browser smoke checks confirm the visible hierarchy on remediated and exception surfaces.

Recommended Sequencing

• Spec 194 should follow with governance friction hardening so structure and friction rules remain separate concerns.