write-problem-description

name	write-problem-description
description	AtCoder Heuristic Contest の問題文を、貼り付けテキスト、スクリーンショット、公式抜粋から `problem_description.txt` に転記・整理する。公式の文言と節順をできるだけ維持し、画像がないと理解しづらい箇所だけ簡潔に補足する。

問題文転記

競技プログラミングの問題文を problem_description.txt に整理して保存する。原文の順序と wording を最大限維持し、画像依存の情報だけを最小限の補足で文章化する。

ワークフロー

1. 入力ソースを確認する

• ユーザーが貼ったテキストを優先し、画像は欠落部分の補完と図の説明把握に使う。
• 既存の problem_description.txt を読み、追記か全面更新かを決める。
• 判読できない箇所や与えられていない節は推測で埋めない。

2. 構成を揃える

• 公式ページの節順を維持する。
• 少なくとも次を検討する: 問題名、実行時間制限、メモリ制限、問題文、得点、入力、出力、入力生成方法。
• 数式や添字は Markdown / plain text に正規化する。例: t_i,j, p_i,j, (i,j)。
• 問題文本文では公式記号名を保持する。N, M は N, M のまま書く。
• 添字だけは h[i,j] のような配列表記にしてよい。
• 入力形式や列挙は、構造が崩れにくい書き方を選ぶ。必要ならコードブロックを使う。

3. 転記する

• 本文はできるだけ原文のまま書く。不要な要約や解説を混ぜない。
• 図や色に依存する説明は、画像がなくても通る短い文章を追加する。
• 追加説明は 補足: と明示し、画像や与えられた文面から確実に読める内容だけを書く。
• 既存メモと混在させる必要がある場合でも、問題文部分と考察部分を分離する。

4. notes/notations.md を更新する

• 問題文から主要な入力記号、座標、集合、スコア、制約、状態量を抽出する。
• notes/notations.md のテンプレ例を問題固有の記号へ置き換える。
• 公式記号名は保持する。N, M, S などの大文字小文字は Rust の命名規約より優先する。
• 添字は 0-based か 1-based かを明記し、実装・会話用には原則 0-based の a[i], h[i,j] 形式を使う。
• 問題文にない実装用の状態量は、state[g], X[p,g] のようにコードとの対応が見える名前にする。
• コード上の代表名、Rust の想定型、index 範囲・不変条件を分かる範囲で書く。
• 不明な型や命名は断定せず、未確定であることを明記する。
• TeX は数式構造だけに使い、コードフェンス内に入れない。
• 解法考察や仮説は notes/notations.md へ混ぜない。

5. 最終確認する

• 固有値、制約、座標系、移動記号、評価条件を見直す。
• 図の通り だけで終わる説明が残っていれば最小限補う。

しないこと

• 解法考察や推測を問題文へ混ぜない。
• OCR の不確実な箇所を断定しない。
• 画像にない情報を創作しない。
• 別ファイルを増やさず、ユーザー指定がなければ project root の problem_description.txt を更新する。