@aitne/daemon 0.1.8 → 0.1.9

package/dist/db/schema.js

@@ -123,7 +123,17 @@ CREATE TABLE IF NOT EXISTS agent_actions (
     -- detail remains the daemon-write telemetry channel; metadata is
     -- the chokepointed agent-write side-channel so the two
     -- responsibilities do not collide.
-    metadata JSON DEFAULT '{}'
+    metadata JSON DEFAULT '{}',
+    -- AGENT_DEFINITIONS_DESIGN.md §5.3 — nullable Agent-identity stamp.
+    -- The dispatcher populates it when the executing context resolves to a
+    -- known Agent (§8.1); historical rows and any unresolved context stay
+    -- NULL. Intentionally carries NO foreign key: an FK would complicate the
+    -- agents-row cascade and would break the legacy NULL rows on a strict
+    -- enforcement pass (design drift note 2026-05-30). Declared LAST in the
+    -- CREATE body so fresh installs match the column order that migration
+    -- 0007-agent-identity's ALTER TABLE ... ADD COLUMN produces on
+    -- upgrading DBs.
+    agent_id TEXT
 );
 CREATE INDEX IF NOT EXISTS idx_actions_date ON agent_actions(date(started_at));
 CREATE INDEX IF NOT EXISTS idx_agent_actions_backend_time
@@ -131,6 +141,17 @@ CREATE INDEX IF NOT EXISTS idx_agent_actions_backend_time
 CREATE INDEX IF NOT EXISTS idx_agent_actions_source
     ON agent_actions(source_kind, source_ref, started_at DESC)
     WHERE source_kind IS NOT NULL;
+-- NB: idx_agent_actions_agent (on the agent_id column) is intentionally NOT
+-- created here. agent_actions is a PRE-EXISTING table, so on an upgrader its
+-- CREATE TABLE IF NOT EXISTS above is a no-op and the agent_id column is absent
+-- until migration 0007-agent-identity runs. applySchema runs BEFORE
+-- runMigrations (bootstrap/db.ts), so a CREATE INDEX ... ON
+-- agent_actions(agent_id) here would throw "no such column: agent_id" at boot
+-- on every pre-0007 install. Per CLAUDE.md upgrade-safety checklist #2, an
+-- index referencing a migration-added column is created ONLY by the migration
+-- (gated behind indexExists), which runs after the ALTER. The migration also
+-- creates it on fresh installs (where the column ships in the CREATE body
+-- above), so the index always exists post-boot on both paths.
 
 -- recurring_schedules is created before agent_schedule so the FK reference
 -- in agent_schedule is syntactically valid. SQLite doesn't validate FK
@@ -230,6 +251,89 @@ CREATE TABLE IF NOT EXISTS agent_schedule (
 CREATE INDEX IF NOT EXISTS idx_schedule_pending
     ON agent_schedule(scheduled_for) WHERE status = 'pending';
 
+-- ── Agent Definitions (AGENT_DEFINITIONS_DESIGN.md §5.1 / §5.2) ──────────────
+--
+-- The Agent-as-identity layer. "agents" is the durable identity row for every
+-- built-in routine and user-authored recurring task; "agent_executions" is the
+-- per-firing rollup the dashboard renders. Both are purely additive (CREATE IF
+-- NOT EXISTS), so a fresh install lands on the target state directly. The
+-- paired migration 0007-agent-identity carries ONLY the agent_actions ALTER
+-- (§5.3) — these two tables need no migration body.
+--
+-- Timestamp columns (created_at / updated_at / enabled_overridden_at /
+-- started_at / ended_at) are epoch-millisecond INTEGERs, matching the
+-- repositories.* convention rather than the legacy CURRENT_TIMESTAMP ISO
+-- string. The loader / recorder / stores are the sole writers and always
+-- supply an explicit value, so enabled_overridden_at compares directly against
+-- an fs.stat mtimeMs in the loader's override resolution (§6.4) with no
+-- string-vs-number coercion.
+--
+-- agents.last_execution_id <-> agent_executions.agent_id is a deliberate
+-- circular FK. SQLite validates FK targets only at row-DML time (never at
+-- CREATE), so the create order below is irrelevant; at runtime the loader
+-- upserts the agents row (last_execution_id NULL — no FK check on NULL) before
+-- any execution references it, and the recorder only ever points
+-- last_execution_id at an id that already exists. ON DELETE CASCADE on
+-- agent_executions.agent_id + ON DELETE SET NULL on the two agents FKs keep
+-- deletes clean: deleting an agent drops its executions and nulls any inbound
+-- recurring/last-execution pointer.
+CREATE TABLE IF NOT EXISTS agents (
+    id TEXT PRIMARY KEY,                  -- slug; matches the YAML \`slug\` field and the /agents/<slug> URL
+    name TEXT NOT NULL,
+    description TEXT,
+    source TEXT NOT NULL
+        CHECK (source IN ('builtin', 'user')),
+    definition_path TEXT NOT NULL,        -- absolute path to agent.md (or the synthesised registry-fallback path)
+    definition_hash TEXT NOT NULL,        -- sha256 of file bytes; cheap change detector on every boot
+    enabled INTEGER NOT NULL DEFAULT 1
+        CHECK (enabled IN (0, 1)),
+    enabled_overridden_at INTEGER,        -- epoch ms of the last dashboard toggle; NULL = YAML wins (§6.4)
+    process_key TEXT,                     -- NULL for the no-LLM in-process passes (roadmap-maintenance, context-index-reconcile); non-null is cross-checked vs PROCESS_KEYS by the loader. Intentionally nullable — NO NOT NULL.
+    schedule_kind TEXT NOT NULL
+        CHECK (schedule_kind IN ('cron', 'one_shot', 'event')),
+    schedule_expression TEXT,             -- cron expr ({dayBoundaryHour} placeholder allowed) OR one_shot ISO timestamp OR event ref
+    schedule_timezone TEXT NOT NULL,      -- loader resolves the concrete zone (YAML schedule.timezone ?? config.timezone ?? system tz). NO baked default — a hardcoded zone would misfire routines for non-JP operators; NOT NULL fails-fast on a loader bug instead of silently storing the wrong zone.
+    tags_json TEXT NOT NULL DEFAULT '[]',
+    stop_warning_json TEXT,               -- nullable for user Agents; mandatory for builtins (enforced upstream by the shared schema)
+    recurring_schedule_id INTEGER         -- FK to the backing recurring row for user Agents; NULL for builtins (cron lives in scheduler.ts)
+        REFERENCES recurring_schedules(id) ON DELETE SET NULL,
+    last_execution_id INTEGER             -- denormalised pointer kept in sync by the recorder; avoids a window-function scan on every dashboard render
+        REFERENCES agent_executions(id) ON DELETE SET NULL,
+    metadata_json TEXT NOT NULL DEFAULT '{}',  -- version_counter (§6.3), last_error (§6.6), override_snapshot (§6.4.1), reserved future fields
+    created_at INTEGER NOT NULL,          -- epoch ms; store is the sole writer
+    updated_at INTEGER NOT NULL           -- epoch ms
+);
+CREATE INDEX IF NOT EXISTS idx_agents_source_enabled
+    ON agents(source, enabled);
+CREATE INDEX IF NOT EXISTS idx_agents_process_key
+    ON agents(process_key);
+
+CREATE TABLE IF NOT EXISTS agent_executions (
+    id INTEGER PRIMARY KEY AUTOINCREMENT,
+    agent_id TEXT NOT NULL REFERENCES agents(id) ON DELETE CASCADE,
+    schedule_row_id INTEGER REFERENCES agent_schedule(id) ON DELETE SET NULL,
+    trigger TEXT NOT NULL
+        CHECK (trigger IN ('cron', 'manual', 'event', 'self')),
+    started_at INTEGER NOT NULL,          -- epoch ms (see the timestamp note above)
+    ended_at INTEGER,                     -- epoch ms; NULL while in-flight, set by completeExecution / sweepAbandoned
+    result TEXT
+        CHECK (result IS NULL OR result IN ('success', 'error', 'skipped', 'timeout')),
+    error_kind TEXT,                      -- 'quota' | 'tool' | 'criteria_fail' | 'timeout' | 'crash' | ...
+    error_message TEXT,
+    cost_usd REAL,
+    tokens_input INTEGER,
+    tokens_output INTEGER,
+    turns INTEGER,
+    success_criteria_json TEXT,           -- {"criterion_id": true|false, ...}; NULL until evaluated
+    output_summary TEXT,                  -- short human-readable line for the dashboard
+    metadata_json TEXT NOT NULL DEFAULT '{}'
+);
+CREATE INDEX IF NOT EXISTS idx_agent_executions_agent_time
+    ON agent_executions(agent_id, started_at DESC);
+CREATE INDEX IF NOT EXISTS idx_agent_executions_result
+    ON agent_executions(result, started_at DESC)
+    WHERE result IS NOT NULL;
+
 -- ── Automation Triggers (docs/design/19-dashboard-ia-and-triggers.md) ────────
 --
 -- A Trigger is a per-domain rule: when an event happens, run the LLM with a
@@ -1036,6 +1140,612 @@ CREATE TABLE IF NOT EXISTS integration_writes (
 CREATE INDEX IF NOT EXISTS idx_integration_writes_expires
     ON integration_writes(expires_at);
 
+-- ── Browser History Integration (P1 infra + observability) ─────────────────
+
+CREATE TABLE IF NOT EXISTS browser_visits (
+    id INTEGER PRIMARY KEY,
+    ts INTEGER NOT NULL,
+    browser TEXT NOT NULL,
+    profile TEXT,
+    url_hash TEXT NOT NULL,
+    domain TEXT NOT NULL,
+    category TEXT NOT NULL,
+    meaningful INTEGER DEFAULT 0,
+    dwell_sec INTEGER,
+    foreground_sec INTEGER,
+    transition INTEGER,
+    is_reload INTEGER DEFAULT 0,
+    root_task_id INTEGER,
+    http_status INTEGER,
+    title TEXT,
+    search_query TEXT,
+    amazon_asin TEXT,
+    amazon_locale TEXT,
+    UNIQUE(browser, profile, ts, url_hash)
+);
+CREATE INDEX IF NOT EXISTS idx_browser_visits_ts
+    ON browser_visits(ts);
+CREATE INDEX IF NOT EXISTS idx_browser_visits_root_task
+    ON browser_visits(root_task_id) WHERE root_task_id IS NOT NULL;
+CREATE INDEX IF NOT EXISTS idx_browser_visits_amazon
+    ON browser_visits(amazon_asin) WHERE amazon_asin IS NOT NULL;
+CREATE INDEX IF NOT EXISTS idx_browser_visits_meaningful
+    ON browser_visits(meaningful, ts) WHERE meaningful = 1;
+
+CREATE TABLE IF NOT EXISTS browser_research_clusters (
+    slug TEXT PRIMARY KEY,
+    root_task_id INTEGER NOT NULL UNIQUE,
+    display_name TEXT NOT NULL,
+    started_at INTEGER NOT NULL,
+    last_activity_at INTEGER NOT NULL,
+    visits_total INTEGER NOT NULL,
+    meaningful_visits_total INTEGER NOT NULL,
+    meaningful_foreground_sec_total INTEGER NOT NULL,
+    distinct_meaningful_domains INTEGER NOT NULL,
+    status TEXT NOT NULL
+        CHECK (status IN ('active', 'dormant', 'concluded', 'muted')),
+    last_dm_at INTEGER,
+    last_research_offer_at INTEGER,
+    last_wiki_offer_at INTEGER,
+    research_offer_accepted_at INTEGER,
+    wiki_summary_written_at INTEGER,
+    agent_summary_revision INTEGER DEFAULT 0
+);
+
+CREATE TABLE IF NOT EXISTS browser_pending_offers (
+    slug TEXT NOT NULL,
+    -- BROWSER_HISTORY_INTEGRATION_PLAN seventh-pass — the 'offered'
+    -- kind is the two-option offer state (user asked, no reply yet);
+    -- accept endpoint narrows it to research_assist / wiki_summary
+    -- on dispatch. P3b-era rows with the kind-specific values still
+    -- parse. Existing installs are migrated via the entry
+    -- 0001-browser-pending-offers-add-offered-kind in migrations.ts.
+    kind TEXT NOT NULL
+        CHECK (kind IN ('offered', 'research_assist', 'wiki_summary')),
+    offered_at INTEGER NOT NULL,
+    expires_at INTEGER NOT NULL,
+    PRIMARY KEY (slug, kind)
+);
+
+CREATE TABLE IF NOT EXISTS browser_reload_signals (
+    date TEXT NOT NULL,
+    url_pattern TEXT NOT NULL,
+    reload_count INTEGER NOT NULL,
+    PRIMARY KEY (date, url_pattern)
+);
+
+CREATE TABLE IF NOT EXISTS browser_shopping_sessions (
+    id INTEGER PRIMARY KEY,
+    date TEXT NOT NULL,
+    vendor TEXT NOT NULL,
+    asin_set TEXT NOT NULL,
+    comparison_minutes INTEGER NOT NULL,
+    locale TEXT
+);
+
+-- ── Managed Chromium Automation (MANAGED_CHROMIUM_IMPLEMENTATION_PLAN.md §8.14, Phase B-2) ──
+-- Per-workflow run audit row. Originally populated by the
+-- workflow-runner; BROWSER_TASK_REDESIGN_PLAN.md §9 Phase 6 retired
+-- both the runner and the \`/api/browser-automation/{workflows,recent-
+-- runs}\` routes that fronted it. The table is INTENTIONALLY retained
+-- as a read-only historical store so users with pre-Phase-6 audit rows
+-- can still query their history out-of-band (sqlite shell). No live
+-- code writes to it; new audit lives in \`browser_task_action_log\`.
+-- The \`outcome\` CHECK constraint stays unchanged to preserve the
+-- shape of historical rows; the Zod mirror that paired with it was
+-- removed in the Phase 6.5 dead-code rip-out (shared/browser-history-
+-- schemas.ts).
+-- \`target_urls\` and \`blocked_requests\` were JSON arrays at write
+-- time. \`screenshot_path\` and \`trace_path\` were NULL when the
+-- workflow did not capture either (e.g., input_validation_error
+-- outcomes that short-circuited before Playwright ran).
+CREATE TABLE IF NOT EXISTS browser_automation_workflows (
+    id                INTEGER PRIMARY KEY AUTOINCREMENT,
+    workflow_id       TEXT NOT NULL UNIQUE,
+    workflow_name     TEXT NOT NULL,
+    params_hash       TEXT NOT NULL,
+    target_urls       TEXT NOT NULL,
+    blocked_requests  TEXT NOT NULL,
+    duration_ms       INTEGER NOT NULL,
+    outcome           TEXT NOT NULL CHECK (outcome IN (
+        'success',
+        'unknown_workflow',
+        'input_validation_error',
+        'output_validation_error',
+        'url_not_allowlisted',
+        'user_allowlist_blocked',
+        'host_not_extractable',
+        'rate_limited',
+        'site_not_connected',
+        'playwright_launch_timeout',
+        'playwright_error',
+        'timeout',
+        -- ── Phase B-3 (gated write automation) outcomes ──
+        -- Retained for historical audit rows. The B-3 approvals surface
+        -- (workflow runner + frozen registry + approvals table) was
+        -- retired in BROWSER_TASK_REDESIGN_PLAN.md §9 Phase 6; no new
+        -- rows with these outcomes are written post-Phase-6.
+        -- \`needs_approval\` — workflow was rejected because the caller
+        --   did not present a valid approval token. (Historical: the
+        --   companion pending row in browser_automation_approvals was
+        --   dropped by migration 0004 in the same plan.)
+        -- \`approval_expired\` — caller presented a token bound to an
+        --   approval whose 5-min TTL elapsed before redemption.
+        -- \`approval_token_invalid\` — token shape was wrong, did not
+        --   match any pending approval, or referenced an approval that
+        --   was already consumed / denied.
+        -- \`payment_path_blocked\` — primary URL matched the hard-coded
+        --   payment URL pattern set (/checkout, /payment, /place-order,
+        --   /buy, /place-bid). B-3 could not touch payment paths even
+        --   with a valid approval token; those belonged to B-4
+        --   purchase workflows (§17.5) which use the DM-token gate.
+        'needs_approval',
+        'approval_expired',
+        'approval_token_invalid',
+        'payment_path_blocked',
+        -- ── Phase B-4 (experimental purchase) runner-level outcomes ──
+        -- MANAGED_CHROMIUM_IMPLEMENTATION_PLAN.md §17 / §13 steps 49-60.
+        --
+        -- These fire BEFORE the workflow's run() is invoked — the master
+        -- toggle is off, per-site B-4 is not opted-in, a token is already
+        -- pending for this site_key (per-site concurrency cap 1), or the
+        -- per-site per-day token / spend cap is exhausted. In-flight
+        -- branches (user replied wrong, timeout, page mutated under the
+        -- pause, displayed total mismatch) surface through the workflow's
+        -- structured outputSchema.status and the runner-level outcome
+        -- stays \`success\` for those.
+        --
+        -- The DM-token gate itself is enforced inside the workflow via
+        -- purchase-handler.awaitReply(jti); there is no runner-level
+        -- \`purchase_token_invalid\` outcome because the agent CANNOT
+        -- supply a token at the route layer (B-4's consent model is
+        -- "daemon mints the token AFTER the pre-confirm screenshot;
+        -- the user types it back in DM").
+        'purchase_b4_disabled',
+        'purchase_site_not_enabled',
+        'purchase_pending_exists',
+        'purchase_daily_cap_exceeded'
+    )),
+    started_at        INTEGER NOT NULL,
+    finished_at       INTEGER NOT NULL,
+    screenshot_path   TEXT,
+    trace_path        TEXT
+);
+CREATE INDEX IF NOT EXISTS idx_browser_automation_workflows_started_at
+    ON browser_automation_workflows(started_at);
+CREATE INDEX IF NOT EXISTS idx_browser_automation_workflows_name
+    ON browser_automation_workflows(workflow_name, started_at DESC);
+
+-- BROWSER_TASK_REDESIGN_PLAN.md §9 Phase 6.5 follow-up retired the
+-- Phase-B-2 per-domain user allowlist (\`browser_automation_allowlist\`).
+-- The workflow-runner's deny-on-unknown gate that consumed it was
+-- deleted in Phase 6; the four \`/api/browser-automation/allowlist*\`
+-- routes that mutated it likewise. Fresh installs no longer materialise
+-- the table; upgrading installs drop it via migration
+-- 0005-drop-browser-automation-allowlist. The browser-task surface
+-- gates host access through the registered \`site-registry.ts\`
+-- \`allowedHostPattern\` plus per-request \`extraAllowedHosts\` (the
+-- §14.1 subset rules in BROWSER_TASK_REDESIGN_PLAN.md), not a runtime
+-- DB allowlist.
+--
+-- BROWSER_TASK_REDESIGN_PLAN.md §6.8 / Phase 6 retired the Phase-B-3
+-- approvals surface (workflow runner + frozen registry). The
+-- \`browser_automation_approvals\` table is no longer created on fresh
+-- installs; upgrading installs drop it via migration
+-- 0004-drop-browser-automation-approvals. The lite-final-confirm token
+-- table that replaces it lives below alongside the Phase B-4 purchase
+-- tokens — both write paths are owned by \`final-confirm-handler.ts\` /
+-- \`purchase-handler.ts\` and dispatch via \`jti\` prefix on incoming
+-- \`!~xxxxxxxx\` DM replies.
+
+-- ── Phase B-4 (experimental purchase) — DM-issued single-use tokens ──
+--
+-- MANAGED_CHROMIUM_IMPLEMENTATION_PLAN.md §17.6.
+--
+-- Every B-4 workflow (variant='purchase') goes through a strict
+-- screenshot-first DM-confirmation flow. The daemon mints a token
+-- ("!~<8 base32 chars>") AFTER taking the pre-confirm screenshot,
+-- DMs the screenshot + token to the user's primary channels, and the
+-- workflow pauses (§5.5 carve-out) on purchase-handler.awaitReply(jti).
+-- The user reads the actual cart screenshot, types the exact token
+-- back, and the messaging adapter's incoming-token-handler atomically
+-- flips consumed_at from NULL to now. Workflow resumes, re-checks
+-- the cart hasn't mutated, clicks confirm, captures post-confirm
+-- screenshot, persists confirmed_amount_minor + order_id.
+--
+-- Schema invariants:
+--   - jti is the server-side opaque id used for joins / audit; the
+--     dashboard only ever sees jti, never the raw token.
+--   - token carries the raw !~xxxxxxxx string while the row is
+--     pending. The daily cleanup cron rotates token to NULL once
+--     consumed_at or cancelled_at plus 1 day has elapsed, bounding
+--     the window during which a stale DM-history token could be replayed
+--     against a daemon bug. UNIQUE so a colliding mint (cosmically
+--     unlikely under 40-bit entropy but cheap to enforce) fails the
+--     INSERT at issuance time and the handler retries.
+--   - delivered_channels is a JSON array of "<platform>:<channel_id>"
+--     refs the daemon DMed to. The validation path checks the inbound
+--     channel against this list — a reply on a non-delivered channel
+--     cancels with a wrong_channel audit row (§17.4).
+--   - cancel_reason is a closed CHECK set so a hand-written cancel
+--     path cannot land an unrecognised category in the audit trail.
+--   - confirmed_amount_minor / order_id / post_screenshot_path
+--     populate only on the confirmed terminal path; everything else
+--     leaves them NULL.
+--
+-- The runner-level outcome on browser_automation_workflows for any
+-- B-4 invocation is either success (workflow ran to completion;
+-- inspect output schema status for the cart-confirm verdict) or one
+-- of purchase_b4_disabled / purchase_site_not_enabled /
+-- purchase_pending_exists / purchase_daily_cap_exceeded for the
+-- pre-flight rejections.
+CREATE TABLE IF NOT EXISTS browser_automation_purchase_tokens (
+    jti                       TEXT PRIMARY KEY,
+    -- Raw "!~xxxxxxxx" string. NULL after the daily cleanup rotates
+    -- consumed/cancelled rows. UNIQUE while non-null — collision at
+    -- mint time fails the INSERT and the handler retries.
+    token                     TEXT UNIQUE,
+    workflow_invocation_id    TEXT NOT NULL,
+    site_key                  TEXT NOT NULL,
+    url_pattern               TEXT NOT NULL,
+    -- The actually-displayed total at screenshot time, in minor units
+    -- (e.g., yen = JPY x 1; cents = USD x 100). The agent's input
+    -- expectedMaxAmountMinor is a sanity check the workflow uses
+    -- BEFORE minting (abort if exceeds); the token's
+    -- max_amount_minor is the daemon-computed exact figure.
+    max_amount_minor          INTEGER NOT NULL,
+    currency                  TEXT NOT NULL,
+    pre_screenshot_path       TEXT NOT NULL,
+    notes_for_user            TEXT,
+    delivered_channels        TEXT NOT NULL,
+    issued_at                 INTEGER NOT NULL,
+    expires_at                INTEGER NOT NULL,
+    consumed_at               INTEGER,
+    consumed_via_channel      TEXT,
+    cancelled_at              INTEGER,
+    cancel_reason             TEXT CHECK (cancel_reason IS NULL OR cancel_reason IN (
+        'user_reply',
+        'wrong_token',
+        'wrong_channel',
+        'timeout',
+        'explicit',
+        'amount_mismatch',
+        'amount_exceeds_token',
+        'page_changed',
+        'playwright_error',
+        'daily_cap_exceeded',
+        'b4_disabled',
+        'site_not_enabled',
+        'supervisor_orphan_sweep',
+        'dashboard_cancel'
+    )),
+    confirmed_amount_minor    INTEGER,
+    order_id                  TEXT,
+    post_screenshot_path      TEXT,
+    -- Derived status — kept on the row so dashboard filters do not
+    -- have to recompute. The application layer (purchase-tokens-store)
+    -- writes this in lockstep with the timestamp columns; the CHECK
+    -- closes the set so a hand-written status that drifts from the
+    -- timestamps fails at the DB layer.
+    status                    TEXT NOT NULL CHECK (status IN (
+        'pending',
+        'confirmed',
+        'cancelled',
+        'expired'
+    ))
+);
+CREATE INDEX IF NOT EXISTS idx_purchase_tokens_site_at
+    ON browser_automation_purchase_tokens(site_key, issued_at);
+CREATE INDEX IF NOT EXISTS idx_purchase_tokens_status_expires
+    ON browser_automation_purchase_tokens(status, expires_at);
+
+-- ── B-4 reply audit trail ─────────────────────────────────────────────
+--
+-- Every inbound message classified as a !~xxxxxxxx-shaped reply lands
+-- here, whether or not it matched a pending token. Powers the audit
+-- view + spoofing/replay analysis. Stores message_body_hash
+-- (sha256 of the raw body) NOT the raw token — even on the misclassify
+-- path the raw string never persists outside browser_automation_purchase_tokens.token.
+CREATE TABLE IF NOT EXISTS browser_automation_purchase_replies (
+    id                INTEGER PRIMARY KEY AUTOINCREMENT,
+    received_at       INTEGER NOT NULL,
+    channel_ref       TEXT NOT NULL,
+    message_body_hash TEXT NOT NULL,
+    matched_jti       TEXT,
+    outcome           TEXT NOT NULL CHECK (outcome IN (
+        'consumed',
+        'wrong_channel',
+        'expired',
+        'already_consumed',
+        'already_cancelled',
+        'no_match',
+        'cancel_workflow',
+        'shape_invalid'
+    ))
+);
+CREATE INDEX IF NOT EXISTS idx_purchase_replies_received_at
+    ON browser_automation_purchase_replies(received_at DESC);
+CREATE INDEX IF NOT EXISTS idx_purchase_replies_matched
+    ON browser_automation_purchase_replies(matched_jti)
+    WHERE matched_jti IS NOT NULL;
+
+-- ── B-4 per-site enable + caps ────────────────────────────────────────
+--
+-- MANAGED_CHROMIUM_IMPLEMENTATION_PLAN.md §17.8.
+--
+-- Per-site_key row. A site with enabled=0 cannot mint tokens — the
+-- runner returns purchase_site_not_enabled before Playwright is
+-- launched. Caps are enforced atomically at token-issuance time inside
+-- the same transaction that inserts the purchase_tokens row.
+--
+-- currency is the canonical ISO-4217 code for that site (mirrors
+-- the agent's params.currency). Caps are denominated in minor units
+-- of that currency (¥ = JPY × 1; ¢ = USD × 100). Cross-currency math
+-- never happens — every cap query filters on (site_key, currency)
+-- before SUM().
+CREATE TABLE IF NOT EXISTS browser_automation_b4_site_config (
+    site_key                       TEXT PRIMARY KEY,
+    enabled                        INTEGER NOT NULL DEFAULT 0
+        CHECK (enabled IN (0, 1)),
+    currency                       TEXT NOT NULL,
+    daily_token_cap                INTEGER NOT NULL DEFAULT 5
+        CHECK (daily_token_cap >= 1 AND daily_token_cap <= 100),
+    daily_spend_cap_minor          INTEGER NOT NULL DEFAULT 30000
+        CHECK (daily_spend_cap_minor >= 0),
+    per_tx_cap_minor_override      INTEGER
+        CHECK (per_tx_cap_minor_override IS NULL OR per_tx_cap_minor_override >= 0),
+    updated_at                     INTEGER NOT NULL
+);
+
+-- ── B-4 primary-channel selection ─────────────────────────────────────
+--
+-- MANAGED_CHROMIUM_IMPLEMENTATION_PLAN.md §17.8 "Primary channel
+-- configuration: list of owner DM channels with a primary:boolean flag
+-- per channel. Only primary channels receive B-4 confirmation requests.
+-- At least one primary channel is required for B-4 to be enabled."
+--
+-- One row per (platform, channel_id) pair the user has flagged as
+-- primary. The token-handler reads this set when minting a token; if
+-- the originating channel of the request is primary, the token is
+-- DM'd to that channel only (single-channel ergonomic flow). For
+-- scheduled-task-driven B-4 invocations (no originating channel) the
+-- token is fanned out to every primary channel and the validation
+-- path follows the "approved on <channel>" rule (§17.3).
+--
+-- Stored as a separate table (not a column on owner_channels) so the
+-- additive CREATE-IF-NOT-EXISTS upgrade path applies without an
+-- ALTER on the pre-existing owner_channels table.
+CREATE TABLE IF NOT EXISTS browser_automation_purchase_primary_channels (
+    platform     TEXT NOT NULL,
+    channel_id   TEXT NOT NULL,
+    set_at       INTEGER NOT NULL,
+    PRIMARY KEY (platform, channel_id)
+);
+
+-- ── Browser-task surface (BROWSER_TASK_REDESIGN_PLAN.md §6.4 / §6.6 / §6.7) ──
+--
+-- Open-ended natural-language browser sub-agent dispatched by
+-- POST /api/browser-task. A fresh Claude-only IAgentCore drives a single
+-- Playwright BrowserContext via the in-process \`aitne-browser\` MCP server.
+-- The agent calls a fixed envelope of tools (navigate / screenshot /
+-- dom_snapshot / click / type / press_key / wait_for / extract /
+-- ask_user / yield_for_clarification / finish); the runner enforces
+-- allowlist composition, the final-confirm gate, the §14 hardening
+-- floor, and writes one audit row per step.
+--
+-- Three tables — all additive via CREATE-IF-NOT-EXISTS:
+--   * browser_task                 — the task row + its terminal state
+--   * browser_task_action_log      — per-step audit (one row per tool call)
+--   * browser_task_clarifications  — ask_user round-trip queue
+-- and one parallel-to-B-4 token table for the lite-final-confirm flow:
+--   * browser_task_final_confirm_tokens
+--
+-- State machine (§4): pending → running → {awaiting_user|final_confirm}*
+--   → {completed|failed|timeout|cancelled|abandoned}. The CHECK pins the
+-- closed set so a hand-written transition cannot land an unknown state
+-- in the audit trail.
+--
+-- Boot-recovery (§6.5): every row in {pending, running, awaiting_user,
+-- final_confirm} is flipped to (failed, 'daemon_restarted') on next boot
+-- — the in-memory BrowserContext is unrecoverable across restarts.
+--
+-- Foreign-key shape: the API serves screenshots via the existing
+-- trace-store layer (\`<PA_DATA_DIR>/automation-traces/<taskId>/...\`), so
+-- \`screenshot_key\` on the action log is the relative filename only — the
+-- task id forms the directory.
+CREATE TABLE IF NOT EXISTS browser_task (
+    -- uuid v4 (crypto.randomUUID); shared with the trace-store sub-dir name.
+    id                          TEXT PRIMARY KEY,
+    -- Natural-language task description, the body of the sub-agent's
+    -- prompt. Capped 1..4096 chars at the route layer.
+    description                 TEXT NOT NULL,
+    -- Matches \`site-registry.ts\`. Nullable so a future Phase 4.1 anon
+    -- read path can land without a schema change; the Phase 1 route layer
+    -- still rejects null with 400 (\`generic_anon\` deferred per §8).
+    site_key                    TEXT,
+    -- JSON array<string>. §14.1 enforces: count <= 5, host-only shape,
+    -- eTLD+1 subset against the siteKey OR the \`EXTRA_ALLOWED_ETLD_HELPERS\`
+    -- set, scheme floor (https for auth profiles, http(s) otherwise).
+    -- Captured at task creation and never mutated mid-task (§14.1.5).
+    extra_allowed_hosts_json    TEXT,
+    -- "<platform>:<channel_id>". NULL when no DM channel is associable
+    -- (synthetic test runs); the runner falls back to
+    -- \`listPrimaryChannels()\` when emitting an ask_user / final-confirm DM.
+    -- §14.8: the value is intersected with primary-channels ∪ session
+    -- channel at task-creation time, never widened mid-task.
+    originating_channel         TEXT,
+    -- FK to agent_schedule when the task was inserted via \`scheduleAt\`.
+    -- Nullable for immediate-run tasks. ON DELETE SET NULL so deleting a
+    -- schedule row (rare) leaves the task row's history intact.
+    schedule_row_id             INTEGER REFERENCES agent_schedule(id) ON DELETE SET NULL,
+    -- §5 final-confirm gate toggle. Defaults true at the route layer.
+    -- Stored as INTEGER 0/1 (SQLite has no bool).
+    require_final_confirm       INTEGER NOT NULL DEFAULT 1
+        CHECK (require_final_confirm IN (0, 1)),
+    -- State machine — see §4.
+    state                       TEXT NOT NULL CHECK (state IN (
+        'pending',
+        'running',
+        'awaiting_user',
+        'final_confirm',
+        'completed',
+        'failed',
+        'timeout',
+        'cancelled',
+        'abandoned'
+    )),
+    -- Free-form categorical detail. Typically populated on non-success
+    -- terminal states (the success path carries its narrative in
+    -- \`report\`); the column accepts any short string the runner / boot
+    -- recovery / route handler chooses to record so a future success-
+    -- side audit hint stays cheap to add. Examples (non-success today):
+    --   'daemon_restarted', 'queue_timeout', 'cancelled_in_queue',
+    --   'site_unregistered', 'backend_unavailable', 'not_implemented',
+    --   'ask_user_without_yield', 'tool_loop_detected',
+    --   'blocked_request_spike', 'max_turns_exceeded',
+    --   'clarification_deadline', 'runner_unavailable'.
+    outcome_detail              TEXT,
+    -- Sub-agent's markdown report on the \`completed\` path. Null otherwise.
+    report                      TEXT,
+    -- Composed effective allowlist regex captured at task start (§14.1.5).
+    -- Persisted so the dashboard can render "why was this URL blocked".
+    -- TEXT (regex source) — the runner re-compiles to a RegExp on resume.
+    effective_allowlist_regex   TEXT,
+    -- Defence-in-depth: per-task CDP-blocked-request counter. The runner
+    -- aborts at >100 per §14.2; persisted so the dashboard surfaces the
+    -- spike post-mortem.
+    blocked_requests_count      INTEGER NOT NULL DEFAULT 0
+        CHECK (blocked_requests_count >= 0),
+    -- Cumulative untrusted-content cap (§14.6). 128 KB ceiling; the
+    -- counter is persisted so the cap survives a session resume from
+    -- yield_for_clarification.
+    extract_chars_total         INTEGER NOT NULL DEFAULT 0
+        CHECK (extract_chars_total >= 0),
+    created_at                  INTEGER NOT NULL,
+    started_at                  INTEGER,
+    finished_at                 INTEGER
+);
+CREATE INDEX IF NOT EXISTS idx_browser_task_created_at
+    ON browser_task(created_at DESC);
+CREATE INDEX IF NOT EXISTS idx_browser_task_state_created
+    ON browser_task(state, created_at DESC);
+-- The non-terminal index powers the "needs your attention" awaiting-count
+-- query (§9a.4) without scanning every historical row.
+CREATE INDEX IF NOT EXISTS idx_browser_task_non_terminal
+    ON browser_task(state)
+    WHERE state IN ('pending', 'running', 'awaiting_user', 'final_confirm');
+
+CREATE TABLE IF NOT EXISTS browser_task_action_log (
+    id              INTEGER PRIMARY KEY AUTOINCREMENT,
+    task_id         TEXT NOT NULL REFERENCES browser_task(id) ON DELETE CASCADE,
+    step_index      INTEGER NOT NULL,
+    -- Tool name as the agent called it (e.g. 'navigate', 'click', or
+    -- 'browser_internal' for the §14.3/§14.4 defence-in-depth handlers
+    -- that fire outside the agent's tool envelope).
+    tool_name       TEXT NOT NULL,
+    -- JSON-stringified args, redacted at insert time (text/screenshot
+    -- payloads truncated, secrets passed through the existing redaction
+    -- coverage guard).
+    args_json       TEXT NOT NULL,
+    -- ok | denied | error | allowlist_block | payment_block | timeout |
+    -- popup_blocked | dialog_dismissed | filechooser_cancelled |
+    -- download_blocked | extract_cap_exceeded | tool_loop_detected
+    outcome         TEXT NOT NULL,
+    blocked_reason  TEXT,
+    -- Relative filename under \`automation-traces/<task_id>/\`. Null when
+    -- the tool did not produce a screenshot.
+    screenshot_key  TEXT,
+    duration_ms     INTEGER NOT NULL CHECK (duration_ms >= 0),
+    at              INTEGER NOT NULL
+);
+CREATE INDEX IF NOT EXISTS idx_browser_task_action_log_task
+    ON browser_task_action_log(task_id, step_index);
+CREATE INDEX IF NOT EXISTS idx_browser_task_action_log_at
+    ON browser_task_action_log(at DESC);
+
+CREATE TABLE IF NOT EXISTS browser_task_clarifications (
+    -- uuid v4. Shared verbatim between the runner, the ask_user DM, and
+    -- the POST /clarify path.
+    id              TEXT PRIMARY KEY,
+    task_id         TEXT NOT NULL REFERENCES browser_task(id) ON DELETE CASCADE,
+    question        TEXT NOT NULL,
+    context_summary TEXT,
+    screenshot_key  TEXT,
+    asked_at        INTEGER NOT NULL,
+    -- asked_at + 5 min (CLARIFICATION_TTL_MS). The deadline scanner
+    -- sweeps overdue rows on the same 30 s tick that handles the
+    -- pending-queue timeout.
+    deadline_at     INTEGER NOT NULL,
+    answer          TEXT,
+    answered_at     INTEGER,
+    resolved        INTEGER NOT NULL DEFAULT 0
+        CHECK (resolved IN (0, 1))
+);
+CREATE INDEX IF NOT EXISTS idx_browser_task_clarifications_task
+    ON browser_task_clarifications(task_id);
+-- Partial index over the unresolved set — the deadline scanner sweeps
+-- this once every 30 s.
+CREATE INDEX IF NOT EXISTS idx_browser_task_clarifications_unresolved
+    ON browser_task_clarifications(deadline_at)
+    WHERE resolved = 0;
+
+-- ── Lite-final-confirm tokens (BROWSER_TASK_REDESIGN_PLAN.md §5 / §14.11) ──
+--
+-- Parallel primitive to B-4's \`browser_automation_purchase_tokens\`. Same
+-- \`!~xxxxxxxx\` UX, same single-use + 5-min TTL CAS, same DM-with-
+-- screenshot dispatch — but no purchase site config + no amount + no
+-- spend caps. The two coexist with distinct DB tables and distinct
+-- dispatch paths so a future B-4 spend-cap change cannot accidentally
+-- widen the lite path.
+--
+-- Dispatch coexistence (§14.11 / Q#6): incoming \`!~xxxxxxxx\` replies are
+-- routed by \`jti\` prefix — \`purchase-handler\` and \`final-confirm-handler\`
+-- jointly inspect the inbound and dispatch to the correct waiter. The
+-- strict-cancel-on-non-token-reply contract is replicated symmetrically.
+CREATE TABLE IF NOT EXISTS browser_task_final_confirm_tokens (
+    jti                       TEXT PRIMARY KEY,
+    -- Raw "!~xxxxxxxx" string while pending. UNIQUE so a colliding mint
+    -- (cosmically unlikely under 40-bit entropy) fails at INSERT.
+    token                     TEXT UNIQUE,
+    task_id                   TEXT NOT NULL REFERENCES browser_task(id) ON DELETE CASCADE,
+    -- The action's natural-language summary (e.g. "post 'Hello world' to X").
+    -- Surfaced verbatim in the DM so the user knows what they're confirming.
+    action_summary            TEXT NOT NULL,
+    -- Relative trace-store filename — the would-be-clicked element's
+    -- screenshot captured immediately before the gate trips.
+    pre_screenshot_path       TEXT NOT NULL,
+    -- JSON array<string> of "<platform>:<channel_id>". Same shape as
+    -- B-4's \`delivered_channels\`. Validation rejects replies on
+    -- non-delivered channels (defence against DM forwarding).
+    delivered_channels        TEXT NOT NULL,
+    issued_at                 INTEGER NOT NULL,
+    expires_at                INTEGER NOT NULL,
+    consumed_at               INTEGER,
+    consumed_via_channel      TEXT,
+    cancelled_at              INTEGER,
+    -- Closed cancel-reason set so a hand-written cancel path cannot land
+    -- an unrecognised category in the audit trail.
+    cancel_reason             TEXT CHECK (cancel_reason IS NULL OR cancel_reason IN (
+        'user_reply',
+        'wrong_token',
+        'wrong_channel',
+        'timeout',
+        'explicit',
+        'task_cancelled',
+        'dashboard_cancel'
+    )),
+    status                    TEXT NOT NULL CHECK (status IN (
+        'pending',
+        'confirmed',
+        'cancelled',
+        'expired'
+    ))
+);
+CREATE INDEX IF NOT EXISTS idx_final_confirm_tokens_status_expires
+    ON browser_task_final_confirm_tokens(status, expires_at);
+CREATE INDEX IF NOT EXISTS idx_final_confirm_tokens_task
+    ON browser_task_final_confirm_tokens(task_id);
+
 -- INTEGRATION-DRIFT-PHASE-7-PLAN.md §3.2 — persistent dedup for the
 -- 15-minute imminent-meeting reminder. Pre-Phase-7 the scheduler kept
 -- an in-memory Set, which was lost on every daemon restart and re-DMed
@@ -1056,7 +1766,7 @@ CREATE INDEX IF NOT EXISTS idx_imminent_event_notifications_notified_at
 -- ── Management Registry & Entities (docs/design/21-management-registry-and-entities.md) ──
 --
 -- L1 — Section B authoritative storage for managed tasks (§9.2).
--- The file at <contextDir>/rules/management.md is a deterministic render
+-- The file at <contextDir>/policies/management.md is a deterministic render
 -- from this table; user hand-edits are parsed back via the registry
 -- watcher (§7.2 management-registry.ts), with parse failures triggering
 -- a re-render from this table (FR-13).
@@ -1332,7 +2042,9 @@ VALUES
 --     routine, scheduled tasks, git.project.* one-shots. Standard
 --     50-turn / $1.00 envelope (git.project.* span 30–100 turns and
 --     $0.50–$2.00 — retemplate is widest because re-template work is
---     unbounded by shape).
+--     unbounded by shape). EXCEPTION: message.dm carries a wider $5.00
+--     per-turn ceiling (see the per-row note below) — its full-history
+--     re-processing tipped legitimate turns over the $1.00 nominal.
 --   - Haiku (DEFAULT_CLAUDE_LITE_MODEL) for "delegated/simple" surfaces —
 --     Gmail classification, GitHub event triage, git-poll observers,
 --     calendar-change handlers. Tight 20-turn / $0.20 envelope keeps an
@@ -1368,7 +2080,19 @@ VALUES
 INSERT OR IGNORE INTO process_backend_config
     (process_key, main_backend, main_model, max_turns, max_budget_usd, updated_by)
 VALUES
-    ('message.dm',              'claude', '${DEFAULT_CLAUDE_MEDIUM_MODEL}',  50,  1.00, 'preset'),
+    -- message.dm carries a wider $5.00 envelope (vs the $1.00 medium
+    -- nominal its siblings keep). DM turns are the operator's primary
+    -- conversational surface: they re-process the full DM history (which
+    -- can carry prior browser-task reports + screenshots) on every turn
+    -- and routinely run $0.70-0.80 on Sonnet, hugging the old $1.00 cap.
+    -- Legitimate multi-step turns (dispatch a browser task, answer a
+    -- follow-up, do real tool work) tipped over $1.00 and surfaced a
+    -- BackendQuotaError(max_budget_usd) to the user even when the work
+    -- itself succeeded. $5.00 is a per-turn CEILING, not a target —
+    -- actual spend is governed by the turn's work. Kept in lock-step
+    -- with ENVELOPE_OVERRIDES_BY_PROCESS_KEY in plan-presets.ts and
+    -- bumped for upgrading installs by migration 0006.
+    ('message.dm',              'claude', '${DEFAULT_CLAUDE_MEDIUM_MODEL}',  50,  5.00, 'preset'),
     ('message.mention',         'claude', '${DEFAULT_CLAUDE_MEDIUM_MODEL}',  50,  1.00, 'preset'),
     ('dashboard.chat',          'claude', '${DEFAULT_CLAUDE_MEDIUM_MODEL}',  50,  1.00, 'preset'),
     -- DOCS_QA_DESIGN.md §10.2 — seeded with updated_by='cascade' so the
@@ -1394,14 +2118,24 @@ VALUES
     -- at/above $0.50. The cap is realigned to $1.50 — 3x the design's
     -- typical p95 (matching the headroom convention used by
     -- routine.today_refresh) and below the parent envelope so Stage A
-    -- still can't silently consume the parent's headroom. Stage B's
-    -- $0.10 cap stays unchanged because its prompt + skills payload
-    -- (~15 KB total) did land at the projected size. Keep these
-    -- envelopes in lock-step with ENVELOPE_OVERRIDES_BY_PROCESS_KEY in
-    -- plan-presets.ts (the same lock-step invariant the
-    -- routine.roadmap_refresh row documents above).
+    -- still can't silently consume the parent's headroom.
+    --
+    -- Stage B was originally seeded at $0.10 on the same 15 KB prompt
+    -- projection that Stage A overshot. Production showed Stage B's
+    -- assembled prompt at ~21 KB; Haiku cache_creation alone (charged
+    -- at 1.25x input) consumes ~$0.06 on cold start and a single Bash
+    -- tool round-trip tipped over $0.10 mid-turn, producing
+    -- BackendQuotaError(max_budget_usd) before Stage B could PUT
+    -- daily/<yesterday>.md. Realigned to $0.30 — 3x observed typical
+    -- spend, matching the same headroom convention as
+    -- routine.today_refresh, below the lite-tier nominal ceiling.
+    --
+    -- Keep these envelopes in lock-step with
+    -- ENVELOPE_OVERRIDES_BY_PROCESS_KEY in plan-presets.ts (the same
+    -- lock-step invariant the routine.roadmap_refresh row documents
+    -- above).
     ('routine.morning_routine_today',   'claude', '${DEFAULT_CLAUDE_MEDIUM_MODEL}', 50, 1.50, 'preset'),
-    ('routine.morning_routine_journal', 'claude', '${DEFAULT_CLAUDE_LITE_MODEL}',   20, 0.10, 'preset'),
+    ('routine.morning_routine_journal', 'claude', '${DEFAULT_CLAUDE_LITE_MODEL}',   20, 0.30, 'preset'),
     ('routine.hourly_check',    'claude', '${DEFAULT_CLAUDE_MEDIUM_MODEL}',  50,  1.00, 'preset'),
     -- $0.30 budget: a typical drift-triggered refresh on Sonnet runs ~$0.10
     -- in 4 turns; the previous $0.10 cap left zero headroom and any larger
@@ -1506,7 +2240,37 @@ VALUES
     -- real morning fan-outs and tripped BackendQuotaError(max_budget_usd)
     -- mid-fetch, so this envelope is widened via the per-process
     -- override in plan-presets.ts (ENVELOPE_OVERRIDES_BY_PROCESS_KEY).
-    ('routine.fetch_window',    'claude', '${DEFAULT_CLAUDE_LITE_MODEL}', 20,  0.50, 'preset');
+    ('routine.fetch_window',    'claude', '${DEFAULT_CLAUDE_LITE_MODEL}', 20,  0.50, 'preset'),
+    -- BROWSER_HISTORY_INTEGRATION_PLAN P3:
+    --   research_cluster_update — nightly per-cluster journal append.
+    --     Lite tier (Haiku-class) — templated DM dispatcher with a
+    --     single PUT to context/research/<slug>.md. 5 turns / $0.05 is
+    --     enough headroom; the §10.3 safety floor refuses Codex
+    --     outright, so the seeded claude row is the only eligible
+    --     binding until the operator widens via /settings/models.
+    --   research_dispatch — accept path. Medium tier (Sonnet). Uses
+    --     WebSearch + WebFetch for parallel external research; budget
+    --     mirrors evening_review (50/$1.00) since the work shape is
+    --     similar (multi-source synthesis + structured write).
+    --   research_wiki_summary — accept path for wiki summary. Medium
+    --     tier; smaller envelope (30/$0.50) — the agent composes from
+    --     the cluster journal it already wrote, so WebFetch fan-out is
+    --     bounded.
+    ('routine.research_cluster_update', 'claude', '${DEFAULT_CLAUDE_LITE_MODEL}',    5,  0.05, 'preset'),
+    ('routine.research_dispatch',       'claude', '${DEFAULT_CLAUDE_MEDIUM_MODEL}', 50,  1.00, 'preset'),
+    ('routine.research_wiki_summary',   'claude', '${DEFAULT_CLAUDE_MEDIUM_MODEL}', 30,  0.50, 'preset'),
+    -- BROWSER_TASK_REDESIGN_PLAN.md §5 — open-ended browser sub-agent.
+    -- Medium tier (Sonnet) by default; the §6.1 safety floor pins claude
+    -- as the only eligible backend. 30 turns / $1.00 envelope absorbs
+    -- the multimodal-input cost of 4-5 screenshots over a 10-turn flow
+    -- without tripping BackendQuotaError ($0.50 was the initial target
+    -- but landed too close to the cap on Sonnet 4.6 with PNG <= 1MB
+    -- attachments).
+    --
+    -- Keep this row's (max_turns, max_budget_usd) in sync with §5's
+    -- envelope spec — a future widening to support multi-tab tasks
+    -- needs both this seed and the spec to move together.
+    ('browser_task',                    'claude', '${DEFAULT_CLAUDE_MEDIUM_MODEL}', 30,  1.00, 'preset');
 
 INSERT OR IGNORE INTO settings (key, value_json, updated_at)
 VALUES (
@@ -1551,4 +2315,3 @@ ORDER BY day DESC;
 export function applySchema(db) {
     db.exec(SCHEMA);
 }
-//# sourceMappingURL=schema.js.map