Files
MealQuest/migrations/0006_ai_runs_status.sql
T
dev_agentandClaude Opus 5.5 b0cf6fb951
CI / ci (push) Successful in 1m35s
CI / ci (pull_request) Successful in 1m32s
Record every harness run in ai_runs with redaction and purge
harness.Run now writes one ai_runs row per run that reaches the provider,
covering the repair turn: skill, version, provider, model, temperature,
status (ok, repaired, bad_output, provider_error), latency, summed token
counts when reported, error text and the per-turn request and response
bodies. Every stored string is redacted first: the decrypted API key,
Authorization and API-key header values, Google Chat webhook URLs and
URLs with key-like query or fragment parameters or user info. JSON is
decoded and its strings redacted, so escapes cannot hide a credential.
A row that cannot be written fails the run.

Purge deletes rows created before a cutoff (RunRetention is 30 days),
clearing suggestion_batches and week_plans references in the same
transaction.

Migration 0006 rebuilds ai_runs with the new status CHECK and a
created_at index; a pre-harness running or error row stops it.

Maestro task 53e382d8-1db3-4555-a31d-e44cf55cc98d.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-05 09:32:20 -04:00

48 lines
2.2 KiB
SQL

-- 0006_ai_runs_status: ai_runs.status becomes the harness run outcome:
-- ok the first reply was usable
-- repaired the first reply was not, the repair turn's was
-- bad_output neither reply was usable, or post-processing failed
-- provider_error the provider failed on either turn
-- A run's row is written once, when it ends, so there is no running state.
-- Nothing wrote ai_runs before the harness did, so no row holds the old
-- running or error values; if one does, the copy back fails the CHECK and
-- the migration stops rather than guess its outcome. created_at gains an
-- index for the 30-day purge. The rebuild is 0005's: copy the rows aside,
-- drop the table, create it again, copy the rows back and drop the copy.
--
-- suggestion_batches.ai_run_id and week_plans.ai_run_id reference ai_runs,
-- so foreign keys are deferred until commit, after the ai_runs rows are
-- back. The pragma lasts only for this migration's transaction.
PRAGMA defer_foreign_keys = ON;
CREATE TABLE ai_runs_copy AS SELECT * FROM ai_runs;
DROP TABLE ai_runs;
CREATE TABLE ai_runs (
id TEXT NOT NULL PRIMARY KEY,
skill TEXT NOT NULL,
skill_version TEXT NOT NULL,
provider TEXT NOT NULL CHECK (provider IN ('openai_compatible', 'anthropic', 'ollama', 'openai', 'openrouter', 'xai')),
model TEXT NOT NULL,
temperature REAL NOT NULL,
status TEXT NOT NULL CHECK (status IN ('ok', 'repaired', 'bad_output', 'provider_error')),
latency_ms INTEGER,
tokens_in INTEGER,
tokens_out INTEGER,
error TEXT,
request_redacted TEXT NOT NULL,
response_redacted TEXT,
created_at TEXT NOT NULL,
updated_at TEXT NOT NULL
);
INSERT INTO ai_runs (id, skill, skill_version, provider, model, temperature, status, latency_ms, tokens_in, tokens_out, error, request_redacted, response_redacted, created_at, updated_at)
SELECT id, skill, skill_version, provider, model, temperature, status, latency_ms, tokens_in, tokens_out, error, request_redacted, response_redacted, created_at, updated_at
FROM ai_runs_copy;
DROP TABLE ai_runs_copy;
CREATE INDEX ai_runs_created_at ON ai_runs (created_at);