docs: define initial product requirements

docs/06-domain-extension-strategy.md

@@ -0,0 +1,56 @@
+# 个人品牌核心与行业扩展策略
+
+## 1. 目标
+
+产品长期服务的是“个人品牌经营者”，而不是某一个行业。不同职业可以有不同的服务字段和业务流程，但都建立在同一套品牌基础能力之上。第一版以餐饮摊主和私厨为试点，餐饮字段不能写死成所有预约都必须填写的字段。
+
+## 2. 三层模型
+
+### 品牌核心层
+
+所有行业共享：品牌资料、服务项目、作品/案例、预约或咨询、客户反馈、内容管理后台。
+
+### 行业配置层
+
+行业可以配置服务分类、预约字段、字段顺序和必填规则、预约说明、状态文案、作品分类和联系前需要收集的信息。
+
+示例：私厨需要人数、地点、预算、口味和忌口；摄影师需要拍摄类型、人数、地点、日期和交付需求；咨询师需要咨询主题、方式和可接受时段。
+
+### 行业流程层
+
+只有真实需求证明流程不同，才增加行业专属状态或步骤。第一版不实现流程编排，只使用通用预约状态和可扩展文案。
+
+## 3. 数据设计原则
+
+- 品牌名称、服务名称、客户联系方式、期望日期等高频字段保持结构化，便于校验和查询。
+- 行业字段使用受控扩展，不让前端提交任意键名。
+- 第一版可使用 `bookings.extra_data` JSON 存储行业字段；字段定义由后端配置决定。
+- 建议支持的字段类型：`text`、`textarea`、`number`、`date`、`select`、`multiselect`。
+- 暂不实现插件系统、行业代码复制和通用字段配置后台。
+
+未来可增加 `industry_profiles`、`booking_field_definitions`，并让每个品牌选择一个行业模板。模板只提供默认值，不能覆盖品牌已经修改的内容。
+
+## 4. 餐饮试点落地
+
+通用字段仍放在 `bookings`：称呼、联系方式、服务、期望日期、备注。餐饮字段放入受控扩展数据：
+
+```json
+{
+  "guest_count": 6,
+  "location": "杭州市西湖区",
+  "budget_range": "500-800",
+  "taste_preferences": ["家常", "微辣"],
+  "allergy_notes": "对花生过敏",
+  "dish_preferences": "希望有一道鱼和一道汤"
+}
+```
+
+第一版可以固定餐饮字段配置，不需要开发字段配置后台；但 API 必须校验字段名、类型和必填规则。
+
+## 5. 稳定的核心接口
+
+不同行业都应复用：获取品牌、获取服务和作品、提交预约/咨询、管理员处理预约、提交反馈、审核反馈。行业差异通过配置、扩展数据和状态文案表达。
+
+## 6. 决策规则
+
+新增行业需求时先判断：这是所有品牌需要的能力，还是行业字段；是否需要查询统计；流程是否真的不同；是否已有第二个真实客户验证；是否影响预约和支付边界。没有重复真实需求时，优先使用配置或 `extra_data`，不增加行业专用表和页面。