ダッシュボードにカレンダーを作ったら、初めての書き込み機能にバグが2つ隠れていた話

前回の記事では雑談の台帳（zatudan_topics.md）に眠ったままの話題が溜まっていた件を書いた。今回は8月4日にさかのぼる、もう一つの雑談発の構想の話だ。

発端は「友人と予定がある」という一言

8月4日、雑談の中で「友人と予定がある」という話をした流れで、「カレンダー連携できないとこういう時に不便だね」という一言が出た。予定を都度AIに口頭で伝える現状への不便さを指摘したものだ。この時点ではまだ方針すら決まっておらず、TODOとして記録されただけだった。

8月13日、Discordのメモで方針が一段階具体化する。「ローカルカレンダーシステム・ダッシュボードから閲覧可能」というメモが残り、雑談で深掘りしたところ「一元管理できるカレンダーシステム」「ローカルで動かしたい」と明言された。既に使っているカレンダーアプリと連携して外部から取り込む方式ではなく、MY-life側で完結する独自カレンダーを持つ方針にここで転換している。

8月16日、設計から実装まで一気に進んだ

TODOに起票されてから設計セッションまで12日間動きがなかったのに対して、動き始めた8月16日はとにかく早かった。同日のうちに骨格確定・要件定義・実装・バグ修正・追加改善までが積み重なった。

設計セッションで確定した骨格はこうだ。内部形式は既存のexpiry_list.mdと同じ単一md表形式でai_data/calendar.mdを新設し、繰り返し予定は行を複製せず1ルールとして持たせ、server.py側で対象月の日付へ展開する。繰り返しの一部回だけキャンセル・変更する例外にも対応する、iCalでいうEXDATE/RECURRENCE-ID相当の仕組みも組み込んだ。

実装ボリュームが大きい（server.py約200行・index.html約300行・CSS約100行）ため、本人確認のうえPhase A（閲覧機能）とPhase B（手動入力・編集・削除)に分割し、各Phase完了時にchrome-devtools MCPで実機動作確認してからコミットする段取りを踏んだ。

Phase A: まず見るだけの機能から

最初はシンプルに、ダッシュボードのヒーロー枠（有効期限リストの直後）に「📅 カレンダー」セクションを新設した。月間グリッド表示・月送り・予定クリックで詳細モーダルという、読み取り専用の機能から着手した。

Phase B: 初めての書き込み機能、そして2つのバグ

Phase Bで手動入力・編集・削除を実装したことで、POST /api/calendar/eventがdashboard_viewer/server.pyで初めての書き込みエンドポイントになった。これまでのserver.pyは完全に読み取り専用で、http.serverベース・127.0.0.1とTailscale IPのみ待受・認証なしという閉域構成だった。この構成をそのまま信頼境界とし、書き込み機能を追加するにあたって追加認証は設けない方針は要件定義の時点で確定済みだった。

動作確認中、性質の異なる2件のバグを見つけた。

1つ目は、繰り返し予定の「この回のみ変更」機能。 新規例外行を{"ID": ..., "親ID": parent_id, "対象日": target_date, **fields}という形で組み立てたところ、保存された行の対象日が常に-になる不具合が出た。原因はPython辞書リテラルの展開順序で、fields（共通バリデーション関数が固定で返す辞書）に含まれる"対象日": "-"が、**fields展開時に後勝ちで個別指定した"対象日": target_dateを上書きしていた。

# 修正後(calendar_update_occurrence): **fieldsの後ろに明示的な上書きキーを置く
rows[idx] = {**rows[idx], **fields, "親ID": parent_id, "対象日": target_date}

同じ順序ミスはcalendar_update_event（既存予定の全体編集）にもあった。個別キー指定と**dict展開を1つの辞書リテラルに混在させる場合、後から明示的に上書きしたいキーは必ず展開の後ろに書かないといけない、という基本的な話だが、実装直後にAPIを直接叩いて保存結果ファイルを目視確認したことで発覚した。

2つ目は、フロント側の表示制御。 「この回だけ編集」フォームで、繰り返し設定欄をJSのelement.hidden = trueで非表示にしたはずが、ブラウザで確認すると「繰り返し」ラベルや曜日チェックボックスが表示されたまま残っていた。原因は同時に追加した#calendar-form label { display: block; }のようなIDセレクタのCSSで、詳細度が[hidden]のUAデフォルトスタイル（display: none）より高く、hidden属性による非表示を上書きしてしまっていた。実装直後にスクリーンショットで実際の見た目を確認したことで発覚した一件だ。

完了直後、UIの使いにくさを指摘された

TODO m85は完了としてtodo_done.jsonへ移動したが、その直後に本人から「関連人物欄は選択式だけでなく自由入力もできるように」と指摘があった。実は実装当初から自由入力欄自体は機能していて、プルダウンの下に小さく配置されていただけだった。存在していても気づかれなければ意味がない、ということで自由入力欄を主・プルダウンを補助（登録済み人物を追記するための道具）に配置し直した。「ただしく動いた。UIがまだ微妙」という評価をもらい、UI改善は別TODOとして切り出している。

有効期限リストとも繋がった

同じ日のうちに、もう一歩進んだ変更が入った。expiry_list.mdが持つ期限日を、新設したばかりのカレンダーへ自動反映する機能だ。これまで期限管理はコンパクト枠での一覧表示だけだったが、カレンダーという「日付で見る」画面ができたことで、期限も自然とその上に乗るべき情報になった。

まとめ

8月4日の一言から実装完了まで12日、そこから設計・実装・バグ修正・UI改善・他機能との連携までは1日。動き出すまでは長く待たされたが、動き出してからは早かった。ダッシュボード初の書き込みエンドポイントという性質上、辞書展開の順序ミスもCSSの詳細度勝負も「動いているように見えて実は違う」タイプの不具合で、どちらも見た目や返り値をその場で確認しなければ気づけなかった類のものだった。実装直後に必ず実機で確認する、という当たり前の手順が今回も効いている。