---
generated_at: 2026-01-30 12:32:00
metrics:
  claims_total: 30
  claims_with_evidence: 28
  claims_without_evidence: 2
confidence_derived: 0.93
---

# 根拠レポート：12-fullSync.md

## 本レポートについて

### 目的
本レポートは、生成された設計書・ドキュメントの信頼性を検証し、人間レビュアーが効率的にレビューできるようにすることを目的としています。

### チェック方法
以下の観点でドキュメントの内容（Claim：主張）を検証しています：

1. **根拠の有無確認**：各主張に対して、ソースコード・既存設計書・要件定義書などの根拠（Evidence）が存在するか
2. **根拠との整合性**：主張の内容が根拠と矛盾していないか
3. **網羅性**：参照すべき情報源を適切にカバーしているか

### 信頼度スコアの算出
- **confidence_derived** = 根拠あり件数 / 総主張件数
- 状態「○」：根拠あり、「△」：根拠不足または要確認

### 本レポートの使い方
1. まず「サマリー」で全体の信頼度と優先レビュー項目を確認
2. 「Claims と根拠の対応」で △ の項目を重点的にレビュー
3. 「不足情報」で補完が必要な情報源を確認

---

## 1) サマリー（まず見るところ）
- 総合信頼度（derived）：**0.93**
  - 根拠あり：28 / 30、根拠なし：2
- 優先レビュー（高）
  1. **サーバー側ペイロード上限20MB**：コードコメントによる記載、サーバー側の確認が望ましい
  2. **処理時間の目標値**：推定値のため運用実績の確認が望ましい

## 2) 参照した情報（Evidence一覧）
> ここに「実在するもの」だけ列挙。抽出フェーズで付けたIDをそのまま出す。

- E-01: `packages/loot-core/src/server/sync/index.ts` (メイン実装ファイル)
- E-02: `packages/loot-core/src/server/sync/app.ts` (アプリケーションハンドラー)
- E-03: `packages/loot-core/src/server/sync/reset.ts` (リセット処理)
- E-04: `packages/loot-core/src/server/sync/repair.ts` (修復処理)
- E-05: `packages/loot-core/src/server/main.ts` (メインエントリ、app-focusedハンドラー)
- E-06: `docs/code-to-docs/バッチ一覧/バッチ一覧.csv` (バッチ定義)

## 3) Claims と根拠の対応（レビューの主戦場）
| Claim ID | 主張 | Evidence | 状態 |
|---|---|---|---|
| C-01 | CRDTベースのマージ処理 | E-01 L1-8 (@actual-app/crdt import) | ○ |
| C-02 | FULL_SYNC_DELAY = 1000ms | E-01 L36 | ○ |
| C-03 | 同期モードの種類（enabled/offline/disabled/import） | E-01 L37-74 | ○ |
| C-04 | scheduleFullSync関数の動作 | E-01 L506-523 | ○ |
| C-05 | テスト環境では即時実行 | E-01 L512-518 | ○ |
| C-06 | app-focusedハンドラーでの同期呼び出し | E-05 L120-125 | ○ |
| C-07 | getMessagesSinceでメッセージ取得 | E-01 L490-496, L654 | ○ |
| C-08 | encoder.encodeでメッセージエンコード | E-01 L665 | ○ |
| C-09 | postBinaryでサーバー送信 | E-01 L671-678 | ○ |
| C-10 | encoder.decodeでレスポンスデコード | E-01 L685 | ○ |
| C-11 | receiveMessagesで受信メッセージ適用 | E-01 L423-429, L692-699 | ○ |
| C-12 | merkle.diffでMerkle差分チェック | E-01 L702 | ○ |
| C-13 | リトライ回数制限（10回/100回） | E-01 L719 | ○ |
| C-14 | out-of-sync時のrebuildMerkleHash | E-01 L725, E-04 L6-25 | ○ |
| C-15 | lastSyncedTimestamp更新 | E-01 L783-790 | ○ |
| C-16 | sync-eventイベント発行 | E-01 L615-620 | ○ |
| C-17 | db.transaction内でのメッセージ適用 | E-01 L334-381 | ○ |
| C-18 | sequential/onceラッパーの使用 | E-01 L257 (sequential), L553 (once) | ○ |
| C-19 | batchMessagesによるメッセージまとめ | E-01 L459-480 | ○ |
| C-20 | unauthorized時のreadOnlyモード設定 | E-01 L597-598 | ○ |
| C-21 | 各種エラー種別とイベント発行 | E-01 L563-608 | ○ |
| C-22 | Timestamp.recvでの論理クロック更新 | E-01 L424-425 | ○ |
| C-23 | budgetType変更時のsetBudgetType呼び出し | E-01 L364-366 | ○ |
| C-24 | インポートモードでのスキップ処理 | E-01 L227-246, L258-260 | ○ |
| C-25 | 情報ログ出力（Syncing since...） | E-01 L658-663 | ○ |
| C-26 | 情報ログ出力（Got messages from server） | E-01 L687 | ○ |
| C-27 | captureExceptionでのエラー送信 | E-01 L567, L605 | ○ |
| C-28 | 5分前をデフォルトのsince値として使用 | E-01 L648-652 | ○ |
| C-29 | サーバー側ペイロード上限20MB | E-01 L668-670 (コメントのみ) | △ |
| C-30 | 処理時間の目標値（数秒〜数十秒） | **根拠なし** | △ |

## 4) 不足情報（Unknown / Missing）
- **サーバー側ペイロード上限**：コード内のTODOコメントで言及されているが、サーバー側の実装確認が必要
  - 候補：サーバー側コード / APIドキュメント / インフラ設定
- **処理時間の目標値**：コード上に明示的なSLAがないため推定値として記載
  - 候補：運用ログ / パフォーマンステスト結果 / 要件定義書

## 5) リスクフラグ（レビュー観点）
- 0: 低リスク - 全体的にソースコードとの整合性が高い
- 1: 中リスク - ペイロード上限についてはサーバー側との整合性確認が望ましい
- 1: 中リスク - out-of-sync発生時のユーザー対応フローの確認が望ましい

## 6) レビュアーチェックリスト（最小）
- [ ] 同期モード（enabled/offline/disabled/import）の切り替えが期待通りに動作するか
- [ ] FULL_SYNC_DELAYによる遅延が適切に機能し、過剰な同期リクエストが発生しないか
- [ ] Merkle差分解消のリトライ処理が無限ループに陥らないか
- [ ] unauthorized時のreadOnlyモード設定が適切にユーザーに伝わるか
- [ ] out-of-sync発生時のrebuildMerkleHash処理が正常に動作するか
- [ ] ペイロード上限（20MB）を超えた場合の動作確認（サーバー側）
