← 回评审台

创业平台首页工作台：首批开发拆解与架构分析

2026-10-10，同日按评审修订一轮（评审意见逐条核实后采纳或驳回，驳回理由在主控回复里），又按白晨 10-10 拍板修订一轮（第四节「已定」）；10-11 按两项目一致性终审与改版原型补一轮（第三节开工条件、已定第 1 条默认尺寸全表、WB-02／05／07／08 验收、第四节「仍待」第 5 条）；同日又按白晨 10-11「结算展示先不做」修订一轮（已定第 10 条：删减 WB-01、04、07、10，重算人日与关键路径），并按改版原型对齐今日行动与我的任务的显示（不再用「制作中」、今日行动右上角放需求方名字、我的任务 2×1 放封面，D10、D11）。输入：首批场景与模块方案（下称「方案」，白晨已基本认可）、09-23 模块清单、10/16 结项待办。开发窗口 10/12～10/16，白晨＋AI 代理。看板 AIC-2706／AIC-2709 由主控同步。 简写：WB/＝apps/web/src/features/workbench/，api/＝apps/api/app/，e2e/＝apps/web/e2e/，acc/＝apps/acceptance/，lib/＝apps/web/src/lib/。【待验证】＝本文没能在仓库里核实的事实，均写明由谁、何时确认。 已定边界不再讨论：只改首页 6 个模块、不新增 WidgetType、规则排序不调模型、界面只显示 coins。本文与方案冲突时以本文为准（方案通篇是【提案】，且有 1.2 所列与代码不符之处）。

〇、结论

  1. 方案的数据假设大体成立，有 11 处与代码不符（1.2）。改变做法的三处：进行中承接的交付恒为 draft，分不出「未开始／交付草稿」；工作台读账本每页只取 1 条；认证列表接口只含官方认证，与本人认证记录口径不一致。其中账本与结算相关的几处（1.2 第 2～4 条）随白晨 10-11「结算展示先不做」（已定第 10 条）不再需要处理。
  2. P0 可以只改前端完成：我能接的单与学习推荐由前端翻页拉全公开任务后求差，作品取最近 3 个已完成承接的交付详情。后端加「只返回未过期」参数（方案 C）放下期第一项（D1，白晨 10-10 定）。
  3. 最大的工作量在改写存量端到端。学习模块进默认布局会让共用辅助函数 addLearning 失效，消息提醒移出默认会让拖动、模板、键盘等场景失效，再加改名，受影响约 18～20 个场景、5 个场景文件、8 个步骤与支撑文件（1.4）。原估 1 人日，现拆成三项共 2 人日。
  4. 待办共 23 项：P0 17 项（9.25 人日），P1 6 项（3.25 人日）。白晨 10-10 定走计划甲（本次改默认布局）；10-11 定结算展示先不做，WB-01、04、07、10 各减 0.25 人日，又因今日行动要显示需求方名字给 WB-04 加回 0.25（D10），P0 从 10 人日降到 9.25 人日，关键路径从 3.75 降到 3.5 人日（WB-04 不在关键路径上）。按理想并行，P0 最早 10/15 中午收口；现实预期是 10/15 下班前收口，10/16 上午给吴梦赢过、下午按反馈修，约有半天缓冲。这是按「10/12 上午与吴梦赢确认后即开工」算的；开工每晚半天，P0 收口跟着晚半天（第三节「开工条件」）。
  5. P1 今日待办「尽量挤进」（白晨 10-10 定）：挤进子集是 5 项、3 人日——设计扩写与评审、后端事项表与增删改勾选、今日待办模块、两层场景、收口；「并入今日行动」后移。设计与后端可在独立分支上与 P0 并行做、不抢 P0 资源，P0 合入后只剩约 1 人日。P0 在 10/15 中午按理想收口时，P1 可在 10/16 中午收口；P0 按现实在 10/15 下班前收口时，P1 余下 1 人日正好占满 10/16、没有缓冲；P0 再晚，P1 留在分支、下周一继续，不做部分合入（第三节）。

一、架构分析

1.1 逐模块核实

模块 方案的数据假设 代码现状（证据） 结论
今日行动 actions GET /me/claims?status=active；阶段取 delivery_status，空＝未开始 工作台已在拉全量承接，每页 100 串行翻页去重（WB/useWorkbenchData.ts:28-51），接口上限 100（api/claims/router.py:305），按承接时间倒序（api/claims/service.py:318），前端再按截止排（WB/logic.ts:181-191）。delivery_status 是非空枚举（api/claims/schemas.py:77-79），承接时建好 version=1 的草稿（api/deliveries/service.py:38），提交即自动验收并完成承接（api/workflows/submit.py:40、:71） 数据现成；阶段只有一档（1.2 第 1 条），10-11 起行上不标阶段，右上角放需求方名字；需求方名称 client_label 只在任务上（api/tasks/schemas.py:144、:205），承接快照里没有（api/claims/schemas.py:28-49），按 task_id 读任务取（D10）
今日行动设置 「显示几项」本次做出来；「显示产能」界面隐藏 设置弹层只给 schedule／tasks／projects／news（WB/WidgetSettingsDialog.tsx:20），由编辑态选中模块后出现的布局面板上的「设置」按钮打开（WB/WorkbenchGrid.tsx:527-591）；条数按高度算，宽 2 时条数＝高度（WB/widgets/ActionsWidget.tsx:12），高 1 时列表不显示（:36）；showCapacity 无处渲染；后端默认设置是 {}（api/workbench/states.py:26），前端新增模块给 {actionLimit:4, showCapacity:true}（WB/catalog.ts:93-94） 要新加设置入口，放进现有设置弹层（WB-05）；缺省按 4；默认改 2×4 使「4 项」生效（已定第 2 条）
我的任务 tasks /me/claims 含交付与两段结算；筛选进行中／已完成 字段齐（api/claims/schemas.py:68-81），结算 9 种状态（api/settlements/states.py:6-16）；承接只有 active／completed 两种状态（api/claims/states.py:3）；白名单里 tasks 只有 source（api/workbench/schemas.py:70） 筛选做组件内切换（D5）；10-11 起只按承接状态分进行中／已完成，结算字段首页不用（已定第 10 条）
我能接的单 inspiration GET /tasks 只列未承接、每页 ≤50；卡片带认证与学习链接 属实（api/tasks/router.py:373-388）。列表含已过期任务且按截止升序（api/tasks/service.py:152），过期的排最前。卡片里每个认证带 task_id，可区分官方与专属（api/tasks/service.py:218-228），学习链接字段是 name／url（api/courses/schemas.py:12-14）。每个任务至少要求一项认证（api/tasks/schemas.py:116-120）。total_coins 为空不等于不能接：历史任务补绑定只写 credits_terms、不写贝壳数（api/tasks/service.py:379-405），能接但金额为空 前端翻页求差（D1）；「现在能接」排除已过期与 total_coins 为空——后者是保守取舍，会漏掉已补绑定的历史任务，换来不会把接不了的单推出来，单测两例都放
学习推荐 learning /certifications＋/me/certifications＋/tasks /certifications 只返回官方认证（api/courses/service.py:47），本人记录两类都有（api/courses/schemas.py:78-85） 「已获／全部」只数官方；推荐候选从任务卡的认证里取
作品与积分 profile /me/account 余额、账本、结算；作品经已完成承接取交付详情 账本每页上限 100（api/settlements/router.py:82），工作台现只取 1 条（WB/useWorkbenchData.ts:81）；每读一页调一次外部余额接口（api/credits/account.py:32-51）；账本 coins、结算 expected_coins 都可为空（api/settlements/schemas.py:38、:54-56）。交付详情里的作品没有可见性字段（api/works/schemas.py:10-16）；作品封面是视频帧图，有专用签名接口 GET /works/{work_id}/cover，隐藏作品只给作者（api/works/router.py:418-430）；没有作品详情页，入口进任务详情（apps/web/src/features/works/logic.ts:13-15，works 域，工作台跨域不能 import） 账本取第 1 页 100 条、必要时续页（10-11 撤下：首页只显示可用积分，账户查询保持现状、不改账本读取，已定第 10 条）；去掉「是否公开」；封面走作品封面接口
今日待办 schedule 后端没有待办表与接口 属实；现为示例（WB/demo/state.ts:95-110，WB/catalog.ts:29-35 标 sample: true），团团示例会往里加事（WB/demo/state.ts:246） 新建后端域，草案见附录 B
默认布局 默认上桌团团＋5 个 P0 模块 前后端各一份：后端 api/workbench/states.py:8-17，前端 WB/catalog.ts:113-130（模板面板、恢复默认、编辑态都读前端这份：WB/WorkbenchToolbar.tsx:73、WB/WorkbenchPage.tsx:180、WB/WorkbenchGrid.tsx:164）。前端默认直接用 createWidget 给尺寸，非团团／今日行动／我的任务一律 1×1（WB/catalog.ts:107-108、:128）。没保存过的用户每次读后端默认（api/workbench/service.py:22-23） 只改默认、不迁移（D4）；默认尺寸单独成表，不改 createWidget（已定第 1 条）
缓存与新鲜度 方案未涉及 承接成功失效 ["my-claims"]、["account"]、["public-tasks"] 前缀（apps/web/src/features/claims/ClaimPanel.tsx:74-80）；认证提交成功直接写 ["my-certifications", userId]（apps/web/src/features/courses/CertificationPage.tsx:112-117）；工作台的键全以 "workbench" 开头（WB/useWorkbenchData.ts:31、:65、:79、:93），一个都匹配不上；全局新鲜期 30 秒（lib/query.ts:7）。注意 lib/settlement-polling.ts:124-140 按 ["workbench","account",…] 的键形状刷新工作台账户，改这个键会断轮询 链路 B「认证页上传 → 回首页能接」在 30 秒内会读到旧数据，WB-04 要处理（D9）

1.2 与方案不一致之处

  1. 「未开始／交付草稿」分不出来（方案 4.1、4.2）：进行中承接的交付恒为 draft，区分要看交付版本，而 MyClaimOut 不带版本（api/claims/schemas.py:68-81；版本只在 ClaimWithDeliveryOut，:65）。两个模块统一叫「制作中」；我的任务阶段收成：制作中 → 尾款结算中 → 已完成／结算待处理。10-11 改：结算阶段不在首页展示，我的任务只分「进行中／已完成」，今日行动的行不再标阶段；「制作中」这个叫法不再使用，它和「进行中」是同一状态，两处都用会出现同一单两种叫法（已定第 10 条）。
  2. 结算状态映射漏两种（方案 4.2）：resolved_exception、not_required 归「已完成」；预付结算异常也算「待处理」。（10-11：首页不再按结算状态分阶段，本条不再适用）
  3. 「待到账」口径前后不一（方案 4.2 只说尾款，4.5 说全部结算）：按预付＋尾款中进行中状态的 expected_coins 之和，金额为空的跳过并计数；blocked 归「待处理」、不计待到账（已定第 4 条）。（10-11：首页不显示待到账，本条不再适用）
  4. 账本只取 1 条（方案 4.5 本月到账）：要改。（10-11：首页不显示本月到账，不改）
  5. 作品「是否公开」拿不到（方案 4.5）：去掉。作品创建时默认隐藏（api/works/service.py:66），本人最近作品多半是隐藏的。
  6. 没有作品详情页（方案 4.5）：入口写 /tasks/{task_id}?work={id}&from=discovery；本人打开隐藏作品时这个来源标记与返回文案是否合适未经浏览器验证【待验证：WB-10 实施时在浏览器核对】。
  7. 学习推荐的「全部认证数」口径不一致（方案 4.4）：只数官方认证，否则会出现「3／2」。
  8. 任务专属认证最多解锁 1 单（方案未提）：学习推荐里排在官方认证之后。
  9. 公开任务列表含已过期任务且排在最前（方案 4.3 只写了 is_expired）：现灵感推荐的首条封面可能是过期任务，改造后先过滤。
  10. 「显示产能」本来就没显示（方案 4.1）：真正要做的是加设置入口。
  11. 工作量没算测试改写（方案〇第 5 条）：见 1.4。

1.3 关键选择（两种方案与推荐）

# 问题 方案 A 方案 B／C 推荐与理由
D1 全量公开任务 前端翻页：先取第 1 页拿 total，其余页并行取；两模块共用缓存；对这个查询关掉窗口聚焦重取；设 20 页上限，超上限时取最后 20 页（列表按截止升序，能接的任务在后面） B：后端 GET /me/task-matches 一次算好。C：给 /tasks 加「只返回未过期」参数，前端仍翻页但页数只随在架任务增长，顺带解决过期任务当封面 已定：10/16 用 A，C 列为下期第一项（白晨 10-10 定）。C 是契约变更，要重生成 lib/api/、补 Apifox 用例与集成测试、改 MSW 处理器，约 0.5 人日，而 P0 已无缓冲；A 的代价是请求数随「未承接＋已过期」任务累积而增长。换 C 的触发条件：生产未承接任务超过 500 条（约 10 页）。数据量：本地开发库 0 条、端到端库全量跑完被重置；端到端一轮内夹具会垫到 56 条以上（e2e/support/workbench-data.ts:131-132）。生产未承接任务总数【待验证：白晨 10/12 上午在后台任务管理页读，本代理不发任何生产请求】
D2 最近作品 取最近 3 个已完成承接，并行读 GET /me/claims/{id}/delivery 的 work，取回后按 work.published_at 重排 GET /me/works A。固定 3 次请求；承接列表按承接时间排，「最近 3 个」是近似，文中如实写；作品多了再做 B
D3 待到账 只算已生成且未到账的结算 再加进行中承接尚未提交的尾款 A。B 把没挣到的钱写成待到账；待处理另起一行「有 N 笔结算待处理」 10-11 撤下：首页不显示待到账（已定第 10 条）
D4 默认布局与已保存布局 只改默认：没保存过的用户自动换新，保存过的不动 数据迁移改所有已保存布局 A。B 覆盖用户编排且难回退。演示账号若保存过布局看不到新默认。【待验证：演示账号是否保存过布局，由白晨 10/12 上午在该账号上直接看；本地开发库 2 行无参考价值，测试环境凭据不在代理可读范围】保存过的，WB-13 收口后由账号本人点「恢复默认布局」
D5 我的任务筛选 组件内切换，不持久 白名单给 tasks 加 scope A，免契约变更
D6 今日行动阶段 不细分，统一一个状态 MyClaimOut 加 delivery_version，区分未开始与交付草稿 A，B 下期。10-11 起行上不再标阶段：列表里全是进行中的承接，原定的「制作中」与我的任务的「进行中」是同一状态，标了就是两种叫法；行右上角改放需求方名字（D10，与原型一致）
D7 待办并入今日行动（P1） 今日行动自己读待办；只并未完成且有日期的；日期按北京时间当天 23:59:59 排序；勾选只在今日待办 两模块同时上桌才合并；行内也能勾选 A，来源不随布局变，单一状态源
D8 本月到账 账本第 1 页 100 条，最早一条仍在本月就续页 用已加载承接里结算的 settled_at＋actual_coins 求和 A。账本才是到账事实、含非任务收入；B 零额外请求、不触发外部余额读取，作备选 10-11 撤下：首页不显示本月到账（已定第 10 条）
D9 首页数据新鲜度 认证复用 lib/my-certifications.ts::myCertificationsQuery；公开任务键用 ["public-tasks","all"] 前缀，被 ClaimPanel 现有失效命中；承接与账户沿用 "workbench" 键（轮询依赖它），改为挂载时总是重读（refetchOnMount: "always"） 承接与账户也改成 ["my-claims"]／["account"] 前缀 A。B 要改 lib/settlement-polling.ts（共享基座）并重测积分轮询；A 只动 WB/，回首页即重读
D10 今日行动的需求方名字（10-11 补） 前端按每行的 task_id 读 GET /tasks/{task_id}（SDK tasksGetPublicTask，ClaimTaskCover 读封面用的同一接口，已承接的任务也能读，apps/web/src/components/ClaimTaskCover.tsx:26-31）取 client_label；只读当前显示的行（默认 4 行），键 ["public-task", taskId] 共用缓存，单行失败只隐藏该行名字 MyClaimOut 加 client_label（契约变更：重生成 lib/api/、补 Apifox 用例与集成测试） A，免契约变更；代价是每行多一个请求。B 放下期，和 D6 的 B 一起做
D11 我的任务已完成行的完成日期（10-11 补） 不显示，已完成按承接时间倒序 MyClaimOut 加 completed_at（契约变更） A。承接接口没有完成时间（api/claims/schemas.py:68-81），尾款结算的 settled_at 是结算时间、且按已定第 10 条不用；原型写的「完成于某日」首批不做，B 放下期

1.4 分档、测试与端到端的隐性成本

二、待办拆解

明细在附录 A；场景清单在附录 C。档次是按 tools/ci/tier.py 的预判，开工与收口以 python -m tools.ci.affected --tier 为准、只升不降。估时单位人日，含写测试与本档收口，不含等全量的墙钟时间。

编号 标题 档 估时 优先级 前置
WB-00 决策先行与基线全量 — 0.25 P0 无
WB-01 纯函数一：今日行动分组、承接计数（10-11 删去结算阶段、待到账、本月到账、账本续页） 中 0.25 P0 WB-00
WB-02 纯函数二：认证匹配、学习推荐、公开任务取页计划 中 0.75 P0 WB-01（同文件）
WB-03 组件测试按模块拆文件（纯重构） 中 0.25 P0 WB-00
WB-04 数据层：全量公开任务、最近作品、需求方名字、新鲜度（10-11 删去本月账本，加需求方名字） 中 1 P0 WB-00；收尾接 WB-02
WB-05 目录改名、默认布局、设置弹层 大 0.75 P0 WB-03
WB-06 今日行动模块 中 0.5 P0 WB-01、WB-05
WB-07 我的任务模块（10-11 改为进行中／已完成两档） 中 0.25 P0 WB-01、WB-03
WB-08 我能接的单模块 中 0.75 P0 WB-02、WB-03、WB-04
WB-09 学习推荐模块 中 0.5 P0 WB-02、WB-03、WB-04
WB-10 作品与积分模块（10-11 积分只留可用积分） 中 0.5 P0 WB-03、WB-04
WB-11a 存量改写一：支撑函数与 AC-101～104 两层 大 0.5 P0 WB-05
WB-11b 存量改写二：AC-105～116 大 1 P0 WB-11a、WB-06～10
WB-11c 存量改写三：交互覆盖纠偏、积分轮询、AC-122 大 0.5 P0 WB-04、WB-05、WB-06、WB-10
WB-12a 新场景一：今日行动、我的任务、作品与积分 大 0.5 P0 WB-06、WB-07、WB-10
WB-12b 新场景二：我能接的单、学习推荐、新用户空态 大 0.5 P0 WB-08、WB-09
WB-13 P0 收口：全量门禁、档案、审查、演示账号核对 大 0.5 P0 全部 P0
WB-P1-0 今日待办设计扩写进附录 B 并过两路评审（挤进子集） 大 0.5 P1 无
WB-P1-1 后端待办域：表、迁移、增删改勾选接口、单元＋集成、契约（挤进子集） 大 1 P1 WB-P1-0
WB-P1-2 今日待办模块（前端，挤进子集） 中 0.5 P1 WB-P1-1、WB-04、WB-05
WB-P1-3 待办验收场景 AC-134、136、137 与日程转真实后的存量调整（挤进子集） 大 0.5 P1 WB-P1-2、WB-13 合入 master
WB-P1-4 P1 收口（挤进子集） 大 0.5 P1 WB-P1-3
WB-P1-5 今日行动并入待办＋AC-135（后移，不在挤进子集） 中 0.25 P1 WB-P1-4、WB-06

P0 共 17 项、9.25 人日（10-11 前为 10 人日：WB-01、04、07、10 各减 0.25，WB-04 又因需求方名字加回 0.25）；P1 共 6 项、3.25 人日，其中挤进子集 5 项、3 人日；合计 23 项。WB-11c 里积分轮询计数的改写随之不需要，但该项其余内容不变，估时不动，省下的算作余量。

可并行组（文件不相交才同时派，deliver-task 派单纪律第 3 条）：

关键路径（10-11 重算）：WB-00 → WB-01 → WB-02 → WB-08 → WB-11b → WB-13，共 0.25＋0.25＋0.75＋0.75＋1＋0.5＝3.5 人日（10-10 版 3.75，WB-01 减 0.25）。WB-08 在 2.0 处完成；WB-11b 同时要等 WB-11a（1.75 处完成）与 WB-06、09、10（都在 1.75 处完成），不改变这条路径。次长的是 WB-12b（2.5 处完成）。

三、排期（10/12～10/16）

白晨 10-10 定走计划甲（P0 全做、改默认布局）。

开工条件（10-11 补）：代码等 10/12 白晨与吴梦赢的确认会开完再开工。确认会拿方案、讲解稿与改版原型过一遍首批要做的事，并当面定第四节「仍待」第 1、2、5 条。会议几点开，本文修订时还没定【待验证：白晨 10/12 约定】。下面的排期表假设确认会在 10/12 上午开完、口径不改，WB-01 在 WB-00 之后（约 10/12 上午 10 点）开工。确认会之前可以先做、不受会议结果影响的事有三件：WB-00（不改代码）、WB-03（纯搬迁测试）、WB-P1-0 起草。所以确认会如果在 10/12 中午前开完，代码实际只晚约 0.25 天，影响介于下表前两行之间。

开工时点（以 WB-01 开工计） P0 理想收口 P0 现实收口 给吴梦赢过 P1 挤进子集
按时：10/12 上午（下面排期表的假设） 10/15 中午 10/15 下班前 10/16 上午，下午按反馈修，约半天缓冲 P0 理想收口时 10/16 中午收口；P0 现实收口时余下 1 人日占满 10/16，没有缓冲
晚半天：10/12 下午 10/15 下班前 10/16 上午 10/16 上午，下午按反馈修，没有缓冲 只有 P0 理想收口时才可能 10/16 下班前收口，没有缓冲；P0 现实收口时下周一继续
晚一天：10/13 上午 10/16 中午 10/16 下班前 10/16 下午，没有按反馈修的时间 不进本周
再晚 10/16 交付 P0 不成立。第三节末尾的后备砍项都不在关键路径上，砍了也追不回来，要白晨另定砍什么（例如学习推荐整体后移），或者推迟交付日 — — —

上表按 10-11 重算后的关键路径 3.5 人日算（WB-00 之后 3.25 人日）。另外，原型第 3 章「链路 C · 成果沉淀」原先演的待到账、本月到账，以及我的任务里「尾款结算中」「结算待处理」的阶段，按白晨 10-11「结算展示先不做」撤下；原型已由另一路按此同步修订（第 3 章改演可用积分变化与最近作品，我的任务只分进行中／已完成），确认会前以修订后的原型为准（已定第 10 条）。

确认会改口径的影响：「仍待」第 2 条（任务专属认证算不算差 1 个）改口径只动 matchTasks 一处，不影响排期；第 1 条如果要求交付单独成卡，等于新增模块，超出「不新增 WidgetType」的边界，P0 要重排；第 5 条选乙，WB-05 加约 0.25 人日，见该条。

各项按依赖尽早开工，下表时点是理想并行下的累计人日（每天按 1 计，10/12 开始为 0）；P1 挤进子集在独立分支上并行：

日期 P0 P1 挤进子集（独立分支） 当日出口
10/12 周一 上午 WB-00（白晨读生产未承接任务总数、看演示账号布局；后台跑基线 make check）与白晨、吴梦赢确认会，会后 WB-01、WB-03、WB-04 开工；下午 WB-02、WB-05、WB-07 代理起草 WB-P1-0 WB-01、WB-03、WB-07 完成
10/13 周二 WB-02、WB-04、WB-05 上午收尾；随后 WB-06、08、09、10、11a 开工 WB-P1-0 过子代理＋Codex 评审，白晨下班前认可 WB-02、04、05、06、08、09、10、11a 完成
10/14 周三 WB-11b、11c、12a、12b 开工 WB-P1-1 后端（只跑单元＋集成） WB-11b、11c、12a、12b 完成；P1 后端完成
10/15 周四 上午 WB-13 跑 make check＋make mutation 并出档，通过即合入 master 上午 WB-P1-2 前端（只跑 vitest）；P0 已合入时下午 WB-P1-3 场景 理想情况中午 P0 收口并合入；现实下班前
10/16 周五 上午给吴梦赢过 P0，下午按反馈修 P0 中午已合入时：上午 WB-P1-4 收口，通过即合入；P0 下班前才合入时：上午 WB-P1-3、下午 WB-P1-4 理想情况中午 P1 收口；现实下班前

P0 结论：关键路径 3.5 人日，理想终点 10/15 中午，前提是确认会按时开完（见上文「开工条件」）、白晨的决策不等待、第 4 组的端到端排队不拖、收口全量一次通过。现实预期 10/15 下班前收口，10/16 有约半天缓冲用来按吴梦赢的反馈修。

P1 挤进的触发条件（逐段判断，不满足就停在该段，已做的留在分支）：

段 开始条件 截止
设计（WB-P1-0） 无条件，代理并行起草；只占白晨 10/13 一次认可 10/13 下班前白晨未认可 → P1 整体下周
后端（WB-P1-1） 设计已认可；10/13 下班时 WB-01～05 已完成、WB-06～10 已开工（P0 前两天没有延误） 10/14 下班前单元＋集成未绿 → 停
前端（WB-P1-2） 后端单元＋集成绿；WB-04、WB-05 已在 P0 分支完成 10/15 中午前未完成 → 停
场景与收口（WB-P1-3、4） P0 的 WB-13 收口通过且已合入 master；时间不晚于 10/16 上午 10 点（余下 1 人日要在当天做完） 10/16 中午还没开始收口，或收口不过 → P1 留在分支，下周一继续

按上表，P0 理想收口（10/15 中午）时 P1 可在 10/16 中午收口；P0 现实收口（10/15 下班前）时 P1 余下 1 人日正好占满 10/16，没有缓冲，而且与 10/16 按反馈修 P0 抢白晨的注意力，P0 优先；P0 再晚，P1 落到下周一。

保护措施（P1 不拖累 P0）：

  1. 独立分支与工作树：P1 在 feat/home-todo-p1 上做，从 P0 分支 WB-04、WB-05 完成后的提交切出；P0 分支先合 master，P1 合入前变基到合入 P0 后的 master，再跑自己的全量收口。迁移 0012 只在 P1 分支，P0 发布不带新表。
  2. 不抢资源：P0 收口前 P1 不跑端到端、不拿 tools/ci/e2e_lock.py 的锁；后端只跑单元与集成（集成用各自的测试容器），前端只跑 vitest。不用 make check-changed，它会带上「初始空状态」等常驻场景（tools/ci/affected.toml:7-9）。
  3. 不用功能开关：开关会多出两条代码路径，都要三层覆盖，反而扩大 P0 的测试面；分支隔离已足够。
  4. 不碰 P0 文件：P1 前端只改 ScheduleWidget.tsx 及其测试、catalog.ts 的日程一项、useWorkbenchData.ts 新增待办查询；这两份共享文件在 WB-04、WB-05 之后 P0 不再改。P1 场景要改的 e2e/support/workbench.ts 等存量文件，等 P0 合入后才动。
  5. 白晨注意力：P1 只占白晨两次——10/13 认可设计、10/16 看结果；P0 的决策与验收始终优先。
  6. 不做部分合入：P1 要么整个挤进子集收口通过后合入，要么整体留在分支。

P0 进度落后时的后备砍项（P1 最先放弃；以下按换回时间排序，触发时请白晨定）：

项 省多少 是否缩短关键路径 代价
今日行动「显示几项」设置后移 约 0.25 否 方案 4.1 这一项不交付
最近作品后移（作品与积分先只给可用积分） 约 0.25 否 结项目标里的「作品」只能在个人页看

四、风险与未决

技术风险

风险 影响 对策
存量端到端改写超估 WB-11 挤占收口 已按 1.4 拆三项、估 2 人日；WB-11a 第一步把 addLearning 改成「添加一个非默认组件」；10/15 上午仍不绿的场景挂起、写进档案「已知问题」请白晨定
生产公开任务量未知 首页两模块变慢 第 1 页后并行取页、关闭聚焦重取、20 页上限取最后 20 页；白晨 10/12 读总数，超过 500 条转方案 C
前端重算「能否承接」与服务端漂移 推荐了接不了的单 规则集中在 WB/logic.ts，单测逐条对照 api/claims/service.py:329-357 的四个判断；详情页仍以服务端为准
时区 跨零点分组错位 北京时间算日界与月界，now 作参数注入；端到端固定时钟用 e2e/support/browser-clock.ts【待验证：WB-12a 实施时确认能用于首页】
基线本身有红 分不清是不是本批引入 WB-00 在分叉点跑全量拿红名单，按 deliver-task「基准自身有红」处理
同一主检出有其他会话在改 互踩 P0、P1 各在基于 master 的独立工作树分支上做
视觉放不下 2×4 的今日行动、1×1 的我能接的单内容溢出 WB-05 开工前在原型里渲染核对（deliver-task 派单纪律第 9 条）；2×4 不通过即按已定第 2 条退到方案 c
P1 变基冲突 P1 合入拖到下周 P1 不碰 P0 文件（保护措施第 4 条）；变基冲突超过半小时即按截止规则留分支

已定（白晨 10-10 定）

  1. 计划甲：本次改默认布局。团团＋5 个 P0 模块成为新默认，顺序团团、今日行动、我的任务、作品与积分、我能接的单、学习推荐；尺寸单独成表、不改 createWidget（否则「添加模块」的尺寸也会变，连带 AC-107）。默认尺寸表如下（宽×高，宽是列数、高是行数；与改版原型「对应拆解的条目」一节及其 data.js 的 DEFAULT_LAYOUT 一致，原型与本表冲突时以原型 README 为准并在此注明，10-11 核对无冲突）：

    顺序 模块 默认尺寸 来源
    1 团团 3×1 沿用现有 createWidget 尺寸（WB/catalog.ts:107-108）
    2 今日行动 2×4 本条与第 2 条
    3 我的任务 2×1 沿用现有 createWidget 尺寸
    4 作品与积分 1×1 沿用现有 createWidget 尺寸；默认只露可用积分，是否调整见「仍待」第 5 条
    5 我能接的单 1×3 本条
    6 学习推荐 1×3 本条

    我的任务、作品与积分取现有尺寸，是因为在今日行动 2×4、两推荐 1×3 定下后，只有这个组合能让四列排满不留空。按 packWidgets 推算（WB/logic.ts:25-50），四列排成 5 行无空洞：第 1 行团团＋作品与积分，第 2～5 行左半是今日行动，右半第 2 行是我的任务，第 3～5 行是两个推荐。两列（宽度 ≤1100px，WB/WorkbenchGrid.tsx:11）只在末行右侧留一格。若第 2 条退到 c，尺寸改为今日行动 2×3、两推荐 1×2，四列 4 行无空洞。消息提醒、项目中心、行业资讯、日程移出默认。

  2. 「显示几项」用方案 b：今日行动默认 2×4，使「4 项」在默认布局下生效；渲染核对不通过退到 c（选项改为「2 项／按卡片高度」，要改字段说明，牵动 openapi.json，届时 WB-05 升为契约变更）。

  3. 开发流程：「方案＋本文」充当 spec，过子代理＋Codex 两路评审，白晨认可本文即算复核（1.4）。

  4. 待到账不含 blocked，归「待处理」（已被第 10 条取代，首页不显示待到账）。原依据：blocked 在契约里是「待配置」（api/settlements/schemas.py:26），界面文案「奖励待配置／待恢复」（lib/settlement-status.ts:56）。

  5. 首页金额一律用接口下发的 coin_name。注意它为空时前端兜底写「贝壳」（lib/coins.ts:9），结算回执文案固定写「积分」（lib/settlement-status.ts:17），WB-06～10 不复用那两处文案。

  6. 保留我能接的单的首条任务封面；AC-116 中借号的那条拆出新号 AC-127 并改数据准备。

  7. AC-101 改标题为「首次进入默认工作台并保存新增的资讯组件」，同步矩阵与 INDEX。

  8. /tasks 10/16 用方案 A，方案 C 下期第一项，触发条件见 D1。

  9. P1 今日待办尽量挤进 10/16：P0 收口后有余力就做，挤进子集、触发条件与保护措施见第三节。

  10. 结算展示先不做（白晨 10-11）：白晨 10-11 在与 Claude 的会话中定，以后任务完成后由需求方（发单人）验收、不再由系统自动验收，验收通过后尾款自动到账；这套逻辑做完之前，首页上待到账这类结算展示不成立，先不做。落到本批：作品与积分的积分部分只显示可用积分（余额不可用时显示降级提示），删去待到账、本月到账、「N 笔结算待处理」及其计算（pendingCoins、monthIncome、needsMoreLedger 不写，账户查询保持现状、不改账本读取）；我的任务只按承接状态分「进行中／已完成」，删去尾款结算中、结算待处理（claimStage 不写），需求方验收上线后再加「待验收」等阶段；今日行动的行不再挂阶段徽章，「制作中」这个叫法整体不用（与「进行中」是同一状态），行右上角改放需求方名字（D10）。结算进度仍可在任务详情与个人页看，那两处不动。最近作品保留：白晨没说去掉，作品来自已生成的作品记录、不依赖结算。取代第 4 条，并改写 1.2 第 1～4 条、D3、D8。知识库记录见 knowledge/wiki/00-口径与治理/00-当前权威口径.md 页首 10-11 块与 03-未决问题.md 2026-10-11 节。

仍待

  1. 交付不单独成卡（吴梦赢）：交付并入我的任务，按承接状态显示进行中／已完成。推荐接受。

  2. 任务专属认证算不算「差 1 个认证」（吴梦赢）：推荐算，学习推荐里排在官方之后。吴梦赢回复前 WB-02 按推荐实现，改口径只动 matchTasks 一处。

  3. 生产未承接任务总数（白晨，10/12 上午 WB-00）：超过 500 条则 D1 转方案 C。

  4. 演示账号是否保存过布局（白晨，10/12 上午 WB-00）：保存过的，P0 合入后由账号本人点「恢复默认布局」。

  5. 作品与积分默认 1×1：最近作品要不要首页一眼可见（白晨，10/12 确认会；10-11 新增，同日按已定第 10 条改写）。按已定第 1 条的尺寸表，作品与积分是 1×1，WB-10 定「1×1 只留可用积分」——这正好就是已定第 10 条允许的积分展示范围，积分这一半不再有问题。剩下的是作品：结项目标 ③ 要求首页「集中掌握……积分和作品」，1×1 时打开首页看不到最近作品。两个选项：

    • 甲（推荐）：接受 1×1。最近 3 件作品放在点开模块后的弹层里（正式版现有的 WidgetPanel 做法）。代价：「作品上首页」要多点一下；用户可在编辑态自己把它拉到 1×3 或 2×2，就能在卡片里看到作品。好处：不动已定第 1 条和尺寸表，WB-05、WB-11 的工作量与关键路径不变，原型不用改。
    • 乙：默认尺寸改为 1×2，重推四列无空洞的布局：顺序改为团团 3×1、今日行动 2×4、作品与积分 1×2、我能接的单 1×3、学习推荐 1×2、我的任务 2×1。按 packWidgets 推算，四列仍是 5 行无空洞（作品与积分在右上角第 1～2 行，我能接的单第 2～4 行，学习推荐第 3～4 行，我的任务落到第 5 行右半），两列只在末行留一格。去掉待到账、本月到账后，1×2 里可用积分下面估计放得下最近 1～2 件作品【待验证：WB-10 开工前在原型里渲染核对】。代价：(1) 学习推荐从 1×3 缩到 1×2，卡片里推荐从 3 条减到 2 条；(2) 我的任务从第 2 行挪到最后一行，1440 宽首屏可能看不到；(3) 已定第 1 条的顺序与尺寸表、WB-05 两端的单测、原型都要跟着改，WB-11 里断言默认顺序与组件个数的存量场景（AC-110 模板计数、AC-112 首个组件）要按新顺序再核一遍，约多 0.25 人日，吃掉 10/16 约半天缓冲的一半。要三件作品都放得下得 1×3（我能接的单、学习推荐都缩到 1×2，我的任务挪到末行）或 2×2（我的任务缩到 1×1、两推荐都缩到 1×2），代价更大。

    推荐甲：乙换来的是首页多露 1～2 件作品的缩略，为此要改已定的顺序与尺寸、压缩学习推荐、把我的任务挤出首屏。甲的不足可以在确认会上当面演示「点一下就看到作品」来说明；吴梦赢若坚持要一眼看到，再走乙。

五、端到端验证步骤（本文充当 spec，白晨 10-10 定）

  1. WB-13 用 tools.testing.run 包住 make check 与 make mutation，四项门禁全过（三层逐行覆盖、变异 ≥80%、矩阵缺口 0、数量阈值）。
  2. 本地起前后端（apps/web/AGENTS.md「起步」），用三个假身份各开一次 /home：①有逾期、今天到期、三天后到期承接各一条的接单者——今日行动按组排、我的任务进行中／已完成分得对、作品与积分的可用积分与 /me/account 一致、最近作品与已完成承接对得上；②只持有一项官方认证的用户——我能接的单两组、学习推荐首位是「解锁单数最多」的认证、点「去学习」打开第一条学习链接；③全新用户——各模块是引导空态。
  3. 在认证页为②补一项认证，经主导航回首页，不刷新页面即看到能接单数变化（D9）。
  4. 1440 宽与 1000 宽各截一张默认布局图，核对无空洞、无溢出；1×1、宽 1 窄高、满 4 列三档各抽查一个模块。

附录 A：待办明细

测试纪律（派单时原样带给子代理）：迭代跑 make check-changed，只改浏览器场景时 make e2e-recheck GREP='<场景名>'；子集结论不能当收口证据；改了 WB/logic.ts 跑 make mutation-changed（门槛 80%）；等后台任务用阻塞等待或 ≤270 秒轮询；全量只在 WB-13 跑。判断类逻辑一律进 WB/logic.ts（前端变异范围，apps/web/AGENTS.md「测试」节）。WB-06～10 的组件测试都要按 1×1、宽 1 窄高、满 4 列三档各验一次，以通过 AC-107 的「十组件 × 十六尺寸」（e2e/steps/workbench.steps.ts:722-770）。

编号 动哪些文件 验收标准与测试
WB-00 无代码改动 白晨读后台生产未承接任务总数、看演示账号是否保存过布局（第四节「仍待」3、4）；基线 make check＋全量变异用 tools.testing.run 留证，红名单与耗时写进台账
WB-01 WB/logic.ts、WB/logic.test.ts actionGroups(claims, limit, now)（已逾期／今天／3 天内／之后，组内截止升序、同截止按承接时间、再按 id）、claimCounts(claims)（按承接状态数进行中、已完成）。10-11 按已定第 10 条删去 claimStage、pendingCoins、monthIncome、needsMoreLedger。单测含跨零点、空列表；行与分支 100%；变异 ≥80%
WB-02 WB/logic.ts、WB/logic.test.ts matchTasks(tasks, myCertIds, now) → 能接（未过期、total_coins 非空、无缺认证；总报酬降序、同报酬截止近者先）与差一个（附缺的认证；组内缺官方认证的在前、任务专属的在后，同类按总报酬降序、同报酬截止近者先，与原型 data.js 的 matchTasks 一致）；recommendCertifications(tasks, myCertIds) → 可多接单数降序、同数按总报酬，0 不出，专属排官方之后；officialProgress(records, definitions)；publicTaskPagePlan(total, size, cap) → 不超上限取全部页，超上限取最后 cap 页。单测含「已补绑定历史任务被保守排除」一例、四条承接判断各一例；变异 ≥80%
WB-03 WB/WidgetContent.test.tsx 拆出 WB/widgets/TasksWidget.test.tsx、InspirationWidget.test.tsx、LearningWidget.test.tsx、ProfileWidget.test.tsx 纯搬迁、单独提交；用例数与覆盖不降（tools/ci/guard_thresholds.py）；npm run test:coverage 仍 100%
WB-04 WB/useWorkbenchData.ts、新建 WB/useWorkbenchData.test.tsx useWorkbenchOpportunities()：第 1 页后按 publicTaskPagePlan 并行取、页间去重、键 ["public-tasks","all"]、关窗口聚焦重取，认证用 myCertificationsQuery 与 coursesQuery；账户查询保持现状（不续页账本，键 ["workbench","account",…] 不动，积分轮询不受影响，已定第 10 条）；承接查询加挂载时重读；useTaskClientLabels(taskIds) 按 D10 并行读当前显示行的任务、取 client_label，单个失败不拖垮其余；useRecentWorks() 并行读 3 个交付详情、单个失败不拖垮其余、按 published_at 重排。renderHook＋MSW 覆盖多页、超上限取末页、某页失败重试、身份切换清缓存、承接后与认证后重新读取、需求方名字单行失败
WB-05 WB/catalog.ts（改名、描述、默认尺寸表）、WB/WidgetSettingsDialog.tsx＋测试、WB/WorkbenchToolbar.tsx＋测试、WB/logic.test.ts、WB/WorkbenchGrid.test.tsx、WB/WorkbenchPage.test.tsx、WB/useWorkbenchLayout.test.tsx、WB/README.md；后端 api/workbench/states.py、api/workbench/README.md、api/workbench/tests/test_service.py、test_http_boundaries.py 四个模块改名（我的任务、我能接的单、学习推荐、作品与积分）；前后端默认布局按已定第 1 条同改（开工前先渲染核对 2×4），前后端各一条单测钉住同一张「类型、顺序、尺寸」表：团团 3×1、今日行动 2×4、我的任务 2×1、作品与积分 1×1、我能接的单 1×3、学习推荐 1×3（「仍待」第 5 条选乙时换成该条的表）；actions 加「显示几项 2／4」、缺省按 4。入口放在现有设置弹层：WidgetSettingsDialog 的类型清单加 actions，编辑态选中今日行动后，在布局面板上点「设置」打开，改动进编辑草稿、点「完成」才保存。原型把下拉直接放在布局面板上（app.js 的 renderHome），只是示意，不照做。理由：其余四类模块的内容设置都走这个弹层，一个入口、一套草稿语义；直接放面板要在通用的 WB/WorkbenchGrid.tsx 里为今日行动开特例，还会多改一个不在本项文件清单里的共享文件；AC-105 改写（WB-11b）的「设置对象换今日行动」也按弹层写。入口位置与原型一致，都在编辑态选中模块后的那条面板上，只是多点一次「设置」；tasks 设置入口移除，保存过的 source=self／assistant 一律按平台承接显示
WB-06 WB/widgets/ActionsWidget.tsx、ActionsWidget.test.tsx 分组标签、剩余天数（逾期标红用原型已有类）、尾款金额与 coin_name；行上不挂阶段徽章，不出现「制作中」（已定第 10 条、D6）；每行右上角显示需求方名字（D10，读不到时不显示、不占位）；条数按已定第 2 条（默认 2×4 下「4 项」显示 4 项）；空态「今天没有要推进的任务」＋去我能接的单；AC-122 仍成立
WB-07 WB/widgets/TasksWidget.tsx、TasksWidget.test.tsx 按承接状态只分「进行中／已完成」两档，不显示结算状态，去掉对 lib/settlement-status.ts 的引用（已定第 10 条）；组件内切换，两个按钮上带各自单数「进行中 N」「已完成 N」（claimCounts），不另设阶段计数（原型的四格阶段计数已去掉）；每行带状态徽章（进行中／已完成），进行中的行写截止（剩余天数，逾期标红）与总报酬，已完成的行写总报酬——接口没有完成时间，原型的「完成于某日」首批不做，已完成按承接时间倒序（D11）；去掉「自主任务与团团任务暂未开放」；空态按方案 4.2。默认 2×1（高 1 不出清单）显示当前筛选下排第一的那单，右侧放这单的任务封面缩略图（沿用现有共享组件 ClaimTaskCover，WB/widgets/TasksWidget.tsx:91 已在用，不新增请求类型）；1×1 只留「N 单进行中」一个数。组件测试覆盖：两档单数之和等于承接总数、切换筛选单数不变、2×1 封面跟着筛选换单、页面上不出现结算文案与「制作中」
WB-08 WB/widgets/InspirationWidget.tsx、InspirationWidget.test.tsx 「你现在能接 N 单」；两组列表；差一个那组写认证名与「去学习」（有学习链接新开第一条，否则进 /certification?certificationId=…，专属认证加 &taskId=）；去掉作品页签；1×1 只留数字与首条任务封面；空态两种。两组都要露出来（照原型，10-11 补）：高 ≥3 时显示首条任务封面，带封面时每组只放 1 行（高 4 放 2 行，规则是每组行数＝高度−2，不带封面时为高度−1，至少 1 行；宽 ≥3 时每组 3 行），多出的写「还有 N 单 · 看全部」，点开模块弹层看全部；「现在就能接」为 0 时那组不出，「差 1 个认证」组多放 1 行。组内排序按 WB-02 的 matchTasks（缺官方认证的在前）。组件测试覆盖：默认 1×3 带封面时两组各 1 行且「看全部」计数正确、能接为 0 时只出差一个那组。未登录态不做：未登录时页面只显示登录卡、模块不挂载（WB/WorkbenchPage.tsx:43-53）
WB-09 WB/widgets/LearningWidget.tsx、LearningWidget.test.tsx 「已获 X／Y 项官方认证」；推荐 2～3 个「学完可多接 N 单，共 X {coin_name}」；1×1 只留首位推荐；空态两种
WB-10 WB/widgets/ProfileWidget.tsx、ProfileWidget.test.tsx 可用积分（不可用时「余额暂不可用」）、最近 3 件作品、认证与承接一行；不显示待到账、本月到账、待处理笔数（已定第 10 条）；新用户零余额且没有作品时补一句「完成第一单后，积分与作品会出现在这里」（AC-133）；封面用作品封面接口 GET /works/{work_id}/cover（SDK worksGetWorkCover），不用按任务取封面的 ClaimTaskCover；入口 /tasks/{task_id}?work={id}&from=discovery；1×1 只留可用积分；去掉「AI 员工可用贝壳」固定文案
WB-11a e2e/support/workbench.ts（addLearning 改为添加非默认组件、标题表、默认组件表）、acc/工作台-布局保存.feature、apps/api/tests/acceptance/test_工作台.py、e2e/steps/workbench.steps.ts 中 AC-101～104 的步骤 两层 AC-101～104 跑通；集成层不再追加已在默认里的组件
WB-11b acc/浏览器-工作台组件.feature、e2e/steps/workbench.steps.ts、e2e/steps/workbench-regression.steps.ts、e2e/support/workbench-auth-boundary.ts、e2e/support/workbench-data.ts AC-105（设置对象换今日行动）、106（拖动对象换掉 messages）、107（新文案与数据断言）、108／109／114（去掉任务来源）、110（模板计数）、111／113（学习卡片断言）、112（首个组件）、115、116（借号那条拆为 AC-127）逐条 make e2e-recheck 绿
WB-11c acc/浏览器-交互覆盖纠偏.feature、e2e/steps/coverage-correction.steps.ts、acc/积分轮询与刷新.feature、e2e/steps/credits-polling.steps.ts、acc/浏览器-今日行动跨页承接.feature、e2e/steps/workbench-claims-pagination.steps.ts 两条工作台追光／Escape 场景不再依赖默认里有消息提醒；AC-045 第三场景改名「作品与积分」，余额读取计数不变（10-11 起账本不续页）；AC-122 复跑绿
WB-12a 新建 acc/浏览器-首页工作台模块.feature、e2e/steps/workbench-modules.steps.ts、e2e/support/workbench-modules.ts；改 acc/AC.md、acc/INDEX.md、tools/ci/affected.toml AC-128（含每行显示需求方名字）、129、132；make tools-test 通过
WB-12b 同一 feature 追加场景、新建 e2e/steps/workbench-matching.steps.ts AC-130、131、133；期望值从页面收到的 /tasks 响应算，AC-133 只断言能接 0 单与引导入口
WB-13 无新代码 重生成 docs/reports/验收矩阵.md；tools.testing.run 包住 make check、make mutation，四项门禁全过；tools.testing.summarize 出档；派 acceptance-reviewer；档案入 docs/reports/acceptance/；按 llm-wiki 记 log；P0 分支合入 master；演示账号保存过布局的，由账号本人点「恢复默认布局」
WB-P1-0 本文附录 B（按已定第 3 条，不另建 spec 文件） 按 docs/superpowers/specs/TEMPLATE.md 的栏目把附录 B 扩写到可开工：错误码、三层测试、端到端验证步骤；子代理＋Codex 评审，白晨认可
WB-P1-1 新建 api/todos/{models,schemas,service,router,examples}.py、README.md、tests/；apps/api/alembic/versions/0012_todo_items.py；改 api/main.py、api/common/openapi.py（TAG_SLUGS 加「待办」→todos）、apps/api/.importlinter、apps/api/pyproject.toml、apps/api/apifox/cases/、tools/ci/affected.toml；新建 apps/api/tests/integration/test_todos.py；make openapi、make client 路由文档要素齐；单元 100%；集成覆盖本人隔离与迁移升降级；变异 ≥80%；契约检查与 Spectral 通过
WB-P1-2 WB/widgets/ScheduleWidget.tsx＋测试、WB/useWorkbenchData.ts（新增待办查询与写操作）、WB/catalog.ts（只改日程一项） 快速新增、勾选完成、删除，沿用「今天／本周」；目录 sample:false、改名「今日待办」；团团示例不再写日程（WB/demo/state.ts:246）；只跑 vitest
WB-P1-3 新建 acc/今日待办.feature、apps/api/tests/acceptance/test_今日待办.py、e2e/steps/todos.steps.ts；改 e2e/support/workbench.ts（日程移出未开放清单）、e2e/steps/workbench.steps.ts（AC-107 日程有了真实入口；AC-108、114 的未开放清单少一项）、acc/AC.md、acc/INDEX.md、tools/ci/affected.toml AC-134（两层）、AC-136、AC-137（集成层）跑通；AC-107、108、114 复跑绿
WB-P1-4 无新代码 变基到合入 P0 后的 master，其余同 WB-13
WB-P1-5 WB/logic.ts＋测试、WB/widgets/ActionsWidget.tsx＋测试、acc/今日待办.feature（加 AC-135） 按 D7 并入，行首标来源；变异 ≥80%；随下一批收口

附录 B：P1 后端待办域草案（WB-P1-0 在此扩写）

附录 C：验收场景清单

AC 场景标题（条件＋行为） 文件 层 等级
AC-127 灵感推荐封面签名失败后可在紧凑卡片内恢复（由 AC-116 借号拆出，标题随改名调整） 浏览器-工作台组件 e2e-only P1
AC-128 有逾期与临近截止的承接时今日行动按紧急程度分组排序 浏览器-首页工作台模块 e2e-only P0
AC-129 有进行中与已完成的承接时我的任务按两档分开显示且不出现结算阶段（10-11 改，原「分别显示制作中、尾款结算中与已完成」） 同上 e2e-only P0
AC-130 持有部分认证时我能接的单分别出现在能接与差一个认证两组 同上 e2e-only P0
AC-131 缺认证时学习推荐按学完可多接的单数排序并给出学习入口 同上 e2e-only P0
AC-132 完成交付后作品与积分显示可用积分与最近作品（10-11 改，原含待到账、本月到账） 同上 e2e-only P0
AC-133 没有承接与认证的新用户在各模块看到去学习和去接单的引导 同上 e2e-only P0
AC-134 新增待办后出现在今日待办，勾选完成后移出未完成列表 今日待办 两层 P0（P1 批）
AC-135 有日期的未完成待办并入今日行动并标明来源（随 WB-P1-5 后移） 同上 e2e-only P0（P1 批）
AC-136 用户不能读取或修改他人的待办 同上 integration-only P0（P1 批）
AC-137 标题为空、超长或未完成数超上限的待办被拒绝 同上 integration-only P1

编号从 AC-127 顺延（现最大 AC-126，AC-119～121 已预留，acc/AC.md）。新首页场景全部 @e2e-only：规则只在前端，集成层没有对应操作。「今日行动显示两项或四项」属交互细节，不占 AC 号，放组件测试并进 AC-105 的设置恢复断言。AC-101 标题按已定第 7 条改。