persionalBrand/agent.md

Project Agent Guide

项目定位

这是一个面向个体户和手艺人的个人品牌小程序试点项目。当前第一个交付对象是朋友的真实品牌。

第一版的核心闭环是：

品牌展示 -> 服务/作品了解 -> 客户预约或咨询 -> 管理员后台处理 -> 客户反馈

产品目标是帮助个人建立自己的品牌入口；后台和多品牌能力是实现手段，不要把项目优先级转向 SaaS、套餐、租户注册或平台流量。

必读文档

开始开发或修改需求前，按以下顺序阅读：

0. PROJECT_STATUS.md：当前阶段、最近提交、下一步和未决问题；跨电脑恢复时优先阅读。
1. docs/PRD.md：产品范围、功能需求和验收标准。
2. docs/01-prototype-spec.md：页面、字段、状态和交互要求。
3. docs/02-architecture-and-decisions.md：技术选型和架构决策。
4. docs/03-data-and-api-design.md：数据模型、接口边界和上传流程。
5. docs/04-implementation-plan.md：里程碑、测试和发布清单。
6. docs/05-pilot-case-food-stall.md：当前首个试点的餐饮场景假设和待确认内容。
7. docs/06-domain-extension-strategy.md：个人品牌核心能力与行业扩展边界。
8. docs/07-requirements-interview-decisions.md：首轮访谈确认的订单与客户身份规则；冲突时优先于早期文档。
9. docs/08-clickable-prototype.md：低保真原型入口、演练路径和边界。

已安装的成熟 Skills

项目当前复用以下外部 skill，不重复维护同类自定义规则：

• playwright-testing：仅在编写或调试 Playwright E2E 测试时使用。重点遵循用户可见角色/标签定位、Page Object、失败截图和 trace。
• codex-review-workflow：在用户要求代码审查、自动质量验证，或功能完成需要正式 review 时使用。默认最多执行初审和一次复审，不把它用于普通探索任务。

这两个 skill 安装在用户级 /Users/que01/.agents/skills/，不属于项目源码。项目规则、产品边界和技术决策仍以本文件及 docs/ 为准。

当前已接受的技术决策

• Monorepo：pnpm workspace + Turborepo
• 小程序：原生微信小程序 + TypeScript
• 管理后台：Next.js + TypeScript
• API：NestJS + TypeScript
• 数据库：PostgreSQL
• ORM：Prisma
• 图片：S3 兼容对象存储
• 后台登录：第一版账号密码，未来可绑定微信身份
• 发布：第一版人工使用微信开发者工具发布

第一版范围

必须实现：

• 小程序首页、品牌介绍、服务、作品集
• 客户无需注册提交预约/咨询
• 公开内容匿名浏览；下单使用微信无感身份，并提供“我的订单”。
• 普通套餐支持数量、自取/配送和预计总价；私厨由经营者人工报价。
• 后台支持订单未读、标签和内部备忘。
• 客户提交反馈，后台审核后公开
• 后台登录和权限校验
• 品牌、服务、作品内容管理
• 预约列表、状态和内部备注
• 图片上传、预览和基本错误处理

明确不实现：

• 支付、退款、发票、财务对账
• 订单和支付状态
• 自动发布微信小程序
• 多商户注册、套餐和计费
• 多员工、多门店、复杂排班
• 会员、优惠券、营销自动化
• 自动消息通知

价格可以作为展示文本；可以预留金额字段，但不得在第一版创建支付入口或支付状态。未来支付应使用独立的 Order、Payment、Refund 模型，不能把支付状态塞进 Booking。

开发规则

• 先确认原型和字段，再修改数据库；不要根据临时页面直接添加字段。
• 公开 API 与管理 API 分离。
• 前端隐藏管理入口不是权限控制，所有管理接口必须服务端鉴权。
• 联系方式、预约备注等敏感数据不得从公开接口返回。
• 内容删除优先使用停用、隐藏或软删除，保留预约和审核记录。
• 新增功能必须说明用户问题、优先级、数据影响和是否影响支付兼容性。
• 不要为了未来 SaaS 过早实现租户注册、计费和复杂权限。
• 不要将品牌文案、服务和作品写死在前端代码中。
• 共享类型和状态枚举放在 packages/，避免前后端重复定义。
• 任何涉及真实客户数据的调试输出都必须脱敏。

推荐目录

apps/miniapp    # 微信小程序
apps/admin      # Next.js 管理后台
apps/api        # NestJS API
packages/types
packages/api-client
packages/validation
packages/config
prisma/
docs/

工作方式

每完成一个里程碑，都要验证对应闭环，而不是只检查页面是否能打开：

1. 后台保存品牌资料，小程序能看到更新。
2. 后台创建服务，小程序能展示并支持预约。
3. 客户提交预约，后台能看到并更新状态。
4. 客户提交反馈，后台审核后小程序才能展示。
5. 未登录用户无法修改任何管理数据。

真实朋友使用前，先完成文档中的发布前检查和数据库备份方案。试点上线后再根据实际使用频率决定是否抽象多品牌和自动化能力。

Vibe Coding 最小规范

以下规则用于控制后续 AI 辅助开发的范围和上下文成本。

开始任务前

1. 先阅读本文件和与任务直接相关的文档，不要一次加载全部代码。
2. 用一句话写清楚本次任务的结果和不包含的内容。
3. 先搜索现有实现，再决定新增文件还是修改现有文件。
4. 涉及数据库、公共类型或 API 契约时，先检查调用方。

实现任务时

• 一次只处理一个可验证的小目标。
• 优先复用现有模式，不为单一需求新增抽象层。
• 每次修改保持在必要文件范围内，不顺手重构无关代码。
• 先实现业务闭环，再补样式、优化和扩展能力。
• 不实现 PRD 明确排除的功能，除非用户明确改变范围。
• 新增依赖前说明用途、替代方案和维护成本。
• 不把临时数据、品牌文案或密钥写死在代码中。

完成任务前

1. 运行与改动匹配的最小验证：类型检查、单元测试、API 测试或手工流程。
2. 检查错误状态、空状态、权限边界和重复提交。
3. 检查是否引入敏感信息、无关文件或未记录的数据库变更。
4. 用简短记录说明改了什么、为什么改、如何验证、剩余风险。

上下文和 token 控制

• 默认只读取完成当前任务所需的文件。
• 大文件先搜索相关符号和行号，再读取局部内容。
• 不重复输出已经确定的背景和完整代码。
• 计划超过三个步骤时，先写出短计划再执行。
• 遇到不确定的产品决策，优先依据 PRD；PRD 没有覆盖时记录假设，不要扩大实现范围。

任务完成定义

任务只有同时满足以下条件才算完成：

• 代码或文档已落盘。
• 相关验证已执行，或明确说明无法执行的原因。
• 变更符合第一版范围和数据/API 约束。
• 用户能根据结果继续下一步工作。