ahmido/TenantAtlas
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects 1 Releases Wiki Activity

Merge remote-tracking branch 'origin/dev' into 213-website-foundation-v0
Some checks failed
PR Fast Feedback / fast-feedback (pull_request) Failing after 44s
Details

Browse Source 
# Conflicts:
#	.github/agents/copilot-instructions.md
This commit is contained in:
Ahmed Darrazi 2026-04-18 22:55:10 +02:00
commit a7124731c9
15 changed files with 1472 additions and 708 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
.github/agents/copilot-instructions.md vendored
View File

@ -205,6 +205,7 @@ ## Active Technologies
- Repository-owned markdown and contract artifacts under `.specify/`, `specs/212-test-authoring-guardrails/`, and root documentation files; no product database persistence (212-test-authoring-guardrails)
- PHP 8.4.15 + Laravel 12, Filament v5, Livewire v4, Pest v4, Tailwind CSS v4, existing `WorkspaceContext`, `OperateHubShell`, `EnsureFilamentTenantSelected`, `WorkspaceRedirectResolver`, `WorkspaceIntendedUrl`, `TenantPageCategory`, and `ResolvesPanelTenantContext` (199-global-context-shell-contract)
- PostgreSQL unchanged plus existing Laravel session keys `current_workspace_id`, `workspace_intended_url`, and `workspace_last_tenant_ids`; no schema change planned (199-global-context-shell-contract)
- Markdown governance artifacts in a PHP 8.4.15 / Laravel 12 / Filament v5 / Livewire v4 repository + `.specify/memory/constitution.md`, `docs/ui/operator-ux-surface-standards.md`, adjacent Specs 196 through 199, existing UI rule IDs `UI-SURF-001`, `ACTSURF-001`, `UI-HARD-001`, `UI-EX-001`, `UI-FIL-001`, `DECIDE-001`, and `UX-001` (200-filament-surface-rules)
- Astro 6.0.0 templates + TypeScript 5.x (explicit setup in `apps/website`) + Astro 6, Tailwind CSS v4, custom Astro component primitives (shadcn-inspired), lightweight Playwright browser smoke tests (213-website-foundation-v0)
- Static filesystem content, styles, and assets under `apps/website/src` and `apps/website/public`; no database (213-website-foundation-v0)
@ -242,6 +243,7 @@ ## Code Style
## Recent Changes
- 213-website-foundation-v0: Added Astro 6.0.0 templates + TypeScript 5.x (explicit setup in `apps/website`) + Astro 6, Tailwind CSS v4, custom Astro component primitives (shadcn-inspired), lightweight Playwright browser smoke tests
- 200-filament-surface-rules: Added Markdown governance artifacts in a PHP 8.4.15 / Laravel 12 / Filament v5 / Livewire v4 repository + `.specify/memory/constitution.md`, `docs/ui/operator-ux-surface-standards.md`, adjacent Specs 196 through 199, existing UI rule IDs `UI-SURF-001`, `ACTSURF-001`, `UI-HARD-001`, `UI-EX-001`, `UI-FIL-001`, `DECIDE-001`, and `UX-001`
- 199-global-context-shell-contract: Added PHP 8.4.15 + Laravel 12, Filament v5, Livewire v4, Pest v4, Tailwind CSS v4, existing `WorkspaceContext`, `OperateHubShell`, `EnsureFilamentTenantSelected`, `WorkspaceRedirectResolver`, `WorkspaceIntendedUrl`, `TenantPageCategory`, and `ResolvesPanelTenantContext`
- 212-test-authoring-guardrails: Added Markdown for repository governance artifacts, JSON Schema plus logical OpenAPI for planning contracts, and Bash-backed SpecKit scripts already present in the repo + `.specify/memory/constitution.md`, `.specify/templates/spec-template.md`, `.specify/templates/plan-template.md`, `.specify/templates/tasks-template.md`, `.specify/templates/checklist-template.md`, `.specify/README.md`, `README.md`, and the existing Specs 206 through 211 governance vocabulary
<!-- MANUAL ADDITIONS START -->

272
.specify/memory/constitution.md
View File

@ -1,33 +1,19 @@
<!--
Sync Impact Report
- Version change: 2.4.0 -> 2.5.0
- Version change: 2.5.0 -> 2.6.0
- Modified principles:
- Test Suite Governance Must Live In The Delivery Workflow
(TEST-GOV-001): expanded into explicit test-impact disclosure,
lane discipline, minimal-fixture defaults, heavy-family visibility,
expensive-default bans, runtime-budget stewardship, review-stop
rules, and escalation triggers
- Governance review expectations: expanded to require test-purpose
classification, explicit runtime-cost review, and visible review
routine coverage in delivery artifacts
- UI surface taxonomy and review expectations: expanded with native
vs custom classification, shared-detail host ownership, named
anti-patterns, and shell/page/detail state ownership review
- Filament Native First / No Ad-hoc Styling (UI-FIL-001): expanded
into explicit native-by-default, fake-native, shared-family, and
exception-boundary language
- Added sections: None
- Removed sections: None
- Templates requiring updates:
- ✅ .specify/memory/constitution.md
- ✅ .specify/templates/plan-template.md (lane-discipline and
escalation-planning checks expanded)
- ✅ .specify/templates/spec-template.md (test-purpose,
lane-discipline, heavy-family, and escalation prompts expanded)
- ✅ .specify/templates/tasks-template.md (task obligations expanded for
classification, cheap defaults, review-stop rules, and runtime
stewardship)
- ✅ .specify/templates/checklist-template.md (review checklist guidance
expanded for lane fit, heavy risk, and escalation)
- ✅ .specify/README.md (SpecKit workflow expectations expanded for
visible test-governance coverage)
- ✅ README.md (developer workflow guidance expanded for lane
discipline and runtime stewardship)
- None in this docs-only constitution slice; enforcement remains
deferred to Spec 201
- Commands checked:
- N/A `.specify/templates/commands/*.md` directory is not present in this repo
- Follow-up TODOs: None
@ -579,6 +565,24 @@ ##### Detail-first Operational Surface
- Destructive actions: detail header or grouped header actions only, always with confirmation.
- Row click and explicit View/Inspect: not applicable.
##### Native vs custom and shared-family classification
- Every operator-facing surface MUST also classify whether it is a
`Native Surface`, a `Custom Surface`, or a `Shared Detail Micro-UI`
embedded inside a `Host`.
- `Native Surface` means the primary interaction contract is expressed
through Filament-native components or approved shared primitives.
- `Custom Surface` means the operator need is materially richer than
standard CRUD, overview, or report semantics and the deviation is
justified through UI-EX-001.
- `Shared Detail Micro-UI` means a repeated embedded review, evidence,
or detail surface that appears in more than one host and must read as
the same family wherever it appears.
- `Host` means the page, resource, workbench, or detail surface that
embeds a shared detail micro-UI and owns routing, authorization, the
outer inspect/open model, and host-only actions.
- A `Fake-Native Surface` is never an allowed classification. It is a
violation class defined by UI-HARD-001 and UI-FIL-001.
#### Action Surface Discipline (ACTSURF-001)
Goal: actions across all surfaces MUST make the next sensible operator
@ -649,6 +653,22 @@ ##### Utility / System surfaces
- System or recovery status does not justify casual placement of
destructive or governance-changing actions.
##### Shared detail families and one primary interaction model
- A shared detail micro-UI MUST define one family-level core
interaction model before a second host extends it.
- Hosts MAY vary framing, assist entry, surrounding navigation, or
optional diagnostics only when the shared core remains recognizable
and the variation is explicit.
- The host owns page-level navigation, authorization, surrounding
mutations, and dangerous actions. The shared family owns only the
repeated read/inspect/view semantics that are intentionally common.
- One user concern MUST NOT be split across two peer interaction
models on the same page.
- `Parallel Inspect Worlds` means the same concern is driven by two
competing inspect, selected-record, or view-state owners. It is
forbidden.
##### Action grouping and order
- Actions MUST be ordered by meaning, frequency, and risk.
@ -718,7 +738,12 @@ ##### Review gate
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?
6. If this is a repeated detail family, what is shared core vs
host-owned variation?
7. Does one concern still have exactly one primary interaction model?
8. Which layer owns the relevant truth: shell, page, or detail?
9. Is any exception real, bounded, and named, or is it a hidden
exception?
If those answers are not clear, the surface is non-conformant.
@ -737,6 +762,11 @@ ##### Primary inspect 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.
- Inline detail, summary, or sidebar inspect MAY exist only as
subordinate presentations of the same selected-record truth, not as a
second inspect contract.
- `Parallel Inspect Worlds` are forbidden even when each local variant
looks individually reasonable.
##### Row-click semantics
- Full-row click is the default for CRUD / List-first and Read-only Registry / Report surfaces.
@ -755,6 +785,29 @@ ##### Action hierarchy
- 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.
##### Native-by-default and fake-native drift
- Standard form, filter, table, action, tab, badge, link, and overview
work is `Native Surface` work by default when Filament or an existing
shared primitive can express it.
- A `Fake-Native Surface` is any surface that visually lives inside
Filament but keeps a second HTML, GET, query, or Blade-request
interaction contract for its primary behavior.
- Simple report or overview pages with ordinary columns, filters, empty
states, and navigation default to native table semantics.
- `Filament Costume` means locally assembled markup imitates native
Filament controls, badges, or actions even though native or shared
primitives fit. It is forbidden.
- `Blade Request UI` means the primary body-state contract depends on
`request()`, GET forms, or manual query parsing inside an active
Filament surface. It is forbidden unless a documented exception limits
request input to initialization-only behavior.
- `Hand-Rolled Simple Overview` means a simple report or overview is
rebuilt as bespoke markup where native table/list/report semantics
fit. It is forbidden.
- `Hidden Exception` means a surface behaves like a custom or special
case without naming an exception type and reason block. It is
forbidden.
##### 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.
@ -802,6 +855,16 @@ ##### Row density and scanability
- 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.
##### Shared-family and state-layer violations
- `Host Drift` occurs when a host silently redefines a shared detail
micro-UI's core zones, diagnostics contract, or primary view/inspect
model. Host Drift is forbidden.
- `State Layer Collapse` occurs when shell, page, or detail layers each
claim the same active truth or restoration responsibility. It is
forbidden.
- A lower layer MAY format or reveal a higher-layer truth, but it MUST
NOT quietly become the higher layer's authority.
##### 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.
@ -812,6 +875,11 @@ #### 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.
- A `Legitimate Exception` is a named, bounded deviation that states the
product reason, the smallest custom behavior required, what remains
standardized, which layer owns the relevant state, and what proof or
review evidence keeps it from turning into a general permission slip.
##### 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.
@ -832,6 +900,38 @@ ##### 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.
##### Legitimate Custom Surface Exception
- Allowed when the operator need is materially richer than ordinary
CRUD, overview, or simple report semantics, such as richer
visualization, high-value diagnostic or review work, multi-zone shared
detail micro-UI, shell-context-specific UI, or domain presentation
that native primitives do not express cleanly.
- Guardrails: the spec MUST state the product reason, the smallest
custom behavior required, which native/shared primitives still apply,
which layer owns the relevant state, and what remains standardized.
##### Nativity Exception
- Allowed only when Filament-native or shared primitives cannot express
the required semantics cleanly.
- Guardrails: the exception MUST name the missing semantic, reject
`Filament Costume`, `Blade Request UI`, and `Hand-Rolled Simple
Overview` shortcuts, keep native/shared surrounding controls where
they still fit, and MUST NOT invent a local status language.
##### Shared Detail Host Variation Exception
- Allowed when a known shared detail micro-UI needs bounded host
framing, assist entry, or optional-zone variation.
- Guardrails: the host MUST NOT redefine the family core zones,
next-step contract, diagnostics contract, or primary view/inspect
model. Differences stay visibly host-scoped.
##### State-Layer Special-case Exception
- Allowed when a page legitimately needs explicit requested, active,
draft, inspect, or restorable roles beyond the simple default.
- Guardrails: the owner layer MUST be explicit, the restorable subset
MUST be explicit, any query role MUST be documented, and no lower
layer may silently take over shell or page truth.
#### Filament UI — Action Surface Contract (NON-NEGOTIABLE)
For every new or modified Filament Resource, RelationManager, or Page:
@ -842,6 +942,10 @@ #### Filament UI — Action Surface Contract (NON-NEGOTIABLE)
- 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.
- Simple report or overview pages with ordinary columns, filters,
empty-state behavior, and navigation MUST be implemented as native
table surfaces unless UI-EX-001 documents why a richer custom surface
is required.
- 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.
@ -850,6 +954,9 @@ #### Filament UI — Action Surface Contract (NON-NEGOTIABLE)
- 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.
- Repeated embedded detail/evidence families MUST declare one shared
core contract. Host-specific navigation, mutations, and destructive
actions stay outside that shared core.
- 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.
@ -864,6 +971,12 @@ #### Filament UI — Action Surface Contract (NON-NEGOTIABLE)
- 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.
- Every changed operator-facing surface MUST also declare whether it is
a `Native Surface`, `Custom Surface`, or `Shared Detail Micro-UI`, and
MUST name any exception type it relies on.
- If a surface uses shell, page, or detail state beyond simple static
rendering, the governing spec MUST name which layer owns the relevant
requested, active, draft, inspect, and restorable state.
- 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.
@ -899,6 +1012,26 @@ #### Filament UI — Layout & Information Architecture Standards (UX-001)
- 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.
State ownership
- `Global Context State` is shell-owned workspace, tenant, or tenantless
truth. Context bars and shell partials may display it, but they MUST
NOT invent second precedence or fallback logic.
- `Page State` is page-owned filter, tab, mode, or selected-record truth
that changes the current page result or workflow.
- `Detail State` is embedded viewer or shared-family state inside one
detail surface and remains subordinate to shell and page truth unless
an approved exception says otherwise.
- `Requested State` is route, query, or upstream input before validation.
- `Active State` is the currently governing validated state.
- `Draft State` is local pending state that is intentionally separate
from the currently applied result state.
- `Inspect State` is the selected-record or selected-detail focus that
drives inline or same-page inspect.
- `Restorable State` is the subset intentionally recreated by refresh,
back, bookmark, or shared link.
- `State Layer Collapse` is forbidden. Shell, page, and detail layers
MUST NOT silently overwrite one another's authority.
Enforcement
- 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.
@ -920,6 +1053,16 @@ ##### Core rule
contextual references do not belong in the header; they belong directly
at the affected field, status indicator, or relation.
##### Shared-family host discipline
- If a record or detail page embeds a shared detail micro-UI, the
header remains host-owned.
- Family-level view switches, tabs, diagnostics reveals, and inner
assist controls belong inside the family, not as copied header
buttons.
- Host-specific navigation or mutations MAY appear in the header only
when they are truly host-critical and do not redefine the family core.
##### Maximum one primary visible header action
- Each record/detail page MUST expose at most one clearly prioritized
@ -1022,6 +1165,9 @@ ##### Reviewer heuristics
- Pure navigation buttons in the header.
- Danger actions beside normal actions without clear separation.
- Rarely used administrative actions as visible standard buttons.
- Shared-family view switches or host-only forks are exported into the
main header instead of staying inside the family or contextual
placement.
- The header resembles an action stockpile instead of a focused
workflow entry point.
@ -1120,8 +1266,12 @@ #### Enforcement Model (UI-REVIEW-001)
actions are ordered, canonical collection route, canonical detail
route, scope signals and their exact meaning, canonical noun,
critical truth visible by default, workflow-vs-storage IA
justification, attention-load reduction, and whether an exception
type is used.
justification, attention-load reduction, whether the surface is
native, custom, or a shared detail family, what shared core vs host
variation exists if relevant, which layer owns the relevant shell,
page, and detail truth, which requested/active/draft/inspect/
restorable roles exist, whether any fake-native or host-drift risk is
present, and whether an exception type is used.
- Missing any of those answers makes the spec incomplete.
PR review requirements
@ -1136,8 +1286,10 @@ #### Enforcement Model (UI-REVIEW-001)
promoted into primary navigation without justification, one case
fragmented across multiple equal-rank pages, new automation that adds
attention surfaces without reducing operator work, noisy default
surfaces with no action/watch/reference hierarchy, or undocumented
exceptions without dedicated tests.
surfaces with no action/watch/reference hierarchy, `Filament Costume`,
`Blade Request UI`, `Hand-Rolled Simple Overview`, `Hidden Exception`,
`Host Drift`, `State Layer Collapse`, `Parallel Inspect Worlds`, or
undocumented exceptions without dedicated tests.
Guard tests
- Repository guards SHOULD validate: declared surface type, declared
@ -1146,8 +1298,11 @@ #### Enforcement Model (UI-REVIEW-001)
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.
stable canonical nouns across shells, absence of fake-native primary
controls where metadata says the surface is native, bounded shared
family contracts where metadata says a family is reused, explicit
state ownership where specs or metadata expose it, and dedicated
tests for every approved exception.
#### Immediate Retrofit Priorities
@ -1200,6 +1355,13 @@ #### 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.
- Standard forms, filters, tables, tabs, badges, links, and simple
overviews are native-by-default.
- Fake-native surfaces, hidden exceptions, host drift, and state-layer
collapse do not ship.
- Repeated detail micro-UIs define shared core and bounded host
variation before a second host forks them.
- Shell, page, and detail truth each have one owner.
- Navigation and mutation do not share equal visual weight without
explicit hierarchy.
- Monitoring and workbench surfaces separate scope/context, selection,
@ -1228,10 +1390,14 @@ #### Appendix B - Feature Review Checklist
- Broad action-surface class is declared.
- Detailed surface type is declared.
- The one most likely next operator action is explicit.
- The surface is classified correctly as native, custom, or shared
family.
- 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.
- Fake-native shortcuts are absent or explicitly exception-gated.
- Shared-family core vs host-owned variation is explicit where relevant.
- Navigation and mutation are separated intentionally.
- Secondary actions are grouped correctly.
- Destructive actions are placed correctly.
@ -1242,6 +1408,9 @@ #### Appendix B - Feature Review Checklist
- Canonical nouns stay consistent.
- Critical truth is visible.
- Scanability is preserved.
- Shell, page, and detail state owners are explicit.
- Requested, active, draft, inspect, and restorable roles are explicit
when the surface uses them.
- Exceptions are documented and tested.
- Header passes the 5-second scan rule (HDR-001).
- No pure navigation in the header.
@ -1261,6 +1430,11 @@ #### Appendix C - Red Flags for Future PRs
attention load.
- The surface creates more noise than priority.
- Row click and View open the same destination.
- A Filament-looking surface keeps its real primary contract in raw HTML,
GET, or Blade request state.
- A simple overview is rebuilt as bespoke markup without a real product
reason.
- A special surface exists only by history and lacks a named exception.
- 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.
@ -1274,6 +1448,10 @@ #### Appendix C - Red Flags for Future PRs
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.
- A repeated detail surface quietly changes family core structure from
one host to another.
- Shell, page, and detail layers each claim the same truth.
- One concern has two competing inspect or view-state owners.
- Header has multiple equally weighted buttons without clear prioritization.
- "Open X" navigation links placed in the header instead of at the related field.
- Governance-changing actions sit casually beside the primary action without friction.
@ -1294,14 +1472,36 @@ ### Filament Native First / No Ad-hoc Styling (UI-FIL-001)
- If Filament already provides the required semantic element, feature code MUST use the Filament-native component instead of a locally assembled replacement.
- Preferred native elements include `x-filament::badge`, `x-filament::button`, `x-filament::icon`, and Filament Forms, Infolists, Tables, Sections, Tabs, Grids, and Actions.
Native-by-default classification
- `Native Surface` means the primary interaction contract is built from
Filament-native components or approved shared primitives.
- Standard forms, filters, tables, tabs, badges, links, and simple
overviews default to `Native Surface` status.
- `Custom Surface` is allowed only through UI-EX-001 when the operator
need is richer than standard CRUD, overview, or report semantics.
- `Fake-Native Surface` is forbidden: a surface that looks native but
keeps a second HTML, GET, query, or Blade-request contract for the
same primary interaction.
Forbidden local replacements
- Feature code MUST NOT hand-build badges, pills, status chips, alert cards, or action buttons from raw `<span>`, `<div>`, or `<button>` markup plus Tailwind classes when Filament-native or shared project primitives can express the same meaning.
- Feature code MUST NOT introduce page-local visual status languages for status, risk, outcome, drift, trust, importance, or severity.
- Feature code MUST NOT make local color, border, rounding, or emphasis decisions for semantic UI states using ad-hoc classes such as `bg-danger-100`, `text-warning-900`, `border-dashed`, or `rounded-full` when the same state can be expressed through Filament props or shared primitives.
- `Filament Costume` is forbidden: locally assembled markup that merely
imitates native Filament controls, badges, or actions.
- `Blade Request UI` is forbidden: request-driven body state or GET-form
control rails as the primary interaction contract inside an active
Filament surface.
- `Hand-Rolled Simple Overview` is forbidden: bespoke overview/report
shells where a native table/list surface fits the job.
Shared primitive before local override
- If the same UI pattern can recur, it MUST use an existing shared primitive or introduce a new central primitive instead of reassembling the pattern inside a Blade view.
- Central badge and status catalogs remain the canonical source for status semantics; local views MUST consume them rather than re-map them.
- If the same custom detail, evidence, or review surface appears in
more than one host, it becomes a `Shared Detail Micro-UI` and MUST
define shared core vs host variation before another host reassembles
it locally.
Upgrade-safe preference
- Update-safe, framework-native implementations take priority over page-local styling shortcuts.
@ -1313,13 +1513,19 @@ ### Filament Native First / No Ad-hoc Styling (UI-FIL-001)
- native Filament components cannot express the required semantics,
- no suitable shared primitive exists,
- and the deviation is justified briefly in code and in the governing spec or PR.
- Approved exceptions MUST stay layout-neutral, use the minimum local classes necessary, and MUST NOT invent a new page-local status language.
- Approved exceptions MUST stay layout-neutral, use the minimum local
classes necessary, MUST NOT invent a new page-local status language,
and MUST say what remains standardized.
- `Hidden Exception` is forbidden. Historical accident or local
implementation convenience is not a valid substitute for UI-EX-001.
Review and enforcement
- Every UI review MUST answer:
- which native Filament element or shared primitive was used,
- why an existing component was insufficient if an exception was taken,
- and whether any ad-hoc status or emphasis styling was introduced.
- whether the surface is native, custom, or a shared detail family,
- and whether any ad-hoc status, emphasis styling, or fake-native
contract was introduced.
- UI work is not Done if it introduces ad-hoc status styling or framework-foreign replacement components where a native Filament or shared UI solution was viable.
### Incremental UI Standards Enforcement (UI-STD-001)
@ -1367,4 +1573,4 @@ ### Versioning Policy (SemVer)
- **MINOR**: new principle/section or materially expanded guidance.
- **MAJOR**: removing/redefining principles in a backward-incompatible way.
**Version**: 2.5.0 | **Ratified**: 2026-01-03 | **Last Amended**: 2026-04-18
**Version**: 2.6.0 | **Ratified**: 2026-01-03 | **Last Amended**: 2026-04-18

7
docs/ui/operator-ux-surface-standards.md
View File

@ -11,6 +11,11 @@ # Operator UX & Surface Standards
This document is normative for new operator-facing UI work and for major UI refactors.
It follows the constitution vocabulary for `Native Surface`, `Custom Surface`,
`Shared Detail Micro-UI`, and shell/page/detail state ownership. This
document complements the constitution and MUST NOT be used as a parallel
rulebook that redefines those terms.
## 1. Purpose
TenantPilot is not a generic admin UI. It is an enterprise operator product for managed Microsoft tenant governance, backup, restore, monitoring, drift detection, and review workflows.
@ -518,4 +523,4 @@ ## 16. Summary
- explicit mutation scope
- safe execution for dangerous actions
- explicit workspace / tenant context
- page-level audience and surface contracts
- page-level audience and surface contracts

175
specs/001-dashboard-recovery-honesty/spec.md
View File

@ -1,175 +0,0 @@
# Feature Specification: Dashboard Recovery Posture Honesty
**Feature Branch**: `[001-dashboard-recovery-honesty]`
**Created**: 2026-04-08
**Status**: Draft
**Input**: User description: "Spec 184 — Dashboard Recovery Posture Honesty"
## Spec Scope Fields *(mandatory)*
- **Scope**: tenant
- **Primary Routes**: `/admin/t/{tenant}`, `/admin/t/{tenant}/restore-runs`, `/admin/t/{tenant}/restore-runs/{record}`, `/admin/t/{tenant}/backup-sets`, `/admin/t/{tenant}/backup-sets/{record}`
- **Data Ownership**: Tenant-owned `BackupSet`, `RestoreRun`, and linked `OperationRun` outcome context are read within the active workspace and tenant scope to derive a more honest overview statement. No new persisted recovery-confidence state is introduced.
- **RBAC**: Workspace plus tenant membership remains required on every affected surface. Members who can open the tenant dashboard must see honest summary boundaries even when they cannot start or manage restore runs. Existing restore-run creation and mutation actions remain under current restore permissions. Non-members continue to receive deny-as-not-found semantics.
## 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 |
|---|---|---|---|---|---|---|---|---|---|---|---|
| Tenant dashboard KPI strip | Dashboard / stats overview | Explicit stat click per signal | forbidden | Supporting text inside the stat description | none | `/admin/t/{tenant}` | Signal-specific drill-through to `/admin/t/{tenant}/restore-runs` or `/admin/t/{tenant}/restore-runs/{record}` | Workspace context plus tenant context | Dashboard KPIs / Backup posture | Backup health is separate from restore evidence | existing widget pattern |
| Needs Attention / Healthy Checks panel | Dashboard / attention summary | Explicit card CTA per attention item; healthy state is read-only | forbidden | Card CTA and helper copy only | none | `/admin/t/{tenant}` | `/admin/t/{tenant}/restore-runs`, `/admin/t/{tenant}/restore-runs/{record}` | Workspace context plus tenant context | Needs attention / Healthy checks | Unknown and weakened recovery confidence are visible before drilldown | existing widget pattern |
| Restore runs page | CRUD / list-first resource | Full-row click to restore-run detail | required | Existing header action plus More menu | Existing More and bulk More groups | `/admin/t/{tenant}/restore-runs` | `/admin/t/{tenant}/restore-runs/{record}` | Tenant context plus restore-run identity | Restore runs / Restore run | Recent restore outcome and follow-up reason confirm the overview claim | none |
## 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 |
|---|---|---|---|---|---|---|---|---|---|
| Tenant dashboard KPI strip | Tenant operator | Dashboard summary | Do healthy backups also have supporting restore evidence, or is that still unknown? | Backup posture, recovery-confidence qualifier, visible claim boundary, next step | Per-run causes, raw backup metadata, deeper restore evidence | backup health, recovery evidence availability, recent restore attention | None; read-only summary | Open restore history, open supporting backup context when backup health itself needs follow-up | none |
| Needs Attention / Healthy Checks panel | Tenant operator | Dashboard attention and healthy-boundary surface | What recovery-confidence issue needs action now, and why? | No restore history, weakened recent restore history, boundary copy, concrete next action | Full restore results, preview or check details, low-level run metadata | backup health, recovery evidence availability, restore result attention, recency | None; read-only summary | Open restore history, open latest problematic restore run | none |
| Restore runs page | Tenant operator | List and detail | Which restore runs explain the dashboard signal? | Recent restore status, result-attention reason, completed timing, related backup context | Assignment-level failures, preview detail, low-level result payloads | execution lifecycle, result attention, follow-up state | Existing restore-run maintenance actions only | Inspect restore run, create restore run | Existing rerun, archive, restore archived, and force-delete actions |
## 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?**: no
- **Current operator problem**: A tenant dashboard can currently look calm or healthy even when restore history is absent or recent restore results weaken confidence, so operators can overread backup health as recovery posture.
- **Existing structure is insufficient because**: Backup health, restore history, and restore result attention already exist as separate truths, but the summary surfaces do not yet combine them with an honest claim boundary. Operators must manually cross-check multiple pages to avoid an overclaim.
- **Narrowest correct implementation**: Derive a small set of overview honesty signals from existing backup health assessment, restore history presence, and per-run restore result attention, then show them on the existing dashboard widgets and existing restore-run drilldowns.
- **Ownership cost**: Additional widget copy, narrow derived-summary logic, and focused feature plus RBAC regression tests that keep overview language and drilldown continuity aligned.
- **Alternative intentionally rejected**: A new recovery-confidence score, enum, page, or persisted posture state was rejected because it would introduce new truth and new ownership cost before the current overview surfaces tell the existing truth accurately.
- **Release truth**: current-release truth hardening
## User Scenarios & Testing *(mandatory)*
### User Story 1 - See Unvalidated Recovery Confidence Early (Priority: P1)
A tenant operator opens the tenant dashboard and needs to know within seconds whether healthy-looking backups are backed by any relevant restore evidence or whether recovery confidence is still unvalidated.
**Why this priority**: This is the highest-risk trust gap. If the first overview screen quietly converts healthy backups into a healthy recovery impression, later detail truth arrives too late.
**Independent Test**: Can be fully tested by rendering the tenant dashboard with healthy backup fixtures and no relevant restore history, then verifying that the overview shows an explicit unvalidated or unknown recovery-confidence signal instead of an all-clear.
**Acceptance Scenarios**:
1. **Given** a tenant has healthy backup posture and no relevant restore history, **When** the operator opens the tenant dashboard, **Then** the summary shows healthy backups plus an explicit unvalidated or unknown recovery-confidence message and a next action.
2. **Given** the same tenant has no other attention items, **When** the healthy-check state renders, **Then** the widget does not show an unqualified all-good message and instead keeps the recovery-confidence boundary visible.
---
### User Story 2 - Escalate Weak Restore History on Overview (Priority: P2)
A tenant operator reviewing the dashboard needs recent failed, partial, or follow-up restore results to affect the overview immediately instead of hiding inside restore history details.
**Why this priority**: Weak restore history is evidence that directly changes how much trust the operator should place in recovery posture. It cannot remain a drilldown-only fact.
**Independent Test**: Can be fully tested by rendering overview surfaces with recent failed, partial, and follow-up restore fixtures and verifying that each case creates a visible confidence-related attention signal with matching drilldown behavior.
**Acceptance Scenarios**:
1. **Given** a tenant has healthy backups but a recent failed or partial restore run, **When** the operator opens the dashboard, **Then** Needs Attention shows a recovery-confidence issue that links to restore history explaining the same failure state.
2. **Given** a tenant has a recent restore run that completed with follow-up required, **When** the operator opens the dashboard, **Then** the overview shows weakened confidence rather than a neutral or healthy-only message.
3. **Given** recent restore history exists without a current confidence-weakening attention state, **When** the operator opens the dashboard, **Then** the overview may say that no recent restore issues are visible but does not claim that recovery is proven.
---
### User Story 3 - Preserve Honest Drilldowns and RBAC Boundaries (Priority: P3)
A tenant operator or read-only member needs the dashboard signal and the destination surface to tell the same story, while RBAC limits must never make the summary look stronger than the accessible evidence.
**Why this priority**: Overview honesty fails if the next click contradicts the dashboard or if authorization gaps hide weakness by omission.
**Independent Test**: Can be fully tested by opening overview signals as different tenant members, verifying that the linked restore-history surface confirms the same reason, and ensuring restricted users still see cautious summary language.
**Acceptance Scenarios**:
1. **Given** the dashboard says recovery confidence is unvalidated because no relevant restore history exists, **When** the operator follows the dashboard action, **Then** the destination surface confirms that the tenant lacks relevant restore history.
2. **Given** the dashboard says recovery confidence is weakened by a recent problematic restore, **When** the operator follows the dashboard action, **Then** the destination surface confirms the same failed, partial, or follow-up reason.
3. **Given** a tenant member can see the dashboard but cannot open deeper restore evidence, **When** the dashboard renders, **Then** the summary remains cautious and truthful and does not replace missing evidence with a stronger claim.
### Edge Cases
- A tenant has only draft, preview-only, or dry-run restore history; the overview treats recovery confidence as unvalidated rather than positive.
- A tenant has both an older successful restore and a more recent failed or follow-up restore; the weakened signal takes precedence on the summary surface.
- A summary signal points to a restore run that is no longer directly openable; the drilldown falls back to tenant-scoped restore history rather than a dead end.
- A user can see the dashboard but lacks permission to inspect restore runs; the summary still states unknown or weakened confidence without suggesting that everything is healthy.
- Healthy backup posture and backup-automation follow-up can coexist with unvalidated recovery confidence; the overview must not let one healthy-sounding statement erase the other caution.
## Requirements *(mandatory)*
This feature introduces no new Microsoft Graph calls, no new background work, no new `OperationRun`, and no new persistence. It is a read-first truth-hardening slice that makes existing backup and restore evidence visible more honestly on tenant overview surfaces.
Authorization remains in the tenant/admin plane under `/admin/t/{tenant}/...`. Non-members must continue to receive 404 responses. Established members missing deeper restore capabilities must continue to receive 403 on execution paths, but summary visibility must not depend on restore-mutation rights.
This slice reuses existing Filament dashboard widgets, stat descriptions, attention cards, and existing restore-run resource surfaces. No new local badge framework, page-local status language, or extra action surface is introduced. UI-FIL-001 is satisfied by continuing to use existing Filament widget primitives and shared status language. UX-001 create, edit, and detail-form rules are not materially changed; the dashboard keeps its existing layout, and the restore-run resource keeps its existing list-and-view contract.
The affected Filament surfaces keep exactly one primary inspect or open model, add no redundant View actions, and introduce no new destructive actions. Existing destructive restore-run actions continue to follow the current placement and confirmation rules. Action Surface Contract expectations therefore remain satisfied.
Existing per-run restore result attention remains the authoritative signal for restore outcome quality. This feature may summarize or elevate that truth, but it must not duplicate it with a second scoring or status system.
### Functional Requirements
- **FR-184-001**: The system MUST present tenant backup health and tenant recovery-confidence evidence as separate truths on tenant dashboard summary surfaces.
- **FR-184-002**: When backup health is healthy but no relevant restore history exists, the system MUST display an explicit unknown or unvalidated recovery-confidence state and MUST NOT present an all-clear summary.
- **FR-184-003**: When the system cannot determine recovery confidence from the available restore history, the system MUST say that limitation directly instead of inferring a positive recovery claim from backup health alone.
- **FR-184-004**: Needs Attention or the healthy-boundary surface MUST surface absence of restore history as an overview-relevant condition with a clear next action.
- **FR-184-005**: Recent restore history with `failed`, `partial`, `completed_with_follow_up`, or an equivalent confidence-weakening attention state MUST appear on overview surfaces as a recovery-confidence issue.
- **FR-184-006**: Overview surfaces MUST distinguish unknown or unvalidated confidence from weakened confidence and MUST NOT collapse both states into one ambiguous bucket.
- **FR-184-007**: Any positive backup-health summary on the dashboard MUST show a visible claim boundary that healthy backups reflect backup inputs only and do not prove restore success.
- **FR-184-008**: Healthy checks MUST NOT render an unqualified healthy or all-clear state when recovery confidence is unknown, weakened, or not evaluated.
- **FR-184-009**: When recovery confidence is unknown or weakened, overview copy MUST explain what is missing or concerning, why that affects confidence, and what the operator should do next.
- **FR-184-010**: Overview signals about missing restore history MUST drill into a tenant-scoped restore-history surface that confirms the absence or insufficiency of relevant restore evidence.
- **FR-184-011**: Overview signals about weakened restore history MUST drill into a tenant-scoped restore-history surface or restore-run detail that confirms the same failed, partial, or follow-up reason shown on the summary surface.
- **FR-184-012**: The feature MUST reuse existing per-run restore result attention as the authoritative quality signal for restore outcomes and MUST NOT introduce a parallel positive-scoring or reason system.
- **FR-184-013**: The feature MUST NOT introduce a new state or message that claims recovery is proven, guaranteed, or strongly confirmed beyond the evidence the current system already has.
- **FR-184-014**: RBAC limits on restore history visibility MUST NOT cause summary surfaces to make stronger recovery claims than the visible evidence supports; when detailed restore evidence cannot be opened, the summary must remain cautious and truthful.
- **FR-184-015**: Tenant-linked summaries shown outside the tenant dashboard, if they reuse this posture signal, MUST preserve the same meaning for unknown, weakened, and backup-only-positive states.
- **FR-184-016**: The feature MUST derive its summary state from existing tenant backup health, restore history, and restore result attention records and MUST NOT add a new persisted recovery-confidence field, table, or scoring artifact.
- **FR-184-017**: When recent restore history exists without a current confidence-weakening attention state, overview surfaces MAY state that no recent restore issues are visible, but MUST stop short of claiming recovery proof.
## Assumptions
- Relevant restore history means tenant-scoped restore runs that have reached an executed result state or another existing result-attention state that the current system can classify. Draft-only, preview-only, or dry-run-only history does not count as proven recovery evidence.
- Existing restore history surfaces already show enough result detail to confirm failed, partial, and follow-up reasons once the operator drills down from the overview.
- Workspace-level surfaces that later reuse this posture language should consume the same tenant-level semantics rather than creating a separate recovery-confidence vocabulary.
## Dependencies
- Existing tenant dashboard surfaces remain the operator entry point for this slice.
- Existing `TenantBackupHealthAssessment` and `TenantBackupHealthResolver` remain the source of backup-input truth.
- Existing `RestoreRun` history surfaces and `RestoreSafetyResolver::resultAttentionForRun(...)` remain the source of restore-outcome truth.
- Existing RBAC helper-text and disabled-link patterns remain the fallback behavior when the operator cannot open deeper restore evidence.
## Out of Scope and Follow-up
- No new recovery-confidence engine, score, enum, or dedicated posture page.
- No automatic restore validation, scheduled restore probes, or restore execution changes.
- No new backup-health rules, restore-result-attention taxonomy changes, or restore-safety model redesign.
- No new claim that a tenant is recovery-proven.
- Reasonable follow-up work includes broader workspace-level recovery rollups after tenant-level overview honesty is stable.
## 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 |
|---|---|---|---|---|---|---|---|---|---|---|
| Tenant dashboard summary widgets | `app/Filament/Pages/TenantDashboard.php`, `app/Filament/Widgets/Dashboard/DashboardKpis.php`, `app/Filament/Widgets/Dashboard/NeedsAttention.php` | none added | Explicit stat and card CTA only; no row click | none | n/a | none | n/a | n/a | no new audit event | Action Surface Contract stays satisfied because the dashboard remains read-only. UI-FIL-001 stays satisfied through existing Filament widget primitives. UX-001 create and edit form rules are not applicable to this dashboard slice. |
| RestoreRunResource list and detail | `app/Filament/Resources/RestoreRunResource.php`, `app/Filament/Resources/RestoreRunResource/Pages/ListRestoreRuns.php`, `app/Filament/Resources/RestoreRunResource/Pages/ViewRestoreRun.php` | Existing `New restore run` action remains | `recordUrl()` clickable row to restore-run detail | Existing More-menu maintenance actions remain unchanged | Existing grouped bulk actions remain unchanged | Existing `New restore run` empty-state CTA remains | none added | Existing restore-run create flow remains unchanged | existing restore-run mutation audit behavior only | This spec reuses restore-run list and detail as canonical drilldowns and adds no new destructive action or placement exception. |
## Key Entities *(include if feature involves data)*
- **Backup health assessment**: Tenant-level summary of backup freshness and input health that is useful but not sufficient to prove recovery success.
- **Restore history**: Tenant-scoped record of restore runs whose presence, absence, and recent outcomes affect how strongly the product can speak about recovery confidence.
- **Restore result attention**: Per-run classification that distinguishes completed, failed, partial, follow-up, and not-executed outcome states that matter for operator trust.
- **Recovery posture summary**: Non-persisted dashboard statement that combines backup health, restore history presence, and restore-result attention without becoming a new score or stored state.
## Success Criteria *(mandatory)*
### Measurable Outcomes
- **SC-001**: In acceptance testing, operators can identify within 10 seconds whether a tenant has healthy backups plus unvalidated or weakened recovery evidence from `/admin/t/{tenant}` without opening raw details.
- **SC-002**: In 100% of tested tenants with no relevant restore history, the dashboard or healthy-boundary surface shows an explicit unvalidated or unknown recovery-confidence signal and never shows a healthy-only all-clear.
- **SC-003**: In 100% of tested tenants with recent failed, partial, or follow-up restore runs, the overview shows a confidence-related attention item with a drilldown that confirms the same reason.
- **SC-004**: In 100% of tested positive backup-health scenarios, summary-level copy includes the claim boundary that healthy backups do not prove restore success.
- **SC-005**: In 100% of tested RBAC-restricted scenarios, summary surfaces remain cautious and truthful even when the user cannot open deeper restore evidence pages.

126
specs/001-finding-risk-acceptance/plan.md
View File

@ -1,126 +0,0 @@
# Implementation Plan: Finding Risk Acceptance Lifecycle
**Branch**: `001-finding-risk-acceptance` | **Date**: 2026-03-19 | **Spec**: [/Users/ahmeddarrazi/Documents/projects/TenantAtlas/specs/001-finding-risk-acceptance/spec.md](/Users/ahmeddarrazi/Documents/projects/TenantAtlas/specs/001-finding-risk-acceptance/spec.md)
**Input**: Feature specification from `/specs/001-finding-risk-acceptance/spec.md`
**Note**: This template is filled in by the `/speckit.plan` command. See `.specify/scripts/` for helper scripts.
## Summary
Introduce a first-class tenant-owned Finding Exception domain that governs formal risk acceptance for findings instead of relying on a bare `risk_accepted` status and freeform reason field. The implementation adds dedicated exception and exception-decision records, tenant-scoped request and detail surfaces, a canonical workspace approval queue, centralized validity semantics, audit coverage for every lifecycle mutation, and explicit downstream contracts so evidence and reporting flows can distinguish valid governed exceptions from expired, revoked, rejected, or missing ones.
The implementation keeps Findings as the system of record for the underlying issue, uses the existing `FindingWorkflowService` as the only path that can transition a finding into or out of `risk_accepted`, stores governance history in append-only decision records, and uses DB-backed tenant/workspace queries rather than a new `OperationRun` workflow for normal approval actions.
## Technical Context
**Language/Version**: PHP 8.4.15
**Primary Dependencies**: Laravel 12, Filament v5, Livewire v4, Pest v4, existing Finding, AuditLog, EvidenceSnapshot, CapabilityResolver, WorkspaceCapabilityResolver, and UiEnforcement patterns
**Storage**: PostgreSQL with new tenant-owned exception tables and JSONB-backed supporting metadata
**Testing**: Pest feature tests, Pest unit tests, and Livewire/Filament component tests
**Target Platform**: Laravel Sail web application on PostgreSQL
**Project Type**: Web application monolith
**Performance Goals**: Exception request, approval, rejection, renewal, and revocation remain synchronous DB-backed actions under 2 seconds; tenant and canonical exception lists remain DB-only at render time; expiring queue filters remain index-backed
**Constraints**: No Microsoft Graph calls; no new public API; one current valid active exception per finding at a time; approval history must remain append-only; normal workflow stays outside `OperationRun`; status-like UI uses centralized badge semantics
**Scale/Scope**: First rollout covers finding-specific exceptions only, tenant detail plus workspace approval queue, linked evidence references, validity-state evaluation, and downstream reuse by evidence/reporting consumers
## Constitution Check
*GATE: Must pass before Phase 0 research. Re-check after Phase 1 design.*
- **Pre-Phase-0 Gate: PASS**
- Inventory-first: PASS. The feature governs findings and linked evidence already present in the product; it does not recollect or redefine source inventory.
- Read/write separation: PASS. Exception request, approval, rejection, renewal, and revocation are explicit governance writes with confirmation, audit coverage, and focused tests.
- Graph contract path: PASS. No Graph calls are introduced.
- Deterministic capabilities: PASS. New capabilities are added to the canonical registry and role maps and tested through existing capability resolver patterns.
- RBAC-UX / workspace / tenant isolation: PASS. Tenant exception records stay tenant-owned; the canonical workspace queue is query-only and entitlement-filtered; non-members remain 404 and in-scope capability denials remain 403.
- Global search: PASS. The first rollout does not require global-search exposure for exception records.
- Run observability: PASS with explicit exemption. Normal exception decisions are DB-only and expected to complete under 2 seconds, so they intentionally skip `OperationRun` and rely on audit history and surface state changes. No remote or long-running work is introduced.
- Ops-UX 3-surface feedback: PASS by non-applicability. No new `OperationRun`-driven operator workflow is introduced in v1.
- Ops-UX lifecycle / summary counts / system runs: PASS by non-applicability for the core decision paths.
- Data minimization: PASS. Exception records store bounded justification, structured evidence references, and sanitized audit context; no raw payloads or secrets are persisted.
- BADGE-001: PASS. New exception-state and validity-state badges are introduced via centralized badge domain entries and covered by tests.
- UI-NAMING-001: PASS. Operator-facing vocabulary remains `Request exception`, `Approve exception`, `Reject exception`, `Renew exception`, and `Revoke exception` with `risk acceptance` used for the governed outcome.
- Filament UI Action Surface Contract: PASS. Tenant finding detail, tenant exception register, canonical approval queue, and exception detail all use explicit inspection affordances, grouped actions, and confirmed destructive-like mutations.
- Filament UI UX-001: PASS. Detail surfaces are inspection-first Infolists; list surfaces expose search, sort, and filters; exception request and renewal use structured sections in modals or dedicated forms.
**Post-Phase-1 Re-check: PASS**
- The design keeps Findings as the underlying domain record, adds a tenant-owned governance layer without cross-tenant duplication, routes all status mutations through the existing workflow service, avoids unnecessary `OperationRun` usage, and preserves audit-first history for every decision path.
## Project Structure
### Documentation (this feature)
```text
specs/001-finding-risk-acceptance/
├── plan.md # This file (/speckit.plan command output)
├── research.md # Phase 0 output (/speckit.plan command)
├── data-model.md # Phase 1 output (/speckit.plan command)
├── quickstart.md # Phase 1 output (/speckit.plan command)
├── contracts/ # Phase 1 output (/speckit.plan command)
└── tasks.md # Phase 2 output (/speckit.tasks command - NOT created by /speckit.plan)
```
### Source Code (repository root)
```text
app/
├── Filament/
│ ├── Pages/
│ │ └── Monitoring/
│ └── Resources/
├── Models/
├── Policies/
├── Services/
│ ├── Audit/
│ ├── Auth/
│ ├── Evidence/
│ └── Findings/
└── Support/
├── Audit/
├── Auth/
├── Badges/
└── Rbac/
database/
└── migrations/
tests/
├── Feature/
│ ├── Findings/
│ ├── Monitoring/
│ └── Guards/
└── Unit/
├── Findings/
└── Support/
```
**Structure Decision**: Keep the existing Laravel monolith structure. Add new exception models and decision-history tables under `app/Models`, lifecycle orchestration under `app/Services/Findings`, authorization under `app/Policies`, and tenant/canonical Filament surfaces under `app/Filament`. Persist schema in `database/migrations` and cover behavior with focused Pest feature/unit tests in existing Findings, Monitoring, and guard suites.
## Complexity Tracking
> **Fill ONLY if Constitution Check has violations that must be justified**
| Violation | Why Needed | Simpler Alternative Rejected Because |
|-----------|------------|-------------------------------------|
## Phase 0 — Research Output
- [research.md](/Users/ahmeddarrazi/Documents/projects/TenantAtlas/specs/001-finding-risk-acceptance/research.md)
## Phase 1 — Design Output
- [data-model.md](/Users/ahmeddarrazi/Documents/projects/TenantAtlas/specs/001-finding-risk-acceptance/data-model.md)
- [quickstart.md](/Users/ahmeddarrazi/Documents/projects/TenantAtlas/specs/001-finding-risk-acceptance/quickstart.md)
- [contracts/finding-risk-acceptance.openapi.yaml](/Users/ahmeddarrazi/Documents/projects/TenantAtlas/specs/001-finding-risk-acceptance/contracts/finding-risk-acceptance.openapi.yaml)
## Phase 2 — Implementation Planning
`tasks.md` should cover:
1. Schema creation for `finding_exceptions` and `finding_exception_decisions` with tenant/workspace ownership constraints, validity indexes, and evidence-reference metadata.
2. Capability registry and role-map updates for `finding_exception.view`, `finding_exception.manage`, and `finding_exception.approve` plus authorization policies for tenant and canonical views.
3. Service-layer orchestration that routes all accepted-risk status mutations through a new exception lifecycle service plus the existing `FindingWorkflowService`.
4. Filament tenant finding-detail, tenant exception register, canonical approval queue, and exception detail surfaces aligned with Action Surface and UX-001 rules.
5. Audit-log integration, badge-domain additions, and canonical related-navigation support.
6. Downstream validity-resolution hooks for evidence and reporting consumers that must distinguish valid governed exceptions from expired, revoked, rejected, or missing ones.
7. Focused Pest coverage for positive and negative authorization, invalid transitions, renewal/revocation history, wrong-tenant behavior, and canonical queue filtering.
| [e.g., 4th project] | [current need] | [why 3 projects insufficient] |
| [e.g., Repository pattern] | [specific problem] | [why direct DB access insufficient] |

203
specs/001-finding-risk-acceptance/spec.md
View File

@ -1,203 +0,0 @@
# Feature Specification: Finding Risk Acceptance Lifecycle
**Feature Branch**: `001-finding-risk-acceptance`
**Created**: 2026-03-19
**Status**: Draft
**Input**: User description: "Create a formal exception and risk acceptance workflow for findings with approval, expiry, renewal, audit trail, and evidence linkage."
## Spec Scope Fields *(mandatory)*
- **Scope**: tenant + canonical-view
- **Primary Routes**:
- `/admin/t/{tenant}/findings/{finding}` as the tenant-context finding inspection surface where operators can review and initiate risk-acceptance requests
- `/admin/t/{tenant}/exceptions` as the tenant-scoped exception register for active, pending, expiring, expired, rejected, and revoked finding exceptions
- `/admin/exceptions` as the canonical workspace review and governance queue for authorized approvers and auditors
- Existing evidence and audit destinations remain drill-down targets from exception detail when the operator is entitled to inspect them
- **Data Ownership**:
- Tenant-owned: finding exception records, approval decisions, renewal decisions, expiry state, revocation state, and linked evidence references for one tenant's findings
- Workspace-owned but tenant-filtered: canonical review queue state, approval workload filters, and workspace-level summaries for expiring or overdue exceptions without changing tenant ownership of the exception itself
- Existing findings, evidence snapshots, review packs, and audit events remain separate systems of record and are referenced rather than duplicated
- **RBAC**:
- Workspace membership remains required for every exception workflow surface
- Tenant entitlement remains required to inspect or mutate tenant-scoped exception records
- `finding_exception.view` permits reviewing exception details within authorized scope
- `finding_exception.manage` permits creating requests, renewing requests, attaching justification and evidence references, and revoking exceptions where policy allows
- `finding_exception.approve` permits approving or rejecting requests and renewals within authorized scope
- Non-members or users outside the relevant workspace or tenant scope remain deny-as-not-found, while in-scope members lacking the required capability remain forbidden
For canonical-view specs, the spec MUST define:
- **Default filter behavior when tenant-context is active**: When an operator navigates from a tenant finding into the shared exceptions queue, the canonical workspace view opens with that tenant prefiltered. The operator may clear or change the filter only within their authorized tenant set.
- **Explicit entitlement checks preventing cross-tenant leakage**: Exception queries, counts, approver queues, filter options, related finding labels, and linked evidence references must be assembled only after workspace and tenant entitlement checks. Unauthorized users must not learn whether another tenant has pending, active, expiring, or expired exceptions.
## User Scenarios & Testing *(mandatory)*
### User Story 1 - Propose and approve a time-bounded risk acceptance (Priority: P1)
As a tenant manager, I want to request a formal risk acceptance for a finding and route it for approval, so that a risk decision becomes explicit, reviewable, and time-bounded instead of being hidden behind a status flag.
**Why this priority**: This is the core governance gap. Without a first-class request and approval flow, the product still cannot answer who accepted a risk, why, and until when.
**Independent Test**: Can be fully tested by creating a finding, submitting a risk-acceptance request with justification and review date, approving it as an authorized approver, and verifying that the finding becomes governed by a valid active exception.
**Acceptance Scenarios**:
1. **Given** a finding is open and no active exception exists, **When** an authorized operator submits a risk-acceptance request with justification, owner, and review deadline, **Then** the system creates a pending exception request linked to that finding.
2. **Given** a pending exception request exists, **When** an authorized approver approves it, **Then** the exception becomes active with a recorded approver, decision time, and expiry date.
3. **Given** a pending exception request exists, **When** an authorized approver rejects it, **Then** the request records the rejection outcome and reason without changing the finding into an accepted-risk state.
4. **Given** a user lacks the relevant capability or tenant entitlement, **When** they attempt to create or approve an exception request, **Then** the server denies the action with the correct 404 or 403 behavior.
---
### User Story 2 - See whether accepted risk is still valid (Priority: P1)
As an auditor or workspace approver, I want a clear register of pending, active, expiring, expired, rejected, and revoked exceptions, so that I can tell which accepted risks are still valid and which require action.
**Why this priority**: A risk-acceptance workflow is only governable if operators can review its current state without reconstructing history from comments and status changes.
**Independent Test**: Can be fully tested by creating exception records in several lifecycle states and verifying that tenant and canonical views expose the correct state, dates, owners, and next-action cues without leaking unauthorized tenant data.
**Acceptance Scenarios**:
1. **Given** a tenant has pending, active, and expired exceptions, **When** an authorized operator opens the tenant exception register, **Then** each exception clearly shows its lifecycle state, finding, owner, approver context, and review timing.
2. **Given** an approver is responsible for multiple tenants, **When** they open the canonical exceptions queue, **Then** they can filter by tenant, state, and due timing without seeing unauthorized tenants.
3. **Given** an active exception is nearing expiry, **When** an authorized operator inspects the register, **Then** the exception is visibly distinguished from long-valid exceptions.
4. **Given** no exception matches the current filters, **When** the operator opens the register, **Then** the empty state explains that no governed exceptions match and offers exactly one clear next action.
---
### User Story 3 - Renew or revoke an accepted risk with audit evidence (Priority: P2)
As a governance operator, I want to renew or revoke an existing accepted risk with a durable decision trail and linked evidence, so that exceptions stay current rather than becoming permanent silent waivers.
**Why this priority**: Time-bounded approval loses value if the product cannot handle renewal and revocation as first-class governance decisions.
**Independent Test**: Can be fully tested by renewing an active exception with new justification and evidence references, revoking another one, and verifying that lifecycle history, current validity, and audit trail remain intelligible.
**Acceptance Scenarios**:
1. **Given** an active exception is approaching expiry, **When** an authorized operator submits a renewal request with updated justification and supporting evidence references, **Then** the system records a new renewal decision path without rewriting the earlier decision.
2. **Given** a renewal request exists, **When** an authorized approver approves it, **Then** the active-validity window extends and the prior decision history remains visible.
3. **Given** an active exception is no longer acceptable, **When** an authorized operator revokes it with a reason, **Then** the exception becomes revoked and no longer counts as valid risk acceptance.
4. **Given** a linked evidence snapshot or supporting artifact later disappears from active views, **When** an operator reviews the exception history, **Then** the exception remains understandable from stored reference metadata.
---
### User Story 4 - Detect governance drift in accepted-risk findings (Priority: P2)
As a compliance-focused operator, I want the system to surface findings marked as accepted risk without a currently valid exception, so that governance drift is visible instead of silently undermining auditability.
**Why this priority**: The business risk is not just missing workflow. It is false confidence when a finding looks accepted even though its approval expired, was revoked, or never existed.
**Independent Test**: Can be fully tested by creating findings in accepted-risk status with valid, expired, revoked, and missing exception records and verifying that only truly valid exceptions count as accepted governance state.
**Acceptance Scenarios**:
1. **Given** a finding is marked as accepted risk and has a valid active exception, **When** the operator inspects it, **Then** the finding shows that the acceptance is governed and time-bounded.
2. **Given** a finding is marked as accepted risk but the linked exception is expired, revoked, or absent, **When** the operator inspects it or opens the exception queue, **Then** the system surfaces it as a governance warning rather than a valid accepted risk.
3. **Given** a downstream review or evidence workflow summarizes accepted risks, **When** it evaluates findings, **Then** only findings backed by a currently valid exception count as active risk acceptance.
### Edge Cases
- A finding is resolved or closed while an exception request is still pending; the request must not silently convert into an active accepted risk without an explicit decision.
- A finding remains in `risk_accepted` status after the governing exception expires or is revoked; the system must show that the risk state is no longer valid.
- An operator attempts to renew an exception that is already expired; the renewal path must remain explicit and must not overwrite the expired decision history.
- The same person requests and approves an exception; the system must either block self-approval in normal flow or record an explicit elevated-policy override when self-approval is allowed.
- A finding reopens through detection recurrence while a previous exception exists; the system must make it clear whether the earlier exception still governs the re-opened risk or whether a fresh decision is required.
- Evidence linked to an exception may be partial, stale, or later removed from active surfaces; the exception history must preserve enough reference context for review.
- A workspace approver can review multiple tenants, but must not see queue counts, labels, or filter values for unauthorized tenants.
## Requirements *(mandatory)*
**Constitution alignment (required):** This feature introduces a new governance data model and new user-driven write behavior, but no new Microsoft Graph calls. Exception request, approval, renewal, rejection, expiry, and revocation are security-relevant DB-backed governance mutations and must be explicitly audited. The feature must define tenant isolation, approval safety, validity semantics, linked-evidence semantics, and tests for valid, expired, revoked, missing, and unauthorized paths. If scheduled reminder or expiry evaluation is introduced, it must describe how that work is observable and how it avoids cross-tenant leakage.
**Constitution alignment (OPS-UX):** The primary workflow is synchronous governance mutation and does not require a dedicated long-running `OperationRun` for request, approval, rejection, renewal, or revocation. These decisions must therefore be observable through audit history, surface state changes, and user notifications instead of an operation progress surface. If the product later adds scheduled reminder or expiry evaluation, that work may integrate with existing monitoring or alerting patterns, but the first release of this feature does not rely on a new operator-facing progress workflow.
**Constitution alignment (RBAC-UX):** This feature operates in the tenant/admin plane for tenant-scoped finding and exception surfaces and in the workspace-admin canonical view for the approval queue. Cross-plane access remains deny-as-not-found. Non-members or users outside workspace or tenant scope receive `404`. In-scope users lacking `finding_exception.view`, `finding_exception.manage`, or `finding_exception.approve` receive `403` according to the attempted action. Authorization must be enforced server-side for request creation, approval, rejection, renewal, revocation, and any canonical queue action. The canonical capability registry remains the only capability source. Destructive-like actions such as revoke and reject require confirmation.
**Constitution alignment (OPS-EX-AUTH-001):** Not applicable. No authentication handshake behavior is changed.
**Constitution alignment (BADGE-001):** Exception lifecycle state, risk-governance validity, and due-timing indicators are status-like values and must use centralized badge semantics rather than per-page color choices. Tests must cover all introduced states such as pending, active, expiring, expired, rejected, and revoked.
**Constitution alignment (UI-NAMING-001):** The target object is the finding exception. Operator-facing verbs are `Request exception`, `Approve exception`, `Reject exception`, `Renew exception`, and `Revoke exception`. The term `risk acceptance` describes the governance outcome, while `exception` names the governed record. The same vocabulary must be preserved across finding detail, exception register, approval queue, audit prose, and notifications. Implementation-first terms such as `waiver row`, `approval token`, or `state machine` must not become primary labels.
**Constitution alignment (Filament Action Surfaces):** This feature modifies tenant finding detail and introduces exception list and detail inspection surfaces plus approval actions. The Action Surface Contract is satisfied if request and review actions are explicit, destructive-like actions require confirmation, list inspection uses a canonical inspect affordance, and every mutation is authorization-gated and audited.
**Constitution alignment (UX-001 — Layout & Information Architecture):** Exception list screens must provide search, sort, and filters for state, tenant, owner, approver, and expiry timing. Exception detail must be an inspection surface using Infolist-style composition rather than a disabled edit form. Creation and renewal may use a structured modal or dedicated form surface, but must keep justification, owner, timing, and evidence references grouped inside sections. Empty states must include a specific title, explanation, and exactly one CTA.
### Functional Requirements
- **FR-001**: The system MUST provide a first-class finding exception record that governs formal risk acceptance for a specific finding.
- **FR-002**: A finding exception MUST capture at minimum the target finding, requester, accountable owner, requested justification, requested decision time, and the bounded validity window for accepted risk.
- **FR-003**: The system MUST support an exception lifecycle that distinguishes at least pending, active, expiring, expired, rejected, revoked, and superseded or renewed states.
- **FR-004**: An operator MUST be able to request risk acceptance for a finding without directly bypassing the approval lifecycle.
- **FR-005**: The system MUST support explicit approval and explicit rejection of pending exception requests, with durable decision reason and actor history.
- **FR-006**: The system MUST support renewal of an existing exception as a new governance decision that preserves earlier request and approval history.
- **FR-007**: The system MUST support explicit revocation of an active exception, with recorded actor, time, and revocation reason.
- **FR-008**: The system MUST treat a finding as having valid accepted risk only while a currently valid active exception exists for that finding.
- **FR-009**: A finding in `risk_accepted` status without a currently valid exception MUST be surfaced as a governance warning rather than a fully governed accepted risk.
- **FR-010**: The feature MUST define whether one finding may have multiple historical exception records over time, while ensuring that only one current exception can govern the finding for a given validity window.
- **FR-011**: Exception requests and renewals MUST support structured supporting context, including freeform justification and one or more linked evidence references when available.
- **FR-012**: Evidence references linked to an exception MUST remain intelligible even if the live evidence artifact later expires, is superseded, or becomes inaccessible from normal active views.
- **FR-013**: The system MUST provide a tenant-scoped exception register that allows authorized operators to review current and historical exception records for that tenant.
- **FR-014**: The system MUST provide a canonical workspace approval and governance queue that allows authorized viewers to review pending, expiring, expired, rejected, and revoked exceptions across entitled tenants.
- **FR-015**: Tenant and canonical views MUST provide filters for lifecycle state, due timing, requester, owner, approver, and finding severity or type where relevant.
- **FR-016**: The system MUST make upcoming expiry and already-expired exceptions clearly visible so that time-bounded risk acceptance does not silently lapse.
- **FR-017**: The system MUST define reminder semantics for exceptions nearing expiry, including who needs visibility when action is required.
- **FR-018**: All exception lifecycle mutations must be recorded in audit history with workspace scope, tenant scope, actor, target finding context, action, outcome, and readable supporting context.
- **FR-019**: Exception audit records MUST be summary-first and MUST NOT store secrets, raw evidence payloads, or arbitrary oversized snapshots.
- **FR-020**: The system MUST enforce 404 deny-as-not-found behavior for non-members and out-of-scope users, and 403 behavior for in-scope users lacking the required capability.
- **FR-021**: The feature MUST define approval separation rules, including whether normal self-approval is blocked and how any exceptional override path is governed and auditable.
- **FR-022**: The feature MUST preserve intelligible history when a finding later resolves, closes, reopens, or changes severity after an exception decision.
- **FR-023**: Downstream review, evidence, and reporting workflows that summarize accepted risk MUST distinguish valid governed exceptions from expired, revoked, rejected, or missing ones.
- **FR-024**: The feature MUST introduce at least one positive and one negative authorization test for tenant-context request flows and canonical approval-queue flows.
- **FR-025**: The feature MUST introduce regression tests for pending, approved, rejected, renewed, revoked, expired, and missing-exception states, plus wrong-tenant and invalid-transition paths.
## 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 Detail Risk Panel | Tenant-context finding inspection under `/admin/t/{tenant}/findings/{finding}` | `Request exception` (`finding_exception.manage`) when no valid exception exists | Linked exception summary card or explicit `View exception` affordance | `View exception`, `Request exception` or `Renew exception` depending on state | None | `Request first exception` when no governance record exists | `Renew exception`, `Revoke exception` when authorized | N/A | Yes | Action labels must describe the governance object, not just the finding status |
| Tenant Exception Register | Tenant-context list under `/admin/t/{tenant}/exceptions` | Contextual filters only | Clickable row to exception detail | `View exception`, `Renew exception` or `Revoke exception` depending on state | None in v1 | `Request first exception` | None | N/A | Yes | Inspection-first surface; no bulk approval in first slice |
| Canonical Exceptions Queue | Workspace canonical view at `/admin/exceptions` | Contextual filters only | Clickable row to exception detail | `Approve exception`, `Reject exception` for pending items | None in v1 | `Clear filters` | None | N/A | Yes | Queue must remain tenant-safe and only show entitled tenants |
| Exception Detail | Tenant or canonical detail inspection surface | None | N/A | None | None | N/A | `Approve exception`, `Reject exception`, `Renew exception`, `Revoke exception` depending on state and capability | N/A | Yes | Detail is an inspection surface, not a disabled edit form |
### Key Entities *(include if feature involves data)*
- **Finding Exception**: A governed risk-acceptance record for one finding, including request context, decision state, validity timing, and current governance outcome.
- **Exception Decision**: A durable approval, rejection, renewal, or revocation record that explains who made the decision, when, and why.
- **Exception Evidence Reference**: A structured pointer to supporting evidence used to justify or review an exception, preserved as intelligible reference metadata.
- **Risk Governance Validity**: The normalized truth of whether a finding's accepted-risk posture is currently valid, expiring soon, expired, revoked, rejected, or unsupported.
## Success Criteria *(mandatory)*
### Measurable Outcomes
- **SC-001**: An authorized operator can request and route a formal finding exception in under 3 minutes without leaving the product.
- **SC-002**: In automated tests, 100% of findings counted as valid accepted risk are backed by a currently valid active exception.
- **SC-003**: In acceptance review, an authorized auditor can answer who requested, who approved, why it was accepted, and until when it remains valid within 2 minutes using the product alone.
- **SC-004**: Expired, revoked, rejected, and missing-governance accepted-risk states are all distinguishable in automated regression coverage with no false classification as valid active acceptance.
- **SC-005**: Negative authorization tests prove that non-members or wrong-tenant users receive deny-as-not-found behavior and in-scope users without the required capability cannot request, approve, renew, or revoke exceptions.
- **SC-006**: Renewal and revocation flows preserve prior decision history in automated tests rather than overwriting the previous governance record.
## Assumptions
- Spec 111 remains the product source of truth for finding lifecycle and status semantics, including the existing `risk_accepted` status.
- Spec 134 remains the source of truth for canonical audit readability and event history behavior.
- Evidence linkage may reference evidence snapshots, review artifacts, or other governance evidence when available, but the exception lifecycle must not be blocked merely because evidence is partial.
- Normal approval flow should not rely on silent self-approval; any permitted override path must be explicit and auditable.
- The first rollout focuses on finding-specific exceptions, not a generic cross-domain waiver engine.
## Non-Goals
- Replacing the existing findings workflow with a different status model
- Creating a generic exception platform for every future domain in the first slice
- Suppressing or deleting findings automatically when risk is accepted
- Making legal or certification claims about compliance acceptance
- Replacing evidence snapshots, review packs, or the broader audit foundation with exception-owned storage
## Dependencies
- Findings workflow semantics and lifecycle rules from `specs/111-findings-workflow-sla/spec.md`
- Audit history foundation and event readability rules from `specs/134-audit-log-foundation/spec.md`
- Evidence-domain linkage patterns from `specs/153-evidence-domain-foundation/spec.md` when evidence snapshots are available

170
specs/001-tenant-review-layer/spec.md
View File

@ -1,170 +0,0 @@
# Feature Specification: Tenant Review Layer
**Feature Branch**: `001-tenant-review-layer`
**Created**: 2026-03-20
**Status**: Draft
**Input**: User description: "Executive Review Packs / Tenant Review Layer"
## Spec Scope Fields *(mandatory)*
- **Scope**: workspace + tenant + canonical-view
- **Primary Routes**:
- `/admin/t/{tenant}/reviews` as the tenant-scoped review library and entry point for recurring review preparation
- `/admin/t/{tenant}/reviews/{review}` as the canonical tenant review inspection surface
- `/admin/reviews` as the workspace-scoped canonical review register for entitled operators who manage recurring reviews across multiple tenants
- Existing evidence, findings, baseline, and permissions surfaces remain linked drill-down destinations from the review detail when the operator is entitled to inspect them
- **Data Ownership**:
- Tenant-owned: tenant review records, review composition metadata, review lifecycle state, executive summary content, and stakeholder-facing review-pack references for one tenant
- Tenant-owned inputs: evidence snapshots, accepted-risk summaries, findings summaries, baseline or drift posture, permission posture, and operational health summaries that are consumed but not re-owned by the review layer
- Workspace-owned but tenant-filtered: canonical review library filters, review schedule summaries, and cross-tenant list presentation state without changing tenant ownership of the review itself
- Compliance or framework readiness interpretations remain outside this feature and are not stored as first-class review truth in this slice
- **RBAC**:
- Workspace membership remains required for every review surface
- Tenant entitlement remains required to inspect or mutate tenant-scoped review records
- `tenant_review.view` permits listing and inspecting reviews within authorized scope
- `tenant_review.manage` permits creating, refreshing, publishing, archiving, and exporting review packs within authorized scope
- Non-members or users outside the relevant workspace or tenant scope remain deny-as-not-found, while in-scope members lacking the required capability remain forbidden
For canonical-view specs, the spec MUST define:
- **Default filter behavior when tenant-context is active**: When an operator navigates from a tenant into the shared review register, the canonical workspace view opens prefiltered to that tenant. The operator may clear or change the filter only within their authorized tenant set.
- **Explicit entitlement checks preventing cross-tenant leakage**: Review queries, counts, tenant labels, filter options, executive summaries, and exported review-pack references must be assembled only after workspace and tenant entitlement checks. Unauthorized users must not learn whether another tenant has review history, stakeholder packs, or upcoming review work.
## User Scenarios & Testing *(mandatory)*
### User Story 1 - Prepare one tenant review from curated evidence (Priority: P1)
As a governance operator, I want to create a tenant review from an evidence snapshot and related governance signals, so that quarterly or ad hoc tenant reviews start from one stable, curated review record instead of manual page-by-page assembly.
**Why this priority**: This is the core product workflow. Without a first-class tenant review record, executive review packs are still ad hoc exports rather than a repeatable review motion.
**Independent Test**: Can be fully tested by selecting an eligible tenant evidence snapshot, creating a tenant review, and verifying that the resulting review preserves the chosen evidence basis, key governance sections, and summary state even if live source data changes later.
**Acceptance Scenarios**:
1. **Given** a tenant has at least one eligible evidence snapshot, findings summary, and posture inputs, **When** an authorized operator creates a tenant review, **Then** the system creates one review record that captures the selected evidence basis and generated review sections for that tenant.
2. **Given** a tenant review has been created from a specific evidence snapshot, **When** live findings or posture data later change, **Then** the existing review remains tied to its original evidence basis until the operator explicitly refreshes or creates a new review.
3. **Given** the chosen evidence basis is partial, **When** the operator creates the review, **Then** the review clearly records which sections are complete, partial, or unavailable rather than implying a fully complete review.
---
### User Story 2 - Present an executive-ready tenant review pack (Priority: P1)
As an MSP account manager or governance lead, I want a concise executive review surface and exportable review pack for one tenant, so that I can lead customer or management conversations with a stakeholder-ready output rather than raw operational artifacts.
**Why this priority**: This is the commercial value layer. The product stops being only an operator console when it can produce a readable, stakeholder-facing review output.
**Independent Test**: Can be fully tested by opening a prepared tenant review, confirming that it presents executive summary sections and drill-down links coherently, and generating a stakeholder-ready review pack from that review without rebuilding the evidence manually.
**Acceptance Scenarios**:
1. **Given** an authorized operator opens a prepared tenant review, **When** the review detail loads, **Then** it shows an executive summary, key risks, accepted-risk summary, posture highlights, and recommended next actions in one coherent inspection surface.
2. **Given** a tenant review is ready for stakeholder delivery, **When** the operator publishes or exports the executive review pack, **Then** the pack is generated from that review record and reflects the same section ordering and summary truth shown in the product.
3. **Given** a stakeholder-facing review pack omits one or more dimensions because the underlying evidence was partial, **When** the operator inspects or exports it, **Then** the omission is explained clearly instead of being silently hidden.
---
### User Story 3 - Manage recurring tenant reviews over time (Priority: P2)
As a workspace operator, I want a canonical review library across the tenants I manage, so that I can see which tenants were reviewed, which reviews are draft or published, and which tenants need the next review cycle.
**Why this priority**: Once the first tenant review exists, the product needs a repeatable operating model rather than one-off packs. This enables recurring review discipline and prepares the ground for the later portfolio dashboard.
**Independent Test**: Can be fully tested by creating reviews for multiple tenants, opening the workspace review register, and verifying that the register shows only entitled tenants with correct lifecycle, publish status, and recency signals.
**Acceptance Scenarios**:
1. **Given** an operator is entitled to multiple tenants with review history, **When** they open the workspace review register, **Then** they can filter by tenant, review state, publish status, and review date without seeing unauthorized tenant rows.
2. **Given** a tenant already has a published review, **When** the operator starts the next review cycle, **Then** the system creates a new draft review instead of mutating the historical published review.
3. **Given** no review matches the current filters, **When** the operator opens the canonical review register, **Then** the empty state explains that no review records match and offers exactly one clear next action.
### Edge Cases
- A tenant has eligible evidence snapshots but no valid accepted-risk records; the review must still generate and explicitly show that no governed accepted risks are currently active.
- A previously published review pack is revisited after the underlying evidence snapshot expires or is superseded; the historical review must remain intelligible from stored review metadata.
- A tenant has multiple evidence snapshots available; the operator must choose which one anchors the review rather than the system silently picking a different basis.
- An operator tries to publish or export a review that is still missing required summary sections; the product must fail with a clear readiness reason instead of producing a misleading finished pack.
- A workspace operator is entitled to some, but not all, tenants in a workspace; the canonical review register must suppress unauthorized tenant labels, counts, and filter values.
- A tenant review is created twice from the same evidence basis without meaningful changes; the system must prevent accidental duplicate published reviews while still allowing a deliberate new draft when needed.
## Requirements *(mandatory)*
**Constitution alignment (required):** This feature introduces a new review-domain data model, user-driven write behavior, and optional long-running generation work for stakeholder-facing review packs, but it does not introduce new Microsoft Graph collection. It must describe the review contract with evidence snapshots, explicit publish/export safety gates, tenant isolation, run observability for any generated pack artifact, and tests. Security-relevant DB-only review lifecycle changes such as publish, archive, and unpublish equivalents must always emit audit history.
**Constitution alignment (OPS-UX):** If review-pack generation is asynchronous, this feature creates or reuses a dedicated `OperationRun` family for tenant review pack generation and must comply with the Ops-UX 3-surface feedback contract. Start actions may show intent-only feedback. Progress belongs only in the active-ops widget and Monitoring run detail. Review detail may link to the canonical run detail but must not create a parallel progress tracker. `OperationRun.status` and `OperationRun.outcome` remain service-owned through `OperationRunService`. Any `summary_counts` must use allowed numeric-only keys and values. Scheduled or system-initiated review generation must not create initiator-only terminal DB notifications.
**Constitution alignment (RBAC-UX):** This feature operates in the tenant/admin plane for tenant review detail and mutation surfaces and in the workspace-admin canonical view for the shared review register. Cross-plane access remains deny-as-not-found. Non-members or users outside workspace or tenant scope receive `404`. In-scope users lacking `tenant_review.view` or `tenant_review.manage` receive `403` according to the attempted action. Authorization must be enforced server-side for create, refresh, publish, archive, and export actions. The canonical capability registry remains the only capability source. Destructive-like actions such as archive require confirmation.
**Constitution alignment (OPS-EX-AUTH-001):** Not applicable. No authentication handshake behavior is changed.
**Constitution alignment (BADGE-001):** Review lifecycle state, publication state, completeness state, and export readiness are status-like values and must use centralized badge semantics rather than local page-specific mappings. Tests must cover all newly introduced values.
**Constitution alignment (UI-NAMING-001):** The target object is the tenant review. Operator-facing verbs are `Create review`, `Refresh review`, `Publish review`, `Export executive pack`, and `Archive review`. Source/domain disambiguation is needed only where the review references evidence dimensions such as findings, baseline posture, permissions, or operations health. The same review vocabulary must be preserved across action labels, modal titles, run titles, notifications, and audit prose. Implementation-first terms such as `render package`, `materialize review`, or `hydrate sections` must not become primary operator-facing labels.
**Constitution alignment (Filament Action Surfaces):** This feature adds or modifies Filament pages/resources for tenant review list and detail plus workspace canonical review register. The Action Surface Contract is satisfied if list inspection uses a canonical inspect affordance, pack generation remains an explicit action, destructive lifecycle actions require confirmation, and all mutations are capability-gated and auditable.
**Constitution alignment (UX-001 — Layout & Information Architecture):** Review list screens must provide search, sort, and filters for tenant, review state, publication state, evidence basis, and review date. Review detail must use an Infolist-style inspection surface rather than a disabled edit form. Any review-creation form or action must keep inputs inside sections. Empty states must include a specific title, explanation, and exactly one CTA.
### Functional Requirements
- **FR-001**: The system MUST provide a first-class tenant review record that represents one curated governance review for one tenant and one chosen evidence basis.
- **FR-002**: A tenant review MUST reference exactly one anchored evidence basis at creation time, with enough stored metadata to remain intelligible if downstream source artifacts later change, expire, or are superseded.
- **FR-003**: The first implementation slice MUST support review sections for executive summary, open-risk highlights, accepted-risk summary, permission posture summary, baseline or drift posture summary, and operational health summary.
- **FR-004**: The system MUST allow an authorized operator to create a tenant review from an eligible evidence snapshot without manually rebuilding each section from live source pages.
- **FR-005**: The system MUST preserve review immutability for published reviews. Refreshing a published review MUST create a new draft review or explicit successor review instead of mutating the published historical record.
- **FR-006**: The system MUST distinguish at least draft, ready, published, archived, and superseded review lifecycle states.
- **FR-007**: The system MUST record review completeness and section availability explicitly, including when a review is based on partial evidence.
- **FR-008**: The system MUST make it clear which evidence dimensions were included, omitted, partial, or stale in each review.
- **FR-009**: The system MUST provide one tenant-scoped review library where authorized operators can list, inspect, refresh, publish, archive, and export review records for the active tenant.
- **FR-010**: The system MUST provide one workspace-scoped canonical review register where authorized operators can review tenant review history across entitled tenants without leaking unauthorized tenant detail.
- **FR-011**: The system MUST provide one stakeholder-facing executive review surface for a prepared tenant review that presents summary content and recommended next steps without forcing the operator into raw source artifacts.
- **FR-012**: The system MUST support an exportable executive review pack derived from one prepared tenant review record rather than from ad hoc live assembly.
- **FR-013**: Exporting an executive review pack MUST use the selected tenant review as the source of truth for section ordering, summary content, and included dimensions.
- **FR-014**: The system MUST block publish or export actions when the review lacks required summary sections or required completeness thresholds for this slice, and it MUST explain the blocking reason clearly.
- **FR-015**: The system MUST define duplicate-prevention semantics so that accidental repeated publish or export attempts from the same unchanged review do not create duplicate final artifacts unintentionally.
- **FR-016**: The system MUST preserve historical published review records and exported pack references so prior reviews remain auditable and comparable over time.
- **FR-017**: Creating, refreshing, publishing, archiving, and exporting a review MUST be recorded in audit history with workspace scope, tenant scope, actor, action, and outcome.
- **FR-018**: The feature MUST explicitly exclude framework-oriented compliance scoring, certification claims, and BSI, NIS2, or CIS mapping from the first slice. Those remain a downstream Compliance Readiness feature.
- **FR-019**: The feature MUST introduce at least one positive and one negative authorization test for tenant-scoped review management and workspace-scoped canonical review visibility.
- **FR-020**: The feature MUST introduce regression tests proving evidence-basis anchoring, published-review immutability, executive-pack consistency, and cross-tenant isolation.
## 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 |
|---|---|---|---|---|---|---|---|---|---|---|
| Tenant Review Library | Tenant-context review list under `/admin/t/{tenant}/reviews` | `Create review` (`tenant_review.manage`) | Clickable row to review detail | `View review`, `Export executive pack` when ready | None in v1 | `Create first review` | None | N/A | Yes | Create may use an action modal because it selects an evidence basis and starts a review composition workflow |
| Tenant Review Detail | Canonical detail route under `/admin/t/{tenant}/reviews/{review}` | None | N/A | None | None | N/A | `Refresh review`, `Publish review`, `Export executive pack`, `Archive review` | N/A | Yes | Inspection surface only; no disabled edit form |
| Workspace Review Register | Workspace canonical view at `/admin/reviews` | `Clear filters` | Clickable row to review detail | `View review`, `Export executive pack` when authorized | None in v1 | `Clear filters` | None | N/A | Export yes | Must suppress unauthorized tenant rows and filter values |
### Key Entities *(include if feature involves data)*
- **Tenant Review**: A curated review record for one tenant anchored to a chosen evidence basis and used for recurring governance conversations.
- **Review Section**: One named portion of the tenant review, such as executive summary, risk highlights, posture summary, or operational health summary, including its completeness and source references.
- **Executive Review Pack**: A stakeholder-facing deliverable derived from one tenant review and preserving that review's section ordering, summary truth, and completeness disclosures.
- **Review Lifecycle State**: The normalized state of a tenant review, including draft, ready, published, archived, and superseded.
## Success Criteria *(mandatory)*
### Measurable Outcomes
- **SC-001**: An authorized operator can create a tenant review from an eligible evidence basis and open its executive summary in under 3 minutes without leaving the product.
- **SC-002**: Published tenant reviews remain unchanged in 100% of automated immutability tests after underlying live source records are modified.
- **SC-003**: In manual review flow validation, an operator can answer the tenant's top risks, current posture highlights, and next actions from one review detail surface without opening more than one optional drill-down page.
- **SC-004**: Exported executive review packs match their source tenant review's included dimensions and summary ordering in 100% of automated integration tests for the covered first-slice review sections.
- **SC-005**: Negative authorization tests prove that non-members or wrong-tenant users receive deny-as-not-found behavior and in-scope users without the required capability cannot create, publish, archive, or export tenant reviews.
- **SC-006**: Operators can distinguish draft, ready, published, archived, and superseded review states in one inspection step from list or detail surfaces.
## Assumptions
- Evidence snapshots are the primary source-of-truth input for review creation in the first slice.
- Findings summaries, accepted-risk lifecycle data, permission posture, and baseline or drift posture are mature enough to populate first-slice review sections.
- The first slice optimizes for tenant-by-tenant recurring reviews and executive packs, not for framework-oriented compliance mapping.
- Workspace-level review visibility is a register and management surface, not yet a portfolio dashboard with SLA analytics.
## Non-Goals
- Building a framework-oriented Compliance Readiness layer with BSI, NIS2, or CIS mapping
- Creating tenant portfolio rollups, SLA health dashboards, or fleet ranking views across tenants
- Implementing cross-tenant compare or promotion workflows
- Turning the tenant review layer into a generic BI reporting system
- Triggering new Microsoft Graph collection during review preparation

36
specs/200-filament-surface-rules/checklists/requirements.md Normal file
View File

@ -0,0 +1,36 @@
# Specification Quality Checklist: UI/UX Constitution Extension: Filament Nativity & Custom Surface Rules
**Purpose**: Validate specification completeness and quality before proceeding to planning
**Created**: 2026-04-18
**Feature**: [spec.md](../spec.md)
## Content Quality
- [x] No implementation details (languages, frameworks, APIs)
- [x] Focused on user value and business needs
- [x] Written for non-technical stakeholders
- [x] All mandatory sections completed
## Requirement Completeness
- [x] No [NEEDS CLARIFICATION] markers remain
- [x] Requirements are testable and unambiguous
- [x] Success criteria are measurable
- [x] Success criteria are technology-agnostic (no implementation details)
- [x] All acceptance scenarios are defined
- [x] Edge cases are identified
- [x] Scope is clearly bounded
- [x] Dependencies and assumptions identified
## Feature Readiness
- [x] All functional requirements have clear acceptance criteria
- [x] User scenarios cover primary flows
- [x] Feature meets measurable outcomes defined in Success Criteria
- [x] No implementation details leak into specification
## Notes
- Optional operator-surface classification tables are intentionally omitted because this feature amends repository governance rather than changing a concrete runtime surface.
- Filament and Livewire terminology is intentional product vocabulary for this constitution slice, not code-level implementation guidance.
- Validation cross-checked the spec against adjacent Specs 196 through 199 and the existing constitution anchors UI-FIL-001, UI-EX-001, DECIDE-001, UI-REVIEW-001, and HDR-001.

103
specs/200-filament-surface-rules/contracts/constitution-governance-contract.md Normal file
View File

@ -0,0 +1,103 @@
# Constitution Governance Contract
## Contract Type
Docs-only governance contract. This feature introduces no runtime HTTP, GraphQL, CLI, or queue API surface.
## Governing Scope
Spec 200 must amend the existing UI constitution so the following rule families become explicit, reviewable, and bounded:
- Filament-native by default
- fake-native prohibitions
- legitimate custom-surface allowance
- shared detail micro-UI family rules
- shell/page/detail state ownership rules
- reviewer-facing guidance and classification questions
- explicit exception handling
- named anti-pattern catalog
## Required Amendment Targets
The implementation must update the existing constitution in `.specify/memory/constitution.md` rather than create a separate rulebook.
Expected amendment targets:
- `UI-SURF-001`
- `ACTSURF-001`
- `HDR-001`
- `UI-HARD-001`
- `UI-EX-001`
- `UI-REVIEW-001`
- `Filament UI — Action Surface Contract`
- `UX-001`
- `UI-FIL-001` where native-first wording needs sharpening
## Final Amendment Mapping
| Source spec | Problem class absorbed by Spec 200 | Final constitution targets |
|---|---|---|
| Spec 196 | Native-by-default clarity, fake-native drift, request-driven body-state misuse, simple-overview drift | `UI-FIL-001`, `UI-HARD-001`, `UI-EX-001`, `UI-REVIEW-001` |
| Spec 197 | Shared detail micro-UI families, host/core boundaries, bounded host variation | `UI-SURF-001`, `ACTSURF-001`, `HDR-001`, `Filament UI — Action Surface Contract`, `UI-REVIEW-001` |
| Spec 198 | Requested vs active vs draft vs inspect vs restorable page-state ownership | `UI-HARD-001`, `UX-001`, `UI-REVIEW-001` |
| Spec 199 | Workspace-first shell truth, tenantless state, shell/page separation, fallback clarity | `ACTSURF-001`, `UX-001`, `UI-REVIEW-001` |
| Spec 201 | Enforcement follow-up only | deferred consumer; no constitution wording invented there |
## Final Exception Boundary
Spec 200 leaves four bounded exception families available inside `UI-EX-001`:
- `Legitimate Custom Surface Exception`
- `Nativity Exception`
- `Shared Detail Host Variation Exception`
- `State-Layer Special-case Exception`
Each exception must stay inside the existing exception model and must state:
1. the product reason
2. the smallest custom behavior required
3. what remains standardized
4. which layer owns the relevant state
5. what Spec 201 may later enforce
## Acceptance Contract
The finished constitution amendment must satisfy all of the following:
1. A reviewer can classify the representative cases from Specs 196, 197, 198, and 199 using the amended constitution alone.
2. The amendment does not create a parallel top-level UI rulebook.
3. Legitimate custom surfaces remain possible through an explicit exception path.
4. The anti-pattern catalog names at least the recurring drift classes identified in the feature spec.
5. Reviewer-facing guidance and classification questions are explicit enough to classify the representative cases from Specs 196 through 199.
6. The cross-spec mapping to Specs 196 through 199 and the deferral to Spec 201 are explicit.
The acceptance contract is not satisfied unless the constitution now names all of the following review classes directly: `Native Surface`, `Fake-Native Surface`, `Custom Surface`, `Shared Detail Micro-UI`, `Host`, `Global Context State`, `Page State`, `Detail State`, `Legitimate Exception`, `Host Drift`, `State Layer Collapse`, and `Parallel Inspect Worlds`.
## Out of Scope
This contract explicitly excludes:
- `app/` runtime code changes
- route, controller, or Livewire behavior changes
- CI/grep/lint/test enforcement
- checklist-template operationalization beyond optional wording-only references
- fabricated REST or GraphQL endpoints
## Deferred Enforcement Boundary
Spec 201 is responsible for operationalization work such as:
- review checklist changes
- grep/lint guards
- CI enforcement
- runtime or test-backed regression guards for the anti-pattern catalog
Spec 200 must define the rule language cleanly enough that Spec 201 can consume it without inventing a new vocabulary.
## Close-out Contract
The final artifact set must leave one explicit close-out note that separates:
- newly added clauses and vocabulary
- tightened existing clauses
- enforcement work intentionally deferred to Spec 201

253
specs/200-filament-surface-rules/data-model.md Normal file
View File

@ -0,0 +1,253 @@
# Data Model: UI/UX Constitution Extension: Filament Nativity & Custom Surface Rules
## Overview
Spec 200 is a docs-only governance feature. Its data model is conceptual rather than persisted: it describes the rule objects, vocabulary, and mappings that the constitution amendment must carry so reviewers can classify future UI work consistently.
No application database schema, runtime DTO, or transport contract is introduced by this feature.
## Entities
### 1. ConstitutionAmendmentTarget
Represents one existing constitution section that Spec 200 extends.
**Fields**
| Field | Type | Description |
|---|---|---|
| `section_id` | string | Existing rule ID or section anchor, for example `UI-SURF-001` or `UI-EX-001` |
| `target_file` | string | File path, always `.specify/memory/constitution.md` for this feature |
| `amendment_type` | enum | `clarification`, `extension`, or `new-clause` |
| `problem_classes` | list<string> | The drift classes this amendment addresses |
| `source_specs` | list<string> | Evidence specs feeding the amendment, limited here to Specs 196 through 199 |
| `expected_outputs` | list<string> | Vocabulary, anti-pattern, exception, or state-layer additions contributed by this target |
| `deferred_enforcement` | list<string> | What remains reserved for Spec 201 |
**Validation rules**
- `section_id` must reference an already existing constitution section.
- `amendment_type` must not imply a new parallel rulebook.
- Every target must cite at least one source spec or one direct repo problem class.
### 2. SurfaceVocabularyTerm
Represents a named concept that future specs and reviews must use consistently.
**Fields**
| Field | Type | Description |
|---|---|---|
| `name` | string | Canonical term, such as `Native Surface` or `Fake-Native Surface` |
| `definition` | text | Reviewable product definition |
| `positive_examples` | list<string> | Example surfaces or surface families that fit the term |
| `negative_examples` | list<string> | Nearby cases that must not be misclassified under the term |
| `governing_sections` | list<string> | Constitution sections that must mention or support the term |
| `source_specs` | list<string> | Adjacent specs that proved the need for the term |
**Validation rules**
- Every term must map to at least one amended constitution section.
- Terms must describe product-review concepts, not implementation jargon.
- Terms must be classifiable from real repo cases.
### 3. AntiPattern
Represents a named failure mode the constitution must forbid or flag.
**Fields**
| Field | Type | Description |
|---|---|---|
| `name` | string | Canonical anti-pattern name, such as `Filament Costume` |
| `definition` | text | What the anti-pattern looks like in practice |
| `trigger_signals` | list<string> | Observable characteristics that let reviewers identify it |
| `default_review_outcome` | enum | `reject`, `document-exception`, or `defer-to-follow-up-spec` |
| `allowed_exception_path` | string | Exception type or `none` when no escape is expected |
| `source_specs` | list<string> | Spec evidence behind the anti-pattern |
**Validation rules**
- Every anti-pattern must have at least one trigger signal.
- Every anti-pattern must either forbid the pattern directly or point to a bounded exception path.
- Anti-pattern names must remain stable enough for future guardrails in Spec 201.
### 4. ExceptionType
Represents a bounded, legitimate deviation from the default rules.
**Fields**
| Field | Type | Description |
|---|---|---|
| `name` | string | Canonical exception name |
| `allowed_when` | text | Product reason that makes the exception legitimate |
| `required_justification` | list<string> | Mandatory explanation points in the governing spec or PR |
| `boundaries` | list<string> | What the exception does not allow |
| `standardized_parts` | list<string> | What must remain consistent despite the exception |
| `governing_section` | string | Expected home in `UI-EX-001` |
| `deferred_enforcement` | list<string> | Which parts Spec 201 may later operationalize |
**Validation rules**
- Every exception type must stay inside the existing exception model.
- `allowed_when` must describe product need, not convenience.
- Every exception must state what stays standardized.
### 5. StateOwnershipRule
Represents the review contract for shell, page, or detail state.
**Fields**
| Field | Type | Description |
|---|---|---|
| `layer` | enum | `shell`, `page`, or `detail` |
| `owns_truth` | text | What this layer is authoritative for |
| `allowed_inputs` | list<string> | Inputs the layer may consume, such as route state, query seed, or local viewer state |
| `query_role` | enum | `initialization-only`, `durable`, `deeplink-only`, or `unsupported` |
| `forbidden_overlaps` | list<string> | Competing truths or cross-layer conflicts that are not allowed |
| `source_specs` | list<string> | Spec 198 and/or 199 evidence |
**Validation rules**
- Each rule must assign exactly one owner layer.
- A rule may describe inputs from other layers, but it may not assign equal authority to multiple layers.
- Query role must be explicit whenever the layer can be initialized from URL or remembered state.
### 6. CrossSpecMapping
Represents how one adjacent spec feeds the constitution amendment and where follow-up work goes.
**Fields**
| Field | Type | Description |
|---|---|---|
| `source_spec` | string | `196`, `197`, `198`, `199`, or `201` |
| `problem_class` | string | Problem family contributed by that spec |
| `constitution_targets` | list<string> | Which amendment targets consume that evidence |
| `status` | enum | `evidence-source`, `consumed-by-spec-200`, or `deferred-to-201` |
| `notes` | text | Short mapping summary |
**Validation rules**
- Specs 196 through 199 must map into at least one amendment target.
- Spec 201 must appear only as a deferred enforcement consumer, not as an implementation dependency within Spec 200.
## Relationships
- A `ConstitutionAmendmentTarget` produces zero or more `SurfaceVocabularyTerm` entries.
- A `ConstitutionAmendmentTarget` may define zero or more `AntiPattern` and `ExceptionType` entries.
- `StateOwnershipRule` entries are a specialized conceptual rule family that feed both vocabulary terms and amendment targets.
- `CrossSpecMapping` connects the adjacent evidence specs to the exact constitution targets that absorb them.
## Lifecycle
### Amendment Lifecycle
1. **Identified**: A rule gap is proven by a current repo case.
2. **Mapped**: The gap is assigned to an existing constitution section.
3. **Integrated**: The constitution text is amended with vocabulary, anti-patterns, or exceptions.
4. **Reviewable**: Representative cases from Specs 196 through 199 can be classified through the amended language.
5. **Operationalized later**: Spec 201 may add checklist, grep, lint, or test enforcement based on the integrated rule.
### Exception Lifecycle
1. **Requested**: A surface claims that native-by-default or shared-contract rules do not fit.
2. **Justified**: The spec states the product reason, boundaries, and standardized parts.
3. **Accepted or rejected**: Review uses the exception type and anti-pattern catalog.
4. **Potentially enforceable later**: Spec 201 may formalize recurring exception checks.
## Derived Outputs
The conceptual data model must support these concrete outputs in the constitution amendment:
- glossary terms for the required vocabulary
- named anti-pattern entries
- explicit exception types or exception clauses
- state ownership guidance for shell/page/detail separation
- a mapping note connecting Specs 196 through 199 to the amended rule family
## Out of Scope
- database tables
- Eloquent models
- runtime registries or service abstractions
- REST or GraphQL transport schemas
- executable state machines
- template or CI enforcement logic in this spec
## Amendment Target Inventory
| Amendment target | Amendment type | Problem classes absorbed | Source specs | Expected outputs | Deferred enforcement |
|---|---|---|---|---|---|
| `UI-FIL-001` | extension | native-by-default, fake-native drift, simple-overview nativity | 196 | `Native Surface`, `Custom Surface`, `Fake-Native Surface`, anti-pattern anchors | Spec 201 guardrails for fake-native patterns |
| `UI-HARD-001` | extension | forbidden fake-native behavior, one-primary-interaction-model, state/inspect conflict classes | 196, 198 | anti-pattern catalog, hard prohibitions, state-layer violation names | Spec 201 grep/test checks for forbidden patterns |
| `UI-EX-001` | extension | bounded legitimate custom surfaces, nativity exceptions, host variation, state special cases | 196, 197, 198 | finalized exception families and guardrails | Spec 201 checklist and exception review enforcement |
| `UI-SURF-001` | extension | shared detail family taxonomy, host terminology | 197 | `Shared Detail Micro-UI`, `Host` | Spec 201 metadata/review guardrails |
| `ACTSURF-001` | extension | one primary interaction model, host/family action ownership, shell/page separation pressure | 197, 199 | host/core action rules, `Parallel Inspect Worlds` review questions | Spec 201 action-surface enforcement |
| `HDR-001` | clarification | host-owned header discipline for embedded shared families | 197 | header-specific host boundary language | Spec 201 header review prompts |
| `Filament UI — Action Surface Contract` | extension | native simple-overview rule, shared-family contract ownership, explicit state ownership disclosure | 196, 197, 198 | Filament-facing execution rules | Spec 201 checklist/guard uptake |
| `UX-001` | extension | shell/page/detail ownership, requested/active/draft/inspect/restorable roles | 198, 199 | state vocabulary and owner-layer rules | Spec 201 review and doc enforcement |
| `UI-REVIEW-001` | extension | reviewer-facing classification, anti-pattern checks, state-owner questions | 196, 197, 198, 199 | explicit review questions and red flags | Spec 201 operationalization |
## Final Vocabulary Inventory
| Term | Governing sections | Source specs | Role in the amendment |
|---|---|---|---|
| `Native Surface` | `UI-SURF-001`, `UI-FIL-001`, `UI-HARD-001` | 196 | Default classification for standard Filament/shared-primitives work |
| `Fake-Native Surface` | `UI-HARD-001`, `UI-FIL-001`, `UI-REVIEW-001` | 196 | Forbidden violation class for Filament-looking but contract-foreign UI |
| `Custom Surface` | `UI-SURF-001`, `UI-EX-001`, `UI-FIL-001` | 196 | Legitimate non-native surface only with bounded product reason |
| `Legitimate Exception` | `UI-EX-001`, `UI-REVIEW-001` | 196 | Shared language for approved deviations |
| `Shared Detail Micro-UI` | `UI-SURF-001`, `ACTSURF-001`, `Filament UI — Action Surface Contract` | 197 | Repeated embedded family that must keep one shared contract |
| `Host` | `UI-SURF-001`, `ACTSURF-001`, `HDR-001` | 197 | Parent page/resource/workbench owning route, auth, and host-only actions |
| `Global Context State` | `UX-001`, `UI-REVIEW-001` | 199 | Shell-owned workspace/tenant truth |
| `Page State` | `UX-001`, `UI-REVIEW-001` | 198 | Page-owned filter/tab/mode/selection truth |
| `Detail State` | `UX-001`, `UI-REVIEW-001` | 197, 198 | Embedded viewer or inner inspect truth subordinate to page/shell |
| `Requested State` | `UX-001`, `UI-REVIEW-001` | 198, 199 | Input state before validation or hydration |
| `Active State` | `UX-001`, `UI-REVIEW-001` | 198, 199 | Current governing validated state |
| `Draft State` | `UX-001`, `UI-REVIEW-001` | 198 | Pending local state not yet applied |
| `Inspect State` | `UI-HARD-001`, `UX-001`, `UI-REVIEW-001` | 198 | Selected-record/detail focus truth |
| `Restorable State` | `UX-001`, `UI-REVIEW-001` | 198 | The shareable subset intentionally recreated |
| `Host Drift` | `UI-HARD-001`, `UI-REVIEW-001` | 197 | Forbidden host-side rewrite of shared-family core semantics |
| `State Layer Collapse` | `UI-HARD-001`, `UX-001`, `UI-REVIEW-001` | 198, 199 | Forbidden multi-layer ownership of the same truth |
| `Parallel Inspect Worlds` | `ACTSURF-001`, `UI-HARD-001`, `UI-REVIEW-001` | 198 | Forbidden competing inspect/view models for one concern |
## Final Anti-pattern Catalog
| Anti-pattern | Trigger signals | Default review outcome | Allowed exception path | Source specs |
|---|---|---|---|---|
| `Filament Costume` | Raw HTML/Tailwind controls mimic Filament semantics that native/shared primitives already provide | reject | `Nativity Exception` only when the semantic gap is explicit and narrow | 196 |
| `Blade Request UI` | Primary body-state contract depends on `request()`, GET forms, or manual query parsing inside an active Filament surface | reject | `Nativity Exception` only for initialization-only request input | 196 |
| `Hand-Rolled Simple Overview` | Simple report/overview with ordinary columns, filters, empty states, and navigation is rebuilt as bespoke markup | reject | `Legitimate Custom Surface Exception` only when the product need is materially richer than a table/list | 196 |
| `Hidden Exception` | Custom behavior survives through history or convenience without a named exception block | reject | none | 196 |
| `Host Drift` | One host changes core family zones, view semantics, or diagnostics contract without declaring host-scoped variation | reject | `Shared Detail Host Variation Exception` | 197 |
| `State Layer Collapse` | Shell, page, or detail state each claim the same active truth or restoration role | reject | `State-Layer Special-case Exception` only when the owner hierarchy stays explicit | 198, 199 |
| `Parallel Inspect Worlds` | Two same-concern inspect/open/select/view contracts coexist as peers | reject | none | 198 |
## Final Exception Relationships
| Exception type | Solves | Governing section | Standardized parts that must remain intact | Related anti-patterns |
|---|---|---|---|---|
| `Legitimate Custom Surface Exception` | Rich visualization, diagnostic/review work, multi-zone evidence, or shell-context-specific UI that does not fit standard CRUD/overview semantics | `UI-EX-001` | canonical nouns, scope clarity, explicit action hierarchy, explicit state ownership | `Hand-Rolled Simple Overview`, `Hidden Exception` |
| `Nativity Exception` | Filament/shared primitives cannot express the required semantics cleanly | `UI-EX-001` | native/shared surrounding controls, no local status language, no request-owned primary body state | `Filament Costume`, `Blade Request UI`, `Hidden Exception` |
| `Shared Detail Host Variation Exception` | A known shared family needs bounded host framing, assist entry, or optional-zone variation | `UI-EX-001` | family core zones, next-step contract, diagnostics contract, primary view/inspect model | `Host Drift` |
| `State-Layer Special-case Exception` | A page legitimately needs explicit requested/active/draft/inspect/restorable distinctions beyond the simple default | `UI-EX-001` | one owner per layer, explicit restorable subset, explicit query role, no silent shell/page overlap | `State Layer Collapse`, `Parallel Inspect Worlds` |
## Final State Ownership Rules
| Layer | Owns truth | Allowed inputs | Query role | Forbidden overlaps | Source specs |
|---|---|---|---|---|---|
| `shell` | workspace/tenant context, tenantless state, shell recovery state | route context, explicit switch/select/clear flows, valid restore candidates | durable only when the shell contract explicitly allows restore | page tabs/filters owning workspace truth, detail viewers owning tenant scope | 199 |
| `page` | filters, tabs, active modes, selected-record/page-level inspect state, applied analysis state | shell context, deeplink/init state, local interactions, explicit draft/apply actions | initialization-only, durable, or unsupported exactly as declared by the page contract | shell precedence logic, detail-local state redefining page truth | 198 |
| `detail` | embedded viewer state, inner section/tab choice, family-local assist or reveal state | host/page state, local viewer controls | usually unsupported or local-only unless an exception documents otherwise | shell or page ownership of the same active inspect/view truth | 197, 198 |
## Final Cross-Spec Mapping
| Source spec | Problem class | Constitution targets | Status | Notes |
|---|---|---|---|---|
| `196` | Fake-native drift and simple-overview nativity | `UI-FIL-001`, `UI-HARD-001`, `UI-EX-001`, `UI-REVIEW-001` | consumed-by-spec-200 | Produces native/custom/fake-native language and the anti-pattern anchors |
| `197` | Shared detail micro-UI host/core boundaries | `UI-SURF-001`, `ACTSURF-001`, `HDR-001`, `Filament UI — Action Surface Contract`, `UI-REVIEW-001` | consumed-by-spec-200 | Produces shared-family, host, host-drift, and header-boundary language |
| `198` | Page-state ownership and inspect/restoration semantics | `UI-HARD-001`, `UX-001`, `UI-REVIEW-001` | consumed-by-spec-200 | Produces requested/active/draft/inspect/restorable vocabulary and inspect-conflict rules |
| `199` | Shell-context truth and shell/page separation | `ACTSURF-001`, `UX-001`, `UI-REVIEW-001` | consumed-by-spec-200 | Produces global-context/page/detail ownership clarity |
| `201` | Review, grep, lint, and regression enforcement | all of the above as downstream consumers | deferred-to-201 | Spec 201 consumes the final vocabulary directly and must not invent replacement categories |

171
specs/200-filament-surface-rules/plan.md Normal file
View File

@ -0,0 +1,171 @@
# Implementation Plan: UI/UX Constitution Extension: Filament Nativity & Custom Surface Rules
**Branch**: `200-filament-surface-rules` | **Date**: 2026-04-18 | **Spec**: `specs/200-filament-surface-rules/spec.md`
**Input**: Feature specification from `specs/200-filament-surface-rules/spec.md`
**Note**: This template is filled in by the `/speckit.plan` command. See `.specify/scripts/` for helper scripts.
## Summary
Extend the existing UI constitution so Filament-native defaults, fake-native drift, legitimate custom surfaces, shared detail micro-UI families, and shell/page/detail state ownership are all reviewable through one integrated rule set. The implementation approach is docs-only: amend existing constitution sections rather than create a parallel UI rulebook, add the shared vocabulary and anti-pattern catalog grounded in Specs 196 through 199, define the exception model boundaries, and record a clean handoff to Spec 201 for enforcement.
## Technical Context
**Language/Version**: Markdown governance artifacts in a PHP 8.4.15 / Laravel 12 / Filament v5 / Livewire v4 repository
**Primary Dependencies**: `.specify/memory/constitution.md`, `docs/ui/operator-ux-surface-standards.md`, adjacent Specs 196 through 199, existing UI rule IDs `UI-SURF-001`, `ACTSURF-001`, `HDR-001`, `UI-HARD-001`, `UI-EX-001`, `UI-REVIEW-001`, `UI-FIL-001`, `DECIDE-001`, and `UX-001`
**Storage**: N/A
**Testing**: Document review, representative-case validation, and checklist verification only
**Validation Lanes**: N/A (docs-only governance change)
**Target Platform**: Repository governance for the Laravel web application and its Filament admin/operator surfaces
**Project Type**: Laravel monolith with docs-only planning artifacts
**Performance Goals**: N/A; the success target is review clarity, constitution precision, and explicit scope boundaries rather than runtime performance
**Constraints**: No parallel rulebook; no runtime routes or API contracts; no CI/grep/lint/test enforcement in this spec; legitimate custom surfaces must remain possible; Spec 201 remains the enforcement boundary
**Scale/Scope**: One constitution amendment path, one supporting operator-UX standards reference, one spec artifact set, and cross-spec mapping across Specs 196 through 199 plus Spec 201
## Constitution Check
*GATE: Must pass before Phase 0 research. Re-check after Phase 1 design.*
- Inventory-first: N/A (docs-only governance feature; no inventory or snapshot behavior changes)
- Read/write separation: PASS (no product write path is introduced)
- Graph contract path: PASS (no Graph calls or contract registry changes)
- Deterministic capabilities: PASS (no capability derivation changes)
- RBAC-UX: PASS (no authorization behavior changes; planned rules only reinforce existing boundaries)
- Workspace isolation: PASS (no new workspace context path; shell/page/detail layering rules must preserve established workspace truth)
- Tenant isolation: PASS (no new tenant access path; future rules explicitly forbid silent scope broadening)
- Run observability: PASS (no `OperationRun` creation or lifecycle changes)
- Ops-UX 3-surface feedback: N/A (no run feedback surfaces)
- Ops-UX lifecycle + summary counts + guards: N/A (no run lifecycle change)
- Ops-UX system runs: N/A
- Automation: N/A (no queued/scheduled flow)
- Data minimization: PASS (no runtime or persistence impact)
- Test governance (TEST-GOV-001): PASS (`N/A` lanes and no runtime impact are explicit; enforcement-oriented follow-up is deferred to Spec 201)
- Proportionality (PROP-001): PASS but triggered; the new vocabulary and taxonomy are bounded to already proven repo problem classes and do not create runtime architecture
- No premature abstraction (ABSTR-001): PASS (no new runtime factory, registry, resolver, or service layer is introduced)
- Persisted truth (PERSIST-001): PASS (repository docs only; no product truth added)
- Behavioral state (STATE-001): PASS (state-layer terms are governance vocabulary, not new persisted or executable state families)
- UI semantics (UI-SEM-001): PASS (the plan strengthens direct, reviewable domain-to-UI rules and rejects local semantic frameworks)
- V1 explicitness / few layers (V1-EXP-001, LAYER-001): PASS (existing constitution sections are amended in place rather than layered with a second framework)
- Spec discipline / bloat check (SPEC-DISC-001, BLOAT-001): PASS (all related semantic additions stay in one rule spec; enforcement stays separate in Spec 201)
- Badge semantics (BADGE-001): PASS (no new badge taxonomy; the plan only clarifies when local status language is forbidden)
- Filament-native UI (UI-FIL-001): PASS (this feature extends the rule instead of introducing alternative UI semantics)
- UI/UX surface taxonomy (UI-CONST-001 / UI-SURF-001): PASS (the plan tightens existing taxonomy and exception logic)
- Decision-first operating model (DECIDE-001): PASS (no new primary surface; the plan strengthens review vocabulary for future surfaces)
- UI/UX inspect model and hard rules (UI-HARD-001): PASS (the plan adds fake-native and state-layer clarity without changing runtime inspect models)
- Action-surface discipline (ACTSURF-001 / HDR-001 / UI-EX-001): PASS (the plan extends existing action and exception rules in place)
Gate status before Phase 0 research: PASS
## Test Governance Check
> **Fill for any runtime-changing or test-affecting feature. Docs-only or template-only work may state concise `N/A` or `none`.**
- **Test purpose / classification by changed surface**: N/A
- **Affected validation lanes**: N/A
- **Why this lane mix is the narrowest sufficient proof**: This feature is a docs-only governance and planning slice. Validation is review-oriented and does not require runtime or test-lane execution.
- **Narrowest proving command(s)**: N/A
- **Fixture / helper / factory / seed / context cost risks**: none
- **Expensive defaults or shared helper growth introduced?**: no
- **Heavy-family additions, promotions, or visibility changes**: none
- **Closing validation and reviewer handoff**: Reviewers should verify the amended constitution against the representative cases from Specs 196 through 199, confirm that no runtime enforcement is claimed prematurely, and ensure the handoff to Spec 201 is explicit.
- **Budget / baseline / trend follow-up**: none
- **Review-stop questions**: Does any rule create a parallel rulebook? Does any clause imply runtime enforcement that belongs to Spec 201? Does the taxonomy overreach beyond proven repo cases? Does the docs-only contract remain clearly bounded?
- **Escalation path**: none
- **Why no dedicated follow-up spec is needed**: A dedicated follow-up already exists as Spec 201; this plan only prepares the vocabulary and constitution amendments that Spec 201 will later operationalize.
## Project Structure
### Documentation (this feature)
```text
specs/200-filament-surface-rules/
├── plan.md
├── checklists/
│ └── requirements.md
├── research.md
├── data-model.md
├── quickstart.md
├── contracts/
│ └── constitution-governance-contract.md
└── tasks.md
```
### Source Code (repository root)
```text
.specify/
├── memory/
│ └── constitution.md
└── templates/
└── checklist-template.md # referenced only; enforcement edits remain deferred to Spec 201
docs/
└── ui/
└── operator-ux-surface-standards.md
specs/
├── 196-hard-filament-nativity-cleanup/
├── 197-shared-detail-contract/
├── 198-monitoring-page-state/
├── 199-global-context-shell-contract/
└── 200-filament-surface-rules/
```
**Structure Decision**: This is a docs-only governance feature. The implementation centers on `.specify/memory/constitution.md` plus the feature artifacts in `specs/200-filament-surface-rules/`. `docs/ui/operator-ux-surface-standards.md` is a reference alignment target only if wording drift is discovered during implementation. Checklist or CI operationalization remains explicitly deferred to Spec 201.
## Complexity Tracking
| Violation | Why Needed | Simpler Alternative Rejected Because |
|-----------|------------|-------------------------------------|
| None | N/A | N/A |
## Proportionality Review
- **Current operator problem**: Reviewers lack one stable language for classifying fake-native drift, bounded custom surfaces, shared-family host drift, and shell/page/detail state ownership. That makes future UI work inconsistent even when local specs identify specific defects.
- **Existing structure is insufficient because**: The existing constitution has strong surface and action rules, but it does not yet state native-by-default, fake-native, shared-family, and explicit state-layer ownership as one integrated set grounded in the proven repo cases from Specs 196 through 199.
- **Narrowest correct implementation**: Amend the existing constitution sections in place, add the minimal new vocabulary and anti-pattern catalog, define the exception boundary, and leave template/checklist/grep/test operationalization to Spec 201.
- **Ownership cost created**: The repo gains a tighter review vocabulary and more precise constitutional language that maintainers must preserve in future UI specs and PRs.
- **Alternative intentionally rejected**: A separate standalone UI constitution document, broad template enforcement in this spec, or a generic design-system framework detached from the existing constitution.
- **Release truth**: current-release review truth and governance clarity
## Phase 0 — Outline & Research (Complete)
Outputs:
- `specs/200-filament-surface-rules/research.md`
Unknowns resolved:
- Which existing constitution sections should absorb the new rules so the repo avoids a parallel rulebook.
- Which parts of Spec 200 are genuinely new versus clarifications or extensions of existing rule IDs.
- How to model a contracts artifact for a docs-only governance slice without inventing runtime API endpoints.
- Which adjacent documentation artifacts should be referenced for operator-language and progressive-disclosure alignment.
- Which parts of review/checklist operationalization must stay deferred to Spec 201 to honor scope.
## Phase 1 — Design & Contracts (Complete)
Outputs:
- `specs/200-filament-surface-rules/data-model.md`
- `specs/200-filament-surface-rules/contracts/constitution-governance-contract.md`
- `specs/200-filament-surface-rules/quickstart.md`
Design highlights:
- The feature uses a conceptual data model only: amendment targets, vocabulary terms, anti-patterns, exception types, state-ownership rules, and cross-spec mappings.
- No runtime API contract is introduced; the contract artifact explicitly records the docs-only governance scope, amendment targets, acceptance conditions, and deferred enforcement boundary.
- The quickstart centers on amending existing constitution sections, validating representative cases, and leaving automation to Spec 201.
## Constitution Re-check (Post-Design)
Result: PASS
- The design remains docs-only and introduces no Graph calls, authorization changes, runtime state, or `OperationRun` behavior.
- The proportionality trigger stays justified because the new taxonomy is bounded to proven repo problem classes and integrated into existing rule IDs.
- No template, checklist, grep, lint, or runtime enforcement is pulled into this spec; those concerns remain explicitly deferred to Spec 201.
- Legitimate custom surfaces remain available through the documented exception path; the design does not collapse all operator-facing UI into one Filament-only rule.
## Implementation Sequencing
1. Amend `.specify/memory/constitution.md` in place, targeting the existing sections `UI-FIL-001`, `UI-SURF-001`, `ACTSURF-001`, `HDR-001`, `UI-HARD-001`, `UI-EX-001`, `UI-REVIEW-001`, `Filament UI — Action Surface Contract`, and `UX-001` with the native-by-default, fake-native, shared-family, state-layer, reviewer-guidance, and exception rules.
2. Add the glossary and anti-pattern catalog inside the amended constitution language so the new vocabulary is reviewable without creating a second rule source.
3. Add the cross-spec mapping and close-out note in the Spec 200 artifact set, showing how Specs 196 through 199 feed the rules and what remains reserved for Spec 201.
4. Validate the amended constitution against the representative cases from Specs 196 through 199 to confirm that each case can be classified through the new rule language alone.
5. If wording drift is discovered, align `docs/ui/operator-ux-surface-standards.md` with the amended constitution without creating a competing standard or adding enforcement mechanics.
6. Record explicit deferrals to Spec 201 for review checklist changes, grep/lint guards, test enforcement, or CI automation.

89
specs/200-filament-surface-rules/quickstart.md Normal file
View File

@ -0,0 +1,89 @@
# Quickstart: Implementing Spec 200
## Purpose
Use this sequence when turning Spec 200 into the actual constitution amendment.
This is a docs-only governance feature. Do not add runtime behavior, transport contracts, CI rules, or enforcement automation here.
## Inputs
- `specs/200-filament-surface-rules/spec.md`
- `specs/200-filament-surface-rules/research.md`
- `specs/200-filament-surface-rules/data-model.md`
- `.specify/memory/constitution.md`
- `docs/ui/operator-ux-surface-standards.md`
- `specs/196-hard-filament-nativity-cleanup/spec.md`
- `specs/197-shared-detail-contract/spec.md`
- `specs/198-monitoring-page-state/spec.md`
- `specs/199-global-context-shell-contract/spec.md`
## Steps
1. Start in `.specify/memory/constitution.md` and locate the existing sections targeted by the plan: `UI-SURF-001`, `ACTSURF-001`, `UI-HARD-001`, `UI-EX-001`, `Filament UI — Action Surface Contract`, `UX-001`, and `UI-FIL-001`.
2. Add the minimum rule language needed to make native-by-default, fake-native, legitimate custom surfaces, shared detail families, and shell/page/detail state ownership explicit.
3. Add the required vocabulary terms and anti-pattern names inside the amended constitution language instead of in a separate standalone document.
4. Extend the exception model so legitimate deviations are named, bounded, and forced to state what remains standardized.
5. Validate the amendment against the representative cases from Specs 196 through 199. Each case must be classifiable from the constitution text alone.
6. Write the close-out note for Spec 200, clearly separating:
- newly added or tightened constitution rules
- clarifications to existing rules
- items intentionally deferred to Spec 201
7. Only if wording drift is discovered, align `docs/ui/operator-ux-surface-standards.md` with the amended constitution. Do not create a competing standards document.
## Representative Walkthrough
Use this exact walkthrough to validate that the amendment classifies the already proven repo cases without inventing new rule families during review.
| Source spec | Case to walk through | Constitution language that must classify it | Expected result |
|---|---|---|---|
| Spec 196 | Dependency edges, required-permissions filters, and evidence overview nativity cleanup | `UI-FIL-001`, `UI-HARD-001`, `UI-EX-001`, `UI-REVIEW-001` | Fake-native and simple-overview drift are rejected unless a bounded custom or nativity exception is explicit |
| Spec 197 | Verification report and normalized diff/settings hosts | `UI-SURF-001`, `ACTSURF-001`, `HDR-001`, `Filament UI — Action Surface Contract`, `UI-REVIEW-001` | Shared-family core and host-owned variation are distinguishable; host drift is rejectable |
| Spec 198 | Monitoring and compare state ownership | `UI-HARD-001`, `UX-001`, `UI-REVIEW-001` | Requested, active, draft, inspect, and restorable state roles are classifiable without treating them as one blur |
| Spec 199 | Global context bar, tenantless shell, fallback behavior | `ACTSURF-001`, `UX-001`, `UI-REVIEW-001` | Global context state is clearly shell-owned and not silently re-owned by a page or partial |
### Walkthrough output checklist
1. Name the surface class and decide whether the surface is `Native Surface`, `Custom Surface`, or a `Shared Detail Micro-UI`.
2. Decide whether any named anti-pattern appears: `Filament Costume`, `Blade Request UI`, `Hand-Rolled Simple Overview`, `Hidden Exception`, `Host Drift`, `State Layer Collapse`, or `Parallel Inspect Worlds`.
3. If the case is still allowed, identify the exact exception type and the standardized parts that remain intact.
4. Name which layer owns the relevant truth: `Global Context State`, `Page State`, or `Detail State`.
5. Name which state roles matter: `Requested`, `Active`, `Draft`, `Inspect`, or `Restorable`.
6. Stop if the review needs a new term. Spec 200 is only complete when the constitution text already contains the needed category.
## Cross-Spec Mapping
| Input spec | What Spec 200 absorbs | What remains outside Spec 200 |
|---|---|---|
| `196-hard-filament-nativity-cleanup` | native-by-default language, fake-native prohibitions, simple-overview default-to-native rule | runtime cleanup work and regression tests |
| `197-shared-detail-contract` | shared detail micro-UI and host/core vocabulary, host-drift review gates | runtime host consolidation and regression tests |
| `198-monitoring-page-state` | shell/page/detail ownership vocabulary and explicit state-role language | runtime page-state contract implementation and regression tests |
| `199-global-context-shell-contract` | workspace-first shell ownership vocabulary and shell/page separation | runtime shell resolution and fallback behavior |
| `201-*` | no new concepts; only enforcement consumers | checklist, grep, lint, CI, and regression operationalization |
## Validation Checklist
- The constitution is still the single source of truth.
- No new runtime route, API, database, or enforcement code has been introduced.
- Legitimate custom surfaces are still possible through the exception model.
- Fake-native drift is named clearly enough that reviewers can identify it quickly.
- Shared detail family and state-layer rules are grounded in the already proven cases from Specs 197, 198, and 199.
- The handoff to Spec 201 is explicit and does not require new conceptual categories.
## Close-out Summary
When the amendment is finished, leave one concise close-out note that separates:
- **New clauses and vocabulary**:
native/custom/fake-native classification, shared detail micro-UI and host language, state-layer ownership terms, and the named anti-pattern catalog.
- **Tightened existing clauses**:
native-by-default expectations, one-primary-interaction-model discipline, shared-family host ownership, record-header discipline for embedded families, and explicit review questions.
- **Deferred enforcement**:
checklist operationalization, grep/lint guards, CI checks, and runtime or test-backed regression enforcement in Spec 201.
## Not In Scope Here
- changing `.specify/templates/checklist-template.md` for enforcement behavior
- adding grep or lint guards
- adding CI checks
- inventing sample runtime endpoints or implementation code snippets to simulate enforcement

85
specs/200-filament-surface-rules/research.md Normal file
View File

@ -0,0 +1,85 @@
# Research: UI/UX Constitution Extension: Filament Nativity & Custom Surface Rules
## Decision 1: Amend existing constitution sections instead of creating a parallel UI rulebook
- **Decision**: Integrate Spec 200 into the existing constitution sections `UI-SURF-001`, `ACTSURF-001`, `UI-HARD-001`, `UI-EX-001`, `Filament UI — Action Surface Contract`, and `UX-001`.
- **Rationale**: The repo already has a binding UI constitution. Extending those sections keeps one authority path for surface taxonomy, action discipline, hard rules, exceptions, Filament-specific contracts, and layout or IA guidance. This directly satisfies the spec's requirement to avoid a parallel rule hierarchy.
- **Alternatives considered**:
- Create a new top-level “Filament Nativity Constitution” section: rejected because it would force reviewers to reconcile two overlapping rulebooks.
- Keep the rules distributed only across Specs 196 through 199: rejected because reviewers still need one durable product-language source rather than four adjacent historical specs.
## Decision 2: Treat native-by-default and fake-native as explicit extensions of existing UI-FIL-001 and UI-HARD-001 behavior
- **Decision**: Add an explicit native-by-default rule and a named fake-native anti-pattern to the existing Filament-native and hard-rule sections instead of inventing new standalone IDs.
- **Rationale**: `UI-FIL-001` already says native Filament components come first, but it does not yet give reviewers a sharp fake-native vocabulary or clearly outlaw GET-form/request-driven body state for standard interactions. Spec 196 proved that gap.
- **Alternatives considered**:
- Leave native-by-default implicit in existing Filament guidance: rejected because implicit guidance did not prevent the repo's fake-native drift cases.
- Introduce a new `UI-FIL-NATIVE-001` rule ID: rejected because the problem belongs inside the existing Filament-native section and hard-rule family.
## Decision 3: Model shared detail micro-UI and host variation as an extension of the current action-surface and exception framework
- **Decision**: Add shared-family and host-variation rules beneath the existing Filament UI contract and exception model instead of describing them as an unrelated custom-UI system.
- **Rationale**: Spec 197 proved that the repeated problem is not “custom UI is bad,” but that repeated detail surfaces need one shared contract before host-specific variation is allowed. The existing action-surface and exception sections already govern how surfaces, actions, and deviations are classified.
- **Alternatives considered**:
- Create a separate “shared micro-UI framework” document: rejected because it would overproduce structure for two proven families and separate the rule from the main constitution.
- Treat each host difference as a local PR concern: rejected because that is what allowed host drift to accumulate in the first place.
## Decision 4: Reuse the state-language proven in Specs 198 and 199 rather than invent a new runtime state taxonomy
- **Decision**: Carry forward shell/page/detail ownership and requested/active/draft/inspect/restorable distinctions as constitution vocabulary only, with no new runtime state framework in this spec.
- **Rationale**: Specs 198 and 199 already proved the important state distinctions. Spec 200's job is to make those distinctions reviewable across future UI work, not to create a new implementation layer.
- **Alternatives considered**:
- Invent a fresh cross-product state taxonomy here: rejected because the repo already has adjacent specs proving the needed terms.
- Limit the spec to visual nativity only: rejected because state-layer collapse is one of the core drift classes this spec must cover.
## Decision 5: Extend the existing exception model instead of normalizing hidden exceptions
- **Decision**: Keep `UI-EX-001` as the home for bounded exceptions and extend it with Spec 200's legitimate custom-surface and host-variation needs.
- **Rationale**: The repo already recognizes that exceptions must be named, justified, and tested. Spec 200 broadens that discipline to fake-native escapes, legitimate custom surfaces, shared-family host variation, and state-related special cases without weakening the existing exception posture.
- **Alternatives considered**:
- Let individual specs define their own exception vocabulary: rejected because that recreates local drift.
- Ban all custom surfaces to avoid exceptions entirely: rejected because the product legitimately includes richer diagnostic, review, and visualization surfaces.
## Decision 6: Treat the contracts artifact as an explicit no-runtime governance contract
- **Decision**: Create a docs-only contract note under `contracts/` that records amendment targets, acceptance conditions, and deferrals instead of inventing REST or GraphQL endpoints.
- **Rationale**: Spec 200 introduces no user-facing API, route, or transport contract. The contract surface is the constitution amendment itself, so the artifact should make that boundary explicit rather than fabricate runtime endpoints that the spec forbids.
- **Alternatives considered**:
- Create a fake OpenAPI file: rejected because it would imply runtime behavior the feature does not add.
- Omit `contracts/` entirely: rejected because the planning workflow expects an artifact and the no-runtime boundary should be made explicit.
## Decision 7: Reference operator-UX standards for language and disclosure, but defer review-checklist operationalization to Spec 201
- **Decision**: Use `docs/ui/operator-ux-surface-standards.md` as the supporting operator-language and progressive-disclosure reference, but keep checklist-template and enforcement work out of Spec 200 unless a wording-only cross-reference becomes unavoidable.
- **Rationale**: Spec 200 is the rule and vocabulary slice. Spec 201 is the enforcement slice. That mirrors the repo's existing TEST-GOV-001 pattern, where standing governance rules live in the constitution and later specs operationalize them in templates and CI.
- **Alternatives considered**:
- Update review checklists now: rejected because it would blur the line between constitution definition and enforcement.
- Ignore operator-UX standards docs completely: rejected because the constitution language should remain aligned with the repo's normative operator-facing UI guidance.
## Decision 8: Keep the implementation footprint intentionally small
- **Decision**: Plan for constitution changes in `.specify/memory/constitution.md`, feature-local artifacts in `specs/200-filament-surface-rules/`, and at most wording alignment in `docs/ui/operator-ux-surface-standards.md`.
- **Rationale**: This keeps the scope proportional to a docs-only governance feature and avoids importing template, CI, or application-code changes that the spec explicitly defers.
- **Alternatives considered**:
- Widen the plan to include `.specify/templates/checklist-template.md`: rejected because template operationalization is enforcement work for Spec 201.
- Widen the plan to include runtime examples in `app/` or `tests/`: rejected because Spec 200 is not an implementation spec.
## Decision 9: Put the new vocabulary into the existing rule families and appendices instead of creating a separate glossary section
- **Decision**: Introduce the new terms and anti-patterns inside the already binding rule families (`UI-SURF-001`, `UI-HARD-001`, `UI-EX-001`, `UX-001`, `UI-REVIEW-001`, `UI-FIL-001`) plus the condensed appendix/checklist/red-flag appendices, rather than creating a standalone vocabulary chapter.
- **Rationale**: Reviewers need the terms exactly where they classify behavior. A standalone glossary would recreate the split-rulebook problem this spec is supposed to remove.
- **Alternatives considered**:
- Add a new glossary-only top-level constitution section: rejected because the review language would become detached from the operative rules.
- Keep the vocabulary only in the Spec 200 artifact set: rejected because the constitution would still be missing the durable review language.
## Decision 10: Review questions should absorb nativity, shared-family, and state-layer checks directly
- **Decision**: Expand `UI-REVIEW-001`, Appendix B, and Appendix C with the new classification and anti-pattern checks rather than invent a second reviewer rubric for Filament nativity or state ownership.
- **Rationale**: The existing enforcement model and appendices are already the review intake for operator-facing UI changes. Extending that surface is the narrowest way to make the new rules usable.
- **Alternatives considered**:
- Create a dedicated nativity/state checklist: rejected because it would fragment one review routine into multiple parallel rubrics.
- Leave the new language implicit and rely on reviewer judgment: rejected because that is the current failure mode.
## Implementation Adjustment Note
- During implementation, the repo-level operator UX standards document only needs wording alignment that points back to the constitution vocabulary. A second standards track for native/custom/shared/state terminology would be overproduction and is intentionally avoided.

314
specs/200-filament-surface-rules/spec.md Normal file
View File

@ -0,0 +1,314 @@
# Feature Specification: UI/UX Constitution Extension: Filament Nativity & Custom Surface Rules
**Feature Branch**: `[200-filament-surface-rules]`
**Created**: 2026-04-18
**Status**: Proposed
**Input**: User description: "Spec 200 - extend the UI/UX constitution with Filament nativity rules, custom surface allowance, shared detail micro-UI rules, state layering rules, and a documented exception model."
## Spec Candidate Check *(mandatory - SPEC-GATE-001)*
- **Problem**: The product still lacks one explicit constitution that answers when an admin surface must stay Filament-native, when a custom surface is legitimate, how repeated detail micro-UIs should be cut, and where shell, page, and detail state belong.
- **Today's failure**: Reviewers and implementers can spot local defects, but they still lack one shared rule language for deciding whether a surface is fake-native drift, a bounded custom exception, host drift inside a shared family, or state-layer collapse.
- **User-visible improvement**: Operators get more consistent, predictable admin UX over time because future surface work is reviewed against one product rule set instead of personal style, delivery pressure, or historical accident.
- **Smallest enterprise-capable version**: Extend the existing UI constitution with bounded rules and vocabulary grounded in Specs 196 through 199, document the exception model, and define the handoff to Spec 201. Do not absorb cleanup sweeps, runtime refactors, or enforcement automation.
- **Explicit non-goals**: No repo-wide cleanup pass, no CI or lint enforcement, no new runtime architecture, no new product surfaces, no separate design-system handbook, no page-state or shell-state implementation rewrite, and no attempt to forbid all custom surfaces.
- **Permanent complexity imported**: A bounded review vocabulary, additional constitution clauses, an explicit anti-pattern catalog, a documented exception model, and a mapping from Specs 196 through 199 into one enduring rule set that Spec 201 can later enforce.
- **Why now**: Specs 196 through 199 already exposed the repeated problem classes, and Spec 201 cannot operationalize guardrails cleanly unless those rules are first named, bounded, and integrated into the existing constitution.
- **Why not local**: Local cleanup specs fix instances, but they do not settle the recurring review questions that keep resurfacing across adjacent UI work and future operator-facing surfaces.
- **Approval class**: Core Enterprise
- **Red flags triggered**: Two red flags are present: foundation-sounding constitution work and new cross-surface vocabulary. Defense: the scope is tightly bounded to already proven repo problem classes, integrates into existing constitution sections instead of inventing a parallel system, and explicitly defers runtime enforcement and automation to Spec 201.
- **Score**: Nutzen: 2 | Dringlichkeit: 2 | Scope: 1 | Komplexität: 1 | Produktnähe: 2 | Wiederverwendung: 2 | **Gesamt: 10/12**
- **Decision**: approve
## Spec Scope Fields *(mandatory)*
- **Scope**: canonical-view
- **Primary Routes**: No new runtime route is introduced. The governed surfaces are the existing operator-facing admin surfaces under `/admin/**` and `/admin/t/{tenant}/...`, plus the workspace-owned constitution artifact that defines how those surfaces must be reviewed and extended.
- **Data Ownership**: Workspace-owned constitution text, review vocabulary, anti-pattern definitions, and handoff notes only. No tenant-owned records, runtime tables, or persisted product entities are introduced.
- **RBAC**: This feature does not change product authorization behavior. Future implementing work remains bound to the existing workspace membership, tenant entitlement, capability, and deny-as-not-found rules already enforced elsewhere in the product.
For canonical-view specs, the spec MUST define:
- **Default filter behavior when tenant-context is active**: This feature defines no new page or route filter behavior. It requires future specs and reviews to state explicitly whether tenant-context is shell scope, page prefilter, detail context, or unsupported state, and to keep those layers separate.
- **Explicit entitlement checks preventing cross-tenant leakage**: This feature introduces no new access path. Any future application of these rules must preserve the existing workspace and tenant boundaries and must not let shell, page, or detail state silently broaden tenant scope.
## Proportionality Review *(mandatory when structural complexity is introduced)*
- **New source of truth?**: yes, but only as additional clauses inside the existing workspace-owned constitution rather than a new product runtime truth
- **New persisted entity/table/artifact?**: yes, but only repository-owned artifacts such as constitution text, mapping notes, and checklist-level governance content
- **New abstraction?**: yes, a bounded review vocabulary and exception model for UI surface classification
- **New enum/state/reason family?**: yes, because the feature formalizes surface classes, state-layer distinctions, and named anti-pattern categories
- **New cross-domain UI framework/taxonomy?**: yes, but only a bounded constitution taxonomy for already proven Filament-adjacent surface problems
- **Current operator problem**: Surface quality still depends too much on who built the page and under what pressure. The same repo now contains fake-native controls, request-driven page bodies, shared-family drift, and mixed shell or page state with no single rule language that reviewers can apply consistently.
- **Existing structure is insufficient because**: Specs 196 through 199 each proved one part of the problem, but without a shared constitution extension the repo still lacks one stable answer to whether a surface should be native, custom, shared-family, shell-owned, page-owned, or a documented exception.
- **Narrowest correct implementation**: Extend the existing UI constitution sections with explicit definitions, native-by-default rules, custom-surface allowance, shared-family rules, state-layer rules, anti-patterns, and an exception model grounded in existing repo cases. Do not add runtime machinery, a new design system, or enforcement automation.
- **Ownership cost**: Maintainers must preserve the vocabulary, keep the amended constitution coherent with future UI work, and ensure later specs and PRs use the same rule language instead of rephrasing it ad hoc.
- **Alternative intentionally rejected**: Leave the topic split across adjacent specs, document local exceptions only in PRs, or create a separate parallel UI-rule document detached from the existing constitution.
- **Release truth**: current-release review truth needed now to keep future UI work and Spec 201 aligned
## Problem Statement
The repo audit did not show that the product is fundamentally misbuilt. It showed that UI and surface quality still depends too much on local authorship and delivery pressure.
The repeated drift patterns are already visible:
- plain HTML controls wearing Filament styling
- Blade-body micro-UIs with their own interaction contract
- shared detail families growing by include or fork instead of by one contract
- page-level state that is sometimes local, sometimes query-driven, and sometimes hybrid without a declared hierarchy
- shell or context logic that still leaks into partials instead of one explicit resolver contract
- legitimate custom surfaces that remain undocumented exceptions and therefore look indistinguishable from accidental drift
The missing ingredient is not another local cleanup. It is a constitution extension that answers the recurring product questions directly:
- What must be native?
- When is custom legitimate?
- How is a special case justified?
- Which state belongs to shell, page, or detail?
- How does a reviewer identify a regression into the old drift patterns early?
Spec 200 exists to establish those answers as durable product rules.
## Dependencies
- Depends on Spec 196 - Hard Filament Nativity Cleanup for the proven fake-native and request-driven UI cases that motivate the native-by-default rules.
- Depends on Spec 197 - Shared Detail Micro-UI Contract for the proven repeated-host problem and the need for shared-core versus host-variation rules.
- Depends on Spec 198 - Monitoring Page-State Contract for the proven page-state taxonomy and the need to distinguish requested, active, draft, inspect, and restorable state.
- Depends on Spec 199 - Global Context Shell Contract for the proven workspace-first shell truth and the need to separate shell context from page and detail state.
- Feeds Spec 201 - Enforcement and Guardrails, which will operationalize the rules from this spec in review, grep, lint, tests, or other automation.
- Does not absorb cleanup implementation, runtime state rewrites, or enforcement machinery from any adjacent spec.
## Goals
- Make it explicit when a surface must use Filament-native primitives.
- Make it explicit when a custom surface is legitimate and how narrow that exception must stay.
- Define how shared detail micro-UI families are cut into shared contract versus host-specific variation.
- Define how shell, page, and detail state are separated and reviewed.
- Establish a named anti-pattern catalog so reviews describe the same problem classes with the same words.
- Give Spec 201 a stable rule set to enforce instead of asking enforcement work to invent the rules later.
## Non-Goals
- Cleaning up all existing violations immediately.
- Enabling CI, lint, grep, or test enforcement in this spec.
- Reorganizing navigation or inventing new product surfaces.
- Creating a generic Filament theory document detached from repo reality.
- Reimplementing page-state or shell-state runtime behavior beyond what adjacent specs already cover.
- Prohibiting legitimate custom visualizations, diagnostic viewers, or multi-zone evidence surfaces.
## Assumptions
- The existing UI constitution sections, especially UI-CONST-001, DECIDE-001, UI-EX-001, UI-REVIEW-001, HDR-001, and UI-FIL-001, remain the binding base that this spec extends rather than replaces.
- Filament-native admin surfaces remain the normal product shell for standard forms, filters, tables, badges, tabs, and actions.
- Legitimate custom surfaces will continue to exist for richer visualization, diagnostics, diff, review, and embedded evidence work.
- Enforcement is intentionally deferred to Spec 201, not partially implemented here.
- Review usefulness matters more than architectural purity; if a rule does not help a reviewer classify a real repo case, it is too abstract.
## Key Decisions
- **Native by default**: Standard form, filter, table, action, and overview work belongs on native Filament or Livewire primitives when an appropriate primitive already exists.
- **Fake-native is a first-class violation**: A surface that only looks native, but keeps a separate HTML, GET, or Blade-request contract for the same core interaction, is drift.
- **Custom requires product reason**: Custom surfaces are legitimate only when the product need is genuinely richer than standard CRUD or overview semantics and the exception is bounded explicitly.
- **Shared contract before host fork**: Repeated detail families must be described once as a shared family before host-specific variation is allowed.
- **State belongs to the right layer**: Workspace and tenant truth belong to the shell, page interaction belongs to the page, and viewer micro-state belongs to the detail surface.
- **One primary interaction model per concern**: Surfaces may not run two competing inspect, tab, filter, or selection contracts for the same user concern.
- **Explicit exceptions beat implicit drift**: Legitimate special cases must be named, bounded, and reviewable instead of surviving through historical accident.
## Required Outcomes
### Constitution Integration
The existing constitution must gain explicit rule language for Filament nativity, fake-native prohibitions, custom-surface allowance, shared detail micro-UI families, shell or page or detail state layering, and exception handling without creating a second parallel rulebook.
### Shared Review Vocabulary
The product must gain one stable vocabulary for the following concepts:
- Native Surface
- Fake-Native Surface
- Custom Surface
- Shared Detail Micro-UI
- Host
- Global Context State
- Page State
- Detail State
- Legitimate Exception
### Anti-Pattern Catalog
The constitution must catalog the recurring failure modes that the repo audit already exposed, so reviewers can call them by name and reject them consistently.
### Exception Model
The constitution must define how a legitimate deviation from native-by-default or shared-contract rules is justified, bounded, and kept from turning into a general permission slip.
### Cross-Spec Mapping
The constitution extension must explain how Specs 196 through 199 feed the new rules and which part of the work remains reserved for Spec 201.
### Close-Out Note
The finished spec must leave one explicit summary of what constitution rules were added or amended, which existing rules were tightened or clarified, and which topics remain enforcement follow-up rather than implementation scope.
## Representative Validation Cases
- **Dependency edges detail surface**: A reviewer must be able to classify a dependency-edge surface as a native-surface violation when standard controls are replaced by GET-form or Blade-request state without a true product reason.
- **Verification report host family**: A reviewer must be able to classify host-specific structural drift inside repeated verification-report surfaces as a shared-family violation unless a clearly justified subtype exists.
- **Monitoring page inspect and filter state**: A reviewer must be able to classify mixed requested, active, draft, or inspect state as page-state drift rather than as a harmless local implementation detail.
- **Global context shell behavior**: A reviewer must be able to classify shell partials that quietly own scope truth or remembered context as shell-contract violations rather than neutral presentation code.
- **Legitimate special visualization**: A reviewer must still be able to approve a truly custom visualization or rich diagnostic viewer when the product reason is real and the exception remains narrow and explicit.
## Testing / Lane / Runtime Impact *(mandatory for runtime behavior changes)*
- **Test purpose / classification**: N/A
- **Validation lane(s)**: N/A
- **Why this classification and these lanes are sufficient**: This feature changes repository governance text and specification artifacts, not product runtime behavior. Validation is document-based and depends on completeness, clarity, and traceability to real repo cases.
- **New or expanded test families**: none
- **Fixture / helper cost impact**: none
- **Heavy-family visibility / justification**: none
- **Reviewer handoff**: Reviewers must confirm that the new rules are grounded in Specs 196 through 199, that no enforcement or runtime behavior is claimed without a follow-up implementation spec, that no parallel rulebook is created, and that the resulting vocabulary is sufficient to classify the representative cases above.
- **Budget / baseline / trend impact**: none
- **Escalation needed**: none
- **Planned validation commands**: N/A
## User Scenarios & Testing *(mandatory)*
### User Story 1 - Classify Nativity And Exceptions Consistently (Priority: P1)
As a reviewer, I want one constitution vocabulary for native, fake-native, and legitimate exception decisions so I can classify a surface without inventing local review language every time.
**Why this priority**: The main current pain is review inconsistency. If the spec cannot standardize the classification language, the rest of the rule set will remain too soft to matter.
**Independent Test**: Can be fully tested by reviewing a representative fake-native case and a representative legitimate custom case and verifying that both can be classified through the constitution alone.
**Acceptance Scenarios**:
1. **Given** a Filament-looking surface that still uses plain HTML controls and request-driven body state, **When** a reviewer applies the amended constitution, **Then** the reviewer can classify it as fake-native drift without adding new terminology.
2. **Given** a rich diagnostic or visualization surface that does not fit standard CRUD or overview primitives, **When** a reviewer applies the amended constitution, **Then** the reviewer can approve it only through the documented exception model and product reason.
---
### User Story 2 - Cut Shared Detail Families And State Layers Correctly (Priority: P1)
As an author or reviewer of operator-facing UI, I want one rule set for shared detail families and shell, page, and detail state so that repeated hosts and complex monitoring pages do not quietly re-fork the product contract.
**Why this priority**: Shared-family drift and state-layer collapse were both already proven by adjacent specs and are the largest remaining sources of UI inconsistency after obvious fake-native cleanup.
**Independent Test**: Can be fully tested by evaluating one shared detail family and one monitoring or shell-context case and confirming that the constitution states where the shared contract ends, where host variation begins, and where each state class belongs.
**Acceptance Scenarios**:
1. **Given** the same detail micro-UI appears in multiple hosts, **When** the reviewer applies the amended constitution, **Then** the reviewer can decide whether the hosts share one family contract or have drifted into unapproved forks.
2. **Given** a page mixes query state, local state, inspect state, and shell context, **When** the reviewer applies the amended constitution, **Then** the reviewer can identify which state belongs to shell, page, or detail instead of treating the mixture as harmless implementation detail.
---
### User Story 3 - Prepare Enforcement Without Re-Inventing Rules (Priority: P2)
As the author of follow-up guardrails, I want the constitution to state the reviewable rule classes explicitly so that enforcement can be derived from stable product language rather than from one-off heuristics.
**Why this priority**: Spec 201 should operationalize this rule set, not rediscover it. Without an explicit handoff, enforcement work will either be too weak or will invent a different vocabulary.
**Independent Test**: Can be fully tested by mapping the amended constitution to a future guardrail backlog and verifying that the enforcement targets follow directly from the named rule and anti-pattern classes.
**Acceptance Scenarios**:
1. **Given** the amended constitution is complete, **When** a maintainer defines follow-up enforcement targets, **Then** the maintainer can identify which rule classes are enforceable without needing new conceptual categories.
2. **Given** a future UI change violates one of the named anti-patterns, **When** Spec 201 is planned, **Then** the follow-up spec can reference the same vocabulary and representative cases instead of restating the rule family from scratch.
### Edge Cases
- A surface visually matches Filament but keeps its real behavior in GET forms, query parsing, or Blade-body request state.
- A custom surface is genuinely justified but risks becoming a broad precedent for unrelated ad hoc markup.
- A repeated detail surface appears in only one current host but is about to appear in another and must not be prematurely over-generalized.
- Remembered shell context, requested page state, and local viewer state disagree on first load.
- A historically grown special surface has no explicit exception record and must be classified as either an allowed exception to document or a drift case to reject.
## Requirements *(mandatory)*
**Constitution alignment (required):** This feature changes repository-owned constitution and review guidance only. It introduces no Microsoft Graph calls, no write workflow, no long-running job, and no new runtime route. Existing operator-facing pages remain governed by their current implementation and authorization contracts until follow-up specs or code changes adopt these rules.
**Constitution alignment (PROP-001 / ABSTR-001 / PERSIST-001 / STATE-001 / BLOAT-001):** This feature introduces a bounded new vocabulary and rule taxonomy inside the existing constitution. It does not add product persistence, runtime abstractions, or execution-state machinery. The proportionality review above explains why the new language is justified now and how the scope remains tighter than a generic UI framework.
**Constitution alignment (TEST-GOV-001):** This feature does not change runtime behavior or test families. Validation is document-based. Any future automation, linting, grep rules, or regression tests that enforce this constitution are deferred to Spec 201 and must carry their own lane and runtime impact disclosure.
**Constitution alignment (OPS-UX):** Not applicable. This feature creates no `OperationRun`, changes no run status transitions, and does not alter toast, progress, or terminal-notification rules.
**Constitution alignment (RBAC-UX):** This feature does not change authorization behavior. It reinforces that shell, page, and detail state rules must not bypass workspace membership, tenant entitlement, capability checks, or deny-as-not-found semantics in future implementations.
**Constitution alignment (OPS-EX-AUTH-001):** Not applicable. Authentication handshake behavior is unchanged.
**Constitution alignment (BADGE-001):** The feature must not create a new page-local badge or severity language. It extends existing UI rules so future surfaces know when native or shared semantics are required and when local status language is forbidden.
**Constitution alignment (UI-FIL-001):** This feature explicitly extends UI-FIL-001 by clarifying when Filament-native primitives are mandatory, which fake-native substitutes are prohibited, and when a product-grounded exception is legitimate.
**Constitution alignment (UI-NAMING-001):** The new vocabulary is review-facing and architectural, not operator-facing action copy. It must remain concise, stable, and tied to repeated repo problem classes rather than implementation jargon.
**Constitution alignment (DECIDE-001):** This feature does not create a new operator surface. It strengthens the review language that future specs and PRs must use when classifying surfaces, exceptions, and the human-in-the-loop role of a page.
**Constitution alignment (UI-CONST-001 / UI-SURF-001 / ACTSURF-001 / UI-HARD-001 / UI-EX-001 / UI-REVIEW-001 / HDR-001):** The feature must integrate into the existing UI constitution family, not sit beside it. Any new rule must either extend an existing section cleanly or add a narrowly scoped adjacent clause that still participates in the same review model.
### Functional Requirements
- **FR-200-001**: The product constitution MUST be extended inside the existing UI constitution structure rather than through a separate standalone rule document.
- **FR-200-002**: The constitution MUST define the following terms explicitly: Native Surface, Fake-Native Surface, Custom Surface, Shared Detail Micro-UI, Host, Global Context State, Page State, Detail State, and Legitimate Exception.
- **FR-200-003**: The constitution MUST state that standard form, filter, table, action, tab, badge, link, and overview work is native-by-default when suitable Filament or existing shared primitives are available.
- **FR-200-004**: The constitution MUST prohibit plain HTML or Filament-costume markup as the primary interaction contract for standard controls when native primitives fit the job.
- **FR-200-005**: The constitution MUST classify GET forms and Blade `request()` body-state as forbidden fake-native patterns when they act as the primary interaction contract inside a running Filament surface, unless an explicit and bounded exception is documented.
- **FR-200-006**: The constitution MUST state that simple report or overview surfaces with ordinary columns, filters, empty states, and navigation default to native table semantics unless a real product reason requires a custom surface.
- **FR-200-007**: The constitution MUST define the legitimate reasons for a custom surface, including richer visualization, high-value diagnostic or review work, multi-zone shared detail micro-UIs, shell-context-specific UI, and domain presentation that does not fit standard CRUD.
- **FR-200-008**: The constitution MUST require every legitimate custom surface to declare its state layers, expected inputs, host-owned actions, shared-core versus host-specific variation, and any shareable or restorable state that matters to the operator.
- **FR-200-009**: The constitution MUST state that speed of implementation, historical growth, or local convenience are not sufficient reasons for a custom-surface or fake-native exception.
- **FR-200-010**: The constitution MUST define shared detail family rules that require a common core contract, mandatory zones, optional zones, host extension points, and explicit state responsibilities before host-specific variation is allowed.
- **FR-200-011**: The constitution MUST limit host variation to contextual framing, allowed actions, and approved optional zones, and MUST classify structural host forks for the same family as drift unless a new subtype is explicitly justified.
- **FR-200-012**: The constitution MUST define page-state rules that distinguish initial requested state, active page state, optional draft state, inspect state, and shareable or restorable state, and MUST require each state class to declare any query or URL role explicitly.
- **FR-200-013**: The constitution MUST define global shell rules that keep workspace as the primary context, tenant as the secondary context, remembered context as subordinate convenience state, and shell partials as renderers of the context contract rather than owners of it.
- **FR-200-014**: The constitution MUST require one primary interaction model per concern and MUST classify competing inspect, tab, filter, or selection contracts on the same surface as a violation unless a documented exception defines their hierarchy.
- **FR-200-015**: The constitution MUST define an explicit exception model that requires each deviation from native-by-default or shared-family rules to state why native or default behavior does not fit, why custom behavior is necessary, what remains standardized, and how the exception stays narrow.
- **FR-200-016**: The constitution MUST catalog at least the following anti-patterns explicitly: Filament Costume, Blade Request UI, Hand-Rolled Simple Overview, Host Drift, State Layer Collapse, Parallel Inspect Worlds, and Hidden Exception.
- **FR-200-017**: The constitution MUST add reviewer-facing guidance and questions that let maintainers classify representative cases from Specs 196 through 199 without creating new local vocabulary during review.
- **FR-200-018**: The feature MUST document how Specs 196 through 199 feed the new rules and which part of the problem remains delegated to Spec 201 for enforcement.
- **FR-200-019**: The feature MUST produce a close-out summary describing which constitution rules were added, which existing rules were tightened or clarified, and which future enforcement topics remain intentionally deferred.
### Non-Functional Requirements
- **NFR-200-001**: The amended rules MUST stay grounded in already observed repo problem classes and be precise enough that a reviewer can classify the representative cases without supplementary verbal explanation.
- **NFR-200-002**: The feature MUST remain docs-only and governance-only. It MUST NOT introduce runtime routes, provider registration changes, assets, persistence, or Graph behavior.
- **NFR-200-003**: The resulting constitution MUST not accidentally ban all custom surfaces. Legitimate rich visualization, diagnostics, evidence, and multi-zone detail work must remain available through the documented exception path.
- **NFR-200-004**: The extension MUST integrate into the existing constitution and review model rather than creating a second manual or rule hierarchy that reviewers must reconcile separately.
- **NFR-200-005**: The wording MUST be strong enough for future enforcement work to derive guardrails from it, but not so dogmatic that it overrides real product reasons for bounded custom behavior.
### Key Entities *(include if feature involves data)*
- **Native Surface Classification**: The constitution-level classification for surfaces whose core interaction is carried by Filament-native or existing shared primitives without a competing local contract.
- **Fake-Native Surface**: A surface that visually imitates native admin UI while keeping its actual interaction contract in plain HTML, GET forms, ad hoc request parsing, or other unnecessary local behavior.
- **Custom Surface Allowance**: The bounded rule that permits truly product-specific surfaces when standard CRUD or overview primitives are not sufficient.
- **Shared Detail Micro-UI Family**: A repeated domain detail surface that must define shared core zones, optional zones, and host variation before multiple hosts can evolve safely.
- **State Layer Classification**: The distinction between global shell context, page interaction state, and detail micro-state, including how requested, active, draft, inspect, and restorable state are separated.
- **Legitimate Exception Record**: The explicit rule-level justification that allows a bounded deviation from native-by-default or shared-family rules.
- **Anti-Pattern Class**: A named review category for recurring UI drift that should be rejected or remediated consistently.
## Deliverables
- **D-200-001**: A constitution amendment that integrates the new Filament nativity, custom-surface, shared-family, state-layer, and exception rules into the existing UI constitution.
- **D-200-002**: A stable vocabulary and anti-pattern catalog covering native, fake-native, custom, shared detail micro-UI, shell or page or detail state, and legitimate exception.
- **D-200-003**: An explicit exception model for bounded custom surfaces and deliberate deviations from native-by-default rules.
- **D-200-004**: A mapping note that explains how Specs 196 through 199 feed the new constitution rules and how Spec 201 will consume them for enforcement.
- **D-200-005**: A close-out note that lists new clauses, amended clauses, and intentionally deferred enforcement follow-up.
## Success Criteria *(mandatory)*
### Measurable Outcomes
- **SC-200-001**: The amended constitution explicitly defines all nine required vocabulary terms from FR-200-002 with no unresolved placeholder or clarification marker.
- **SC-200-002**: During document review, a reviewer can classify one representative case from each of Specs 196, 197, 198, and 199 using only the amended constitution and the named anti-pattern or exception vocabulary.
- **SC-200-003**: The amended constitution contains explicit rule language for native-by-default behavior, fake-native prohibitions, shared-family contracts, page-state layering, shell-context layering, and legitimate exceptions.
- **SC-200-004**: The result integrates into the existing constitution model and does not create a parallel standalone rulebook for Filament-adjacent UI development.
- **SC-200-005**: The handoff to Spec 201 identifies the enforceable rule classes without requiring Spec 201 to invent new conceptual categories.
- **SC-200-006**: In acceptance review, a team member can explain when native is required, when custom is legitimate, how shared families are cut, and where state belongs after reading the amended constitution and this spec.
## Follow-up Assumptions
- Adjacent specs remain the authoritative evidence base for the specific repo cases this constitution extension names.
- Future code changes will update the constitution and follow-up specs rather than treating this vocabulary as optional review prose.
- Spec 201 will remain a separate enforcement slice instead of being partially absorbed into implementation PRs.

174
specs/200-filament-surface-rules/tasks.md Normal file
View File

@ -0,0 +1,174 @@
# Tasks: UI/UX Constitution Extension: Filament Nativity & Custom Surface Rules
**Input**: Design documents from `/specs/200-filament-surface-rules/`
**Prerequisites**: plan.md, spec.md, research.md, data-model.md, quickstart.md, contracts/constitution-governance-contract.md
**Tests**: N/A. This is a docs-only governance feature; no runtime or test-surface changes are planned in Spec 200.
## Test Governance Checklist
N/A for this docs-only governance feature. Keep the feature bounded to documentation and constitution artifacts only.
## Phase 1: Setup (Shared Context)
**Purpose**: Lock the implementation scope, amendment targets, and supporting source material before editing the constitution.
- [x] T001 Review `specs/200-filament-surface-rules/spec.md`, `specs/200-filament-surface-rules/plan.md`, and `specs/200-filament-surface-rules/research.md` to lock the amendment scope and Spec 201 deferrals.
- [x] T002 [P] Inspect `.specify/memory/constitution.md` and `docs/ui/operator-ux-surface-standards.md` to confirm the exact insertion points for `UI-FIL-001`, `UI-SURF-001`, `ACTSURF-001`, `HDR-001`, `UI-HARD-001`, `UI-EX-001`, `UI-REVIEW-001`, `Filament UI — Action Surface Contract`, and `UX-001`.
---
## Phase 2: Foundational (Blocking Prerequisites)
**Purpose**: Prepare the shared governance artifacts and validation scaffolding that all story work depends on.
**⚠️ CRITICAL**: No user story work should begin until this phase is complete.
- [x] T003 Align `specs/200-filament-surface-rules/contracts/constitution-governance-contract.md` with the agreed amendment targets, acceptance contract, and explicit no-runtime boundary before constitution edits begin.
- [x] T004 [P] Normalize the baseline amendment-target, vocabulary, anti-pattern, exception, and state-ownership definitions in `specs/200-filament-surface-rules/data-model.md`.
- [x] T005 [P] Expand `specs/200-filament-surface-rules/quickstart.md` with the baseline representative validation flow for Specs 196 through 199 and the explicit Spec 201 handoff.
**Checkpoint**: Amendment scope, supporting vocabulary, and deferred enforcement boundary are locked.
---
## Phase 3: User Story 1 - Classify Nativity And Exceptions Consistently (Priority: P1) 🎯 MVP
**Goal**: Make native-by-default, fake-native drift, and legitimate custom-surface exceptions reviewable through the constitution alone.
**Independent Test**: A reviewer can classify a fake-native dependency surface and a legitimate custom visualization using only the amended constitution and the representative cases from Spec 196.
- [x] T006 [US1] Amend `.specify/memory/constitution.md` in `UI-FIL-001` and `UI-HARD-001` to add explicit native-by-default language and fake-native prohibitions.
- [x] T007 [US1] Amend `.specify/memory/constitution.md` in `UI-EX-001` to define bounded legitimate custom-surface and nativity-exception rules.
- [x] T008 [US1] Add `Native Surface`, `Fake-Native Surface`, `Custom Surface`, `Legitimate Exception`, plus the `Filament Costume`, `Blade Request UI`, `Hand-Rolled Simple Overview`, and `Hidden Exception` catalog entries in `.specify/memory/constitution.md`.
- [x] T009 [US1] Amend `.specify/memory/constitution.md` in `UI-REVIEW-001` to add reviewer-facing nativity and exception-classification questions, then validate the amended language against `specs/196-hard-filament-nativity-cleanup/spec.md` and record any wording refinements in `specs/200-filament-surface-rules/quickstart.md`.
**Checkpoint**: Native and exception cases are classifiable without local review vocabulary.
---
## Phase 4: User Story 2 - Cut Shared Detail Families And State Layers Correctly (Priority: P1)
**Goal**: Make shared detail micro-UI families, host variation, and shell/page/detail state ownership explicit in the constitution.
**Independent Test**: A reviewer can classify shared-family drift and shell/page/detail state confusion using only the amended constitution and the representative cases from Specs 197 through 199.
- [x] T010 [US2] Amend `.specify/memory/constitution.md` in `UI-SURF-001`, `ACTSURF-001`, `HDR-001`, and `Filament UI — Action Surface Contract` to define shared detail micro-UI families, one-primary-interaction-model guidance, shared core zones, bounded host variation, and any related header-discipline clarifications.
- [x] T011 [US2] Amend `.specify/memory/constitution.md` in `UX-001` and adjacent UI sections to define shell/page/detail ownership plus requested, active, draft, inspect, and restorable state roles.
- [x] T012 [US2] Add `Shared Detail Micro-UI`, `Host`, `Global Context State`, `Page State`, `Detail State`, `Host Drift`, `State Layer Collapse`, and `Parallel Inspect Worlds` entries in `.specify/memory/constitution.md`.
- [x] T013 [US2] Amend `.specify/memory/constitution.md` in `UI-REVIEW-001`, `ACTSURF-001`, `HDR-001`, and `UI-HARD-001` review gates to add reviewer-facing shared-family and state-layer questions, then validate the amended language against `specs/197-shared-detail-contract/spec.md`, `specs/198-monitoring-page-state/spec.md`, and `specs/199-global-context-shell-contract/spec.md`, and record any refinements in `specs/200-filament-surface-rules/quickstart.md`.
**Checkpoint**: Shared-family and state-layer cases are classifiable without inventing a second taxonomy.
---
## Phase 5: User Story 3 - Prepare Enforcement Without Re-Inventing Rules (Priority: P2)
**Goal**: Leave a clean cross-spec mapping and enforcement handoff so Spec 201 can operationalize the rules directly.
**Independent Test**: A maintainer can derive Spec 201 enforcement targets from the amended constitution and feature artifacts without introducing new rule categories.
- [x] T014 [US3] Update `specs/200-filament-surface-rules/contracts/constitution-governance-contract.md` with the finalized cross-spec mapping and the deferred enforcement boundary for Spec 201.
- [x] T015 [P] [US3] Update `specs/200-filament-surface-rules/data-model.md` with the finalized `CrossSpecMapping` and exception-type relationships produced by the amended constitution.
- [x] T016 [P] [US3] Add the close-out summary of new clauses, tightened clauses, and intentionally deferred enforcement work to `specs/200-filament-surface-rules/quickstart.md`.
- [x] T017 [US3] Review `.specify/memory/constitution.md`, `specs/200-filament-surface-rules/contracts/constitution-governance-contract.md`, and `specs/200-filament-surface-rules/quickstart.md` together to verify that Spec 201 can consume the final vocabulary directly.
**Checkpoint**: The constitution amendment and Spec 201 handoff are aligned and explicit.
---
## Phase 6: Polish & Cross-Cutting Concerns
**Purpose**: Final alignment, wording cleanup, and end-to-end validation across all stories.
- [x] T018 [P] Align any remaining wording drift between `.specify/memory/constitution.md` and `docs/ui/operator-ux-surface-standards.md`.
- [x] T019 [P] Refresh `specs/200-filament-surface-rules/research.md` with any final amendment-target or rejected-alternative adjustments discovered during implementation.
- [x] T020 Run the representative-case walkthrough in `specs/200-filament-surface-rules/quickstart.md` against `.specify/memory/constitution.md` plus `specs/196-hard-filament-nativity-cleanup/spec.md`, `specs/197-shared-detail-contract/spec.md`, `specs/198-monitoring-page-state/spec.md`, and `specs/199-global-context-shell-contract/spec.md`.
- [x] T021 Clean up and cross-check `specs/200-filament-surface-rules/plan.md`, `specs/200-filament-surface-rules/contracts/constitution-governance-contract.md`, and `specs/200-filament-surface-rules/quickstart.md` so the final artifact set tells one consistent story.
---
## Dependencies & Execution Order
### Phase Dependencies
- **Setup (Phase 1)**: No dependencies.
- **Foundational (Phase 2)**: Depends on Setup completion and blocks all story work.
- **User Story 1 (Phase 3)**: Depends on Foundational completion.
- **User Story 2 (Phase 4)**: Depends on Foundational completion.
- **User Story 3 (Phase 5)**: Depends on User Stories 1 and 2 because the enforcement handoff must reflect the final amended rule language.
- **Polish (Phase 6)**: Depends on all user stories being complete.
### User Story Dependencies
- **US1 (P1)**: Can start immediately after Foundational and serves as the MVP slice.
- **US2 (P1)**: Can start after Foundational, but it edits the same constitution file as US1, so one implementer should do the core `.specify/memory/constitution.md` edits sequentially or split them by section ownership deliberately.
- **US3 (P2)**: Starts after US1 and US2 stabilize because it documents the final mapping and Spec 201 handoff.
### Within Each User Story
- Core `.specify/memory/constitution.md` edits should be completed before validation tasks for that story.
- Story validation tasks should feed any refinement updates into `specs/200-filament-surface-rules/quickstart.md`.
- Close-out and handoff tasks should only run after the governing constitution language is stable.
### Parallel Opportunities
- `T002` can run in parallel with `T001` after the feature scope is understood.
- `T004` and `T005` can run in parallel after `T003` establishes the final contract boundary.
- `T015` and `T016` can run in parallel once the final constitution wording from US1 and US2 is stable.
- `T018` and `T019` can run in parallel during Polish because they touch different files.
---
## Parallel Example: Foundational Work
```bash
# After T003 locks the final contract boundary:
Task: "Normalize the amendment-target, vocabulary, anti-pattern, exception, and state-ownership definitions in specs/200-filament-surface-rules/data-model.md"
Task: "Expand specs/200-filament-surface-rules/quickstart.md with the representative validation flow for Specs 196 through 199 and the explicit Spec 201 handoff"
```
---
## Parallel Example: User Story 3
```bash
# After US1 and US2 stabilize the final constitution wording:
Task: "Update specs/200-filament-surface-rules/data-model.md with the finalized CrossSpecMapping and exception-type relationships"
Task: "Add the close-out summary of new clauses, tightened clauses, and intentionally deferred enforcement work to specs/200-filament-surface-rules/quickstart.md"
```
---
## Implementation Strategy
### MVP First (User Story 1 Only)
1. Complete Phase 1: Setup.
2. Complete Phase 2: Foundational.
3. Complete Phase 3: User Story 1.
4. **STOP and VALIDATE**: Confirm a reviewer can classify a fake-native case and a legitimate custom case from the amended constitution alone.
### Incremental Delivery
1. Complete Setup + Foundational.
2. Add User Story 1 and validate nativity/exception classification.
3. Add User Story 2 and validate shared-family/state-layer classification.
4. Add User Story 3 and validate the Spec 201 handoff.
5. Finish with Polish and representative-case walkthrough.
### Parallel Team Strategy
With multiple contributors:
1. One contributor completes the contract-boundary task `T003`.
2. A second contributor can prepare `T004` while another prepares `T005`.
3. Once the constitution wording stabilizes, one contributor can finalize the contract note while another finalizes the close-out summary and data-model mapping.
---
## Notes
- `[P]` tasks are parallelizable because they touch different files and do not depend on unfinished work in the same artifact.
- User-story phases remain independently valuable, but US1 and US2 share `.specify/memory/constitution.md`, so section-level coordination matters.
- No runtime tests, CI rules, or lint/grep enforcement should be added under this task list; those remain reserved for Spec 201.