FACTUAL ACTIVITY RECORD · 実際の作業をもとにした活動記録
Thread同期登録をRoomsへ統合する
Session IDの検証、metadata同期、Room割当を一つの確認操作へまとめる
目的
管理者は独立したThreads画面で同期対象を登録した後、Rooms画面でも同じIDを入力して割り当てる必要があった。この二段階の導線は、同期登録とRoom所属が別の概念であることを画面操作へ露出し、途中状態も見つけにくくしていた。
RoomsのAdd Threadだけでroot検証、同期設定、最低限のmetadata同期、Room割当まで進め、子Threadと会話履歴はbackground同期へ残すことを目指した。
実装
管理applicationから独立したThreads navigationを外した。Room詳細のAdd ThreadはSession IDを検証し、未登録なら同期planを作成したうえで、native confirmation後に設定適用とRoom割当を順に実行する。公開中Roomへ追加する場合は公開範囲が広がることを確認文へ示す。
Rooms toolbarへSynchronized Threads sheetを追加し、同期登録済みrootとRoom割当先をまとめて表示する。同期登録後に割当だけが失敗しても登録を暗黙に戻さず、未割当のrootとして再確認できる。
root task readerと同期処理は、追加直後にroot metadataだけを先行取得する経路を持つ。payloadのturnsComplete=falseをdatabase側で解釈し、metadata-only ingestが既存の完全なTurnとMessageを削除しないようにした。
Room割当mutationの応答を一覧用recordとしてdecodeせず、成功確認後にlist RPCから表示recordを再取得する形へ変更した。これにより、database上では成功しているのに一覧専用fieldの欠落をerrorとして表示する不整合を解消した。
図を描画しています…
確認したこと
確認結果
Roomsから1回の確認で同期設定とRoom割当を進める画面構成になり、独立したThreads navigationは削除された。
metadata-only ingestがrootの情報を更新しながら、既存のTurnとMessageを保持するpgTAP回帰検査が追加された。
cutoff時点の仕様記録ではlocal fresh reset、pgTAP 69 assertions、Swift 22 tests、local Data API検査、実service smokeが成功していた。
この変更は対象へ反映されたが、最終的なStory全体の取込みとIssue完了は次の独立した活動である。
完了とした根拠
Rooms内の単一操作でroot検証から割当まで進み、metadata先行同期が完全な履歴を壊さず、同期済み・未割当状態も再確認できることをcode、database test、仕様記録で確認したことを完了基準とした。