Repository navigation
Neural Development Factory: NDF を Web UI で操作できる Software Factory のサービスにする #2168
Description
概要
NDF を Neural Development Factory として、Web UI から操作できる Software Factory のサービスにする。GitHub のリポジトリを取り込み、/ndf:development-workflow のスプリントを Web 上で並列に進め、進捗を見て、承認ゲートで判断できるようにする（Devin・Claude on the web に近い使い方）。
背景
今の NDF は、利用者の手元の CLI（Claude Code / Codex）で動くプラグインである。スプリントの進み具合は issue の本文・ボード・supervise.py の進捗ログに散らばり、承認ゲートでは利用者が CLI のセッションの前にいる必要がある。Web のサービスにすれば、複数のスプリントを並列に流し、進捗の一覧と承認を 1 か所で扱える。
方針（利用者の決定）
判断の基準としての文面は、マイルストーン「25 Neural Development Factory」の説明のスプリント MVV（2026-11-02）にある。
| 項目 | 決めたこと |
|---|---|
| プラグインとしての NDF | OSS のまま（今の plugins/ndf/ と配布の仕組みを変えない） |
| Web サービスのコード | OSS。ただしライセンスを切り離す可能性があるため、ディレクトリを明確に分ける（プラグインと同じ木に混ぜない） |
| セキュリティに関わるインフラ（CDK など） | 別の private リポジトリに置く。このリポジトリには置かず、課題もそちらで持つ |
| 実行の形態（2026-10-30 に追加） | アカウントごとに 3 つから選ぶ: ① 手元のランナー（利用者の環境で、利用者がログインした claude）・② キーの持ち込み（利用者の Anthropic API キーか、利用者の AWS アカウントの Bedrock）・③ サービスの Bedrock。claude.ai のログインをサービスが預かる形は、Anthropic の規約（Agent SDK の文書）が認めないため採らない |
| 課金 | サブスクリプション。③ を選んだアカウントだけ、AI モデルの token 課金（Amazon Bedrock の課金をそのまま上乗せする）を足す |
| プラン | Claude.ai に近い形: Free・個人 Pro・個人 Max・Team（standard / premium の席）。Free は ① と ② だけを選べる。月の token の上限は ③ のときだけ掛かる |
| 認証 | Amazon Cognito。Google と GitHub のログインに対応 |
| リポジトリの取り込み | GitHub のリポジトリを取り込んで開発を進められる |
| スプリントの並列 | /ndf:development-workflow のスプリントを並列で進められる |
| スプリントの一覧 | スプリントごとに、いまどのフェーズ（設計・実装・検査・取り込み・仕上げ）にいるかが一覧で分かる |
| スプリントの詳細 | 課題ごとの工程・Pull Request・CI・承認ゲートの状態など、進捗が見える |
| 通知 | 承認ゲートに達したら通知する。Slack への通知も設定できる |
| 操作性と UX（2026-11-02 に追加。以下 5 行は carul と同じ方針） | 機能の数より、迷わず速く操作できることを優先する。操作の手数と待ち時間を減らす変更を選ぶ |
| 画面先行 | UX の土台（画面の地図・部品・端末・オフラインの見せ方・国際化）→ 機能の画面をダミーデータで作り切る → API の中身をつなぐ、の順で作る。API の入出力は画面の 1 枚に合わせず機能から起こし、常に配列で受け渡す |
| オフライン利用 | スマートフォン・タブレットで操作でき、つながらないときも最後に受け取った一覧・詳細・承認資料を読める。端末に残すデータは暗号化する。承認の確定はオンラインでだけ行う |
| AI からも人と同じく使える | 画面で行えるすべての操作を API と MCP からも行える。画面も同じ API を通る。委任を明示する認証・人と同じ認可・追記だけの操作の記録を持つ。承認ゲートとレッドラインの承認は人だけが行う |
| 国や地域を越えて使える | 文言は国際化の仕組みで持ち、日時は UTC で保存して利用者の時刻帯で表示し、金額は通貨とともに扱う。まだ出ていない国の機能は先回りして作らない |
受け入れ条件（案。requirements-design で確定する）
- Web サービスのコードが、プラグインと分かれた 1 つのディレクトリの下にまとまっている。そのディレクトリを別ライセンスにしても、
plugins/と配布物（.claude-plugin/marketplace.json）が影響を受けない - CDK などのインフラのコードと認証情報が、このリポジトリに 1 つも無い
- Google か GitHub のアカウントで Cognito 経由でログインでき、プラン（Free / Pro / Max / Team standard / Team premium）ごとに使える量が分かれる
- 利用者が自分の GitHub のリポジトリを登録し、そのリポジトリで NDF のスプリントを始められる
- 1 つのアカウントで複数のスプリントを同時に流せる。一覧に、スプリントごとの今のフェーズが出る
- スプリントの詳細に、課題ごとの工程・Pull Request・CI の結果・承認ゲートの状態が出る
- 承認ゲート（設計 Pull Request のマージ・本番系へ届く操作）に達すると利用者へ通知が届く。Slack の通知先を設定でき、Web から承認すると工程が続く。承認ゲートの数は増やさない（2 つのまま）
- ③ を選んだアカウントで、使った Bedrock の token が利用者・チームごとに記録され、サブスクリプションの料金に上乗せして請求できる
- アカウントごとに実行の形態（①・②・③）を選べ、どの形態でもスプリントを流せる。① と ② ではサービスが Claude の token の費用を持たない
- 今のプラグインの利用者（CLI だけで使う人）の振る舞いが変わらない
子課題（2026-10-30 に分割を決定）
1 スプリント（1 版を 1〜2 日）と設計文書 1 本 1,000 行以下に収めるため、機能ごとに分ける。最初のスプリントは #2169（残りの前提）。2026-10-30 に #2171 を「contracts と受け口」（#2171）と「実行の制御とランナー」（#2186）の 2 本に分けた。同じ日に実行の形態を 3 つにし、① を #2189 に分けた（② と ③ は #2186）。
| 順 | 課題 | 受け持つ受け入れ条件 | 前提 |
|---|---|---|---|
| 1 | #2169 置き場・ライセンスの切り離し・全体設計（v10.25.0 で完了） | 1・2・9 | — |
| 2 | #2170 認証とプラン（v10.26.0 で配布。実環境のログインの確かめが残る） | 3・10（形態の値と選べる条件） | #2169 |
| 3 | #2171 contracts と進捗の受け口（閉じた） | 4・5（前半）の土台（factory/contracts/・進捗の受け口・実行ジョブの token の検証） |
#2169・#2170 |
| 4 | #2186 実行の制御とランナー（閉じた） | 4・5（前半）・10（② と ③） | #2170・#2171（contracts を使う） |
| 4 | #2172 一覧と詳細 | 5（後半）・6 | #2169 の契約（進捗の事象の形）。#2171 の実装の完了は待たない |
| 5 | #2173 承認ゲートの通知と Web からの承認 | 7 | #2171・#2186 |
| 5 | #2174 課金 | 8 | #2170 |
| 6 | #2189 手元のランナー（形態 ①） | 10（①） | #2170・#2171・#2186 |
| — | #2347 開発ループ・並行する実行の調整・ループの見え方（閉じた） | 5（並列で流す） | #2186 |
| — | #2382 UX の土台（画面の地図・部品・端末・オフラインの見せ方・国際化）（閉じた） | 方針の「操作性と UX」「画面先行」 | — |
| — | #2384 画面の操作を API と MCP からも行える（閉じた） | 方針の「AI からも人と同じく使える」 | — |
| — | #2383 つながらないときも一覧・詳細・承認資料を端末で読める | 方針の「オフライン利用」 | #2382 |
| — | #2439 オーガナイザー（同じリポジトリで並行する実行の配布と承認・問いの集約） | 5（並列で流す）・7 | #2347・#2189 |
| — | #2608 NDF の状態をサーバー側の DB で、ログを CloudWatch Logs で持ち、ECS のジョブをまたいで続ける（2026-11-06 に利用者が決定） | 4・5（承認の後の再開が続きから動く） | #2186・#2606（置き場の寿命の契約） |
範囲外（この issue では扱わない）
- CDK のスタック・ネットワーク・秘密情報の管理の実装（private リポジトリ側の課題にする）
- プラグイン側の配布の仕組みの変更
全体設計で決まったこと
#2169 の確定仕様 docs/specifications/ndf-factory-service-boundary.md が持つ。要点:
| 項目 | 決まったこと |
|---|---|
| サービスのディレクトリ | リポジトリの根の factory/。LICENSE はその中の 1 ファイルで、差し替えても配布物に影響しないことを境界の検査（scripts/check-service-boundary.py、CI の service-boundary-check）が守る |
| 実行基盤 | 実行ジョブ（ECS Fargate のコンテナ 1 つ分）。承認の依頼が出たら終わり、答えで新しいジョブを起こす。ランナーが NDF をマーケットプレイスから導入し、版をスプリントの開始で固定する |
| 進捗の正本 | ランナーの中の NDF が書く sprint.json・progress.jsonl を、ランナーが進捗の事象へ翻訳して追記だけで持つ。一覧・詳細・通知・課金はここから導く |
| 子課題の間の契約 | 実行ジョブの指示・進捗の事象の種類と受け口・承認の依頼の答えを読む経路。子課題は形を変えずに作り、変えるときは確定仕様を先に直す |
| 認証・アカウント・使える量 | #2170 の確定仕様 docs/specifications/ndf-factory-accounts-and-plans.md が持つ。他の子課題は factory/api/src/index.ts が export する resolveAccount・getLimits・judgeLimits・setPlan を使い、account_id は token に載せず経路から解決する。factory/ は npm の workspaces |
未決（子課題で決める）
- 決済の手段（Stripe など）と、Bedrock の使用量を利用者ごとに分ける方法（NDF Factory: サブスクリプションと Bedrock の token 課金 #2174）
🤖 Generated with Claude Code
Activity
Merge pull request #2190 from devbasex/docs/factory-exec-modes