From 03f9740c4e4a1bcb1bf2d07381d50d4eb2213efa Mon Sep 17 00:00:00 2001
From: Ahmed Darrazi <ahmed.darrazi@live.de>
Date: Sat, 11 Apr 2026 18:10:07 +0200
Subject: [PATCH] docs: amend constitution for action surface discipline

---
 .specify/memory/constitution.md      | 246 +++++++++++++++++++++++++--
 .specify/templates/plan-template.md  |   9 +-
 .specify/templates/spec-template.md  |  27 ++-
 .specify/templates/tasks-template.md |  24 ++-
 docs/product/standards/README.md     |   4 +-
 5 files changed, 282 insertions(+), 28 deletions(-)

diff --git a/.specify/memory/constitution.md b/.specify/memory/constitution.md
index bb19be46..1bccf24a 100644
--- a/.specify/memory/constitution.md
+++ b/.specify/memory/constitution.md
@@ -1,20 +1,29 @@
 <!--
 Sync Impact Report
 
-- Version change: 2.0.0 -> 2.1.0
+- Version change: 2.1.0 -> 2.2.0
 - Modified principles:
-  - UX-001 (Layout & IA): header action line strengthened from SHOULD to MUST
-    with cross-reference to new HDR-001
+  - UI-SURF-001: broadened to require one explicit broad action-surface
+    class before detailed surface typing
+  - UX-001 (Layout & IA): header-action guidance aligned to
+    ACTSURF-001 / HDR-001 instead of a generic max-two-actions rule
+  - HDR-001: expanded and refocused as the record/detail/edit-specific
+    specialization of the wider action-surface discipline addendum
+  - UI-REVIEW-001: spec and PR review gates expanded to require action
+    hierarchy, next-step clarity, and justified exceptions
 - Added sections:
-  - Header Action Discipline & Contextual Navigation (HDR-001)
+  - Action Surface Discipline (ACTSURF-001)
 - Removed sections: None
 - Templates requiring updates:
   - ✅ .specify/memory/constitution.md
-  - ✅ .specify/templates/plan-template.md (Constitution Check: HDR-001 added)
-  - ✅ .specify/templates/tasks-template.md (Filament UI section: HDR-001 added)
-  - ⚠ .specify/templates/spec-template.md (no changes needed; existing
-    UI/UX Surface Classification and Operator Surface Contract tables already
-    cover header action placement implicitly)
+  - ✅ .specify/templates/plan-template.md (Constitution Check updated for
+    ACTSURF-001 / HDR-001)
+  - ✅ .specify/templates/spec-template.md (surface classification +
+    requirements updated for action-surface discipline)
+  - ✅ .specify/templates/tasks-template.md (implementation task guidance
+    updated for action hierarchy, grouping, and exception handling)
+  - ✅ docs/product/standards/README.md (Constitution index updated for the
+    new action-surface principle)
 - Commands checked:
   - N/A `.specify/templates/commands/*.md` directory is not present in this repo
 - Follow-up TODOs:
@@ -324,7 +333,19 @@ ### Operator-Facing UI/UX Constitution v1 (UI-CONST-001)
 
 #### Surface Taxonomy (UI-SURF-001)
 
-Every new admin surface MUST be assigned exactly one surface type before implementation. Ad-hoc interaction models are forbidden.
+Every new admin surface MUST be assigned exactly one broad action-surface
+class before implementation. Ad-hoc interaction models are forbidden.
+
+The allowed broad action-surface classes are:
+- Record / Detail / Edit
+- Monitoring / Queue / Workbench
+- List / Table / Bulk
+- Wizard / Flow
+- Utility / System
+
+Operator-facing surfaces MUST also declare exactly one detailed surface
+type from the taxonomy below. The broad class determines the action
+hierarchy first; the detailed surface type refines it.
 
 ##### CRUD / List-first Resource
 - Purpose: scan, find, open, and selectively mutate many business records.
@@ -377,6 +398,157 @@ ##### Detail-first Operational Surface
 - Destructive actions: detail header or grouped header actions only, always with confirmation.
 - Row click and explicit View/Inspect: not applicable.
 
+#### Action Surface Discipline (ACTSURF-001)
+
+Goal: actions across all surfaces MUST make the next sensible operator
+step obvious, keep safe navigation distinct from mutation, and prevent
+dangerous or governance-relevant actions from sitting casually beside
+harmless context changes.
+
+##### Surface class first
+
+- Every new or materially changed surface MUST declare exactly one broad
+  action-surface class before actions are designed.
+- Different surface classes MAY use different action models only when
+  the difference is deliberate, documented, and justified by the
+  workflow.
+- Detailed surface types refine the rule set; they do not replace the
+  broad class requirement.
+
+##### Record / Detail / Edit surfaces
+
+- Classic record/detail/edit pages MUST expose at most one visible
+  primary header action.
+- Pure navigation MUST NOT live in the header when it can be placed
+  inline at summary, field, badge, status, or related-context level.
+- Secondary, rare, or administrative actions MUST be grouped.
+- Multiple equally weighted mutation buttons in the header are
+  forbidden.
+- Destructive, irreversible, or governance-relevant actions MUST be
+  clearly separated from routine actions.
+- The likely next operator step MUST be recognizable within seconds.
+- HDR-001 is the binding specialization for record/detail/edit headers.
+
+##### Monitoring / Queue / Workbench surfaces
+
+- Surface-level context, scope context, navigation, selection actions,
+  and object actions MUST NOT be mixed as one flat header strip.
+- Scope indicators are context signals, not ordinary calls to action.
+- Selection-dependent actions SHOULD become prominent only when a
+  selection or focused object actually exists.
+- Record-page header rules MUST NOT be copied blindly onto workbench
+  surfaces.
+- Workbench surfaces MAY use a different action model, but that model
+  MUST be explicit, repeatable, and internally consistent.
+
+##### List / Table / Bulk surfaces
+
+- Inspect/open affordances MUST remain consistent within the same
+  surface class.
+- Bulk actions are allowed only for genuine multi-record work.
+- Row actions MUST NOT dominate reading and scanning.
+- Rare, destructive, or governance-relevant actions MUST NOT accumulate
+  casually in default row actions.
+- Tables exist primarily to scan, filter, compare, and decide; they
+  MUST NOT become unstructured action stockpiles.
+
+##### Wizard / Flow surfaces
+
+- Wizard actions MUST reflect staged progression, explicit back/cancel
+  semantics, and safe confirmation at the step where risk becomes real.
+- Wizard pages MAY expose more than one visible action when the flow
+  genuinely requires progression, backtracking, or guarded cancellation.
+- Even in a wizard, the next primary step MUST remain obvious.
+
+##### Utility / System surfaces
+
+- Utility and system pages MAY use narrower tooling-oriented action
+  sets, but they MUST still separate safe navigation, routine control,
+  and dangerous intervention.
+- System or recovery status does not justify casual placement of
+  destructive or governance-changing actions.
+
+##### Action grouping and order
+
+- Actions MUST be ordered by meaning, frequency, and risk.
+- The preferred order is:
+  1. primary next step
+  2. common secondary action
+  3. rare or contextual action
+  4. dangerous or irreversible action
+- An `ActionGroup` / More menu is not a junk drawer. Navigation,
+  mutation, external links, and destructive actions inside a group MUST
+  still be named, ordered, and separated coherently.
+
+##### Navigation vs mutation
+
+- Navigation and mutation are different intent classes and MUST NOT
+  appear as equal-weight peers without explicit hierarchy.
+- Harmless context switches MUST NOT visually overpower
+  governance-relevant actions.
+- Pure context navigation SHOULD live near the content it concerns
+  rather than as header filler.
+
+##### Governance friction
+
+- Actions with risk, blast radius, or irreversible effect MUST use
+  shared governance-friction rules rather than per-surface improvisation.
+- Depending on impact, the required friction is confirmation, optional
+  reason, mandatory reason, typed confirmation, or staged flow.
+- Clear danger semantics and separated placement are mandatory for
+  dangerous or governance-changing actions.
+
+##### Exceptions require explicit reason
+
+- New surfaces MAY deviate only when the surface class or workflow truly
+  requires it.
+- Allowed justification labels are:
+  - Special type
+  - Workflow hub
+  - Wizard
+  - Utility / System surface
+  - Another clearly defined exception documented in the governing spec
+- "Historically grew this way" and "it was easy to add to the header"
+  are invalid reasons.
+
+##### Reuse before invention
+
+- New features MUST reuse existing disciplined patterns, reference
+  architectures, and shared primitives when they fit the chosen surface
+  class.
+- Reference patterns are reuse baselines, not automatic mandates for
+  every surface.
+
+##### Constitution over convenience
+
+- Local implementation speed MUST NOT override consistent action
+  hierarchy.
+- No new feature may introduce:
+  - multiple equal-rank header mutations without a clear primary
+  - navigation as casual header filler
+  - unreflective mixing of record, workbench, and governance patterns
+  - new local exceptions without explicit rationale
+
+##### Review gate
+
+Every new or materially changed surface with actions MUST answer:
+1. What broad action-surface class is it?
+2. What is the one most likely next operator action?
+3. Is navigation cleanly separated from mutation?
+4. Are rare or risky actions removed from the primary plane?
+5. Is the hierarchy scanable in a few seconds?
+6. Is this a real special type or just an unordered exception?
+
+If those answers are not clear, the surface is non-conformant.
+
+##### Canonical outcome
+
+- The goal is not the smallest possible number of buttons.
+- A conformant surface highlights the next sensible step, separates
+  context, navigation, mutation, and danger cleanly, remains structured
+  as capability grows, and applies the same principles consistently
+  across the product.
+
 #### Hard Rules (UI-HARD-001)
 
 ##### Primary inspect model
@@ -509,6 +681,8 @@ #### Filament UI — Action Surface Contract (NON-NEGOTIABLE)
 
 Behavior over declaration
 - Every spec MUST include both a UI/UX Surface Classification and a UI Action Matrix.
+- Every changed operator-facing surface MUST declare its broad
+  action-surface class and the one most likely next operator action.
 - Custom action-surface contracts are legitimate only when they validate rendered behavior, not only declarations or slot counts.
 - A change is not Done unless the implemented interaction semantics conform to the declared surface type or an approved exception documents and tests the deviation.
 
@@ -532,7 +706,10 @@ #### Filament UI — Layout & Information Architecture Standards (UX-001)
 - When records exist, that primary CTA moves to the header and MUST NOT be duplicated in the empty state shell.
 
 Actions and flows
-- Pages MUST expose at most one primary header action and one secondary header action; all others belong in groups (see HDR-001 for the full header discipline rule).
+- Record / Detail / Edit pages MUST expose at most one visible primary
+  header action. Any additional visible secondary header action requires
+  explicit justification under ACTSURF-001 / HDR-001; the rest belong in
+  groups or contextual placement.
 - Multi-step or high-risk flows MUST use a wizard or an equivalent staged flow with preview and confirmation.
 - Destructive actions remain non-primary and confirmed.
 
@@ -545,9 +722,12 @@ #### Filament UI — Layout & Information Architecture Standards (UX-001)
 - Shared layout builders such as `MainAsideForm`, `MainAsideInfolist`, and `StandardTableDefaults` SHOULD be reused where available.
 - A change is not Done unless UX-001 is satisfied or an approved exception documents why not.
 
-#### Header Action Discipline & Contextual Navigation (HDR-001)
+#### Record / Detail / Edit Header Discipline & Contextual Navigation (HDR-001)
+
+Goal: record, detail, and edit pages MUST be comprehensible within
+seconds. HDR-001 is the binding record/detail/edit specialization of
+ACTSURF-001.
 
-Goal: record and detail pages MUST be comprehensible within seconds.
 Header actions are reserved for the primary workflow of the current page
 and MUST NOT become a dumping ground for every available action or
 navigation jump.
@@ -565,6 +745,8 @@ ##### Maximum one primary visible header action
   primary visible header action.
 - That action MUST represent the most obvious next operator step on
   exactly this page.
+- Multiple equally weighted mutation buttons in the header are
+  forbidden.
 
 ##### Navigation does not belong in headers
 
@@ -594,6 +776,8 @@ ##### Rare secondary actions belong in an Action Group
   or are only occasionally needed MUST NOT appear as equally weighted
   visible header buttons.
 - They MUST be placed in an Action Group.
+- The Action Group itself MUST remain structured; it MUST NOT become an
+  unlabelled mix of navigation, external links, mutations, and danger.
 
 ##### Header clarity over implementation convenience
 
@@ -744,11 +928,26 @@ #### Spec Scope Fields (SCOPE-002)
 #### Enforcement Model (UI-REVIEW-001)
 
 Spec review requirements
-- Every spec that changes an operator-facing surface MUST answer: surface type, primary inspect/open model, row-click rule, whether explicit View/Inspect exists or is forbidden, where secondary actions live, where destructive actions live, canonical collection route, canonical detail route, scope signals and their exact meaning, canonical noun, critical truth visible by default, and whether an exception type is used.
+- Every spec that changes an operator-facing surface MUST answer: broad
+  action-surface class, detailed surface type, one likely next operator
+  action, primary inspect/open model, row-click rule, whether explicit
+  View/Inspect exists or is forbidden, where navigation lives, where
+  secondary actions live, where destructive actions live, how grouped
+  actions are ordered, canonical collection route, canonical detail
+  route, scope signals and their exact meaning, canonical noun,
+  critical truth visible by default, and whether an exception type is
+  used.
 - Missing any of those answers makes the spec incomplete.
 
 PR review requirements
-- A PR MUST NOT pass when it introduces more than one primary inspect model, redundant View beside row click, destructive inline actions beside inspect on standard lists, empty overflow or bulk groups, long workflow labels in dense rows, misleading scope chips, drifting domain nouns, hidden critical operational truth, or undocumented exceptions without dedicated tests.
+- A PR MUST NOT pass when it introduces more than one primary inspect
+  model, redundant View beside row click, destructive inline actions
+  beside inspect on standard lists, empty overflow or bulk groups, long
+  workflow labels in dense rows, misleading scope chips, drifting domain
+  nouns, hidden critical operational truth, flat record headers with
+  multiple equal-weight mutations, workbench headers that mix scope,
+  selection, navigation, and object actions as peers, or undocumented
+  exceptions without dedicated tests.
 
 Guard tests
 - Repository guards SHOULD validate: declared surface type, conformant primary inspect model, absence of redundant View actions, presence of explicit Inspect on Queue / Review and History / Audit surfaces, absence of empty `ActionGroup` or `BulkActionGroup`, correct placement of destructive actions, truthful scope signals, stable canonical nouns across shells, and dedicated tests for every approved exception.
@@ -768,6 +967,8 @@ #### Immediate Retrofit Priorities
 
 #### Appendix A - One-page Condensed Constitution
 
+- Every new or materially changed surface declares one broad
+  action-surface class first.
 - Every admin surface has one surface type.
 - Every list has exactly one primary inspect/open model.
 - CRUD and Registry surfaces use one-click open.
@@ -777,6 +978,10 @@ #### Appendix A - One-page Condensed Constitution
 - Destructive actions never sit openly beside inspect on standard lists.
 - Overflow is standardized per surface class and is never empty.
 - Bulk exists only when it is genuinely useful.
+- Navigation and mutation do not share equal visual weight without
+  explicit hierarchy.
+- Monitoring and workbench surfaces separate scope/context, selection,
+  navigation, and object actions.
 - Scope chips must be truthful.
 - Domain nouns are canonical and stable.
 - Critical operational truth is default-visible.
@@ -788,11 +993,14 @@ #### Appendix A - One-page Condensed Constitution
 
 #### Appendix B - Feature Review Checklist
 
-- Surface type is declared.
+- Broad action-surface class is declared.
+- Detailed surface type is declared.
+- The one most likely next operator action is explicit.
 - Primary inspect/open model is defined.
 - Row-click rule is decided.
 - View/Inspect is correctly present or correctly forbidden.
 - Edit-as-inspect is used only when allowed.
+- Navigation and mutation are separated intentionally.
 - Secondary actions are grouped correctly.
 - Destructive actions are placed correctly.
 - Overflow is not empty.
@@ -806,6 +1014,7 @@ #### Appendix B - Feature Review Checklist
 - Header passes the 5-second scan rule (HDR-001).
 - No pure navigation in the header.
 - Governance-changing actions have extra friction.
+- Any special type or workflow-hub exception is real and justified.
 
 #### Appendix C - Red Flags for Future PRs
 
@@ -813,11 +1022,14 @@ #### Appendix C - Red Flags for Future PRs
 - A row becomes a control center.
 - Archive or Delete sits openly beside View or Inspect on a standard list.
 - More menus or bulk menus are empty.
+- A More menu becomes a mixed junk drawer with no ordering logic.
 - Scope chips have no real scope effect.
 - Runs and Operations are used as competing primary collection nouns.
 - Long workflow labels live in dense tables.
 - Edit is used as default inspect even though a true View surface exists.
 - Queue surfaces throw the operator out of context through row click.
+- A workbench surface mixes scope, selection, navigation, and object
+  actions as one flat header rail.
 - Critical health or operability truth is hidden by default.
 - A contract claims conformance while the rendered UI behaves differently.
 - Header has multiple equally weighted buttons without clear prioritization.
@@ -906,4 +1118,4 @@ ### Versioning Policy (SemVer)
 - **MINOR**: new principle/section or materially expanded guidance.
 - **MAJOR**: removing/redefining principles in a backward-incompatible way.
 
-**Version**: 2.1.0 | **Ratified**: 2026-01-03 | **Last Amended**: 2026-04-07
+**Version**: 2.2.0 | **Ratified**: 2026-01-03 | **Last Amended**: 2026-04-11
diff --git a/.specify/templates/plan-template.md b/.specify/templates/plan-template.md
index 7c6cd037..a5f845ba 100644
--- a/.specify/templates/plan-template.md
+++ b/.specify/templates/plan-template.md
@@ -71,7 +71,14 @@ ## Constitution Check
 - Operator surfaces (OPSURF-001): each new or materially refactored operator-facing page defines a page contract covering persona, surface type, operator question, default-visible info, diagnostics-only info, status dimensions, mutation scope, primary actions, and dangerous actions
 - Filament UI Action Surface Contract: for any new/modified Filament Resource/RelationManager/Page, define Header/Row/Bulk/Empty-State actions, ensure every List/Table has a surface-appropriate inspect affordance, remove redundant View when row click or identifier click already opens the same destination, keep standard CRUD/Registry rows to inspect plus at most one inline safe shortcut, group or relocate the rest to “More” or detail header, forbid empty bulk/overflow groups, require confirmations for destructive actions, write audit logs for mutations, enforce RBAC via central helpers (non-member 404, member missing capability 403), and ensure CI blocks merges if the contract is violated or not explicitly exempted
 - Filament UI UX-001 (Layout & IA): Create/Edit uses Main/Aside (3-col grid, Main=columnSpan(2), Aside=columnSpan(1)); all fields inside Sections/Cards (no naked inputs); View uses Infolists (not disabled edit forms); status badges use BADGE-001; empty states have specific title + explanation + 1 CTA; max 1 primary + 1 secondary header action (see HDR-001); tables provide search/sort/filters for core dimensions; shared layout builders preferred for consistency
-- Header action discipline (HDR-001): record/detail pages expose at most 1 primary visible header action; pure navigation (Open finding, Open tenant, View related run, etc.) is placed at the relevant field/badge/relation, NOT in the header; destructive or governance-changing actions are separated and require friction; rare actions live in Action Groups; every record/detail page passes the 5-second scan rule
+- Action-surface discipline (ACTSURF-001 / HDR-001): every changed
+  surface declares one broad action-surface class; the spec names the
+  one likely next operator action; navigation is separated from
+  mutation; record/detail/edit pages keep at most one visible primary
+  header action; monitoring/workbench surfaces separate scope/context,
+  selection actions, navigation, and object actions; risky or rare
+  actions are grouped and ordered by meaning/frequency/risk; any special
+  type or workflow-hub exception is explicit and justified
 ## Project Structure
 
 ### Documentation (this feature)
diff --git a/.specify/templates/spec-template.md b/.specify/templates/spec-template.md
index 8d18a681..515fa4a6 100644
--- a/.specify/templates/spec-template.md
+++ b/.specify/templates/spec-template.md
@@ -38,11 +38,12 @@ ## Spec Scope Fields *(mandatory)*
 ## UI/UX Surface Classification *(mandatory when operator-facing surfaces are changed)*
 
 If this feature adds or materially changes an operator-facing list, detail, queue, audit, config, or report surface,
-fill out one row per affected surface.
+fill out one row per affected surface. Declare the broad Action Surface
+Class first, then the detailed Surface Type.
 
-| 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 |
-|---|---|---|---|---|---|---|---|---|---|---|---|
-| e.g. Tenant policies page | CRUD / List-first Resource | Full-row click | required | One inline safe shortcut + More | More / detail header | /admin/t/{tenant}/policies | /admin/t/{tenant}/policies/{record} | Tenant chip scopes rows and actions | Policies / Policy | Policy health, drift, assignment coverage | none |
+| Surface | Action Surface Class | Surface Type | Likely Next Operator Action | 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 / Justification |
+|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
+| e.g. Tenant policies page | List / Table / Bulk | CRUD / List-first Resource | Open policy for review | Full-row click | required | One inline safe shortcut + More | More / detail header | /admin/t/{tenant}/policies | /admin/t/{tenant}/policies/{record} | Tenant chip scopes rows and actions | Policies / Policy | Policy health, drift, assignment coverage | none |
 
 ## Operator Surface Contract *(mandatory when operator-facing surfaces are changed)*
 
@@ -199,19 +200,33 @@ ## Requirements *(mandatory)*
 - how the same domain vocabulary is preserved across button labels, modal titles, run titles, notifications, and audit prose,
 - and how implementation-first terms are kept out of primary operator-facing labels.
 
-**Constitution alignment (UI-CONST-001 / UI-SURF-001 / UI-HARD-001 / UI-EX-001 / UI-REVIEW-001):** If this feature adds or changes an operator-facing surface, the spec MUST describe:
-- the chosen surface type and why it is the correct classification,
+**Constitution alignment (UI-CONST-001 / UI-SURF-001 / ACTSURF-001 / UI-HARD-001 / UI-EX-001 / UI-REVIEW-001 / HDR-001):** If this feature adds or changes an operator-facing surface, the spec MUST describe:
+- the chosen broad action-surface class and why it is the correct classification,
+- the chosen detailed surface type and why it is the correct refinement,
+- the one most likely next operator action,
 - the one and only primary inspect/open model,
 - whether row click is required, allowed, or forbidden,
 - whether explicit View or Inspect is present, and why it is present or forbidden,
+- where pure navigation lives and why it is not competing with mutation,
 - where secondary actions live,
 - where destructive actions live,
+- how grouped actions are ordered by meaning, frequency, and risk,
 - the canonical collection route and canonical detail route,
 - the scope signals shown to the operator and what real effect each one has,
 - the canonical noun used across routes, labels, runs, notifications, and audit prose,
 - which critical operational truth is visible by default,
 - and any catalogued exception type, rationale, and dedicated test coverage.
 
+**Constitution alignment (ACTSURF-001 - action hierarchy):** If this
+feature adds or materially changes header actions, row actions, bulk
+actions, or workbench controls, the spec MUST describe:
+- how navigation, mutation, context signals, selection actions, and
+  dangerous actions are separated,
+- why any visible secondary action deserves primary-plane placement,
+- why any ActionGroup is structured rather than a mixed catch-all,
+- and why any workflow-hub, wizard, system, or other special-type
+  exception is genuine rather than a convenience shortcut.
+
 **Constitution alignment (OPSURF-001):** If this feature adds or materially refactors an operator-facing surface, the spec MUST describe:
 - how the default-visible content stays operator-first on `/admin` and avoids raw implementation detail,
 - which diagnostics are secondary and how they are explicitly revealed,
diff --git a/.specify/templates/tasks-template.md b/.specify/templates/tasks-template.md
index ad586baa..f974afc8 100644
--- a/.specify/templates/tasks-template.md
+++ b/.specify/templates/tasks-template.md
@@ -51,18 +51,33 @@ # Tasks: [FEATURE NAME]
 - keeping workspace and tenant context explicit in navigation, actions, and page semantics so tenant pages do not silently expose workspace-wide actions.
 **Filament UI Action Surfaces**: If this feature adds/modifies any Filament Resource / RelationManager / Page, tasks MUST include:
 - filling the spec’s “UI Action Matrix” for all changed surfaces,
+- assigning exactly one broad action-surface class to every changed
+  operator-facing surface and keeping the detailed surface type in sync
+  with the spec,
+- identifying the one likely next operator action for each changed
+  surface and shaping the visible hierarchy around it,
 - implementing required action surfaces (header/row/bulk/empty-state CTA for lists; header actions for view; consistent save/cancel on create/edit),
 - ensuring every List/Table has exactly one primary inspect/open model with the correct surface-appropriate affordance,
 - removing redundant View/Inspect actions when row click or identifier click already opens the same destination,
 - keeping standard CRUD / Registry rows to inspect/open plus at most one inline safe shortcut,
+- separating navigation from mutation so pure context changes do not
+  compete visually with state-changing actions,
 - moving additional secondary actions into More or the detail header,
+- ordering visible actions and grouped actions by meaning, frequency,
+  and risk rather than append order,
 - placing destructive actions in More or the detail header for standard lists and using catalogued exceptions only where allowed,
+- ensuring workbench and monitoring surfaces separate scope/context,
+  selection actions, navigation, and object actions instead of mixing
+  them into one flat header zone,
 - grouping bulk actions via BulkActionGroup,
 - preventing empty `ActionGroup` / `BulkActionGroup` placeholders,
 - adding confirmations for destructive actions (and typed confirmation where required by scale),
 - adding `AuditLog` entries for relevant mutations,
 - using native Filament components or shared UI primitives before any local Blade/Tailwind assembly for badges, alerts, buttons, and semantic status surfaces,
 - avoiding page-local semantic color, border, rounding, or highlight styling when Filament props or shared primitives can express the same state,
+- documenting any workflow-hub, wizard, utility/system, or other
+  special-type exception in the spec/PR and adding dedicated test
+  coverage,
 - documenting any catalogued UI exception in the spec/PR and adding dedicated test coverage,
 - documenting any UI-FIL-001 exception with rationale in the spec/PR,
 - adding/updated tests that enforce the contract and block merge on violations, OR documenting an explicit exemption with rationale.
@@ -71,8 +86,13 @@ # Tasks: [FEATURE NAME]
 - ensuring all form fields are inside Sections/Cards (no naked inputs at root schema level),
 - ensuring View pages use Infolists (not disabled edit forms); status badges use BADGE-001,
 - ensuring empty states show a specific title + explanation + exactly 1 CTA; non-empty tables move CTA to header,
-- capping header actions to max 1 primary + 1 secondary (rest grouped),
-- enforcing HDR-001 header action discipline: at most 1 primary visible action per record/detail page; pure navigation (Open finding, Open tenant, View related run, etc.) placed at the relevant field/badge/relation, NOT in the header; destructive or governance-changing actions separated and requiring friction; rare actions in Action Groups; every record/detail page passing the 5-second scan rule,
+- enforcing ACTSURF-001 / HDR-001 action discipline: record/detail/edit
+  pages keep at most 1 visible primary header action; pure navigation
+  moves to contextual placement; destructive or governance-changing
+  actions are separated and require friction; monitoring/workbench
+  surfaces use their own layered hierarchy; rare actions live in
+  structured Action Groups; every affected surface passes the few-second
+  scan rule,
 - using shared layout builders (e.g., `MainAsideForm`, `MainAsideInfolist`, `StandardTableDefaults`) where available,
 - OR documenting an explicit exemption with rationale if UX-001 is not fully satisfied.
 **Badges**: If this feature changes status-like badge semantics, tasks MUST use `BadgeCatalog` / `BadgeRenderer` (BADGE-001),
diff --git a/docs/product/standards/README.md b/docs/product/standards/README.md
index f9154bc3..a2451a22 100644
--- a/docs/product/standards/README.md
+++ b/docs/product/standards/README.md
@@ -4,7 +4,7 @@ # Product Standards
 > Specs reference these standards; they do not redefine them.
 > Guard tests enforce critical constraints automatically.
 
-**Last reviewed**: 2026-03-28
+**Last reviewed**: 2026-04-11
 
 ---
 
@@ -42,7 +42,7 @@ ## Related Docs
 
 | Document | Location | Purpose |
 |---|---|---|
-| Constitution | `.specify/memory/constitution.md` | Permanent principles (PROP-001, BLOAT-001, UI-CONST-001, UI-SURF-001, UI-HARD-001, UI-EX-001, OPSURF-001, UI-FIL-001, UX-001, Action Surface Contract, RBAC-UX) |
+| Constitution | `.specify/memory/constitution.md` | Permanent principles (PROP-001, BLOAT-001, UI-CONST-001, UI-SURF-001, ACTSURF-001, UI-HARD-001, UI-EX-001, HDR-001, OPSURF-001, UI-FIL-001, UX-001, Action Surface Contract, RBAC-UX) |
 | Product Principles | `docs/product/principles.md` | High-level product decisions |
 | Table Rollout Audit | `docs/ui/filament-table-standard.md` | Rollout inventory and implementation state from Spec 125 |
 | Action Surface Contract | `docs/ui/action-surface-contract.md` | Original action surface reference (now governed by this standard) |