「ほかの日からコピー」のcopyOneDayが固定連絡を黙って消していた

結論

「ほかの日からコピー」の内部関数 copyOneDay は、対象日の連絡欄（notices）を複製元の内容で全置換する実装だった。AI が連絡欄を書き換える経路ではすでに使っていた固定連絡（pinned・「ずっと」表示）の保全関数 preservePinnedNotices を、コピーの書き込み経路だけ呼んでいなかったため、教員が対象日に入力していた固定連絡はコピーを実行した瞬間に黙って消えていた。

症状

サイネージエディタには、前日・前週の連絡や予定を対象日へ複製する「ほかの日からコピー」がある。連絡欄には教員が「ずっと」表示させたい項目を固定（pinned）にする機能があり、AI が連絡内容を反映する経路ではこの固定連絡を消さないよう保全する処理が入っていた。

ところがコピー機能の内部コア copyOneDay は、対象日の notices を複製元の daily.get("notice") でそのまま置き換えていた。

// 2026-07-18 14:36 時点（#1292 マージ直後）: 全置換するだけで、対象日の固定連絡を見ていない
if (block === "schedule" || block === "notice" || block === "assignment") {
  const items = daily.get(block) ?? [];
  const field =
    block === "schedule" ? "schedules" : block === "notice" ? "notices" : "assignments";
  await upsertDailySectionForTarget(tx, actor, target, toDate, field, items);
  count = items.length;
}

複製元の連絡に固定行が含まれているかどうかに関わらず、対象日側にあった固定連絡はこの upsertDailySectionForTarget の呼び出しで丸ごと上書きされ、消える。教員から見ると、対象日に入力していた「ずっと」表示の連絡が、コピー操作のあと理由もなく無くなっている状態になる。

原因

このコピー機能は、前日コピーと前週コピーという別々の実装を「ほかの日からコピー」という1つのツールへ統合した #1289 で今の形になった。連絡欄の全置換自体は元々の前日/前週コピーにもあった挙動で、「その日の写し」を作るという設計としては正しい。

問題は、それとは別に AI が連絡欄を書き換える経路（assistant-chat-core）には、固定連絡を保全する preservePinnedNotices という関数がすでに用意されていたことだった。連絡欄を書き換えるという同じ操作なのに、AI 経路には保全があり、コピー経路には無い。この非対称に、#1289 のレビューで指摘が入った。

#1289 のマージが 14:29、直後に undo（元に戻す）機能を足す #1292 が 14:36 にマージされている。#1292 は「コピーしたら困ったときに戻せる」という保険であって、固定連絡が消えること自体を防ぐものではない。教員は固定連絡が消えたと気づかない限り undo を使う理由がなく、実質的な救済にはならなかった。

直す

copyOneDay の連絡書き込みだけ、AI 反映と対称になるよう preservePinnedNotices を通すようにした。

// #1310（16:39 マージ）: 上書き前に控えた対象日の RAW スナップショット(before)から
// 固定行を前置き合流させてから書き込む
const toWrite =
  block === "notice"
    ? preservePinnedNotices(
        [{ date: toDate, items: (before.notice ?? []) as NoticeItem[] }],
        toDate,
        items as NoticeItem[],
      )
    : items;
await upsertDailySectionForTarget(tx, actor, target, toDate, field, toWrite);

before は undo 用にすでに読んでいた「上書き前の対象日スナップショット」を、書込みと同一トランザクション内でそのまま再利用している。追加の読み取りは発生していない。

複製元の固定連絡との二重表示も起きない。複製元を読む readCopySource の copyableNoticeItems が、複製元側の固定連絡を最初からコピー対象（items）に含めていないため、preservePinnedNotices が足すのは対象日にもともとあった固定連絡だけになる。

再発防止

このパターンの怖さは、schedule / notice / assignment という3種類のブロックのうち、保全が要るのは notice だけだという点にある。同じ if 分岐の中を書き換える際、notice の分岐にだけ気を配る必要があり、次に似た書き込み経路を増やしたときも同じ抜けが起きうる。

そのため copy-pinned-notice.test.ts では、DB・認可・パターン解決といった周辺のシームはスタブしつつ、copyableNoticeItems と preservePinnedNotices という pinned 判定の純ロジックはモックせず実体のまま通し、upsertDailySectionForTarget に実際に渡る notices の中身を検証するようにした。周辺を止めて中核だけ実測する形にしたことで、次に書き込み経路が増えても、保全が抜けていればこのテストが落ちる。