FACTUAL ACTIVITY RECORD · 実際の作業をもとにした活動記録
Public Webとlocal同期基盤を仕上げる
実dataだけを表示し、fixture責務とThread tree取得を実運用に揃える
目的
Public Webの初期実装には画面内で生成するDemo dataが残り、公開data取得failureとpublished Room 0件を区別できなかった。local fixtureと実同期用初期化も同じcommandへ混在し、database reset後のConnector stateがDBと食い違う可能性があった。
公開画面を実dataだけに限定し、同期data、製品default、rich dummy dataの責務を分け、root配下の全Threadを確実に収集できるlocal検証基盤へ整えることを目指した。
実装
3D clientから生成済みDemo snapshotを削除した。published Roomが0件ならempty state、接続や設定のfailureならmaintenance stateとして扱い、古い表示を成功扱いで残さない。検索結果とRoom timelineも別stateへ分離した。
root task readerは全Threadを走査してsession IDで絞る方式をやめ、ancestorThreadIdを指定してactiveとarchivedの両方をpaginationする。取得した各候補をthread/readで検証し、descendant上限を維持する。
pnpm db:fixturesはowner、Connector、origin digest、製品default Agentだけを投入し、RoomやThreadのdummy dataを作らない。pnpm db:fixtures:allをrich local dataset用として分離し、実同期確認と画面確認が同じdatasetへ暗黙に依存しないようにした。
local database reset処理はlocal database reset時にdevelopment Connectorを停止し、同期対象、outbox、sequenceをDBと一緒に初期化する。Web用env生成はfixtureのdigestと対になるraw tokenをowner-only fileへ出し、databaseは変更しない。
図を描画しています…
確認したこと
確認結果
Public Webはfabricated Demo dataを表示せず、空状態と取得failureを別の画面状態として扱うようになった。
Connectorはrootのdescendant queryをactive／archivedへ分け、global scanに依存しなくなった。
最小fixtureとrich fixtureが別commandになり、reset後のConnector local stateもdatabaseと同時に初期化される。
cutoff時点でこれらの仕上げは対象へ反映された。CEO portrait追加とStory全体の最終確定は後続活動である。
完了とした根拠
実data限定のWeb状態、root限定のThread tree取得、最小／rich fixture分離、databaseとConnector stateの同時resetがcodeと検査手順へ揃ったことを、この仕上げ作業の完了基準とした。