課題本文の「実測」を計画の前に踏み直す段が無く、4 束すべてで設計の途中に誤りが出た

[takemi-ohama]

何を見つけたか

課題の本文に「実測」として書かれた値が誤っていることが常態だった。
devbasex/devbase の v3.7.0 は 6 束・12 本の Pull Request で通したが、設計の束 4 つすべてで
issue 本文の実測が誤っており、設計または実装の途中で初めて分かった。

課題	本文の記述	実際
devbase#161	「直し方（検証済み）」として fontconfig の設定を全文で掲載	その設定は serif:lang=zh-cn と Arial:lang=zh-cn を壊す。中国語・韓国語を明示したときのフェイスを保つはずの match target="pattern" が、Arial の指定まで CJK へ引き寄せる
devbase#188	「見出しだけを変えるなら、差し替えるのは 2 か所で足りる」	実際は 5 か所
devbase#192	「cmd_scale は compose_env() が適用されない」	cmd_scale だけでなく cmd_login にも適用されていなかった
devbase#203	「syncer が唯一の入口」	env import も projects/ にディレクトリを作る

誤りの種類が 4 件とも違う。 検証したつもりの設定（#161）、影響範囲の数え落とし（#188、#192）、
入口の見落とし（#203）である。1 つの原因ではなく、起票の時点の調査が
「症状を再現するところまで」で止まり、修正の範囲までは確かめていないという共通の形を持つ。

どこで見つけたか

devbasex/devbase の v3.7.0 の 4 束（PLAN63 / PLAN64 / PLAN65 / PLAN66）の設計と実装。
各束の設計のフェーズが、issue 本文を入力として読んだ時点で食い違いを見つけている。

現在の手順では、この再実測を求める場所が無い。

Skill	何をするか	課題本文の実測を確かめるか
requirements-design	受け入れ条件を作る	課題本文を入力として読むが、実測の再現は求めない
implementation-plan	計画を作る	「目的と非目的」を決める。実測の再現は求めない
investigation-rules	調査レポートの書き方	書く側の規則で、読む側が確かめる段を持たない
design	データ構造と契約を決める	進む前に突き合わせる対を持つが、対象は設計の内部

なぜこの変更の範囲外なのか

v3.7.0 の 8 課題は devbase 本体の不具合と文書を対象にしており、Skill の手順は対象外である。

直さないと何が起きるか

• 誤った実測を前提に設計を書き、設計レビューか実装で初めて崩れる。4 束すべてで
  手戻りが起きた
• 設計フェーズの成果物を規約化する Skill を作る #161 のように「検証済み」と明記された設定をそのまま採ると、直したつもりで別の言語を
  壊す。 今回は設計のフェーズが気づいたが、気づかなければ配布まで通る
• 影響範囲の数え落とし（複数の Pull Request をまとめてマージした後、版を上げる担い手と時期が決まっていない #188 の 2 か所 → 5 か所）は、受け入れ条件の粒度まで誤らせる

直し方の案

案	内容
A	requirements-design（または implementation-plan）に「課題本文の実測を 1 つずつ踏み直し、食い違いを issue へコメントで戻す」段を足す。踏み直した結果は受け入れ条件の入力になる
B	investigation-rules に、起票する側へ「修正の範囲（どのファイルの何か所か）まで数えて書く」を足す。書く側で防ぐ
C	課題本文の実測に「いつ・どの版で測ったか」を必須にし、版が変わったら再実測を求める

A は読む側、B は書く側である。4 件の誤りの種類が違うため、片方だけでは防げない可能性が高い。
A を先に入れて、踏み直しで見つかった食い違いの種類を溜めてから B を決めるのがよい。

入れる場所

• 段は requirements-design に足す（案 A）。今の requirements-design/SKILL.md に「LLM に残る判断」の節は無く、手順（### 0〜### 7）のどこへ足すかは着手の時点で決める。踏み直しそのものは読んで確かめる判断で、
  スクリプトには移らない
• 踏み直した結果（実行したコマンドと出力）は、基盤: 検証の証跡を積む evidence.py と、テストの実行方法を返す detect-test-runner #853 の evidence.py で証跡として残す
• implementation-plan / plan-to-spec / requirements-design / design: 雛形と構造の検査を doc-check の呼び出しにする #872（requirements-design / implementation-plan の手順のスクリプト化）は閉じている。同じ Pull Request で入れる縛りは無い

関連

• implementation-plan / plan-to-spec / requirements-design / design: 雛形と構造の検査を doc-check の呼び出しにする #872 — requirements-design / implementation-plan / plan-to-spec のスクリプト化
• 基盤: 検証の証跡を積む evidence.py と、テストの実行方法を返す detect-test-runner #853 — 検証の証跡を積む evidence.py

由来

devbasex/devbase の issue #161 / #160 / #188 / #192 / #195 / #203 / #208 / #209
（v3.7.0 の振り返り、PR devbasex/devbase#212）