@forumone/throughline 1.0.0-next.0 → 1.0.0-next.2

package/CHANGELOG.md

@@ -1,5 +1,51 @@
 # @forumone/throughline
 
+## 1.0.0-next.2
+
+### Major Changes
+
+- dcf84fc: `resend`, `@react-email/components` and `@react-email/render` are optional peers rather than dependencies, and `inngest` is an optional peer. `payload` is the only required one. Each optional peer is loaded only by the subpath that uses it, and the root loads none: the approval emails import their templates when they send, so registering the suite with `throughline()` no longer loads React or React Email. A missing optional peer fails when its feature runs, with an error naming the package to install.
+- e7d34fa: Smaller gaps closed before 1.0:
+
+  - `Integration.createFunctions` is optional. `throughline()` runs `createJobs` and never called it.
+  - `auditQuery.readAccess` now applies: it takes the tool's context, `(ctx) => boolean`, and replaces the admin/editor rule for the five audit tools. It was declared with a `PayloadRequest` and read by nothing.
+  - `job-failures` takes an `admin` sidebar group like every other Throughline collection, and gets the suite's from `throughline()`.
+  - An accessibility issue of severity `warning` reaches the publish result's `warnings` instead of being dropped.
+  - The webhook integration no longer subscribes to `form/submission.received`, which nothing sends since forms left the suite; the stored filter option stays. Stale text naming forms, the "Approvals Server" and 0.x paths is corrected.
+
+- 673ff70: `throughline()`: one call for the whole suite (`docs/spec/1.0-throughline-call.md`). It returns `{ plugin, mcpTools, jobs }`: one Payload plugin that registers every enabled Throughline plugin in order, the tool array for `mcpPlugin`, and every job the options call for. Audit, job failures and `check_slug` are always on; every other plugin is on when its key is present. Shared values are given once: `approvals.collectionSlug` reaches the collection, the emails and the expiry job, and `collections` reaches publishing, "Your work" and scheduled publishing. Its defaults are what every site wrote by hand: scheduled publishes go through the publishing pipeline (`publishScheduledThroughPipeline`), approval links are signed with approvals' secret, and a failing healthcheck is recorded in `job-failures`. On Payload Jobs it registers its jobs itself. It refuses an integration with no `createJobs`.
+
+  **Internal now:** `getPluginRegistry`, `resolveAdminGroup`, `DEFAULT_ADMIN_GROUP`, `PluginRegistry*`, `createMcpToolCollector` and the collector's option types, `toPayloadMcpTool(s)`, `getEmailFunctions`, `getIntegrationRegistry` and `getIntegrationContext`. Use `throughline()`. `McpToolCollector` and `PayloadMcpTool` stay exported as types.
+
+  `HealthcheckOptions.onFailure` receives `{ payload }` as a second argument, and `createHealthcheckFailureHandler()` made without a `payload` records on the run's own.
+
+- 6c1409a: The trust boundary now covers every write that changes what the public sees. A create with `_status: 'published'` is refused (create a draft, then publish), and so is a non-draft save that changes a live document (save a draft, then publish). Before, both went live with no pipeline, approval or audit row, so "requires approval" held only for a page's first publish. Data a system derives from a live page and writes back to it, such as an audio URL, passes with `context: DERIVED_WRITE_CONTEXT` from `/publishing`, which can never change `_status`, create, or promote a draft.
+
+### Minor Changes
+
+- 2e49ee7: `throughline migrate-imports [paths…] [--dry-run]`, a new bin: rewrites every 0.x `@forumone/throughline-*` import to its 1.0 home, by `docs/spec/1.0-exports.md`. It splits an import by where each name went, keeps `type` and aliases, rewrites admin component paths (`importMap.js` included), and points mocks, dynamic imports and module augmentation at the 1.0 counterpart for you to check. Names 1.0 removed or made internal are left in place and listed with what to use instead, as are the `package.json` dependencies to swap, and it exits 1 while anything is left. Run on forumone-2026, it rewrites 163 files and leaves the five imports `throughline()` replaces.
+
+### Patch Changes
+
+- @forumone/throughline-design-system@1.0.0-next.2
+
+## 1.0.0-next.1
+
+### Patch Changes
+
+- 825f4e9: `@forumone/throughline-design-system`: the 1.0 design-system package, from `@forumone/throughline-design-contract` and `@forumone/throughline-design-system-payload`, by `docs/spec/1.0-exports.md`. It is published for the first time: design-system-payload was private and shipped TypeScript source, and this package builds to `dist`.
+
+  - `@forumone/throughline-design-contract` is `/contract`, and its `/lint` is `/lint`.
+  - design-system-payload's `/generate`, `/render`, `/client` and `/testing` keep their names. Its root (`fieldOverride` and the override types) is part of `/generate`.
+  - The `check-block-props` bin is unchanged, and runs the built CLI.
+  - Admin component paths are `@forumone/throughline-design-system/client#BlockSummary`, `#BlockGuidance` and `#RowSummary`, so a site's `importMap.js` changes.
+  - `/contract` and `/lint` need no peers. `payload`, `react`, `@payloadcms/ui`, `typescript` (which `/generate` uses to read component source) and `vitest` (for `/testing`) are optional peers.
+
+  `@forumone/throughline/components` now reads manifests through `@forumone/throughline-design-system/contract`.
+
+- Updated dependencies [825f4e9]
+  - @forumone/throughline-design-system@1.0.0-next.0
+
 ## 1.0.0-next.0
 
 ### Major Changes

package/README.md

@@ -1,352 +1,98 @@
 # @forumone/throughline
 
-Throughline for Payload CMS: the audit log, MCP authentication and tools, the jobs event taxonomy and
-Inngest client, the field kit, media hardening and reference tracking, error reporting, environment
-checks and a logger. Each part lives on its own subpath.
+Throughline for Payload CMS: publishing behind a policy pipeline, approvals, the audit log, editorial
+reports, integrations, email and background jobs, with every feature reachable over MCP. One call
+registers the suite; each part also lives on its own subpath.
 
 > **1.0 is in progress.** Every 0.x server package has moved in: core, plugin-contract, publishing,
-> workflows, audit, approvals, components, integrations and email. `throughline()` comes next.
-> [`docs/spec/1.0-exports.md`](../../docs/spec/1.0-exports.md) maps every 0.x import to its 1.0 path.
+> workflows, audit, approvals, components, integrations and email.
+> [Upgrading from 0.x](https://github.com/forumone/throughline/blob/main/docs/guides/upgrading.md) moves a 0.x site onto it.
 > Pre-releases publish as `1.0.0-next.N` under the `next` dist-tag.
 
-## What's inside
-
-| Subpath           | Holds                                                                                                                                                                                  |
-| ----------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| (root)            | `assertEnvironment`, `checkEnvValue`, `hardenCoreCollections`, `mcpApiKeyAccess`, `withMeta`, `auditContext`, the logger, utilities, and the plugin types                              |
-| `/publishing`     | `publishingPlugin`, the publishing service, `isDraftWrite`, the accessibility checks, and the revalidation and scheduled-publishing jobs; see [docs/publishing.md](docs/publishing.md) |
-| `/editorial`      | `editorialPlugin`: content health, the content calendar, "Your work", command palette search, and their MCP tools                                                                      |
-| `/approvals`      | `approvalsPlugin`, signed action links, `expireStaleApprovalsJob`; see [docs/approvals.md](docs/approvals.md)                                                                          |
-| `/audit`          | `auditPlugin`, `getAuditWriter`, `AUDIT_ACTIONS`, `auditQueryPlugin` and its tools, `auditEventEchoJob`; see [docs/audit.md](docs/audit.md)                                            |
-| `/components`     | `componentsPlugin`: the design-system manifest over MCP; see [docs/components.md](docs/components.md)                                                                                  |
-| `/integrations`   | `integrationsPlugin`, the registry, the webhook integration, manual sync, `healthcheckJob`; see [docs/integrations.md](docs/integrations.md)                                           |
-| `/email`          | `emailPlugin`, the Resend client, the approval notifications and their templates; see [docs/email.md](docs/email.md)                                                                   |
-| `/jobs`           | `defineJob`, the job types, the failure handlers, and `CoreEvents` for module augmentation; see [docs/jobs.md](docs/jobs.md)                                                           |
-| `/jobs/inngest`   | `inngestJobs`, `createInngestClient`, `resolveInngestEnv`, `registrableInngestFunctions`                                                                                               |
-| `/jobs/payload`   | `payloadJobs`                                                                                                                                                                          |
-| `/media`          | Blob client-upload hardening, and reference tracking: `referencesPlugin`, `findReferences`, the delete and trash guards                                                                |
-| `/fields`         | The field kit: `slugField`, `publishingFields`, `revisedAtField`, `unlistedField`, `characterCountPlugin`, `fieldsPlugin`                                                              |
-| `/observability`  | `jobFailuresPlugin`, `getJobFailureWriter`, `createErrorReporter`, `reportError`, `buildRequestErrorReport`                                                                            |
-| `/testing`        | `describeAnonymousAccess`, `checkAnonymousAccess`: test helpers for a site                                                                                                             |
-| `/cache-tags`     | `createCacheTags`, which imports nothing, for front-end readers                                                                                                                        |
-| `/client`, `/rsc` | The admin's client and server components, named in Payload's import map                                                                                                                |
-| bin               | `throughline-payload`, see [below](#running-the-payload-cli-throughline-payload)                                                                                                       |
-
-The MCP collector (`createMcpToolCollector`) is on the root until `throughline()` wires it.
-
-## Installation
-
-```bash
-pnpm add @forumone/throughline@next
-```
+**Reference: [`docs/reference/throughline.md`](https://github.com/forumone/throughline/blob/main/docs/reference/throughline.md)**, with a page per plugin.
 
-Peers: `payload@^3.89.0` and `inngest@^4.0.0`.
-
-## The audit log
+## What's inside
 
-Every consequential action in the framework writes to a single immutable Payload collection. Plugins do not write directly — they call the writer attached to the Payload instance by `auditPlugin`.
+| Subpath           | Holds                                                                                                                                                                                                                                                                                    |
+| ----------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| (root)            | `assertEnvironment`, `checkEnvValue`, `hardenCoreCollections`, `mcpApiKeyAccess`, `withMeta`, `auditContext`, the logger, utilities, and the plugin types                                                                                                                                |
+| `/publishing`     | `publishingPlugin`, the publishing service, `isDraftWrite`, the accessibility checks, and the revalidation and scheduled-publishing jobs; see [publishing](https://github.com/forumone/throughline/blob/main/docs/reference/throughline/publishing.md)                                   |
+| `/editorial`      | `editorialPlugin`: content health, the content calendar, "Your work", command palette search, and their MCP tools                                                                                                                                                                        |
+| `/approvals`      | `approvalsPlugin`, signed action links, `expireStaleApprovalsJob`; see [approvals](https://github.com/forumone/throughline/blob/main/docs/reference/throughline/approvals.md)                                                                                                            |
+| `/audit`          | `auditPlugin`, `getAuditWriter`, `AUDIT_ACTIONS`, `auditQueryPlugin` and its tools, `auditEventEchoJob`; see [audit](https://github.com/forumone/throughline/blob/main/docs/reference/throughline/audit.md)                                                                              |
+| `/components`     | `componentsPlugin`: the design-system manifest over MCP; see [components](https://github.com/forumone/throughline/blob/main/docs/reference/throughline/components.md)                                                                                                                    |
+| `/integrations`   | `integrationsPlugin`, the registry, the webhook integration, manual sync, `healthcheckJob`; see [integrations](https://github.com/forumone/throughline/blob/main/docs/reference/throughline/integrations.md)                                                                             |
+| `/email`          | `emailPlugin`, the Resend client, the approval notifications and their templates; see [email](https://github.com/forumone/throughline/blob/main/docs/reference/throughline/email.md)                                                                                                     |
+| `/jobs`           | `defineJob`, the job types, the failure handlers, and `CoreEvents` for module augmentation; see [jobs](https://github.com/forumone/throughline/blob/main/docs/reference/throughline/jobs.md)                                                                                             |
+| `/jobs/inngest`   | `inngestJobs`, `createInngestClient`, `resolveInngestEnv`, `registrableInngestFunctions`                                                                                                                                                                                                 |
+| `/jobs/payload`   | `payloadJobs`                                                                                                                                                                                                                                                                            |
+| `/media`          | Blob client-upload hardening, and reference tracking: `referencesPlugin`, `findReferences`, the delete and trash guards                                                                                                                                                                  |
+| `/fields`         | The field kit: `slugField`, `publishingFields`, `revisedAtField`, `unlistedField`, `characterCountPlugin`, `fieldsPlugin`                                                                                                                                                                |
+| `/observability`  | `jobFailuresPlugin`, `getJobFailureWriter`, `createErrorReporter`, `reportError`, `buildRequestErrorReport`                                                                                                                                                                              |
+| `/testing`        | `describeAnonymousAccess`, `checkAnonymousAccess`: test helpers for a site                                                                                                                                                                                                               |
+| `/cache-tags`     | `createCacheTags`, which imports nothing, for front-end readers                                                                                                                                                                                                                          |
+| `/client`, `/rsc` | The admin's client and server components, named in Payload's import map                                                                                                                                                                                                                  |
+| bin               | `throughline migrate-imports`, see [Upgrading from 0.x](https://github.com/forumone/throughline/blob/main/docs/guides/upgrading.md); `throughline-payload`, see [the reference](https://github.com/forumone/throughline/blob/main/docs/reference/throughline.md#throughline-payload-bin) |
+
+## `throughline()`
 
 ```ts
-import { auditPlugin } from '@forumone/throughline/audit'
-import { createInngestClient } from '@forumone/throughline/jobs/inngest'
-import { buildConfig } from 'payload'
-
-const inngest = createInngestClient({ id: 'my-site' })
+// payload.config.ts
+import { mcpApiKeyAccess, throughline } from '@forumone/throughline'
+import { inngestJobs } from '@forumone/throughline/jobs/inngest'
+
+export const suite = throughline({
+  jobs: inngestJobs(inngest), // or payloadJobs() from /jobs/payload
+  collections: ['pages', 'posts'],
+  publishing: { urls: { pages: (slug) => `/${slug}`, posts: (slug) => `/blog/${slug}` } },
+  approvals: { groups, groupResolver },
+  email: { resolveApprover, resolveRequester },
+  integrations: {},
+  healthcheck: { checks: [createPayloadReachableCheck()] },
+})
 
 export default buildConfig({
-  // collections, db, secret...
+  // …
   plugins: [
-    auditPlugin({ inngest }),
-    // your other Throughline plugins
+    suite.plugin,
+    mcpPlugin({
+      mcp: { tools: suite.mcpTools },
+      overrideApiKeyCollection: mcpApiKeyAccess(isAdmin),
+    }),
   ],
 })
 ```
 
-In a downstream plugin's `onInit`:
-
-```ts
-import { getAuditWriter } from '@forumone/throughline/audit'
-
-onInit: async (payload) => {
-  const writer = getAuditWriter(payload)
-  await writer({
-    actor: { type: 'user', userId: 'u1' },
-    action: 'publishing.publish',
-    mcpServer: 'publishing',
-    mcpTool: 'publishing.publish',
-    targetCollection: 'pages',
-    targetId: 'p1',
-    targetTitle: 'Homepage',
-  })
-}
-```
-
-The writer is **fire-and-forget**: failures log but never throw. Audit failures must never break the originating action.
-
-### Sidebar group
-
-The `audit-events` collection sits in the admin sidebar's `Throughline` group by default. `auditPlugin({ inngest, admin: { group: 'Workflow' } })` files it elsewhere; `admin: { group: false }` leaves it ungrouped. Every Throughline plugin that declares a collection takes the same option — see [the reference](https://github.com/forumone/throughline/blob/main/docs/reference/plugin-contract.md#admin-sidebar-group).
-
-## Job failures and error reporting
-
-The audit log records who did what through an MCP tool. A background job that
-ran out of retries is not that, so it has its own collection:
-`jobFailuresPlugin()` adds `job-failures` and attaches a writer that
-the failure handlers in `/jobs` find. Adding it to an
-existing site is a schema change — run `payload migrate:create` afterwards.
-
-Error reports go to a webhook, not to a vendor SDK: `reportError` posts JSON to
-`ERROR_WEBHOOK_URL` (a log drain, an alerting endpoint, a Slack incoming
-webhook, a proxy in front of a tracker), with a 3-second timeout, and never
-throws. `buildRequestErrorReport` shapes what Next's `onRequestError` hands
-over, copying request headers from an allowlist — `cookie` and `authorization`
-are never copied.
-
-```typescript
-// instrumentation.ts
-import type { Instrumentation } from 'next'
-import { buildRequestErrorReport, reportError } from '@forumone/throughline/observability'
-
-export const onRequestError: Instrumentation.onRequestError = async (error, request, context) => {
-  await reportError(buildRequestErrorReport(error, request, context))
-}
-```
-
-`./observability` imports neither Payload nor Inngest at runtime, so it is safe
-in `instrumentation.ts`. See `docs/operations/observability.md`.
-
-## MCP authentication
-
-`@payloadcms/plugin-mcp` handles MCP authentication. It adds the `payload-mcp-api-keys` collection, looks up `Authorization: Bearer <key>` on `/api/mcp`, and runs each tool as the person the key is bound to. This package's `createApiKeysCollection`, `createBearerTokenAuthenticator` and `createMcpHandler` are gone.
-
-What this package adds is two access helpers for a site that registers that plugin.
-
-**Only admins should manage keys.** A key runs every tool as its user, so minting, reading and revoking keys is an admin's job. The plugin doesn't enforce that by default. `mcpApiKeyAccess(isAdmin)` is an `overrideApiKeyCollection` that applies your admin rule to `read`, `create`, `update`, `delete` and `unlock`, and refuses an MCP key principal before it asks the rule:
-
-```ts
-import { createMcpToolCollector, mcpApiKeyAccess } from '@forumone/throughline'
-import { mcpPlugin } from '@payloadcms/plugin-mcp'
-import type { Access } from 'payload'
-
-const isAdmin: Access = ({ req: { user } }) =>
-  user?.collection === 'users' && Array.isArray(user.roles) && user.roles.includes('admin')
-
-mcpPlugin({
-  mcp: { tools: mcpTools.tools },
-  overrideApiKeyCollection: mcpApiKeyAccess(isAdmin),
-})
-```
-
-It changes `access` and nothing else. To set other options too, call it inside your own override:
-
-```ts
-overrideApiKeyCollection: collection => {
-  const hardened = mcpApiKeyAccess(isAdmin)(collection)
-  return { ...hardened, admin: { ...hardened.admin, group: 'Throughline' } }
-},
-```
-
-**"Signed in" is not `Boolean(req.user)`.** Before Payload 3.89.0, the key collection's `auth.useAPIKey` registered Payload's API-key strategy on every REST route, so a key _document_ could become `req.user`. It has no roles, but it passes `Boolean(req.user)`, so a rule like "published, or anybody signed in" served drafts to anyone holding a key. Payload 3.89.0 fixed this, and it's this package's peer floor. Refuse the principal in your own rules as well:
-
-| Export                       | What it does                                                                    |
-| ---------------------------- | ------------------------------------------------------------------------------- |
-| `isSignedIn(user)`           | `true` for a person, `false` for anonymous or an MCP key document. A type guard |
-| `signedIn`                   | `isSignedIn` as an `Access` function                                            |
-| `isMcpApiKeyPrincipal(user)` | `true` only for a key document from `payload-mcp-api-keys`                      |
-| `MCP_API_KEYS_SLUG`          | `'payload-mcp-api-keys'`                                                        |
-
-None of these affects `/api/mcp`. A tool call there arrives as the key's user, in `users`, with that person's roles. See [the security model](../../docs/operations/security-model.md#signed-in-is-not-booleanrequser).
-
-### Scopes
-
-A key carries `scopes`, and a tool may declare the one it needs:
-
-```ts
-const publishTool: McpToolDefinition = {
-  name: 'publish',
-  requiredScope: 'publishing.execute',
-  // …
-}
-```
-
-> **Nothing enforces this today.** The paragraphs below describe how
-> `requiredScope` behaved when each server mounted its own `/api/<server>/mcp`
-> endpoint behind a hand-written JSON-RPC handler. That handler — and the
-> `auth.ts` that held callers to their scopes — were removed by "one MCP
-> transport, not seven" (#80), which consolidated every server onto Payload's
-> `/api/mcp`. The scope declarations survived the refactor; the enforcement did
-> not, and this section was not updated to say so. Audit 04 F-02.
->
-> **What gates a tool now** is the per-key checkbox `@payloadcms/plugin-mcp`
-> generates, one per tool name. Two consequences worth knowing before relying
-> on either: all 27 of them **default to `true`**
-> (`createApiKeysCollection.js:4-15`), and a checkbox list cannot express
-> "writes off until granted, reads on" the way a scope can.
->
-> The declarations are kept because they are the tool → scope mapping a
-> scope-aware default would be built from — see the note on `requiredScope` in
-> `McpToolDefinition`, which states the same thing at the
-> type. Reinstating enforcement means putting it on the surviving transport.
-
-Historically, and as the intended design: a tool that declares no
-`requiredScope` is callable by any authenticated key, which is the right
-default for a read. A tool that declares one was **hidden from `tools/list`**
-and refused on a direct call unless the key named that scope — hidden as well
-as refused, because an agent shown a tool it will be turned away from will try
-it, fail, and report the tool as broken when what is narrow is the key.
-
-A key carrying no scopes at all passed nothing scoped. Absent was read as none,
-not as everything.
-
-The consequential tools in this suite and the scopes they require:
-
-| Scope                  | Tools                                                           |
-| ---------------------- | --------------------------------------------------------------- |
-| `publishing.execute`   | `publish`, `unpublish`, `schedule_publish`, `rollback`          |
-| `approvals.request`    | `request_approval`                                              |
-| `approvals.decide`     | `respond_to_approval`                                           |
-| `forms.manage`         | `create_form`, `update_form_fields`, `update_form_destinations` |
-| `integrations.trigger` | `trigger_sync`, `test_integration`                              |
-
-Everything else — the component tools, the audit queries, the read side of publishing and approvals — needs only a valid key.
-
-## Events
-
-`CoreEvents` enumerates the events the framework fires today. Server packages add their own via TypeScript module augmentation:
-
-```ts
-declare module '@forumone/throughline/jobs' {
-  interface FrameworkEvents {
-    'approval/decided': {
-      data: { approvalId: string; decision: 'granted' | 'declined' }
-    }
-  }
-}
-```
-
-After augmentation, `inngest.send({ name: 'approval/decided', data: { ... } })` is type-checked everywhere.
-
-## Checking the environment
-
-Each plugin that falls back to `process.env` exports what it needs as data — `approvalsEnv`, `emailEnv`, `formsEnv` — and checks the same entries at init. A site passes every list, plus its own variables, to `assertEnvironment` first thing in `payload.config.ts`:
-
-```ts
-import { assertEnvironment } from '@forumone/throughline'
-import { approvalsEnv } from '@forumone/throughline/approvals'
-import { emailEnv } from '@forumone/throughline/email'
-
-assertEnvironment(
-  approvalsEnv,
-  emailEnv,
-  { name: 'PAYLOAD_SECRET', minLength: 32, why: 'Signs Payload sessions.' },
-  () => databaseConnectionString(),
-)
-```
-
-It throws once, listing every missing or too-short value with the reason it is needed, under a first line that says `Configuration problem` — instead of each plugin failing on the first thing it finds, one deploy at a time, inside a `next build` stack trace. It never prints a value. A function argument is for a rule that is not "this name, this long": what it throws becomes a line in the report.
-
-`checkEnvValue(requirement, value)` is the one-value check behind it, which a plugin uses for its own init backstop.
-
-## Document content hashing
-
-`documentContentHash(document)` reduces a Payload document to a hash of the part an editor authored, ignoring the metadata that moves without the content moving — `id`, `createdAt`, `updatedAt`, `_status`, `__v`, `_id`, `globalType`, stripped at every level of the document. Object key order does not affect the result, because blocks come back out of JSONB in no promised order; array order does, because that is the order of the blocks on the page.
-
 ```ts
-import { documentContentHash } from '@forumone/throughline'
-
-const version = await documentContentHash(page)
-const withExtras = await documentContentHash(page, { exclude: ['syncedAt'] })
+// app/api/inngest/route.ts, on Inngest. On Payload Jobs, suite.plugin registers the jobs itself.
+const jobs = inngestJobs(inngest, { onFailure: createTerminalFailureHandler({ payload }), payload })
+export const { GET, POST, PUT } = serve({ client: inngest, functions: jobs.functions(suite.jobs) })
 ```
 
-It exists so that approvals can bind to _what an approver read_ rather than to when it was last saved. Approvals writes it as `targetVersion`; publishing recomputes it at publish time. Two consequences worth stating: a save that changed nothing keeps a granted approval, and an edit that is reverted brings one back.
-
-**Two callers only agree if they hash a document loaded the same way.** Both of the above use `payload.findByID({ collection, id, draft: true })` at the config's default depth. A populated relationship and a bare relationship id are different values, and normalising cannot turn one into the other — so a third caller fetching at a different depth would produce a hash that matches nothing.
-
-## Running the Payload CLI: `throughline-payload`
-
-`pnpm payload generate:types` is shell → pnpm → node, and pnpm (like npm and
-yarn) does not forward signals to the node child it spawns. Kill the shell — a
-Ctrl-C, an agent's tool-call timeout, a cancelled CI step — and node keeps
-running, reparented to PID 1. When the run was hung rather than slow, it spins
-on a core until something kills it; one machine collected 48 of them.
-
-`throughline-payload` is a drop-in for the `payload` binary that cannot do that.
-Point every script that runs the Payload CLI at it:
-
-```json
-{
-  "scripts": {
-    "payload": "throughline-payload",
-    "payload:reap": "throughline-payload --reap",
-    "generate:types": "throughline-payload generate:types",
-    "generate:importmap": "throughline-payload generate:importmap",
-    "migrate": "PAYLOAD_MIGRATING=1 throughline-payload migrate",
-    "migrate:create": "throughline-payload migrate:create",
-    "migrate:status": "throughline-payload migrate:status"
-  }
-}
-```
+- **It registers every plugin in the order they need.** Audit, job failures and `check_slug` are always on. Every other plugin is on when its key is present.
+- **It gives every plugin the one MCP collector.** `suite.mcpTools` is what `mcpPlugin` serves.
+- **Shared values are given once.** `approvals.collectionSlug` reaches the approvals collection, the emails and the expiry job. `collections` reaches publishing, "Your work" and scheduled publishing. `admin` is every added collection's sidebar group, unless a plugin's own says otherwise.
+- **`suite.jobs` is every job the options call for:** revalidation (given `publishing.urls`), scheduled publishing and its backstop, approval expiry, the audit echo, the healthcheck, the three approval emails, and each integration's jobs. Function ids are the ones the 0.x factories registered.
+- **Its defaults are what every site wrote by hand.** Scheduled publishes go through the publishing pipeline. Approval links are signed with `APPROVAL_TOKEN_SECRET` against `NEXT_PUBLIC_SERVER_URL`. A failing healthcheck is recorded in `job-failures`.
 
-Arguments pass straight through. What it adds:
+The reasoning is in [`1.0-throughline-call.md`](https://github.com/forumone/throughline/blob/main/docs/spec/1.0-throughline-call.md). Each plugin is still exported from its subpath for a site that wires them by hand.
 
-- **Its own process group.** Payload runs `detached`, so the whole subtree can be
-  killed as a group, by pid. Nothing is ever matched by process name.
-- **Signals forwarded.** SIGINT, SIGTERM and SIGHUP go to the group; after a
-  grace period, whatever ignored them gets SIGKILL. When Payload exits on its
-  own, anything it left running in its group goes with it.
-- **A wall clock.** `PAYLOAD_CLI_TIMEOUT_MS`, default 300000 (five minutes); `0`
-  disables it. The `migrate` family (`migrate`, `migrate:create`, …) has no wall
-  clock unless you set one: a large migration is legitimately long and
-  `migrate:create` can stop at a prompt. A timed-out run exits 124.
-  `PAYLOAD_CLI_GRACE_MS` (default 5000) is the wait between the polite signal
-  and SIGKILL.
-- **A sweep for what a killed runner left behind.** A SIGKILLed runner runs no
-  handlers, so each run is recorded in `.payload-cli-pids` and the next run —
-  or `throughline-payload --reap` — kills the group of any entry whose runner
-  is gone. An entry is acted on only if the pid is alive, its start time and
-  full command line still match what was recorded (so a recycled pid is never
-  touched), the command line is rooted in this workspace, and its runner is
-  gone (so a concurrent run keeps its child). Anything else is forgotten, not
-  signalled.
-
-Payload is resolved from the directory the command runs in — the app — not
-from this package's install. `.payload-cli-pids` lives at the workspace root:
-the nearest ancestor with a `pnpm-workspace.yaml`, or, outside a pnpm
-workspace, the nearest directory with a `package.json`. Add it to
-`.gitignore`. On Windows, which has neither process groups nor `ps`, the runner
-just runs Payload.
-
-## Testing what an anonymous reader can read
-
-`@forumone/throughline/testing` holds a site's access rules to a bucket map, as a vitest suite that needs no database. It imports `vitest`, an optional peer, so it lives on its own subpath and the main entry never loads it.
-
-Every query the public site makes runs with nobody signed in, so a collection's own `read` rule decides whether a page can see its content. Close one by mistake and nothing errors: the page renders empty. Open the wrong one and the audit log or the MCP keys are on the internet.
-
-```ts
-// apps/web/src/access/anonymousAccess.test.ts
-import { describeAnonymousAccess } from '@forumone/throughline/testing'
-import config from '../payload.config'
+## Installation
 
-describeAnonymousAccess(config, {
-  renderPath: {
-    pages: 'the [...slug] route',
-    media: 'every populated upload',
-  },
-  private: ['users', 'payload-mcp-api-keys', 'audit-events', 'payload-preferences'],
-  // Optional. When given, every global must be in it.
-  globals: { renderPath: { navigation: 'the header and footer' } },
-})
+```bash
+pnpm add @forumone/throughline@next
 ```
 
-It asserts:
-
-- **Every collection is in exactly one bucket.** That covers the collections plugins and Payload add as well as the site's own. A collection in no bucket fails, so adding one forces somebody to decide. An entry the config no longer has fails too.
-- **Render-path collections allow an anonymous read.** The rule must answer `true` or a query. Having no rule fails, because Payload's default needs a user.
-- **Collections with drafts narrow that read.** On a collection with `versions.drafts`, a bare `true` serves unpublished documents, so the rule has to answer a query, usually `{ _status: { equals: 'published' } }`.
-- **Private collections refuse it.** `true` or a query fails. Having no rule passes, because Payload's default refuses.
+`payload@^3.89.0` is the one required peer. The rest are optional, each needed only by the subpaths that use it, and none is loaded by the root:
 
-A rule that calls `req.payload` cannot be checked as a value, and it throws rather than guessing. `checkAnonymousAccess(config, buckets)` returns the same findings as a list, for a script or a custom assertion.
+| Install                                                             | When the site uses                                                                                                       |
+| ------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------ |
+| `inngest`                                                           | `/jobs/inngest`: jobs on Inngest                                                                                         |
+| `resend`, `@react-email/components`, `@react-email/render`, `react` | `/email`, or `email` in `throughline()`. Loaded when an email is sent, so a missing one says so then, naming the package |
+| `next`, `react`, `@payloadcms/ui`, `@payloadcms/next`               | `/client` and `/rsc`, which Payload's admin imports                                                                      |
+| `@vercel/blob`, `@payloadcms/plugin-cloud-storage`                  | `/media`'s client-upload hardening                                                                                       |
+| `vitest`                                                            | `/testing`                                                                                                               |
 
-## Why all of this lives in one package
+`src/peers.test.ts` checks the table: a static import that would load an optional peer from somewhere else fails it.
 
-Server packages (Component, Publishing, Approvals, Audit Query, Forms, Integrations) all depend on the same audit log, the same authentication pattern, and the same event taxonomy. Splitting these across packages would create circular dependencies — every server package would need the audit writer, and an audit-only package would need to know about every server. Consolidating the plumbing here keeps the dependency graph one-way: core → server packages → client app.
+Every option, the jobs `suite.jobs` holds, the audit log, MCP authentication, the environment check and the `throughline-payload` bin are in [the reference](https://github.com/forumone/throughline/blob/main/docs/reference/throughline.md).

package/bin/throughline.mjs

@@ -0,0 +1,6 @@
+#!/usr/bin/env node
+// `throughline migrate-imports`: 0.x imports to their 1.0 homes. See
+// ../src/migrate/cli.ts.
+import { main } from '../dist/migrate/cli.js'
+
+process.exitCode = await main(process.argv.slice(2))

package/dist/approvals/tokens.d.ts

@@ -2,7 +2,7 @@
  * HMAC-signed action tokens used in inline action emails (Approve / Decline /
  * Request changes / Discuss). Each token is bound to one approval, one
  * action, and one approver. Tokens are valid for a configurable window
- * (default 14 days) and consumed via the `consumedTokens` array on the
+ * (default 72 hours) and consumed via the `consumedTokens` array on the
  * approval record so they can't be replayed.
  *
  * Crypto uses the Web Crypto API (`crypto.subtle`) so the same code runs
@@ -22,7 +22,7 @@ export interface ActionToken {
  */
 export declare function generateActionToken(token: ActionToken, secret: string): Promise<string>;
 export interface VerifyOptions {
-    /** Override the default 14-day token lifetime. */
+    /** Override the default 72-hour token lifetime. */
     maxAgeMs?: number;
     /** Override "now" — useful in tests. Defaults to `Date.now()`. */
     now?: number;

package/dist/approvals/tokens.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"tokens.d.ts","sourceRoot":"","sources":["../../src/approvals/tokens.ts"],"names":[],"mappings":"AAAA;;;;;;;;;GASG;AAEH,MAAM,MAAM,iBAAiB,GAAG,SAAS,GAAG,SAAS,GAAG,SAAS,GAAG,SAAS,CAAA;AAE7E,MAAM,WAAW,WAAW;IAC1B,UAAU,EAAE,MAAM,CAAA;IAClB,MAAM,EAAE,iBAAiB,CAAA;IACzB,UAAU,EAAE,MAAM,CAAA;IAClB,uDAAuD;IACvD,QAAQ,EAAE,MAAM,CAAA;CACjB;AA2BD;;;GAGG;AACH,wBAAsB,mBAAmB,CACvC,KAAK,EAAE,WAAW,EAClB,MAAM,EAAE,MAAM,GACb,OAAO,CAAC,MAAM,CAAC,CAKjB;AAED,MAAM,WAAW,aAAa;IAC5B,kDAAkD;IAClD,QAAQ,CAAC,EAAE,MAAM,CAAA;IACjB,kEAAkE;IAClE,GAAG,CAAC,EAAE,MAAM,CAAA;CACb;AAED,MAAM,MAAM,YAAY,GACpB;IAAE,EAAE,EAAE,IAAI,CAAC;IAAC,KAAK,EAAE,WAAW,CAAA;CAAE,GAChC;IAAE,EAAE,EAAE,KAAK,CAAC;IAAC,KAAK,EAAE,MAAM,CAAA;CAAE,CAAA;AAEhC;;;GAGG;AACH,wBAAsB,iBAAiB,CACrC,OAAO,EAAE,MAAM,EACf,MAAM,EAAE,MAAM,EACd,OAAO,GAAE,aAAkB,GAC1B,OAAO,CAAC,YAAY,CAAC,CAiDvB;AAED;;;;GAIG;AACH,wBAAgB,cAAc,CAAC,SAAS,EAAE,MAAM,EAAE,KAAK,EAAE,MAAM,GAAG,MAAM,CAGvE"}
+{"version":3,"file":"tokens.d.ts","sourceRoot":"","sources":["../../src/approvals/tokens.ts"],"names":[],"mappings":"AAAA;;;;;;;;;GASG;AAEH,MAAM,MAAM,iBAAiB,GAAG,SAAS,GAAG,SAAS,GAAG,SAAS,GAAG,SAAS,CAAA;AAE7E,MAAM,WAAW,WAAW;IAC1B,UAAU,EAAE,MAAM,CAAA;IAClB,MAAM,EAAE,iBAAiB,CAAA;IACzB,UAAU,EAAE,MAAM,CAAA;IAClB,uDAAuD;IACvD,QAAQ,EAAE,MAAM,CAAA;CACjB;AA2BD;;;GAGG;AACH,wBAAsB,mBAAmB,CACvC,KAAK,EAAE,WAAW,EAClB,MAAM,EAAE,MAAM,GACb,OAAO,CAAC,MAAM,CAAC,CAKjB;AAED,MAAM,WAAW,aAAa;IAC5B,mDAAmD;IACnD,QAAQ,CAAC,EAAE,MAAM,CAAA;IACjB,kEAAkE;IAClE,GAAG,CAAC,EAAE,MAAM,CAAA;CACb;AAED,MAAM,MAAM,YAAY,GACpB;IAAE,EAAE,EAAE,IAAI,CAAC;IAAC,KAAK,EAAE,WAAW,CAAA;CAAE,GAChC;IAAE,EAAE,EAAE,KAAK,CAAC;IAAC,KAAK,EAAE,MAAM,CAAA;CAAE,CAAA;AAEhC;;;GAGG;AACH,wBAAsB,iBAAiB,CACrC,OAAO,EAAE,MAAM,EACf,MAAM,EAAE,MAAM,EACd,OAAO,GAAE,aAAkB,GAC1B,OAAO,CAAC,YAAY,CAAC,CAiDvB;AAED;;;;GAIG;AACH,wBAAgB,cAAc,CAAC,SAAS,EAAE,MAAM,EAAE,KAAK,EAAE,MAAM,GAAG,MAAM,CAGvE"}

package/dist/approvals/tokens.js

@@ -2,7 +2,7 @@
  * HMAC-signed action tokens used in inline action emails (Approve / Decline /
  * Request changes / Discuss). Each token is bound to one approval, one
  * action, and one approver. Tokens are valid for a configurable window
- * (default 14 days) and consumed via the `consumedTokens` array on the
+ * (default 72 hours) and consumed via the `consumedTokens` array on the
  * approval record so they can't be replayed.
  *
  * Crypto uses the Web Crypto API (`crypto.subtle`) so the same code runs
@@ -18,7 +18,7 @@
  * Seventy-two hours is what an approval actually needs. It covers a weekend,
  * which is the realistic gap between sending a request and somebody opening
  * their mail, and it is well inside the request's own expiry so the two cannot
- * disagree. `createExpireStaleApprovalsFunction` handles anything that ages
+ * disagree. `expireStaleApprovalsJob` handles anything that ages
  * out either way.
  *
  * The token is otherwise well built — HMAC-SHA256, constant-time compare, bound

package/dist/audit/query/options.d.ts

@@ -1,5 +1,5 @@
 import type { McpToolCollector } from '../../mcp/collector.js';
-import type { PayloadRequest } from 'payload';
+import type { McpToolContext } from '../../plugin-contract/mcp.js';
 import type { BaseCorePluginOptions } from '../../plugin-contract/index.js';
 export interface AuditQueryPluginOptions extends Omit<BaseCorePluginOptions, 'routePrefix'> {
     /**
@@ -8,10 +8,12 @@ export interface AuditQueryPluginOptions extends Omit<BaseCorePluginOptions, 'ro
      */
     collectionSlug?: string;
     /**
-     * Custom access-control function for read operations. Returns true to
-     * allow reads. Defaults to admin and editor roles.
+     * Who may read the whole audit log through the tools. Anyone else is
+     * scoped to their own actions: `who_changed_what` about themselves, and a
+     * `permission-denied` envelope from the broad tools. Default
+     * `isAuditReader`: the `admin` and `editor` roles.
      */
-    readAccess?: (req: PayloadRequest) => boolean;
+    readAccess?: (ctx: McpToolContext) => boolean;
     /**
      * Where to put this server's MCP tools so Payload's own MCP plugin can serve
      * them.

package/dist/audit/query/options.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"options.d.ts","sourceRoot":"","sources":["../../../src/audit/query/options.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,EAAE,gBAAgB,EAAE,MAAM,wBAAwB,CAAA;AAC9D,OAAO,KAAK,EAAE,cAAc,EAAE,MAAM,SAAS,CAAA;AAC7C,OAAO,KAAK,EAAE,qBAAqB,EAAE,MAAM,gCAAgC,CAAA;AAQ3E,MAAM,WAAW,uBAAwB,SAAQ,IAAI,CAAC,qBAAqB,EAAE,aAAa,CAAC;IACzF;;;OAGG;IACH,cAAc,CAAC,EAAE,MAAM,CAAA;IACvB;;;OAGG;IACH,UAAU,CAAC,EAAE,CAAC,GAAG,EAAE,cAAc,KAAK,OAAO,CAAA;IAE7C;;;;;;;;;;;OAWG;IACH,QAAQ,CAAC,EAAE,gBAAgB,CAAA;CAC5B;AAED;;;GAGG;AACH,wBAAgB,eAAe,CAAC,OAAO,EAAE,uBAAuB,GAAG,uBAAuB,CAEzF"}
+{"version":3,"file":"options.d.ts","sourceRoot":"","sources":["../../../src/audit/query/options.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,EAAE,gBAAgB,EAAE,MAAM,wBAAwB,CAAA;AAC9D,OAAO,KAAK,EAAE,cAAc,EAAE,MAAM,8BAA8B,CAAA;AAClE,OAAO,KAAK,EAAE,qBAAqB,EAAE,MAAM,gCAAgC,CAAA;AAQ3E,MAAM,WAAW,uBAAwB,SAAQ,IAAI,CAAC,qBAAqB,EAAE,aAAa,CAAC;IACzF;;;OAGG;IACH,cAAc,CAAC,EAAE,MAAM,CAAA;IACvB;;;;;OAKG;IACH,UAAU,CAAC,EAAE,CAAC,GAAG,EAAE,cAAc,KAAK,OAAO,CAAA;IAE7C;;;;;;;;;;;OAWG;IACH,QAAQ,CAAC,EAAE,gBAAgB,CAAA;CAC5B;AAED;;;GAGG;AACH,wBAAgB,eAAe,CAAC,OAAO,EAAE,uBAAuB,GAAG,uBAAuB,CAEzF"}

package/dist/audit/query/options.js.map

@@ -1 +1 @@
-{"version":3,"file":"options.js","sourceRoot":"","sources":["../../../src/audit/query/options.ts"],"names":[],"mappings":"AAqCA;;;GAGG;AACH,MAAM,UAAU,eAAe,CAAC,OAAgC;IAC9D,OAAO,OAAO,CAAA;AAChB,CAAC"}
+{"version":3,"file":"options.js","sourceRoot":"","sources":["../../../src/audit/query/options.ts"],"names":[],"mappings":"AAuCA;;;GAGG;AACH,MAAM,UAAU,eAAe,CAAC,OAAgC;IAC9D,OAAO,OAAO,CAAA;AAChB,CAAC"}

package/dist/audit/query/plugin.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"plugin.d.ts","sourceRoot":"","sources":["../../../src/audit/query/plugin.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,EAAE,UAAU,EAAE,MAAM,gCAAgC,CAAA;AAMhE,OAAO,EAAE,KAAK,uBAAuB,EAAmB,MAAM,cAAc,CAAA;AAY5E;;;;;;GAMG;AACH,eAAO,MAAM,gBAAgB,EAAE,UAAU,CAAC,uBAAuB,CA0D9D,CAAA"}
+{"version":3,"file":"plugin.d.ts","sourceRoot":"","sources":["../../../src/audit/query/plugin.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,EAAE,UAAU,EAAE,MAAM,gCAAgC,CAAA;AAMhE,OAAO,EAAE,KAAK,uBAAuB,EAAmB,MAAM,cAAc,CAAA;AAY5E;;;;;;GAMG;AACH,eAAO,MAAM,gBAAgB,EAAE,UAAU,CAAC,uBAAuB,CA8D9D,CAAA"}

package/dist/audit/query/plugin.js

@@ -41,7 +41,11 @@ export const auditQueryPlugin = (rawOptions) => (incomingConfig) => {
             would look is the thing that broke.
             */
             const auditWriter = getAuditWriter(payload);
-            const deps = { payload, collectionSlug };
+            const deps = {
+                payload,
+                collectionSlug,
+                ...(options.readAccess ? { canRead: options.readAccess } : {}),
+            };
             const tools = [
                 createQueryAuditTool(deps),
                 createGetChangeHistoryTool(deps),

package/dist/audit/query/plugin.js.map

@@ -1 +1 @@
-{"version":3,"file":"plugin.js","sourceRoot":"","sources":["../../../src/audit/query/plugin.ts"],"names":[],"mappings":"AAEA,OAAO,EAAE,iBAAiB,EAAE,MAAM,mCAAmC,CAAA;AACrE,OAAO,EAAE,iBAAiB,EAAE,aAAa,EAAE,MAAM,uBAAuB,CAAA;AACxE,OAAO,EAAE,cAAc,EAAE,MAAM,cAAc,CAAA;AAC7C,OAAO,EAAE,kBAAkB,EAAE,MAAM,kBAAkB,CAAA;AACrD,OAAO,EAAgC,eAAe,EAAE,MAAM,cAAc,CAAA;AAC5E,OAAO,EACL,sBAAsB,EACtB,0BAA0B,EAC1B,2BAA2B,EAC3B,oBAAoB,EACpB,4BAA4B,EAC5B,wBAAwB,GACzB,MAAM,kBAAkB,CAAA;AAEzB,MAAM,SAAS,GAAG,mCAAmC,CAAA;AACrD,MAAM,cAAc,GAAG,OAAO,CAAA;AAC9B;;;;;;GAMG;AACH,MAAM,CAAC,MAAM,gBAAgB,GAC3B,CAAC,UAAU,EAAE,EAAE,CAAC,CAAC,cAAc,EAAE,EAAE;IACjC,IAAI,UAAU,CAAC,OAAO,KAAK,KAAK;QAAE,OAAO,cAAc,CAAA;IAEvD,MAAM,OAAO,GAAG,eAAe,CAAC,UAAU,CAAC,CAAA;IAC3C,MAAM,cAAc,GAAG,OAAO,CAAC,cAAc,IAAI,kBAAkB,CAAA;IACnE,MAAM,MAAM,GAAG,iBAAiB,CAAC,aAAa,EAAE,OAAO,CAAC,MAAM,IAAI,aAAa,CAAC,CAAA;IAEhF;;;;;MAKE;IACF,OAAO,CAAC,QAAQ,EAAE,OAAO,CAAC,sBAAsB,EAAE,EAAE,UAAU,EAAE,OAAO,EAAE,CAAC,CAAA;IAE1E,OAAO;QACL,GAAG,cAAc;QACjB,MAAM,EAAE,KAAK,EAAE,OAAO,EAAE,EAAE;YACxB,IAAI,cAAc,CAAC,MAAM;gBAAE,MAAM,cAAc,CAAC,MAAM,CAAC,OAAO,CAAC,CAAA;YAE/D,MAAM,QAAQ,GAAG,iBAAiB,CAAC,OAAO,CAAC,CAAA;YAC3C,QAAQ,CAAC,iBAAiB,CAAC,WAAW,EAAE,SAAS,CAAC,CAAA;YAElD;;;;;;cAME;YACF,MAAM,WAAW,GAAG,cAAc,CAAC,OAAO,CAAC,CAAA;YAC3C,MAAM,IAAI,GAAG,EAAE,OAAO,EAAE,cAAc,EAAE,CAAA;YACxC,MAAM,KAAK,GAAG;gBACZ,oBAAoB,CAAC,IAAI,CAAC;gBAC1B,0BAA0B,CAAC,IAAI,CAAC;gBAChC,wBAAwB,CAAC,IAAI,CAAC;gBAC9B,4BAA4B,CAAC,IAAI,CAAC;gBAClC,2BAA2B,CAAC,IAAI,CAAC;aACA,CAAA;YAEnC,qEAAqE;YACrE,sEAAsE;YACtE,8CAA8C;YAC9C,OAAO,CAAC,QAAQ,EAAE,GAAG,CAAC,KAAK,EAAE,EAAE,UAAU,EAAE,OAAO,EAAE,MAAM,EAAE,KAAK,EAAE,WAAW,EAAE,CAAC,CAAA;YAEjF,QAAQ,CAAC,QAAQ,CAAC;gBAChB,EAAE,EAAE,SAAS;gBACb,OAAO,EAAE,cAAc;gBACvB,YAAY,EAAE,CAAC,aAAa,CAAC;aAC9B,CAAC,CAAA;YAEF,MAAM,CAAC,IAAI,CAAC,0BAA0B,EAAE;gBACtC,cAAc;gBACd,SAAS,EAAE,KAAK,CAAC,MAAM;aACxB,CAAC,CAAA;QACJ,CAAC;KACF,CAAA;AACH,CAAC,CAAA"}
+{"version":3,"file":"plugin.js","sourceRoot":"","sources":["../../../src/audit/query/plugin.ts"],"names":[],"mappings":"AAEA,OAAO,EAAE,iBAAiB,EAAE,MAAM,mCAAmC,CAAA;AACrE,OAAO,EAAE,iBAAiB,EAAE,aAAa,EAAE,MAAM,uBAAuB,CAAA;AACxE,OAAO,EAAE,cAAc,EAAE,MAAM,cAAc,CAAA;AAC7C,OAAO,EAAE,kBAAkB,EAAE,MAAM,kBAAkB,CAAA;AACrD,OAAO,EAAgC,eAAe,EAAE,MAAM,cAAc,CAAA;AAC5E,OAAO,EACL,sBAAsB,EACtB,0BAA0B,EAC1B,2BAA2B,EAC3B,oBAAoB,EACpB,4BAA4B,EAC5B,wBAAwB,GACzB,MAAM,kBAAkB,CAAA;AAEzB,MAAM,SAAS,GAAG,mCAAmC,CAAA;AACrD,MAAM,cAAc,GAAG,OAAO,CAAA;AAC9B;;;;;;GAMG;AACH,MAAM,CAAC,MAAM,gBAAgB,GAC3B,CAAC,UAAU,EAAE,EAAE,CAAC,CAAC,cAAc,EAAE,EAAE;IACjC,IAAI,UAAU,CAAC,OAAO,KAAK,KAAK;QAAE,OAAO,cAAc,CAAA;IAEvD,MAAM,OAAO,GAAG,eAAe,CAAC,UAAU,CAAC,CAAA;IAC3C,MAAM,cAAc,GAAG,OAAO,CAAC,cAAc,IAAI,kBAAkB,CAAA;IACnE,MAAM,MAAM,GAAG,iBAAiB,CAAC,aAAa,EAAE,OAAO,CAAC,MAAM,IAAI,aAAa,CAAC,CAAA;IAEhF;;;;;MAKE;IACF,OAAO,CAAC,QAAQ,EAAE,OAAO,CAAC,sBAAsB,EAAE,EAAE,UAAU,EAAE,OAAO,EAAE,CAAC,CAAA;IAE1E,OAAO;QACL,GAAG,cAAc;QACjB,MAAM,EAAE,KAAK,EAAE,OAAO,EAAE,EAAE;YACxB,IAAI,cAAc,CAAC,MAAM;gBAAE,MAAM,cAAc,CAAC,MAAM,CAAC,OAAO,CAAC,CAAA;YAE/D,MAAM,QAAQ,GAAG,iBAAiB,CAAC,OAAO,CAAC,CAAA;YAC3C,QAAQ,CAAC,iBAAiB,CAAC,WAAW,EAAE,SAAS,CAAC,CAAA;YAElD;;;;;;cAME;YACF,MAAM,WAAW,GAAG,cAAc,CAAC,OAAO,CAAC,CAAA;YAC3C,MAAM,IAAI,GAAG;gBACX,OAAO;gBACP,cAAc;gBACd,GAAG,CAAC,OAAO,CAAC,UAAU,CAAC,CAAC,CAAC,EAAE,OAAO,EAAE,OAAO,CAAC,UAAU,EAAE,CAAC,CAAC,CAAC,EAAE,CAAC;aAC/D,CAAA;YACD,MAAM,KAAK,GAAG;gBACZ,oBAAoB,CAAC,IAAI,CAAC;gBAC1B,0BAA0B,CAAC,IAAI,CAAC;gBAChC,wBAAwB,CAAC,IAAI,CAAC;gBAC9B,4BAA4B,CAAC,IAAI,CAAC;gBAClC,2BAA2B,CAAC,IAAI,CAAC;aACA,CAAA;YAEnC,qEAAqE;YACrE,sEAAsE;YACtE,8CAA8C;YAC9C,OAAO,CAAC,QAAQ,EAAE,GAAG,CAAC,KAAK,EAAE,EAAE,UAAU,EAAE,OAAO,EAAE,MAAM,EAAE,KAAK,EAAE,WAAW,EAAE,CAAC,CAAA;YAEjF,QAAQ,CAAC,QAAQ,CAAC;gBAChB,EAAE,EAAE,SAAS;gBACb,OAAO,EAAE,cAAc;gBACvB,YAAY,EAAE,CAAC,aAAa,CAAC;aAC9B,CAAC,CAAA;YAEF,MAAM,CAAC,IAAI,CAAC,0BAA0B,EAAE;gBACtC,cAAc;gBACd,SAAS,EAAE,KAAK,CAAC,MAAM;aACxB,CAAC,CAAA;QACJ,CAAC;KACF,CAAA;AACH,CAAC,CAAA"}