Repository navigation
NDF Factory: Web サービスの置き場とライセンスの切り離し、全体設計（実行基盤・進捗の正本） #2169
Description
親: #2168（Neural Development Factory）。最初のスプリント。 残りの子課題（#2170〜#2174）すべての前提になる。
依頼（原文）
ndfを「Neural Development Factory」として、WebUIで操作可能なSoftware Factoryサービスとして運営します。
- ndfのpluginsとしての利用はOSSのまま
- WebサービスのコードもOSS
- ただしCDKなどのセキュリティに関わるインフラ部分は別のprivate repositoryに(owner=volare)
- Webサービス部分はライセンスを切り離す可能性があるため、ディレクトリを明確に分離しておく
- Webサービスそのものはサブスクリプション+AIモデルToken課金(bedrockの課金をそのままオン)
- Cognitoによる認証(Google, Githubの認証に対応)
- Claude.aiと類似の認証・課金モデル(Free, 個人PRo, 個人Max, Team(standard/premium sear) etc)
- Devin, Claude Webと同様、github リポジトリをとりこんで開発を進められる
- /ndf:development-workflow のsprintを並列で進めることが可能。
- sprint一覧でそれぞれがどのフェーズを進めているかが化しかできる
- sprint詳細で進捗状況が可視化できる。
- 承認ゲートで通知。Slack通知も設定可能
この構想をissueを起こし、再起動して /goal /ndf:development-workflow で開発を進めてください
（書き手: 利用者、日付: 2026-10-30。会話の原文）
親＋機能別の子課題（#2168 を親に子課題 6 本。最初のスプリントは置き場・ライセンスの切り離し・全体設計）
（書き手: 利用者、日付: 2026-10-30。分け方の問いへの回答）
この課題が受け持つのは、原文のうち「WebサービスのコードもOSS」「CDKなどの…インフラ部分は別のprivate repositoryに」「ライセンスを切り離す可能性があるため、ディレクトリを明確に分離しておく」「ndfのpluginsとしての利用はOSSのまま」の 4 つと、残りの項目を実装するための全体設計である。
起票者の推定
| # | 条件 | 推した出所 | この要求での扱い |
|---|---|---|---|
| S1 | 別ライセンスにしても plugins/ と .claude-plugin/marketplace.json が影響を受けない |
原文「ライセンスを切り離す可能性があるため、ディレクトリを明確に分離」 | 受け入れ条件 1・2 |
| S2 | インフラのコードと認証情報が無いことを CI が確かめる | 原文「CDKなどの…インフラ部分は別のprivate repositoryに」。手で守る約束は崩れるため機械で見ると推した | 受け入れ条件 4 |
| S3 | CLI だけで使う人の振る舞いが変わらない | 原文「ndfのpluginsとしての利用はOSSのまま」 | 受け入れ条件 5 |
| S4 | 全体設計で実行基盤・進捗の正本・決済の手段を決める | #2168 の「未決」の節（起票者が書いた） | 受け入れ条件 6（決済の手段は #2174 の設計へ回し、ここでは課金の境界だけ） |
| S5 | フェーズの名前を「設計・実装・検査・取り込み・仕上げ」にする | #2168 の方針の表（起票者が supervise.py のフェーズから当てた） |
含まない（#2172 で決める） |
| S6 | ライセンスは当面 MIT のまま、切り離すのは後で | 原文「切り離す可能性がある」（今切り離すとは書いていない） | 前提 1 |
目的
- Web サービスのコードを、ライセンスを差し替えてもプラグインの配布に何も起きない 1 つのディレクトリにまとめる
- インフラと秘密がこのリポジトリへ入らないことを、人の注意でなく機械で守る
- NDF Factory: Cognito の認証（Google・GitHub）とプランごとの利用量 #2170〜NDF Factory: サブスクリプションと Bedrock の token 課金 #2174 が互いに食い違わずに並列で進められるよう、サービス全体の形（構成要素・実行基盤・進捗の正本・構成要素の間の契約）を先に決める
前提
- 前提 1: ライセンスの切り離しは、この課題では行わない。Web サービスのディレクトリには根と同じ MIT の
LICENSEを置き、差し替えはそのファイル 1 つ（と根のREADME.mdの案内）で済む形にする。切り離す時期と新しいライセンスは利用者が決める - 前提 2: Web サービスは NDF を配布物（マーケットプレイスから導入したプラグイン）として使う。
plugins/のファイルをパスで読み込まない。これで、プラグインの版と配布の規則（docs/versioning-and-distribution.md）がサービスにもそのまま当たる - 前提 3: CDK のスタック・ネットワーク・秘密の管理は private リポジトリ（owner =
volare）が持つ。この課題はそのリポジトリへ何も書かない。このリポジトリ側は、インフラへ渡す値（環境変数の名前など）の一覧を.env.exampleの形で持つだけにする - 前提 4: Web サービスのディレクトリの名前と置き場所、使う言語・フレームワークは設計で決め、ゲート 1 の承認資料に載せる
- 前提 5: 既存のテストの入力に、秘密の形をした偽の値がある（
plugins/ndf/scripts/tests/test_project_decl.py:22のAKIAで始まる値。2026-10-30 にgit grep -nE 'AKIA[0-9A-Z]{16}'で 1 件）。境界の検査はこれを許可の一覧で個別に除き、受け入れ条件 4 と 5 を両立させる。許可の一覧はファイルと値の組で持ち、ディレクトリごと除かない - 前提 6:
.env.example（値を持たない雛形。既存はplugins/mcp/mcp-dbhub/・plugins/mcp/mcp-redash/の 2 件）は受け入れ条件 4 の「.envの実ファイル」に当たらない
対象範囲
含む:
- Web サービスのディレクトリの作成（
README.md・LICENSE・.env.example・最小の雛形） - 境界の検査（下の受け入れ条件 2〜4）を CI へ足す
- サービス全体の設計文書: 構成要素、実行基盤（スプリントを動かすコンテナ・ジョブの単位、
supervise.pyのプランと進捗ログをどう Web へ渡すか）、進捗の正本、構成要素の間の契約、NDF Factory: Cognito の認証（Google・GitHub）とプランごとの利用量 #2170〜NDF Factory: サブスクリプションと Bedrock の token 課金 #2174 の境界 - 用語集へサービスの語を足す
含まない:
- 認証・プラン（NDF Factory: Cognito の認証（Google・GitHub）とプランごとの利用量 #2170）、取り込みと実行（NDF Factory: contracts と進捗の受け口 #2171）、一覧と詳細の画面（NDF Factory: スプリントの一覧（フェーズ）と詳細（工程・PR・CI・承認ゲート） #2172）、通知と Web からの承認（NDF Factory: 承認ゲートの通知（Slack を含む）と Web からの承認 #2173）、課金と決済の手段（NDF Factory: サブスクリプションと Bedrock の token 課金 #2174）の実装
- CDK のスタック・ネットワーク・秘密の管理の実装（private リポジトリ側）
- ライセンスの差し替え（前提 1）
- プラグインの配布の仕組みと版の規則の変更（MVV の P1 に当たる）
ドメインイベント
| # | イベント | 引き金 | 失敗したとき | 順序の前提 |
|---|---|---|---|---|
| E1 | Web サービスのディレクトリを作った | この課題の実装 | — | — |
| E2 | Pull Request で境界の検査が走った | develop 宛の Pull Request の作成・更新 |
検査が起動しない → 必須チェックが欠けてマージできない | E1 |
| E3 | 境界の違反を見つけて Pull Request を落とした | E2 で、plugins/ などからサービスのディレクトリへの参照・インフラのコード・秘密のどれかが見つかった |
見落とした → 受け入れ条件 4 のテストの入力で検出できることを確かめる | E2 |
| E4 | プラグインを配布した | リリース | サービスのディレクトリの変更が配布物に混ざる → 受け入れ条件 1 で検出 | E1 |
| E5 | サービスのディレクトリのライセンスを差し替えた（将来） | 利用者の決定 | 差し替えが plugins/ や配布物へ波及する → 受け入れ条件 2 で検出 |
E1 |
用語
| 用語 | 意味 |
|---|---|
| Neural Development Factory | NDF を Web UI から操作できる Software Factory のサービスとして提供するときの名前。プラグインとしての NDF と区別するときに使う |
| サービスのディレクトリ | Web サービスのコードを置く、プラグインと分けた 1 つのディレクトリ |
| 境界の検査 | サービスのディレクトリとプラグイン・配布物・インフラの境目が守られているかを CI で見る検査 |
| 実行基盤 | Web サービスからスプリントを動かす、コンテナとジョブの仕組み |
受け入れ条件
- 1. サービスのディレクトリの中のファイルを足しても消しても、
claude plugin validate .の結果と、各プラグインの配布物（.claude-plugin/marketplace.jsonのsourceが指す木）の中身が変わらない - 2.
plugins/の下と.claude-plugin/marketplace.jsonのどのファイルも、サービスのディレクトリを参照しない。参照を 1 つ足した Pull Request は境界の検査で落ちる - 3. サービスのディレクトリの
LICENSEを別の文面へ差し替えても、受け入れ条件 1・2 の検査と既存のテストが通る - 4. 境界の検査は、リポジトリの中に次のどれかがあれば落ちる: CDK などインフラの定義（
cdk.json・aws-cdk-libへの依存・CloudFormation / Terraform の定義）、秘密らしい値（AWS のアクセスキーの形・秘密鍵の PEM・.envの実ファイル）。それぞれを 1 つずつ入れたテストの入力で落ちることを確かめる - 5. 既存のテスト（
uv run --frozen --project . --all-extras pytest . -q -n 4）・claude plugin validate .・既存の CI の必須チェックが、この変更の前と同じに通る。プラグインの利用者の手順と振る舞いは変わらない - 6. 設計文書が次を決めている: サービスのディレクトリの名前と置き場所、構成要素とその間の契約、実行基盤（スプリントの実行の単位、
supervise.pyのプランと進捗ログを Web へ渡す経路）、進捗の正本、NDF Factory: Cognito の認証（Google・GitHub）とプランごとの利用量 #2170〜NDF Factory: サブスクリプションと Bedrock の token 課金 #2174 がそれぞれ受け持つ範囲と、互いに依存する契約 - 7. 設計文書が、ai-plugins の形（ブランチ名・テストのコマンド・配布の手段）を Web サービスの既定に埋め込まない。取り込むリポジトリごとの違いは、そのリポジトリの
.ndf/の設定で受ける（MVV の Value 5）
非機能の条件
| 大項目 | 条件 |
|---|---|
| 運用・保守性 | 境界の検査は 1 本のスクリプトで、手元でも CI と同じコマンドで走る。所要は 10 秒以内 |
| セキュリティ | このリポジトリに秘密・認証情報・インフラの定義を置かない（受け入れ条件 4）。.env.example は値を持たない |
影響
| 対象 | 影響 |
|---|---|
| 公開インタフェース | 変わらない（プラグインの Skill・hook・スクリプトの引数と出力は触らない） |
| データ | 無し |
| 既存の振る舞い | CI に境界の検査が 1 つ増える。プラグインの振る舞いは変わらない |
検証手段
| 項目 | 手段 |
|---|---|
| テスト | uv run --frozen --project . --all-extras pytest . -q -n 4（境界の検査のテストを含む） |
| 静的解析 | claude plugin validate .・境界の検査のスクリプト・python3 plugins/ndf/scripts/instructions-check.py --root . |
| 手動確認（マージ前） | 境界の検査が CI で必須チェックとして走り、違反を入れた検証用の Pull Request で落ちることを見る |
前提とする取り決め
| 項目 | 参照先 / 決めたこと |
|---|---|
| プロジェクト構造 | AGENTS.md の「マーケットプレイスの構造」。サービスのディレクトリは plugins/ の外に置く。境界の検査はリポジトリの検査なので scripts/（配布物でない側）に置く |
| コーディング規約 | AGENTS.md の「最小限のコード実装」。検査のスクリプトは既存の scripts/check-*.sh / .py の形に揃える |
| テスト戦略 | 境界の検査は、違反を 1 つずつ入れた一時ディレクトリを入力にした単体テストで担保する。.md の文言を照合するテストは書かない |
境界
| 区分 | 内容 |
|---|---|
| 常に行う | 既存テストと claude plugin validate . の実行、検査のスクリプトを書く前に使うコマンドの挙動を確かめる |
| 確認してから行う | サービスのディレクトリの名前・言語・構成要素の分け方（ゲート 1 の承認資料に載せる） |
| 行わない | private リポジトリへの書き込み、ライセンスの差し替え、プラグインの配布の規則の変更、#2170〜#2174 の実装の先取り |
未決
| 項目 | 誰が決めるか | 期限 |
|---|---|---|
| サービスのディレクトリの名前・言語・フレームワーク | 設計（ゲート 1 で利用者が承認） | #2169 の設計 Pull Request |
| ライセンスを切り離す時期と新しいライセンス | 利用者 | 決めない（この課題の範囲外） |
| 決済の手段（Stripe など） | #2174 の設計 | #2174 |
境界の検査を既存の必須チェックの job に入れるか、新しい必須チェックとして足すか（後者は ruleset の変更が要り、scripts/check-required-checks.py の突き合わせにも当たる） |
設計（ゲート 1 で利用者が承認）。ruleset の変更が要るなら、利用者がゲート 2 の承認資料で見て行う | #2169 の設計 Pull Request |
進行
モード: —
- 要求と受け入れ条件 — 2026-10-30 01:11
- 作業場所の用意 — 2026-10-30 04:13
- 設計 — 2026-10-30 01:16
- 素材の収集と出典の確定
- ドキュメント再構成
- ドキュメントレビュー
- 計画 — 2026-10-30 04:13
- 実装 — 2026-10-30 04:13
- 構造改善 — 2026-10-30 04:55
- 実装レビュー — 2026-10-30 05:22
- 完了判定 — 2026-10-30 04:29
- Pull Request — 2026-10-30 04:40
- 確定仕様化 — 2026-10-30 06:38
- 後片付け — 2026-10-30 06:34
- 配布 — 2026-10-30 06:00
- 体裁レビュー
- リリース後テスト — 2026-10-30 06:34
- 振り返り — 2026-10-30 06:46
- 棚卸し — 2026-10-30 06:47
🤖 Generated with Claude Code
振り返り: #2169 (comment)
Activity
Docs: #2169 の契約で、判断からの再開・事象の重複の判定・受け口の認証を決める
Docs: #2169 の契約で、答えの読み出しと gate.answered の受け付けを承認の依頼と照らす
Merge pull request #2175 from devbasex/design/issue-2169
Merge pull request #2177 from devbasex/feat/issue-2169-m2169
takemi-ohama commentedon Oct 30, 2026
振り返り（2026-10-30）
対象: issue #2169 / 設計 PR #2175 / 実装 PR #2177 / スプリント PR #2178 / リリース PR #2181
Neural Development Factory の最初のスプリントとして、Web サービスの置き場
factory/（LICENSE・README.md・.env.example・.gitignore）と、その境目を CI で見る境界の検査（scripts/check-service-boundary.py、ジョブservice-boundary-check）を作り、#2170〜#2174 が並列に進めるためのサービス全体の設計（構成要素・実行基盤・進捗の正本・構成要素の間の契約）を決めた。ndf v10.25.0 で正式版として出した。何が起きたか
cross-reviewを 3 ラウンド回した（major 7 件 → 5 件 → 0 件）。その後、承認ゲート 1 で利用者が GitHub の表示から mermaid の描画エラー 2 つ（subgraphの題の括弧・erDiagramの日本語の実体名）を見つけて差し戻した。設計の工程・3 ラウンドのレビュー・承認資料の組み立てのどれもこの構文エラーを見つけていない。リポジトリに mermaid の構文を解析する検査が無いためで、#2176 として起票済みpace: normalの工程を飛ばさずに通した。確定仕様化は normal のプランが持たないため、仕上げのフェーズへ移して通したgate-rejections.jsonl）に残っていなかった（gate-rejections.py countが 0 件）。手順はapproval-request.mdの「答えを記録する」とpace.mdの表にあるが、conductor が打っていない。振り返りの時点でgate-rejections.py recordで 1 行足したservice-boundary-checkを ruleset の必須チェックへ足すのは利用者の作業（設計の決定 11）。2026-10-30 15:40 JST 時点で ruleset「protect main and develop」に入っていないcontext window の大きさ
測れたのは仕上げのフェーズを動かした conductor のセッション 2 つだけである。設計・実装・配布のフェーズは
supervise.pyのプラン（claude -p）で動いており、この表に入っていない。割る候補: そのまま。2 つのセッションのうち 1 つが配布までの全フェーズを通しており、切り替えは中継の再起動で既に行っているworker を使いすぎ: そのまま。測った時点の worker は確定仕様化（設計 498 行の書き直しとコードの照合）の 1 件で、その後に棚卸しの調べ（6 件の本文と設計の突き合わせ）の 1 件を足した。どちらも supervisor の文脈に入れると読み込みが重く、ほかの工程（リリース後テスト・振り返り）と並べて進めるために分けた用語集の変化
ndf-factory承認ゲートの差し戻し
gate-rejections.py count --sprint .ndf/tmp/sprint-m2169/sprint.json: 関門 1 が 1 件・関門 2 が 0 件。MVV を見直すか
project-mvv.py signals（版 3）: 覆し 0 件（閾値 3）・判定できない 0 件（閾値 5）・続けて 0 回（閾値 3）・流出不具合 0 件（閾値 3）。どの兆候も閾値に届いていない。pace: normalで MVV 判定を承認に使っていないため、覆しはこのスプリントでは数えられない。無人の経路のため改訂するかの問いは conductor へ返す（推奨: 改訂しない。兆候が 0 件のため）。次に変えること
doc-checkのdiagrams）と CIdevelopment-workflowの手順（supervise.py/sprint-state.pyの続け方）途中で起票した課題
takemi-ohama commentedon Oct 30, 2026
スプリントの終わりの工程を通りました
Merge pull request #2184 from devbasex/docs/2169-spec