小さな時計に、9 層のゲートを敷いた理由
NeNe Clock — Java 21 / Swing のデスクトップ時計
枠も釦も無い小さなデスクトップ時計を、「意味ごとに正規の実装経路は 1 本、それを人の記憶ではなく機械が守る」という規律で作りました。見どころは時計そのものではありません。規律を機械化した層と、その機械が「テストは緑なのに壊れていた」ものを何件捕まえたかの記録です。
言語が変わっても、設計と品質ゲートは同じ形で通します。以下の数字はすべて検証リンク付きで、まだ機械で強制できていない項目も隠していません。
規律を機械化した 9 層
「core は壁時計を読めない」は、レビューで気をつけることではなくビルドの失敗にしてあります。forbidden-apis が JDK のメソッド署名を直接名指しできるからです。メソッド単位は forbidden-apis、パッケージ単位は ArchUnit——同じ規則を 2 か所で見張ることはしません。二重化すると、どちらが効いているのか分からなくなるからです。
sealed ＋ switch の網羅性now() / nanoTime() / Math.random() / 既定ゾーン・ロケールを名指しで禁止null の意味を 1 つに固定するdefault・文書整合）「テストは緑なのに壊れていた」4 件
ゲートを敷く価値は、通ったことではなく止まったことで決まります。全件、実行結果の引用つきで記録してあります。
determinism.txt をどのビルドも読んでおらず、証明が落ちて見えたのは別の束が偶然拾っていたから。System.nanoTime() や Instant.now() は素通りしていた。
見つけ方 次の作業に入る前に、別の API でもう一度わざと落としてみた
「落ちた」ではなく「何によって落ちたか」まで見ないと、証明にならない
Java 21 は可変フォントの軸を選べない。Font.createFont が通るかを見る検査は 30 件すべて緑のままだった。
見つけ方 窓を出して画面を見た
「読み込める」は「正しく描かれる」ではない
100pt で時刻が切れる／ポインタ位置によっては操作部が永久に出ない／色見本が寄る／チップが潰れる。
見つけ方 WSLg で窓を出し、Robot で操作して確認した
見た目に機械の検査は無い。だから「テストが緑だから動く」とは書かない
直すたびに悪化するか、変わらなかった。5 回目に刻みを 200ms から 30ms に落として 40 枚撮ったら、アプリの絵は一度も壊れていなかった。白は OS 側の合成層で入っていた。
見つけ方 直すのをやめて、観測できる状態を先に作った
直して悪化したら、それは修正ではなく診断。観測できないものを直そうとしない
AI と組んだときに、何を人がやったか
AI に書かせたことが売りではありません。売りは、規律を先に機械化しておいたので、AI の作業でも何が捕まったかを記録として出せることです。
出発点は別の AI と作った草案でした。内容は妥当でしたが、ほぼ全部が「レビューで気をつけること」です。そのままでは人の注意力に依存するので、ID を振って機械が強制する形に書き換えました。
初日に 71 規則。全部に機械強制の状態（active / 一部 / planned / 不能）を付け、正本は強制マトリクス 1 か所に置いて、文書と実装が食い違ったら merge を止める検査を入れました。
手を動かす前に案を並べて方向を決め、捨てた案も残しました。仕様の判断を 2 件覆していますが、覆した理由と捨てた選択肢は ADR に書いてあります。
ちらつきの件では「見てもらう」を 5 回挟みました。測れる状態を先に作っていれば 1 回で済んだ、と日報に書いてあります。AI と組んでも、この種の失敗は消えません。消えるのは、記録が残らないことの方です。
できていないこと
- コード署名なし（Windows で警告が出ます）。macOS 版の配布はしていません。
- 強制マトリクス 46 規則のうち、8 件は一部のみ・6 件は planned・1 件は機械では不能。依存の SHA-256 検証も未導入です。
- ストップウォッチとタイマーは未着手。MSI の上書きインストールとアンインストールは未確認です。
- 「見た目の機械検査は不能」＝目視の表でしか担保していません。
- そもそも 2 日間の成果であって、長期運用の証拠ではありません。