chore(format): apply prettier across the workspace to clear CI drift

`pnpm format:check` in CI was failing on ~137 files that had accumulated
prettier drift over many commits. The pre-commit hook (lint-staged + prettier)
only formats *staged* files, so any commit that touched unrelated parts of a
file left the rest unformatted. Over time this produced enough drift that the
format-check job started red-flagging the build, but it was masked because
the upstream Build step was dying first on the rollup duplicate (now fixed
in ec278b3).

This is a pure mechanical reformat — line wrapping at the configured
printWidth, trailing-comma normalisation, no logic changes. ~137 files,
all matching what `pnpm format` would produce on a clean clone.

Drive-by: remove an unused `itemsTab` locator in customize.spec.ts that the
reformat surfaced via eslint --max-warnings=0 in the pre-commit hook.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Author: ersinkoc

AGENTS.md

@@ -61,6 +61,7 @@ PostgreSQL via pg adapter. Repositories in `packages/gateway/src/db/repositories
 - Unused variables prefixed with `_` (ESLint convention)
 
 <!-- dfmt:v1 begin -->
+
 # Context Discipline — REQUIRED
 
 This project uses DFMT to keep large tool outputs from exhausting the
@@ -72,7 +73,7 @@ in this project.**
 Always use DFMT's MCP tools when an output might exceed 2 KB:
 
 | Native     | DFMT replacement |
-|------------|------------------|
+| ---------- | ---------------- |
 | `Bash`     | `dfmt_exec`      |
 | `Read`     | `dfmt_read`      |
 | `WebFetch` | `dfmt_fetch`     |
@@ -90,7 +91,7 @@ a large output without flooding the context.
 DFMT is a strong preference, not a hard dependency. If a `dfmt_*` tool
 errors, times out, or is unavailable, report the failure to the user
 (one short line — which call, what error) and continue with the native
-equivalent so the session is not blocked. The ban is on *silent*
+equivalent so the session is not blocked. The ban is on _silent_
 fallback — every switch must be announced. After a fallback, drop a
 brief `dfmt_remember` note tagged `gap` when practical. If the native
 tool is also denied (permission rule, sandbox refusal), stop and ask
@@ -108,4 +109,5 @@ Some agents do not provide hooks to enforce these rules automatically.
 **Compliance is your responsibility as the agent.** A single raw shell
 output above 8 KB can push earlier context out of the window, erasing
 the conversation's history. Following the rules above preserves it.
+
 <!-- dfmt:v1 end -->

architecture.md

@@ -101,23 +101,27 @@ CREATE TABLE job_history (
 ## Integration Plan
 
 ### Phase 1: Infrastructure (gateway)
+
 1. ✅ Add `jobs` + `job_history` tables to `schema/core.ts` + migration 031_job_queue.sql
 2. ✅ Add `JobQueueService` to `services/`
 3. ✅ Add `enqueueJob(name, payload, options)` function
 4. ✅ Add `enqueueJobAtPriority(queue, priority)` for system jobs
 
 ### Phase 2: Workflow System (gateway)
+
 1. Refactor `WorkflowService.dispatchNode()` to enqueue each node as a job instead of executing synchronously
 2. Worker pool (configurable size, default 4) claims available jobs, executes, writes results, triggers dependents via gating
 3. Node outputs stored in DB — crash recovery reads last successful node output + resumes from next pending node
 4. Workflow-level job groups: all nodes in a workflow share a `workflow_run_id`; orphan cleanup marks incomplete runs on restart
 
 ### Phase 3: Trigger + Plan Systems (gateway)
+
 1. `TriggerService.scheduleJob()` → enqueue for cron jobs
 2. `PlanExecutor` → each step becomes a job; step N+1 enqueued after step N succeeds
 3. Subagent sessions → wake up, re-claim in-progress job on reconnect
 
 ### Phase 4: Fleet + Subagent (gateway)
+
 1. Fleet worker pool claims jobs from `fleet_tasks` queue
 2. Subagent worker pool claims from `subagent_jobs` queue
 3. `requeueOrphanedTasks()` replaced by jobs that self-recover on worker restart
@@ -127,30 +131,33 @@ CREATE TABLE job_history (
 ## Consequences
 
 ### Positive
+
 - **Crash recovery**: workers restart, see `active`/`available` jobs, continue
 - **Horizontal scaling**: multiple gateway instances share the same queue via `FOR UPDATE SKIP LOCKED`
 - **Retry with backoff**: no thundering herd on transient failures
 - **No extra infra**: uses existing Postgres, deployed via migration
 
 ### Negative
+
 - **Added latency**: jobs are queued, not synchronous; UI feedback must reflect queued state
 - **Complexity**: requires managing job state machine + worker pool lifecycle
 - **Transaction boundaries**: job claim + result write must be atomic; careful use of `FOR UPDATE SKIP LOCKED`
 
 ### Risks
+
 - **Queue depth explosion**: if workers are slower than enqueuers, queue grows unbounded. Mitigate: monitor queue depth in metrics, alert at threshold, circuit-breaker on enqueue
 - **Job lock contention**: many workers competing for same priority tier. Mitigate: partition by queue name + priority
 
 ---
 
 ## Alternatives Considered
 
-| Option | Why Not |
-|--------|---------|
-| **Redis** (Bull/BullMQ) | Extra infrastructure to deploy/monitor; Redis failure = queue unavailable |
-| **Graphile Worker** | More opinionated (synchronous, migration-first); pg-boss async API fits our enqueue-anywhere pattern better |
-| **In-memory only** | Already the problem we are solving |
-| **SQS/IronMQ** | Cloud-only, not self-hosted; adds vendor lock-in |
+| Option                  | Why Not                                                                                                     |
+| ----------------------- | ----------------------------------------------------------------------------------------------------------- |
+| **Redis** (Bull/BullMQ) | Extra infrastructure to deploy/monitor; Redis failure = queue unavailable                                   |
+| **Graphile Worker**     | More opinionated (synchronous, migration-first); pg-boss async API fits our enqueue-anywhere pattern better |
+| **In-memory only**      | Already the problem we are solving                                                                          |
+| **SQS/IronMQ**          | Cloud-only, not self-hosted; adds vendor lock-in                                                            |
 
 ---
 

docs/ADR/ADR-001-persistent-job-queue.md

@@ -21,21 +21,21 @@ Centralize retention enforcement at the database level using a single nightly cl
 
 ### Retention Intervals
 
-| Table | Retention | Rationale |
-|-------|-----------|-----------|
-| `request_logs` | 30 days | API debugging, auditability |
-| `audit_log` | 90 days | Compliance requirement |
-| `claw_history` | 90 days | Audit trail |
-| `claw_audit_log` | 30 days | High-volume audit detail |
-| `workflow_logs` | 90 days | Workflow execution history |
-| `plan_history` | 90 days | Plan execution history |
-| `trigger_history` | 30 days | Trigger event log |
-| `heartbeat_log` | 30 days | High-frequency heartbeat events |
-| `subagent_history` | 90 days | Agent execution history |
-| `embedding_cache` | 7 days | LRU cache, auto-evicts |
-| `jobs` | 30 days | Completed/failed jobs |
-| `job_history` | 90 days | Dead-letter entries |
-| `provider_metrics` | 30 days | High-frequency telemetry |
+| Table              | Retention | Rationale                       |
+| ------------------ | --------- | ------------------------------- |
+| `request_logs`     | 30 days   | API debugging, auditability     |
+| `audit_log`        | 90 days   | Compliance requirement          |
+| `claw_history`     | 90 days   | Audit trail                     |
+| `claw_audit_log`   | 30 days   | High-volume audit detail        |
+| `workflow_logs`    | 90 days   | Workflow execution history      |
+| `plan_history`     | 90 days   | Plan execution history          |
+| `trigger_history`  | 30 days   | Trigger event log               |
+| `heartbeat_log`    | 30 days   | High-frequency heartbeat events |
+| `subagent_history` | 90 days   | Agent execution history         |
+| `embedding_cache`  | 7 days    | LRU cache, auto-evicts          |
+| `jobs`             | 30 days   | Completed/failed jobs           |
+| `job_history`      | 90 days   | Dead-letter entries             |
+| `provider_metrics` | 30 days   | High-frequency telemetry        |
 
 ---
 
@@ -71,6 +71,7 @@ ON CONFLICT (table_name) DO NOTHING;
 ## Cleanup Job
 
 A single `nightly_retention_cleanup` job runs daily at 02:00 UTC (configurable). For each enabled policy:
+
 1. Call the table's existing `cleanup{N}(retention_days)` method
 2. Update `retention_policies.last_cleanup = NOW()`
 3. Log count of deleted records
@@ -93,32 +94,40 @@ export class RetentionService {
 
   private async cleanupTable(table: string, days: number): Promise<number> {
     const methods: Record<string, () => Promise<number>> = {
-      request_logs:      () => getRequestLogsRepository().cleanupOld(days),
-      audit_log:        () => getAuditRepository().cleanupOld(days),
-      claw_history:     () => getClawsRepository().cleanupOldHistory(days),
-      claw_audit_log:   () => getClawsRepository().cleanupOldAuditLog(days),
-      workflow_logs:    () => getWorkflowsRepository().cleanupOld(days),
-      plan_history:     () => getPlansRepository().cleanupOld(days),
-      trigger_history:  () => getTriggersRepository().cleanupHistory(days),
-      heartbeat_log:    () => getHeartbeatRepository().cleanupOld(days),
+      request_logs: () => getRequestLogsRepository().cleanupOld(days),
+      audit_log: () => getAuditRepository().cleanupOld(days),
+      claw_history: () => getClawsRepository().cleanupOldHistory(days),
+      claw_audit_log: () => getClawsRepository().cleanupOldAuditLog(days),
+      workflow_logs: () => getWorkflowsRepository().cleanupOld(days),
+      plan_history: () => getPlansRepository().cleanupOld(days),
+      trigger_history: () => getTriggersRepository().cleanupHistory(days),
+      heartbeat_log: () => getHeartbeatRepository().cleanupOld(days),
       subagent_history: () => getSubagentsRepository().cleanupOld(days),
-      embedding_cache:  () => getEmbeddingCacheRepository().cleanupOld(days),
-      jobs:             () => getJobsRepository().cleanupOld(days),
-      job_history:      () => getJobsRepository().cleanupHistory(days),
+      embedding_cache: () => getEmbeddingCacheRepository().cleanupOld(days),
+      jobs: () => getJobsRepository().cleanupOld(days),
+      job_history: () => getJobsRepository().cleanupHistory(days),
       provider_metrics: () => getProviderMetricsRepository().cleanupOld(days),
     };
     const fn = methods[table];
-    if (!fn) { log.warn('No cleanup method for table', { table }); return 0; }
+    if (!fn) {
+      log.warn('No cleanup method for table', { table });
+      return 0;
+    }
     return fn();
   }
 }
 ```
 
 Nightly job registration in `server.ts`:
+
 ```typescript
 const { getJobQueueService } = await import('./services/job-queue-service.js');
 const queue = getJobQueueService();
-await queue.enqueue('nightly_retention_cleanup', {}, { queue: 'system', priority: 100, runAfter: nextUTCMidnight() });
+await queue.enqueue(
+  'nightly_retention_cleanup',
+  {},
+  { queue: 'system', priority: 100, runAfter: nextUTCMidnight() }
+);
 ```
 
 ---

docs/ADR/ADR-002-database-retention-policy.md

@@ -20,13 +20,13 @@ OwnPilot's API is at `/api/v1/`. As the platform matures, breaking changes will
 
 ## Why Side-by-Side
 
-| Factor | Side-by-Side | Header-based |
-|--------|-------------|--------------|
-| Complexity | Low — same handlers registered twice | High — version detection logic in every handler |
-| Backward compat | Full — callers migrate on their timeline | Partial — header must be present |
-| Testability | Easy — same tests for both versions | Hard — version branching in tests |
-| Extension impact | Extensions using v1 keep working | Extensions break if they don't send header |
-| Observability | Version visible in URL | Requires header log extraction |
+| Factor           | Side-by-Side                             | Header-based                                    |
+| ---------------- | ---------------------------------------- | ----------------------------------------------- |
+| Complexity       | Low — same handlers registered twice     | High — version detection logic in every handler |
+| Backward compat  | Full — callers migrate on their timeline | Partial — header must be present                |
+| Testability      | Easy — same tests for both versions      | Hard — version branching in tests               |
+| Extension impact | Extensions using v1 keep working         | Extensions break if they don't send header      |
+| Observability    | Version visible in URL                   | Requires header log extraction                  |
 
 ## Implementation
 
@@ -51,6 +51,7 @@ packages/gateway/src/app.ts
 ### Version Detection
 
 No version detection middleware. The URL path determines the version:
+
 - `/api/v1/chat` → v1 handlers
 - `/api/v2/chat` → v2 handlers (same implementation initially)
 
@@ -94,11 +95,13 @@ When v1 is deprecated:
 ## Consequences
 
 **Positive:**
+
 - Extensions and channel adapters continue working without changes
 - v2 can evolve independently
 - No complex version-detection logic in handlers
 
 **Negative:**
+
 - Route registration is duplicated (but consolidated in one file per domain)
 - Some code duplication if v2-specific handlers are needed