@canonry/canonry 4.159.0 → 4.161.0

package/README.md

@@ -94,7 +94,7 @@ Configure during `cnry init`, in the dashboard `/settings`, or as env vars.
 | **Aero — built-in agent** | [skills/aero/SKILL.md](skills/aero/SKILL.md) |
 | **Agent Plugin — portable core + Codex / Claude adapters** | [docs/plugins.md](docs/plugins.md) |
 | **MCP — Claude Desktop / Cursor / Codex** | [docs/mcp.md](docs/mcp.md) |
-| **Integrations** | [GSC](docs/google-search-console-setup.md) · [GA4](docs/google-analytics-setup.md) · [Bing](docs/bing-webmaster-setup.md) · [Google Business Profile](skills/canonry/references/google-business-profile.md) · [WordPress](docs/wordpress-setup.md) · [Server-side traffic (Cloudflare direct push, Cloud Run, Vercel, WordPress)](skills/canonry/references/server-side-traffic.md) |
+| **Integrations** | [GSC](docs/google-search-console-setup.md) · [GA4](docs/google-analytics-setup.md) · [Bing](docs/bing-webmaster-setup.md) · [Google Business Profile](skills/canonry/references/google-business-profile.md) · [WordPress](docs/wordpress-setup.md) · [Server-side traffic (Cloudflare direct push or Queue pull, Cloud Run, Vercel, WordPress)](skills/canonry/references/server-side-traffic.md) |
 | **Deployment** — Docker, Railway, Render, systemd, Tailscale | [docs/deployment.md](docs/deployment.md) |
 | **API** — 118+ endpoints | `GET /api/v1/openapi.json` (no auth) |
 | **Standalone skills bundle** for Claude Code / Codex | `cnry skills install` ([details](skills/canonry/SKILL.md)) |

package/assets/agent-workspace/skills/aero/SKILL.md

@@ -16,7 +16,22 @@ Persist only *user-scoped* context (operator preferences, communication style) i
 
 **Two signals, not one.** Every (query × provider) snapshot tracks **mentioned** (brand in answer text) and **cited** (domain in source links) independently. Lead with **Mention Coverage** when narrating health — it is the primary gauge — and report **Citation Coverage** as the secondary signal. Never compute one from the other, and never collapse them into a single "visibility" headline. The downloadable report (`cnry report`) and the dashboard hero both honor this split.
 
-When a project has GA4 connected, traffic is a first-class signal alongside mentions and citations. Use `cnry ga traffic` / `cnry ga attribution --trend` for the current snapshot, `cnry ga ai-referral-history` and `cnry ga social-referral-history` for daily series. Reads query a local DB synced by `cnry ga sync` — confirm `cnry ga status` shows a recent `lastSyncedAt` before quoting numbers; if stale, ask for explicit approval before re-syncing. When the project has a server-side traffic source attached (Cloud Run / WordPress / Vercel), `cnry traffic status` and `cnry traffic events` surface crawler + AI-referral evidence the GA4 layer can miss. Full command reference and return shapes live in the co-installed `canonry/references/canonry-cli.md`.
+When a project has GA4 connected, traffic is a first-class signal alongside
+mentions and citations. Use `cnry ga traffic` and `cnry ga attribution --trend`
+for the current snapshot. Use the GA referral-history commands for daily series.
+Before you quote GA4 data, make sure that `cnry ga status` has a recent
+`lastSyncedAt`. If it is stale, get approval before you run `cnry ga sync`.
+
+For Cloud Run, WordPress, Vercel, or Cloudflare, use `cnry traffic status` and
+`cnry traffic events` for crawler and AI-referral evidence. Read the Cloudflare
+`deliveryMode` before you recommend an action. Direct push does not use
+`traffic sync`. Queue pull freshness requires an enabled `traffic-sync`
+schedule. Run the `traffic.source.*` doctor checks. Inspect
+`traffic.source.queue-backlog` before you quote current Queue data. If more than
+1,000 messages remain, report that one default tick cannot drain the backlog.
+Get approval before you run a manual sync or change the schedule. The full
+command reference is in the co-installed
+`canonry/references/canonry-cli.md`.
 
 **Diagnosing a stuck Vercel/Cloud Run source:** if `cnry traffic status` shows `status=error` with a recent `lastError` of `refusing to advance` or `ExceedsBillingLimitError`, the source's `lastSyncedAt` has aged past the upstream retention boundary and every sync now throws. Recovery: `cnry traffic reset <project> --source <id> --advance-to-now`. This advances `lastSyncedAt` to NOW and resumes going-forward syncs — historical events in the gap are unrecoverable from the sync path; run `cnry traffic backfill --days N` separately if any of that history is needed (capped at retention).
 

package/assets/agent-workspace/skills/canonry/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: canonry
-description: "Set up and operate Canonry AEO projects: inspect mention and citation coverage, diagnose regressions, run technical audits, and act through the Canonry CLI or MCP tools. Examples: inspect project acme coverage (run + report), diagnose query drift via attribution (report.html + visibility-attribution), submit GSC sitemaps (gsc-sitemap-submission batched)."
+description: "Set up and operate Canonry AEO projects. Inspect mention and citation coverage, diagnose regressions, and run technical audits. Connect Cloudflare direct-push or queue-pull traffic. Act through the Canonry CLI or MCP tools. Examples: inspect project acme coverage (run + report), diagnose query drift via attribution (report.html + visibility-attribution), or submit GSC sitemaps (gsc-sitemap-submission batched)."
 compatibility: Requires Node.js 22.14+ and globally installed @canonry/canonry; canonry-mcp must be on PATH.
 metadata:
   agent: >-
@@ -131,10 +131,22 @@ GA4 is a first-class signal alongside citation tracking. Connect once with `cnry
 
 When the project ships behind a server you control, connect Cloud Run, WordPress,
 or Vercel. `cnry traffic sync` pulls and classifies their logs into hourly
-buckets. For a Cloudflare site, `cnry traffic connect cloudflare <project> ...`
-deploys a direct-push Worker from the credential-owning host. Cloudflare direct
-push does not use `traffic sync`. Use `cnry traffic events / sources / status`
-for every adapter. See `references/server-side-traffic.md` for setup.
+buckets. For Cloudflare, choose `direct-push` or `queue-pull` on the local,
+credential-owning host. Direct push requires a public Canonry HTTPS receiver.
+It does not use `traffic sync`. Queue pull sends events to a Cloudflare Queue,
+then Canonry drains it through `traffic sync` and the `traffic-sync` schedule.
+
+If the connect response reports `activationRequired`, attach the Worker route
+first. Then run `cnry traffic activate <project> --source <id>`. Activation
+pauses all sibling sources. It also moves the one `traffic-sync` schedule to
+Queue pull. A first source becomes active automatically.
+
+Each default Queue tick drains at most 1,000 messages. Use `cnry traffic status`
+and the `traffic.source.queue-backlog` doctor check to read the backlog. If more
+than 1,000 messages remain, get approval before a manual sync or a shorter
+schedule interval. Use `cnry traffic events`, `cnry traffic sources`, and
+`cnry traffic status` for every adapter. See
+`references/server-side-traffic.md` for setup and smoke tests.
 
 **Vercel gotcha:** a freshly connected Vercel source captures only going-forward traffic — `lastSyncedAt` is seeded to NOW to avoid the 30-day default window exceeding Vercel's ~14-day request-logs retention (which would otherwise throw on every first sync). Use `cnry traffic backfill <project> --source <id> --days N` for historical recovery. If an idle Vercel/Cloud Run source has been failing long enough that `lastSyncedAt` aged past retention, unstick it with `cnry traffic reset <project> --source <id> --advance-to-now`.
 

package/assets/agent-workspace/skills/canonry/references/canonry-cli.md

@@ -564,6 +564,72 @@ cnry wordpress onboard <project> --url <url> --user <user>  # full onboarding wo
 
 **Onboard** runs: connect → audit → set-meta → schema deploy → Google submit → Bing submit. Use `--skip-schema` or `--skip-submit` to skip steps. `--profile <file>` provides business data and page-to-schema mapping for schema deployment.
 
+## Server-Side Traffic
+
+Cloudflare supports direct push and Queue pull. Run Cloudflare connect only from
+the local host that owns the Canonry configuration and Wrangler profile. This
+operation is not available through MCP because it uses local credentials.
+
+```bash
+# Direct push to a stable public Canonry HTTPS receiver:
+cnry traffic connect cloudflare <project> \
+  --delivery-mode direct-push \
+  --zone-id <zone-id> --account-id <account-id> \
+  --deploy --confirm-route --confirm-fail-open
+
+# Create the Queue and enable its HTTP pull consumer first:
+wrangler queues create canonry-traffic-<project>
+# Workers Paid only: use this command to change the four-day default.
+wrangler queues update canonry-traffic-<project> \
+  --message-retention-period-secs <seconds>
+wrangler queues info canonry-traffic-<project>
+wrangler queues consumer http add canonry-traffic-<project>
+
+# Queue pull keeps the API token in the local Canonry credential store:
+cnry traffic connect cloudflare <project> \
+  --delivery-mode queue-pull \
+  --zone-id <zone-id> --account-id <account-id> \
+  --queue-id <queue-id> --queue-name canonry-traffic-<project> \
+  --api-token-file <mode-0600-token-file> \
+  --retention-seconds <actual-queue-retention-seconds> \
+  --deploy --confirm-route --confirm-fail-open
+```
+
+Workers Free retention is fixed at `86400` seconds. Workers Paid defaults to
+`345600` seconds. If you change paid retention with `wrangler queues update`,
+pass the same value to Canonry. The Canonry flag does not change the Queue.
+
+Both commands deploy an unattached Worker. Attach the exact site route in the
+Cloudflare Dashboard. Then set its request-limit failure mode to **Fail open**.
+Do not put the Queue API token on the command line or in an agent transcript.
+
+```bash
+# If connect reports activationRequired, activate after the route is live:
+cnry traffic activate <project> --source <source-id>
+cnry traffic sync <project> --source <source-id>      # pull adapters, including Cloudflare Queue pull
+cnry traffic sources <project> --format json
+cnry traffic status <project> --format json
+cnry traffic events <project> --source <source-id> --format json
+
+cnry doctor --project <project> --check 'traffic.source.*' --format json
+cnry schedule show <project> --kind traffic-sync --format json
+cnry schedule set <project> --kind traffic-sync \
+  --source <source-id> --cron "*/10 * * * *"
+```
+
+A first source becomes active automatically. A staged source stays paused until
+the explicit activation command. Activation pauses sibling sources and moves the
+one `traffic-sync` schedule for the project. Direct push rejects `traffic sync` and
+does not use this schedule.
+
+Queue pull drains at most 1,000 messages in one default sync. The doctor warns
+when the remaining backlog is more than 1,000 messages. If the operator approves
+a manual drain, run a manual sync. If the backlog recurs, get approval to shorten
+the schedule interval.
+
+Read the [server-side traffic guide](server-side-traffic.md) for token safety,
+route checks, activation order, smoke tests, rollback, and troubleshooting.
+
 ## Google Analytics 4
 
 GA4 integration uses service account authentication (no OAuth). The service account must have Viewer access on the GA4 property. `ga sync` writes to four DB tables (`gaTrafficSnapshots`, `gaAiReferrals`, `gaSocialReferrals`, `gaTrafficSummaries`); every subsequent read command queries the local store rather than re-fetching from GA4, so reads are fast and quotaless. AI-referral rows are tracked across 10 known providers (chatgpt, perplexity, claude, gemini, openai, anthropic, copilot, phind, you.com, meta.ai), three GA4 attribution dimensions (`session` / `first_user` / `manual_utm`), and joined to landing pages. Social referrals are split Organic vs Paid via GA4's `sessionDefaultChannelGroup`. All commands support `--format json`.

package/assets/agent-workspace/skills/canonry/references/server-side-traffic.md

@@ -39,11 +39,12 @@ Adapters today:
 | [`cloud-run`](#connecting-a-cloud-run-source) | Pull | GCP Cloud Run request logs via Logging API | Any service running on Cloud Run |
 | [`wordpress`](#connecting-a-wordpress-source) | Pull | Canonry Traffic Logger REST endpoint | WordPress sites where you control wp-admin |
 | [`vercel`](#connecting-a-vercel-source) | Pull | Vercel project logs via the Vercel API | Sites deployed on Vercel |
-| [`cloudflare`](#connecting-a-cloudflare-source-direct-push) | Direct push | A zone Worker selects and sends edge events | Sites whose public traffic passes through Cloudflare |
+| [`cloudflare`](#connecting-a-cloudflare-source) | Direct push or Queue pull | A zone Worker selects edge events; Canonry either receives them directly or pulls them from Cloudflare Queues | Sites whose public traffic passes through Cloudflare |
 
 Future adapters slot in by implementing the same contract.
-Cloud Run, WordPress, and Vercel pull logs during `traffic sync`.
-Cloudflare sends selected events from its Worker and does not use `traffic sync`.
+Cloud Run, WordPress, Vercel, and Cloudflare Queue sources pull during
+`traffic sync`. Cloudflare direct push sends selected events from its Worker
+and does not use `traffic sync`.
 
 ## Connecting a Cloud Run source
 
@@ -195,31 +196,38 @@ Run `cnry traffic backfill <project> --source <id> --days N` (capped at
 history. It's an explicit operator action; the connect flow never pulls
 it implicitly.
 
-## Connecting a Cloudflare source (direct push)
+## Connecting a Cloudflare source
 
-Cloudflare direct push runs a small ES-module Worker on the site's exact
-zone route. It applies a broad AI filter and sends selected edge events
-to Canonry in `ctx.waitUntil()`. The origin response remains independent
-from filtering, scheduling, and delivery errors. The event shape is also
-the contract for the later Queue pull transport.
+Both Cloudflare modes run the same small ES-module Worker on the site's exact
+zone route. It applies a broad AI filter and delivers selected edge events in
+`ctx.waitUntil()`. The origin response remains independent from filtering,
+scheduling, and delivery errors. Both modes use the same
+`CloudflareEdgeEventBatch`, normalizer, classifier, receipts, and rollups.
 
-The shipped adapter does not pull Cloudflare analytics or request logs.
-Queue pull has a reserved transport mode, but it is not available yet.
+- `direct-push` sends a signed batch to a public Canonry HTTPS receiver.
+- `queue-pull` sends the batch to a Cloudflare Queue. The single-team Canonry
+  server pulls and acknowledges it through the Cloudflare Queues HTTP API.
+
+The adapter does not pull Cloudflare analytics or request logs.
 
 ```mermaid
 flowchart LR
   request["Site request"] --> worker["Canonry Cloudflare Worker"]
   worker --> origin["Existing origin or Pages site"]
   origin --> response["Unchanged site response"]
-  worker -. "signed selected event via ctx.waitUntil" .-> ingest["Canonry public HTTPS ingest"]
-  ingest --> classify["Shared traffic classifier"]
+  worker -. "direct-push" .-> ingest["Canonry public HTTPS ingest"]
+  worker -. "queue-pull" .-> queue["Cloudflare Queue"]
+  queue --> pull["Canonry scheduled pull"]
+  ingest --> classify["Shared receipt and traffic pipeline"]
+  pull --> classify
   classify --> rollups["Hourly crawler, user-fetch, and referral rollups"]
 ```
 
 ### Setup flow
 
 1. Create or select a Canonry project with one exact canonical hostname.
-2. Give the Canonry server a stable public HTTPS URL outside the site route.
+2. Choose delivery: direct push needs a stable public Canonry HTTPS URL outside
+   the site route; Queue pull needs a pre-created Queue and HTTP pull consumer.
 3. Authenticate Wrangler with the Cloudflare account that owns the zone.
 4. Inspect existing Worker routes for the exact canonical hostname.
 5. Run the local Cloudflare connect command with `--deploy`.
@@ -228,20 +236,23 @@ flowchart LR
 
 ### Current support boundary
 
-Direct push currently supports a local `canonry serve` instance. The CLI
-and server must read the same `~/.canonry/config.yaml` credential store.
-You can expose that local server through a stable HTTPS tunnel.
+Both modes currently target one local, single-team `canonry serve` instance.
+The Queue consumer is not a multi-tenant Cloudflare control plane. The CLI and
+server must read the same `~/.canonry/config.yaml` credential store. Direct
+push requires a stable public HTTPS receiver; Queue pull does not.
 
 The Cloud Run `apps/api` service has no Cloudflare credential store.
-Therefore, `apps/api` cannot retain the per-source bearer and HMAC values
-that deployment requires.
+Therefore, `apps/api` cannot retain direct-push bearer/HMAC values or the
+Queue API token.
 
-CAUTION: Use one authoritative server-traffic source for the canonical
-site. Overlapping adapters capture the same requests and double-count
-project totals. This is a current limitation. Queue support must define
-source coverage before it permits a transport change.
+CAUTION: Use one authoritative server-traffic source for the canonical site.
+Connecting any adapter while a sibling source is active creates or keeps a
+paused staged source. `canonry traffic activate` validates the target's local
+credential, atomically pauses every sibling, and moves or removes the one
+traffic-sync schedule. Overlapping adapters outside this cutover can still
+double-count project totals.
 
-### Expose the Canonry receiver
+### Expose the Canonry receiver (direct push only)
 
 Complete the local dashboard setup and set its password before you expose
 Canonry. A tunnel makes the loopback server reachable from the public Internet.
@@ -342,18 +353,20 @@ Worker and keeps the origin available. See [Cloudflare Workers limits](https://d
 Free-plan classification uses user-agent, referer, and UTM evidence. Granular
 `request.cf.botManagement` scores require the Enterprise Bot Management add-on.
 
-### Generate or deploy
+### Generate or deploy direct push
 
 ```bash
 # Generate secret-free worker.js and wrangler.toml in
 # ./canonry-cloudflare-<project-slug>:
 cnry traffic connect cloudflare <project> \
+  --delivery-mode direct-push \
   --zone-id <cloudflare-zone-id> \
   --account-id <cloudflare-account-id>
 
 # Deploy only the Worker after the route preflight.
 # Both safety acknowledgements are mandatory:
 cnry traffic connect cloudflare <project> \
+  --delivery-mode direct-push \
   --zone-id <cloudflare-zone-id> \
   --account-id <cloudflare-account-id> \
   --deploy --confirm-route --confirm-fail-open
@@ -413,6 +426,112 @@ Cloudflare connect is absent from MCP because deployment reads local
 secrets. An agent can guide the CLI command. It must not request, print,
 or send either secret through chat.
 
+### Generate or deploy Queue pull
+
+Queue pull reuses the same edge filter without requiring a public Canonry
+receiver. Create the Queue first. Then use `wrangler queues info` to get its ID.
+Create a Cloudflare API token with **Account Queues Edit** for the owning
+account. Put only the token in a mode-0600 file. Keep that file off shell argv.
+
+```bash
+wrangler queues create canonry-traffic-<project>
+
+# Workers Paid only: use this command to change the four-day default.
+wrangler queues update canonry-traffic-<project> \
+  --message-retention-period-secs <seconds>
+
+wrangler queues info canonry-traffic-<project>
+wrangler queues consumer http add canonry-traffic-<project>
+
+cnry traffic connect cloudflare <project> \
+  --delivery-mode queue-pull \
+  --zone-id <cloudflare-zone-id> \
+  --account-id <cloudflare-account-id> \
+  --queue-id <cloudflare-queue-id> \
+  --queue-name canonry-traffic-<project> \
+  --api-token-file <path-to-mode-0600-token-file> \
+  --retention-seconds <actual-queue-retention-seconds>
+
+cnry traffic connect cloudflare <project> \
+  --delivery-mode queue-pull \
+  --zone-id <cloudflare-zone-id> \
+  --account-id <cloudflare-account-id> \
+  --queue-id <cloudflare-queue-id> \
+  --queue-name canonry-traffic-<project> \
+  --api-token-file <path-to-token-file> \
+  --retention-seconds <actual-queue-retention-seconds> \
+  --deploy --confirm-route --confirm-fail-open
+```
+
+Read the Queue ID from the `wrangler queues info` output. Pass that exact value
+to `--queue-id`.
+
+The `queues update` command sets Cloudflare retention on Workers Paid. The
+Canonry `--retention-seconds` option only records the actual value. It does not
+change the Queue. Use `86400` for Workers Free, where retention is fixed at one
+day. Workers Paid defaults to `345600` (four days). Paid accounts accept values
+from 60 seconds through 14 days. If you change the paid Queue, use the same
+value in both commands. See Cloudflare's [Queue limits](https://developers.cloudflare.com/queues/platform/limits/).
+
+The HTTP-consumer command is required. The producer binding does not enable
+HTTP pull. Cloudflare does not support an HTTP pull consumer in
+`wrangler.toml`. Remove any existing Worker consumer before you enable HTTP
+pull. One Queue cannot use both consumer types at the same time. See
+Cloudflare's [pull-consumer setup](https://developers.cloudflare.com/queues/configuration/pull-consumers/).
+
+The token stays only in Canonry's local credential store. It is not written to
+the source row, Worker, TOML, command output, MCP, or Worker bindings. Wrangler
+authentication remains the operator's active Wrangler profile. Canonry does
+not reuse the Queue pull token for deployment.
+
+The generated TOML contains one `[[queues.producers]]` binding named
+`CANONRY_TRAFFIC_QUEUE` and no direct-push ingest URL or Worker secrets. After
+the Worker is deployed and the route is ready, activate a staged source:
+
+```bash
+cnry traffic activate <project> --source <source-id>
+cnry traffic sync <project> --source <source-id>
+```
+
+A new project with no other active traffic source activates immediately. A
+mode change stays paused until the explicit activation command. Activation
+pauses the prior source and points the project's one `traffic-sync` schedule at
+Queue pull; activating direct push removes that Queue schedule.
+
+For Queue-to-direct rollback, drain Queue pull until its backlog is empty,
+switch the Cloudflare route, then activate direct push immediately. The route
+change and Canonry activation are separate operator actions, so keep the
+cutover window short.
+
+### Queue-pull acceptance test
+
+Use this test after the Queue-pull source is active and the Worker route is
+attached. The UTM request provides a deterministic classification signal.
+If connect reports `activationRequired`, activate the source before this test:
+
+```bash
+cnry traffic activate <project> --source <source-id>
+```
+
+```bash
+CANONRY_QUEUE_SMOKE_PATH="/canonry-cloudflare-queue-smoke/$(date -u +%Y%m%dT%H%M%SZ)"
+
+curl -sS -o /dev/null -w '%{http_code}\n' \
+  "https://www.example.com${CANONRY_QUEUE_SMOKE_PATH}?utm_source=chatgpt"
+
+sleep 2
+cnry traffic sync <project> --source <source-id>
+cnry traffic events <project> --source <source-id> \
+  --kind all --since-minutes 120 --limit 5000 --format json
+cnry traffic status <project> --format json
+cnry doctor --project <project> --check 'traffic.source.*' --format json
+```
+
+The manual sync must complete. The events output must contain the unique smoke
+path as an AI referral. The status output shows `queueBacklogCount` and
+`queueBacklogObservedAt`. The doctor must not report a credential failure. If
+the path is absent, wait two seconds and repeat the sync up to ten times.
+
 ### Direct-push behavior and smoke test
 
 The Worker forwards a request candidate when at least one condition is true:
@@ -434,7 +553,7 @@ Direct push has bounded retries for network failures and HTTP 408, 425,
 429, and 5xx responses (250 ms, then 1 s). Delivery is asynchronous and
 never changes the site's response. If Canonry remains unavailable after
 the retry budget, the selected event is lost. Direct push has no durable
-edge buffer. This limit is the primary reason to add Queue pull next.
+edge buffer. Use Queue pull when delivery needs a durable edge buffer.
 
 The receiver accepts at most 256 KiB per request. Its default budgets are
 6,000 requests per minute for each source and each caller IP. A bearer token
@@ -456,7 +575,7 @@ Raw samples retain the user-agent and normalized path. Do not put personal
 data in URL paths. Canonry replaces numeric, UUID, and long hexadecimal path
 segments with `:id`, but it retains other path segments.
 
-### User acceptance test
+### Direct-push acceptance test
 
 1. Choose a stable, harmless origin path and create a unique smoke-run name.
 2. Before route attachment, capture the origin response and source rollups.
@@ -570,11 +689,26 @@ For a dedicated Canonry-generated Worker:
 1. Detach the exact site route from the Worker.
 2. Request an ordinary site page. Make sure that the origin status,
    headers, and body remain healthy.
-3. Run `wrangler delete --config <artifact-directory>/wrangler.toml`.
-4. Stop the tunnel if no other integration uses it.
-5. Run the doctor. Expect source-health warnings until Canonry supports
+3. If this source uses Queue pull, run manual syncs until its backlog is zero.
+4. If a replacement source exists, activate it after the Queue is empty.
+5. If no replacement source exists, run
+   `cnry schedule remove <project> --kind traffic-sync`.
+6. If this source uses Queue pull, run
+   `wrangler queues consumer http remove <queue-name>`.
+7. Run `wrangler delete --config <artifact-directory>/wrangler.toml`.
+8. If this source uses direct push, stop its unused tunnel.
+9. Run the doctor. Expect source-health warnings until Canonry supports
    Cloudflare disconnect.
 
+CAUTION: If no other producer uses the Queue, delete it only after the drain:
+
+```bash
+wrangler queues delete <queue-name>
+```
+
+If the API token is dedicated to Canonry, revoke it after you remove the HTTP
+consumer.
+
 If Canonry code shares an existing Worker, remove only the Canonry code and
 bindings. Redeploy the prior Worker version. Do not delete the shared Worker.
 
@@ -589,30 +723,43 @@ source archival and local credential cleanup.
 | Wrangler preflight fails | Install the latest Wrangler. Run `wrangler whoami`. Then rerun connect. |
 | Worker deploys to the wrong account | Make the correct Wrangler profile active. Pass the matching `--account-id`. |
 | Route cannot attach | Make sure that the zone is active, DNS is proxied, and the exact route is unclaimed. Inspect every overlapping route. |
-| Receiver probe returns `403` | Remove the Access or WAF challenge from the exact ingest path. |
-| Worker log shows ingest `401` | Rerun connect from the credential-owning host. Make sure that system clocks differ by less than five minutes. |
-| No events arrive | Make sure that the route matches the exact host and `publicUrl` is reachable. Inspect AI Crawl Control, Access, WAF, and route precedence. Then send the UTM smoke request. |
+| Direct-push receiver returns `403` | Remove the Access or WAF challenge from the exact ingest path. |
+| Direct-push Worker log shows ingest `401` | Rerun connect from the credential-owning host. Make sure that system clocks differ by less than five minutes. |
+| No direct-push events arrive | Make sure that the route matches the exact host. Make sure that `publicUrl` is reachable. Inspect AI Crawl Control, Access, WAF, and route precedence. Then send the UTM smoke request. |
+| No Queue-pull events arrive | Run `wrangler queues info <queue-name>` and `wrangler queues consumer http list <queue-name>`. Make sure that the producer binding uses that Queue. Make sure that the account ID, Queue ID, and token scope match. Then run the Queue acceptance test. |
+| Queue pull returns `403` | Create a token with **Account Queues Edit** for the Queue account. Reconnect with the token file. |
+| Queue backlog remains above 1,000 | Run a manual sync. If the backlog grows again, shorten the 30-minute schedule interval. |
 | Some paths are absent | Inspect more-specific routes and terminating security rules. Integrate Canonry into those routes or document the excluded coverage. |
-| Ingest returns `429` | Wait for the rate window. The Worker retries twice, then drops the event. |
+| Direct-push ingest returns `429` | Wait for the rate window. The Worker retries twice, then drops the event. |
 | Site returns Cloudflare error `1027` | Set the route to **Fail open**, or detach it. The account exhausted its daily Worker requests. |
 | Doctor reports stale or empty direct-push data | Do not run `traffic sync`. Inspect the route, receiver, and Worker logs. Then repeat the smoke request. |
 
-### Queue pull seam (not shipped yet)
-
-Queue pull is the first follow-up for hosted or platform deployments with
-loopback-only tenant engines. Customer Workers cannot reach those engines.
-The future pull adapter will let Canonry read events without a public
-tenant-ingest endpoint.
-
-Before broad direct-push rollout, consider an edge sampling or batching control
-for high-volume generic bot traffic.
-
-`deliveryMode: direct-push` is explicit in the source config. The reserved
-`queue-pull` mode will keep the Worker filter, `CloudflareEdgeEventBatch`,
-canonical JSON encoding, normalizer, classifier, and rollups unchanged.
-Only delivery changes to a Queue binding, and Canonry gains a polling
-adapter. A source must use one mode at a time so the same edge event cannot
-arrive through both transports and double-count.
+### Queue pull delivery guarantees
+
+Queue delivery is at least once. Canonry claims a durable source-scoped sync
+lease, short-polls bounded batches, validates the transport-neutral event
+schema and canonical host, and commits event receipts plus rollups in one DB
+transaction. It acknowledges the Cloudflare lease only after that commit.
+
+If acknowledgement fails after commit, Cloudflare can redeliver the batch.
+The durable receipt makes the redelivery a no-op before Canonry acknowledges it
+again. Unsupported V8 messages and malformed message bodies are acknowledged
+as poison after their safe lease metadata is read; raw bodies and the API token
+never enter errors or logs. A process crash leaves unacknowledged messages for
+Cloudflare to redeliver after the visibility timeout.
+
+The source lease rejects concurrent scheduler and operator drains. A stale
+lease can be recovered after its expiry, and only its owner can release it.
+Receipts remain for Cloudflare's current 14-day platform maximum plus a replay
+margin. This stays safe even when the locally recorded retention is stale or
+lower than the Queue's actual setting.
+
+Each default Queue sync drains at most 10 batches of 100 messages: **1,000
+messages per tick**. Doctor reports a residual of 1–1,000 messages as within
+that budget. If no new messages arrive, the next scheduled sync can clear it.
+Doctor warns when more than 1,000 messages remain because one default tick
+cannot drain the residual. Run a manual sync to accelerate the drain. If the
+backlog remains above 1,000, shorten the `traffic-sync` schedule interval.
 
 ## Syncing data
 
@@ -628,6 +775,12 @@ cnry traffic sync <project> --source <id>
 cnry traffic sync <project> --source <id> --since-minutes 4320  # 3 days
 ```
 
+Cloudflare Queue pull is cursorless and ignores `--since-minutes`; each call
+drains a bounded set of leased Queue messages. Repeat the command when you need
+to accelerate a backlog, or let the auto-created 30-minute schedule continue
+draining. Direct push still rejects `traffic sync` because it has no pull
+transport.
+
 ### Unsticking a stuck source
 
 If a Vercel (or Cloud Run) source has been failing for so long that
@@ -654,9 +807,9 @@ above; clearing `lastError` for a transient WordPress failure also
 works. Archived sources are rejected — re-connect them with
 `cnry traffic connect ...` instead.
 
-Cross-sync dedupe via the `last_event_ids` ring buffer means re-running a
-sync over an overlapping window cannot double-count rolled-up hourly
-hits. Safe to schedule (see "Scheduling" below) or trigger from CI.
+Time-window and cursor adapters use the `last_event_ids` overlap ring. Queue
+pull uses durable event receipts sized to Queue retention. Both paths make a
+repeated pull safe to schedule or trigger from CI.
 
 ## Inspecting source state
 
@@ -706,7 +859,7 @@ schema change, the stored rollups are untouched.
 | Project dashboard `/projects/:name/activity` | Live source table + 24h totals + GA4 referrals (combined view) |
 | Top-level `/traffic` route | Cross-project source admin (connect, sync, archive) |
 | `cnry report <project>` (HTML + SPA) | "AI Visibility — Server-Side" section, ranked above Indexing Health |
-| `cnry doctor --project <name>` | Source health checks, including Cloudflare `traffic.source.worker-version` deployment drift |
+| `cnry doctor --project <name>` | Source health checks, including direct-push Worker drift and Queue-pull local credential/sync state |
 | MCP toolkit `traffic` | Read/status tools plus pull-source setup/sync tools. Cloudflare connect is local-CLI-only so Worker secrets cannot enter an MCP transcript. |
 
 ## Doctor signals
@@ -719,7 +872,9 @@ The doctor checks are adapter-agnostic. When they fail or warn:
 | `traffic.source.connected` | `traffic.source.all-errored` | Re-connect the source. The check's `details.lastError` shows the underlying reason. |
 | `traffic.source.recent-data` | `traffic.recent-data.stale` | For pull sources, run `cnry traffic sync …`. For Cloudflare direct push, inspect the route and receiver. |
 | `traffic.source.recent-data` | `traffic.recent-data.empty` | Inspect source configuration. For Cloudflare direct push, send the UTM smoke request and inspect Worker logs. |
-| `traffic.source.credentials` | `traffic.credentials.resolve-failed` | Reconnect from the host that owns the source credentials. |
+| `traffic.source.queue-backlog` | `traffic.queue-backlog.within-drain-budget` | 1–1,000 Queue messages remain. If no new messages arrive, the next scheduled sync can drain them. Run a manual sync to accelerate. |
+| `traffic.source.queue-backlog` | `traffic.queue-backlog.remaining` | More than 1,000 Queue messages remain. Run a manual sync. If the backlog persists, shorten the traffic-sync schedule. |
+| `traffic.source.credentials` | `traffic.credentials.resolve-failed` | Reconnect from the host that owns the source credentials. Queue pull requires a non-empty Account Queues Edit token paired by source ID. |
 | `traffic.source.cache-blindspot` | `traffic.cache-blindspot.wordpress-plugin` | A WordPress source is connected, so the plugin cannot see cache-served page views. Exclude AI user-agents from the page cache and any CDN, or switch to a log/edge source. Warns only, not a failure. |
 | `traffic.source.worker-version` | `traffic.worker-version.waiting-for-first-event` | Send a smoke-test request through the Worker. Then run the doctor again. |
 | `traffic.source.worker-version` | `traffic.worker-version.stale` | Redeploy the generated Worker from the credential-owning host. Use `--deploy --confirm-route --confirm-fail-open`. Attach the route manually. |
@@ -728,14 +883,28 @@ Cloudflare doctor behavior is capability-driven: only
 `deliveryMode=direct-push` (and legacy Cloudflare rows with no mode) skips
 pull-watermark lag. The same mode enables `traffic.source.worker-version`.
 That check compares `configJson.workerVersion` with `lastWorkerVersion`.
-The reserved Queue pull mode uses pull checks and skips the version check.
+Queue pull uses pull lag checks and skips the direct-push Worker-version check.
 
 ## Scheduling
 
-`cnry schedule` supports `--kind traffic-sync` for pull sources. Cloudflare
-direct push is event-driven and must not receive a traffic-sync schedule. Recurring syncs are
-safe because of the `last_event_ids` cross-sync dedupe ring buffer
-described above. Recommended cadence:
+`cnry schedule` supports `--kind traffic-sync` for pull sources. Activation of
+Queue, Cloud Run, WordPress, or Vercel creates or repoints this schedule at a
+30-minute cadence.
+Cloudflare direct push is event-driven and must not receive a traffic-sync
+schedule. Recurring syncs are safe because of the adapter's overlap ring or
+durable Queue receipts.
+
+Keep the auto-created 30-minute schedule for Queue pull. The Worker sends one
+selected event in each Queue message. At its 1,000-message limit, this cadence
+drains about 0.56 selected events per second. If the Queue backlog remains
+above 1,000, run a manual sync. Then shorten the interval:
+
+```bash
+cnry schedule set <project> --kind traffic-sync \
+  --source <source-id> --cron "*/10 * * * *"
+```
+
+Use these cadences only for Cloud Run, WordPress, and Vercel:
 
 | Cadence | Use case |
 |---|---|
@@ -798,8 +967,8 @@ domains, or PII are surfaced.
   no client IP, so every Vercel crawler hit is unverified by
   construction (UA-only). A Vercel source reading 100% unverified is
   expected, not a misconfiguration.
-- **Four adapters ship: Cloud Run, WordPress, Vercel, and Cloudflare
-  direct push. More adapters are planned.** The doctor checks and report renderer are
+- **Four adapters ship: Cloud Run, WordPress, Vercel, and Cloudflare with
+  direct-push and queue-pull delivery. More adapters are planned.** The doctor checks and report renderer are
   adapter-agnostic — adding a new adapter is just a new entry in
   `traffic_sources.source_type` and a `TrafficSourceValidator`
   registration.

package/assets/assets/{AuditHistoryPanel-BiloGcQA.js → AuditHistoryPanel-C_1twF00.js}

@@ -1 +1 @@
-import{r as a,u as h,j as e}from"./vendor-tanstack-Dock0eH1.js";import{cc as L,cd as P,bx as E,k as u,B as x,d as v,T as k}from"./index-DmsIZQAm.js";const o=100;function M(s){if(s==="all")return;const n=Number.parseInt(s,10);return new Date(Date.now()-n*24*60*60*1e3).toISOString()}function O(s){const n=s.userAgent?.toLowerCase()??"";return n.includes("canonry-mcp")?"MCP":n.includes("canonry-cli")?"CLI":n.includes("mozilla/")?"Dashboard":s.actor==="scheduler"?"Scheduler":s.actor==="agent"?"Agent":s.actor==="mcp"?"MCP":s.actor==="cli"?"CLI":s.actor}function B(s){return/delete|remove|revoke|disconnect|failed/.test(s)?"negative":/create|add|connect|completed/.test(s)?"positive":/update|replace|sync|apply/.test(s)?"caution":"neutral"}function D(s){return[s.action,s.actor,s.entityType,s.entityId,s.actorSession,s.userAgent,s.diff==null?"":JSON.stringify(s.diff)].filter(Boolean).join(" ").toLowerCase()}function H({projectName:s}){const[n,l]=a.useState(0),[c,y]=a.useState("90d"),[m,N]=a.useState(""),[p,w]=a.useState(""),S=a.useMemo(()=>M(c),[c]),g={limit:o,offset:n*o,since:S,actor:m||void 0},C=h({...L({client:u,path:{name:s??""},query:g}),enabled:!!s}),A=h({...P({client:u,query:g}),enabled:!s}),f=h({...E({client:u}),enabled:!s}),i=s?C:A,r=i.data??[],I=a.useMemo(()=>new Map((f.data??[]).map(t=>[t.id,t.displayName||t.name])),[f.data]),d=p.trim().toLowerCase(),j=a.useMemo(()=>d?r.filter(t=>D(t).includes(d)):r,[r,d]),b=t=>{l(0),t()};return i.isLoading?e.jsx("p",{className:"supporting-copy mt-6",role:"status",children:"Loading change history…"}):e.jsxs("section",{className:"mt-6","aria-labelledby":"change-history-heading",children:[e.jsxs("div",{className:"section-head section-head-inline",children:[e.jsxs("div",{children:[e.jsx("p",{className:"eyebrow eyebrow-soft",children:"Audit trail"}),e.jsx("h2",{id:"change-history-heading",children:"Change history"}),e.jsx("p",{className:"supporting-copy mt-1 max-w-2xl",children:"Configuration and operator actions. Execution outcomes remain in Runs."})]}),e.jsx(x,{type:"button",variant:"outline",size:"sm",onClick:()=>{i.refetch()},disabled:i.isFetching,children:i.isFetching?"Refreshing…":"Refresh"})]}),e.jsxs("div",{className:"mt-4 grid gap-2 sm:grid-cols-3",children:[e.jsx("input",{type:"search","aria-label":"Search change history",value:p,onChange:t=>w(t.target.value),placeholder:"Search actions, entities, or details",className:"min-h-11 rounded-md border border-base bg-bg px-3 text-sm text-strong placeholder-mono-600 focus:outline-none focus-visible:ring-1 focus-visible:ring-mono-600"}),e.jsxs("select",{"aria-label":"Filter change history by actor",value:m,onChange:t=>b(()=>N(t.target.value)),className:"min-h-11 rounded-md border border-base bg-bg px-3 text-sm text-strong focus:outline-none focus-visible:ring-1 focus-visible:ring-mono-600",children:[e.jsx("option",{value:"",children:"All actors"}),e.jsx("option",{value:"api",children:"API and dashboard"}),e.jsx("option",{value:"cli",children:"CLI"}),e.jsx("option",{value:"scheduler",children:"Scheduler"}),e.jsx("option",{value:"agent",children:"Agent"}),e.jsx("option",{value:"mcp",children:"MCP"})]}),e.jsxs("select",{"aria-label":"Filter change history by date range",value:c,onChange:t=>b(()=>y(t.target.value)),className:"min-h-11 rounded-md border border-base bg-bg px-3 text-sm text-strong focus:outline-none focus-visible:ring-1 focus-visible:ring-mono-600",children:[e.jsx("option",{value:"30d",children:"Last 30 days"}),e.jsx("option",{value:"90d",children:"Last 90 days"}),e.jsx("option",{value:"365d",children:"Last year"}),e.jsx("option",{value:"all",children:"All retained history"})]})]}),i.isError?e.jsxs(v,{className:"surface-card empty-card mt-4",children:[e.jsx("h3",{children:"Change history unavailable"}),e.jsx("p",{children:i.error instanceof Error?i.error.message:"Could not load the audit trail."})]}):j.length===0?e.jsxs(v,{className:"surface-card empty-card mt-4",children:[e.jsx("h3",{children:"No changes match these filters"}),e.jsx("p",{children:"Widen the date range or clear the actor and search filters."})]}):e.jsx("div",{className:"evidence-table-wrap mt-4",children:e.jsxs("table",{className:"evidence-table",children:[e.jsx("thead",{children:e.jsxs("tr",{children:[e.jsx("th",{children:"When"}),s?null:e.jsx("th",{children:"Scope"}),e.jsx("th",{children:"Action"}),e.jsx("th",{children:"Entity"}),e.jsx("th",{children:"Origin"}),e.jsx("th",{children:"Details"})]})}),e.jsx("tbody",{children:j.map(t=>e.jsxs("tr",{children:[e.jsx("td",{className:"whitespace-nowrap tabular-nums text-muted",children:new Date(t.createdAt).toLocaleString()}),s?null:e.jsx("td",{className:"text-secondary",children:t.projectId?I.get(t.projectId)??`Deleted project · ${t.projectId}`:"Instance settings"}),e.jsx("td",{children:e.jsx(k,{tone:B(t.action),children:t.action})}),e.jsxs("td",{children:[e.jsx("span",{className:"text-strong",children:t.entityType}),t.entityId?e.jsx("span",{className:"mt-0.5 block max-w-48 truncate font-mono text-[11px] text-faint",title:t.entityId,children:t.entityId}):null]}),e.jsxs("td",{children:[e.jsx("span",{className:"text-secondary",children:O(t)}),t.actorSession?e.jsxs("span",{className:"mt-0.5 block max-w-40 truncate font-mono text-[11px] text-faint",title:t.actorSession,children:["Session ",t.actorSession]}):null]}),e.jsx("td",{children:t.diff==null?e.jsx("span",{className:"text-faint",children:"No field diff"}):e.jsxs("details",{children:[e.jsx("summary",{className:"min-h-11 cursor-pointer py-3 text-sm text-secondary hover:text-strong",children:"View diff"}),e.jsx("pre",{className:"max-h-72 max-w-xl overflow-auto whitespace-pre-wrap break-words rounded-md bg-bg-elevated p-3 text-xs text-secondary",children:JSON.stringify(t.diff,null,2)})]})})]},t.id))})]})}),!i.isError&&(n>0||r.length===o)?e.jsxs("div",{className:"mt-4 flex items-center justify-between gap-3",children:[e.jsx(x,{type:"button",variant:"outline",size:"sm",disabled:n===0,onClick:()=>l(t=>Math.max(0,t-1)),children:"Previous"}),e.jsxs("span",{className:"text-xs tabular-nums text-muted",children:["Page ",n+1]}),e.jsx(x,{type:"button",variant:"outline",size:"sm",disabled:r.length<o,onClick:()=>l(t=>t+1),children:"Next"})]}):null]})}export{H as A};
+import{r as a,u as h,j as e}from"./vendor-tanstack-Dock0eH1.js";import{cc as L,cd as P,bx as E,k as u,B as x,d as v,T as k}from"./index-CQGAqmDx.js";const o=100;function M(s){if(s==="all")return;const n=Number.parseInt(s,10);return new Date(Date.now()-n*24*60*60*1e3).toISOString()}function O(s){const n=s.userAgent?.toLowerCase()??"";return n.includes("canonry-mcp")?"MCP":n.includes("canonry-cli")?"CLI":n.includes("mozilla/")?"Dashboard":s.actor==="scheduler"?"Scheduler":s.actor==="agent"?"Agent":s.actor==="mcp"?"MCP":s.actor==="cli"?"CLI":s.actor}function B(s){return/delete|remove|revoke|disconnect|failed/.test(s)?"negative":/create|add|connect|completed/.test(s)?"positive":/update|replace|sync|apply/.test(s)?"caution":"neutral"}function D(s){return[s.action,s.actor,s.entityType,s.entityId,s.actorSession,s.userAgent,s.diff==null?"":JSON.stringify(s.diff)].filter(Boolean).join(" ").toLowerCase()}function H({projectName:s}){const[n,l]=a.useState(0),[c,y]=a.useState("90d"),[m,N]=a.useState(""),[p,w]=a.useState(""),S=a.useMemo(()=>M(c),[c]),g={limit:o,offset:n*o,since:S,actor:m||void 0},C=h({...L({client:u,path:{name:s??""},query:g}),enabled:!!s}),A=h({...P({client:u,query:g}),enabled:!s}),f=h({...E({client:u}),enabled:!s}),i=s?C:A,r=i.data??[],I=a.useMemo(()=>new Map((f.data??[]).map(t=>[t.id,t.displayName||t.name])),[f.data]),d=p.trim().toLowerCase(),j=a.useMemo(()=>d?r.filter(t=>D(t).includes(d)):r,[r,d]),b=t=>{l(0),t()};return i.isLoading?e.jsx("p",{className:"supporting-copy mt-6",role:"status",children:"Loading change history…"}):e.jsxs("section",{className:"mt-6","aria-labelledby":"change-history-heading",children:[e.jsxs("div",{className:"section-head section-head-inline",children:[e.jsxs("div",{children:[e.jsx("p",{className:"eyebrow eyebrow-soft",children:"Audit trail"}),e.jsx("h2",{id:"change-history-heading",children:"Change history"}),e.jsx("p",{className:"supporting-copy mt-1 max-w-2xl",children:"Configuration and operator actions. Execution outcomes remain in Runs."})]}),e.jsx(x,{type:"button",variant:"outline",size:"sm",onClick:()=>{i.refetch()},disabled:i.isFetching,children:i.isFetching?"Refreshing…":"Refresh"})]}),e.jsxs("div",{className:"mt-4 grid gap-2 sm:grid-cols-3",children:[e.jsx("input",{type:"search","aria-label":"Search change history",value:p,onChange:t=>w(t.target.value),placeholder:"Search actions, entities, or details",className:"min-h-11 rounded-md border border-base bg-bg px-3 text-sm text-strong placeholder-mono-600 focus:outline-none focus-visible:ring-1 focus-visible:ring-mono-600"}),e.jsxs("select",{"aria-label":"Filter change history by actor",value:m,onChange:t=>b(()=>N(t.target.value)),className:"min-h-11 rounded-md border border-base bg-bg px-3 text-sm text-strong focus:outline-none focus-visible:ring-1 focus-visible:ring-mono-600",children:[e.jsx("option",{value:"",children:"All actors"}),e.jsx("option",{value:"api",children:"API and dashboard"}),e.jsx("option",{value:"cli",children:"CLI"}),e.jsx("option",{value:"scheduler",children:"Scheduler"}),e.jsx("option",{value:"agent",children:"Agent"}),e.jsx("option",{value:"mcp",children:"MCP"})]}),e.jsxs("select",{"aria-label":"Filter change history by date range",value:c,onChange:t=>b(()=>y(t.target.value)),className:"min-h-11 rounded-md border border-base bg-bg px-3 text-sm text-strong focus:outline-none focus-visible:ring-1 focus-visible:ring-mono-600",children:[e.jsx("option",{value:"30d",children:"Last 30 days"}),e.jsx("option",{value:"90d",children:"Last 90 days"}),e.jsx("option",{value:"365d",children:"Last year"}),e.jsx("option",{value:"all",children:"All retained history"})]})]}),i.isError?e.jsxs(v,{className:"surface-card empty-card mt-4",children:[e.jsx("h3",{children:"Change history unavailable"}),e.jsx("p",{children:i.error instanceof Error?i.error.message:"Could not load the audit trail."})]}):j.length===0?e.jsxs(v,{className:"surface-card empty-card mt-4",children:[e.jsx("h3",{children:"No changes match these filters"}),e.jsx("p",{children:"Widen the date range or clear the actor and search filters."})]}):e.jsx("div",{className:"evidence-table-wrap mt-4",children:e.jsxs("table",{className:"evidence-table",children:[e.jsx("thead",{children:e.jsxs("tr",{children:[e.jsx("th",{children:"When"}),s?null:e.jsx("th",{children:"Scope"}),e.jsx("th",{children:"Action"}),e.jsx("th",{children:"Entity"}),e.jsx("th",{children:"Origin"}),e.jsx("th",{children:"Details"})]})}),e.jsx("tbody",{children:j.map(t=>e.jsxs("tr",{children:[e.jsx("td",{className:"whitespace-nowrap tabular-nums text-muted",children:new Date(t.createdAt).toLocaleString()}),s?null:e.jsx("td",{className:"text-secondary",children:t.projectId?I.get(t.projectId)??`Deleted project · ${t.projectId}`:"Instance settings"}),e.jsx("td",{children:e.jsx(k,{tone:B(t.action),children:t.action})}),e.jsxs("td",{children:[e.jsx("span",{className:"text-strong",children:t.entityType}),t.entityId?e.jsx("span",{className:"mt-0.5 block max-w-48 truncate font-mono text-[11px] text-faint",title:t.entityId,children:t.entityId}):null]}),e.jsxs("td",{children:[e.jsx("span",{className:"text-secondary",children:O(t)}),t.actorSession?e.jsxs("span",{className:"mt-0.5 block max-w-40 truncate font-mono text-[11px] text-faint",title:t.actorSession,children:["Session ",t.actorSession]}):null]}),e.jsx("td",{children:t.diff==null?e.jsx("span",{className:"text-faint",children:"No field diff"}):e.jsxs("details",{children:[e.jsx("summary",{className:"min-h-11 cursor-pointer py-3 text-sm text-secondary hover:text-strong",children:"View diff"}),e.jsx("pre",{className:"max-h-72 max-w-xl overflow-auto whitespace-pre-wrap break-words rounded-md bg-bg-elevated p-3 text-xs text-secondary",children:JSON.stringify(t.diff,null,2)})]})})]},t.id))})]})}),!i.isError&&(n>0||r.length===o)?e.jsxs("div",{className:"mt-4 flex items-center justify-between gap-3",children:[e.jsx(x,{type:"button",variant:"outline",size:"sm",disabled:n===0,onClick:()=>l(t=>Math.max(0,t-1)),children:"Previous"}),e.jsxs("span",{className:"text-xs tabular-nums text-muted",children:["Page ",n+1]}),e.jsx(x,{type:"button",variant:"outline",size:"sm",disabled:r.length<o,onClick:()=>l(t=>t+1),children:"Next"})]}):null]})}export{H as A};