FACTUAL ACTIVITY RECORD · 実際の作業をもとにした活動記録
編集セッションを動的に登録し安全にroomへ結び付ける
fresh rootの取込みからmembership完了までを永続化し、同じ取得先の日次重複を入口で防ぐ
目的
取得先ごとに始まるfresh rootを、通常の会話同期を壊さず一つの論理roomへ動的に結び付ける経路が必要だった。
失敗後の再試行で別rootが作られると同じ取得先・同じ日のidentityが衝突するため、remote送信より前に重複を止める必要があった。
実装
所有者だけが扱えるsecure spoolから開始・終了recordを収集し、fresh rootの形式、作業場所、作成時刻、親子関係を再検証する。通常の取込みが完了した後、lease付きの永続outboxで論理roomのmembershipを送り、ack後にrecordをsealする順序をSQLiteへ保存した。
- 取得先IDとJST日を不変のidentityとして各保存・送信境界で一致検査する。
- 一つの取得先と日付に最初のfresh rootだけを許可し、別rootはoutboxへ入る前に拒否する。
- 再試行は同じrootのrecord再読込と、同じ永続outboxの再送だけで行う。
- 別取得先の同日実行と、同じ取得先の別日実行は独立して受け入れる。
- 過去形式のpending record、payload、hash、membershipは変換せず読み続ける。
source情報がまだ用意されていない応答は一時的な前提不足として分類し、恒久的な失敗にせず同じidentityで再試行できるようにした。
一次Commitで追加されたenrollment stateと、started/terminal evidenceを同一実行として受け入れる照合条件を示す。型注釈と一部の補助比較を省いた詳細値は公開せず、確認した挙動だけを記録した。
図を描画しています…
確認したこと
確認結果
13のtest fileに含まれる214件のtest、typecheck、build、差分整合が通った。
最初のrootが実行中、終了待ち、seal済みの各状態で、同じ取得先・日付の別rootを送信前に拒否できた。
同一rootの再読込、別取得先の同日、同一取得先の別日、拒否後のscan継続が確認できた。
過去形式のnullable source、raw payloadとhash、同日複数rootの互換挙動が維持された。
動的登録とmembership連携は対象へ反映された。本番でのprocess起動とend-to-end往復はcutoff時点で未実施だった。
完了とした根拠
secure spool、fresh root再検証、永続checkpointとmembership outbox、単一root admission、過去形式互換を実装し、214件のtestで正常・競合・再試行経路を確認できたことをもって完了とした。