TenantAtlas/specs/200-filament-surface-rules/spec.md

# 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.