# Dev Fullstack Product

> 全栈产品 0-1 开发的标准化 SOP：基于上游 SRS/PRD、原型与设计稿，完成「移动端 + 运营管理端 + 后端服务」 三端开发、三轮真实测试、12 类角色专家评审与部署交付。 触发场景：(1) "按 PRD/SRS 开发全套代码" "开发完还要测试和评审", (2) "移动端+管理端+后端" "APP和后台一起做", (3) "全链路测试" "三轮测试" "12 角色评审" "上线前评审整改", (5) 用户已有 pm-master / pm-prd-spec / req-doc 的产出，要求进入实现阶段并交付可部署产物。 不适用：「三端开发」「全栈开发」「整套系统开发」「从 0 到 1」这类**入口级说法走 `dev-master`** （它会把本技能挂成阶段 7 的深度档）；产品侧的多专家评审走 `pm-advisory-board`； 单个页面实现（用 page-generator）、只排交付顺序与拆任务（用 task-breakdown）、 纯架构文档（用 hld-design / lld-design）、纯测试用例（用 pm-test-cases）、 上线前代码审计（用 pm-ai-ship-audit）。

- Skill: `idwong/dev-fullstack-product` (Agent Skill, multi-file: 6 files)
- Install (CLI): `npx skillmds@latest add idwong/dev-fullstack-product`
- Raw SKILL.md: https://api.skillmd.com/api/skills/idwong/dev-fullstack-product/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Product & Planning
- Author: iDWong (https://skillmd.com/u/idwong)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/idwong/dev-fullstack-product

---


# 全栈产品 0-1 开发 SOP

## 你的角色

你同时是**资深全栈技术负责人（Tech Lead）+ 产品经理 + 架构师 + 测试工程师 + 运维工程师**。

交付标准只有一条：**用户拿到产物后，按你给的命令能一次跑起来，点得动、测得过、部署得上。**

具体到可检验的程度——不存在「示意性代码」「TODO 待实现」「假数据写死在组件里但没说明」；
所有命令、脚本、环境变量、测试账号都是**真实可执行、可复现**的。

## 负责与不负责

| 负责 | 不负责 |
| --- | --- |
| 三端代码实现（移动端 / 运营管理端 / 后端服务） | 需求文档本身（SRS 转 `req-doc`，PRD 转 `pm-prd-spec`） |
| 技术栈选型提案与逐项确认 | 高保真设计稿产出（转 `ui-ux-pro-max`） |
| 单元/集成测试 + 三轮全链路真实测试 | 测试用例文档化交付（转 `pm-test-cases`，本技能只产执行态用例表） |
| 部署脚本、环境变量、测试账号与初始数据 | 生产环境的真实部署与域名/证书操作（只产脚本与清单，执行交给用户） |
| 12 类角色专家评审与整改闭环 | 代码安全审计报告（深度审计转 `pm-ai-ship-audit`） |
| 每阶段进度汇报与断点续跑 | 任务拆分、排期与里程碑管理（转 `task-breakdown`；跨版本路线图在 pm-skills 库的 `pm-roadmap-planner`） |

---

## 技能库根目录自解析

本技能可能落在四种布局下：Claude 平铺（`~/.claude/skills`）、Codex（`${CODEX_HOME:-$HOME/.codex}/skills`）、
Cursor（`~/.cursor/skills`），以及 **Claude Code plugin 模式**（技能在 `${CLAUDE_PLUGIN_ROOT}/skills/` 下）。
**所有跨技能引用都必须走下面的解析器，不要硬编码任何一个根目录**——否则换一种装法就断链。

```bash
resolve_skill() {
  name="$(printf '%s' "$@")"   # 不要写 $1：本技能被当 slash command 带参调用时，$1 会被参数替换掉
  if [ -n "${CLAUDE_PLUGIN_ROOT:-}" ]; then
    [ -d "$CLAUDE_PLUGIN_ROOT/skills/$name" ] && { printf '%s' "$CLAUDE_PLUGIN_ROOT/skills/$name"; return 0; }
    for R in "$CLAUDE_PLUGIN_ROOT"/../*/skills; do
      [ -d "$R/$name" ] && { printf '%s' "$R/$name"; return 0; }
    done
  fi
  for R in "$HOME/.claude/skills" "${CODEX_HOME:-$HOME/.codex}/skills" "$HOME/.cursor/skills"; do
    [ -d "$R/$name" ] && { printf '%s' "$R/$name"; return 0; }
  done
  echo "未找到技能：$name（plugin 模式请确认同 marketplace 的相关 bundle 已安装）" >&2; return 1
}

SELF="$(resolve_skill dev-fullstack-product)"
COMMON="$(resolve_skill common)"
```

---

## 执行顺序总览

```
阶段 0 输入前置检查   → 文档清点 + 真源门禁 + 需求澄清 → 用户确认
阶段 1 技术栈确认     → 提案表格 → 用户逐项确认（不确认不开工）
阶段 2 开发规范与约束 → 落地规范文件 + 设计稿对齐口径 → 用户确认
阶段 3 分模块开发     → 后端 → 管理端 → 移动端（或按模块纵向打通）
                        每模块：实现 → 自检 → 汇报 → 用户确认
阶段 4 测试与验收     → 单元/集成 → 部署检查 → 测试账号 → 三轮全链路测试
阶段 5 专家评审       → 12 类角色交叉评审 → 评审报告 → 整改闭环
阶段 6 交付           → 目录结构 + 关键文件 + 运行命令 + 环境变量 + 测试账号
```

**禁止跳步。** 每个阶段结束必须按「统一输出格式」汇报并等用户确认，用户说「继续/不用确认了/自动执行」
才可连跑；连跑时每阶段仍要输出汇报，只是不停下等待。

### 落盘目录：产出一律进 `dev/`

**唯一落盘根是 `dev/`**（记作 `DEV_DOC_ROOT`），与产品侧的 `prd/` 彻底分开——`prd/`（上游 `pm-master` 那条链写的
PRD、战略、调研、画像）与旧根 `docs/**` 在本技能里都**只读**。被 `dev-master` 阶段 7 调起时，沿用它已建好的同一套目录。

```
dev/
├─ SRS/                          规格真源（SPEC_SOURCE 指这儿）
├─ design/                       功能清单 · 概要/详细设计 · error-codes.md · 数据字典
├─ plan/                         交付计划
├─ test/                         三轮测试的用例表 · 执行报告 · 缺陷清单与修复记录
├─ reports/                      12 角色专家评审报告
├─ release/                      交付说明 · 部署清单 · 测试账号表
├─ code/                         **三端代码**：`mobile/`（移动端）· `admin/`（运营管理端）· `server/`（后端服务）
│                                 —— 名称按项目实际叫法，单端项目直接 `dev/code/src/`
└─ dev-fullstack-{项目名称}.md    进度存档
```

四条规则：

1. **写一律 `dev/`，读 `dev/` 优先 → `prd/`（上游 PRD 与产品文档）→ `docs/**` 兜底**（存量项目）。
   目录不存在就先建，别把文档散在仓库根。
2. **图片放各文档同级 `images/`**（如 `dev/test/images/` 放测试截图），不要集中放——跨目录引用在 Word 导出时会丢图。
3. **老项目命中 `docs/` 里的历史产出：原地续用，不主动搬家**，在进度存档里登记真实路径。
   用户明确要求迁移才迁，迁移时 `images/` 一起搬并回改全部相对引用。
4. **代码落 `dev/code/`**；每个子项目自己的 `README-DEV.md`、`.env.example`、lint 配置、`migrations/`
   跟着子项目走（`dev/code/<子项目>/` 下）。**仓库级基建留仓库根**：`docker-compose*.yml`、`Dockerfile`
   编排、CI 配置、`hooks/`、`scripts/`、部署文档。设计稿与设计令牌同在 `design-system/`，不在 `dev/` 下。
   存量项目代码已在仓库根的，**原地续用不搬家**，除非用户要求迁移。

### 进度存档（支持断点续跑）

全程维护 `dev/dev-fullstack-{项目名称}.md`，记录：当前阶段、技术栈确认结果、模块清单与状态、
测试轮次与缺陷闭环、评审整改项。每次阶段结束写回。
**重新进入本技能时先读这个文件**，命中则问用户「续跑 / 重来」，不要从阶段 0 重问一遍。

---

## 阶段 0：输入前置检查

### 0.1 规格真源门禁（先于一切）

Read `../common/prd-to-srs-gate.md`（路径用 `$COMMON/prd-to-srs-gate.md`），按 §2 检测：

```bash
ls dev/SRS/*.md 2>/dev/null                      # 新落点，优先
ls docs/SRS/*.md 2>/dev/null                     # 只读兼容
ls docs/01-需求与规划/*SRS*.md 2>/dev/null        # 旧归档路径，只读兼容
ls prd/PRD/*.md 2>/dev/null                      # 上游产物，只读（现行）
ls docs/PRD/*.md 2>/dev/null                     # 上游产物，只读（旧路径）
ls dev/dev-fullstack-*.md dev/dev-master-*.md issues/kanban.md dev/plan/delivery-plan-*.md 2>/dev/null
ls docs/dev-fullstack-*.md docs/delivery-plan-*.md 2>/dev/null   # 老项目兼容
```

- **有合格 SRS**（含功能清单 / 页面清单 / 字段级功能详细设计三个角色）→ 登记 `SPEC_SOURCE=<路径>`，继续 0.2
- **只有 PRD** → 按门禁 §3 话术请用户走 `req-doc` **Step F** 转写；**说完中止**，等答复。
  用户原话说「跳过 SRS / 按 PRD 手动对齐」才可降级，且产出全程标注 `⚠ 降级模式`
- **两者都无** → 路由 `req-doc`（要 SRS）或 `pm-prd-spec`（先要 PRD），中止

> 三端字段级实现比单页面实现更吃字段完整性：PRD 的 §4/§5 缺校验、缺枚举、缺状态流转，
> 拿它直接开工的结果是三端各自猜一套，后面测试轮次全在补这个坑。

### 0.2 文档清点

逐项检查并原样输出这张表（✅ 具备 / ❌ 缺失 / ⚠️ 不完整），**标注实际文件路径**：

| 文档类型 | 常见来源 | 状态 | 路径 / 备注 |
|---|---|---|---|
| SRS 需求规格说明书 | `req-doc` | ⬜ | 规格真源（`dev/SRS/`，老项目可能在 `docs/SRS/`） |
| 产品需求文档 PRD | `pm-prd-spec` / `pm-prd-writer` | ⬜ | 产品意图参考 |
| 功能清单 | `feature-list` / `pm-master` | ⬜ | |
| 页面清单 | SRS 3.3 / `pm-master` | ⬜ | |
| 业务流程图 | `diagram-generator` | ⬜ | |
| 原型 / 设计稿 | `pm-prd-spec` / `ui-ux-pro-max` | ⬜ | 需含移动端 + 管理端 |
| 接口草案 | `lld-design` / PRD | ⬜ | |
| 数据字典 | SRS / `lld-design` | ⬜ | |
| 埋点需求 | `pm-tracking-spec-writer`（pm-skills 库） | ⬜ | |
| 合规与安全要求 | SRS 非功能章节 | ⬜ | |
| 概要设计 / 详细设计 | `hld-design` / `lld-design` | ⬜ | 缺失不阻断，但要在阶段 1 补架构决策 |

### 0.3 需求澄清（仅问缺失项，已在文档里的**不要重复问**）

按下面 8 类逐条比对文档，**只把文档里查不到的列成问题清单**，一次性问完：

1. 目标用户与核心使用场景
2. 三端功能边界（哪些功能只在移动端 / 只在管理端 / 双端都有）
3. 用户角色权限矩阵（RBAC：角色 × 功能 × 数据范围）
4. 核心业务流程与关键异常分支（支付失败、超时、并发冲突、退款、审核驳回……）
5. 数据字典缺口、埋点需求、合规与安全要求（实名、隐私协议、日志留存、等保/GDPR）
6. 设计规范（颜色、字体、间距、圆角、图标、动效、多端适配断点）
7. 非功能性需求（性能、并发量级、可用性、日志、监控、数据量预估）
8. 交付里程碑与时间预期

> **未补全前不进入阶段 1。** 但不要为了「问全」卡住：属于实现细节、用户明显没想过的，
> 给出你的默认方案 + 理由，让用户「确认或改」，而不是开放式提问。

**阶段 0 输出**：清点表 + 缺失清单 + 问题清单（含你的默认建议）→ 等用户确认。

---

## 阶段 1：技术栈确认

读 `references/tech-stack-matrix.md`，结合本项目的形态、团队栈、部署环境，产出提案表。
**每一行都要给出你的推荐项 + 一句话选型理由**，不要只摆选项让用户选。

| 分类 | 推荐方案 | 备选 | 选型理由 | 确认 |
|---|---|---|---|---|
| 移动端语言/框架 | | | | ⬜ |
| 运营管理端框架 | | | | ⬜ |
| 后端语言/框架 | | | | ⬜ |
| 数据库 / 缓存 / 检索 | | | | ⬜ |
| 接口协议 | | | | ⬜ |
| 鉴权方案 | | | | ⬜ |
| 状态管理 | | | | ⬜ |
| UI 组件库 | | | | ⬜ |
| 容器与编排 | | | | ⬜ |
| CI/CD | | | | ⬜ |
| 测试框架 | | | | ⬜ |
| 监控日志 | | | | ⬜ |
| 对象存储 | | | | ⬜ |

**硬规则**：

- 所有依赖**写死大版本**（如 `Spring Boot 3.3.x`、`React 18`、`Flutter 3.24`），不写 `latest`
- **先探测本机环境再提案**：`node -v`、`java -version`、`go version`、`python3 -V`、`docker info`、
  `psql --version` / `mysql --version`。本机已有的栈优先，避免提案里出现装不上的东西
- 用户逐项确认后，把最终结果写进进度存档，**之后不得擅自更换**；确需更换必须重新确认该行

---

## 阶段 2：开发规范与约束

读 `references/dev-standards.md`，在项目里**落成真实文件**（不是口头约定）：
lint / formatter 配置、commit 规范、分支策略、`.env.example`、OpenAPI 骨架、`README-DEV.md`。

四条硬性约束：

1. **设计稿 1:1 对齐**：颜色值、字号、行高、间距、圆角、阴影、图标、以及全部交互状态
   （default / hover / active / focus / disabled / loading / empty / error）。
   设计稿没覆盖的状态**自动补全**并在 `README-DEV.md` 记为「设计补全项」；
   与设计稿的任何偏差必须**书面说明**（原因 + 影响 + 是否需回补设计）
2. **允许且鼓励引入成熟第三方库**（UI / 状态 / 表单 / 图表 / 动画 / 国际化 / 工具），
   但每个新依赖要给出：**选型理由 + 版本 + 体积/许可证影响**
3. **模块化开发**：按业务模块切分（认证、用户、权限、订单……），一个模块纵向打通三端后再开下一个
4. **安全与合规**：参数校验、防注入、敏感信息加密存储、接口限流、日志脱敏、越权校验（IDOR）、
   文件上传白名单。密钥一律走环境变量，**禁止硬编码进仓库**。
   有资金流／多角色权限／个人信息／文件上传／第三方回调时，**阶段 2 先跑 `threat-model`**
   把威胁落成接口鉴权列与测试用例编号，别等三轮测试时才发现越权设计

**阶段 2 输出**：规范落地文件清单 + 模块切分表（模块 / 三端职责 / 依赖关系 / 开发顺序）→ 等用户确认。
模块切分表落 `dev/design/`，错误码表落 `dev/design/error-codes.md`。

---

## 阶段 3：分模块开发

推进方式二选一，在阶段 2 确认：

- **纵向打通（默认）**：单模块内 后端 API → 管理端页面 → 移动端页面 → 联调跑通，再进下一模块
- **横向分层**：全部后端 → 全部管理端 → 全部移动端（适合接口已完全冻结的项目）

每个模块完成后**自检**（不通过不汇报）：

- [ ] 接口与 SRS 字段表逐字段核对：字段名、类型、必填、校验、枚举、默认值
- [ ] 页面与设计稿逐项核对：颜色 / 字号 / 间距 / 圆角 / 图标 / 8 种交互状态
- [ ] 权限矩阵核对：每个角色能进的页面、能点的按钮、能看的数据范围
- [ ] 异常分支：接口 4xx/5xx、超时、空数据、长文本、并发重复提交
- [ ] 单元/集成测试已写并通过，覆盖率达到阶段 1 约定阈值
- [ ] lint / 类型检查 / 构建三项全绿
- [ ] 无遗留 `TODO`、无写死的假数据、无 `console.log` 调试残留

**每模块汇报**用统一输出格式，并附「本模块新增依赖 / 新增接口 / 新增表」三项清单。

---

## 阶段 4：测试与验收（强制多轮迭代）

详见 `references/test-protocol.md`（用例表、报告模板、部署检查清单、测试账号表）。
**验收判据另见 `references/delivery-review.md`**——三轮测试解决的是「跑没跑过」，
交付验收解决的是「交付物对不对」，两件事都要做。

1. **单元/集成测试**：每模块完成即写即跑，覆盖率达标再进下一模块
2. **Bug 修复**：测试中发现的 bug **直接修复**，记录问题单与修复结论，不留「已知问题」清单当交付物
3. **测试环境部署检查**：Dockerfile、docker-compose、环境变量、依赖、端口占用、网关、
   数据库初始化与迁移脚本、Nginx 配置 —— 确认**可一键部署**（真的跑一次起服务，不是看配置文件说「应该可以」）
4. **生成测试账号与初始数据**：超管 / 运营 / 普通用户 / 访客等各角色各一套，连同种子数据脚本
5. **三轮全链路真实测试**（真跑，不是纸面推演；Web 端用 Browser 工具驱动，移动端用模拟器工具驱动）：
   - **第 1 轮 全覆盖**：每个页面、功能、按钮、表单、跳转、异常路径 → 出报告 → 修复
   - **第 2 轮 回归**：用测试账号回归，重点覆盖修复项 + 其关联路径 → 出报告 → 修复
   - **第 3 轮 全量复测**：主流程 + 边界 + 异常全部跑通 → 通过
   - **未跑通则继续第 4、5…轮**，直到通过为止；不得以「非阻塞问题」为由提前宣布通过

**每轮输出**：测试用例表、执行结果（通过/失败/阻塞）、缺陷清单（含复现步骤与严重级）、修复记录、遗留风险。
**落盘**：每轮一份 `dev/test/测试报告-第N轮-{日期}.md`，截图等证据放 `dev/test/images/`；
测试账号表与种子数据说明落 `dev/release/`。

> **报告真实性**：只写真正执行过的结果。没跑的用例标 `未执行`，跑挂的标 `失败` 并贴关键报错，
> 不得把「预期应当通过」写成通过。

---

## 阶段 4.5：交付闭环验收（**进专家评审前必过**）

按 `references/delivery-review.md` 五阶段逐层验收，**每阶段有独立签字人，禁止开发者自签**：

| 阶段 | 签字人 | 查什么 | 证据形态 |
| --- | --- | --- | --- |
| 一 · 还原 | 视觉设计 | 与设计稿 1:1：间距 ≤2px、字号字重色值圆角**偏差为 0**、缓动曲线四值逐位比、十种交互状态逐一核 | **叠图差异截图** |
| 二 · 覆盖 | 前端 + 产品 | 三端页面清单双向映射：「设计稿有代码无」「代码有设计稿无」**各须为 0** | 覆盖表 |
| 三 · 连通 | 测试 | **每个「接口 × 调用端」是一个独立判定单元**，只填「通/不通」 | 请求+响应报文、状态码、耗时 |
| 四 · 落库 | 后端 | 每个写操作的库、表、字段与查询结果；事务回滚 / 幂等 / 并发 / 缓存一致各实测一次 | **SQL 语句与结果** |
| 五 · 测试闭环 | 测试 | 四层用例、正常+异常+边界三类覆盖、断言含落库、单跑可重跑、覆盖率达阈值、CI 回归 | 测试报告 + 覆盖率报告 |

**三条铁律**：

1. **一切判定以证据为准**——本技能阶段 3 的自查清单里「已完成」不构成验收通过；
2. **禁止只验接口返回不验数据库**——「返回成功但库中无数据」是最贵的一条，必须查库；
3. **禁止以一端通过推定其余端通过**——同一个接口，移动端传 3 个参数、后台传 9 个，是两个判定单元。

**五方对齐**（`delivery-review.md` §8）：设计稿 ↔ 页面 ↔ 接口 ↔ 表 ↔ 用例五者一一映射，
八类断链 A1–A8 **全部须为 0**；任一方变更**必须**标记并触发其余四方复核。

**禁止上线红线**（§10.4）：资金用浮点 / 支付无幂等 / 越权可访问 / 无权限仅前端隐藏 /
删除无软删无备份 / 注入未防护 / 敏感信息明文 / 本次变更无已验证的回滚方案——
命中任意一条，**即使其余全绿也禁止上线**。

**前置**：设计稿必须已过 `prototype-review.md` 四阶段并签字（那份在 `pm-master` / `pm-prd-spec` 下）。

---

## 阶段 5：专家评审

读 `references/expert-review.md`，按 12 类角色逐个视角评审，**每个角色至少给 3 条具体意见**
（指到文件/页面/接口，不说「代码质量尚可」这类空话）：

高级开发工程师 / 高级测试工程师 / 高级产品经理 / 产品总监 / 项目经理 / 项目总监 /
高级 UI/UX 设计师 / UI/UX 设计总监 / 高级运维工程师 / 运营总监 / 全栈开发专家 / 技术 CTO

输出《专家评审报告》落 `dev/reports/专家评审报告-{项目名}-{日期}.md`：
**符合项 / 不符合项 / 整改建议 / 责任人 / 截止时间 / 状态**，
对不符合项**当场整改并回填闭环状态**，全部闭环才进入阶段 6。

---

## 阶段 6：交付

交付说明落 `dev/release/交付说明-{项目名}.md`（测试账号表与部署清单同目录）。
**对外有真实用户时，同时用 `release-rollout` 出一份《发布与回滚预案》**（灰度批次、监控阈值、
回滚触发条件与演练记录）——交付说明讲「怎么跑起来」，预案讲「出事怎么退回来」。输出：

1. **目录结构说明**（三端 + 部署目录，标注每个目录放什么）
2. **关键文件清单**（入口、路由、配置、迁移脚本、CI 配置）
3. **运行 / 部署命令**（本地开发、构建、一键部署测试环境，每条都实跑验证过）
4. **环境变量说明**（变量名 / 用途 / 示例值 / 是否必填 / 敏感级别）
5. **测试账号一览**（角色 / 账号 / 密码 / 可见范围）
6. **遗留风险与后续建议**

---

## 统一输出格式（每阶段固定用这五段）

```
【阶段 N：名称】
- 本阶段目标：
- 已完成内容：
- 待用户确认事项：
- 风险与依赖：
- 下一步计划：
```

---

## 质量标准（自检这 8 条，缺一条不算完成）

1. 每阶段用户确认后才进下一阶段，**禁止跳步**（用户明确授权连跑除外）
2. 规格真源是 SRS；只有 PRD 时必须过门禁，降级模式全程标注
3. 所有页面与设计稿 1:1 对齐，偏差**书面说明**
4. 测试**至少 3 轮真跑**，以「全部主流程可跑通」为通过标准，报告只写真实执行结果
5. 专家评审覆盖全部 12 类角色，不符合项**整改闭环**
6. 所有命令、脚本、配置**真实可执行、可复现**，交付前至少完整跑通一次
7. 无硬编码密钥、无写死假数据、无遗留 TODO；文档产出全部落 `dev/`，`docs/` 只读不写
8. 进度存档随时可续跑，换会话不丢上下文

---

## 上下游接力

| 情形 | 路由 |
|---|---|
| 只有 PRD，没有 SRS | `req-doc` Step F 转写 |
| 要有人统筹整条研发链（文档→设计→实现→测试→上线） | `dev-master`（研发总控，本技能是它阶段 7 的深度档） |
| 需求都还没有 | `pm-master`（产品全流程）或 `pm-prd-spec`（直接出 PRD） |
| 只要实现单个页面 | `page-generator` |
| 只要排开发顺序与进度追踪 | `task-breakdown` |
| 要架构 / 表结构 / 接口设计文档 | `hld-design` / `lld-design` |
| 要正式测试用例文档 | `pm-test-cases` |
| 要上线前代码审计（权限、安全、性能） | `pm-ai-ship-audit` |
| 要设计稿 / 高保真原型 | `ui-ux-pro-max` |
| 要操作手册 / 发版说明 | `pm-operation-manual` / `pm-release-notes` |

---

## 启动指令（复制即用）

> 请基于本项目 `dev/` 下的 SRS、`prd/` 下的 PRD（老项目兼容 `docs/`）与原型 / 设计稿，启动 `dev-fullstack-product`，
> 所有文档产出落 `dev/`（`SRS/ design/ plan/ test/ reports/ release/`）：
> 先执行阶段 0（真源门禁 + 文档清点 + 缺失澄清），确认后进阶段 1 技术栈提案并等我逐项确认；
> 之后按阶段 2 规范分模块开发，每模块完成汇报；开发完成执行阶段 4 的三轮真实测试，
> 发现 bug 直接修；测试通过后做阶段 5 的 12 角色专家评审并整改闭环；最后按阶段 6 交付。
> 现在开始阶段 0。

## 外部依赖与降级：浏览器/模拟器驱动

本技能要真的把页面跑起来点一遍，依赖宿主提供的浏览器工具（Claude Code 的 Browser 面板、
Playwright MCP 等），移动端还要模拟器。

| 情况 | 怎么办 |
|---|---|
| 宿主没有浏览器工具 | **明确写「本轮该端未执行」**，给出人工验证清单让用户自己点；**不得纸面推演成"通过"** |
| 服务起不来（端口占用/依赖缺失） | 先修起服务再测；修不了就记为**阻塞**，写清阻塞原因与复现命令 |
| 模拟器不可用 | 该端标「未执行」，不要用截图或经验描述代替实跑结果 |

**铁律**：报告里只写**真正执行过**的结果。没跑的标「未执行」，跑挂的标「失败」并贴关键报错。