full-stack-doc

プロダクトドキュメント標準（full-stack-doc v3.0）

PartMe / Octo シリーズに準拠した、固定のディレクトリ構成と命名規則を適用します。すぐにコピーして使える Markdown テンプレートは templates/ にあります。詳細なファイル対応表と規則については、references/structure.md を参照してください。

---

1. 使用する場面

• プロダクトドキュメント用リポジトリを作成または初期化する
• Octo* または PartMe プロジェクトのドキュメントツリーを作成する
• 既存のリポジトリを監査し、PartMe ドキュメント標準に準拠させる
• 命名規則に合わせてドキュメントを生成またはリネームする
• partme-docs/ の内容をテンプレート構成に合わせる
• ルートレベルの計画ドキュメント 10 点を作成または拡充する

---

2. プレースホルダー

プレースホルダー	意味	例
{Name}	プロダクト／ブランド名	OctoEcom、OpenMem
{Name-Open}	オープンソース版の名前（デュアルトラックの場合）	OpenEcom、OpenMem
{V}	バージョンディレクトリ名	V1、V2
{模块简称}	モジュールの略称	登录页、设备中心
{YYYY-MM-DD}	日付のプレースホルダー	2026-03-27
{姓名}	作成者／レビュアー名	张三
{组织}	組織名	PartMe

ファイル名と内容の両方でプレースホルダーを置き換えてください。ルートには 6、 のファイルを 1 つだけ置きます。旧ファイル 6、详细功能清单 は 10、功能菜单与版本规划 に統合されています。

---

3. ドキュメント構成

3.1 4 層構造

{产品名}/
├── 1、{Name}-命名与品牌说明.md          ─┐
├── 2、{Name}-术语表与词汇表.md          │
├── 3、{Name}-市场与商业分析.md          │
├── 4、{Name}-技术与可行性分析.md        │ Root (10) — 产品级，与版本无关
├── 5、{Name}-技术方案与路线.md          │
├── 6、{Name}-产品与版本规划.md          │
├── 7、{Name}-领域模型设计.md            │
├── 8、{Name}-系统架构设计.md            │
├── 9、{Name}-视觉与交互DNA规范.md       │
├── 10、{Name}-功能菜单与版本规划.md      ─┘
│
├── V1/                                   ─┐
│   ├── 1、{Name}-需求调研文档-V1.md      │
│   ├── 2、{Name}-需求分析文档-V1.md      │
│   ├── 3、{Name}-系统架构设计-V1.md      │ Version (7) — 版本级实施文档
│   ├── 4、{Name}-功能与界面规划-V1.md    │
│   ├── 5、{Name}-PRD文档-V1.md           │
│   ├── 6、{Name}-功能菜单与版本规划-V1.md│
│   ├── 7、{Name}-UI设计说明-V1.md        │
│   │                                     ─┘
│   ├── 1、{模块A}/                       ─┐
│   │   ├── {Name}-{模块A}-PRD-V1.md      │ Module (3) — 可选，按模块
│   │   ├── {Name}-{模块A}-Stitch设计提示词.md │
│   │   └── {Name}-{模块A}-UI设计说明-V1.md    ─┘
│   └── ...
│
├── 其他/                                 ─┐
│   ├── 1、技术细分模板.md                │
│   ├── 2、功能提测模板.md                │ Delivery (5) — 可选，研发交付
│   ├── 3、测试结果模板.md                │
│   ├── 4、上线通知模板.md                │
│   └── 5、项目运维模板.md                ─┘
│
├── 技术调研/                             ── 技术调研、协议分析（版本无关）
└── assets/                               ── 图片、附件等

3.2 スコープの概要

スコープ	数	テンプレート	命名パターン
ルート	10	templates/root/	{序号}、{Name}-{文档名}.md
バージョン（{V}/）	7	templates/version/	{序号}、{Name}-{文档名}-{V}.md
モジュール（任意）	モジュールごとに 3	templates/module/	{Name}-{模块简称}-{类型}-{V}.md
デリバリー（任意）	5	templates/delivery/	コンテキストに依存

3.3 ルートのドキュメント 10 点 — 作成順序

ドキュメント間には厳密な上流・下流の依存関係があります。作成時は次の順序で進めてください。

flowchart LR
    D1["1、命名与品牌"] --> D2["2、术语表"]
    D2 --> D3["3、市场分析"]
    D3 --> D4["4、可行性分析"]
    D4 --> D5["5、技术方案"]
    D5 --> D6["6、版本规划"]
    D6 --> D7["7、领域模型"]
    D7 --> D8["8、系统架构"]
    D8 --> D9["9、视觉DNA"]
    D6 --> D10["10、功能菜单"]
    D9 --> D10

番号	ドキュメント	主な入力	主な出力	対応する Mermaid タイプ
1	命名とブランドの説明	プロダクトビジョン	ブランドの統一方針、境界	graph LR（ブランド関係）
2	用語集と語彙集	Doc 1 のブランドポジショニング	統一された用語	なし（表のみ）
3	市場・ビジネス分析	Doc 1 のポジショニング＋外部データ	TAM/SAM/SOM、競合、価格設定	quadrantChart / funnel
4	技術・実現可能性分析	Doc 3 の機会＋Doc 5 の初期選定	実現可能性の結論、リスク	flowchart / sequenceDiagram
5	技術方針とロードマップ	Doc 4 の結論	技術スタック、ADR、マイルストーン	flowchart / gantt
6	プロダクト・バージョン計画	Doc 3 のビジネス＋Doc 5 のロードマップ	バージョンマトリクス、価格設定、リリース戦略	graph / timeline
7	ドメインモデル設計	Doc 2 の用語＋Doc 6 の機能境界	境界づけられたコンテキスト、集約、イベント	classDiagram / graph TB
8	システムアーキテクチャ設計	Doc 5 の技術スタック＋Doc 7 のドメイン	レイヤー構成、データフロー、デプロイ	flowchart / sequenceDiagram
9	ビジュアル・インタラクション DNA 規範	Doc 1 のブランド特性	色、フォント、コンポーネント、アニメーション	flowchart（ページ構成）
10	機能メニューとバージョン計画	Doc 6＋Doc 8＋Doc 9	ナビゲーション、ルーティング、機能一覧、優先度	mindmap / pie / flowchart

---

4. スキャフォールディングの手順

Step 1 — ルートのドキュメント

templates/root/ のファイル 10 点をすべてプロジェクトのルートにコピーします。各ファイル名の {Name} を置き換えます。

# Example: OctoEcom
for f in templates/root/*.md; do
  name=$(basename "$f" | sed 's/{Name}/OctoEcom/g')
  cp "$f" "partme-docs/18、OctoEcom/$name"
done

Step 2 — バージョンのドキュメント

{V}/（例：V1/）を作成します。templates/version/ のファイル 7 点をコピーします。ファイル名と内容の {Name} および {V} を置き換えます。

Step 3 — モジュールのドキュメント（任意）

機能モジュールごとに {V}/{序号}、{模块名}/ を作成します。templates/module/ のファイル 3 点をコピーします。{Name}、{模块简称}、{V} を置き換えます。

例（OctoEcom V1 の商品収集）：

V1/1、商品采集/
├── OctoEcom-商品采集-PRD-V1.md
├── OctoEcom-商品采集-Stitch设计提示词.md
└── OctoEcom-商品采集-UI设计说明-V1.md

Step 4 — デリバリーのドキュメント（任意）

templates/delivery/ を 其他/ または専用のデリバリーフォルダーにコピーします。{Name} と日付を置き換えます。

Step 5 — 特殊ディレクトリ

技術調査用に 技术调研/ を、標準外のドキュメント用に 其他/ を作成します。demo/、assets/、.stitch/ などのディレクトリは変更しません。

Step 6 — 検証

検証チェックリスト（セクション 7）を実行します。

---

5. 品質基準

5.1 コンテンツの深度ベンチマーク

OctoEcom と OpenEcom の本番ドキュメントに基づきます。

ドキュメント	目標行数	Mermaid 最低数	表の最低数	主要な品質指標
1、命名とブランド	100–120	1	2	ブランド関係図、オープン版／商用版の比較表
2、用語集	100–160	0	8+	レイヤー／ドメイン別分類、中国語・英語対照、略語
3、市場分析	160–220	1–3	10+	TAM データソースの注記、SWOT 表、競合マトリクス
4、実現可能性分析	180–230	2–3	10+	実現可能性の評価凡例、階層別評価、リスク総覧表
5、技術計画	260–400	3–4	9+	コード例、Gantt ロードマップ、デプロイトポロジー
6、バージョン計画	200–340	2–3	5+	バージョン機能マトリクス、価格表、リリース戦略
7、ドメインモデル	300–410	7–9	7+	集約ごとの classDiagram、イベント表、リポジトリーインターフェース
8、システムアーキテクチャ	400–510	7–14	9+	階層別 subgraph、シーケンス図、状態遷移図
9、ビジュアル DNA	250–300	0–1	12+	ASCII ワイヤーフレーム、CSS 変数、色値の表
10、機能メニュー	400–560	3–5	20+	全体像の mindmap、機能一覧、優先度の集計

5.2 共通のドキュメント構成

各ルートドキュメントには、以下の標準構成を必ず含めてください。

ドキュメントの冒頭:

# {Name} 文档标题

> **文档说明**：一句话说明文档用途与范围。
>
> **版本**：V1.0.0
> **最后更新**：{YYYY-MM-DD}

ドキュメントの末尾:

---

**文档版本**：V1.0.0
**创建日期**：{YYYY-MM-DD}
**最后更新**：{YYYY-MM-DD}
**文档状态**：✅ 待评审

5.3 書式規則

要素	規則
章番号	## N. を最上位、### N.M を下位に使用し、階層は 3 層以内にします
表の配置	:--- を使用して左揃えにします
実現可能性の評価	✅ 実現可能性：高 / ⚠️ 実現可能性：中 / 🔴 実現可能性：低
優先度	P0（必須）/ P1（重要）/ P2（希望）/ P3（任意）
バージョンラベル	🆓 無料 / 👤 個人 / 👥 プロ / 🏢 エンタープライズ
状態マーク	✅ 実装済み / 🔧 開発中 / ⏳ 計画中 / ❌ 実装しない
Mermaid	各図の前後に空行を入れます。図の種類は内容に合わせます（3.3 の対照列を参照）
コードブロック	言語を明記します（typescript/go/bash/yaml/sql）
中国語と英語の混在	中国語と英語／数字の間にスペースを入れます：OpenAI 模型

5.4 相互参照の規則

• Doc 3 の関連ドキュメントには Doc 1（ブランドの境界）と Doc 5（技術的な実現可能性）へのリンクを含めます
• Doc 5 の Gantt の日付は、Doc 6 のバージョンマイルストーンおよび Doc 10 のリリースペースと一致させます
• Doc 7 の集約名は Doc 2 の用語集で定義します
• Doc 8 の階層名は Doc 5 の技術選定と一致させます
• Doc 10 の機能一覧に記載するバージョンは、Doc 6 のバージョンマトリクスと一致させます

---

6. 注意点

• バージョンフォルダー内の連番 1–7 は、7 件の標準ドキュメント用に予約されています。標準外のドキュメントには 8+ を使用するか、其他/ に配置してください。
• ルートにある 6、 の番号を持つファイルは1 つだけです（製品とバージョン計画）。詳細な機能一覧は 10、機能メニューとバージョン計画 に含まれています。
• ユーザーから明示的な依頼がない限り、特別なディレクトリ（demo/、assets/、.stitch/、stitch_*、实施指南/）を再編成しないでください。
• 納品用テンプレートは任意であり、ルートレベルの標準連番には含まれません。
• 製品がオープンソースと商用のデュアルトラック（例：OpenEcom/OctoEcom）を採用する場合、各トラックに完全な 10 件のドキュメントセットを用意し、相互参照を設定します。

---

7. 検証チェックリスト

Doc Validation:
- [ ] Root contains exactly 10 standard files (1–10)
- [ ] Each file starts with H1 + blockquote doc description
- [ ] Each file ends with version/date/status footer
- [ ] ## section numbering is sequential (no gaps, no duplicates)
- [ ] ### sub-sections use parent number prefix (e.g., ## 3 → ### 3.1)
- [ ] Mermaid diagrams render without syntax errors
- [ ] Cross-document references resolve to existing files
- [ ] Timeline dates are consistent across Doc 3, 5, 6, 10
- [ ] Terminology matches Doc 2 definitions
- [ ] Version folder contains exactly 7 standard files with {V} suffix
- [ ] Module folders have PRD / Stitch / UI triplet (if applicable)
- [ ] 技术调研/ and 其他/ do not contain root-level standard docs
- [ ] No sequence numbers 1–7 used for non-standard docs in version folders

---

8. テンプレート一覧

テンプレート	場所	行数	Mermaid	主なセクション
命名とブランドの説明	templates/root/1、命名与品牌说明.md	~120	1	ブランドの位置付け、命名の由来、製品の境界、コア公式、ブランドファミリー
用語集と語彙集	templates/root/2、术语表与词汇表.md	~150	0	ドキュメント情報、製品／アーキテクチャ／ビジネス／プラットフォーム／ガバナンス用語、略語
市場・ビジネス分析	templates/root/3、市场与商业分析.md	~220	3	市場機会、TAM/SAM/SOM、競合マトリクス、SWOT、ビジネスモデル、価格設定
技術・実現可能性分析	templates/root/4、技术与可行性分析.md	~230	3	階層別評価、セキュリティとコンプライアンス、性能と拡張性、リスク総覧表、結論
技術計画とロードマップ	templates/root/5、技术方案与路线.md	~300	4	技術選定、階層別設計、ADR、段階別ロードマップ、デプロイ、監視
製品とバージョン計画	templates/root/6、产品与版本规划.md	~240	3	製品の位置付け、バージョンマトリクス、ロードマップ、価格設定、リリース戦略、成功指標
ドメインモデル設計	templates/root/7、领域模型设计.md	~350	9	戦略設計、ユビキタス言語、集約設計、ドメインイベント、リポジトリーインターフェース
システムアーキテクチャ設計	templates/root/8、系统架构设计.md	~400	8	階層型アーキテクチャ、DDD/COLA、データフロー、セキュリティ、デプロイ、拡張メカニズム
ビジュアル・インタラクション DNA 規範	templates/root/9、视觉与交互DNA规范.md	~280	1	デザイン原則、色彩、フォント、レイアウト、コンポーネント、アニメーション、ダークモード、アクセシビリティ
機能メニューとバージョン計画	templates/root/10、功能菜单与版本规划.md	~450	5	全体像、メニュー構成、機能の詳細、バージョンごとの機能分布、ユーザージャーニー、機能一覧

---

9. 関連スキル

• documentation-builder: 一般的なドキュメント作成と書式の規則
• api-doc-generator: OpenAPI と API ドキュメントの生成