レビューの投稿はチャットのルームにしか無い。ルームは片付け（archive）の対象になり、消えないという保証が無い。指摘の内容も、相手がどう直したかも、そこにしか残っていない。
もう 1 つは読み返す経路が無いことである。aichat recent は件数で遡る道具で、日付や対象で引けない。12 本を通して読みたいときに使えない。
この保存は記録であって、レビューのやり方を変えるものではない。投稿はこれまでどおりチャットへ出し、そのあとで同じ内容をファイルに落とす。
利用者から 6 点の選択肢を示され、次のように決まった。番号は提示時のもの。
| # | 決めたこと | 採った案と理由 |
|---|---|---|
| 1 | フォルダ番号 | notes/80_quality_review/。70 を将来のために空ける |
| 2 | #seq の意味 |
チャットの発言番号。「発生した時の番号」はルームが振った番号を指す |
| 3 | ファイル名の # |
入れない。URL でフラグメントの開始になり、リンクが切れる |
| 4 | 相手の返信 | 同じファイルに入れる。指摘から対応までが 1 件で完結する |
| 5 | Markdown 化 | 保留。HTML を固めてから流す |
| 6 | この計画書 | 残す。経緯が無いとルールの変更が追えなくなる |
置き場は notes/80_quality_review/。1 件 1 ファイルで蓄積するフォルダなので、名前は種別 1 文字と日付の形に従う。
ファイルを作ったら、同じフォルダの品質レビューの記録に 1 行足す。保存と索引の追記は 1 つの作業で、別の回に回さない。README には一覧を置かない（更新の手が届かず古くなる）。
q yymmdd -nn -<対象プロジェクト> -<発言番号> -品質レビュー.html
│ │ │ │ │
│ │ │ │ └ 投稿がルームで受けた番号
│ │ │ └ レビューした相手のプロジェクト名
│ │ └ その日の連番。36 進数 2 桁（01〜09 0a〜0z 10〜1z … zz）
│ └ 投稿した日
└ 種別。q は品質レビュー| 番号 | どこに出るか | 意味 |
|---|---|---|
| 発言番号 | ファイル名・ID | ルームが投稿に振った通し番号。投稿が消えても、どれを指していたかが残る |
| レビュー番号 | 本文の見出し | 【レビュー #N】。指摘を投稿したときだけ 1 つ進む |
ファイル名に採るのは発言番号のほうである。レビュー番号はこちらの数え方で、欠番が出る（実際に #4 が欠けている）。発言番号はルームが振るので重複も欠落も起きない。
ファイル名に # は入れない。URL では # から先がフラグメント（ページ内の位置）として扱われるため、...-#560-... を含むリンクは %23 に書き換えないと到達しない。GitHub Pages でも同じである。資料の中では #560 の形で書く。
投稿しなかった回はレビュー番号を使わない決めごとなので、残すものも無い。ただし #4 だけは番号を消費した状態で欠けている。この決めごとを立てる前の回で、当時は回数で振っていた。
置き場も種別 1 文字も定期と同じにする。末尾の件名だけを変える。
| 項目 | 定期 | 都度の依頼 |
|---|---|---|
| 置き場 | notes/80_quality_review/ | 同じ |
| 種別 1 文字 | q | 同じ |
| 発言番号 | 自分の投稿 | 依頼 |
| 件名 | 品質レビュー | 依頼レビュー |
| 章 | 3 章 | 4 章（先頭に「依頼」） |
入れるのは、その回の起点になった発言の番号である。定期は依頼が無いので自分の投稿が起点、都度は依頼が起点になる。返信の番号はタイトルバーと本文に書く。
置き場と種別を分けないので、nn が 1 日 1 本の連番で足りる。分けると同じ日に -01 が 2 つでき、名前順が時系列と揃わなくなる。
依頼は 2 段で来る（コーディング後にコードと設計資料、テスト後に総合）。同じ変更に対して 2 本の記録が残り、名前は起点になった依頼の発言番号で分かれる。段階はタイトルバーに書く。
notes/ 配下なので単独の HTML にする。CSS は <style> に全部書き、外部ファイルを参照しない。BOM 付き UTF-8。
| 場所 | 中身 |
|---|---|
| タイトルバー | 【レビュー #N】 の見出し、対象プロジェクト、投稿日時、発言番号、作成日 / 更新日 |
| 章 1「指摘」 | 投稿した本文の指摘部分。項目ごとに h2 で分ける |
| 章 2「あわせて確認したこと」 | 「食い違いが無かったところ」「解消を確認した分」。添えていない回はその旨を 1 行 |
| 章 3「相手の対応」 | 返信の本文と、あとでこちらが解消を確かめた結果。返信が無い回はその旨 |
| 先頭とフッター | root の README.html へ戻るリンク |
定期の分は章 3 本で、色相は 280 / 140 / 0。都度の依頼は先頭に「依頼」が入って 4 本になり、色相は 280 / 186.7 / 93.3 / 0 にする。
本文は投稿したものから変えない。あとから読む人が、チャットに流れたものと資料が同じかどうかを疑わずに済む。書式（見出し・表・コード）の置き換えだけを行う。
章 1・2 は投稿時点で固定するが、章 3 だけは相手の返信が届くたびに書き直す対象である。「返信待ち」のまま置き去りにしない。
別のタスクとして「あとで更新する」を覚えておかない。チャットへ返信する・報告する、その同じ作業の中で、対応する保存済みファイルがあれば章 3 を直し、convert-encoding と html2md まで済ませてから終える。「返信した」と「ファイルを直した」を 2 つの別の行為にすると、片方だけ行って終わる（実際に #560 で 9 日間起きた）。
対応する保存済みファイルの見分け方: 返信の --reply-to が指す発言番号、または本文が名指しする #NNN・【レビュー #N】から、notes/80_quality_review/ の同じ番号のファイルを探す。
定期レビューのほかに、N:/ 以下のプロジェクトからチャットでレビューを頼まれることがある。頼まれたらその場で実施し、チャットで返信する。人間の応答は待たない。
| 段 | ルーム | 中身 |
|---|---|---|
| 1 | public |
依頼はここに来る。誰が誰に頼んだかが全員に見える |
| 2 | 依頼元のコネクタ ID と同じ名前のルーム | 詳細のやり取りはこちらで行う。依頼元が作る |
依頼が来たら、そのコネクタ ID と同じ名前のルームも待受けの対象に足す。public と ai-chat-lite の 2 本に、依頼のあった分が加わる形になる。
aichat waiters :ai-chat-lite-reviewer: -p 8787 -r <依頼元のコネクタ ID>
aichat wait :ai-chat-lite-reviewer: -p 8787 -r <依頼元のコネクタ ID>ルームは依頼元が作る。こちらでは作らない。wait と say が参加者として登録するので、join も打たない。
| 項目 | 扱い |
|---|---|
| 対象 | 依頼で示された N:/ 以下のフォルダ。読むだけで、書き込みはしない |
| 中身 | 指摘だけ。直さない・催促しない。観点は定期レビューと同じ |
| 返信先 | 依頼元のルーム。元の発言に --reply-to で繋げる |
| 番号 | 【レビュー #N】 は付けない。あの番号は定期レビューの通し番号 |
承認を待たずに返せるのは、返すものが事実だからである。判断を含む返信（断る・方針を決める・仕様を変える）は、案を出して確認を得る。
| 残り | 中身 |
|---|---|
| Markdown 化 | 保留。流すと notes/ 配下の分も一度に増えるため、HTML を固めてから |
種別 1 文字の q |
共通ルールの変更にあたる。利用者の指示を待つ |
| 段階の語 | 依頼は「コードと設計資料」「総合」の 2 段で来る。タイトルバーに書く語をこの 2 つに固定するかは、3 段目が出たときに決める |
種別 1 文字を足すのは共通ルールの側である。いま q はこのプロジェクトの中でしか通らない。ほかのプロジェクトが同じ文字を別の用途に使うと、あとで衝突する。