2026年9月20日の所属園児数修正の本番更新

状態: 2026年9月20日9:29:22 JSTに本番反映完了。

ユーザーによるsudo認証後、更新プログラムが正常に完了した。完了証跡と現在の配備メタデータを照合し、版・イメージの一致、Composeの保持、実機で描画した所属園児数と在園数の一致を確認済み。起動コマンドの再実行は不要。

ユーザーはモック確認後の実装を承認し、続けて本番反映を依頼した。現在の本番版を土台に、所属園児数の修正だけを取り込んだ。

固定した配備版

• 更新前: 8e458f223e2b32b30675cfec78cb2464fcf1fc0e（9月19日配備版）。
• 配備版: 801ed69915846bc42ec6e1f1342fc4f9f9aa6771。
• 本番用ブランチ: codex/classroom-count-20260920-production。
• 開発側の修正: 45639ae（codex/spec-20260919）。

ランタイムの差分は routers/classrooms.py と templates/classrooms/list.html の2ファイルのみ。所属園児を在園状態の園児だけで数える。画面構成、追加・編集操作、退園・卒園記録とクラスとの関連は保持する。DBスキーマ変更はない。

本番側のカレンダー取込・議事録出力・端末全画面維持・バックアップ方式・認証・通知・Composeを保持する。開発側の全体をそのまま配備しない。

配備前の検証

• 固定した本番用版の全体テスト: 754件成功、298.30秒。
• Ruff、MkDocs strict、差分の空白検査: 成功。
• 合意したモックの人数、在園0人、クラス未登録、クラス未設定、在籍状況変更後の再集計、退園・卒園記録の保持を確認。
• 更新プログラムの構成保持、WALバックアップ、既存データ改変検出、正常更新、切替前中断、起動失敗時の復旧、人数検証結果が得られない場合の復旧を模擬検証。
• 実機で使う既存機能・スキーマ確認コードをローカルの合成DBで実行。
• 新しい人数確認コードを合成データで検証。表示値が誤っていれば更新確認を失敗させる。
• ランタイム314ファイルのハッシュを固定。転送後のチェックサム・Python構文・本番版と設定の不変・更新未開始を確認。

本番反映の確認

新イメージを構築し、ネットワークを遮断した実DBコピーで起動処理を検証した。切替前にSQLiteバックアップ、設定退避、ZFSスナップショットを取得した。

更新後にアプリの正常起動、コネクターの稼働、既存68テーブルの内容、314ファイル、設定の保持を確認した。実機でクラス一覧を読み取り専用で描画し、人数がDBの在園数と一致することも検証した。退園児の記録は保持されている。確認結果はクラス別・在籍状況別の集計値のみを取得し、園児の氏名や入退園日は取得していない。

• 配備イメージ: sha256:e5576e7e853705922f279ca82d895634ab3f59a09feb20917cc48540858a8fcf。
• 更新前バックアップ・スナップショット識別子: before-classroom-count-20260920-20260920T002644Z。
• 完了証跡: SSHユーザーのホームの classroom-count-20260920-801ed69/status.json。
• 完了状態は complete。現在の配備メタデータが完了証跡のコミット・イメージと一致し、Composeハッシュが更新前と一致することを再確認した。

公開HTTPSへのブラウザー確認は、実行環境からのアクセスが ERR_BLOCKED_BY_CLIENT で遮断された。公開画面を確認済みとは扱わず、更新処理内のヘルスチェック・実機での読み取り専用描画・既存データ照合・配備メタデータの一致を完了根拠とする。アクセス制限は変更していない。

実利用者のアカウントによる編集試験は行っていない。利用中のクラス管理画面は再読み込みしてから人数を確認する。