Summary

Running gbrain init --migrate-only (or apply-migrations) on an existing brain at schema v29 fails with column "agent_name" does not exist while migrating to v34.

The failing migration in src/core/migrate.ts does an ALTER TABLE mcp_request_log ADD COLUMN IF NOT EXISTS agent_name TEXT followed by an UPDATE mcp_request_log SET agent_name = COALESCE(...) in what appears to be the same transaction. Postgres can't see the newly-added column inside the same transaction without a commit/savepoint.

Reproduction

1. Brain at schema v29 (gbrain v0.22.4).
2. Pull master tip (gbrain v0.26.7).
3. gbrain init --migrate-only
4. Output ends with:

   column "agent_name" does not exist
   

5. Schema-version row in config table stays at 29; later migrations don't apply.

Workaround

Manually pre-add the columns, then re-run the migrator:

ALTER TABLE mcp_request_log ADD COLUMN IF NOT EXISTS agent_name TEXT;
ALTER TABLE mcp_request_log ADD COLUMN IF NOT EXISTS params JSONB;
ALTER TABLE mcp_request_log ADD COLUMN IF NOT EXISTS error_message TEXT;

After that, gbrain init --migrate-only runs the remaining migrations cleanly through to v34.

Suggested fix

Either:

• Split the ALTER and UPDATE into separate transactions / commit blocks.
• Use a stored procedure / DO block with EXECUTE format(...) so the planner re-resolves names after the ALTER takes effect.
• Wrap the UPDATE in a guard that checks information_schema.columns first.

Environment

• macOS 26.3
• Postgres 18.3 (Homebrew)
• gbrain 0.26.7 (from master)