@ai-matrx/records-ui 0.85.9 → 0.85.10

package/dist/index.d.cts

@@ -1,7 +1,7 @@
 import * as react from 'react';
 import { ReactNode, ComponentType, RefObject } from 'react';
 import * as _ai_matrx_records from '@ai-matrx/records';
-import { PermissionLevel, Table, RecordScopeContext, EnrichCell, RecordsError, Uuid as Uuid$1, StoreFilter, AggregateFilter, Field, RecordDocument, ReadRow, RelationDisplay, WriteConflict, RecordsErrorCode, TableDecorations, DeclarableFieldKind, ParityFieldType, NewFieldDeclaration, RuleExpression, HiddenFieldNotice, ValueEnvelope, ChecklistRequirementKind, ContextPolicy, WorkDueState, FieldSensitivity, StageRuleOnFail, SubscriptionCadence, WorkApprovalState, WorkInboxKind, FieldKind, RecordFilter, RecordsResult, SavedViewRow, ArchiveLane, ArchivedRow, WorkInboxView, WorkInboxItem, FormSummary, PortalCard, PortalPrincipal, PortalPreviewRow, MySubscription, DashboardBlockKind, AggregateBucket, AggregateMeasure, AggregateCompare, DashboardTarget, DashboardBlock, DashboardSummary, DocTemplateRow, DocRenderRow, QuietHours, DashboardBlockResult, ChecklistRunStep, BookingSummary, CaptureSheetFace, CaptureField, AnonTokenBinding, RecordsConfig, RecordsActor, RecordsDataSource, HistoryActor, FieldHistoryEntry } from '@ai-matrx/records';
+import { PermissionLevel, Table, RecordScopeContext, EnrichCell, RecordsError, Uuid as Uuid$1, StoreFilter, AggregateFilter, Field, RecordDocument, ReadRow, RelationDisplay, WriteConflict, RecordsErrorCode, TableDecorations, RecordFilter, RuleExpression, RecordsResult, SavedViewRow, DeclarableFieldKind, ParityFieldType, NewFieldDeclaration, HiddenFieldNotice, ValueEnvelope, ChecklistRequirementKind, ContextPolicy, WorkDueState, FieldSensitivity, StageRuleOnFail, SubscriptionCadence, WorkApprovalState, WorkInboxKind, FieldKind, ArchiveLane, ArchivedRow, WorkInboxView, WorkInboxItem, FormSummary, PortalCard, PortalPrincipal, PortalPreviewRow, MySubscription, DashboardBlockKind, AggregateBucket, AggregateMeasure, AggregateCompare, DashboardTarget, DashboardBlock, DashboardSummary, DocTemplateRow, DocRenderRow, QuietHours, DashboardBlockResult, ChecklistRunStep, BookingSummary, CaptureSheetFace, CaptureField, AnonTokenBinding, RecordsConfig, RecordsActor, RecordsDataSource, HistoryActor, FieldHistoryEntry } from '@ai-matrx/records';
 import { Uuid, StoreFilter as StoreFilter$1, Field as Field$1, ReadRow as ReadRow$1 } from '@ai-matrx/records/react';
 import { RecordsClient } from '@ai-matrx/records/core';
 export { DEFAULT_FIELDS, DeclareResult, NewFieldSpec, NewTableSpec, addFields, declareTable, fieldDeclarationFor, tokenFor } from '@ai-matrx/records/core';
@@ -650,6 +650,7 @@ declare function useRowRights(rowIds: Uuid$1[], enabled: boolean): (rowId: Uuid$
  *   `retention_days`                     a document key, snake_case
  *   `8f2c1b0a-…`                         a uuid
  *   `23514` / `PT409`                    a SQLSTATE
+ *   `STORE-TAILS-3:` / `UI-FIX-19:`      a build lane's tag (UI-FIX-19)
  */
 declare const MACHINE_IDENTITY: RegExp[];
 /** Whether any shape above appears in this text. */
@@ -1227,12 +1228,292 @@ declare function styleFromDecorations(decorations: TableDecorations | null | und
  */
 declare function resolveTableStyle(decorations: TableDecorations | null | undefined, fields: readonly Field[], viewStyle: TableStyle | undefined): TableStyle;
 
+/** The four ways one saved view can be looked at (SCR-6). */
+declare const VIEW_LAYOUTS: readonly ["grid", "kanban", "calendar", "gallery"];
+type ViewLayout = (typeof VIEW_LAYOUTS)[number];
+declare const LAYOUT_LABEL: Record<ViewLayout, string>;
+/**
+ * What each layout needs before it can draw anything, in one sentence a screen
+ * prints. A layout that is missing its Field says so instead of rendering an
+ * empty board that looks like "no records".
+ */
+declare const LAYOUT_NEEDS: Record<ViewLayout, string | null>;
+/** One sort clause. The Field's key and a direction; nothing else is a sort. */
+interface ViewSort {
+    field: string;
+    direction: "asc" | "desc";
+}
+/** How a saved view is ordered: by hand, by its sort, or it never said (the same as sorted). */
+type ViewOrder = "manual" | "sorted" | null;
+/**
+ * THE DECLARATIVE SPEC. An agent writes this whole object; a person tweaks it.
+ * Every builder component in this package takes one of these as a prop.
+ */
+interface SavedViewSpec {
+    name: string;
+    /** The Table this view looks at. */
+    subject: Uuid$1;
+    layout: ViewLayout;
+    /** Kanban: the Field whose value becomes a column. */
+    groupField?: string | null;
+    /**
+     * Kanban: a number Field to TOTAL under each column heading. It lives on the VIEW for
+     * the same reason the colours do — two people read one board two ways and neither
+     * reading is a fact about the records.
+     */
+    measure?: string | null;
+    /**
+     * Kanban: the Field whose values cut the board into SWIMLANES across the columns — a
+     * dispatcher's board by Status, one lane per Technician (S1-PRIME VIEW-KEYS). Never the
+     * column Field itself; the store refuses that.
+     */
+    swimlaneField?: string | null;
+    /** Kanban: the columns this view keeps shut to a strip, by the column's stored value. */
+    collapsedColumns?: string[];
+    /** Calendar: the Field that places a record in the month. */
+    dateField?: string | null;
+    /** Gallery: the Field shown large on the card. */
+    imageField?: string | null;
+    sorts?: ViewSort[];
+    /**
+     * HOW THE VIEW IS ORDERED (ORDER-FIX): `"manual"` — the positions a person set by hand ARE the
+     * view's sort, and it carries no `sorts`; `"sorted"` or null — by `sorts`. READ ONLY: the store
+     * writes "manual" only when the rows are placed (`custom.view_record_order_set`) and turns it
+     * off itself when a sort is saved, so no patch ever sends it (`viewSettingsPatch` does not).
+     */
+    order?: ViewOrder;
+    /**
+     * The membership Rule. The STORE decides who is in this view; this is a
+     * reference to its Rule record, never a predicate this package evaluates.
+     */
+    ruleId?: Uuid$1 | null;
+    /**
+     * THE FLAT FILTER a digest or a notify rule wrote the view with — the one shape
+     * `custom.record_filter_sql` compiles, by Field KEY. A view saved in the bar has
+     * none; a view saved by `DigestScheduler` ("where Status is Open") does, and the
+     * grid and the board show exactly the records it names.
+     */
+    filters?: RecordFilter;
+    /**
+     * S2-PRIME — THE VIEW'S OWN QUESTION, as the condition builder writes it: the store's Rule
+     * shape `{op, args}`, ALL / ANY / NOT groups nested to any depth, Fields by id. Kept in the
+     * definition as `where` and asked of the store unchanged — the grid's list door, the board's
+     * headings and the dashboard's numbers compile it into the one WHERE clause
+     * (`custom.record_filter_sql`). Never stored under `filters`: that key is the flat map the
+     * digests and the notifier read, and they would refuse it by name.
+     */
+    where?: RuleExpression | null;
+    isDefault?: boolean;
+    /**
+     * HOW THIS VIEW LOOKS — its colors, its per-column formats and its frozen
+     * column (`presentation.ts`).
+     *
+     * It lives on the VIEW and not on the Fields because two people read one
+     * table two ways and neither reading is a fact about the records; it lives on
+     * a RECORD, not a new column, because that is what makes it something an
+     * agent writes with the same `records` tool as everything else.
+     */
+    presentation?: GridPresentation;
+}
+/**
+ * A saved view as it comes back out of the store, with its row's own id.
+ *
+ * It carries no version: `custom.view_declare` MERGES one key at a time, so two
+ * tabs pressing two different controls on one view both stand, and one control
+ * pressed in both keeps the latest — how Airtable and Notion keep a view change.
+ */
+interface SavedView extends SavedViewSpec {
+    id: Uuid$1;
+    /** Where the view came from when it was moved in (the mover, the S0 repair), else null. */
+    movedFrom: Record<string, unknown> | null;
+    /**
+     * THE WAY THIS TABLE IS MEANT TO BE LOOKED AT, when somebody decided one — a layout id the
+     * host draws (`sheet`), read off the stored kind before `layout` folds it to the four the
+     * package draws. Null when nobody designated one. See `designatedLayoutOf`.
+     */
+    designatedLayout?: string | null;
+}
+/**
+ * WHICH LAYOUT A VIEW WAS DESIGNATED, OR NULL (lane DATA-V2-FACE, owner 2026-09-24).
+ *
+ * "For something like my data tables, which are predetermined with a default view of 'Sheet'
+ * I want to see … it just shows them the way it should in the default view. That's how you take
+ * custom systems and fake like they're hard-coded builtin systems."
+ *
+ * A designation is a DELIBERATE write, never a click: a view whose stored kind is a layout the
+ * HOST draws (`sheet` — a layout the store's view-keys registry declares, and one the layout
+ * buttons never write onto a view). That is the ONE way a table is designated (lane
+ * VIEW-KEYS-SHEET): the mover and the repair write `layout: "sheet"` on a copied older table's
+ * default view; `moved_from` says only where a view came from and designates nothing. A package
+ * kind (`grid`, `kanban`, …) is not a designation: picking Kanban writes `layout: "kanban"` onto
+ * the view, and a click must never take the layout chooser away.
+ */
+declare function designatedLayoutOf(definition: Record<string, unknown> | null | undefined): string | null;
+/**
+ * HOW THE TABLE OPENS, decided once from its default view and the layouts the host draws.
+ *
+ *   · `designated` — the default view names a host layout this host registered: the page opens
+ *     IN it and offers no other layout by default (the others sit in the page's one menu);
+ *   · `chooser`    — nothing designated (or the host does not draw what was designated): the
+ *     page opens on the view's own layout and shows the layout chooser.
+ *
+ * Only the DEFAULT view designates: a person who opens another saved view is choosing, and the
+ * chooser is theirs.
+ */
+type TableOpening = {
+    kind: "designated";
+    hostLayout: string;
+} | {
+    kind: "chooser";
+};
+declare function tableOpening(view: Pick<SavedView, "isDefault" | "designatedLayout"> | null | undefined, hostLayoutIds: readonly string[]): TableOpening;
+/**
+ * THE TABLE'S DEFAULT VIEW WHEN MORE THAN ONE SAYS IT IS (lane DATA-V2-FACE-2).
+ *
+ * Two views can both claim the default: the mover's designated one (the older table's own, the
+ * Sheet) and a page seed that a later move of the view bar's older store brings in beside it —
+ * both named "All records", so the store's name order cannot tell them apart. A designation is a
+ * deliberate write and a seed is not, so the designated default wins; then the first default.
+ */
+declare function defaultViewOf<V extends Pick<SavedView, "isDefault" | "designatedLayout">>(views: readonly V[]): V | undefined;
+/**
+ * WHICH FIELD EACH LAYOUT CAN BE DRAWN FROM, decided from the FIELD'S OWN
+ * DECLARATION and never from the values it happens to hold.
+ *
+ * A kanban makes columns from a choice: the Field whose value is one of a
+ * closed set (FLD-5 / FLD-6 — a pick-list is a Table, and a select stores the
+ * id of one of its records). Grouping by a free-text Field produces one column
+ * per record, which is not a board. A calendar places a record in time, so it
+ * needs a Field that holds a date.
+ *
+ * These two answers are here, beside the layouts, because the picker on the
+ * screen and any agent writing a view spec must agree about what is offerable.
+ */
+declare const LAYOUT_FIELD_KIND: Record<ViewLayout, "choice" | "date" | null>;
+/**
+ * ─────────────────────────────────────────────────────────────────────────────
+ * WHICH VIEW A LINK NAMES — the address bar as a first-class control.
+ *
+ * 🚨 THE DEFECT THIS CLOSES (lane FRONT-DOOR, 2026-09-21; VERIFIER-8 HIGH-2).
+ * `/data-v2/<table>?view=kanban` returned 200 and rendered THE GRID. The
+ * switcher was there, the four buttons worked, and the parameter was read by
+ * nobody — so a person who bookmarked a board, or sent one to a colleague, got
+ * a grid, and nothing on the screen said the view had been dropped. A link that
+ * does not land is the inbox-link defect (`activeRecordId`) and the dashboard
+ * defect (`activeDashboardId`) for the third time, so this is the same shape of
+ * fix: the URL names it, the page opens on it, and the URL FOLLOWS the person
+ * when they pick another.
+ *
+ * The dashboards are a fifth value and not a special case: to the person, "the
+ * dashboard" is one of the ways to look at this table, and a link to it has to
+ * work like a link to the board.
+ */
+/**
+ * 🚨 `archived` IS THE SIXTH VALUE, AND IT IS NOT A SPECIAL CASE EITHER (lane
+ * FIX-10A-ARCHIVE, 2026-09-22; VERIFIER-10 F4).
+ *
+ * Archiving a record used to be a ONE-WAY DOOR: the grid's row action soft-
+ * deletes correctly — `deleted_at` set, version bumped, nothing removed — and
+ * then no screen anywhere in the platform could bring it back. The store's
+ * `custom.record_restore` was there the whole time and did exactly the right
+ * thing; nothing reached it, because every read door answers live rows only.
+ *
+ * So the archive is a WAY OF LOOKING AT THIS TABLE, like the board and the
+ * dashboards, reached by the same row of buttons and named by the same
+ * `?view=` parameter — never a Trash area of the app somebody has to know
+ * exists, and never a per-table screen. Every Table inherits it the moment it
+ * is in this list.
+ */
+declare const PAGE_VIEWS: readonly ["grid", "kanban", "calendar", "gallery", "dashboards", "archived"];
+type PageView = (typeof PAGE_VIEWS)[number];
+declare const PAGE_VIEW_LABEL: Record<PageView, string>;
+/**
+ * What a `?view=` value means, or `null` when it means nothing here.
+ *
+ * `null` is NOT "show the grid": the caller is expected to say that the link
+ * named something this table has no view for, because silently substituting a
+ * different view is exactly the defect above wearing a parser.
+ */
+declare function pageViewFromParam(raw: string | null | undefined): PageView | null;
+/** The sentence a link that named a view nobody has says. Never silent. */
+declare function unknownViewLine(raw: string): string;
+/** The one sentence a layout says when the table holds no Field it could use. */
+declare const LAYOUT_NO_FIELD: Record<ViewLayout, string>;
+/**
+ * THE SPEC AS THE ONE DEFINITION `platform.saved_view` HOLDS — the keys
+ * `custom.view_declare` documents, by Field KEY. `subject` is not in it: the door
+ * takes the Table as its own argument and writes `table_id` itself.
+ */
+declare function viewDocument(spec: SavedViewSpec): Record<string, unknown>;
+/**
+ * One row of `custom.views` back into the spec a screen and an agent both read — THROUGH THE ONE
+ * ACCESSOR (`viewSettings`, viewKeys.ts), so every layout sees every declared key the same way.
+ */
+declare function viewFromRow(row: SavedViewRow): SavedView;
+/**
+ * SAVE ONE NEW VIEW of a Table — the bar's "New view" and an agent's seed spec.
+ * One `view_declare` with no `view_id`; the answer is the new view's id.
+ */
+declare function declareView(client: Pick<RecordsClient, "viewDeclare">, spec: SavedViewSpec): Promise<RecordsResult<Uuid$1>>;
+/**
+ * WRITE A CHANGE ONTO A SAVED VIEW, AND KEEP IT.
+ *
+ * `custom.view_declare` with the view's id MERGES: only the keys in `patch` are
+ * written, a key cleared to null is removed, and everything the patch did not
+ * name — the grid's own choices, a hand-set order, where the view was moved from,
+ * a colour set in another tab — stays exactly as it was (S0, 2026-09-23: the door
+ * used to rebuild the whole definition from what one press sent).
+ *
+ * There is no version to be stale against (VERIFIER-15 M4 is closed by the shape,
+ * not by a retry): a saved view is a person's own arrangement of a table, and
+ * their latest press on a control is the one that stands. A refusal — the view
+ * was removed, or belongs to a table this person cannot open — is handed back for
+ * the page to say through the one notice.
+ */
+declare function saveViewPatch(client: Pick<RecordsClient, "viewDeclare">, tableId: Uuid$1, viewId: Uuid$1, patch: Partial<SavedViewSpec>): Promise<RecordsResult<Uuid$1>>;
+/**
+ * A PARTIAL change to a saved view, as the definition keys the door merges. Only
+ * the keys the caller actually changed are sent; a Field cleared (a board with no
+ * "Group by") is sent as `null`, which the door removes.
+ */
+declare function viewPatchDocument(patch: Partial<SavedViewSpec>): Record<string, unknown>;
+
+/** A column sort as the grid holds it: the Field key and a direction. */
+interface ColumnSort {
+    field: string;
+    direction: "asc" | "desc";
+}
+
 /**
  * WHAT A TABLE WITH NO COLUMNS SAYS. Named here because the gate asserts on it:
  * the state it describes is what a first-time person met for two days.
  */
 declare const NO_COLUMNS_YET = "This table has no columns yet";
 declare const NO_COLUMNS_WHY: string;
+/**
+ * THE OPEN VIEW'S ORDER (lane GRID-MANUAL). A saved view is ordered by its sort OR by hand, never
+ * both (the store's rule, ORDER-FIX). The grid is told which view it is drawing only for this: the
+ * hand order lives on the view's row and is read and written through the view's own doors
+ * (`custom.read_records_in_view_order`, `custom.view_record_order_set`). Left out, the grid is
+ * ordered by the table's own sort exactly as before, and offers no Reorder.
+ */
+interface GridViewOrder {
+    viewId: Uuid;
+    /** The view's own order word (`definition.order`). */
+    order: ViewOrder;
+    /** The view's own sort (`definition.sorts`) — where a sorted view OPENS, over the table's. */
+    sorts?: readonly ViewSort[] | undefined;
+    /**
+     * The rows were placed by hand (Reorder → Save): the store made the view manual and removed its
+     * sort. The host updates the view it holds. Unbound, Reorder is ABSENT — never a dead button.
+     */
+    onPlaced?: (() => void) | undefined;
+    /**
+     * "Use this sort instead": the host writes the sort onto the view (`custom.view_declare` with
+     * `sorts`), which turns the hand order off in the store. Unbound, the control is ABSENT.
+     */
+    onUseSort?: ((sort: ColumnSort) => void) | undefined;
+}
 interface GridProps {
     tableId: Uuid;
     /** Rows per page. The table's own pagination handles the rest. */
@@ -1301,9 +1582,11 @@ interface GridProps {
      * state — they are simply not remembered.
      */
     onPresentationChange?: ((next: GridPresentation) => void) | undefined;
+    /** The open view's order — its hand-set order or its sort (`GridViewOrder`). */
+    viewOrder?: GridViewOrder | undefined;
     className?: string | undefined;
 }
-declare function Grid({ tableId, pageSize, filter, onOpenRecord, onAddField, onNewRecordForm, toolbarActions, editable, presentation, onPresentationChange, className, onAskWhoChanged, }: GridProps): react.JSX.Element;
+declare function Grid({ tableId, pageSize, filter, onOpenRecord, onAddField, onNewRecordForm, toolbarActions, editable, presentation, onPresentationChange, viewOrder, className, onAskWhoChanged, }: GridProps): react.JSX.Element;
 /**
  * One Field becomes one column. The header is the Field's own NAME — never its
  * key (`names.ts`) — and the cell is the value, rendered by its parity type and
@@ -2042,247 +2325,6 @@ interface TrackedVersion {
     note: (version: number) => void;
 }
 
-/** The four ways one saved view can be looked at (SCR-6). */
-declare const VIEW_LAYOUTS: readonly ["grid", "kanban", "calendar", "gallery"];
-type ViewLayout = (typeof VIEW_LAYOUTS)[number];
-declare const LAYOUT_LABEL: Record<ViewLayout, string>;
-/**
- * What each layout needs before it can draw anything, in one sentence a screen
- * prints. A layout that is missing its Field says so instead of rendering an
- * empty board that looks like "no records".
- */
-declare const LAYOUT_NEEDS: Record<ViewLayout, string | null>;
-/** One sort clause. The Field's key and a direction; nothing else is a sort. */
-interface ViewSort {
-    field: string;
-    direction: "asc" | "desc";
-}
-/**
- * THE DECLARATIVE SPEC. An agent writes this whole object; a person tweaks it.
- * Every builder component in this package takes one of these as a prop.
- */
-interface SavedViewSpec {
-    name: string;
-    /** The Table this view looks at. */
-    subject: Uuid$1;
-    layout: ViewLayout;
-    /** Kanban: the Field whose value becomes a column. */
-    groupField?: string | null;
-    /**
-     * Kanban: a number Field to TOTAL under each column heading. It lives on the VIEW for
-     * the same reason the colours do — two people read one board two ways and neither
-     * reading is a fact about the records.
-     */
-    measure?: string | null;
-    /**
-     * Kanban: the Field whose values cut the board into SWIMLANES across the columns — a
-     * dispatcher's board by Status, one lane per Technician (S1-PRIME VIEW-KEYS). Never the
-     * column Field itself; the store refuses that.
-     */
-    swimlaneField?: string | null;
-    /** Kanban: the columns this view keeps shut to a strip, by the column's stored value. */
-    collapsedColumns?: string[];
-    /** Calendar: the Field that places a record in the month. */
-    dateField?: string | null;
-    /** Gallery: the Field shown large on the card. */
-    imageField?: string | null;
-    sorts?: ViewSort[];
-    /**
-     * The membership Rule. The STORE decides who is in this view; this is a
-     * reference to its Rule record, never a predicate this package evaluates.
-     */
-    ruleId?: Uuid$1 | null;
-    /**
-     * THE FLAT FILTER a digest or a notify rule wrote the view with — the one shape
-     * `custom.record_filter_sql` compiles, by Field KEY. A view saved in the bar has
-     * none; a view saved by `DigestScheduler` ("where Status is Open") does, and the
-     * grid and the board show exactly the records it names.
-     */
-    filters?: RecordFilter;
-    /**
-     * S2-PRIME — THE VIEW'S OWN QUESTION, as the condition builder writes it: the store's Rule
-     * shape `{op, args}`, ALL / ANY / NOT groups nested to any depth, Fields by id. Kept in the
-     * definition as `where` and asked of the store unchanged — the grid's list door, the board's
-     * headings and the dashboard's numbers compile it into the one WHERE clause
-     * (`custom.record_filter_sql`). Never stored under `filters`: that key is the flat map the
-     * digests and the notifier read, and they would refuse it by name.
-     */
-    where?: RuleExpression | null;
-    isDefault?: boolean;
-    /**
-     * HOW THIS VIEW LOOKS — its colors, its per-column formats and its frozen
-     * column (`presentation.ts`).
-     *
-     * It lives on the VIEW and not on the Fields because two people read one
-     * table two ways and neither reading is a fact about the records; it lives on
-     * a RECORD, not a new column, because that is what makes it something an
-     * agent writes with the same `records` tool as everything else.
-     */
-    presentation?: GridPresentation;
-}
-/**
- * A saved view as it comes back out of the store, with its row's own id.
- *
- * It carries no version: `custom.view_declare` MERGES one key at a time, so two
- * tabs pressing two different controls on one view both stand, and one control
- * pressed in both keeps the latest — how Airtable and Notion keep a view change.
- */
-interface SavedView extends SavedViewSpec {
-    id: Uuid$1;
-    /** Where the view came from when it was moved in (the mover, the S0 repair), else null. */
-    movedFrom: Record<string, unknown> | null;
-    /**
-     * THE WAY THIS TABLE IS MEANT TO BE LOOKED AT, when somebody decided one — a layout id the
-     * host draws (`sheet`), read off the stored kind before `layout` folds it to the four the
-     * package draws. Null when nobody designated one. See `designatedLayoutOf`.
-     */
-    designatedLayout?: string | null;
-}
-/**
- * WHICH LAYOUT A VIEW WAS DESIGNATED, OR NULL (lane DATA-V2-FACE, owner 2026-09-24).
- *
- * "For something like my data tables, which are predetermined with a default view of 'Sheet'
- * I want to see … it just shows them the way it should in the default view. That's how you take
- * custom systems and fake like they're hard-coded builtin systems."
- *
- * A designation is a DELIBERATE write, never a click: a view whose stored kind is a layout the
- * HOST draws (`sheet` — a layout the store's view-keys registry declares, and one the layout
- * buttons never write onto a view). That is the ONE way a table is designated (lane
- * VIEW-KEYS-SHEET): the mover and the repair write `layout: "sheet"` on a copied older table's
- * default view; `moved_from` says only where a view came from and designates nothing. A package
- * kind (`grid`, `kanban`, …) is not a designation: picking Kanban writes `layout: "kanban"` onto
- * the view, and a click must never take the layout chooser away.
- */
-declare function designatedLayoutOf(definition: Record<string, unknown> | null | undefined): string | null;
-/**
- * HOW THE TABLE OPENS, decided once from its default view and the layouts the host draws.
- *
- *   · `designated` — the default view names a host layout this host registered: the page opens
- *     IN it and offers no other layout by default (the others sit in the page's one menu);
- *   · `chooser`    — nothing designated (or the host does not draw what was designated): the
- *     page opens on the view's own layout and shows the layout chooser.
- *
- * Only the DEFAULT view designates: a person who opens another saved view is choosing, and the
- * chooser is theirs.
- */
-type TableOpening = {
-    kind: "designated";
-    hostLayout: string;
-} | {
-    kind: "chooser";
-};
-declare function tableOpening(view: Pick<SavedView, "isDefault" | "designatedLayout"> | null | undefined, hostLayoutIds: readonly string[]): TableOpening;
-/**
- * THE TABLE'S DEFAULT VIEW WHEN MORE THAN ONE SAYS IT IS (lane DATA-V2-FACE-2).
- *
- * Two views can both claim the default: the mover's designated one (the older table's own, the
- * Sheet) and a page seed that a later move of the view bar's older store brings in beside it —
- * both named "All records", so the store's name order cannot tell them apart. A designation is a
- * deliberate write and a seed is not, so the designated default wins; then the first default.
- */
-declare function defaultViewOf<V extends Pick<SavedView, "isDefault" | "designatedLayout">>(views: readonly V[]): V | undefined;
-/**
- * WHICH FIELD EACH LAYOUT CAN BE DRAWN FROM, decided from the FIELD'S OWN
- * DECLARATION and never from the values it happens to hold.
- *
- * A kanban makes columns from a choice: the Field whose value is one of a
- * closed set (FLD-5 / FLD-6 — a pick-list is a Table, and a select stores the
- * id of one of its records). Grouping by a free-text Field produces one column
- * per record, which is not a board. A calendar places a record in time, so it
- * needs a Field that holds a date.
- *
- * These two answers are here, beside the layouts, because the picker on the
- * screen and any agent writing a view spec must agree about what is offerable.
- */
-declare const LAYOUT_FIELD_KIND: Record<ViewLayout, "choice" | "date" | null>;
-/**
- * ─────────────────────────────────────────────────────────────────────────────
- * WHICH VIEW A LINK NAMES — the address bar as a first-class control.
- *
- * 🚨 THE DEFECT THIS CLOSES (lane FRONT-DOOR, 2026-09-21; VERIFIER-8 HIGH-2).
- * `/data-v2/<table>?view=kanban` returned 200 and rendered THE GRID. The
- * switcher was there, the four buttons worked, and the parameter was read by
- * nobody — so a person who bookmarked a board, or sent one to a colleague, got
- * a grid, and nothing on the screen said the view had been dropped. A link that
- * does not land is the inbox-link defect (`activeRecordId`) and the dashboard
- * defect (`activeDashboardId`) for the third time, so this is the same shape of
- * fix: the URL names it, the page opens on it, and the URL FOLLOWS the person
- * when they pick another.
- *
- * The dashboards are a fifth value and not a special case: to the person, "the
- * dashboard" is one of the ways to look at this table, and a link to it has to
- * work like a link to the board.
- */
-/**
- * 🚨 `archived` IS THE SIXTH VALUE, AND IT IS NOT A SPECIAL CASE EITHER (lane
- * FIX-10A-ARCHIVE, 2026-09-22; VERIFIER-10 F4).
- *
- * Archiving a record used to be a ONE-WAY DOOR: the grid's row action soft-
- * deletes correctly — `deleted_at` set, version bumped, nothing removed — and
- * then no screen anywhere in the platform could bring it back. The store's
- * `custom.record_restore` was there the whole time and did exactly the right
- * thing; nothing reached it, because every read door answers live rows only.
- *
- * So the archive is a WAY OF LOOKING AT THIS TABLE, like the board and the
- * dashboards, reached by the same row of buttons and named by the same
- * `?view=` parameter — never a Trash area of the app somebody has to know
- * exists, and never a per-table screen. Every Table inherits it the moment it
- * is in this list.
- */
-declare const PAGE_VIEWS: readonly ["grid", "kanban", "calendar", "gallery", "dashboards", "archived"];
-type PageView = (typeof PAGE_VIEWS)[number];
-declare const PAGE_VIEW_LABEL: Record<PageView, string>;
-/**
- * What a `?view=` value means, or `null` when it means nothing here.
- *
- * `null` is NOT "show the grid": the caller is expected to say that the link
- * named something this table has no view for, because silently substituting a
- * different view is exactly the defect above wearing a parser.
- */
-declare function pageViewFromParam(raw: string | null | undefined): PageView | null;
-/** The sentence a link that named a view nobody has says. Never silent. */
-declare function unknownViewLine(raw: string): string;
-/** The one sentence a layout says when the table holds no Field it could use. */
-declare const LAYOUT_NO_FIELD: Record<ViewLayout, string>;
-/**
- * THE SPEC AS THE ONE DEFINITION `platform.saved_view` HOLDS — the keys
- * `custom.view_declare` documents, by Field KEY. `subject` is not in it: the door
- * takes the Table as its own argument and writes `table_id` itself.
- */
-declare function viewDocument(spec: SavedViewSpec): Record<string, unknown>;
-/**
- * One row of `custom.views` back into the spec a screen and an agent both read — THROUGH THE ONE
- * ACCESSOR (`viewSettings`, viewKeys.ts), so every layout sees every declared key the same way.
- */
-declare function viewFromRow(row: SavedViewRow): SavedView;
-/**
- * SAVE ONE NEW VIEW of a Table — the bar's "New view" and an agent's seed spec.
- * One `view_declare` with no `view_id`; the answer is the new view's id.
- */
-declare function declareView(client: Pick<RecordsClient, "viewDeclare">, spec: SavedViewSpec): Promise<RecordsResult<Uuid$1>>;
-/**
- * WRITE A CHANGE ONTO A SAVED VIEW, AND KEEP IT.
- *
- * `custom.view_declare` with the view's id MERGES: only the keys in `patch` are
- * written, a key cleared to null is removed, and everything the patch did not
- * name — the grid's own choices, a hand-set order, where the view was moved from,
- * a colour set in another tab — stays exactly as it was (S0, 2026-09-23: the door
- * used to rebuild the whole definition from what one press sent).
- *
- * There is no version to be stale against (VERIFIER-15 M4 is closed by the shape,
- * not by a retry): a saved view is a person's own arrangement of a table, and
- * their latest press on a control is the one that stands. A refusal — the view
- * was removed, or belongs to a table this person cannot open — is handed back for
- * the page to say through the one notice.
- */
-declare function saveViewPatch(client: Pick<RecordsClient, "viewDeclare">, tableId: Uuid$1, viewId: Uuid$1, patch: Partial<SavedViewSpec>): Promise<RecordsResult<Uuid$1>>;
-/**
- * A PARTIAL change to a saved view, as the definition keys the door merges. Only
- * the keys the caller actually changed are sent; a Field cleared (a board with no
- * "Group by") is sent as `null`, which the door removes.
- */
-declare function viewPatchDocument(patch: Partial<SavedViewSpec>): Record<string, unknown>;
-
 /** Every surface a saved view is drawn by. `sheet` is the spreadsheet surface (G-lanes). */
 type ViewKeyLayout = "grid" | "kanban" | "calendar" | "gallery" | "sheet";
 /** Who may write a key: anyone who may save the view, an input the door rewrites, or the server only. */
@@ -2405,11 +2447,24 @@ interface ViewSwitcherProps {
     chooser?: boolean | undefined;
     /** Handed to a host layout's `render` — the page's own export. */
     openExport?: (() => void) | undefined;
+    /**
+     * THE SAVED VIEW'S OWN ID, when the view is a stored one (lane GRID-MANUAL). A hand-set order
+     * lives on the view's row, so the grid reads it (`custom.read_records_in_view_order`) and writes
+     * it (`custom.view_record_order_set`, Reorder → Save) through it. Left out — a literal spec —
+     * the view has no hand order and the grid offers no Reorder.
+     */
+    viewId?: Uuid | null | undefined;
+    /**
+     * The rows were placed by hand: the store made this view manual and removed its sort. The host
+     * updates the view it holds (nothing is written — the store already did).
+     */
+    onOrderPlaced?: (() => void) | undefined;
     className?: string | undefined;
 }
 /** The records this view holds: its Rule's members when it names one, the table otherwise. */
-declare function useViewRecords(view: SavedViewSpec, pageSize?: number, filter?: StoreFilter): {
+declare function useViewRecords(view: SavedViewSpec, pageSize?: number, filter?: StoreFilter, viewId?: Uuid | null): {
     rows: ReadRow$1[];
+    manual: boolean;
     loading: boolean;
     error: RecordsError | null;
     /**
@@ -2426,7 +2481,7 @@ declare function useViewRecords(view: SavedViewSpec, pageSize?: number, filter?:
      */
     membership: string;
 };
-declare function ViewSwitcher({ view, onLayoutChange, onViewChange, onOpenRecord, onMoved, onNewRecordForm, onAskWhoChanged, pageSize, titleField, filter, hostLayout, onHostLayoutChange, chooser, openExport, className, }: ViewSwitcherProps): react.JSX.Element;
+declare function ViewSwitcher({ view, onLayoutChange, onViewChange, onOpenRecord, onMoved, onNewRecordForm, onAskWhoChanged, pageSize, titleField, filter, hostLayout, onHostLayoutChange, chooser, openExport, viewId, onOrderPlaced, className, }: ViewSwitcherProps): react.JSX.Element;
 
 /** What the screen says above the list, so nobody has to be told twice that nothing was destroyed. */
 declare const ARCHIVE_MEANS = "Archiving never destroys anything. A record you remove from the grid waits here until somebody brings it back.";