@remit/api-openapi-types 0.0.54 → 0.0.56

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@remit/api-openapi-types",
-  "version": "0.0.54",
+  "version": "0.0.56",
   "type": "module",
   "main": "types.d.ts",
   "types": "types.d.ts",

package/types.d.ts

@@ -1648,17 +1648,17 @@ with `onExisting: merge` to upsert instead.
        */
       parentMailboxId: string;
       /**
-       * Sync status for mailbox operations (create, rename, delete)
+       * Which folder mutation is outstanding, read as a pair with `pendingPath` (docs/architecture/folder-rename-and-delete.md D1, D3). Total: a row written without one is `synced`, because a folder the server just told us about is confirmed. Four values carry six states — `pending` covers a create and a rename in flight, `failed` covers a failed rename and a failed delete — so every guard and every transition predicate names the pair, never this field alone.
        */
-      syncStatus?: MailboxSyncStatus;
+      syncStatus: MailboxSyncStatus;
       /**
-       * Cursor integrity state machine for stored UIDs (epic #1281 invariant 5, issue #1272). Total per RFC 032: defaults to `normal` rather than being absent. A row written before this field existed reads back as `normal` (unset DynamoDB/Postgres attribute deserializes to the schema default).
+       * The path a recorded rename is moving this folder to. Absent unless a rename is in flight or has just failed, which is what tells a create in flight from a rename in flight (D2, D3). `fullPath` stays the path the server holds throughout, so a failed rename is this field cleared rather than a subtree of paths restored. Invariant: non-null only while `syncStatus` is `pending` or `failed`.
        */
-      cursorState: MailboxCursorState;
+      pendingPath?: String512;
       /**
-       * Previous path before rename (used during RENAME sync)
+       * Cursor integrity state machine for stored UIDs (epic #1281 invariant 5, issue #1272). Total per RFC 032: defaults to `normal` rather than being absent. A row written before this field existed reads back as `normal` (unset DynamoDB/Postgres attribute deserializes to the schema default).
        */
-      oldPath?: String512;
+      cursorState: MailboxCursorState;
       /**
        * Denormalized list of IMAP SPECIAL-USE designations (RFC 6154). Populated from the same `\Sent`, `\Drafts`, etc. attributes the server reports during LIST. Stored on the row to avoid an N+1 join when listing mailboxes.
        */
@@ -1719,9 +1719,13 @@ with `onExisting: merge` to upsert instead.
        */
       lastMessageSyncAt: number;
       /**
-       * Sync status for mailbox operations (create, rename, delete)
+       * Which folder mutation is outstanding, read as a pair with `pendingPath` (docs/architecture/folder-rename-and-delete.md D1, D3). Total: a row written without one is `synced`, because a folder the server just told us about is confirmed. Four values carry six states — `pending` covers a create and a rename in flight, `failed` covers a failed rename and a failed delete — so every guard and every transition predicate names the pair, never this field alone.
        */
-      syncStatus?: MailboxSyncStatus;
+      syncStatus: MailboxSyncStatus;
+      /**
+       * The path a recorded rename is moving this folder to. Absent unless a rename is in flight or has just failed, which is what tells a create in flight from a rename in flight (D2, D3). `fullPath` stays the path the server holds throughout, so a failed rename is this field cleared rather than a subtree of paths restored. Invariant: non-null only while `syncStatus` is `pending` or `failed`.
+       */
+      pendingPath?: String512;
       /**
        * Denormalized list of IMAP SPECIAL-USE designations (RFC 6154). Populated from the same `\Sent`, `\Drafts`, etc. attributes the server reports during LIST. Stored on the row to avoid an N+1 join when listing mailboxes.
        */
@@ -6537,6 +6541,10 @@ declare namespace Paths {
       limit?: number;
       starred?: boolean;
       query?: string;
+      from?: string;
+      subject?: string;
+      accountId?: Components.Schemas.UUID;
+      muted?: boolean;
       category?: Components.Schemas.MessageCategory[];
       unread?: boolean;
       attachments?: boolean;
@@ -7296,7 +7304,9 @@ Pagination: pass the returned `continuationToken` to fetch the next page; keep p
 
 Starred mode (`starred=true`): served by the `byStarred` LSI4 instead. A star is a marker on the mail rather than on its placement, so the INBOX scope does not apply and a starred thread in Archive is still returned. Excluded are muted and soft-deleted rows as usual, plus the folders a star never surfaces from: Junk, Trash, and Gmail's All Mail (a second copy of everything, whose rows would otherwise double every starred message). All filtering happens in the query, so a page is short only when the results are exhausted. Rows are per mailbox: the same mail filed in two folders is two rows sharing a `threadId`, and a client rendering one row per conversation collapses by `threadId` across the pages it has accumulated.
 
-Search mode (`query=<text>`): the listing widens past the INBOX scope to every non-muted mailbox of every non-muted account, and returns only rows whose subject or From address matches the text. This is the unscoped search of the daily brief: one query reaching every folder of every account. Whitespace splits the text into terms and every term must match (AND), each against subject OR From. Matching is case-insensitive substring, not tokenized full-text, so it neither stems nor ranks.
+Search mode (`query=<text>`): the listing widens past the INBOX scope to every non-muted mailbox of every non-muted account, and returns only rows whose subject, From address or body text matches the text. This is the unscoped search of the daily brief: one query reaching every folder of every account. Whitespace splits the text into terms and every term must match (AND), each against subject OR From OR body. Matching is case-insensitive substring, not tokenized full-text, so it neither stems nor ranks.
+
+Body text is the stored preview the row carries — the first prose of the message with quoted replies removed, which is the same text the row renders under its subject. A term further into a long message is not reached; a term the reader can see on the row is.
 
 Search scope: every non-muted mailbox EXCEPT Trash. The scope is defined by what it excludes, so anything a server offers that is not on that list is searched — Spam, Drafts and Gmail's virtual folders (All Mail, Starred, Important) included. Spam is deliberately in scope: the point of an unscoped search is that it reaches the folders the user did not think to look in. Combining `query` with `starred=true` searches the starred scope instead.
 
@@ -7310,6 +7320,12 @@ Callers that omit `query` are unaffected: the INBOX (and starred) listings behav
 
 Row filters: `category`, `unread` and `attachments` are columns on the ThreadMessage row, so each is a predicate inside the query rather than a pass over what a page returned. They compose with every mode above — INBOX, starred and search alike — and a page therefore comes back full of matches however rare the criterion is. This is what the cross-account collections need: filtering the pages a client happens to have loaded shows an empty list whenever the matching mail sits below the newest page (#308).
 
+Field filters: `from` and `subject` each match one field, which the single `query` cannot express — it matches both at once. They compose with `query` and with each other as further AND terms.
+
+Account scope: `accountId` narrows every mode to the mailboxes of one account. The scope is built from the account's own mailboxes, so the listing, the count and the search all answer over the same set. Without it the listing is the cross-account aggregate.
+
+Muted senders: `muted=false` excludes rows whose From address is muted, `muted=true` returns only those, and omitting it filters nothing. Muting is a property of the address rather than a column on the row, so this is the one predicate that reaches outside the ThreadMessage table; it applies to the listing and the `count` alike, which is what lets a caller that hides muted mail state a number that is the size of what it renders.
+
 Counting: `count=true` answers how many CONVERSATIONS match, over the whole scope and independent of `limit`. `results=false` omits the rows, which is how a header total is read without also paying for a page of mail. Conversations rather than rows because that is what this listing renders: a row is per mailbox, so the same mail filed in two folders is two rows sharing a `threadId`, and clients collapse by it. Counting rows would put a third number beside a list that shows a second one.
    */
   'listAllThreads'(
@@ -8122,7 +8138,9 @@ Pagination: pass the returned `continuationToken` to fetch the next page; keep p
 
 Starred mode (`starred=true`): served by the `byStarred` LSI4 instead. A star is a marker on the mail rather than on its placement, so the INBOX scope does not apply and a starred thread in Archive is still returned. Excluded are muted and soft-deleted rows as usual, plus the folders a star never surfaces from: Junk, Trash, and Gmail's All Mail (a second copy of everything, whose rows would otherwise double every starred message). All filtering happens in the query, so a page is short only when the results are exhausted. Rows are per mailbox: the same mail filed in two folders is two rows sharing a `threadId`, and a client rendering one row per conversation collapses by `threadId` across the pages it has accumulated.
 
-Search mode (`query=<text>`): the listing widens past the INBOX scope to every non-muted mailbox of every non-muted account, and returns only rows whose subject or From address matches the text. This is the unscoped search of the daily brief: one query reaching every folder of every account. Whitespace splits the text into terms and every term must match (AND), each against subject OR From. Matching is case-insensitive substring, not tokenized full-text, so it neither stems nor ranks.
+Search mode (`query=<text>`): the listing widens past the INBOX scope to every non-muted mailbox of every non-muted account, and returns only rows whose subject, From address or body text matches the text. This is the unscoped search of the daily brief: one query reaching every folder of every account. Whitespace splits the text into terms and every term must match (AND), each against subject OR From OR body. Matching is case-insensitive substring, not tokenized full-text, so it neither stems nor ranks.
+
+Body text is the stored preview the row carries — the first prose of the message with quoted replies removed, which is the same text the row renders under its subject. A term further into a long message is not reached; a term the reader can see on the row is.
 
 Search scope: every non-muted mailbox EXCEPT Trash. The scope is defined by what it excludes, so anything a server offers that is not on that list is searched — Spam, Drafts and Gmail's virtual folders (All Mail, Starred, Important) included. Spam is deliberately in scope: the point of an unscoped search is that it reaches the folders the user did not think to look in. Combining `query` with `starred=true` searches the starred scope instead.
 
@@ -8136,6 +8154,12 @@ Callers that omit `query` are unaffected: the INBOX (and starred) listings behav
 
 Row filters: `category`, `unread` and `attachments` are columns on the ThreadMessage row, so each is a predicate inside the query rather than a pass over what a page returned. They compose with every mode above — INBOX, starred and search alike — and a page therefore comes back full of matches however rare the criterion is. This is what the cross-account collections need: filtering the pages a client happens to have loaded shows an empty list whenever the matching mail sits below the newest page (#308).
 
+Field filters: `from` and `subject` each match one field, which the single `query` cannot express — it matches both at once. They compose with `query` and with each other as further AND terms.
+
+Account scope: `accountId` narrows every mode to the mailboxes of one account. The scope is built from the account's own mailboxes, so the listing, the count and the search all answer over the same set. Without it the listing is the cross-account aggregate.
+
+Muted senders: `muted=false` excludes rows whose From address is muted, `muted=true` returns only those, and omitting it filters nothing. Muting is a property of the address rather than a column on the row, so this is the one predicate that reaches outside the ThreadMessage table; it applies to the listing and the `count` alike, which is what lets a caller that hides muted mail state a number that is the size of what it renders.
+
 Counting: `count=true` answers how many CONVERSATIONS match, over the whole scope and independent of `limit`. `results=false` omits the rows, which is how a header total is read without also paying for a page of mail. Conversations rather than rows because that is what this listing renders: a row is per mailbox, so the same mail filed in two folders is two rows sharing a `threadId`, and clients collapse by it. Counting rows would put a third number beside a list that shows a second one.
      */
     'get'(