01 / 形状の差分

何が動いたかと、何が変わったかは同じではない。

形状の比較は、壁が移動した、開口が広がった、面積が変わったことを示せます。その証拠は必要ですが、設計判断の理由までは説明しません。

BIMのワークフローでは、人がコメント、課題管理、議事録、オブジェクト名によって失われた文脈を補っています。プロジェクトの履歴は、モデルと、その周囲にある会話へ分かれます。

02 / 意味の差分

コード自身に、文脈を語らせる。

.muroでは、用途、隣接、境界、通過が原本の記述です。そのためテキストの差分は、形状を再ビルドする前に、建築的な判断を示せます。

$ git diff -- before.muro after.muro
- space /L1/work office name:個室 use:exclusive
+ space /L1/work office name:共同制作室 use:common
+ boundary /L1/work /L1/court type:open

変更内容を読めます。個室を共同制作室へ変え、中庭との境界を開く。壁と開口の変更は、その判断から生まれる結果です。

03 / 意図をレビューする

判断と、その結果を一緒に確かめる。

レビューは意味差分から始め、ビルドを実行し、影響を受けた投影を確認できます。新しい用途は適切か。開いた境界は必要な性能を満たすか。動線、面積、囲われ方に予期しない変化はないか。

Gitは、永続的なコミット、ブランチ、変更者、比較を提供します。Koyuは、そこへ比較する価値のある建築的な内容を与えます。

04 / プロジェクトの記憶

理由の連続が、プロジェクトの記憶になる。

各コミットが読める設計意図を変更していれば、履歴はバックアップ以上のものになります。新しく参加した人やLLMが、判断の連続として読み直せるプロジェクトの記憶です。

コミットメッセージや議論も、引き続き重要です。コードは交渉、判断、設計という社会的な仕事を置き換えません。目標はもっと限定的です。形状の意味を人がコメントするまで、原本が沈黙したままにならないことです。

05 / Gitが解決しないこと

履歴がきれいでも、設計判断が正しいとは限らない。

明快な差分でも、よくない判断を記述できます。建築のレビューには、人、気候、法規、施工、費用、文化についての知識が必要です。Gitが与えるのは追跡可能性であって、正しさではありません。

この区別は大切です。約束したいのは自動的な合意ではありません。人とLLMが同じ読める変更について話し、その形状的な結果を再現できる原本です。