Verify what the migration wrote, rather than reading its exit status. A

migration that reports success can still have written the wrong values, and a

data-bearing migration is the one place where that is expensive and silent.

Query the affected rows directly:

```sh

docker exec openagents /app/bin/openagents rpc 'Code.eval_file("/tmp/check.exs")'

```

Query the affected rows directly.

For a column added with a backfill, check three things: the row values the

backfill was supposed to write, the column's `is_nullable` and

`column_default` in `information_schema.columns`, and any constraint the

migration created. Capture the same counts before the migration runs so the

after-state has something to be compared against.

migration created.

```sh

docker exec openagents /app/bin/openagents rpc 'OpenAgents.Repo.query!("SELECT count(*) FROM <table> WHERE <column> IS NULL") |> IO.inspect()'

docker exec openagents /app/bin/openagents rpc 'OpenAgents.Repo.query!("SELECT is_nullable, column_default FROM information_schema.columns WHERE table_name = $1 AND column_name = $2", ["<table>", "<column>"]) |> IO.inspect()'

docker exec openagents /app/bin/openagents rpc 'OpenAgents.Repo.query!("SELECT c.conname, pg_get_constraintdef(c.oid) FROM pg_constraint c JOIN pg_class t ON t.oid = c.conrelid WHERE t.relname = $1", ["<table>"]) |> IO.inspect()'

```

Write the query out rather than staging a script and evaluating it. A step that

tells you to run a file it never shows you is a step you have to invent, and

what you invent is what goes unreviewed.

Capture the same counts before the migration runs so the after-state has

something to be compared against.

## 7. Rolling replacement

## What is here now

OpenAgents [hosts Git repositories](/docs/repositories) that you can create,

import from GitHub once, clone, push, pull, and browse. Use the browser or the

npm-distributed [OpenAgents CLI](/docs/openagents-cli).

import from GitHub once, clone, push, pull, and browse. Use the browser or

[Coder](/docs/install-cli), the command-line agent, which installs as a single

binary.

The issue tracker includes issues, labels, milestones, assignees, and projects,

each with a browser view and a GitHub-compatible REST endpoint. Code browsing

renders files and commits in repositories that you can access.

[Pull requests](/docs/pull-requests) propose one branch into another, and

[stacks](/docs/stacked-pull-requests) order several of them so each builds on

the one before it.

Three surfaces exist to show the system's own work rather than yours. The

[changelog](/changelog) lists every change with the receipt chain that took it

live. [Status](/status) reports fleet health. The

## What is not here yet

Pull requests, code review, and webhooks are not built. Where a page in these

docs describes something, that thing exists and you can click it — a

documentation site that mixes shipped features with planned ones leaves you

unable to tell which half you are reading.

Code review and webhooks are not built. A pull request can be opened, browsed

with its diff, commented on, and merged, but nothing records an approval, a

requested change, or a comment anchored to a line.

Where a page in these docs describes something, that thing exists and you can

click it — a documentation site that mixes shipped features with planned ones

leaves you unable to tell which half you are reading.

## Compatibility