mainへの変更統合（2026年9月22日）

ユーザーの「mainに変更点を反映してほしい」に対応する統合記録。本番・デモサーバーへの配備は含まない。

統合元と保持した変更

開発版 9175fe6。ローカルmain 60d5a86 の未反映コミットも祖先として保持する。資料の再編、写真、連絡・記録、バックアップ形式2、9月17・19日の変更、設定・職員ログイン時間、保護者CSV変換の入力・省略修正を含む。
本番配備済み 5dec9cf。家庭一覧だけを整理するアーカイブ、記録を保護する家庭削除、管理者の園全体復元、9月15日のカレンダー取込・議事録出力・職員認証修正を統合する。
デモで確認した、保護者番号が文字列で保存された家庭CSVの差分表示修正を反映する。デモ専用認証・利用者別DBの構成はデモブランチに保持する。

競合した資料は最新の開発側の目次と配備完了記録を残し、本番側にしかなかった機能の説明を追加した。

mainの新規バックアップは形式2を維持する。家庭アーカイブとカレンダー取込のテーブルを含む main-integration-20260922 契約を追加し、以前の契約ファイルは変更しない。

管理画面の復元は形式1・形式2のIDとデータに対応する。許可したアプリ版、同じ園、互換スキーマ、管理者の再認証、写真・添付・DBの整合性検査を引き続き行う。形式2は保存時の検証契約も照合する。

復元直前の退避も形式2で作成する。イメージの固定digest、復旧手順の記録ID、復元ジョブIDを保持し、変更前の退避として扱う。形式2の定期設定は保存済みの頻度・時刻を復元し、無効にして管理者の確認を待つ。形式1は現在の設定を無効にする。

9月22日時点の本番環境は形式1の 5dec9cf のまま。次回の本番配備では、形式2に必要な設定と実機上の旧バックアップ互換性を別途確認する。

アーカイブ・復元・削除・スキーマの対象60件成功（139.47秒）。
アプリ、gateway、backup-worker、restore-workerを起動する架空データの復元演習が成功。利用停止、CSRF、パスワード再確認、WebSocket、復元後の再ログイン、進捗の閲覧権限、定期実行の無効化を確認した。
演習初回は確認POSTが400で停止した。診断出力を追加して再実行した結果、操作を省略せず完走した。初回の原因は特定していない。
統合コミット 3fbe9ca のGitHub CI成功。全891件成功（302.48秒）、Lint、資料のstrictビルドが成功した。検証結果。
ローカルでもLintと資料のstrictビルドが成功した。