-- 0010_agent_config.sql — single-row live `AGENT_CONFIG` table the agent
-- runtime wrapper reads on every invoke. Paired with the existing
-- `stackbone_platform.agent_config_versions` (migration 0007) which keeps the
-- audit history; this table holds the *current* payload only and is what the
-- SDK wrapper (libs/sdk/src/serve/request-handler.ts) issues a
-- `SELECT payload FROM stackbone_platform.agent_config WHERE id = 1` against
-- on every `POST /invoke`.
--
-- Two tables, one source of truth (`agent_config.payload`):
--   - agent_config_versions  — append-only audit trail + rollback source.
--   - agent_config           — single row, mirrors the latest payload.
--
-- AgentConfigService.put() writes both inside the same call so the audit
-- never lags the live read.
--
-- The install saga (apps/api/.../neon.adapter.ts) used to create this table
-- inline because no migration existed for it; the inline DDL is now a no-op
-- (CREATE TABLE IF NOT EXISTS) but kept in place so the seed insert that
-- copies the per-install snapshot config into row id=1 still runs.

CREATE TABLE IF NOT EXISTS stackbone_platform.agent_config (
    id         int         PRIMARY KEY DEFAULT 1 CHECK (id = 1),
    payload    jsonb       NOT NULL DEFAULT '{}'::jsonb,
    updated_at timestamptz NOT NULL DEFAULT now()
);

-- Make sure the row exists even on a Neon that pre-dates the saga bootstrap
-- (e.g. testcontainer integration suites). Idempotent: re-running the
-- migration leaves the existing payload untouched.
INSERT INTO stackbone_platform.agent_config (id, payload)
VALUES (1, '{}'::jsonb)
ON CONFLICT (id) DO NOTHING;
