データの形と土台から決める

処理を書く前に、データの形を決める。核になる型を早く定め、読み書きの経路をすべてたどり、主な経路に合う構造を選ぶ。後のすべての段で役立つもの（CI・lint・試験の仕組み・共有の型）は、機能より先に作る。

なぜ: データの形が合っていれば、その後のコードは自明になる。形を誤ったまま処理を積むと、直すときに処理ごと書き直す。先に置いた土台は、以降のすべての変更で効く。

適用する場面:

• 新しい解析や機能の、最初の関数を書こうとしたとき。
• 機能と、CI・試験の仕組みのどちらから手を付けるか決めるとき。
• 2 つの処理（並行する作業、常駐の処理と子の処理）が、同じファイル・同じ状態を読み書きしそうなとき。

やること:

• 型とデータの持ち方を先に書き、読み書きの経路を並べて、主な経路で無理が無いかを確かめる。
• 共有する前に「別の処理が同時にこれを変えたら何が起きるか」を問う。答えが「何も起きない」でなければ分ける。
• 共通化するのは構造（型・データモデル）で、似た行ではない。似た文が 3 つ並ぶ程度なら、早すぎる抽象より並べたままにする。
• 順番は、削る → 土台 → 機能、試験 → 修正。commit は小さく、目的を 1 つにする。

使わないとき: 1 回だけの集計や使い捨ての調査スクリプト。形を決める費用が、得るものを上回る。

確かめる例: 最初の commit が型・データ構造か土台（CI・試験）で、機能の commit がその上に載っている。共有する状態に、同時の変更への答え（分離・排他）がある。