ウォーターフォール・スウォーム

ウォーターフォール・スウォームの全体像

ウォーターフォール・スウォーム（Waterfall Swarm）は、全体を先に設計し、設計をデータの持ち主ごとのブロックに分けて、AI のスレッドの群れで一斉に作るやり方です。ビーズビルディングでは、段 5（作る）がこのやり方そのものです。

設計図をブロックに分け、ブロックごとに統括（C）と開発のスレッド（T1〜）を置いて、波 1・波 2 の順に一斉に立ち上げます。B01 は土台と結合を持ち、T9 が PR を点検して入れる順に並べます。横断のスレッド E1〜E7 は、全部のブロックをまたいで見ます。

いちばん大事な決まり：時間の指示はない

全部を、今から同時に作ります。日付・週・段で待ちません。

このため、1 つのブロックが遅れても、ほかのブロックは止まりません。ブロックの間は約束の型（ブロックの間で渡すデータの型）でつながり、相手のコードの出来上がりを待たないからです。

役	数	受け持つこと
ブロックの統括	1 ブロックに 1 本	指示を配る・ブロックの間の依頼を振り分ける・進みをつかむ。コードは書かない
開発のスレッド	1 ブロックに 2〜7 本	画面からコアとデータまでを縦に持って作る。独立した作業はサブエージェントに分ける
品質と結合（T9）	ハイブに 1 本	PR を点検し、入れる順に並べる。main を見張り、壊れたら止める
横断のスレッド	ハイブに 7 本	全体の統括・セキュリティ監査・UI/UX・紹介とドキュメント・AI テスト・CI・外の PR

作る人と見る人を分けます。監査・UI/UX・AI テスト・CI は、作るスレッドとは別の横断のスレッドが受け持ちます。指摘は全体の統括を通し、持ち場の表で持ち主のブロックに返します。役の詳しい中身はスレッドと名札にあります。

先に決める：動かす場所・リポジトリ・アカウントの割り振り・モデルと考える量・始め方（波）・マージの範囲・GitHub の使い方・始める合図の 8 つを決めます（一斉に立ち上げる）。
設計する：ウォーターフォールの設計書と画面のキャンバスをそろえます。ビーズビルディングなら、作る前の門まで済んでいます。
ブロックに分ける：データの持ち主ごとに分け、約束の型の表と持ち場の表を作ります。既存のコードがあれば、再利用の地図も作ります（ブロックに分ける）。
指示書を作る：ブロックとスレッドの指示を、一つの元から作ります（指示書を一つの元から作る）。
用意する：ハブとコードのリポジトリ、プロジェクト、動かす場所を用意します。
1 本で試す：試しのスレッドを 1 本だけ動かし、許可のカードが出ないことを確かめます。
立ち上げる：統括から始め、波ごとに全部のスレッドを起こします（一斉に立ち上げる）。
毎日回す：統括・T9・横断のスレッドが回し、人は決めることと押すことだけをします（毎日の回し方と止まった時）。

用意と 1 本の試しが終わるまで、立ち上げに進みません。これまでの実例のつまずきは、ほとんどが「用意がそろう前にスレッドを始めた」ことから来ています。

1 つのハイブは、10〜20 のブロックに分けるのが目安です。画面の数が多い製品ほど、ブロックとスレッドは増えます。BeesBuild 自身は画面が多いので、27 のブロックで作ります。

作る段の長さは、試験を含めて約 1 か月が目安です。実績では、Geniam Time を 1 日で約 10 万行、Xroid Dev を 1 日で約 5 万行作りました（実績：1 日で 10 万行）。

マージの仕方は、リポジトリの開発の段階のモードで決まります。

モード	マージ
実験モード	人が一度承認した自動マージの決まりに合う PR を、BeesBuild が GitHub App の名前でマージする
試す人ありモード	自動でマージするのは、持ち場だけ・旗がオフ・危なくない PR だけ
運用モード	エンジニアがマージの机で 1 本ずつ押す

どのモードでも、AI はマージしません。本番の反映は、どのモードでも人が押します（PR の地図とマージ・公開と反映）。