Merge pull request 'sync: 恢复 R6 旅程自包含性原则 — 前置条件禁止业务数据依赖' (#52) from sync/d8d-skills-20260419-142958 into master

Reviewed-on: http://gitea.d8d.fun/d8dfun/bmad-method-template/pulls/52

.claude/skills/d8d-dev/modes/journey/journey-definition.md

@@ -108,6 +108,10 @@
 
 **规则 3：前置条件必须明确且可验证**
 - 每个旅程必须写明"操作前系统/用户应处于什么状态"
+- 遵循**自包含性原则**：前置条件只限用户状态和系统配置状态，禁止业务数据依赖
+  - ✅ 允许：`用户已登录` / `用户已授权连接 TikTok`
+  - ❌ 禁止：`已有一个处理完成的视频` / `已有订单等待发货`
+- 所有业务数据必须通过 UI 操作创建，不得跳过
 - ❌ "用户提交申请"（什么用户？什么状态？）
 - ✅ "前置：用户已登录（有 token），且 organizer=null（无局头身份）"
 

.claude/skills/d8d-dev/modes/journey/journey-execution.md

@@ -186,7 +186,11 @@ curl 只用于补充数据验证（如确认数据库状态），**永远不能
    - browser_resize → 正确视口（小程序 375x812 / 管理后台 1440x900）
    - 读取旅程定义的前置条件
    - curl/API 验证前置条件（✅ 允许 curl）
-   - 前置条件不满足 → FAIL
+   - 检测到违规（前置条件包含业务数据依赖，违反 R6 自包含性原则）→ ❌ BLOCKED
+     - 不允许使用 curl 自动创建数据补全前置条件
+     - 必须要求旅程定义重写，补充完整的 UI 上传/创建步骤
+     - 旅程标记 FAIL，不进入执行阶段
+   - 前置条件不满足且不违规 → FAIL
 
 2. 执行阶段（按用户视角步骤逐一执行 — ⛔ 只能用 Playwright）:
    - browser_navigate → 起始页（自然入口）（⛔ 禁止用 curl 替代）

.claude/skills/d8d-dev/rules/journey-authenticity-rules.md

@@ -135,7 +135,67 @@ grep -rn "import.meta.env.DEV\|process.env.NODE_ENV\|isDev" app/mini-program/src
 
 ---
 
-## 规则 R6：用户操作可行性兜底原则
+## 规则 R6：旅程自包含性原则
+
+### 核心原则
+
+旅程必须是**从用户原始状态开始的完整操作序列**，禁止依赖测试环境预先存在的数据。所有业务数据必须通过用户 UI 操作创建，不得在前置条件中假设数据已存在。
+
+### 规则细则
+
+#### ✅ 允许的前置条件：
+- 用户认证状态：`用户已登录` / `用户未登录` / `Admin 账号可用`
+- 系统配置状态：`平台连接配置已完成` / `账号已授权`
+
+#### ❌ 禁止的前置条件（数据依赖）：
+- ❌ `"已有至少一个处理完成的视频"`
+- ❌ `"已有订单"`
+- ❌ `"数据已导入"`
+- ❌ `"已有选中的封面"`
+
+### 为什么必须强制：
+- 真实用户首次使用系统时，确实没有任何预先存在的数据
+- 测试环境定期清零，无法保证数据持久存在
+- 缺失"上传→创建"步骤会导致这部分 UI 永远得不到验证
+
+### 检测方法
+
+1. 扫描旅程的"前置条件"段落
+2. 匹配模式：`已有` / `存在` / `包含` + `视频/订单/数据/内容/封面/平台`
+3. 如果发现数据依赖 → ❌ 违规，必须修复
+
+### 修复策略
+
+检测到违规 → 旅程必须从头重写：
+
+```
+原违规前置："用户已登录，已有至少一个处理完成的视频"
+    ↓ 修复
+1. 保留：用户已登录（允许）
+2. 补充完整 UI 步骤：
+   - 用户点击"上传视频"按钮
+   - 用户选择视频文件 → browser_file_upload
+   - 用户等待上传完成 → 等待处理完成
+   - 然后进入原有旅程步骤
+```
+
+### 例外场景（允许数据依赖）
+
+只有以下场景允许依赖预先存在的数据：
+1. **增量操作场景**：旅程本身就是"编辑已有 X"，且用户必须先创建才能编辑
+   - 示例："编辑用户头像"旅程，前置条件"用户已登录且已有头像"是允许的
+   - 但必须有另一条完整旅程覆盖"上传头像"操作
+2. **纯后台管理功能**：数据由批量导入产生，用户只做审核/审批操作
+3. 例外必须标注：`⚠️ 例外：本旅程是编辑操作，"上传创建"由另一条旅程覆盖`
+
+### 通过标准
+- 前置条件仅包含用户状态和系统状态
+- 不包含业务数据依赖
+- 所有业务数据必须通过用户 UI 操作创建
+
+---
+
+## 规则 R7：用户操作可行性兜底原则
 
 > **⛔ 通用规则，不需要为每种操作类型单独定义子规则。**
 
@@ -268,7 +328,7 @@ uni.showToast({ title: "验证码已发送", icon: "success" })
 
 ---
 
-## 规则 R7：约束声明必须与代码实际行为一致
+## 规则 R8：约束声明必须与代码实际行为一致
 
 > **⛔ 通用规则，检测旅程描述和页面 UI 文案中的约束声明与代码实际验证逻辑的不一致。**
 
@@ -356,7 +416,7 @@ A 和 B 均不满足 → 普通 FAIL #12 (ENV-ADAPT) → 按提示补填继续
 
 ---
 
-## 规则 R8：页面/视图覆盖深度（⛔ 强制）
+## 规则 R9：页面/视图覆盖深度（⛔ 强制）
 
 ### 核心原则
 
@@ -448,7 +508,7 @@ A 和 B 均不满足 → 普通 FAIL #12 (ENV-ADAPT) → 按提示补填继续
 ## 自动校验执行流程（定义和验证通用）
 
 ```
-步骤 1：逐规则校验（R1 → R2 → R3 → R4 → R5 → R7 → R8）
+步骤 1：逐规则校验（R1 → R2 → R3 → R4 → R5 → R6 → R7 → R8 → R9）
   ↓
 步骤 2：汇总结果
   ├── 全部 PASS → 返回校验通过