diff --git a/doc/migration-todo.md b/doc/migration-todo.md
index 6188e8f..3bc1f7b 100644
--- a/doc/migration-todo.md
+++ b/doc/migration-todo.md
@@ -74,6 +74,8 @@ Date: `2026-04-12`
 - An organization-scoped Gitea Actions runner for `trade-next` is now online on `sol` and can reach the target `k3s` cluster using the `K3S_KUBECONFIG_B64` org secret.
 - The first canary environment now exists in `trade-next/trade-gitops` under `environments/sol/trade-r001-canary`.
 - Namespace `trade-r001-canary` is live on `sol` with initial quota and limit guardrails, and can reach the shared `Postgres` and `Redis` services in `trade-infra`.
+- The first application surface for `R001` is now live in `trade-r001-canary`: `Hasura`, `trade-api`, and `trade-frontend`.
+- The target host `Postgres` on `sol` now has `TimescaleDB` installed and a matching application database/user provisioned for `R001`.
 
 ## Migration Risks
 
@@ -295,6 +297,7 @@ Date: `2026-04-12`
 - Done on `2026-04-12`: `Postgres` and `Redis` are running on `sol` as host services, bound to `127.0.0.1` and `149.50.96.162` for `k3s` pod access.
 - Done on `2026-04-12`: validated `Postgres` on `/srv/trade/postgres/16/main`, validated `Redis` on `/srv/trade/redis`, and confirmed `btrfs` quotas are active for both paths.
 - Done on `2026-04-12`: `Postgres` listens with pod CIDR access in `pg_hba.conf`, and `Redis` announces `149.50.96.162` for cluster-aware clients inside `k3s`.
+- Done on `2026-04-12`: installed `TimescaleDB 2.26.2` packages on host `Postgres` for `sol`, enabled `shared_preload_libraries=timescaledb`, and provisioned application role/database `admin/crypto` matching the live `trade-postgres` secret from `trade-staging`.
 
 ### 19. Bootstrap an organization-scoped Gitea Actions runner on `mevnode`
 
@@ -326,9 +329,19 @@ Date: `2026-04-12`
 
 ### 21. Bring up `Hasura`, API, and frontend on `mevnode`
 
-- Pending.
+- Done on `2026-04-12`.
 - Bring up `Hasura` only after `Postgres` is healthy.
 - Bring up API and frontend only after `Hasura`, `Postgres`, and `Redis` are healthy.
+- Use `trade-next/trade-gitops` as the source of truth for the canary application surface, not ad-hoc manifests on the host.
+- Keep the first application rollout internal to the cluster: `ClusterIP` services and health checks first, public ingress later.
+- Reuse the live `R001` application images and live application secrets, but point them at the target host `Postgres` on `sol`.
+- Done on `2026-04-12`: added `Hasura`, `trade-api`, and `trade-frontend` manifests to `trade-next/trade-gitops` under `environments/sol/trade-r001-canary`.
+- Done on `2026-04-12`: added operator scripts to `trade-next/trade-gitops` for `sol` host preparation, `gitea-registry` secret creation, and live secret sync from `mevnode_bot/trade-staging` into `trade-r001-canary`.
+- Done on `2026-04-12`: prepared `trade-r001-canary` secrets on `sol` for `trade-postgres`, `trade-hasura`, `trade-api`, `trade-frontend-tokens`, `trade-basic-auth`, and `gitea-registry`.
+- Done on `2026-04-12`: ran `postgres-migrate` and `hasura-bootstrap` jobs successfully on `sol`.
+- Done on `2026-04-12`: deployed `Hasura`, `trade-api`, and `trade-frontend` to `trade-r001-canary`; all three deployments reached `Available`.
+- Done on `2026-04-12`: verified internal HTTP health checks `200` for `http://hasura:8080/healthz`, `http://trade-api:8787/healthz`, and `http://trade-frontend:8081/healthz`.
+- Done on `2026-04-12`: verified GitOps execution through Gitea Actions; commit `6672e10` completed with status `success` for `deploy-trade-r001-canary / apply (push)`.
 
 ### 22. Migrate publishers and ingest only after storage and Redis validation pass
 
@@ -364,7 +377,7 @@ Date: `2026-04-12`
 - [x] 18. Install `Postgres` and `Redis` on `mevnode`.
 - [x] 19. Bootstrap an organization-scoped Gitea Actions runner on `mevnode`.
 - [x] 20. Prepare a minimal canary namespace for trade on `mevnode`.
-- [ ] 21. Bring up `Hasura`, API, and frontend on `mevnode`.
+- [x] 21. Bring up `Hasura`, API, and frontend on `mevnode`.
 - [ ] 22. Migrate publishers and ingest only after storage and Redis validation pass.
 - [ ] 23. Validate host health, agave health, trade health, and end-to-end flow after rollout.
 - [ ] 24. Keep `mevnode_bot` as a rollback target until the new stack is stable.