diff --git a/docs/operations/deploy.md b/docs/operations/deploy.md
index e650917a..823b99e5 100644
--- a/docs/operations/deploy.md
+++ b/docs/operations/deploy.md
@@ -29,7 +29,7 @@ flowchart LR
 
 - **ソースはイメージに焼き込まれる。** サーバーで `git pull` しただけでは何も変わらない。`build` してから `up` する。
 - **API は起動のたびにコンパイルする。** `api/prod.Dockerfile` はビルド時にコンパイルせず、compose の `go run main.go` が起動時にモジュールを取得してコンパイルする。そのため起動にはインターネット接続が要り、起動直後の数十秒〜数分は API が応答しない。
-- **DB はサーバーの外にある。** 本番の compose に DB は含まれない。DB は他のサービスと共用の HA クラスタで、ボリュームを消して作り直すような操作はできない。
+- **DB はサーバーの外にある。** 本番の compose に DB は含まれない。DB は他のサービスと共用の HA クラスタで、ボリュームを消して作り直すような操作はできない。アプリからの接続は、接続プール（PgBouncer）、Primary を選んで振り分ける HAProxy、Postgres の順に通る。DDL 用のポートは、接続プールを通らない（下の「migrate と seed」）。ポートとアドレスは別紙にある。
 - **解説 HTML はサーバーの `manuals/` にしかない。** git の管理外なので、サーバーを作り直すと消える。DB を初期化しても消えない。
 
 ## 作業の前に
@@ -222,7 +222,7 @@ mobile の入れ替えは数秒で済む。ただし入れ替えた直後は、
 1つの変更が API と GAS の両方にまたがるときは、「古い側が新しい側を受け取っても害がない」順に出す。
 
 - 45th のレスキュー通知（#546）は **GAS → API** の順にした。今の API は知らない項目を無視するので、新しい GAS が先でも害はない。逆にすると、通知してはいけない送信者に DM が飛ぶ。
-- 45th の休憩カード（#492）は **API → mobile → GAS → シフトの送り直し** の順にした。休憩のデータが入るのは GAS を更新して送り直したときなので、それまでは API と mobile を戻しても害がない。
+- 45th の休憩カード（#492）は **API → mobile → GAS → シフトの送り直し** の順にした。休憩のデータが入るのは GAS を更新して送り直したときなので、それまでは API と mobile を戻しても害がない。逆に GAS を先に入れて送り直すと、休憩の担当者を隠す処理が入っていない古い API のまま、休憩のシフトが入る。休憩のカードに担当者として全員が並び、誰が休憩中かが全員に見える（PR #492 の本文）。一度見られたものは、あとから API を入れ替えても取り消せない。
 
 ### 環境変数だけを変えるとき
 
@@ -256,7 +256,7 @@ docker compose up -d --force-recreate --no-build api
 - **前年のデータを残すなら、先に取り出す。** スキーマを作り直すと全部消える（アプリ内レビューなど）。
 - **`USER_DEFAULT_PASSWORD` を先に設定する。** 初期パスワードは、名簿送信でユーザーが作られた時点の値で固定される。
 - **`SLACK_BOT_TOKEN` を入れる順番に気をつける。** 順番を間違えると、溜まったシフト変更が一斉に DM で飛ぶ（[SeeFT に渡すデータの約束事](seeft-data-contract.md) の「Slack 通知を有効にする順番」）。
-- **`shifts` のインデックスを貼り直す。** migration に入っていないので、作り直すと消える（issue #500）。
+- **`shifts` のインデックスを貼り直す。** migration に入っていないので、作り直すと消える（issue #500）。インデックスを作る DDL（`CREATE INDEX CONCURRENTLY`）も、migrate と同じく DDL 用のポートで打つ（下の「migrate と seed」）。アプリ用のポート（接続プール経由）では、トランザクションの中として扱われて失敗する（2026-09-10 に本番の DB で確かめた）。どちらのポートにつながっているかは、psql の `\conninfo` で確かめる。SQL の `inet_server_port()` は Postgres 本体のポートを返すので、見分けられない。
 
 ### migrate と seed
 
diff --git a/docs/operations/staging-rehearsal.md b/docs/operations/staging-rehearsal.md
index 3e0cac91..95653e5a 100644
--- a/docs/operations/staging-rehearsal.md
+++ b/docs/operations/staging-rehearsal.md
@@ -16,7 +16,9 @@
 | 外からの入り口 | cloudflared のクイックトンネル（起動のたびに URL が変わる） | Cloudflare の名前付きトンネル（`seeft-api.nutfes.net` など） |
 | アプリ | 検証環境には立てず、手元の Mac から起動する | コンテナで配信 |
 
-このため、検証環境では見つからない問題がある。ビルドの漏れ、DB への接続（SSL・接続プール・ポート）、本番の環境変数の誤りは、本番でしか確かめられない。本番のデプロイ後の確認は [本番へのデプロイ](deploy.md) にある。
+このため、今の検証環境では見つからない問題がある。ビルドの漏れ、DB への接続（SSL・接続プール・ポート）、本番の環境変数の誤りは、本番でしか確かめられない。
+
+本番の DB への接続は、接続プール（PgBouncer）、HAProxy、Postgres の順に通る（[本番へのデプロイ](deploy.md) の「本番の構成」）。今の検証環境は、compose の中の PostgreSQL に直接つないでいるので、接続プールの中で DDL が失敗する、といった本番と同じ失敗は起きない。DB への接続の振る舞いまで検証環境で確かめたいときは、検証環境に接続プールと HAProxy を足し、この3段を同じ順につなぐ必要がある。45th の検証環境では、この構成は作っていない。本番のデプロイ後の確認は [本番へのデプロイ](deploy.md) にある。
 
 ## 手順
 
@@ -88,7 +90,7 @@ SELECT task, year_id, count(*) FROM tasks GROUP BY task, year_id HAVING count(*)
 
 ### 5. 手元の Mac からアプリを起動する
 
-アプリは検証環境に立てない。API が通信を許可している相手（CORS）が `http://localhost:45029` なので、手元でこのポートで起動する必要がある。
+アプリは検証環境に立てない。API が通信を許可している相手（CORS）が `http://localhost:45029` なので、手元でこのポートで起動する必要がある。検証用のサーバーからアプリを配信すると、ブラウザが送る Origin が `http://<検証用のサーバーのアドレス>:45029` になる。許可する相手は `api/lib/externals/server/server.go#RunServer` の `AllowOrigins` に書いた決まったリストで、ほかの Origin を許す仕組み（`AllowOriginFunc`）は無い。そのため、許可するには API のコードを書き換えて作り直す必要がある。
 
 ```bash
 cd mobile && fvm flutter run -d chrome --web-port 45029 --dart-define-from-file=env/.env --dart-define=API_BASE_URL=<トンネルのURL>
diff --git a/gas/README.md b/gas/README.md
index b18996ef..9849406f 100644
--- a/gas/README.md
+++ b/gas/README.md
@@ -58,6 +58,13 @@ cat *.js > /tmp/all.js && node --check /tmp/all.js
 "$repo_root/gas/node_modules/.bin/clasp" push -f
 ```
 
+レスキューのウェブアプリ（`rescue/`）は、デプロイごとに版を固定している。`clasp push` だけでは本番の `/exec` は変わらない。push のあと、`clasp deployments`（clasp 3.3.0 の正式名は `list-deployments`）で今の版を確かめ、同じデプロイ ID に新しい版を付け直す。下の `clasp deploy` は、正式名 `create-deployment` の別名である。前の版に戻すときも、同じデプロイ ID のまま、版だけを戻す。新しくデプロイすると別の URL になり、本番の API の `RESCUE_GAS_URL` が古い URL を指したままになる。デプロイ ID は別紙にある。
+
+```bash
+"$repo_root/gas/node_modules/.bin/clasp" deploy -i <デプロイ ID> -d "<説明>"
+"$repo_root/gas/node_modules/.bin/clasp" deploy -i <デプロイ ID> -V <戻す版>
+```
+
 push が通ったら、同じファイルをリポジトリへ写して commit する。これが「同期」にあたる。
 
 ```bash