# Shopify Polaris
Use this after the Thorbis UI skill when the problem is a large collection, saved views, bulk operations, long forms, unsaved state, multi-edit, or a business-object detail workspace.
Thorbis remains Linear-first. Polaris contributes operational administration grammar, not visual styling.
## Keep
- Collection state belongs with the collection: search, filters, saved views, sort, columns.
- Tabs slice the current collection. They are not global navigation.
- `X` selects a row. Selection summons a visible bulk bar. Do not show bulk clutter before selection.
- Row identity is a real link. Do not add `View` to every row.
- Repeated same-field edits across many records may promote into a dedicated grid workspace.
- Dirty state is persistent and explicit. Save / Discard remains visible until resolved.
- Large forms use progressive disclosure and a durable route rather than a giant modal.
- Main content defines the resource; the inspector supports it with status, metadata and context.
- Workbench width follows data density. Focused forms keep a readable measure.
- One likely action stays visible, verb-led and concrete. Secondary actions stay quieter. Rare or destructive actions may use overflow, but critical actions must have a visible discoverable path.
- Saved views and column choices are operator preferences. Defaults remain canonical.
- Status is a word first, hue second.
- Timelines record meaningful evidence, not decorative activity.
## Refuse
- Shopify green, light Admin palette, exact radii, cards, shadows or typography.
- Card-of-cards page composition.
- Tabs as app navigation.
- Badge soup.
- Generic activity feeds everywhere.
- Giant modal forms.
- Spreadsheet editing when the task is really a single durable record.
- Consumer softness or a second shell.
## Thorbis collection contract
A collection workspace is:
`location → view bar → search/filter/saved view/sort/columns → rows → selection state → bulk bar`
Normal state is quiet. Selection is a mode.
If a filter combination matters repeatedly, let the operator save or pin it. Do not create a new module or sidebar destination for every useful slice.
## Thorbis dirty-state contract
When a durable form differs from its saved state:
1. Mark the view dirty immediately.
2. Keep Save and Discard persistently reachable.
3. Save names what it commits when ambiguity exists.
4. Navigation cannot silently lose edits.
5. Error stays with the field or save surface; do not pretend a failed save succeeded.
6. Successful save clears dirty state without moving the operator unless the workflow requires it.
Do not add autosave only to avoid designing this state.
## Thorbis multi-edit contract
Use multi-edit only when:
- more than one record is selected;
- the same fields are being compared/changed across records;
- row/column structure improves speed and accuracy;
- validation can be represented per cell or per row;
- there is a clear commit/discard state.
Otherwise use the normal Record workspace.
## Detail workspace
The resource identity, state and primary action remain stable. The main work area owns the defining workflow. The inspector owns supporting facts and relationships.
Do not mirror every main-section field into the inspector. Do not turn supporting metadata into equal cards that compete with the work.
## Payments
Polaris covers the admin, not the moment money is committed. For pay, deposit, invoice payment, and checkout flows, read the repository study `content/design/SHOPIFY_CHECKOUT_REFERENCE.md`. The UI skill still names the surface.
Source study: [Shopify Polaris](https://design.thorbis.com/research/studies/shopify-polaris). The repository study is `content/design/POLARIS_REFERENCE.md`.
Use this after the Thorbis UI skill when the problem is a large collection, saved views, bulk operations, long forms, unsaved state, multi-edit, or a business-object detail workspace.
Collection state belongs with the collection: search, filters, saved views, sort, columns.
Tabs slice the current collection. They are not global navigation.
X selects a row. Selection summons a visible bulk bar. Do not show bulk clutter before selection.
Row identity is a real link. Do not add View to every row.
Repeated same-field edits across many records may promote into a dedicated grid workspace.
Dirty state is persistent and explicit. Save / Discard remains visible until resolved.
Large forms use progressive disclosure and a durable route rather than a giant modal.
Main content defines the resource; the inspector supports it with status, metadata and context.
Workbench width follows data density. Focused forms keep a readable measure.
One likely action stays visible, verb-led and concrete. Secondary actions stay quieter. Rare or destructive actions may use overflow, but critical actions must have a visible discoverable path.
Saved views and column choices are operator preferences. Defaults remain canonical.
Status is a word first, hue second.
Timelines record meaningful evidence, not decorative activity.
Spreadsheet editing when the task is really a single durable record.
Consumer softness or a second shell.
Thorbis collection contract
A collection workspace is:
location → view bar → search/filter/saved view/sort/columns → rows → selection state → bulk bar
Normal state is quiet. Selection is a mode.
If a filter combination matters repeatedly, let the operator save or pin it. Do not create a new module or sidebar destination for every useful slice.
Thorbis dirty-state contract
When a durable form differs from its saved state:
Mark the view dirty immediately.
Keep Save and Discard persistently reachable.
Save names what it commits when ambiguity exists.
Navigation cannot silently lose edits.
Error stays with the field or save surface; do not pretend a failed save succeeded.
Successful save clears dirty state without moving the operator unless the workflow requires it.
Do not add autosave only to avoid designing this state.
Thorbis multi-edit contract
Use multi-edit only when:
more than one record is selected;
the same fields are being compared/changed across records;
row/column structure improves speed and accuracy;
validation can be represented per cell or per row;
there is a clear commit/discard state.
Otherwise use the normal Record workspace.
Detail workspace
The resource identity, state and primary action remain stable. The main work area owns the defining workflow. The inspector owns supporting facts and relationships.
Do not mirror every main-section field into the inspector. Do not turn supporting metadata into equal cards that compete with the work.
Payments
Polaris covers the admin, not the moment money is committed. For pay, deposit, invoice payment, and checkout flows, read the repository study content/design/SHOPIFY_CHECKOUT_REFERENCE.md. The UI skill still names the surface.
Source study: Shopify Polaris. The repository study is content/design/POLARIS_REFERENCE.md.
