fluentui-design 0.1.0

package/skills/fluentui-design/SKILL.md

@@ -0,0 +1,184 @@
+---
+name: fluentui-design
+description: Design, implement, and review coherent Fluent UI React v9 web applications. Use when composing pages, choosing surfaces (page, drawer, or dialog), arranging navigation, commands, forms, DataGrid or Table, tabs, feedback, and empty, loading, and error states for business and admin apps. Cross-links the API-focused fluentui skill for exact props and imports instead of copying API documentation.
+license: MIT
+---
+
+# Fluent UI Design
+
+This skill is the composition layer for Fluent UI React v9. It answers where a
+surface belongs, which regions a page needs, who owns state, and how the parts
+work together. It does not restate component props or imports; the sibling
+`fluentui` skill owns those exact API facts.
+
+Read this entry point first, then open only the references the task needs.
+
+## Triggers and non-triggers
+
+Use this skill when the task is about composition:
+
+- Choosing a surface: a page, a drawer, a dialog, or an inline editor.
+- Arranging navigation, page chrome, commands, and content regions.
+- Deciding state ownership, save model, or submit feedback.
+- Laying out forms, data grids, tabs, or multi-step task flows.
+- Reviewing accessibility, responsive behavior, or visual coherence.
+
+Do not use it for pure API lookup:
+
+- The exact props, types, imports, or slots of one component.
+- Token names or theme shape without a design question.
+- Version-specific API changes.
+
+For those, use the sibling `fluentui` skill. The entry point states that
+dependency in its description on purpose: the two skills are co-installed.
+
+## Reconnaissance
+
+Before proposing a design, inspect the project instead of assuming:
+
+- The installed `@fluentui/react-components` version, and whether it matches
+  the baseline in [Compatibility](#compatibility).
+- The React version. v9 peers on React `>=16.14.0` and `<20.0.0`.
+- Where `FluentProvider` is mounted and which theme it applies.
+- Existing page shells, layout patterns, and naming the app already uses.
+- Whether the sibling `fluentui` skill is available for exact API facts.
+
+If a project deviates from the baseline, say so and re-verify the rules you use.
+
+## Task classification
+
+Classify the request by the decision it contains, then load that reference.
+The generated [reference index](references/index.md) maps every decision to the
+patterns that resolve it.
+
+| The task sounds like | Load |
+| --- | --- |
+| "Build a new area of the app" | [PAT-001 application shell](references/patterns/PAT-001-application-shell.md) |
+| "Show a filterable list" | [PAT-002 list page](references/patterns/PAT-002-list-page.md) |
+| "Show one record and its actions" | [PAT-003 record detail](references/patterns/PAT-003-record-detail.md) |
+| "Create or edit an entity" | [PAT-004 form page](references/patterns/PAT-004-form-page.md) |
+| "Edit without leaving the list" | [PAT-005 contextual edit](references/patterns/PAT-005-contextual-edit.md) |
+| "Configure options" | [PAT-006 settings page](references/patterns/PAT-006-settings-page.md) |
+| "Walk through a wizard" | [PAT-007 multi-step task](references/patterns/PAT-007-multi-step-task.md) |
+| "Show metrics and trends" | [PAT-008 dashboard](references/patterns/PAT-008-dashboard.md) |
+
+Cross-cutting questions have their own references: composition and state in
+[foundation/composition-and-state.md](references/foundation/composition-and-state.md),
+styling in [foundation/styling-and-tokens.md](references/foundation/styling-and-tokens.md),
+accessibility in [foundation/accessibility.md](references/foundation/accessibility.md),
+and responsive and localization behavior in
+[foundation/responsive-and-localization.md](references/foundation/responsive-and-localization.md).
+
+When a request names an exact component prop, that part is a `fluentui` skill
+question. Answer the composition here, then hand off the API detail.
+
+## Design-before-code checklist
+
+Run the short sequence in
+[checklists/design-before-code.md](references/checklists/design-before-code.md)
+before writing components. In brief:
+
+1. Name the user task in one sentence.
+2. Choose the surface and say why the alternatives are worse.
+3. List the page regions in reading order.
+4. Decide state ownership and the save model.
+5. Decide the feedback for loading, empty, error, and success.
+6. Decide the responsive collapse and the permission state.
+7. Confirm the accessibility path for every action.
+
+A design that cannot answer all seven is not ready to implement.
+
+## Surface decision workflow
+
+Work from the task outward, not from a component inward.
+
+- **Page versus drawer versus dialog.** A full page owns a stable URL and
+  survives a refresh. A drawer keeps list context and suits a short edit. A
+  dialog interrupts for a small, focused decision. State the reason in the
+  pattern you choose.
+- **Data surface.** A `DataGrid` is for interactive, columnar data with
+  selection and sorting. A `Table` is for a small, mostly read-only set. The
+  rule ids are listed in the [rule index](references/rules/index.md).
+- **Region order.** Order regions as the user reads them: page header, command
+  bar, filters, content, then details. Each pattern states its region order.
+- **State ownership.** Keep server state in the data layer and view state in the
+  page. Lift state only to the lowest common owner. The patterns state where
+  each piece of state lives.
+- **Derived decisions.** Every pattern lists what the application still owns,
+  such as routing, validation, fetching, authorization, and persistence.
+
+## Implementation constraints
+
+- Use only exports that exist in the pinned package. The
+  [rule index](references/rules/index.md) is grounded in a verified allowlist;
+  when in doubt, confirm the export before using it.
+- Prefer semantic HTML and the component's own slots over DOM overrides.
+- Style with tokens and `makeStyles`. Do not hardcode colors, spacing, or
+  shadows that the theme should own.
+- Do not inject unsanitized HTML, and never suggest bypassing validation.
+- Keep API specifics out of this package. Link the `fluentui` skill instead of
+  copying a prop table.
+
+## Accessibility and visual review
+
+Accessibility is part of the design, not a later pass.
+
+- Every interactive element is reachable and operable by keyboard.
+- Opening and closing an overlay returns focus to the trigger.
+- Async results are announced, not only drawn.
+- Contrast, motion, zoom, and reflow are checked in the active theme.
+- Run the focused review in
+  [checklists/accessibility-review.md](references/checklists/accessibility-review.md)
+  and the visual pass in
+  [checklists/visual-review.md](references/checklists/visual-review.md).
+
+The [accessibility foundation](references/foundation/accessibility.md) explains
+the reasoning shared by every pattern.
+
+## Tradeoff explanation
+
+When a design choice has a real cost, say so plainly:
+
+- State the choice and the alternative you rejected.
+- Give the reason and the evidence, naming the rule that supports it.
+- State confidence and the condition that would change the answer.
+- Never present a convention as a requirement when it is only a preference.
+
+A pattern file lists the derived decisions so a tradeoff is attributed to the
+application, not to the component library.
+
+## Evidence fallback
+
+Evidence can be missing, outdated, or contradictory. Handle each case:
+
+- **Missing.** Say which fact is unverified, answer from the bundled rules and
+  patterns, and do not invent props.
+- **Outdated.** Compare the project version with [Compatibility](#compatibility)
+  and treat a newer install as unverified until re-pinned.
+- **Contradictory.** Prefer the rule with a higher confidence and a named
+  source, and surface the conflict instead of hiding it.
+- **Sibling skill absent.** Answer composition from this package, and state that
+  exact API facts could not be confirmed.
+
+To refresh the bundled facts, follow
+[maintenance/refresh-and-repin.md](references/maintenance/refresh-and-repin.md).
+
+## Compatibility
+
+| Item | Baseline |
+| --- | --- |
+| `@fluentui/react-components` | 9.74.7 |
+| React peer range | `>=16.14.0 <20.0.0` |
+| Pinned API-fact commit | `d595d79` |
+
+Rules and patterns are written against this baseline. A different installed
+version may still work, but its exports are not verified here until re-pinned.
+
+## When to re-browse and re-verify
+
+Re-verify when the installed Fluent UI version differs from the baseline, when a
+rule is disputed in review, or when a design depends on a fact that this package
+marks as unverified. Follow
+[maintenance/refresh-and-repin.md](references/maintenance/refresh-and-repin.md):
+refresh the sources, re-pin the facts commit, regenerate the indexes, and re-run
+the gates. Do not silently adjust a rule to match a newer library.

package/skills/fluentui-design/references/checklists/accessibility-review.md

@@ -0,0 +1,51 @@
+# Accessibility Review
+
+Run this pass after the feature works, and again before release. It covers the
+states that are easy to miss, not only the happy path.
+
+## Keyboard
+
+- Reach every action with the keyboard alone, in visual order.
+- Enter or Space activates the focused control, and Escape closes an overlay.
+- A grid, menu, or tab set behaves as one composite widget (RULE-021): one tab
+  stop enters it and arrows move within it.
+
+## Focus
+
+- Focus is always visible and never hidden behind a sticky header or overlay
+  (RULE-020).
+- Opening an overlay moves focus inside; closing it returns focus to the trigger.
+- Deleting or filtering an item moves focus to a sensible neighbour.
+- A route change moves focus to the new page heading.
+
+## Names and roles
+
+- Every icon-only control has an accessible name (RULE-022).
+- Every input has a programmatic label and, where needed, helper text
+  (RULE-005).
+- Errors are associated with the field they describe.
+
+## Announcements
+
+- A save, a filter change, and a failed submission are announced (RULE-016).
+- A loading state exposes a busy or status indication.
+
+## Visual
+
+- Text and non-text contrast pass in light, dark, and high-contrast themes.
+- Motion respects the reduced-motion preference (RULE-019).
+- The layout reflows under zoom and at a narrow width (RULE-023).
+- Truncated content exposes its full value (RULE-025).
+
+## States to exercise
+
+Test each of these, because each can break an assumption:
+
+- First load with no data.
+- Filter with no matches, distinct from no data.
+- A failed request with a retry.
+- A user without permission for an action.
+- A very long value in every column and field.
+
+See [accessibility foundation](../foundation/accessibility.md) for the reasoning
+behind each check.

package/skills/fluentui-design/references/checklists/design-before-code.md

@@ -0,0 +1,53 @@
+# Design Before Code
+
+Answer these questions before writing components. Each one has a home in a
+pattern or foundation reference; unresolved questions become rework.
+
+## 1. Name the task
+
+Write the user task in one sentence, in the user's words. If the sentence needs
+"and", the task is probably two tasks and should split.
+
+## 2. Choose the surface
+
+Pick a page, a drawer, a dialog, or an inline edit, and say why the others are
+worse. A page owns a URL and survives a refresh. A drawer keeps list context. A
+dialog interrupts for one small decision. See
+[PAT-004 form page](../patterns/PAT-004-form-page.md) and
+[PAT-005 contextual edit](../patterns/PAT-005-contextual-edit.md).
+
+## 3. List the regions
+
+List the page regions in reading order: header, command bar, filters, content,
+details. Each pattern names its regions and their order.
+
+## 4. Decide state ownership
+
+Decide who owns the draft, the selection, and the open overlay, using
+[composition-and-state](../foundation/composition-and-state.md). Lift state only
+to the lowest common owner.
+
+## 5. Decide the save model
+
+Choose explicit save, immediate apply, or a hybrid, and state the feedback for
+each outcome. Guard unsaved changes before they can be lost (RULE-029) and
+prevent duplicate submission (RULE-030).
+
+## 6. Decide the four states
+
+Design loading, empty, search-empty, and error explicitly (RULE-016). Decide
+where each appears inside the regions you listed.
+
+## 7. Decide the collapse and the permission state
+
+Decide how the layout reflows at a narrow width (RULE-023) and what a user
+without permission sees. A hidden action and a disabled action are different
+designs; choose deliberately.
+
+## 8. Confirm the accessibility path
+
+For every action, confirm the keyboard path, the accessible name, and the
+announcement of its result. Run
+[accessibility-review](accessibility-review.md) as the design exit check.
+
+When all eight are answered, the design is ready to implement.

package/skills/fluentui-design/references/checklists/visual-review.md

@@ -0,0 +1,45 @@
+# Visual Review
+
+Run this pass at two widths, in light and dark, before calling a page done.
+Visual coherence is what makes independently built pages look like one product.
+
+## Layout
+
+- Regions appear in the order the design lists them.
+- Spacing uses the token scale, not hand-set values.
+- Alignment is consistent between the header, the content, and the actions.
+- The page does not scroll horizontally at the narrow width.
+
+## Typography
+
+- Headings use the type ramp (RULE-018), with one heading per page that names
+  its task (RULE-003).
+- Body text and captions are legible in both themes.
+
+## Color and theme
+
+- Surfaces and text come from alias tokens, not hard-coded values (RULE-017).
+- The page is correct in light, dark, and high-contrast themes.
+- Emphasis uses one accent consistently, not several competing colors.
+
+## Commands and states
+
+- One primary action is visually dominant; the rest sit in a toolbar (RULE-004).
+- Disabled, loading, empty, search-empty, and error states all look intentional.
+- A pending action shows progress and prevents a second submission (RULE-030).
+
+## Motion
+
+- Transitions explain a change and are subtle.
+- Reduced motion removes animation rather than shortening it (RULE-019).
+
+## Direction and content
+
+- The layout mirrors correctly under right-to-left direction (RULE-024).
+- Long values wrap or truncate deliberately, and truncated values stay
+  reachable (RULE-025).
+- Translated text has room to grow.
+
+See [styling and tokens](../foundation/styling-and-tokens.md) and
+[responsive and localization](../foundation/responsive-and-localization.md) for
+the reasoning behind each check.

package/skills/fluentui-design/references/foundation/accessibility.md

@@ -0,0 +1,70 @@
+# Accessibility
+
+Accessibility is a property of the composition, not a checklist applied at the
+end. This reference explains the reasoning every pattern shares. For exact ARIA
+attributes and component props, use the sibling `fluentui` skill:
+[Dialog](fluentui:references/components/dialog.md).
+
+## Keyboard first
+
+Every action must be reachable and operable from the keyboard, in an order that
+follows the visual order. Test the path before shipping: open a surface, move
+through its actions, and close it without reaching for a pointer. A component
+that only works under a mouse is not finished.
+
+## Focus
+
+Keep focus visible and never obscure the focused control (RULE-020). Focus is
+the user's position in the page, so moving it without cause loses their place.
+The rules that matter most:
+
+- Opening an overlay moves focus into it; closing it returns focus to the
+  trigger.
+- Removing an item moves focus to a sensible neighbour, not to the top of the
+  page.
+- A route change moves focus to the new page heading.
+
+Follow the composite-widget keyboard model for grids, menus, and tabs
+(RULE-021): one tab stop enters the widget and arrow keys move within it.
+
+## Names, roles, and instructions
+
+Provide names, roles, and instructions for non-text content (RULE-022). An icon
+button needs an accessible name. A form field needs a programmatic label, not
+only a nearby visual one (RULE-005). An unfamiliar control needs an instruction
+that a screen reader can reach.
+
+## Announce asynchronous results
+
+A change that is drawn but not announced is invisible to a screen reader. When a
+save completes, a filter reduces the result count, or a submission fails, expose
+the result through a live region or a status message (RULE-016). The feedback
+channel is a design decision; the announcement is the accessibility obligation.
+
+## Overlays
+
+An overlay traps focus while it is open, is dismissible by Escape, and returns
+focus on close. Dialog suits a short, focused decision (RULE-008); a drawer
+suits a longer contextual edit (RULE-009). Both must behave the same way for the
+keyboard user.
+
+## Contrast, motion, zoom, and reflow
+
+- Check text and non-text contrast in light, dark, and high-contrast themes.
+- Respect reduced motion (RULE-019).
+- Ensure the layout survives zoom and a narrow viewport by reflowing rather than
+  clipping (RULE-023).
+- Give truncated content an accessible full value (RULE-025).
+
+## Review
+
+Use [checklists/accessibility-review.md](../checklists/accessibility-review.md)
+for the focused pass. It lists the states to exercise, including the ones that
+are easy to forget: empty, loading, error, and permission-denied.
+
+## Related references
+
+- [Responsive and localization](responsive-and-localization.md) for reflow and
+  direction.
+- [Composition and state](composition-and-state.md) for focus ownership across
+  regions.

package/skills/fluentui-design/references/foundation/composition-and-state.md

@@ -0,0 +1,92 @@
+# Composition and State
+
+Composition is the part of the design that Fluent UI React v9 does not decide for
+you. The library provides parts; your application decides how the parts form a
+page, who owns each piece of state, and what happens when the data is not ready.
+
+This reference supports
+[PAT-001 application shell](../patterns/PAT-001-application-shell.md) and the
+derived decisions every pattern lists. For exact component APIs, use the sibling
+`fluentui` skill: [Nav](fluentui:references/components/nav.md).
+
+## The shell is application-owned
+
+Fluent UI React v9 ships components, not an application shell. The shell — the
+persistent frame around every page — is a composition you own (RULE-001). A shell
+usually contains:
+
+- One `FluentProvider` at the root with an explicit theme and text direction
+  (RULE-026). Mount it once; do not nest providers to change one subtree.
+- Primary navigation for the top level of the hierarchy, and a breadcrumb or
+  page header for position within it (RULE-002).
+- A content region whose layout each page pattern defines.
+
+Because the shell is not a single export, treat it as an application-owned
+composition and keep it small. A shell that grows business rules has stopped
+being a shell.
+
+## Compose with public parts
+
+Build layout with `makeStyles` and the component's own slots (RULE-028). Reach
+for the DOM or internal class names only when the public surface cannot express
+the layout, and record why. Composing from public parts keeps a design readable
+and upgradeable.
+
+## State ownership
+
+Keep application state in the application (RULE-027). Fluent components own
+only the state a widget needs to function, such as whether a menu is open.
+Everything that outlives a widget belongs in your layer:
+
+| State | Owner |
+| --- | --- |
+| Fetched records and their cache | Data or query layer |
+| Form draft and validation | The form's page or hook |
+| Selection and sort in a grid | The list page |
+| Open overlay and its focus | The overlay's host component |
+| Theme and direction | The root provider |
+
+Lift state only to the lowest common owner. Moving state higher than necessary
+couples unrelated regions and makes both harder to test.
+
+## Decide the save model
+
+State the save model before building the form. The common shapes are:
+
+- **Explicit save** for a page form. The user edits a draft and commits with a
+  primary action.
+- **Immediate apply** for a setting. The change saves as it is made, and success
+  or failure is reported at once.
+- **Hybrid** for a settings page: immediate for cheap toggles, explicit save for
+  a group that must change together.
+
+Each pattern states which model it assumes and what the application still owns.
+
+## Server state versus view state
+
+Separate the two deliberately. Server state is fetched, cached, and possibly
+stale. View state is local and cheap. A grid that sorts server data re-queries
+when the sort changes (RULE-011); it does not sort only the loaded page. Keeping
+that distinction explicit is what makes paging, filtering, and selection
+predictable.
+
+## What the application owns
+
+Every pattern ends with the same reminder in different words: routing, data
+fetching, validation, authorization, and persistence are application
+responsibilities. Fluent UI React v9 renders them well; it does not implement
+them. When you explain a tradeoff, attribute those decisions to the application
+so no one looks for a component that does not exist.
+
+## Failure and readiness
+
+Design the state of the surface, not only its happy path. Loading, empty,
+search-empty, and error are four different states and each needs an explicit
+treatment (RULE-016). The composition decision is where each one appears: inside
+the content region, replacing the grid, or in a message region above it.
+
+## Related references
+
+- [Styling and tokens](styling-and-tokens.md) for the two-layer token model.
+- [Accessibility](accessibility.md) for focus and keyboard composition.
+- [Responsive and localization](responsive-and-localization.md) for reflow.

package/skills/fluentui-design/references/foundation/responsive-and-localization.md

@@ -0,0 +1,63 @@
+# Responsive and Localization
+
+A layout that only works at one width and one language is unfinished. This
+reference supports
+[PAT-002 list page](../patterns/PAT-002-list-page.md) and
+[PAT-008 dashboard](../patterns/PAT-008-dashboard.md).
+
+For the exact breakpoint and direction props, use the sibling `fluentui` skill:
+[FluentProvider](fluentui:references/components/fluentprovider.md).
+
+## Reflow, do not shrink
+
+Reflow content rather than shrinking it (RULE-023). Shrinking produces illegible
+text and unreachable controls. Reflowing changes the arrangement:
+
+- Columns collapse into a stacked detail view.
+- A filter bar collapses into a single control that opens a panel.
+- A wide grid becomes a list of records with a details region.
+
+Choose the collapse behaviour when you design the region, not when you discover
+the narrow width.
+
+## Logical properties for direction
+
+Use logical properties so a layout mirrors under right-to-left direction
+(RULE-024). Prefer inline-start and inline-end over left and right in margins,
+padding, and borders. A layout built with physical sides looks correct in one
+direction and broken in the other.
+
+Set the text direction once, at the root provider (RULE-026). Do not flip
+individual components; mirroring at the root is what keeps icons, alignment, and
+scrollbars consistent.
+
+## Long content and truncation
+
+Plan for long content and truncation with an accessible full value (RULE-025). A
+long name, a long email, and a long description all happen in real data. Decide
+per column:
+
+- Wrap when the value is short and the row can grow.
+- Truncate with an accessible full value when the row height must stay fixed.
+- Move the full value into a details view when the column cannot show it.
+
+Truncation without a way to read the full value is data loss, not a layout fix.
+
+## Content length across languages
+
+Translated text is often longer than the English source. Leave room for growth,
+and avoid layouts that depend on an exact string width. A button, a tab, or a
+column sized to the English label will break in another language. Size to the
+container and let the content wrap or truncate deliberately.
+
+## Verify at the edges
+
+Check at least two widths in every theme, and check the direction opposite to
+the one you designed in. The
+[visual review checklist](../checklists/visual-review.md) lists the states to
+cover, including the narrow and mirrored ones.
+
+## Related references
+
+- [Styling and tokens](styling-and-tokens.md) for theme-level values.
+- [Accessibility](accessibility.md) for zoom and reflow obligations.

package/skills/fluentui-design/references/foundation/styling-and-tokens.md

@@ -0,0 +1,71 @@
+# Styling and Tokens
+
+Fluent UI React v9 draws its visual consistency from a two-layer token model.
+Styling that respects that model adapts to theme, contrast, and brand without
+per-component overrides. This reference supports
+[PAT-006 settings page](../patterns/PAT-006-settings-page.md) and any pattern
+that renders chrome.
+
+For the exact token names and the `makeStyles` signature, use the sibling
+`fluentui` skill: [tokens](fluentui:references/tokens.md).
+
+## The two-layer token model
+
+There are two layers, and using the right one is the whole discipline
+(RULE-017):
+
+1. **Global tokens** hold raw values: a specific gray, a specific radius. They
+   are the palette.
+2. **Alias tokens** map a role to a palette value: a neutral background, a
+   brand stroke, a subtle shadow. Components use these.
+
+Style against alias tokens. A hard-coded color, spacing, or shadow bypasses the
+theme, so it survives a theme switch as a visible bug. When no alias fits, the
+answer is usually a design conversation, not a literal value.
+
+## Type
+
+Use the type ramp instead of ad-hoc font sizes (RULE-018). The ramp keeps
+heading, body, and caption sizes consistent across pages, and it already
+accounts for line height. A page that sets its own sizes drifts from every other
+page the moment the theme changes.
+
+## Motion
+
+Respect reduced motion (RULE-019). When a user asks for less motion, replace an
+animated transition with an instant change rather than a shorter animation.
+Motion should explain a change — an overlay appearing, a row leaving — never
+decorate it.
+
+## Dark and high-contrast themes
+
+Because alias tokens are resolved per theme, a design built from them works in
+light, dark, and high-contrast themes without changes. Check the three states
+that commonly break:
+
+- A hard-coded white surface disappears in a light theme.
+- A low-contrast border disappears against a dark surface.
+- A custom shadow reads as a smudge in high contrast.
+
+If a component genuinely needs a new role, add an alias in the theme rather than
+a literal in the component.
+
+## Layout spacing
+
+Prefer the layout components and tokenized gaps over hand-set margins. A
+consistent spacing scale is what makes two independently built pages look like
+one application. When you must choose a value, choose the token closest to the
+intent, and let the theme own it.
+
+## Boundaries with the API skill
+
+This reference explains which layer to use and why. It does not list token
+names, the `makeStyles` options, or the theme shape — those are API facts and
+belong to the sibling `fluentui` skill. Link them rather than copying them.
+
+## Related references
+
+- [Composition and state](composition-and-state.md) for where styling decisions
+  live.
+- [Responsive and localization](responsive-and-localization.md) for logical
+  properties and reflow.

package/skills/fluentui-design/references/index.md

@@ -0,0 +1,42 @@
+<!-- GENERATED FILE — DO NOT EDIT; source: skill/references/patterns + rules/rules.json -->
+
+# Reference Index
+
+This index is generated. Route by the decision you face, then open the pattern.
+For exact component props and imports, use the sibling `fluentui` skill
+(for example [Button](fluentui:references/components/button.md)).
+
+## Decisions
+
+| Decision | Patterns | Rules |
+| --- | --- | --- |
+| `command-scope` | PAT-001 | RULE-001, RULE-002, RULE-003 |
+| `data-processing-location` | PAT-002 | RULE-010, RULE-011, RULE-012, RULE-016 |
+| `data-resilience` | PAT-002, PAT-008 | RULE-003, RULE-010, RULE-011, RULE-012, RULE-015, RULE-016 |
+| `data-surface` | PAT-002 | RULE-010, RULE-011, RULE-012, RULE-016 |
+| `edit-surface` | PAT-005 | RULE-008, RULE-009, RULE-029 |
+| `feedback-channel` | PAT-008 | RULE-003, RULE-015, RULE-016 |
+| `field-annotation` | PAT-004 | RULE-005, RULE-006, RULE-007, RULE-029, RULE-030 |
+| `form-layout` | PAT-004 | RULE-005, RULE-006, RULE-007, RULE-029, RULE-030 |
+| `modal-behavior` | PAT-005 | RULE-008, RULE-009, RULE-029 |
+| `navigation-model` | PAT-001, PAT-006 | RULE-001, RULE-002, RULE-003, RULE-013, RULE-014 |
+| `permission-state` | PAT-003, PAT-008 | RULE-003, RULE-015, RULE-016, RULE-029 |
+| `progressive-disclosure` | PAT-006 | RULE-013, RULE-014 |
+| `row-activation` | PAT-002 | RULE-010, RULE-011, RULE-012, RULE-016 |
+| `save-model` | PAT-007 | RULE-029, RULE-030 |
+| `selection-scope` | PAT-002 | RULE-010, RULE-011, RULE-012, RULE-016 |
+| `submit-feedback` | PAT-004, PAT-007 | RULE-005, RULE-006, RULE-007, RULE-029, RULE-030 |
+| `virtualization` | PAT-002 | RULE-010, RULE-011, RULE-012, RULE-016 |
+
+## Application patterns
+
+| Pattern | Title | Decisions |
+| --- | --- | --- |
+| [PAT-001](patterns/PAT-001-application-shell.md) | Application shell | command-scope, navigation-model |
+| [PAT-002](patterns/PAT-002-list-page.md) | Searchable and filterable list page | data-surface, data-processing-location, selection-scope, row-activation, data-resilience, virtualization |
+| [PAT-003](patterns/PAT-003-record-detail.md) | Record detail page | permission-state |
+| [PAT-004](patterns/PAT-004-form-page.md) | Create and edit form page | form-layout, field-annotation, submit-feedback |
+| [PAT-005](patterns/PAT-005-contextual-edit.md) | Short contextual edit in a drawer or focused dialog | edit-surface, modal-behavior |
+| [PAT-006](patterns/PAT-006-settings-page.md) | Settings page with optional advanced sections | progressive-disclosure, navigation-model |
+| [PAT-007](patterns/PAT-007-multi-step-task.md) | Multi-step task with review and preserved state | save-model, submit-feedback |
+| [PAT-008](patterns/PAT-008-dashboard.md) | Dashboard whose content reflects actual tasks and data | feedback-channel, data-resilience, permission-state |