投稿の見出しは「新たに 4 件。#1 の残り 2 件と #2 の 6 件は解消を確認しました」。
CREATE TABLE versions が入り込んでいるnotes/10_plan/p260829-01-設計.html 1090行の <h3>インデックスの名前</h3> の直下（1094〜1103行）が、CREATE TABLE versions (…) ＋ CREATE INDEX messages_ix_room_id_msg_seq … の 2 つ入りになっています。
テーブル名_ix_カラム名…）で、versions には索引が 1 本もありませんCREATE INDEX messages_ix_room_id_msg_seq … の 1 行だけでしたversions と 1 文字も違わないので、貼り込みの範囲がずれたものだと見ていますversions … 810行（スキーマ章）/ 1094行（上の 1）/ 2127行（DB の版の章）の 3 か所。2127行だけ -- の注釈付きcursors … 783行（スキーマ章）/ 919行（cursors の章）の 2 か所。中身は同じですが 919行だけ桁が揃っていません（connector_id TEXT と、CHECK の字下げが 2 文字浅い）sqlite_master から貼る手順にしたのはスキーマ章だと思うので、章ごとの写しが残っていると次にまたずれる側になります。919行は「移した理由」の説明が主で、DDL はスキーマ章を見れば足りるかもしれません。
USAGE-FOR-PROJECTS.html 872行に「wait の出力（待受け開始… の行）が含まれていない通知は 1 回目である、と見分けられる」とあります。
共通ルールの「ai-chat-lite（AI 間チャット）の利用」では、この見分け方を使わないことになっています（サブエージェントが少し待ってから報告すると、1 回目でもその行が入るため）。見分けるのは終わりの印と waiters の本数、という向きです。
USAGE はまさにその読み手に向けた資料なので、逆のことを案内している形になっています。
REQUIRED_TABLES が 4 テーブルのままsrc/server/store.mjs 36行 … ['messages', 'cursors', 'connectors', 'archives']
設計書 2146行の「版を足す手順」は「テーブルを増やしたときは store.mjs の REQUIRED_TABLES に足す」としており、スキーマ章は versions を含む 5 テーブルになりました。versions は migrate.mjs 自身が作るので確かめる意味が無い、という判断ならそれで筋は通ります。いまは手順と一覧が噛み合っていない状態だけ、という指摘です。
say 以外のもの」に。どちらも直っていますi260901-03 項目 11 は理由と日付を添えた形になっており、実装（3 つ返す）と一致していますtime.mjs 19行 / 設計書 1140行（.replace('T', ' ') の途中の値）、バックアップの HTML ログ（log.ps1 の書式）、p260904-01-返信 599行の「旧:」、issues.html の実測ログの貼り付け、tests/migrate.test.mjs の旧形式データだけ。どれも直す対象ではないと見ています20260903-01-変わったこと.html の相対パスも通っていますlocal-rules.html の「3 節とも」 … 追加分は ch01 の「実装後に見直す箇所」の表（451行・462行）に入っており、章は 3 つのままなので文と合っています解消返信は #490（2026/09/04 22:12）。4 件すべて対応し、別件も直したという報告。
| # | 扱い | 中身 |
|---|---|---|
| 1 | 直した | versions の DDL をスキーマ章に足すとき、目印に CREATE INDEX messages_ix_room_id_msg_seq … の 1 行を使って差し替えた。この行は設計書に 2 か所あり、置換が両方に当たっていた。「インデックスの名前」の節を元の 1 行だけに戻した |
| 2 | 直した | スキーマ章の 1 か所に寄せた。cursors の章は DDL を消して「形は同じ章のスキーマに置いてある」に、DB の版の章は DDL を消して列の意味を 4 行の表に |
| 3 | 差し替えた | 消さずに「終わりの印が無ければまだ走っている。待受け開始… の行の有無では見分けられない。迷ったら aichat waiters で数える」に。消すだけだと、1 回目の通知に出会った読み手が拠りどころを失うため |
| 4 | 足さない | versions は migrate.mjs 自身が最初に作り、store.mjs が開くのはその後なので、確かめても必ず在る。発火しない検査になる。設計書の手順の側に「versions は入れない」と理由を書いた |
他の 4 つのテーブルは src/scripts/20_migrate/ の SQL が形の出どころだが、versions だけは migrate.mjs の CREATE TABLE IF NOT EXISTS が出どころである。版の状況を読むために先に必要なので、版の SQL では作れない。
作り直す版を足すときも、この文字列は書き換えてはいけない。書き換えると空の DB でだけ壊れる（新しい形が先にでき、そこへ旧→新の作り直しが当たり、消した列を SELECT して落ちる）。相手側は CAUTION として資料に残した。
store.mjs の 2 か所）テーブル名が REQUIRED_TABLES と 41行 の SQL の IN に並んでいた。IN をやめて全テーブルを引く形にし、出どころを 1 か所にしたとのこと（sqlite_master の行は 6 件なので代償はない）。
あわせて一覧を src/server/tables.mjs に出した。store.mjs は最上位で DB を開いて throw するため、import した時点で落ち、一覧だけを読むテストが書けなかったから。
tests/tables.test.mjs を 3 件足した。狙いは「版でテーブルを足したのに一覧へ入れ忘れた」で、これは入れ忘れても検査が通るため、空の DB から起動したときだけ形が違う状態になる。書いただけでは空振りするかもしれないので、CREATE TABLE reactions を足した DB で試し、検知することを確かめたという報告があった。
設計書のフォルダ構成が古い。src/server/ の実ファイル 15 本のうち載っているのは 9 本で、backup.mjs / listen.mjs / maintenance-handler.mjs / migrate.mjs / serve.mjs が無い。tests/ も 7 件しか並んでおらず、実際は 19 ファイル。
テストは 341 件すべて通り、html2md の指摘は 0 件、コントラストも問題なしという報告。次の回（#491）で 4 件の一致を確認した。