Daily Rhythm
连接中
今日开发节奏
当前专注块
45:00
只保留一条主线。新想法先放进任务板，完成当前闭环后再切换。
Repository
项目状态
Quick Access
快速进入
Tasks
每日开发任务
B-side MVP Guide
首月 P0
B 端最小 MVP：从审核到服务报告
先记住一句话：让一名已审核的宠托师，完成一笔已支付订单，并让 C 端和 PC 端都看见真实报告。
这就是首月的完成标准。钱包、保证金、认证费、培训、复杂排班和自动派单都不是本期阻塞项；它们会进入二期。
C 端宠主下单、支付、查看报告
B 端宠托师接单、签到、提交报告
PC 运营审核入驻、查看履约、异常兜底
Server状态、权限与唯一归属的唯一事实源
First, understand the gates
最容易混淆的三个状态
登录会创建基础资料；这只能证明“有账号”。
不能接单运营审核通过后，才获得接单资格；驳回后可修改再提交。
具备资格有资格但关闭接单开关时，仍不应该出现在可接订单的范围内。
可以参与订单池记忆口诀：个人资料 ≠ 入驻成功；报名 ≠ 接单成功；B 端报告提交成功 ≠ 交付完成，必须在 C 端与 PC 端回显。
End-to-end flow
一笔订单怎样完成
准入 账号建档 ≠ 审核通过
分配 报名 ≠ 接单成功
验收 B 提交报告 ≠ 交付完成，必须 C/PC 回显
New developer walkthrough
按这个顺序开发和联调
让宠托师“有资格接单”
页面：B 端工作台 / 入驻资料；PC 宠托师管理。
要做：登录后创建基础档案；提交入驻申请；PC 人工审核通过；审核通过才允许打开接单开关。
验收：未审核账号请求大厅或接单接口会被服务端拒绝，而不是只在页面上隐藏按钮。
让已支付订单出现在正确的人面前
前提：C 端宠主完成支付，订单状态进入 PENDING_DISPATCH。
要做：大厅只返回“已审核 + 已开启接单 + 服务类型/区域匹配”的订单；未接单前隐藏详细地址和电话。
验收：一名合格宠托师能看见订单，不符合条件的账号不能看见或只能看到脱敏信息。
报名后，确保只有一人接到订单
页面：B 端接单大厅、订单详情、我的订单。
要做：报名不等于归属；点击“确认接单”才执行 Server 的条件更新/乐观锁。成功者进入待服务，失败者明确提示“已被接走”。
验收：两个测试宠托师同时确认同一订单，只有一个成功；成功后才可读取完整履约信息。
按服务排期签到和提交报告
页面：我的订单 → 订单详情 → 当前服务排期。
要做：检查订单归属、当前排期、服务顺序和定位；签到后上传图文报告。多次上门时，前一次未完成不能签到下一次。
验收：重复签到、越序签到、非本人订单、已取消订单都会被拦截；报告能再次读出并回显。
从客户侧确认“服务真的交付了”
页面：C 端订单详情 / 报告页；PC 订单详情。
要做：B 端报告保存后，C 端读取真实报告并展示进度、图片和异常；PC 可查看履约记录并在异常时人工兜底。
验收：不能只看 B 端提示成功。必须用同一订单号在 C 端和 PC 端都看到报告，才算这个闭环完成。
Prototype & interaction references
原型图与交互流程图怎么用
原型图回答“页面应该长什么样”，交互流程图回答“跨端状态怎样流转”。先按本页 MVP 规则开发，再用原图补充字段和交互细节；不要把原图中的二期资金/培训链路误当作首月必做。
阶段 1：准入
重点看入驻资料、审核结果和接单开关。流程原图中的认证费与培训为二期，本期在“PC 审核通过”后即可进入接单验证。
阶段 2：分配
重点看订单池、报名成功/失败和订单详情。首月只保留“报名 → 确认接单 → 唯一归属”，不实现复杂自动派单规则。
阶段 3：履约
重点看签到、上传图片、服务报告和客户确认。首月必须保证“B 提交 → C/PC 回显”，评价、结算等后续能力不阻塞本次验证。
Deploy
等待状态
服务脚本
运行前确认
脚本会提交当前后端仓库的所有本地变更并推送，然后连接对应服务器完成构建和重启。
脚本日志
等待运行脚本。
Toolkit
常用检查
Skill Context
已接入
winter-pet-context
芯宠项目的长期开发上下文
用于快速定位小程序与后端链路、复用既有工程约定，并保留已经确认的业务规则。敏感凭据不会在工作台中明文展示。
Review
已保存
今日开发记录
建议记录问题现象 · 最小根因 · 修改内容 · 验证结果 · 明日第一步