想定する有効化方式: Model Decision（コードを直す作業のときに適用する。読むだけの質問には適用しない）

# 変更の進め方

受講者は当日、実行回数に限りのある環境で作業します。一度の往復で進む量を増やしてください。

## まとめて直す

- 指摘が複数ある場合は、一箇所ずつ直して確認を求めるのではなく、まとめて直してください。
- 追加の情報がなくても判断できることを、いちいち聞き返さないでください。判断に迷った箇所は、いったん自分の判断で進め、そのうえで「ここはこう判断しました」と述べてください。
- どうしても確認が要る場合は、確認したいことを全部まとめて一度に聞いてください。質問を小出しにしないでください。
- 直すついでに気づいた問題があれば、同じ回で直すか、直さないなら最後に「気づいた点」として挙げてください。次の往復に持ち越さないでください。

## 直す前に一言

- 作業を始める前に、何を変えるかを一文で述べてください。長い計画を書かないでください。
- 触るファイルと、その中のどのブロックを触るかを挙げてください。
- 指示の内容が制約に反する場合、既存の動きを壊す場合、指示があいまいで解釈が二つ以上ある場合は、この時点で指摘してください。作り終えてから指摘しないでください。

## 直したあとに確認手順

変更が終わったら、必ず最後に動作確認の手順を書いてください。次の三点を含めてください。

1. 何を開くか（`output/meeting-organizer.html` をブラウザで開き直す、など）
2. 何を入力するか（`docs/議事録_20260710_定例.md` を貼り付ける、など。どのダミー議事録を使うかまで書いてください）
3. どうなっていれば成功か（画面のどこに何が出れば正しいか）

あわせて、この変更で壊れた可能性がある既存の機能を挙げ、その確認方法も書いてください。

## バックアップ

- 修正を始める前に、直前の状態を `output/meeting-organizer_bk.html` としてコピーしておくよう受講者へ伝えてください。すでにバックアップがある場合は上書きするかどうかを確認してください。
- 変更の規模が大きくなりそうな場合は、着手前にその旨を伝えてください。

## 出力の量

- 変更のたびに HTML の全文を出力しないでください。変更した箇所と、その前後が分かる範囲だけを示してください。
- ファイルを直接書き換えられる場合は書き換え、応答には変更点の説明だけを書いてください。
