|
|
|
|
@ -1,32 +1,32 @@
|
|
|
|
|
<!--
|
|
|
|
|
Sync Impact Report
|
|
|
|
|
|
|
|
|
|
- Version change: 1.13.0 → 1.14.0
|
|
|
|
|
- Version change: 1.14.0 -> 2.0.0
|
|
|
|
|
- Modified principles:
|
|
|
|
|
- Governance / Scope & Compliance → Governance / Scope, Compliance, and Review Expectations
|
|
|
|
|
- Filament UI - Action Surface Contract -> Operator-Facing UI/UX Constitution v1 / Filament UI - Action Surface Contract
|
|
|
|
|
- Filament UI - Layout & Information Architecture Standards (UX-001) -> Operator-Facing UI/UX Constitution v1 / Filament UI - Layout & Information Architecture Standards (UX-001)
|
|
|
|
|
- Operator-facing UI Naming Standards (UI-NAMING-001) -> Operator-Facing UI/UX Constitution v1 / Operator-facing UI Naming Standards (UI-NAMING-001)
|
|
|
|
|
- Operator Surface Principles (OPSURF-001) -> Operator-Facing UI/UX Constitution v1 / Operator Surface Principles (OPSURF-001)
|
|
|
|
|
- Spec Scope Fields (SCOPE-002) -> Operator-Facing UI/UX Constitution v1 / Spec Scope Fields (SCOPE-002)
|
|
|
|
|
- Added sections:
|
|
|
|
|
- Proportionality First (PROP-001)
|
|
|
|
|
- No Premature Abstraction (ABSTR-001)
|
|
|
|
|
- No New Persisted Truth Without Source-of-Truth Need (PERSIST-001)
|
|
|
|
|
- No New State Without Behavioral Consequence (STATE-001)
|
|
|
|
|
- UI Semantics Must Not Become Their Own Framework (UI-SEM-001)
|
|
|
|
|
- V1 Prefers Explicit Narrow Implementations (V1-EXP-001)
|
|
|
|
|
- One Truth, Few Layers (LAYER-001)
|
|
|
|
|
- Spec Discipline Over Slice Proliferation (SPEC-DISC-001)
|
|
|
|
|
- Tests Must Protect Business Truth (TEST-TRUTH-001)
|
|
|
|
|
- Enterprise Complexity Is Allowed Only Where Risk Demands It (RISK-COMP-001)
|
|
|
|
|
- Mandatory Bloat Check for New Specs (BLOAT-001)
|
|
|
|
|
- Default Bias (BIAS-001)
|
|
|
|
|
- Operator-Facing UI/UX Constitution v1 (UI-CONST-001)
|
|
|
|
|
- Surface Taxonomy (UI-SURF-001)
|
|
|
|
|
- Hard Rules (UI-HARD-001)
|
|
|
|
|
- Exception Model (UI-EX-001)
|
|
|
|
|
- Enforcement Model (UI-REVIEW-001)
|
|
|
|
|
- Immediate Retrofit Priorities
|
|
|
|
|
- Appendix A - One-page Condensed Constitution
|
|
|
|
|
- Appendix B - Feature Review Checklist
|
|
|
|
|
- Appendix C - Red Flags for Future PRs
|
|
|
|
|
- Removed sections: None
|
|
|
|
|
- Templates requiring updates:
|
|
|
|
|
- ✅ .specify/memory/constitution.md
|
|
|
|
|
- ✅ .specify/templates/spec-template.md
|
|
|
|
|
- ✅ .specify/templates/plan-template.md
|
|
|
|
|
- ✅ .specify/templates/tasks-template.md
|
|
|
|
|
- ✅ docs/product/principles.md
|
|
|
|
|
- ✅ docs/product/standards/README.md
|
|
|
|
|
- ✅ docs/HANDOVER.md
|
|
|
|
|
- ✅ docs/product/principles.md
|
|
|
|
|
- ✅ Agents.md
|
|
|
|
|
- Commands checked:
|
|
|
|
|
- N/A `.specify/templates/commands/*.md` directory is not present in this repo
|
|
|
|
|
- Follow-up TODOs:
|
|
|
|
|
@ -317,98 +317,266 @@ ### Scheduled/system runs (OPS-UX-SYS-001)
|
|
|
|
|
- Scheduled/queued operations MUST use locks + idempotency (no duplicates).
|
|
|
|
|
- Graph throttling and transient failures MUST be handled with backoff + jitter (e.g., 429/503).
|
|
|
|
|
|
|
|
|
|
### Filament UI — Action Surface Contract (NON-NEGOTIABLE)
|
|
|
|
|
### Operator-Facing UI/UX Constitution v1 (UI-CONST-001)
|
|
|
|
|
|
|
|
|
|
For every new or modified Filament Resource / RelationManager / Page:
|
|
|
|
|
Purpose and scope
|
|
|
|
|
- This section governs operator-facing admin UI semantics across TenantPilot / TenantAtlas.
|
|
|
|
|
- It defines allowed surface types, allowed interaction models, primary/secondary/destructive action hierarchy, list/detail/queue semantics, scope and context signals, canonical navigation and naming rules, visibility of critical operational truth, scanability and density rules, exception handling, and review and enforcement requirements.
|
|
|
|
|
- It does not govern branding, colors, typography, spacing tokens, marketing or landing pages, implementation details without UX effect, purely cosmetic copy changes, or backend architecture except where backend design would create false UI mental models.
|
|
|
|
|
- This section is governance, not a style guide. Its purpose is to prevent ambiguity, operator risk, and UI drift before they spread through the product.
|
|
|
|
|
|
|
|
|
|
#### Surface Taxonomy (UI-SURF-001)
|
|
|
|
|
|
|
|
|
|
Every new admin surface MUST be assigned exactly one surface type before implementation. Ad-hoc interaction models are forbidden.
|
|
|
|
|
|
|
|
|
|
##### CRUD / List-first Resource
|
|
|
|
|
- Purpose: scan, find, open, and selectively mutate many business records.
|
|
|
|
|
- Primary behavior: Browse -> Open -> Decide / Mutate.
|
|
|
|
|
- Primary model: one-click inspect/open. Full-row click is the default; identifier click is allowed only when full-row click conflicts with another dominant row mechanism.
|
|
|
|
|
- Secondary actions: at most one inline non-destructive shortcut; everything else belongs in overflow.
|
|
|
|
|
- Destructive actions: never inline beside inspect; only in overflow or the detail header; confirmation is mandatory.
|
|
|
|
|
- Explicit View/Inspect: forbidden when row click or identifier click already opens the same destination.
|
|
|
|
|
|
|
|
|
|
##### Queue / Review Surface
|
|
|
|
|
- Purpose: triage items, inspect them in context, decide, and continue working through the queue.
|
|
|
|
|
- Primary behavior: Inspect in context -> Decide -> Continue.
|
|
|
|
|
- Primary model: explicit Inspect using a slide-over, inline detail pane, or same-page inspect.
|
|
|
|
|
- Secondary actions: only queue-relevant actions belong in the row.
|
|
|
|
|
- Destructive actions: inline is allowed only when the destructive decision is part of the real queue work; irreversibility or high risk still requires confirmation.
|
|
|
|
|
- Row click: forbidden by default.
|
|
|
|
|
- Explicit View/Inspect: required unless the detail is already visible inline.
|
|
|
|
|
|
|
|
|
|
##### History / Audit Surface
|
|
|
|
|
- Purpose: inspect immutable history, events, and evidence without losing chronology.
|
|
|
|
|
- Primary behavior: Inspect event -> Follow trace -> Return to history context.
|
|
|
|
|
- Primary model: explicit Inspect, preferably in a slide-over or same-page detail.
|
|
|
|
|
- Secondary actions: related navigation only.
|
|
|
|
|
- Destructive actions: normally none.
|
|
|
|
|
- Row click: forbidden.
|
|
|
|
|
- Explicit View/Inspect: required.
|
|
|
|
|
|
|
|
|
|
##### Config-lite Resource
|
|
|
|
|
- Purpose: manage small, low-cardinality configuration where edit is effectively the detail surface.
|
|
|
|
|
- Primary behavior: Open config -> Adjust.
|
|
|
|
|
- Primary model: edit-as-inspect.
|
|
|
|
|
- Secondary actions: minimal and usually limited to Edit or overflow.
|
|
|
|
|
- Destructive actions: overflow or detail header only.
|
|
|
|
|
- Row click: allowed when it opens Edit directly and no separate View surface exists.
|
|
|
|
|
- Explicit View/Inspect: forbidden.
|
|
|
|
|
|
|
|
|
|
##### Read-only Registry / Report Surface
|
|
|
|
|
- Purpose: inspect, compare, reference, and export immutable or mostly read-only artifacts.
|
|
|
|
|
- Primary behavior: Scan -> Open detail -> Reference / Export.
|
|
|
|
|
- Primary model: row click or identifier click to detail.
|
|
|
|
|
- Secondary actions: optional single inline non-destructive shortcut when it serves the operator flow.
|
|
|
|
|
- Destructive actions: normally none; if they exist they belong in detail only.
|
|
|
|
|
- Explicit View/Inspect: forbidden when a functional one-click open already exists.
|
|
|
|
|
|
|
|
|
|
##### Detail-first Operational Surface
|
|
|
|
|
- Purpose: fully understand one operational record, including state, truth, context, and next steps.
|
|
|
|
|
- Primary behavior: Read -> Understand -> Act / Navigate.
|
|
|
|
|
- Primary model: dedicated detail page or dedicated operational page.
|
|
|
|
|
- Secondary actions: header actions and related-link groups.
|
|
|
|
|
- Destructive actions: detail header or grouped header actions only, always with confirmation.
|
|
|
|
|
- Row click and explicit View/Inspect: not applicable.
|
|
|
|
|
|
|
|
|
|
#### Hard Rules (UI-HARD-001)
|
|
|
|
|
|
|
|
|
|
##### Primary inspect model
|
|
|
|
|
- Every list surface MUST expose exactly one primary inspect/open model.
|
|
|
|
|
- A surface MUST NOT offer row click, identifier click, and explicit View/Inspect for the same destination as parallel primary models.
|
|
|
|
|
- CRUD / List-first and Read-only Registry / Report surfaces MUST provide an obvious one-click open path.
|
|
|
|
|
- Queue / Review and History / Audit surfaces MUST use explicit Inspect rather than row-click navigation.
|
|
|
|
|
|
|
|
|
|
##### Row-click semantics
|
|
|
|
|
- Full-row click is the default for CRUD / List-first and Read-only Registry / Report surfaces.
|
|
|
|
|
- Identifier-only click is allowed only when full-row click would conflict with another dominant row behavior such as selection-heavy interaction, expand/collapse, drag/sort, or another primary row mechanism.
|
|
|
|
|
- When row click is enabled, the row MUST feel consistent. Silent split behavior inside the same row is forbidden.
|
|
|
|
|
- Edit-as-inspect is allowed only for Config-lite resources.
|
|
|
|
|
|
|
|
|
|
##### View and Inspect actions
|
|
|
|
|
- Explicit View MUST NOT exist when the same destination is already opened through row click or identifier click.
|
|
|
|
|
- Explicit Inspect is the default only for Queue / Review, History / Audit, and explicitly catalogued exceptions.
|
|
|
|
|
- View and Inspect MUST NOT be treated as interchangeable labels. If the interaction preserves context and behaves unlike ordinary navigation, it is Inspect, not View.
|
|
|
|
|
|
|
|
|
|
##### Action hierarchy
|
|
|
|
|
- Every surface MUST distinguish between the primary inspect/open action, secondary safe actions, destructive actions, and long-running workflow launches.
|
|
|
|
|
- Standard CRUD and Read-only Registry rows MUST NOT exceed the primary open interaction plus one inline safe shortcut.
|
|
|
|
|
- All other secondary actions MUST move to overflow.
|
|
|
|
|
- Long-running workflow launches such as sync, compare, verify, generate, consent, setup, or retry SHOULD live in list headers or detail headers rather than in every row.
|
|
|
|
|
|
|
|
|
|
##### Destructive actions
|
|
|
|
|
- Destructive actions MUST NOT appear inline beside the primary inspect interaction on standard CRUD, Config-lite, or Read-only Registry surfaces.
|
|
|
|
|
- Destructive actions MUST live in overflow or the detail header.
|
|
|
|
|
- Destructive actions MUST use confirmation.
|
|
|
|
|
- High-risk or high-volume destructive bulk actions SHOULD use typed confirmation.
|
|
|
|
|
- The Queue Decision exception applies only when the destructive decision is part of the actual queue work.
|
|
|
|
|
|
|
|
|
|
##### Overflow and More
|
|
|
|
|
- Overflow actions MUST follow one product-wide pattern per surface class.
|
|
|
|
|
- Mixed labeled-overflow versus icon-only overflow patterns inside the same surface class are forbidden unless an approved exception documents why.
|
|
|
|
|
- Empty `ActionGroup` and empty `BulkActionGroup` are forbidden.
|
|
|
|
|
- Placeholder UI added only to satisfy a contract or slot is forbidden.
|
|
|
|
|
|
|
|
|
|
##### Bulk actions
|
|
|
|
|
- Bulk actions are allowed only when they are safe enough, materially faster than row-by-row execution, and genuinely fit the surface.
|
|
|
|
|
- A surface with no real bulk need MUST NOT render bulk UI.
|
|
|
|
|
- Bulk destructive actions follow the same protection rules as row destructive actions, with stricter confirmation and review expectations.
|
|
|
|
|
|
|
|
|
|
##### Row label length and action budget
|
|
|
|
|
- Inline row action labels MUST stay short and SHOULD be one or two words.
|
|
|
|
|
- Long workflow labels belong in overflow, headers, or detail surfaces.
|
|
|
|
|
- Standard list rows MUST NOT become control centers for onboarding recovery, provider management, consent flows, RBAC setup, diagnostics, and destructive lifecycle actions all at once.
|
|
|
|
|
|
|
|
|
|
##### Scope and context semantics
|
|
|
|
|
- Scope chips, tenant pills, and similar context signals MUST correspond to real scoping behavior.
|
|
|
|
|
- A scope signal MUST NOT be shown when it neither scopes the displayed data nor materially changes the action targets.
|
|
|
|
|
- Remembered context is allowed only when labeled clearly as reference context rather than active scope.
|
|
|
|
|
- Cross-panel navigation MUST NOT imply that the operator remains inside the same logical scope when that is not true.
|
|
|
|
|
|
|
|
|
|
##### Canonical navigation and terminology
|
|
|
|
|
- Every domain object MUST have one canonical collection noun and one canonical singular noun.
|
|
|
|
|
- The same domain object MUST NOT use competing primary nouns across shells.
|
|
|
|
|
- The Operations domain MUST use one canonical collection noun. Parallel primary nouns such as Runs beside Operations are forbidden.
|
|
|
|
|
- Cross-panel navigation is allowed only when it lands on a canonical surface, uses stable nouns, and keeps back navigation clear.
|
|
|
|
|
|
|
|
|
|
##### Visibility of critical operational truth
|
|
|
|
|
- Critical operational truth MUST be visible by default.
|
|
|
|
|
- It MUST NOT be hidden only in default-off columns, tooltips, helper text, overflow menus, or detail pages when list decisions depend on it.
|
|
|
|
|
- Lifecycle truth, operability truth, health truth, execution outcome, trust/confidence, and next action MUST remain separate semantic dimensions.
|
|
|
|
|
- One badge, column, or label MUST NOT collapse multiple truth dimensions into a generic status.
|
|
|
|
|
|
|
|
|
|
##### Row density and scanability
|
|
|
|
|
- Standard CRUD lists MUST remain scanable.
|
|
|
|
|
- Outside Queue / Review and History / Audit exceptions, each row MAY contain at most one multi-line explanatory column and at most one prose-heavy explanatory context.
|
|
|
|
|
- Standard CRUD rows MUST NOT carry more than one sentence of flowing prose.
|
|
|
|
|
- Next-step prose belongs in detail, inspect, or queue surfaces, not in ordinary CRUD rows.
|
|
|
|
|
|
|
|
|
|
##### Custom abstractions
|
|
|
|
|
- Custom UI abstractions MAY document and validate, but they MUST NOT create declaration-only safety that diverges from real behavior.
|
|
|
|
|
- Contract systems MUST NOT force placeholder UI.
|
|
|
|
|
- Behavior matters more than declaration. If declared conformance and rendered behavior differ, the surface is non-conformant.
|
|
|
|
|
- A feature MUST NOT ship when its implemented interaction semantics contradict its declared surface type.
|
|
|
|
|
|
|
|
|
|
#### Exception Model (UI-EX-001)
|
|
|
|
|
|
|
|
|
|
Only catalogued exception types are allowed. Every exception MUST be named in the spec, reference its exception type, include a reason block, be called out explicitly in the PR, and carry at least one dedicated test.
|
|
|
|
|
|
|
|
|
|
##### Queue Decision Exception
|
|
|
|
|
- Allowed when per-item decision-making is the real queue work.
|
|
|
|
|
- Guardrails: Inspect remains available unless detail is already inline; irreversible decisions require confirmation; unrelated maintenance actions do not join the row.
|
|
|
|
|
|
|
|
|
|
##### History In-place Inspect Exception
|
|
|
|
|
- Allowed when leaving the page would break chronology or traceability.
|
|
|
|
|
- Guardrails: explicit Inspect is mandatory; row click is forbidden; generic mutation rails are forbidden.
|
|
|
|
|
|
|
|
|
|
##### Config-lite Edit-as-Inspect Exception
|
|
|
|
|
- Allowed when a separate View surface would add no value.
|
|
|
|
|
- Guardrails: no parallel View surface; no high-risk destructive flow as the default entry point.
|
|
|
|
|
|
|
|
|
|
##### Read-only Shortcut Exception
|
|
|
|
|
- Allowed for exactly one dominant non-destructive shortcut.
|
|
|
|
|
- Guardrails: inspect/open remains dominant; only one shortcut exists; the shortcut does not compete with the primary open path.
|
|
|
|
|
|
|
|
|
|
##### Cross-panel Canonical Route Exception
|
|
|
|
|
- Allowed when only one canonical surface makes sense.
|
|
|
|
|
- Guardrails: nouns stay stable; shell transition is explicit; back navigation is clear; scope signals remain truthful.
|
|
|
|
|
|
|
|
|
|
#### Filament UI — Action Surface Contract (NON-NEGOTIABLE)
|
|
|
|
|
|
|
|
|
|
For every new or modified Filament Resource, RelationManager, or Page:
|
|
|
|
|
|
|
|
|
|
Required surfaces
|
|
|
|
|
- List/Table MUST define: Header Actions, Row Actions, Bulk Actions, and Empty-State CTA(s).
|
|
|
|
|
- Inspect affordance (List/Table): Every table MUST provide a record inspection affordance.
|
|
|
|
|
- Accepted forms: clickable rows via `recordUrl()` (preferred), a dedicated row “View” action, or a primary linked column.
|
|
|
|
|
- Rule: Do NOT render a lone “View” row action button. If View is the only row action, prefer clickable rows.
|
|
|
|
|
- View/Detail MUST define Header Actions (Edit + “More” group when applicable).
|
|
|
|
|
- View/Detail MUST be sectioned (e.g., Infolist Sections / Cards); avoid long ungrouped field lists.
|
|
|
|
|
- Create/Edit MUST provide consistent Save/Cancel UX.
|
|
|
|
|
- List/Table MUST define Header Actions, Row Actions, Bulk Actions, and Empty-State CTA(s).
|
|
|
|
|
- Every table MUST provide a record inspection affordance that matches its surface type.
|
|
|
|
|
- Accepted forms are `recordUrl()` row click, a primary linked column, or an explicit row action when the taxonomy requires Inspect.
|
|
|
|
|
- CRUD / List-first, Config-lite, and Read-only Registry surfaces MUST NOT render a redundant View action when the same destination is already available through row click or identifier click.
|
|
|
|
|
- Queue / Review and History / Audit surfaces MAY use a lone explicit Inspect action because context-preserving inspect is the primary interaction.
|
|
|
|
|
- View/Detail MUST define header actions and MUST keep destructive actions grouped and confirmed.
|
|
|
|
|
- View/Detail MUST be sectioned using Infolists, Sections, Cards, Tabs, or equivalent composable structure.
|
|
|
|
|
- Create/Edit MUST provide consistent Save and Cancel UX.
|
|
|
|
|
|
|
|
|
|
Grouping & safety
|
|
|
|
|
- Max 2 visible Row Actions (typically View/Edit). Everything else MUST be in an ActionGroup “More”.
|
|
|
|
|
- Bulk actions MUST be grouped via BulkActionGroup.
|
|
|
|
|
- RelationManagers MUST follow the same action surface rules (grouped row actions, bulk actions where applicable, inspection affordance).
|
|
|
|
|
- Destructive actions MUST NOT be primary and MUST require confirmation; typed confirmation MAY be required for large/bulk changes.
|
|
|
|
|
Grouping and safety
|
|
|
|
|
- Standard CRUD and Read-only Registry rows MUST NOT exceed inspect/open plus one inline safe shortcut.
|
|
|
|
|
- Queue / Review rows MAY expose inline decision actions only when allowed by UI-EX-001.
|
|
|
|
|
- Everything else MUST move to `ActionGroup::make()` or the detail header.
|
|
|
|
|
- Bulk actions MUST be grouped via `BulkActionGroup` only when the surface has a real bulk use case.
|
|
|
|
|
- Empty `ActionGroup` and `BulkActionGroup` are forbidden.
|
|
|
|
|
- Destructive actions MUST NOT be primary and MUST require confirmation; typed confirmation MAY be required for large or high-risk bulk changes.
|
|
|
|
|
- Relevant mutations MUST write an audit log entry.
|
|
|
|
|
|
|
|
|
|
RBAC enforcement
|
|
|
|
|
- Non-member access MUST abort(404) and MUST NOT leak existence.
|
|
|
|
|
- Member without capability: UI visible but disabled with tooltip; server-side MUST abort(403).
|
|
|
|
|
- Central enforcement helpers (tenant/workspace UI enforcement) MUST be used for gating.
|
|
|
|
|
- Members without capability MAY see disabled actions with helper text, but server-side execution MUST still abort(403).
|
|
|
|
|
- Central tenant and workspace UI enforcement helpers MUST be used for gating.
|
|
|
|
|
|
|
|
|
|
Spec / DoD gates
|
|
|
|
|
- Every spec MUST include a “UI Action Matrix”.
|
|
|
|
|
- A change is not “Done” unless the Action Surface Contract is met OR an explicit exemption exists with documented reason.
|
|
|
|
|
- CI MUST run an automated Action Surface Contract check (test suite and/or command) that fails when required surfaces are missing.
|
|
|
|
|
Behavior over declaration
|
|
|
|
|
- Every spec MUST include both a UI/UX Surface Classification and a UI Action Matrix.
|
|
|
|
|
- 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.
|
|
|
|
|
|
|
|
|
|
### Filament UI — Layout & Information Architecture Standards (UX-001)
|
|
|
|
|
#### Filament UI — Layout & Information Architecture Standards (UX-001)
|
|
|
|
|
|
|
|
|
|
Goal: Demo-level, enterprise-grade admin UX. These rules are NON-NEGOTIABLE for new or modified Filament screens.
|
|
|
|
|
Goal: operator-facing Filament screens MUST feel enterprise-grade, legible, and decisive.
|
|
|
|
|
|
|
|
|
|
Page layout
|
|
|
|
|
- Create/Edit MUST default to a Main/Aside layout using a 3-column grid with `Main=columnSpan(2)` and `Aside=columnSpan(1)`.
|
|
|
|
|
- All fields MUST be inside Sections/Cards. No “naked” inputs at the root schema level.
|
|
|
|
|
- Main contains domain definition/content. Aside contains status/meta (status, version label, owner, scope selectors, timestamps).
|
|
|
|
|
- Related data (assignments, relations, evidence, runs, findings, etc.) MUST render as separate Sections below the main/aside grid (or as tabs/sub-navigation), never mixed as unstructured long lists.
|
|
|
|
|
- All fields MUST live inside Sections or Cards. Naked root-level inputs are forbidden.
|
|
|
|
|
- Main content carries domain definition and working content. Aside carries status and meta such as scope, owner, timestamps, or version labels.
|
|
|
|
|
- Related data MUST render as separate sections, tabs, or subordinate surfaces rather than as one long unstructured form or detail page.
|
|
|
|
|
|
|
|
|
|
View pages
|
|
|
|
|
- View/Detail MUST be a read-only experience using Infolists (or equivalent), not disabled edit forms.
|
|
|
|
|
- Status-like values MUST render as badges/chips using the centralized badge semantics (BADGE-001).
|
|
|
|
|
- Long text MUST render as readable prose (not textarea styling).
|
|
|
|
|
- View/Detail MUST be a read-only surface built with Infolists or an equivalent read-first structure, not disabled edit forms.
|
|
|
|
|
- Status-like values MUST render via BADGE-001 semantics.
|
|
|
|
|
- Long text MUST read like prose, not like disabled textarea output.
|
|
|
|
|
|
|
|
|
|
Empty states
|
|
|
|
|
- Empty lists/tables MUST show: a specific title, one-sentence explanation, and exactly ONE primary CTA in the empty state.
|
|
|
|
|
- When non-empty, the primary CTA MUST move to the table header (top-right) and MUST NOT be duplicated in the empty state.
|
|
|
|
|
- Empty lists and tables MUST show a specific title, a one-sentence explanation, and exactly one primary CTA.
|
|
|
|
|
- When records exist, that primary CTA moves to the header and MUST NOT be duplicated in the empty state shell.
|
|
|
|
|
|
|
|
|
|
Actions & flows
|
|
|
|
|
- Pages SHOULD expose at most 1 primary header action and 1 secondary action; all other actions MUST be grouped (ActionGroup / BulkActionGroup).
|
|
|
|
|
- Multi-step or high-risk flows MUST use a Wizard (e.g., capture/compare/restore with preview + confirmation).
|
|
|
|
|
- Destructive actions MUST remain non-primary and require confirmation (RBAC-UX-005).
|
|
|
|
|
Actions and flows
|
|
|
|
|
- Pages SHOULD expose at most one primary header action and one secondary header action; all others belong in groups.
|
|
|
|
|
- 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.
|
|
|
|
|
|
|
|
|
|
Table work-surface defaults
|
|
|
|
|
- Tables SHOULD provide search (when the dataset can grow), a meaningful default sort, and filters for core dimensions (status/severity/type/tenant/time-range).
|
|
|
|
|
- Tables MUST render key statuses as badges/chips (BADGE-001) and avoid ad-hoc status mappings.
|
|
|
|
|
Table defaults
|
|
|
|
|
- Tables SHOULD provide search when the dataset can grow, a meaningful default sort, and filters for core dimensions.
|
|
|
|
|
- Standard CRUD tables MUST stay scanable and MUST NOT rely on row prose to communicate next steps.
|
|
|
|
|
- Critical operational truth that informs list decisions MUST be default-visible.
|
|
|
|
|
|
|
|
|
|
Enforcement
|
|
|
|
|
- New resources/pages SHOULD use shared layout builders (e.g., `MainAsideForm`, `MainAsideInfolist`, `StandardTableDefaults`) to keep screens consistent.
|
|
|
|
|
- A change is not “Done” unless UX-001 is satisfied OR an explicit exemption exists with a documented rationale in the spec/PR.
|
|
|
|
|
- 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.
|
|
|
|
|
|
|
|
|
|
### Operator-facing UI Naming Standards (UI-NAMING-001)
|
|
|
|
|
#### Operator-facing UI Naming Standards (UI-NAMING-001)
|
|
|
|
|
|
|
|
|
|
Goal: operator-facing actions, run labels, notifications, audit prose, and related UI copy MUST use consistent,
|
|
|
|
|
enterprise-grade product language.
|
|
|
|
|
Goal: operator-facing actions, runs, notifications, audit prose, and navigation MUST use one clear domain vocabulary.
|
|
|
|
|
|
|
|
|
|
Naming model
|
|
|
|
|
- Operator-facing copy MUST distinguish four layers: Scope, Source/Domain, Operation, and Target Object.
|
|
|
|
|
- Scope terms (`Workspace`, `Tenant`) describe execution context and MUST NOT be used as the primary action label unless they are the actual target object.
|
|
|
|
|
- Source/Domain terms (`Intune`, `Entra`, `Teams`, future providers) are secondary and MUST NOT lead the primary label unless the current screen presents competing sources that need explicit disambiguation.
|
|
|
|
|
- Operator-facing copy MUST distinguish Scope, Source/Domain, Operation, and Target Object.
|
|
|
|
|
- Scope terms such as Workspace and Tenant describe execution context and MUST NOT become the primary action label unless they are the actual target object.
|
|
|
|
|
- Source/domain terms such as Intune or Entra are secondary and lead only when same-screen disambiguation genuinely requires them.
|
|
|
|
|
|
|
|
|
|
Primary action labels
|
|
|
|
|
- Primary buttons, header actions, and menu actions MUST use `Verb + Object`.
|
|
|
|
|
- Preferred examples: `Sync policies`, `Sync groups`, `Capture baseline`, `Compare baseline`, `Restore policy`, `Run review`, `Export review pack`.
|
|
|
|
|
- Forbidden examples: `Sync from tenant`, `Backup tenant`, `Compare tenant`, `Sync from Intune`, `Run tenant sync now`, `Start inventory refresh from provider`.
|
|
|
|
|
Primary labels
|
|
|
|
|
- Primary buttons, header actions, and menu actions MUST use Verb + Object.
|
|
|
|
|
- Preferred examples are `Sync policies`, `Sync groups`, `Capture baseline`, `Compare baseline`, `Restore policy`, `Run review`, and `Export review pack`.
|
|
|
|
|
- Implementation-first labels such as `Sync from tenant`, `Sync from Intune`, `Run tenant sync now`, or `Start inventory refresh from provider` are forbidden.
|
|
|
|
|
|
|
|
|
|
Domain vocabulary
|
|
|
|
|
- Operator-facing copy MUST prefer product-domain objects such as `policies`, `groups`, `baseline`, `findings`, `review pack`, `alerts`, and `operations`.
|
|
|
|
|
- Primary operator-facing copy MUST NOT use implementation-first terms such as `provider`, `gateway`, `resolver`, `collector`, `contract registry`, or `job dispatch`.
|
|
|
|
|
- Source/domain details MAY appear in modal descriptions, helper text, run metadata, audit metadata, and notifications when needed for precision.
|
|
|
|
|
Canonical nouns and routes
|
|
|
|
|
- Every domain object MUST keep one canonical collection noun and one canonical singular noun.
|
|
|
|
|
- Cross-shell or cross-panel navigation MUST preserve the same noun.
|
|
|
|
|
- Operations is the canonical collection noun for run records. Runs MUST NOT appear as a competing primary collection noun.
|
|
|
|
|
|
|
|
|
|
Run, notification, and audit semantics
|
|
|
|
|
- Visible run titles MUST use the same domain vocabulary as the initiating action and SHOULD be concise noun phrases such as `Policy sync`, `Baseline capture`, `Baseline compare`, `Policy restore`, and `Tenant review`.
|
|
|
|
|
- Notifications MUST use either `{Object} {state}` or `{Operation} {result}` and remain short, e.g. `Policy sync queued`, `Policy sync completed`, `Policy sync failed`, `Baseline compare detected drift`.
|
|
|
|
|
- Audit prose MUST use the same operator-facing language, e.g. `{actor} queued policy sync`, `{actor} captured baseline`, `{actor} reopened finding`.
|
|
|
|
|
- The same user-visible action MUST keep the same domain vocabulary across button labels, modal titles, run titles, notifications, and audit prose.
|
|
|
|
|
- Visible run titles MUST use the same domain vocabulary as the initiating action and SHOULD remain concise noun phrases such as `Policy sync`, `Baseline capture`, `Baseline compare`, `Policy restore`, and `Tenant review`.
|
|
|
|
|
- Notifications MUST use either `{Object} {state}` or `{Operation} {result}` and remain short.
|
|
|
|
|
- Audit prose MUST use the same operator-facing language as the initiating action.
|
|
|
|
|
- The same user-visible action MUST keep the same domain vocabulary across button labels, modal titles, run titles, notifications, audit prose, and related navigation.
|
|
|
|
|
|
|
|
|
|
Verb standard
|
|
|
|
|
- Preferred verbs are `Sync`, `Capture`, `Compare`, `Restore`, `Review`, `Export`, `Open`, `Archive`, `Resolve`, `Reopen`, and `Assign`.
|
|
|
|
|
- `Start`, `Execute`, `Trigger`, and `Perform` SHOULD be avoided for operator-facing copy unless there is a deliberate domain reason.
|
|
|
|
|
- `Run` MAY be used only when the object is itself run-like, such as `Run review` or `Run compare`; it MUST NOT be the generic fallback verb for all operations.
|
|
|
|
|
- `Start`, `Execute`, `Trigger`, and `Perform` SHOULD be avoided unless the domain specifically requires them.
|
|
|
|
|
- `Run` MAY be used only when the object is itself run-like, such as `Run review`; it MUST NOT become the fallback verb for everything.
|
|
|
|
|
|
|
|
|
|
Current binding decision
|
|
|
|
|
- The Policies screen primary action MUST be `Sync policies`.
|
|
|
|
|
@ -417,75 +585,125 @@ ### Operator-facing UI Naming Standards (UI-NAMING-001)
|
|
|
|
|
- The visible run label for that action MUST be `Policy sync`.
|
|
|
|
|
- The audit prose for that action MUST be `{actor} queued policy sync`.
|
|
|
|
|
|
|
|
|
|
### Operator Surface Principles (OPSURF-001)
|
|
|
|
|
#### Operator Surface Principles (OPSURF-001)
|
|
|
|
|
|
|
|
|
|
Goal: operator-facing surfaces MUST optimize for the primary working audience rather than raw implementation visibility.
|
|
|
|
|
Goal: operator-facing surfaces MUST optimize for the operator's working question instead of raw implementation visibility.
|
|
|
|
|
|
|
|
|
|
Operator-first default surfaces
|
|
|
|
|
- `/admin` is operator-first.
|
|
|
|
|
- Default-visible content MUST use operator-facing language, clear scope, and actionable status communication.
|
|
|
|
|
- Default-visible content MUST use operator language, clear scope, and actionable status communication.
|
|
|
|
|
- Raw implementation details MUST NOT be default-visible on primary operator surfaces.
|
|
|
|
|
|
|
|
|
|
Progressive disclosure for diagnostics
|
|
|
|
|
- Diagnostic detail MAY be available where needed, but it MUST be secondary and explicitly revealed.
|
|
|
|
|
- JSON payloads, raw IDs, internal field names, provider error details, and low-level technical metadata belong in diagnostics surfaces, drawers, tabs, accordions, or modals rather than primary content.
|
|
|
|
|
- A surface MUST NOT require operators to parse raw JSON or provider-specific field names to understand the primary state or next action.
|
|
|
|
|
- Diagnostic detail MAY exist, but it MUST be secondary and explicitly revealed.
|
|
|
|
|
- JSON payloads, raw IDs, internal field names, provider error details, and low-level technical metadata belong in diagnostics surfaces rather than the primary content region.
|
|
|
|
|
- Operators MUST NOT need to parse raw payloads to understand current state or next action.
|
|
|
|
|
|
|
|
|
|
Distinct status dimensions
|
|
|
|
|
- Operator-facing surfaces MUST distinguish at least the following dimensions when they all exist in the domain:
|
|
|
|
|
- execution outcome
|
|
|
|
|
- data completeness
|
|
|
|
|
- governance result
|
|
|
|
|
- lifecycle or readiness state
|
|
|
|
|
- These dimensions MUST NOT be collapsed into a single ambiguous status model.
|
|
|
|
|
- If a surface summarizes multiple status dimensions, the default-visible presentation MUST label each dimension explicitly.
|
|
|
|
|
Distinct truth dimensions
|
|
|
|
|
- When the domain has execution outcome, data completeness, governance result, lifecycle or readiness state, operability truth, health truth, trust/confidence, or next action semantics, the surface MUST keep them explicit instead of collapsing them into one ambiguous status.
|
|
|
|
|
- If multiple truth dimensions are summarized, the default-visible UI MUST label each dimension clearly.
|
|
|
|
|
|
|
|
|
|
Explicit mutation scope
|
|
|
|
|
- Every action that changes state MUST communicate before execution whether it affects:
|
|
|
|
|
- TenantPilot only
|
|
|
|
|
- the Microsoft tenant
|
|
|
|
|
- simulation only
|
|
|
|
|
- Mutation scope MUST be understandable from the action label, helper text, confirmation copy, preview, or nearby status copy before the operator commits.
|
|
|
|
|
- A mutating action MUST NOT rely on hidden implementation knowledge to communicate its blast radius.
|
|
|
|
|
- Every state-changing action MUST communicate before execution whether it affects TenantPilot only, the Microsoft tenant, or simulation only.
|
|
|
|
|
- Mutation scope MUST be understandable from nearby action copy, helper text, preview, or confirmation.
|
|
|
|
|
|
|
|
|
|
Safe execution for dangerous actions
|
|
|
|
|
- Dangerous actions MUST follow a consistent safe-execution pattern:
|
|
|
|
|
- configuration
|
|
|
|
|
- safety checks or simulation
|
|
|
|
|
- preview
|
|
|
|
|
- hard confirmation where required
|
|
|
|
|
- execute
|
|
|
|
|
- One-click destructive actions are not acceptable for high-blast-radius operations.
|
|
|
|
|
- When a full multi-step flow is not feasible, the spec MUST document the explicit exemption and the replacement safeguards.
|
|
|
|
|
Safe execution
|
|
|
|
|
- Dangerous actions MUST follow a consistent safety flow: configuration, safety checks or simulation, preview, hard confirmation where required, then execution.
|
|
|
|
|
- One-click high-blast-radius actions are forbidden unless an approved exception documents replacement safeguards.
|
|
|
|
|
|
|
|
|
|
Explicit workspace and tenant context
|
|
|
|
|
- Workspace and tenant scope MUST remain explicit in navigation, actions, and page semantics.
|
|
|
|
|
- Tenant-scoped surfaces MUST NOT silently expose workspace-wide actions.
|
|
|
|
|
- Canonical workspace views that reference tenant-owned records MUST make the workspace and tenant context legible before the operator acts.
|
|
|
|
|
- Workspace and tenant context MUST remain explicit in navigation, action copy, and page semantics.
|
|
|
|
|
- Tenant surfaces MUST NOT silently expose workspace-wide actions.
|
|
|
|
|
- Canonical workspace views that operate on tenant-owned records MUST make both workspace and tenant context legible before the operator acts.
|
|
|
|
|
|
|
|
|
|
Critical truth visibility and scanability
|
|
|
|
|
- Critical operational truth MUST be default-visible wherever the list or summary surface is used to prepare decisions.
|
|
|
|
|
- Standard CRUD surfaces MUST preserve scanability and MUST avoid collapsing multiple truth dimensions into one generic badge or one prose-heavy row.
|
|
|
|
|
|
|
|
|
|
Page contract requirement
|
|
|
|
|
- Every new or materially refactored operator-facing page MUST define:
|
|
|
|
|
- primary persona
|
|
|
|
|
- surface type
|
|
|
|
|
- primary operator question
|
|
|
|
|
- default-visible information
|
|
|
|
|
- diagnostics-only information
|
|
|
|
|
- status dimensions used
|
|
|
|
|
- mutation scope
|
|
|
|
|
- primary actions
|
|
|
|
|
- dangerous actions
|
|
|
|
|
- This page contract MUST be recorded in the governing spec and kept in sync when the page semantics materially change.
|
|
|
|
|
- Every new or materially refactored operator-facing page MUST define the primary persona, surface type, primary operator question, default-visible information, diagnostics-only information, status dimensions used, mutation scope, primary actions, and dangerous actions.
|
|
|
|
|
- The page contract MUST live in the governing spec and stay in sync with implementation.
|
|
|
|
|
|
|
|
|
|
Spec Scope Fields (SCOPE-002)
|
|
|
|
|
#### Spec Scope Fields (SCOPE-002)
|
|
|
|
|
|
|
|
|
|
- Every feature spec MUST declare:
|
|
|
|
|
- Scope: workspace | tenant | canonical-view
|
|
|
|
|
- Primary Routes
|
|
|
|
|
- Data Ownership: workspace-owned vs tenant-owned tables/records impacted
|
|
|
|
|
- RBAC: membership requirements + capability requirements
|
|
|
|
|
- For canonical-view specs, the spec MUST define:
|
|
|
|
|
- Default filter behavior when tenant-context is active (e.g., prefilter to current tenant)
|
|
|
|
|
- Explicit entitlement checks that prevent cross-tenant leakage
|
|
|
|
|
- Every feature spec MUST declare Scope, Primary Routes, Data Ownership, and RBAC requirements.
|
|
|
|
|
- Canonical-view specs MUST define the default filter behavior when tenant context is active and the entitlement checks that prevent cross-tenant leakage.
|
|
|
|
|
|
|
|
|
|
#### 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.
|
|
|
|
|
- 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.
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
#### Immediate Retrofit Priorities
|
|
|
|
|
|
|
|
|
|
Wave 1 - Interaction normalization
|
|
|
|
|
- First fixes target redundant row click plus View, destructive row actions on standard lists, empty overflow or bulk groups, and rows that have become pseudo-control centers.
|
|
|
|
|
- First-slice focus surfaces are Tenants, Workspaces, Policies, Alert Deliveries, and other CRUD-first list surfaces with the same drift pattern.
|
|
|
|
|
- Wave 1 is done only when each surface has exactly one primary inspect model, destructive actions are protected, and placeholder groups are gone.
|
|
|
|
|
|
|
|
|
|
Wave 2 - Scope, nouns, and truth
|
|
|
|
|
- Then fix scope and context leaks, stabilize canonical nouns, make cross-panel transitions explicit, move critical operational truth to default-visible regions, and reduce prose-heavy dense rows.
|
|
|
|
|
|
|
|
|
|
Wave 3 - Enforcement
|
|
|
|
|
- Then move the constitution into repo enforcement, require the PR checklist, anchor guard tests, and trim old declaration-only action-surface checks until behavior is the governing truth.
|
|
|
|
|
|
|
|
|
|
#### Appendix A - One-page Condensed Constitution
|
|
|
|
|
|
|
|
|
|
- Every admin surface has one surface type.
|
|
|
|
|
- Every list has exactly one primary inspect/open model.
|
|
|
|
|
- CRUD and Registry surfaces use one-click open.
|
|
|
|
|
- Queue and Audit surfaces use explicit Inspect.
|
|
|
|
|
- Edit-as-inspect exists only for Config-lite resources.
|
|
|
|
|
- Standard lists expose at most one inline safe shortcut.
|
|
|
|
|
- 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.
|
|
|
|
|
- Scope chips must be truthful.
|
|
|
|
|
- Domain nouns are canonical and stable.
|
|
|
|
|
- Critical operational truth is default-visible.
|
|
|
|
|
- Semantic truth dimensions are not collapsed into a generic status.
|
|
|
|
|
- Standard lists stay scanable.
|
|
|
|
|
- Exceptions are catalogued, justified, and tested.
|
|
|
|
|
- Features with ambiguous interaction semantics do not ship.
|
|
|
|
|
|
|
|
|
|
#### Appendix B - Feature Review Checklist
|
|
|
|
|
|
|
|
|
|
- Surface type is declared.
|
|
|
|
|
- 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.
|
|
|
|
|
- Secondary actions are grouped correctly.
|
|
|
|
|
- Destructive actions are placed correctly.
|
|
|
|
|
- Overflow is not empty.
|
|
|
|
|
- Bulk is justified.
|
|
|
|
|
- Inline labels are short.
|
|
|
|
|
- Scope signals are truthful.
|
|
|
|
|
- Canonical nouns stay consistent.
|
|
|
|
|
- Critical truth is visible.
|
|
|
|
|
- Scanability is preserved.
|
|
|
|
|
- Exceptions are documented and tested.
|
|
|
|
|
|
|
|
|
|
#### Appendix C - Red Flags for Future PRs
|
|
|
|
|
|
|
|
|
|
- Row click and View open the same destination.
|
|
|
|
|
- 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.
|
|
|
|
|
- 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.
|
|
|
|
|
- Critical health or operability truth is hidden by default.
|
|
|
|
|
- A contract claims conformance while the rendered UI behaves differently.
|
|
|
|
|
|
|
|
|
|
### Data Minimization & Safe Logging
|
|
|
|
|
- Inventory MUST store only metadata + whitelisted `meta_jsonb`.
|
|
|
|
|
@ -569,4 +787,4 @@ ### Versioning Policy (SemVer)
|
|
|
|
|
- **MINOR**: new principle/section or materially expanded guidance.
|
|
|
|
|
- **MAJOR**: removing/redefining principles in a backward-incompatible way.
|
|
|
|
|
|
|
|
|
|
**Version**: 1.14.0 | **Ratified**: 2026-01-03 | **Last Amended**: 2026-03-27
|
|
|
|
|
**Version**: 2.0.0 | **Ratified**: 2026-01-03 | **Last Amended**: 2026-03-28
|
|
|
|
|
|
Ahmed Darrazi