Verse

2課題

当初の計画は、十週で完全なデスクトップ統合開発環境を作り切って出荷するというものだった。これを投資家・エンジニアリング・プロダクトの三視点による外部批評に掛けたところ、その期間では出荷不可能と判定された。争点は工数だけではない。最初に届ける相手の順序と、どの形態から配り始めるかという配布経路も、批評を受けて入れ替えることになった。批評の結論を受け、ペルソナ順序と工程を全面的に組み替えることになった。この転換の経緯は、破棄せずに要件定義書の草案へ残してある。

3要件・制約

転換後に自分へ課した制約は三つある。第一に、最初の配布物は単体アプリではなく VS Code の拡張であること。ホストは Node の別プロセス、画面はウェブビューという二重の実行環境を前提に設計を組まねばならない。第二に、質感を安易に作らないこと。半透明の背後をぼかすだけの実装を規約で明文的に禁じ、背後の像を実際に歪ませる方式を要求した。第三に、モーション系ライブラリの重量に硬い上限を設け、超過したビルドを機械的に落とすこと。いずれも規約とビルドの側に置いた。

4設計

配布は二段階に分けた。第一段の拡張では、ホストとウェブビューの間を判別可能な合併型のメッセージ規約で結び、双方向の受け渡しを型で閉じる。第二段の Tauri デスクトップでは、Rust のシェルが rusqlite による埋め込みデータベースと FTS5 による全文検索索引を抱え、後から複製同期を載せられるスキーマを先に敷いておく。画面については、実装に着手する前に必ず Figma のデザインファイル側でノードを起こす手順を規約化した。

5技術選定理由

ガラスの質感は、スパイクで二案を同時に実装してから決めた。背後の像そのものを歪ませる案と、面の内部だけで完結させる案である。実測を経て、用途によって二案を使い分ける混成に落とした。配布物はバンドラで束ねず、ブラウザ自身が解決する読み込み経路のまま配ることにし、外部ライブラリは手元へ取り込んで固定した。

6実装

実装は拡張・デスクトップ・シェルの三層に分かれる。拡張側はホストとウェブビューの両方を持ち、デスクトップ側はウェブの実装の下に Rust のシェルを敷く。テストは各層に置き、その規模は本節末の計測に示す。ただし本稿が事実として扱うのは、独立に数えられたテストファイルの数までである。ケース数として流通している値は作業記録の自己申告であり、この検証では裏付けを取っていない。

テストファイル — main 304 / worktree 314（件数は自己申告）¹

7性能対策

性能については、測るより先に太らせない仕組みを置いた。モーション系のチャンクに硬い上限を設け、その値をビルド成果物から直接検証し、超えたらビルドを落とす。あわせて同じ経路で、そのライブラリが入口のチャンクへ混入していないことも確かめる。歪みに使う写像の生成には確保量の上限を入れた。これはレビューで、極端な入力では例外が投げられ「例外を投げない」という契約に違反するという重大度の高い指摘を受けての修正である。現在の消費率は本節末の計測に示す。

バンドル予算 — 115,324B / 120,832B = 95.44%²

8結果

レビューは本節末の計測のとおり多数回にわたり、人数の記録が残る回だけでも相当数のエージェントが入っている。加えて別系統の言語モデルによる独立した第二意見を複数回挟み、明示的に受容した一件を除き、重大度の高い指摘をゼロまで収束させた。本線は、実際に背後を歪ませるガラスの出荷まで到達している。ただし配布そのものは未達で、拡張は公開登録されていない — 発行者の識別子が仮の値のまま残っており、この状態では公開できない。

レビュー — 14 ラウンド（人数明記の 4 ラウンドで 72 エージェント）＋ Codex 独立第二意見 3 回³

9検証で判明した注意点

重大度の高い指摘が一件、明示的な受容として残っている。上下端の帯がポインタ操作専用で、キーボードによる中心選択の経路に乗っていないというものである。解決済みとしては扱っていない。

セキュリティ関連の改修は第一段のみが本線へ入っており、以降の段は変更要求が開いたままである。

テストのケース数は作業記録の自己申告であって実行結果ではない。またテスト実行スクリプトは同時期の別プロダクト側の資産であり、この案件の成果として数えていない。

10AI 支援の関与

AI の関与は主にレビュー側にあり、多数のエージェントによる並列レビューを繰り返した上で、別系統の言語モデルによる独立した第二意見を挟む運用を取った — 確保量の上限を欠いた欠陥もこの経路で見つかっている（実装の分担については一次記述がない）。