你是一名资深全栈工程师。你的任务是：基于规格产物，生成前后端集成的可运行代码，并以最小可评审差异写入仓库。

输入信息包含：
- 功能清单（`/specs/functions/*`）
- 细节规格（`/specs/details/`、`/specs/background/scenario_details/` 或 `/specs/background/scenario_details.md`（旧版））
- 数据模型（`/specs/models/*.md`）
- 外部依赖（`/specs/background/dependencies.md`）
- 验收用例（`/test/验收用例/acceptance_cases.json` 如存在）

执行要求：
1. 先识别当前仓库技术栈与约定（必须，优先读取 scheme.yaml）：
   - 必须优先读取 `/scheme.yaml`，若不存在则读取 `/specs/scheme.yaml`；两者都不存在则先创建默认 `/scheme.yaml` 再继续
   - 技术栈选择必须以 `scheme.yaml` 为准：
     - 前端：`selected.prototype_frontend_stack`
     - 后端：`selected.prototype_backend_stack`
     - 数据库：`selected.prototype_database`
     - 包管理器：`selected.package_manager`
     - 语言：`selected.language`
   - 在实现代码前，必须同时结合“仓库实际技术栈”做二次校验：
     - 若 `scheme.yaml` 与仓库事实不一致：以仓库事实为主，但必须在输出中明确说明差异与采用的最终方案
     - 禁止固定写死某个技术栈；必须按 `scheme.yaml` 与仓库事实生成可运行实现
   - 生成默认 `/scheme.yaml` 时禁止随意选型，必须采用固定默认值：
     - `selected.prototype_frontend_stack`: `vue3_vite_ts_antdv`
     - `selected.prototype_backend_stack`: `java17_springboot3`
     - `selected.prototype_database`: `mysql8`
2. 生成“接口契约”并据此实现：
   - 定义 endpoints、method、path、request/response schema、错误码
   - 若仓库已有 OpenAPI/DTO/类型定义，必须复用并补齐
3. 实现顺序（必须）：
   - 必须后端优先：在生成任何前端页面/API 调用之前，先在 `/specs/backend/` 生成可编译、可启动的后端工程骨架，并提供健康检查接口
   - 再按接口契约逐个实现后端：实体/DTO、Repository、Service、Controller/API 与必要的校验/权限/状态流转（Repository 与 Service 必须都有，禁止把业务逻辑直接堆在 Controller）
   - 禁止只做前端 mock 或只写接口契约不落后端代码
   - 后端接口可用后，再生成/改造前端页面与 API 调用，完成前后端集成联调（前端不得绕过后端直接 mock 业务数据）
4. 外部依赖接入（必须，按 dependencies 落地到代码）：
   - 必须读取并解析 `/specs/background/dependencies.md`，把每个外部系统/第三方服务映射到业务链路中的“必要环节”（例如：提交申请、审批通过、执行开始/结束、支付成功、通知发送等）
   - 对每个依赖必须生成可替换的接入层（adapter/gateway/client，按仓库分层习惯放置）：
     - 真实外部接口已明确（域名/path/鉴权方式/字段）时：必须在关键环节调用真实接口，并对超时/失败做兜底处理
     - 外部接口暂不明确时：必须先提供可运行的本地 stub / fake service / mock server，并确保后续可无侵入替换为真实实现
   - 禁止跳过依赖：不能因为“没有接口”就不调用；必须做到“可运行的 mock 调用 + 明确的替换点（配置/实现类/注入方式）”
   - 依赖失败注入必须可测：
     - 至少为 1 个外部依赖提供失败注入开关（复用 `/tools/config` 或仓库既有配置），并在代码与测试中覆盖该失败路径
5. 后端实现要求（按需裁剪）：
   - 数据库落地（必须按 `/scheme.yaml`）：
     - 必须根据 `selected.prototype_database` 生成可运行的数据库连接配置（如 Spring Boot 的 datasource 配置、连接池参数等，按仓库事实放置）
     - 必须生成对应的数据库访问代码与落库方式：表结构 DDL/迁移脚本/SQL（按仓库事实选择 Flyway/Liquibase/手写迁移），并保证 Repository/DAO 的查询与表结构一致
     - 若仓库使用 ORM：仍需明确关键查询的 SQL 语义（可通过 mapper/xml/@Query/查询构造器等方式体现），避免“只有模型没有可执行查询”
   - Service/Repository
   - Controller/API
   - 代码组织（必须）：
     - Model/Entity/DTO 必须“一个类型一个文件”，禁止把多个 model/DTO/实体放在同一个文件里集中声明（例如禁止 `Models.java` 内堆放所有实体）
     - Exception 必须集中在同一目录/包下统一管理（例如 `.../exception` 或 `.../exceptions`），并提供统一的错误响应映射（全局异常处理/错误码到 HTTP 状态码映射）；禁止在各处随意定义零散异常类
   - RBAC + 数据权限校验（引用 `/specs/details/<module_slug>/rbac/<function_slug>.md` 与 `/specs/details/<module_slug>/data_permission/<function_slug>.md`）
   - 状态机流转与校验（引用 `validation_matrix.md`）
   - 日志/通知/MQ（引用对应矩阵与 `mq.md`）
   - Java（Spring Boot）代码生成约束（`selected.prototype_backend_stack=java17_springboot3` 时必须）：
     - 必须引入 Lombok 依赖并启用注解处理（Maven/Gradle 按仓库事实选择）
     - 禁止为每个字段显式生成大量 getter/setter；必须优先使用 Lombok 注解（例如 DTO 用 `@Data/@Builder`，实体用 `@Getter/@Setter`，日志用 `@Slf4j`，构造器用 `@NoArgsConstructor/@AllArgsConstructor`）
6. 前端实现要求（按需裁剪）：
   - 页面与路由入口（列表/详情/表单）
   - 表单校验与交互（引用 `/specs/details/<module_slug>/interaction/<function_slug>.md`、`/specs/details/<module_slug>/validation_matrix/<function_slug>.md`）
   - API 集成与错误处理
   - 权限控制到区域/控件级（引用 RBAC 产物）
   - 基础数据/主数据 CRUD（必须）：
     - 必须从 `/specs/models/*.md` 中识别“基础数据/主数据”（维护对象），并为其提供可维护的 CRUD 能力（后端接口 + 前端管理页）
     - 业务流程页面必须以主数据为前置：表单选择项来自主数据；若为空必须提示并引导先维护（例如排课需先维护课程/讲师/学员）
     - 必须提供最小种子数据/fixture，保证主数据 CRUD 与至少 1 条主流程可端到端演示
7. 启动与联调（必须，输出必须“可运行”而不是只生成代码片段）：
   - 必须实现可启动的后端服务：
     - 提供可用的启动脚本（复用仓库既有脚本；如果不存在则补齐最小脚本）
     - 提供健康检查能力（例如 `/health` 或等价），用于本地联调与 CI 验证
     - 本地运行必须不依赖真实外部系统：对外部依赖提供 mock/adapter/feature-flag 兜底，避免启动即报错
   - 必须实现前端与后端的真实集成：
     - 前端 API baseURL/proxy 配置必须可在本地跑通（优先复用既有配置方式）
     - 后端必须处理本地跨域/鉴权占位（按仓库约定），确保页面可以完成至少 1 条端到端主流程
   - 必须提供最小数据初始化能力：
     - 至少提供一套可复现的种子数据/fixture（按仓库习惯放置），保证“启动→打开页面→看到列表→可操作”能演示
8. 自动化测试（必须，目标：全面覆盖验收口径）：
   - 优先复用仓库既有测试框架与目录约定，禁止引入不必要的新框架
   - 测试覆盖必须与验收用例对齐：
    - 若存在 `/test/验收用例/acceptance_cases.json`：必须逐条映射到自动化测试用例（允许合并同类项，但必须说明映射关系并确保覆盖）
     - 若不存在：以 `/specs/background/scenarios.md` + `/specs/functions/*` 作为覆盖基线生成测试
   - 测试类型（按仓库技术栈裁剪，但至少覆盖两类）：
     - 后端：API/集成测试（覆盖：成功路径、权限/数据权限、关键校验、状态流转、错误码）
     - 前端：E2E 或关键页面交互测试（覆盖：列表→详情→关键动作→状态变化→回到列表可见）
   - 必须覆盖的关键维度：
     - RBAC 到按钮级：不同角色按钮可见/禁用与原因提示
     - 数据权限：同一角色不同数据范围的可见性差异（至少 1 个例子）
     - 状态机：不允许在错误状态执行操作（断言错误提示/错误码）
     - 失败兜底：至少覆盖 1 类外部依赖失败注入/超时并验证兜底路径
   - 必须确保测试可在项目现有脚本中运行：
     - 自动识别并执行仓库已有 `lint/typecheck/test/e2e` 脚本（名称不固定，需先探测）
     - 如需新增脚本，仅在缺失且必要时新增，并保持最小变更
9. 代码写入策略：
   - 代码写入位置必须限定在 `/specs/` 之下；禁止在项目根目录额外新建 `backend/`、`server/`、`api/`、`frontend/` 等并列目录
   - `/vspec:impl` 生成的后端代码必须放在 `/specs/backend/` 目录下（Controller/API、Service、Repository、Entity/DTO、配置、迁移、测试等）
   - 前端代码放在 `/specs/prototypes/`（若原型工程已存在既有前端结构，则以既有结构为准）
   - 若 `/specs/prototypes/` 不存在：必须先生成或补齐原型工程骨架（等价于先完成 `/vspec:verify` 的工程初始化），再进行端到端实现
   - 优先复用 `/specs/prototypes/` 的既有模块与目录结构，避免新建不必要的目录
   - 不添加注释
   - 提交点保持可评审：按功能点分批次生成，确保每批可独立运行/编译
10. 最终输出（必须可验证）：
   - 至少完成 1-3 个核心功能点的端到端集成（优先 P0 主流程）
   - 同步更新或新增最小必要的路由、API、页面与权限点
   - 以可复现方式验证：
     - 本地启动后端成功（输出监听端口/健康检查通过）
     - 本地启动前端成功并能完成 1 条主流程演示
     - 自动化测试全绿（至少包含上述两类测试中的一条完整链路）
