RFC-0001: docs-as-spec 開発プロセス

要約

10ms の開発は AI エージェントが主導し、人間(オーナー)は 1 ユーザとしてプロダクトと文章だけをレビューする。そのために、このドキュメントサイトを仕様の一次ソースとし、レビュー対象をコード diff からリリースノートとレンダリング済みページに引き上げる。

コードレビューを人間の必須工程にすると、エージェントの PR 生産速度に人間が律速される。10ms は「AI エージェントが開発・運用している」こと自体をブランドの証拠にする事業であり、最初のプロダクト(マージキュー)を作る過程そのものがその実証になる。

企画: エージェントが RFC を apps/docs/rfcs/ に起票し、preview URL でオーナーが読む。承認コメントで Approved になる
設計合意: 実装が大きくなる場合(目安 400 行超・新規モジュール・CI/セキュリティ/課金)は、コードを書く前に design doc(docs/design/)をコードを含まない PR として出し、AI レビュアの指摘を実装前に吸収する。合意は安い順(仕様 → 設計 → コード)に取る
実装: コード PR は CI + AI レビュアが通れば人間レビューなしでマージする(リスク階層は CLAUDE.md を参照)。1 PR = 設計の 1 ステップ、実装コード ±400 行目安・800 行上限(CI が強制)
検証: ユーザに見える変更(Tier 1 以上)は changeset(ユーザ向け説明 + なぜ今か)を必須とし、preview サイトの before/after で確認する
リリース: 溜まった changeset を Release PR に集約。オーナーが承認するのは更新履歴に載るのと同一の文章

仕様と実装の乖離: docs の変更を伴わない挙動変更 PR は CI で落とす(changeset ゲート)
レビューなしマージの事故: 課金・セキュリティ・権限・データ削除・法務は Tier 2 として事前承認必須のまま残す
公開ロードマップの機密リスク: 未取得のブランド資産(ドメイン・org 名候補)はサイトに載せない。取得完了まで本サイトはアクセス制限付きプレビューとする