FACTUAL ACTIVITY RECORD · 実際の作業をもとにした活動記録
3D空間へ表示するセッションを選べるようにする
全履歴の同期を保ちながら、所有者単位の許可リストで表示対象だけを管理する
目的
同期済みのroot sessionがすべて3D空間へ並ぶため、見たいtaskへ絞る方法がなかった。履歴の保存範囲を狭めたり削除したりせず、画面へ見せるsessionだけを選択する仕組みが必要だった。
認証済みの管理画面から複数sessionを選び、島、session選択、会話取得のすべてへ同じ許可リストを適用しながら、未選択の履歴も保存し続けることを目指した。
実装
画面実装とsession管理UIに管理画面を追加した。検索、複数選択、全解除、選択上限の表示、保存中・成功・失敗状態を備え、最大24件を一度に表示対象として選べるようにした。
- session表示policyは所有者とprojectに対応する許可sessionを読み書きする。
- endpoint実装は認証済みの要求だけを受け、一覧取得と置換保存を分ける。
- databaseの専用RPCは、所有者、project、root session、上限を検証してから許可一覧を原子的に置き換える。
許可リストtableへ所有者単位の行制御を設定し、同じprojectへの複数タブ保存はproject row lockで直列化した。初回移行では従来表示を急に消さないため最新24件を許可済みにし、その後に同期された新しいsessionは明示選択まで非表示にした。
同期adapterと3D状態変換へ許可sessionを渡し、3Dの島、session pull-down、会話APIを同じ対象へ限定した。非表示sessionのroomIdが指定された場合は最新の表示対象へ戻し、選択が0件なら架空の島を作らず管理画面への案内を出す。
- 選択解除は表示だけを変え、同期済みtask、turn、messageを削除しない。
- collectorとdatabaseへの全件同期は変更せず、保存と表示の責務を分離した。
- 同一の認証所有者内での表示制御に限定し、外部閲覧者ごとの公開認可とは扱わない。
mapperと表示境界のtestに加え、認証済みdatabaseで24件上限、同時保存の直列化、非表示sessionの除外、無効な指定からのfallbackを検査した。lint、型検査、production build、database lintも同じ変更に対して実行した。
表示対象の選択にはdatabase側とapplication側で共通の上限を置き、設定不備・mismatch・上限超過・query失敗を区別して停止した。
図を描画しています…
確認したこと
確認結果
21件のtestが成功し、lint、TypeScript型検査、production build、database lintも通過した。
認証済みdatabaseで、24件上限と複数保存の直列化が機能することを確認した。
許可されていないsessionは島、選択肢、会話取得から除外され、無効な指定は表示可能なsessionへ戻った。
選択0件では架空のsessionを表示せず、管理画面へ誘導する状態になった。
cutoff時点で表示管理と許可リストは対象へ反映され、全履歴の同期は維持された。外部閲覧者別の公開認可や、24件を超える表示設計はこの範囲に含めていない。
完了とした根拠
管理画面、原子的な許可一覧更新、所有者単位の行制御、3つの表示経路への共通filterが揃い、正常系・同時更新・非表示・0件の確認が通った内容が対象へ反映されたことをもって完了とした。