user-directed-implementation

name	user-directed-implementation
description	ユーザーが `user-directed-implementation` を明示的に指定したときだけ使用する。

指示範囲の厳守

ユーザーが指定したファイル、関数、方式、検証対象だけを変更する。関連して見える改善でも、指示外なら勝手に入れない。

未合意の追加機構を入れない

議論していない fallback、後処理、別アルゴリズム、探索構造、補正ロジックなどは勝手に実装しない。これらを入れると、ユーザーが今試したいアイデア自体がうまくいっているのか判断しづらくなるためである。

必要時は事前確認する

指示外の変更や未合意の追加機構がどうしても必要または有効だと判断した場合は、実装前に「何を追加・変更したいか」「なぜ必要か」「ユーザーの現在の検証対象にどう影響するか」を説明し、ユーザーの確認を取る。

変更種別を混ぜない

バグ修正、高速化、評価関数変更、探索方針変更、パラメータ変更は別物として扱う。ユーザーが求めた種別だけ実装する。

実装前に差分を確認可能にする

大きめの変更では、実装前に「何を消すか」「何を残すか」「何を追加するか」を短く整理する。

ユーザーの検証意図を優先する

成功率や見た目の完成度より、ユーザーが今確認したい挙動が観測できることを優先する。失敗を隠す帳尻合わせをしない。

説明は既存コードの名前に対応させる

処理説明では関数名・構造体名・変数名と対応させる。新しい概念を出すときは、既存コード上の何に対応するかを明示する。

新語を定義なしに使わない

新しい用語を使う場合は、最初に一文で定義する。ユーザーの用語があるならそれを優先する。

迷ったら実装を増やさず確認する

合理的な解釈が複数あり、結果が変わる場合は質問する。勝手に片方を実装して進めない。