🔴 概念声明（刘总 2026-09-28，最高优先级）：「取钥匙」是转山噱头，论据来自当地习俗（老话「转冈仁波钦不转咋达布热，等于没转冈仁波钦」等），讲钥匙必带习俗出处，禁降格成空话术；预售凭证与钥匙零关联——券链路只讲产品事实，不对比、不互文、不写否定句澄清。全文见 docs/概念声明-转山钥匙与预售凭证-2026-09-28.md。
## 🔴 分工口径（刘总 2026-09-28 16:0x 亲定 · 最高优先级 · 覆盖此前所有分工表述）
>
现在没办法安排分工。
>
原因（刘总原话）：「你们的进度不一样，如果按照职责去分工，小程序永远做不好，现在只能通过我来安排」。
>
因此：
1. 不按职责域分工——此前所有「前端=X / 后端=Y」「谁负责哪个域」的表述一律作废，不要再据此判断该谁做。
2. 改为逐单派活：由刘总直接安排每人当前做什么。接到什么做什么，做完等下一单。
3. 不要自己找活、不要按"我该负责什么"去抢或推——不确定就问刘总，不要按旧分工推断。
4. 台账登记照旧（TASKS.md WIP 行），但 WIP 里的"职责域"仅是历史记录，不代表分工。
5. 冲突处理：谁的活谁做；撞车时以「谁先领单谁做」为准，另一方改做别的并登记说明。
>
唯一权威 = 刘总当面的派单。 本文件、TASKS.md、任何 prior 分工文档都不构成分工依据。
刘总 2026-09-07 19:2x 问「我让他们看什么文档」→ 本文件为回答而立。
本表是指针：完整要求、冲突裁决、退回判据一律以 TASKS.md 行尾批注为准（见下表「判据出处」列）。
开工三步：①看本表找自己的顺序号 → ②打开对应 WIP 工单行 → ③读到行尾（退回/裁决写在行尾，行头状态可能滞后）。
维护人：派工岗（小齐 / 冈子）。更新即 commit，不口头通知。
📮 干活的人必读：docs/receipts/回执要求-给执行者.md—— 每人维护自己的docs/receipts/<名字>.md，开工/卡住/完工/换活都要更新；不写回执 = 视为无进展。
| 文档 | 谁看 | 看什么 |
|---|---|---|
| docs/NOW.md（本文件） | 全员 | 我下一步唯一动作 + 顺序 |
| docs/TASKS.md | 全员 | 全量台账：领活登记、文件锁、行尾退回批注（判据唯一权威） |
| docs/receipts/<你的名字>.md | 干活的人 | 写回执：进度 / 需求 / 卡点 / 下一步（派工岗看这个派活，制度见 docs/receipts/README.md） |
| docs/reports/*.md | 被点名者 | 验收结论与退回项（不是任务源） |
⚠️ 2026-09-28 时效治理：本表原列的 plans/2026-09-07-*（测试版上传任务安排 / 工单总排产）、
NOW-REVIEW.md、plans/2026-09-05-小齐→小冈工作交接单.md、ROADMAP.md均为 09-07 前后立的老文档，
与当前 v3 提审主线脱节。已归档者见 docs/archive/2026-09-28-时效治理/。
当前主线的判断依据：AGENTS.md（仓库铁律）+ 本文件顶部（分工口径）+docs/TASKS.md（台账）。
涉及 SQL 表名/列名：以 backend/sql/*.sql 迁移文件与实库为准（不要用已归档的 schema-snapshot.md）。
## ⛔ 本节已过时（2026-09-28 时效治理 · 冈子）
>
本节内容为 2026-09-08「第九轮」的当时动作（涉及 WIP-202~230，话题如"压图 vs 迁 COS"），
与当前 v3 提审主线无关。保留仅供追溯历史决策，不得作为当前派工依据。
>
当前的动作依据：本文件顶部「🔴 分工口径」+ docs/TASKS.md 在办 WIP 行。
历史版本已归档：docs/archive/。
# 🔴🔴 第九轮变更令（21:2x · 刘总两拍板 · 全员先看这条）
>
## ① WIP-230 路线整体变更：「压图」作废 → 「主包图片迁 COS」
刘总 09-08 原话：「主包的图片要单独在服务器的cos上存放的」。
- 🔴 小冈：立刻停手，别再跑scripts/compress_mainpack_images.sh（含--dry-run）。该脚本标废弃，新方向下继续压图＝白干，而且会把 hero 压糊（旧判据「avatar ≤150KB / hero ≤280KB」全部作废）。第八轮里所有关于压图阈值、sips 参数、一键脚本的指令一律失效。
- 为什么压图路线不成立（口径翻新，本单数字第三次改）：不迁 COS 只压图，须把这批图削 89.30%（整包削 74.29%）；且「必然全糊」不能由体积比推出（原图/显示尺寸未测）⇒ 迁 COS 的理由改为「既有存储拍板 + 包体预算」。
- 好消息：COS 通道无需新建（小齐 09-08 实测）。backend/app/routers/upload.py就是刘总 09-01 亲自拍板的素材存储范式（独立桶公有读+签名写／一期后端中转／二期 STS 直传契约不变／未配密钥诚实降级 503／禁回退本地盘双轨）；files.py已有 302 跳 COS。230 两容器 COS_ 变量数均=0，容器内127.0.0.1:8000直打 upload ⇒ 503「素材存储未配置（COS 密钥缺失）」0.0s 快速失败，openapi 确认路由已注册 ⇒ 代码全在，只差四个密钥。
- 🔴 唯一缺口＝刘总给 COS 四配置：COS_SECRET_ID/COS_SECRET_KEY/COS_REGION（默认 ap-chengdu）/COS_ASSETS_BUCKET。给了之后必须同时重启容器并复测（原因见下 ③）。
>
## ② 视觉规范升 v1.0（刘总原话「7项全部认可」）
- 规范由 v0.10 草案升 v1.0 正式版（commit 见 §五），§七 七项全部拍板通过，自此为强制标准、不再有待拍板项。
- 🔴 对 WIP-233 的直接效力：§2.1 深底语义色-on-dark四枚（#8FBF9C/#E0A652/#F09A90/#9DBAD4）由「推荐值待拍板」升为「生效值」⇒ 小冈照这四个值落地即可，无二次返工风险（仍然禁自调色，改值须重跑check_semantic_contrast.py --recommend）。
>
## ③ 🔴 astra 预审揪出两个后端真 bug（配了密钥也会出事 → 已独立开单 WIP-234 派阿仁，不再「随 WIP-230 一起修」）
🟢 21:4x 派工补记：本节五项（两 bug + 非法 folder + 两处白名单同步扩 + 迁移脚本）已拆为 WIP-234（TASKS.md 有完整行号、修法与九条实测判据）。其中 ①②③ 不依赖 COS 密钥、阿仁可立刻开工，只有 ④⑤ 等刘总四配置 ⇒ 不必全链路卡在一个缺口上。WIP-230（小冈·C 端引用改造）与 WIP-234（阿仁·后端）并行推进、共用一个验收入口 scripts/verify_cos_migration.py（阿仁须先交付该脚本）。
小齐逐条读原文坐实（不是采信模型）：
-upload.py:36bucket = os.environ["COS_ASSETS_BUCKET"]是下标取值且在 try 外 ⇒ 有密钥但缺桶名会抛KeyError，逃逸出既定的 503 诚实降级路径。
-upload.py:26@lru_cache会把_cos_client()返回的None缓存住 ⇒ 补配密钥后旧进程仍持续 503、必须重启容器才恢复（这条会直接坑运维）。
- 附带两条：upload.py对非法 folder 静默回落tasks（迁移资产可能落错目录）⇒ 须改 400；utils/img-resolve.ts的exists()恒返 true（全文件无任何 cache 写入）⇒ 注释「本地缺失时回退 logo.png（禁破图）」是未实现的承诺，**删本地图后/images/content/*映射必产死链** ⇒ 本单必须同时重写该解析器。
>
## ④ 流程改造（刘总 21:0x 令「就不能用gpt6去跑审核吗」）
裁定：能，但只用在「审」、不用在「验」。 审核段（挑毛病）并行后台跑 astra；验收段仍由人跑命令取回显（staging curl / tsc / 提交树 grep / author=committer）——astra 没有手、碰不到服务器。纪律「不采信自报」对模型输出同样适用：本轮 astra 揪出派工岗自己 5 处错（2 个后端真 bug + 1 个方案误判 + 2 个数字错，其中「余量 708KB」是加减法错，2048−1339=709）。审前件全文＝docs/precheck/WIP-230-astra.md。手册已升 v1.2 更正两条自有结论（「120 秒硬超时」只在 high 档成立，medium 档实测 163.3s 成功；max_tokens不是硬截断，设 3500 实测输出 5344）。
>
## ⑤ 🔴 顺序硬约束（违者成片破图）
先上传并验证匿名读取 → 再改客户端引用 → 再删本地图片 → 最后重测上传包。严禁先删图。
🔴🔴【本段（00:5x 点名）内关于 WIP-230 的指令已被 21:2x 第九轮变更令作废——原文保留留痕，禁照此执行】 具体：下面小冈条目里「第一动作＝bash scripts/compress_mainpack_images.sh --dry-run」「阈值 avatar ≤150KB / hero ≤280KB」全部作废，该脚本标废弃、禁再跑；WIP-230 解法已改「主包图片迁 COS」（见本节顶部变更令 ① 与表格 WIP-230 行）。本段其余内容（G10 退回＝WIP-233 三个缺口、波波 v1.2、冈子三事）仍然有效。
>
📮 00:5x 点名（两位已刷新回执但未消化最新裁决，请按此对表）：
- 小冈：你回执已刷新到 00:5x（提交f9c7c2701:00），并交付了 G10 第一批（5f24cfb，12 处 antd 色→语义令牌）。但有两件事必须立刻看：①🔴 你的回执全文对WIP-230/主包/compress_mainpack零命中（派工岗实测git show f9c7c27:docs/receipts/小冈.mdgrep = 0）⇒ 你仍不知道那张 P0 单，而它现在挡着刘总上传。第一动作＝bash scripts/compress_mainpack_images.sh --dry-run（只打印不动文件）→ 确认后去掉--dry-run；阈值以 00:2x 校正批注为准（avatar ≤150KB / hero ≤280KB，原「hero ≤150KB」作废）。②🔴 G10 第一批被判「部分达标·退回」＝新单 WIP-233（原编号 WIP-233 已被一号 01:06 自领占用，派工岗让号），三个缺口全是实测：#ff4d4f仍剩 5 处（你自报「全库 antd 色残留 0」不成立，规范 §6/§22 明写 antd 四色含#FF4D4F）；status-bar/altimeter是深色卡片底，套浅底语义令牌后对比度腰斩（砖红最恶劣档仅 1.03:1，改前 antd 红是 2.07:1 ⇒ 深底上本次是负优化）；规范 §241 红线 4 要求的截图回显零交付。修法与深底令牌推荐值（#8FBF9C/#E0A652/#F09A90/#9DBAD4，出自python3 scripts/check_semantic_contrast.py --recommend）已写全在 WIP-233 行尾，不必自己摸索。顺序：WIP-230（P0 上传阻塞）→ WIP-233 → WIP-229 → WIP-228①② → G04 剩批。
- 波波：你回执已刷新到 00:35（提交07a2c9b00:27），但内容是「AI 通道接入」，风险段④仍写「上轮 WIP-221 仍待派工岗验收」 ⇒ 你还没看到 23:2x 的分项裁决：标准正文已判过 ✅、§五 清单数据层退回 ❌ 须出 v1.2。退回根因＝两个系统性漏扫致在用图被误标「零引用→建议删」（漏.svg、漏config/）。v1.2 请用已入库工具重跑python3 scripts/audit_image_assets.py（口径写进 docstring），数字以脚本输出为准。另：你 00:27 提交的《借鉴方案更正 v1.1》作废手法 8「按单返福钥」——派工岗已核，该更正正确（福钥经商户领取任务获得，按单返＝交易挂钩贴 GMV，撞零挂钩红线），判过。
- 冈子：🟡 第二轮点名（00:5x 点过，01:1x 复点，两处自纠一处未修）。你 00:58 提交bb5d4ff把回执「更新时间」刷到 00:5x，但那是追加、不是覆盖：①「下一步」第一处仍写「等小冈 apply 补丁并以 xiaogang 推送」（该拟稿补丁 22:2x 已裁决作废、你历史段自己也记了）——你只在下面又加了一条新「下一步」，于是当前状态段现在有两个「下一步」、两个「风险」，与 00:5x 点名时一模一样，等于没改；②纪律 8 三事仍未表态：分级预审口径是否接受（你写的是「我的后续任务一律先过 astra 预审」＝未采纳派工岗「不再逐单必审」的裁决，且 astra 固定开销 4460 token/次 + 120s 硬超时 + 502 也计费）／补交docs/precheck/WIP-224-astra.md（git log --all --diff-filter=A -- docs/precheck/*仍为空）／「小冈令」署名更正（5300a5cauthor=冈子）。⇒ 请把「当前状态」段整段重写为一份（七字段各一行，禁重复），并在回执里逐条回这三件事。
【🔴 G10 第一批：判「部分达标·退回」＝WIP-233（01:0x，小齐实测）】 小冈5f24cfb交付 12 处替换，方向对、映射表用法对（禁自调色 ✓）、C端 tsc EXIT=0（派工岗实跑 ✓），5f24cfb已入库不回滚（浅底改善有效）。但三个缺口全部实测在案：
- ① antd 四色未清零：在origin/main提交树上扫，改前小程序内 17 处 → 改后仍 5 处#ff4d4f（status-bar.wxss行 21/40/155/249/260）+ 派生色#ff78751 处（行 156）。规范 §6/§22 明写 antd 四色含#FF4D4F⇒ 自报「全库 antd 色残留 0」不成立。#1890ff/#52c41a/#faad14三色确已归零 ✓。
- ② 🔴 深底对比度腰斩（本单核心）：status-bar底色rgba(0,0,0,0.6)、altimeter底色rgba(255,255,255,0.1)，都浮在首页 hero 图上；而 §2.1 语义令牌是为浅底调的一套。派工岗新建scripts/check_semantic_contrast.py（WCAG 2.1，可复跑）实测：浅底全面改善（苔绿 +2.30 / 砖红 +2.90 / 雾蓝 +1.09 / 琥珀 +1.00），但 hero 雪面亮档下深底四色全 FAIL（门槛 3.0:1 图形元素）——status-bar 等效底#464A4D、altimeter#585C5F，砖红#B3261E分别仅 1.37:1 / 1.03:1（近乎不可见），而改前 antd 红同底是 2.74:1 / 2.07:1 ⇒ 深底上这次是负优化。问题不在语义色，在规范只给了一套（已立 WIP-232 修规范）。
- ③ 规范 §241 红线 4「每页迁移完贴开发者工具截图回显」零交付 ⇒ 无回显无法判「观感仅冷转暖」，自报不可作验收依据。
- 派工岗自纠留痕：首扫误判一次——在工作区旧 HEAD（fce6aab，未含小冈提交）上扫，得出「残留 18 处、只改 12 处」的错误结论；正确姿势＝git fetch后在提交树上扫（git grep <rev> -- <path>），真值「改后剩 5 处」。此即纪律 6 第四变种（见第三节）。
- 粗筛误报已排除：曾按rgba(0,0,0粗筛出 22 个「深底+语义令牌」文件，逐一核后真深底只有 2 个（status-bar7 处 /altimeter1 处），其余是dialog-mask遮罩与box-shadow误命中；weather-widget（rgba(0,0,0,0.4)）与countdown（rgba(0,0,0,0.2)）虽深底但零语义令牌，归第二批顺改。
【✅ 规范 v0.9 查出五处自身缺陷＝WIP-232 已完工关账（02:0x，commit3a32877）：规范升 v0.10，拍板项由 6 项回到 7 项】 五处缺陷全修完（六处「33」→实测 17 处 / §2.1 补深底语义色四枚-on-dark+ 判定规则 / tokens 同步 / 红线 3 补「深底以对比度 ≥3.0·4.5:1 为准」/ 红线 4 补截图可执行标准，无回显＝不受理验收）；双版本核验v0.10md=18 / html=19（差 1 为<title>）、二次渲染污染 0。🔗app.wxss落地不在本单（属 C 端文件，避免与 WIP-233 抢同一文件）⇒ 随 WIP-233 修返工一并做。原记（保留留痕）最要紧两条：①「antd 四色 33 处」是未经工具核验的账面数，实测 17 处（28 处命中其实在 docs 文档里）——与 WIP-230 我方自估「110KB / 1.71 倍」被脚本推翻是同一类错误：派工岗给出去的数字，自己先跑一遍。②§八 写「待刘总拍板七项」而 §七 只列 6 项⇒ 第 7 项在 v0.9 定稿时丢了，正好以「深底语义色一套」补回，待刘总拍板项由 6 项回到 7 项。
【🟢 冈子·批次 0 审核报告判过（00:5x）】docs/reports/2026-09-07-批次0样板审核报告-冈子.md派工岗已核，「有条件通过 + 6 项修正清单」的判定成立，其中两处抓得准：①「语义浅底四色为新造值」（success-50 等 4 个本应与app.wxss逐字一致却新造）——token 是全局基础、错值会扩散全站，定 P1 正确；②「福钥 chip 白字压金底，对比度约 2.1:1 不达 4.5:1」——无障碍硬指标，定 P1 正确。transaction-boundary-v1.html评「最优样板」与我方口径一致（术语未回退、零保障承诺、显式声明无在线支付按钮）。放行批次 1 的条件（6 项修正 + 你复验修正点）由你自持，不必送派工岗。
【🟡 冈子·回执两处自纠（00:5x）】 ①你的「当前状态」段下一步仍写「等小冈 apply 补丁并以 xiaogang 推送」，但该拟稿补丁已在 22:2x 裁决作废、不得 apply（你历史段 22:5x 自己也记了「因重复劳动且实现冲突被裁决作废」）⇒ 当前状态段与历史段自相矛盾；请把下一步改为「R2 复核 + 两个设计待办（造数管线／组件收敛+分包 ADR）+ 额度烧速周报首期」。②你的「当前状态」段有两个「下一步」、两个「风险」（重复段落）——回执制度要求该段每次整体覆盖，你这是追加未覆盖，请清成一份。③纪律 8 三事仍未表态：分级预审口径是否接受／补交docs/precheck/WIP-224-astra.md（三重实测证明全历史从未入库）／「小冈令」署名更正（提交5300a5cauthor=冈子，小冈与冈子是两个账号，身份链铁律禁混署）。
>
✅ 验收队列现状：已清空（WIP-204/205/206/209/218/222/223/225/226 P0 全部 22:2x–22:5x 实测判过关账）。扫描器仍显示「已完工待验」是因为他们的回执未刷新，不是派工岗积压；四单的行头状态列已与关账批注对齐（此前挂着「待开工」，属账面不一致，本轮已修）。
🔴🔴【本段（23:2x/00:2x 压图口径）已被 21:2x 第九轮变更令整体作废——原文保留留痕，禁照此执行】 三处作废：①结论「分包救不了，必须压图」作废 ⇒ 改为「分包救不了，必须迁 COS」（刘总 09-08 令「主包的图片要单独在服务器的cos上存放的」）；②全部压图参数与阈值作废（1200px/600px、-Z/-q、avatar ≤150KB / hero ≤280KB、闭包图片 1215KB、主包 1.36MB、余量 652KB）⇒scripts/compress_mainpack_images.sh标废弃；③「主包最小闭包 3572KB / 超限 1.74 倍」是口径错（那是最小必需闭包下限，不是上传体积）⇒ 精确口径：打包基准 19550KB − 零引用 22 个 11584KB（ignoreUploadUnusedFiles:true剔除）= 现状上传体积 7966KB，为上限 2048KB 的 3.89 倍（超出约 289%）；需迁 COS 的被引用资产 16 个 6627KB；全迁后 1339KB、余量 709KB（🔴 曾误写 708，2048−1339=709，加减法错，astra 预审纠出＝纪律 9 第五实例）。⚠️ 7966KB 须视为「基于指定剔除集合的本地估算」：ignoreUploadUnusedFiles依赖开发者工具分析，不等于audit_image_assets.py的零引用名单，验收以迁移后实际主包报告为准。
⛔🔴 上传阻塞仍未解除（23:2x 重大更正依旧有效）：原写「G08 前置已全部满足，随时可传」不成立——主包体积超微信硬上限。00:2x 数字校正（脚本化后闭包递归实测，比手工估更准）：源文件 181KB（原估 110+8KB 偏低）⇒ 图片额度 1867KB（非 1930）、主包最小闭包 3572KB、超限 1.74 倍（非 1.71）。微信官方「单个分包/主包不能超过 2M」（上传阶段即校验）、app.json 无任何分包配置（118 页全在主包）⇒ 分包救不了，必须压图。
🆕 00:2x 关键实测发现：hero-a~d 只降质量几乎无效（-s formatOptions 75 不降分辨率：426305B→412095B，-3%），因原图已是压缩 JPEG ⇒ 必须降分辨率；而「保原分辨率」的画质优先档主包 2.07MB 仍超限 ⇒ 原阈值（hero-a~d ≤150KB）作废，只能压到 600px 以下会发虚。校正后目标档：全屏背景长边 1200px（真机最宽 430pt×3x=1290px，已达原生分辨率、全屏无画质损失感）、头像 600px（显示仅 40-80px，7.5 倍冗余）⇒ 闭包图片 1215KB、主包 1.36MB、余量 652KB ✅。
上传时机仍由刘总自定，派工岗不催（刘总 22:0x「我不着急上传，什么时候上传我自己决定」）；但技术上须等 WIP-230 关账，否则传不上去。其余前置仍成立：A1 护栏生产生效、mockMode:false、涉钱假数据清零、C端 tsc=0、118 注册页文件全齐（实测「注册但文件缺失＝无」）不会编译失败。
| 人 | 工单 | 动作 | 优先级 | 完成判据（不采信自报） | |
|---|---|---|---|---|---|
| 刘总 | G08 | ⛔ 上传测试版——现暂不能传，先等 WIP-230（P0 包体·已改迁 COS）修完。微信开发者工具导入 /Users/yujiaxinmeiti/dev/kailash/miniprogram → 上传 → 公众平台「版本管理」设为体验版 → 登记 docs/version-ledger.md。🔴 21:2x 口径第三次翻新（前两次数字均作废，留痕见 WIP-230 行尾批注）：①最早自估「3.42MB / 超 1.71 倍」错；②其后报「3572KB / 超 1.74 倍」是最小必需闭包下限、不是上传体积；③精确口径＝真实主包 19.11MB → 打包基准 19550KB（减 mock）→ ignoreUploadUnusedFiles:true 生效剔除零引用 22 个 11584KB ⇒ 现状上传体积 7966KB，为上限 2048KB 的 3.89 倍（超出约 289%）。⚠️ 该 7966KB 是本地估算，微信工具最终体积待验证，验收以迁移后实际主包报告为准。🔴 现需刘总两件事：①给 COS 四配置（COS_SECRET_ID/COS_SECRET_KEY/COS_REGION/COS_ASSETS_BUCKET）＝通道 503 的唯一缺口，代码全在（实测证据在案）；②微信后台配 downloadFile 合法域名 + 确认桶公有读/Referer/流量告警。给了密钥务必同时重启容器（upload.py 的 @lru_cache 会缓存住 None，不重启仍持续 503）。上传时机仍由刘总自定，无人催（刘总 22:0x「我不着急上传，什么时候上传我自己决定」）；但技术上须等 WIP-230 关账 | ⛔ 待 WIP-230 | COS 四配置到位 + 域名配好 + 上传成功 + 白名单 15 人可见 | |
| 阿仁 | WIP-227 | A1 余量补漏：生产 28 条 dev_ 前缀账号 is_test=false 漏标回填（054 迁移）。派工岗生产实测捞出，053 只回填了 oxr% 真实微信用户。非上线阻塞（28 条关联订单=0），属口径补漏 | P2 | 派工岗生产实测 count(NOT is_test AND openid LIKE 'dev_%')=0 + schema_migrations 含 054 + 备份文件在 + 当日记账 | |
| 阿仁 | WIP-228④ | P3 死码：miniapp_orders.py:535 if payment_mode=="online" 分支永假（L534 刚无条件赋 offline），三行不可达 → 补注释「商品类路径预留」或抽品类判定函数。可与 227 同批 | P3 | 行号+改法写进行尾批注 | |
| 阿仁 | 🔴 WIP-234（新派 · 后端配套） | WIP-230 迁 COS 的后端半部：upload.py 两个真 bug + 非法 folder 静默回落 + 静态图匿名可达路径 + 一次性受控迁移脚本（五类必派之跨域契约；astra 预审揪出、派工岗逐条 cat -n 读原文坐实）。🔴 两个真 bug（配了密钥也会出事）：①:36 bucket = os.environ["COS_ASSETS_BUCKET"] 下标取值且在 try 外 ⇒ 有密钥但缺桶名抛 KeyError，用户面变 500，逃逸出刘总 09-01 拍板的「诚实降级 503」；②:26 @lru_cache 把 _cos_client() 返回的 None 缓存住 ⇒ 补配密钥后旧进程仍持续 503、必须重启容器才恢复（现象与「密钥没配对」无法区分，会直接坑运维）。另：③:61 非法 folder 静默回落 tasks ⇒ 资产可能上传成功却落错目录、零错误信号，须改 400；④ALLOWED_FOLDERS（upload.py:23）与 _ALLOWED（files.py:14）须同步扩主包静态图前缀（files.py:13 注释已要求两处对齐，只改一处＝写入成功而 302 读不到）；⑤迁移走一次性受控脚本（内容版本化 key + 自动 Content-Type + 映射清单 + 下载回来算摘要核对，COS ETag 分块上传时不可当 MD5），不走 base64 接口（:63 UUID 随机名不利幂等）。🟢 可立刻动手：①②③ 不依赖 COS 密钥，不用等刘总；④⑤ 等四配置。🔴 顺序硬约束：先上传并验证匿名读取 → 再改客户端引用（小冈）→ 再删本地图片 → 最后重测上传包，严禁先删图。 | P1 | 派工岗实测九条：故障矩阵（缺密钥／缺桶名／无效凭证／COS 不可达 ⇒ 配置缺失全 503、写入故障 502、假成功 0、本地盘写入 0、切 mock 0）＋ 补配后不重启即 503→200 ＋ 非法 folder 400 且 tasks/ 零新增 ＋ 两处白名单值集合完全相同 ＋ 迁移脚本连跑两次第二次零新增 ＋ 清单每个 URL 匿名完整 GET（非 HEAD）且图片可解码、摘要比对不符 0 个 ＋ Content-Type 为 image/*（octet-stream 0 个）＋ 四配置字面值全仓提交树 0 命中 ＋ 后端测试全绿 + staging 冒烟 26/26 不退化。与 WIP-230 判据③共用验收入口 scripts/verify_cos_migration.py（须先交付） | |
| 小冈 | ⛔🔴 WIP-230（已重开·解法换轨） | P0 上传阻塞：主包体积超微信硬上限 → 刘总一上传必被拒。🔴🔴 21:2x 刘总令换轨：解法由「压图」改「主包图片迁 COS」（原话「主包的图片要单独在服务器的cos上存放的」）⇒ 原判据①-⑧与全部压图阈值作废，scripts/compress_mainpack_images.sh 标废弃、禁再跑（含 --dry-run），继续压图＝白干且会把 hero 压糊。<br>你的活（C 端，等 COS 密钥到位后开工，密钥未到位前先做不依赖密钥的部分）：<br>A. 不依赖密钥、可立刻做：①重写 utils/img-resolve.ts——🔴 该文件 exists() 恒返 true（if (cache[path] !== undefined) return cache[path]; return true，全文件无任何 cache 写入）⇒ 注释「本地缺失时回退 logo.png（禁破图）」是未实现的承诺，**删本地图后 /images/content/* 映射必产死链。改为「逻辑资产名 → HTTPS COS 绝对 URL」版本化清单；未知名称返回不可用状态、禁猜本地地址；http:// 不得原样放行（须 HTTPS）。②建本地兜底集 /images/fallback/logo.png + 1 张占位图，合计 ≤20 KiB（20,480 字节）——裁定不违反「禁回退本地盘双轨」（该拍板上下文是后端素材存储，随包发布的固定 UI 兜底图不是第二套素材存储、不是 mock），但该预算须计入最终主包。③给所有 <image> 接 binderror：记录失败 URL、保留版面尺寸、展示占位；占位图自身失败后降为纯色块/文字、禁再次加载占位图（避免递归报错）；禁无限重试；装饰背景失败时停用轮播、不阻断业务操作。<br>B. 依赖密钥（等刘总给 COS 四配置）：④改 27 处引用＝wxml 静态 src 8 处 + ts 动态 19 处 + wxss 0 处，其中 🔴 config/weather-fx.ts:39 的拼接常量 const IMG = '/images/draft/'（:51 起 IMG + 'hero-a.jpg'）改这一处即可覆盖 6 个天气档背景池——这正是字面量 grep 的死角、曾让派工岗把 hero-a~d 误判「零引用」险删活图。⚠️ 更正我方误判：wxml 静态 src 可以直接写 HTTPS 绝对 URL，改数据绑定是可维护性选择（统一资产清单）、不是技术约束，二选一均可，推荐改绑定。⑤原地注入禁整体重写（事故 3c4da68）。<br>🔴 顺序硬约束（astra 最大风险 1，违者成片破图）：先上传并验证匿名读取 → 再改客户端引用 → 再删本地图片 → 最后重测上传包。严禁先删图。<br>零引用 22 个（11584KB）处置：kailash-logo-icon-2048x2048.png（2805KB）与 icon-1024.png（1448KB）建议移出 miniprogram/ 到仓库根 assets/brand/；其余 20 张 draft 零引用建议删——删前必复跑 python3 scripts/audit_image_assets.py（引用判定以该脚本为权威口径，字面量 grep 仅辅助）。本单不动 app.json（分包属架构变更，另开单待刘总点头）。<br>分工：后端配套（upload.py 两个 bug + 非法 folder 改 400 + 匿名可达路径 + 迁移脚本）＝阿仁；方案/派工/验收＝小齐；审前件全文＝docs/precheck/WIP-230-astra.md** | P0 ⛔ | 新判据九条（详见 TASKS.md WIP-230 行尾批注第十节，替换旧①-⑧）：①干净构建取官方上传校验实际主包字节数 ≤ 2,000,000 字节、上传拒绝 0 次（口径＝微信工具计量，不是 du、不是仓库大小）②扩展审计器覆盖 wxml 绑定/ts 常量与拼接与模板表达式/wxss/编译产物，27 处引用、16 个资产逐项有迁移记录，非兜底图求值为清单内 HTTPS COS 绝对 URL，旧本地路径引用 0 处、未解析表达式 0 处（禁只 grep 完整文件名）③清单每 URL 匿名完整 GET（非 HEAD、非只看 200）+ 图片可解码 + 与源文件摘要比对，失败 0 次、摘要不符 0 个 ④已删旧图的干净构建：旧 /images/draft/ 引用 0 处、旧图残留 0 个、本地引用目标缺失 0 个、兜底文件最多 2 个合计 ≤20,480 字节 ⑤解析器七类错误链断言失败 0 条、每组件每轮切本地占位最多 1 次、占位失败后网络重试 0 次 ⑥后端故障矩阵：缺配置 503、写入故障 502、假成功 0 次、本地盘写入 0 次、切 mock 0 次，补配后按重启流程恢复 ⑦真机域名对照实验（开发工具「不校验合法域名」结果不得入账）⑧真机离线+清缓存断网+弱网各 ≥1 轮（建议 RTT 800ms/下行 256kbit/s/丢包 5%/60 秒），无限重试 0 次、mock 回退 0 次、误报成功 0 次 ⑨真机引用覆盖回放（含 8 处原 wxml 页面、动态分支、天气背景池、后端图片字段样本），未覆盖 0 处、旧本地路径加载 0 次。⑦⑧⑨ 必须真机，不得用开发者工具替代 + C端 tsc=0 + verify-c 全绿 <br>🟢 22:5x 已核验你的改造清单 b92e910 → 判「基本达标·可开工批 1」，1 处漏项须补：①✅ 「27 处」与我方独立实测精确相等（差额 0），口径＝完整路径引用实例数（16 文件/26 行/27 实例）；⚠️ 验收按实例数扫不按编号数数（supplier-product-edit.ts:9 一行 2 路径、admin-content.ts:10-12 一编号 3 行、weather-fx.ts bgPool 六编号背后 14 个拼接实例——你标「随 IMG 常量不改」判断正确）。②🔴 漏 1 处真缺陷：pages/login/login.wxml:2 仍引用本地 icon-back-white.svg，而微信 image 组件不支持本地 SVG（你 09-07 21:5x 回执自己定性过、并称「94 页全站换字符 ‹」）⇒ 实测全仓小程序内 .svg 引用仅这 1 处，你的「全站换字符」差 1 处未清零，现象＝登录页返回箭头隐形、用户进去出不来；修法＝同其余 94 页改字符（推荐，零 COS 依赖）。③✅ 无漏迁：你命中 13 个大图＝我方复算「须迁 16 个」的体积 Top13（合计 6588KB）；留本地 3 项实测仅 40KB ⇒ 判断成立。④✅ 迁后主包账（P0 关键数字，可复跑）：images/ 外全量 1322KB + 留本地 40KB + 兜底集 20KB = 1381KB / 2048KB ⇒ 占比 67%、余量 667KB ✅；与压图路线（1.36MB/余量 652KB）相当但不损画质 ⇒ 刘总换轨决策技术上验证成立；ignoreUploadUnusedFiles:true 已核实在位（project.config.json:13）。⑤批 1 立刻开工（不等密钥，与阿仁 WIP-234 并行；你四批序顺序硬约束守住 ✅），四条验收要求见清单批注 §五：(a) img-resolve.ts 须真删 exists() 恒真（cache 声明了却全文件零写入、直接 return true ⇒ 头注释「禁破图」是未实现的承诺，删本地图后必产死链）(b) 兜底集 ≤20KiB 交 du -sk 回显 (c) 补 login.wxml:2 (d) C 端 tsc EXIT=0 回显 + ≥3 页真机截图证明画面未变，无回显＝不受理验收（红线 4）。⑥⚠️ 你回执称「接替生效（刘总 22:18 令）——派工/验收/台账/文档维护归我」已上报刘总裁决（挂起）：现行交接单 §9.4 白纸黑字「冈子=接替小齐」（刘总 09-07 18:22 原令）、「刘总 22:18 令」全仓零记载。你的施工权本就属自己、批 1 照常开工不受影响；但「代派工/代验收」权在刘总回话前请勿行使（同 09-07 19:2x 注销「阿仁无代派工代验收权」之例，commit 5f86ba2）。详见 docs/plans/WIP-230-小冈C端改造清单.md 末尾「派工岗核验批注」。—— 小齐 22:5x <br>🔴🔴 23:5x 批 1 验收退回（P0 顺序违例，全文判据见 TASKS WIP-230 行尾）：你已推 c4d4baa+a2b78db（img-resolve v2/v2.1 + 兜底集），通过项据实记账：exists() 恒真 bug 真删了 ✅（要求 (a) 满足）、tsc 派工岗独立复跑 EXIT=0 ✅、images/draft/ 提交树仍 36 个文件（未删图）✅、config.ts 两常量设计合理 ✅、v2.1 三项加固（非字符串守卫／cosKey 逐段编码／空键归一）保留勿回退 ✅、astra 预审按纪律 8 留痕 ✅。退回主因（P0，当下就在破图）：resolveImg() 现把 /images/content/<name> 与 /images/draft/<name> 都映射成 COS 绝对 URL，而 COS 上一张业务图都还没传（批 3 未做）——派工岗取提交树 draft 全部 36 个文件名逐个匿名 GET ⇒ 命中 200＝0 个、全 404；而 staging 库 recommendations.image 抽样 8 行全是 /images/content/<name>.jpg，home.ts:167 与 product-detail.ts:73 是既有代码（批 1 未改这两文件）⇒ 首页推荐区 5 图 + 商品详情封面现在就是 404 破图；旧版把 content 映射到本地 draft（ca19d96:img-resolve.ts:20-22）而那三张图提交树里确实在（687955/537811/470318 字节）⇒ 改前能出图、改后必破图。你自报「双保险期：本地图未删，COS 未上传键 binderror 回退存量」不成立：resolveImg() 是同步字符串 API、只返 COS 地址，本地候选只在 imgCandidates()，而批 1 无任何页面调用它（git grep -alE "imgCandidates" <rev> -- pages components ＝ 0 文件），home.wxml 也无 binderror 绑定。修法（走 ①）：①加迁移开关（config.ts 导出 COS_MIGRATION_LIVE = false），开关为 false 时 content/draft 前缀返回本地 /images/draft/<name>（＝旧版行为、零破图），批 3 真上传并验证后只改这一行为 true ⇒ 全站一次生效；②把批 3 提前——但批 3 正被派工岗暂缓（密钥来源未明 + staging .env 664），当下不可行。另三项：②兜底集超上限 2.28 倍——fallback/logo.png 与 placeholder.png 各 23391 字节、合计 46782，判据九上限 20480 字节；且两者blob 哈希完全相同（2a2b93e3）、与既有 images/draft/logo.png 也是同一 blob ⇒ 占位图是品牌 logo 的第三份副本（git 去重不涨仓库、但打包按文件计三份，主包白吃 46.8KB）；请另做极简灰底占位图 ≤3KB 并把 logo 压到 ≤17KB，改后交 git ls-tree -r -l <rev> -- ...fallback/ 回显（这是判据不是建议）。③login.wxml:2 仍是本地 svg ⇒ 登录页返回箭头隐形（此项不计你交付不实：要求写在 22:5x 批注里，而那条批注当时未推送，你提交时 HEAD 仍是 ca19d96）。④截图零交付 ⇒ 按红线 4 不受理完工；按上面实测，首页此刻应当是破图的，截图恰是最快的自证。🔴 批 2 暂不开工：19 处 ts + 2 处 wxml 全依赖 resolveImg() 行为，开关没定就切＝把破图面从 2 页扩到 20+ 页。优先级：本批 ＞ WIP-233 ＞ WIP-229（本批是当下唯一在产生用户面破图的单）。🔴 台账（第二次同类事故）：你的 ef3e64c 在本行追加批 1 登记时，把该行既有的「④遗留」整段删掉了（实测 ca19d96 命中 1、a2b78db 命中 0）——那两项待办正是你自己 22:4x 写的；派工岗 22:5x/23:2x 两段（合计 6370 字符）也因你基于旧版本提交而面临永久丢失。已三方合并修复：以你的提交为基底，按时序补回 21:2x③段 → 22:4x COS 批注含④遗留 → 22:5x 核验 → 23:1x 你的批 1 登记 → 23:2x 复验 → 23:5x 退回批注，13 项内容逐项 assert 命中恰好 1 次才写入（含竖线数校验）。⇒ 立纪律 11（见第三节）：改长行必须脚本化「读全文→定位该行→只在行尾追加→写回」，提交前必跑 check_tasks_table.py --diff-head。派工岗自己的失误也记档：批注写完未立即推送，导致你按未含要求的版本施工 ⇒ 新规：派工岗批注写完必须当批推送，不得留在工作区过夜。—— 小齐 23:5x | |
| 小冈 | WIP-229（次于 230） | app.json 漏注册 2 页 → 商户工作台入口点击必失败（P1 运行时故障）：payment-confirm + task-review 有目录未注册（118 注册/119 目录），而 workbench-home.ts:35-36 goEntry map[5]/[6] 与 :72/:77 两个直跳函数真在跳 ⇒ 商户点「收款确认」「任务审核」必报 page not found。三端已核实齐备只差注册（页面真调 service 零 mock / URL 与后端 :207/:220 逐字对齐 / staging 两端点 200、无 token 401）。要求：pages 数组末尾追加（严禁动首位=启动页）+ 补两页页面级 .json（惯例 117/118 有 json）+ 原地注入禁整体重写（事故 3c4da68）+ 无裸色值。不阻塞刘总上传（118 注册页 ts/wxml 全齐，实测「注册但文件缺失=无」），属上传后可见故障，建议上传前修掉 | P1 | 注册数 118→120、有目录未注册=0、两页 .json 在位、C端 tsc=0、map[5]/[6] 目标已在 pages 中（脚本比对）、模拟器点两入口能进页 | |
| 小冈 | WIP-228①② | 两处 C 端卫生批：①profile.ts:77/:78 两个入口都叫「组合详情」（跳 package-detail 与 package-booking 两个不同页），用户面重名 → 区分命名且避禁词「预订」（可用「套餐详情」/「行程组合」），路由名不动 ②unwrap 族 7 处冗余 double-unwrap（scene-cards W1-W2 / products W3-W5 / product-detail W6 / safety W7）→ request.ts 已统一解包，删页面内二次解包 | P2 | 逐条写文件:行号+改前后；C端 tsc=0；verify-c 全绿 | |
| 小冈 | WIP-233（G10 第一批退回） | 修返工三件事：①补清剩余 5 处 #ff4d4f + 1 处 #ff7875（全在 status-bar.wxss 行 21/40/155/249/260/156）②app.wxss 补四枚 深底令牌 -on-dark，status-bar（7 处）+ altimeter（1 处）深底改用它 ③补开发者工具截图回显（status-bar 四态 + altimeter，深浅 hero 各一组）<br>🟢 21:2x 好消息：规范已升 v1.0（刘总「7项全部认可」），四枚 -on-dark 由「推荐值待拍板」升为「生效值」⇒ 照 #8FBF9C/#E0A652/#F09A90/#9DBAD4 直接落地，无二次返工风险（仍禁自调色，改值须重跑 check_semantic_contrast.py --recommend）；截图标准已写进规范红线 4＝无回显＝不受理验收。<br>⚠️ 与 WIP-230 的耦合关系已变：230 由压图改迁 COS ⇒ hero 原图保留、不再被压亮，原判据「230 压图后 hero 更亮 ⇒ 深底更差」失效；但两单仍须同批验（230 会动 app.wxss 附近的引用与兜底逻辑）。若 hero 图被替换或新增，须重跑 --recommend 复核深底最恶劣档 | 🔴 P1（不阻塞上传，但与 WIP-230 同批验） | ①git grep -aiE 四色+派生色 = 0 命中（在提交树上扫，禁工作区 grep）②check_semantic_contrast.py --pair 四色全 PASS ③四枚 -on-dark 在 app.wxss 在位且被引用 ≥8 处 ④C端 tsc=0 ⑤截图回显在行尾或 docs/reports/（无回显＝不受理） | |
| 小冈 | 🆕 WIP-236（复验退回 · 文档治理批） | 两批自领提交复验＝判退回：1b786c2（00:30《文档库系统性审计报告》213 文档 astra 六卷定位）+ 009b77c（00:39「治理五项落地」）。🔴🔴 P0-1 交付不实：宣称「五项全采纳落地」，实测 docs/tools/verify-c.sh 本次零改动——BASE 98 行 → NEW 98 行、blob 哈希完全相同（git rev-parse 9791937:docs/tools/verify-c.sh 与 009b77c: 同路径两值相等），本次提交非 md 改动＝0，「状态倒挂」在 009b77c 全树只存在于其自己报告的建议文字里、无任何实现 ⇒ 宣称 5 项、实落 4 项。🔴 P0-2 双版本失步：改 41 份 md、0 份 html，其中 22 份有同名 html 在树却未重生成（违反铁律「md/html 双版本同步」）——派工岗已代补 22/22 ✅。🔴 报告口径错误 4 项已污染落地动作（其 009b77c 父提交＝小齐 9791937 00:36，开工时事实已在树上、可查而未查）：①缺口第 5 条称会员体系「待评审」⇒ 已被决议 23 砍除（总纲 :83，且派工岗 00:36 刚把 :131 基线表改成「已砍除」，就在其父提交里）；②缺口第 3 条称视觉规范「v0.9/v1.0」+「33 处污染」⇒ 规范早已 v1.0 正式版（f5ac41c 09-08 21:13，刘总「7项全部认可」）、且 33 是 v0.9 账面错数、v0.10 已校正为 17 处（＝WIP-232 成果）；③改名后的存档版横幅指向错文档（写《现行定位与功能布局研究》，全仓无此文件名；现行应是 docs/项目总纲.md v1.6）⇒ 比不加横幅更危险，正是其治理建议第 4 条「引用完整性」要治的病；④称「G07 v1.1/v1.2 并存」⇒ 树上只有 v1.0 与 v1.2 两份、无 v1.1 文件（横幅结论侥幸对、依据不实）。🟢 据实记账（不因上述错误全盘否定）：报告规模断言基本准确（md 实测 215 份 vs 称 213、总码点 1848544 vs 称 178 万＝+3.9%）；其点名 19 份文档存在性逐个命中；成本自报高度自洽（6×4460＝26760≈「~2.7 万」+ 失败 1 次 ≈3.2 万）；§五主动写出 astra 110s 超时一次、71KB 超 low 档上限、按手册 §九止损改人工组织＝纪律 10 正面示范（不藏失败）；缺口第 4 条完全成立（福钥 L2 三键 key_grant_real_ratio/key_redeem_real_ratio 实测只在 4 份文档、后端零落库）⇒ 已采纳、派阿仁随 WIP-234 同批。🟢 落地手法通过 4 项：38 份横幅属纯插入、原文零改动（旧文非空行集合 ⊆ 新文；新增 ⛔ 行恰好 38 行/38 份，全批 85 insertions(+), 2 deletions(-)）⇒ 未犯事故 3c4da68 同族之戒，手法合规；改名内容零丢失（6147→6191，差异仅 44 码点横幅、相似度 98%、旧名已不在树上）；引用完整性 2 处属等长替换且语义正确（规则样板→插槽终稿、码点差 +0）；README(+204)/小渔.md(+56) 补齐「代码里有、文档里无」的双文件规则 ✅。 | 🔴 判退回（不返工全批，只补 4 件）：（1）verify-c 第五项要么真写、要么撤回宣称（提交信息不改历史 ⇒ 撤回须在报告头部挂更正横幅注明「③未落地」并另建单跟踪）；（2）修 2 处错误横幅指向（存档版总纲 → docs/项目总纲.md v1.6；G07 v1.0 → 依据改「v1.2 为现行（退回重做版）」）；🟡 另 25 处横幅的「现行以《X》为准」写的是描述性短语而非精确文件名（《后续刘总指令》《当前实现状态文档》《新版交易/结算方案》《ROADMAP/TASKS》等，全仓无同名文档）⇒ 不算错，但达不到「检索一眼可辨」的设计意图，建议（非强制）能对应精确文件的改写成路径；（3）报告头部加更正横幅、注明缺口第 5 条与第 3 条两项作废并写清正确口径（该报告已被 1 份文档按旧名引用，留着不改会继续误引）；（4）回执刷新（其「当前状态」仍停 09-08 22:3x，而 00:30 交报告、00:39 交治理批＝两批交付均未登记，按回执制度「不写＝视为无进展」）。复验判据 6 条（可复跑，全文见 TASKS WIP-236 行尾）：①非 md 改动非空 ②verify-c 行数>98 且含「状态倒挂」③存档版横幅含 docs/项目总纲.md 且不含「现行定位与功能布局研究」④报告头部含更正横幅且两条已标作废 ⑤md 份数＝html 份数 ⑥回执更新时间不早于 09-09 00:5x。🔴 纪律 2 违例记档：两批均属自领提交且未登记 WIP 号（纪律 2「自领可以，但必须登记 WIP 号」）；且 WIP-230 批 1 重修是当前最急（退回结论 1f77bdd 00:13 已在其提交树祖先链上），其却先做两批文档治理 ⇒ 优先级倒置风险（🟡 其是否读到退回结论无法证实，不认定「明知而拒不修」，但纪律 1「开工前必读工单行尾」要求其下批开工前先读 WIP-230 行尾 23:5x 退回批注）。批 1 重修优先级仍最高、本单 4 件事不得挤占它（4 件做完仍须回批 1）。 | P0（批 1 重修之后） | 4 件事按复验判据 6 条逐条核；横幅制度本身采纳（成本极低、检索一眼可辨，是好主意） |
| 小齐 | WIP-232 | 规范 v0.9→v0.10 修自身五处缺陷（①「antd 四色 33 处」账面错→实测 17 处，六处全改 ②§2.1 补深底语义色一套 + 判定规则（含排除项 dialog-mask/box-shadow）③红线 4 补截图可执行标准 ④红线 3 补「深底以对比度 ≥3.0/4.5:1 为准」⑤🔴 §八写「待拍板七项」而 §七只列 6 项 ⇒ 第 7 项在 v0.9 定稿时丢了，以深底令牌补回）<br>🟢 21:2x 续办并关账：刘总「7项全部认可」⇒ 规范升 v1.0 正式版——标题去草案、§七 七项逐条标「✅ 已拍板」（7 处）并注明生效说明（原问题文本留档不删）、§2.1 四枚 -on-dark 升生效值、§八 追加 v1.0 版本记录 | ✅ 已完工关账（v0.10＝3a32877；v1.0＝f5ac41c，author=committer=小齐，ls-remote 核验相等） | ✅ md/html 双版本同步（单参数 md2html）：已拍板 md=7 / html=7、生效值 html=5；check_tasks_table.py --diff-head 本次新引入错位=无；污染 0 份；待拍板项 0（§七 全部已拍板，§八 仅留痕） | |
| 小冈 | G04 剩批 | 全入口白名单 add（剩批） | P2 | 白名单实测 | |
| 小渔 | WIP-228③ | v4 报告 1 项 Critical + 11 项 Minor 补证据：Critical 项必须在回执点名「文件+行号+复现步骤」（派工岗复核后定级再派，不采信自报）；11 项 Minor 同格式。另：v3 报的「种子回填 FAIL(P1)」已被派工岗更正撤销（053 就是回填 SQL 且已在生产执行 applied_at=12:06，trial_openids note=seed_user_backfill_053 自证），不必再做 | P1 | Critical 三要素齐 → 派工岗复核 | |
| 波波 | WIP-221 | G07 素材标准：标准正文判过 ✅，§五 清单数据层退回 ❌ → 出 v1.2。判过：§二 三级分级+三条硬判据+正反例、§三 AI 修图五条红线（红线 3「不得 AI 生成虚假实景」抓到命门）、§四 商户信息保真、§六 不占工程产能、边界声明（不代填三列）。退回根因＝两个系统性漏扫致「在用图被误标零引用→建议删」：①漏 .svg（draft 实测 36＝32jpg+2png+2svg，v1.1 称 34＝36−2svg）——icon-back-white.svg 实测被 login.wxml:2 引用 ②漏 config/ 目录——hero-a/b/c/d v1.1 全标「零引用→建议删」，实测全被 config/weather-fx.ts bgPool 引用（:51/58/65/72/79/86）且该文件被 home.ts:7 import ⇒ 照单删会打断首页天气特效背景池。v1.1 自称的三个数字全部与实测不符：资产 37→实测 39（v1.0 的 39 本来是对的）、draft 34→36、被引用 12→17。v1.2 必须用派工岗已入库的工具重跑：python3 scripts/audit_image_assets.py（口径写进 docstring：资产不限扩展名、源文件遍历全树含 config/utils/mock/components），§一/§五/§5.1 数字全部以脚本输出为准 + 文中写明「实测口径＝该脚本，扫描源文件 613 个」。另 §5.1「包体提醒」定性偏轻 → 升级为独立小节并指向 WIP-230（主包最小闭包 3572KB/上限 2048KB/超 1.74 倍/无分包，三层实测；数字以 audit_image_assets.py --mainpack 输出为准，勿引 23:2x 的旧值 3.42MB/1.71 倍——00:2x 脚本化后已校正）。详见行尾「小齐 23:2x 验收」批注 | P1 | §五 39 行一行一图（数字与脚本输出一致）+ 两个漏项补入 + hero-a~d 改为「被引用·weather-fx.ts」并移出建议删名单 + 「建议删」逐张标注实测引用数=0 并加删除前复跑警告 + 正式 logo 三张改口径（horiz-376 仅 mock 引用且已被 packOptions.ignore 排除／icon-1024+icon-2048 零引用→建议移出 miniprogram/）+ §5.1 升级为独立小节指向 WIP-230 + 文件名与内容版本一致 | |
| 波波 | WIP-208 | 已交付，等刘总阅文档 + 裁三道闸 | 待刘总 | — | |
| 一号 | WIP-223 余 P3 | WIP-204 / WIP-223 均已关账（e2e 派工岗二次代跑 PASS=11/FAIL=0/SKIP=2，7.2 point_id 已修；契约对齐批 4ad4663 已消费阿仁真实契约）。✅ 09-08 00:5x 你 22:3x 的 astra 预审自查批 b2271ed 已判过——派工岗独立复验：B端 tsc 我方实跑 EXIT=0（非引用你自报）、你自报「验收点零变化」属实（券类 :159-166 仍零控件、货类仍接真端点键名一致、留痕三分支文案诚实）、「通道未开通」用户面清零属实（残留 1 处在 L34 注释解释 -1 哨兵值，mock 1 处在 L61「不 mock」否定声明，均非用户面）、不采纳 matched 态的判断我方认可（WIP-204 M1 预留分支 + 已补注释说明永不可达）。🟡 但派工岗抓出 1 项你 astra 预审未覆盖的缺口（P3，不挡关账）：同类运行时校验两页不对称——MyDemands.tsx:56 已加 Array.isArray 守卫，而 PaymentSettings.tsx:54 的 setPaymentMode(body.data.payment_mode ?? null) 只靠 TS 类型断言、无运行时值域校验 ⇒ 后端若返回契约外字符串（如已废弃的 merchant_mch），TS 断言会骗过编译器、分段控件落到「无选中项」的静默异常态（用户看不出问题、也不报错）。修法：加白名单校验（仅 online/offline/mixed 才 set，否则置 null 走已有诚实提示分支）——与同文件 change_count 的 typeof === 'number' 守卫同款思路，那处你已做对了，补齐到 payment_mode 即可。方法论提醒：既然预审抓了 A 页面的「接口边界数据按 unknown 校验」，同批次交付的 B 页面同型风险应一并扫，否则预审覆盖不全反而给人「已加固」的安全感。其余＝等派工或自领（自领须登记 WIP 号、不得抢 P0） | P3 | 白名单校验在位（值域外置 null）+ B端 tsc=0 + 回执登记 | |
| 冈子 | 接替 | 每轮复核第一步＝回执扫描（python3 scripts/scan_receipts.py）。🔴 裁决留档：冈子 WIP-226 P0 拟稿补丁（docs/handoff/…冈子拟稿.patch）作废不得 apply——与小冈已落地版冲突，且拟稿把映射表硬编码进 home.ts，违反文案走 site_texts 配置域既定架构 ⇒ 小冈版胜（详见 WIP-226 行尾批注）。🟡 新增两项待办（源自律 8 裁决，见本节纪律区块 + WIP-228 台账 ⑧）：①补交 WIP-224 预审实录 docs/precheck/WIP-224-astra.md——三重实测证明该文件全历史从未入库（git log --all --diff-filter=A 空 + 目录不存在 + 无未跟踪残留），而纪律 8 自身要求留痕，须把实录（含「端点盘点插值失败·astra 未被糊弄」自首段原样）入库后本条纪律才算首例已立 ②回执表态是否接受「分级预审」（必审＝涉钱/生产迁移/跨域契约/C端批量改动/五类必派单；免审＝文案改字/行尾批注/回执更新/单文件卫生批）——原文「每个 AI 接到任务动手前都送审」与 astra 手册「别拿它跑批量小问题·固定开销 4460·502 也计费」冲突，在冈子确认前全员按分级口径办 ③署名须正：纪律 8 自称「小冈令」而入库提交 5300a5c author=冈子，小冈与冈子是两个不同账号身份（身份链铁律禁混署），请改为「冈子立」或写明实际下令人 | — | 可独立派工验收 | |
| 小齐 | 验收+提效 | 验收队列已清空（226 P0/225/223/206 等 9 张全判过关账，扫描器显示「待验」是他们回执未刷新，非派工岗积压）。本轮（00:0x–00:3x）产出：①校正自己给的数字——脚本化闭包递归实测出源文件 181KB（原手工估 110+8KB 偏低）⇒ 图片额度 1867KB（非 1930）、超限 1.74 倍（非 1.71），已同步改 WIP-230 行尾与本节 ②捞出并作废一个错阈值——原写「hero-a~d ≤150KB」实测不可达而不发虚（这些图只降质量 -3% 几乎无效，必须降分辨率），改为 ≤280KB + 全屏背景长边 1200px（真机 430pt×3x=1290px，已达原生分辨率）③给 audit_image_assets.py 补 --mainpack 能力（原判据①写的命令跑不出闭包体积，属派工岗疏漏，已补齐：闭包递归+逐张引用归属+额度+超限倍数，超限 EXIT=1）④沉淀一键脚本 compress_mainpack_images.sh（参数实机试压验证、自动备份、tmp+mv 原地覆盖、末尾自动验证，--dry-run 可先看不改）⑤修四处账面不一致——226 P0/225/223/206 已关账但行头状态列仍挂「待开工/完工待验收」，扫表的人会误判 ⇒ 已对齐批注 ⑥00:3x 点名小冈与波波（两人回执时间 22:0x/21:58 早于派单 23:2x，可能还不知道有 WIP-230 与 WIP-221 退回）。00:3x–00:5x 续：⑦WIP-235 派工岗自持关账（总纲 4 处正文对齐决议 23/16，框图行按 east_asian_width 计宽补空格、手算「宽 6」被自己 assert 拦下实为 5）+ 答复波波三条需求（(a) 主包瘦身单已存在＝WIP-230，且其引用的 3572KB 是已作废口径；(b) 总纲 4 处不必授权、派工岗已自持修完；(c) 服务费口径冲突核实成立、已上报第⑧项）⑧复验小冈两批文档治理提交 ⇒ 判退回并建 WIP-236（抓到「宣称 5 项实落 4 项」＝verify-c.sh blob 哈希与改前相同、41 份 md 改动 0 份 html、报告 4 项口径错误已污染落地动作；同时据实记账通过 4 项与报告成立部分）⑨代补 22 份失步 html（逐份核 mtime 22/22，并抓出自己 while read 漏读最后一行的坑）⑩立纪律 12/13（宣称落地须比 blob 哈希；批量改文档须同步 html 并逐份核产物 + 中文路径一律 -c core.quotepath=false）。下一步：等 WIP-230 批 1 重修后复验（跑 --mainpack + 肉眼比画面 + tsc + 六条复验判据）→ 验 WIP-236 四件事 → 验收 WIP-229/227/228 各批 | P0 | 每张实测证据；凡自己给的数字被更准工具推翻，立即改判据并留痕，不藏 |
✅ 本轮已判过（22:2x 实测，非自报；含派工岗二次代跑）
payment_mode 读写端点：staging 九步全过——读 {payment_mode,change_count:3} / 写 sequence:4 / 非法值 400 / 重复同值 409 / change_count 3→4 递增 / 无 token 401 / DB audit_log 3 条留痕四要素齐（operator_id=159/role=owner/detail{from,to,sequence}/created_at）/ FOR UPDATE 行锁在位 ✅PaymentSettings.tsx:170-174）+ 货类接线真端点 + 留痕计数可见、明细 DB 可查；B端 tsc=0 ✅7431116（20:19）即在位，且该提交是上轮验收 HEAD ec428a8 的祖先，git show ec428a8:…merchant_console.py | grep -c service_fee_paid_at=3 ⇒ 上轮「零命中」纯属派工岗自身失误（HEAD 未对齐），「完工不实第 2 次」记档撤销（阿仁在册回到 1 次）✅workbench-home 涉钱假数据：①-⑤ 全项落地，todayRedeemed/pendingRedeemed 已绑真字段（?? '—' 诚实兜底），违禁样本全归零（古格川菜馆/K20260901042/feeds/12/3 = 0，自检肯定命中词 metric=4 证明扫描有效）✅/merchants/1/presentation 实测 offline_direct_flag=True/note=True，DB 14/14 回填，匿名 200），注脚与 B-011 蓝图逐字一致；禁词归零、路由名未动、同批 9 处非违规项未顺手改 ✅miniapp_orders.py:534 无条件 offline，staging 双例（gate=auto / gate=online_only）均 offline ⇒ 闸门压不住；merchant_mch 全库零命中；退款链路 422 硬拒一致 ⇒ 券款全链路平台零触碰 ✅point_id:"tarqen"，建停闭环）；MyDemands/Profile 真接线键名与后端实测逐字一致；mock 零命中 ✅auth.py:62/82 建号打标源头、merchant_console.py:582 微信支付鉴权、1 处注释）；mockMode:false 符合提审五铁律；🔴 更正小渔「种子回填 FAIL(P1)」为 PASS（053 已在生产执行）；v4 口径校正采纳（表 76→107 静态/109 生产、C端 120→119 目录/118 注册、B端 23→25 路由）✅texts.ts:723 phSearch + home.wxml:17 消费 / texts.ts:770 emoMap + home.ts:152 消费且 display_name 兜底 / product-card.wxss:63 line-clamp:2）；2 条红线排除项守住（会员化/双 CTA 零命中）；C端 tsc=0 ✅053_trial_seed_users_backfill.sql 就是回填 SQL 且已在生产执行 applied_at=12:06，且 053 提交 6479010 早在小渔 v4 基线 c1a5966f 里）；🔴 Major F-23「guest-archive 硬编码假数据」误报（文件仅 76 行，:15 是 type GuestVM 字段声明、:38 是 setData；假客人关键词全 0；mock/假天气 命中均在 L3 注释「…全删」；WIP-202 修复 c6a33e5+dc48285 在位）；B-5 属实但不可达（miniapp_orders.py:755 首行 env != "dev" → 501，生产无攻击面，接真微信支付前须补金额校验 → 已入 WIP-207 前置清单）；W-2 属实 P3（B端 auth.ts:74 expiresDays=30 vs 后端 JWT_TTL_HOURS=24）；B-4 部分属实（miniapp_site.py:88-101 staff 可改站点配置，注释自证是 PLAN-04 B-026 既定口径，若要收紧属口径变更需刘总拍板）；D-1/D-4（credit_journal.direction 无 CHECK / user_wallets.balance 无非负 CHECK）属涉钱五类+生产迁移，待刘总定是否纳入本轮（当前生产 orders=0、wallets=2 行，不阻塞上传）。⇒ WIP-206 关账，遗留项全转 WIP-227/228/229 + WIP-207 前置清单，无悬空1b786c2 审计报告 + 009b77c 五项落地）经提交树逐条实测＝宣称 5 项、实落 4 项（③verify-c 第五项零实现，blob 哈希与改前相同）+ 41 份 md 改动 0 份 html（22 份失步，派工岗已代补 22/22）+ 报告 4 项口径错误已污染落地动作；手法通过 4 项（38 份横幅纯插入零改原文、改名零丢失、引用完整性等长替换语义正确、README 补双文件规则）。退回补 4 件（真写或撤回 verify-c 第五项 / 修 2 处错误横幅指向 / 报告挂更正横幅 / 刷回执），判据 6 条见 TASKS WIP-236 行尾。：app.json 漏注册 2 页致商户工作台两入口点击必失败（详见第二节）⏸️ 缓办：WIP-203（上传后、上线前）｜WIP-207（等刘总给微信商户号 API 凭据）｜WIP-182（待排产，上传后派阿仁）｜WIP-228⑤（键名统一，挂起不单独发版）｜二号（已退场）。
🟡 待刘总拍板／交付（8 项，集中列此便于一次过 · 23:2x 增第⑦项安全与治理 · 00:2x 增第⑧项两条战略口径；第①项已不再是硬缺口——COS 四配置已被代配且派工岗实测通道已通，余四项待清见该项更正段；第①项的「批 1/批 2 可立即执行」已由 23:5x 第三次更正作废）：
①🔴🔴 【最急】COS 四配置＝WIP-230 的唯一缺口，给了才能开工上传段：COS_SECRET_ID / COS_SECRET_KEY / COS_REGION（默认 ap-chengdu）/ COS_ASSETS_BUCKET。实测证据在案（不是推测）：全仓搜 COS_ 只有代码里的 os.environ.get、无任何配置文件写入；230 两容器（kailash-staging-app / kailash-app）COS_ 变量数均=0；容器内 127.0.0.1:8000 直打 /api/miniapp/upload ⇒ HTTP 503「素材存储未配置（COS 密钥缺失）」、耗时 0.0s 快速失败，openapi 确认路由已注册 ⇒ 通道代码完整（刘总 09-01 亲自拍板的素材范式），只差密钥，无需新建基础设施。⚠️ 给了密钥务必同时重启容器并复测——upload.py:26 的 @lru_cache 会把 _cos_client() 返回的 None 缓存住，不重启仍持续 503（astra 预审揪出、小齐读原文坐实）。同时需确认：桶公有读（游客端首屏 hero 必须未登录、无 Cookie/Authorization、冷缓存真机可达）、微信后台配 downloadFile 合法域名、是否加 Referer 防盗链（🔴 Referer 形如 https://servicewechat.com/<appid>/<version>/page-frame.html，放行该域名不能隔离其他 appid、且可伪造、不是鉴权机制）与流量告警（公开 hero 有盗刷风险）。CDN 不是必需（COS HTTPS 公网域名可作一期读取地址），别让包体整改被未准备好的 CDN 阻塞。🔴🟢 23:2x 更正（原文保留留痕，本段为准）：四配置已不是缺口——小冈 22:4x「代配」并已重启两容器；派工岗独立实测结论＝通道确已打通，但其余四项未清。
- ✅ 实测通过（派工岗自造数，非采信自报）：带 token 真打/api/miniapp/upload（自造 69 字节 1×1 PNG）⇒ HTTP 200 / 0.14s；对返回 URL 发不带任何凭据的完整 GET ⇒ 200 /Content-Type=image/png/ 69 字节 / 与原图逐字节相同；匿名列举桶根 ⇒ 403 AccessDenied（公有读边界正确、不能枚举）；两容器COS_变量 各 4/4；桶名kailash-1427423546，appid 1427423546 是项目既有腾讯云主账号（备份桶data-1427423546见docs/生产部署确认单.md:310）⇒ 归属合规；小冈测试对象三路径 全 404＝其自清属实；派工岗自己的 2 个造数对象已删、复核残留 0。
- 🔴 其验证推理不成立（结论对、论证错）：自报「upload 503→401＝配置生效」错——upload.py里 pydantic 校验（422）与鉴权（401）都在 COS 检查（:49-51）之前，不带 token 时无论配没配都返 401「未登录」。实测三档：无 token ⇒ 401、带 token 参数错 ⇒ 422、带 token 参数对 ⇒ 200。⇒ 配置生效的证据是「带 token 真打 200 + 匿名 GET 200 逐字节相同」，不是 401。
- 🔴 请刘总拍板/知悉的四项（批 3「真上传 13 张图」在此之前暂缓）：
- 🔴🔴 23:5x 放行口径第三次更正（前两次「批 1/批 2 可立即执行」作废，本段为准）：批 1 已验收退回、批 2 暂不开工、批 3 仍暂缓——即 WIP-230 三个批次当前全部在等，但等的不是刘总的四项，而是小冈改批 1 的一处 P0 缺陷（详见 TASKS WIP-230 行尾「小齐验收退回 23:5x」）。根因：批 1 的resolveImg()已把后端下发的/images/content/<name>映射成 COS 绝对 URL，而COS 上一张业务图都还没传（派工岗逐个匿名 GET 实测：本地 draft 36 个文件 ⇒ COS 命中 200 0 个、全 404）⇒ 首页推荐区与商品详情封面当下就是破图（改前旧版映射到本地 draft、能出图）。这正是本单判据与他自己清单都写明的「先上传 → 再改引用 → 再删图」顺序约束被违反。⇒ 对刘总的实际影响：无新增待办，四项照旧；批 1 修完（加迁移开关）后批 2 才可开工，批 3 仍须等 (a)(b) 两项安全整改。
1. staging.env权限整改（P0 密钥卫生）：其自报「权限 600 保持」与实测不符——生产/srv/kailash/.env= 600 ✅，但/srv/kailash-staging/.env= 🔴 664（组可读）、目录 755，而getent group ubuntu组成员含www-data与agent-git⇒ 任何能登录 230 的账号（含 git 服务账号）都能读到 COS 密钥明文。要求改为 600 并交stat -c %a回显。
2. 🔴 密钥来源与最小权限未查明（最高风险项）：生产与 staging 共用同一COS_SECRET_ID（sha256 指纹相同b72a1e0514c3d5e9，只比指纹未回显明文）；/etc/passwd-cosfs不存在 ⇒ 无法判定是主账号密钥还是子账号密钥。若是主账号密钥则违反既有基线（docs/生产部署确认单.md:325明写「子账号最小权限，仅授予该桶 PutObject/GetObject/ListBucket」），主账号密钥泄露＝整个云账号沦陷（含每日 03:30 自动备份桶）。请刘总告知这对密钥是谁的、什么权限；若为主账号，须换成仅授权素材桶的专用子账号密钥并轮换（旧钥作废）。
3. 微信后台 downloadFile 合法域名：kailash-1427423546.cos.ap-chengdu.myqcloud.com（小冈自己也列为遗留 ✅）。
4. 桶流量告警 + Referer 防盗链：告警未设；防盗链未核（原判读仍有效——Referer 形如 https://servicewechat.com/<appid>/<version>/page-frame.html，放行该域名不能隔离其他 appid、且可伪造、不是鉴权机制，公开 hero 有盗刷风险，故告警比防盗链更要紧）。CDN 仍非必需。
🟢 但刘总不必等自己给完密钥才有进展：上述 lru_cache 缓存 None 与 :36 缺桶名抛 KeyError、:61 非法 folder 静默落错目录三项修复均不依赖密钥，已拆为 WIP-234 派阿仁可立刻开工（含迁移脚本与两处白名单同步扩）；只有「真上传 + 匿名读取验证」这一段必须等四配置。⇒ 刘总给密钥前，链路已在动。
②D-1/D-4 表约束是否本轮补（credit_journal.direction 无 in/out CHECK、user_wallets.balance 无非负 CHECK，属涉钱五类+生产迁移；当前生产 orders=0/wallets=2 行，不阻塞上传，可留到接真支付前）。
③站点文案是否收紧为仅 admin 可改（现 staff 也可改，是 PLAN-04 B-026 既定口径，非漏洞，收紧属口径变更）。
④WIP-207 微信商户号 API 凭据（缓办中；凭据到位后开工前置清单已含「支付端点补金额服务端校验（B-5）」）。
⑤🆕 主包分包改造是否立项（由 WIP-230 派生 · 21:2x 口径翻新）：大图外置已不再是待决项——刘总 09-08 已拍板「主包的图片要单独在服务器的 cos 上存放的」⇒ 迁 COS 就是既定路线（原「压图 + 是否外置 CDN」的问法作废）。剩下的真问题是分包：118 页全在一个主包、app.json 无任何 subpackages 配置；迁 COS 后上传体积估算降到 1339KB（余量 709KB），但这是「图片全走网络」换来的空间，页面与代码本身仍在增长（本轮 draft 已 36 张、页面 118 个），长期仍会再撞 2048KB 墙。⇒ 是否现在立项做分包改造，属架构变更须刘总点头后另开单。注意：此项不阻塞上传，WIP-230 迁 COS 关账后即可传，本项是中长期架构决策。⚠️ 另：迁 COS 后 ignoreUploadUnusedFiles 与「零引用 22 个 11584KB 不上传」这条依赖关系必须在派工单里显式声明——若哪天该配置被关掉或微信改判定逻辑，上传体积会立刻从 1339KB 跳回 7966KB 以上（这是个隐藏的脆性依赖）。
⑥⚠️🆕 【治理裁决 · 请刘总一句话定】派工/验收权归谁？：小冈 22:3x 回执称「接替生效（刘总 22:18 令）——派工/验收/台账/文档维护归我」，并已按其理解领取 WIP-230/233、产出改造清单。
派工岗核验事实三条：(a) 现行 docs/plans/2026-09-05-小齐→小冈工作交接单.md §9.4 白纸黑字「角色：…冈子=接替小齐」，依据是刘总 09-07 18:22 原令「冈子随时接替你的工作（你的套餐可能要到期了）」；(b) 冈子 22:0x 回执亦称「接替就绪已闭环：交接单 9.2–9.5 与三份接手知识库已读」；(c) 小冈所称「刘总 22:18 令」全仓零记载（grep 全 docs 命中 0）。
⇒ 出现两人同时主张接替、且依据互相冲突。请刘总裁决其一：①冈子接替（维持 09-07 原令）②小冈接替（则须作废交接单 §9.4 与冈子的接替就绪）③维持小齐到套餐到期再交（则小冈该句作废）。
🔴 00:5x 补注·裁决前的事实已变（对刘总的裁决有直接影响）：小冈在裁决之前又连交两批自领提交（1b786c200:30《文档库系统性审计报告》、009b77c00:39「文档库治理五项落地」改 41 份文档），经派工岗复验（见 WIP-236）：第二批宣称「五项全采纳落地」而实测只落 4 项（verify-c.shblob 哈希与改前相同、零实现）+ 22 份 html 双版本失步+ 其报告 4 项口径错误已污染落地动作（其中一处把存档版总纲的读者指向了不存在的文档名）；且两批都未登记 WIP 号（纪律 2 违例）、回执仍停 09-08 22:3x（两批交付均未登记）。⇒ 这正是需要刘总尽快定权的理由：定权前无人对其自领范围与交付质量负责，派工岗只能事后复验退回（本轮已退两批：WIP-230 批 1、WIP-236）；定权后若判小冈接替，则它自领自验、派工岗无从复核；若判冈子接替或维持小齐，则自领提交一律须登记 WIP 号 + 由派工岗复验这条必须写死。派工岗处置：不据 WIP-236 追责「自领」本身（纪律 2 允许自领），只记「未登记 WIP 号」违例 + 交付不实 1 次；横幅制度本身采纳（成本极低、检索一眼可辨，是好主意）。
处置原则（裁决前）：施工权不受影响——小冈的 C 端活、阿仁的后端活照常开工（WIP-230 批 1／WIP-234 ①②③ 均不等密钥 🔴 23:5x 更正：WIP-230 批 1 已验收退回、批 2 暂不开工，见第①项 23:5x 更正段与 TASKS WIP-230 行尾；WIP-234 ①②③ 仍不等密钥、照常开工）；「代派工/代验收」权在刘总回话前任何一方请勿行使（同 09-07 19:2x 注销「阿仁无代派工代验收权」之例，commit 5f86ba2）。本项由派工岗主动上报、不自行剥夺任何一方权利，亦不自行扩权。
🟡 23:5x 补注·术语撞车（防误判，不构成新的权争议）：冈子回执 23:1x 的「批次 0 样板审核完成（有条件通过）」「审核节奏：设计 AI 修正 → 复验 → 放行批次 1」指的是视觉设计 AI 的出稿批次（其任务书 v1.1、GPT6 质感挑战、三端设计语言测试场那条线），与 WIP-230 的「批 1／批 2／批 3」（小冈客户端改造批次）是完全不同的两件事。派工岗已核实：冈子并未对 WIP-230 批 1 行使验收权（WIP-230 批 1 的验收由派工岗做、结论＝退回）。但两套「批次 N」叫法并存极易误读（尤其扫回执的人会以为有人抢了 WIP-230 的验收），⇒ 请两位统一叫法：视觉设计线改称「设计批次 N」或「样板批次 N」，WIP-230 线保留「批 N」；派工岗在自己文档里也一律写全称「WIP-230 批 1」而非裸「批 1」。
⑦🔴🆕 【安全与治理 · 23:2x 新增，请刘总定夺】未登记密钥执行了生产变更，且追溯通道零记录：
.env 修改时间 22:40:19、docker inspect 显示生产 kailash-app StartedAt=2026-09-08T14:42:05Z（＝北京 22:42:05）与 staging 14:42:07Z ⇒ 生产确有约 2 分钟重启窗口（当前 Status=running、RestartCount=0、健康检查通过，未造成遗留故障）。auth.log 22:33/22:39 起三次 Accepted publickey for ubuntu from 100.64.1.88，指纹 SHA256:4TZx0msrc2buZ1UIISeaHwooVheaomLpFTpKFEbQ62Q ＝ authorized_keys 第 1 行、注释 skey-hx9tcfpb（RSA 2048）。而《运维通道与署名链》登记的是：派工岗 workbuddy-yos-deploy（ED25519 / 100.64.1.89）、冈子 gangzi@kailash.ops-2026-09-07（ED25519）⇒ skey-hx9tcfpb 不在登记通道之内。请刘总定：补登记并说明属主，还是收回该密钥？/var/log/kailash-ops/ops.log 最后写入停在 09-07 22:14，本次生产变更未记账；auth.log 该时段只有 sshd 登录、无 sudo COMMAND 记录（ubuntu 走免密 sudo 未触发 pam）⇒ 变更内容与执行人无法从日志还原。这与 09-07 建立追溯机制的初衷相悖，建议补一条纪律：凡 sudo 改生产（.env / 容器重启 / 迁移）必须在 ops.log 记一行，并把 BASH_ENV 追溯覆盖到免密 sudo 路径。.env + 重启生产容器属五类必派之「生产变更」，无工单、无派工。派工岗不据此追责个人（其动机是解 P0 阻塞、结果也确实把通道打通了、且自清了造数），但流程必须补：生产变更须先派工→执行→当日记账。⑧🟡🆕 【两条战略口径 · 00:2x 新增，波波 e068166《项目总纲可行性论证》§五 上报、派工岗实测核实成立】
1. 服务费到底是「月付」还是「签约时收」？——口径缝隙，不定死则任何算账都不成立
- 两侧原文（派工岗逐条实测复核，非采信自报）：总纲决议 15（docs/项目总纲.md:73）＝「服务费档位等一切定价数值=运营参数…总纲只锁结构（固定档位月付制、禁 GMV 抽成已定）」；《试点作战手册》§三（docs/试点作战手册.md:30-:34）＝「服务费收取 SOP（试点期全线下）…商户协议签署 ≥3 家（服务费收讫）（:21）…台账三列 商户名/服务费档位/实收日期/发票号——当日登记，周对一次」。
- 为什么不是一回事（波波判断成立 ✅）：月付＝每月收一笔、要催缴、有续费流失；签约时收＝一次性收、现金流前置、但档位对应「服务多久」没定义。
- 影响面：直接决定商户谈判话术与现金流模型，是商业面能否算账的前提——波波喂给 astra 的模型轮 1 算出「P/v/m/F 四缺三、算不出够活线」，根因正是这个口径没定死。
- 请刘总定：①月付（每月一笔，须配催缴与续费机制）②签约时一次性收（须同时定义「档位对应多长服务期」）③试点期签约时收、正式期改月付（须写明切换时点）。定完由派工岗同步改两份文档口径（总纲决议 15 与作战手册 §三），避免两处继续漂移。
>
2. 本季（9-10 月马年窗口）只保一件事：保「自营锚点跑真实预售券」还是保「领队工具」？——与既有决议方向相反，须刘总定
- 波波建议：保自营锚点（1 家自营 + A 型自营券 + 手工台账 + 拍照留证），领队工具推到淡季。理由＝领队是外部人、本季最忙、配合意愿最低、且客源在拉萨不在本地；自营锚点是自己人、不依赖任何外部配合、今天就能动。
- 模型建议（轮 2）：保「领队付费协作记账 H5」。
- 🔴 与既有决议冲突：总纲决议 16（docs/项目总纲.md:74，刘总 09-01 拍板）＝「业态首打样=领队/分销工作台，判据=能快速盘活整个小程序经济飞轮的核心群体（领队=获客尖刀，灯塔策略启动键），非技术就绪度」；遗留清单第 4 项（:163）同口径。
- 派工岗不代裁：这是战略取舍，不是文档缺陷，拍板权在刘总。波波的马年窗口论据（「客流大但商户最忙，本季不宜做需要商户配合的系统试点」，其回执风险⑤）有说服力，但决议 16 的判据是「商业杠杆」而非「本季好不好推」，两条判据本身不在同一维度上 ⇒ 需刘总明确「本季先验证什么」。
- 请刘总定：①维持决议 16（领队工作台先打样）②本季改保自营锚点（则决议 16 顺延至淡季，派工岗须同步改总纲 M2′ 与遗留清单第 4 项，并注明「本季例外」）③两条并行（须明确各自的最小验证判据与人力分配，当前执行侧产能已被 WIP-230 批 1 重修 + WIP-233 + WIP-234 占满）。
- 附波波同批上报的第三条（已由派工岗自持处理，不需刘总动作）：「主包瘦身至今无人派单」＝该单已存在，就是 WIP-230（小冈 · P0 上传阻塞），且解法已于 09-08 21:2x 换轨为「主包图片迁 COS」；迁后主包账派工岗已算清（1381KB / 上限 2048KB ⇒ 余量 667KB ✅）。最新状态＝批 1 已验收退回（P0 顺序违例·当下破图），批 2 暂不开工、批 3 暂缓 ⇒ 详见第①项 23:5x 更正段。另总纲 4 处正文与决议冲突已由派工岗自持修完（WIP-235 已关账），波波未擅改顶层文档、按契约上报请授权的做法正确。
🔴 上线前必办：生产 system_settings.trial_auto_accept 现为 true（updated_at=2026-09-07 10:02），体验期结束必须置回 false，否则任何真实微信用户登录都被自动打标 is_test=true（会被测试数据清理脚本误删）。执行＝阿仁，时机＝刘总定。
⑧-裁决更新（刘总 2026-09-09 19:16）：「自营锚点 vs 领队工具」不是二选一——全部落地。执行序：自营锚点先行（不依赖外部配合，验证交易链路），领队工具并行推进（决议 16 不变）。波波 §五-2「本季只保一件」建议与模型「只保领队 H5」建议均作废；排期以「全落地、分先后」重排，不再以窗口为由砍范围。「三选一」选项作废。
⑧-二裁（刘总 2026-09-09 19:20）：①G08 上传方式变更——刘总自行用微信开发者工具审核并上传体验版，不走一号 CI/上传密钥流程；一号 G08 构建上传职责解除；version-ledger 登记改为「刘总上传后口头报版本号」轻流程（或按刘总意愿取消）。②E4 值守人=运营排班事项，非系统实现项——不写代码、不进配置，刘总口头/微信定人即办结；从技术待办清单移除，归类运营侧。此前「待刘总定人」的表述按此修正。
⑧-三裁（刘总 2026-09-09 20:51，四拍板全落）：①自营锚点=城堡酒店（merchant 1）②管理后台=独立 Web ③服务费口径=档位额度×周期线下约定（协议模板/总纲 #15/台账三处修订待落）④长线任务序列已建（WIP-241-248：阿仁线锚点闭环/管理后台后端/福钥后端；一号线 C 端视觉收尾/管理后台前端/B 端收敛/组包+领队工作台/福钥前端）。⑤人力：两人负载偏紧，刘总授权二号与小渔可加入——小冈评估：二号宜在阶段二入场承接管理后台前端（一号专注 C 端+锚点），小渔维持审计线；入场时点待阶段一跑完按实际速率定。
⑧-四裁（刘总质询 2026-09-09 20:56 · 小冈认错修正）：WIP-241 原「城堡酒店配置入库+补 packages」=把运营决策编码化（第二次犯）——锚点选择是上线后运营决策（随时可换），系统只做能力。修正：①WIP-241 去「城堡酒店」具体化，改「任意商户可成锚点」的系统能力 ②管理后台「商户+商品管理」最小子集提前至阶段一（先于锚点验证），阶段二保留完整后台 ③阶段一验收判据改为「刘总自助配置任意锚点后真实订单全链可跑」。
⑧-六登（小冈 2026-09-09 21:5x · 验收岗空档处置）：小齐退二线、冈子接收待刘总指定的空档期，复验职责由小冈（派工岗）兼任——波波 WIP-237 交付、在途包验收均由小冈执行；冈子被刘总正式指定后即移交。同时登记：纪律 11 事故第三次（2be68c4 删波波批注，根因=编辑脚本 c/lines 双模型混用）——单次脚本禁混用两种编辑模型已入 TOOLS 禁令。
⑧-五裁（刘总 2026-09-09 21:0x 纠正）：①演示数据=工程交付物——阶段收口=代码完成+is_test 演示数据入库+全流程可操作演示（从某页点到某页能点通，不是静态页面）；此前「提前写死+替决策」是错法，「阶段后插演示数据」是正法 ②「可操作的系统级小程序」=验收根本标准（tsc/verify-c 绿≠完成，可点通才算）③真实锚点/真实价格=运营决策（上线后自助录入）；演示数据=验证用（is_test 标记），两者分离。
⑧-三裁（刘总 2026-09-09 20:51，四拍板全落）：①自营锚点=城堡酒店（merchant 1）②管理后台=独立 Web ③服务费口径=档位额度×周期线下约定（协议模板/总纲 #15/台账三处修订待落）④长线任务序列已建（WIP-241-248：阿仁线锚点闭环/管理后台后端/福钥后端；一号线 C 端视觉收尾/管理后台前端/B 端收敛/组包+领队工作台/福钥前端）。⑤人力：两人负载偏紧，刘总授权二号与小渔可加入——小冈评估：二号宜在阶段二入场承接管理后台前端（一号专注 C 端+锚点），小渔维持审计线；入场时点待阶段一跑完按实际速率定。
docs/receipts/<名字>.md——在做 / 进度 / 卡点需求 / 下一步 / 风险 五段。需求只认回执，不认口头（要人、要数据、要权限、要拍板都写进去，派工岗负责上报盯办）；不写回执 = 视为无进展；派工岗每轮派工前先扫回执再派，避免再出现"人家早改了我还在判未修"。applied_at=12:06）；054 已派 WIP-227（阿仁，dev_ 前缀漏标回填）；下一可用号 = 055，领号找小齐/冈子，不得自行占用。 🔴 09-08 01:2x 升格：WIP 工单号同受本纪律管辖，且「建单前必先 git fetch 扫远端占用」适用于派工岗自己（纪律 6「先对齐 HEAD」此前只当验收纪律用，现扩到建单）。事故留痕：本轮派工岗建单用了 WIP-231，但扣子一号已于 01:06 e6e400c 自领 WIP-231（auth.ts token 缓存 30 天→1 天，其自领合规），我 01:2x 建单未先扫远端 ⇒ 同号不同事。按先到先得处置：一号保留 231，本单让号 WIP-233（232 未被占，保留），已在 TASKS/NOW/回执/提交信息全量改号 + 撞车留痕批注 + --amend 改提交信息（仅在未推送时安全）。责任在派工岗，不涉一号。建单前置动作（固定三步）：①git fetch origin main ②git show origin/main:docs/TASKS.md | grep -aoE "WIP-2[0-9]{2}" | sort -u 取已占号 ③取最小未占号；自领者也照此办（一号本次就是按纪律 2 登记 + 不抢 P0，属合规）。git fetch + git reset --hard FETCH_HEAD ②零命中时用肯定命中词自检（如查 service_fee_paid_at 零命中，先确认同文件 payment_mode 有命中）③必要时用 git show <HEAD>:<path> 查该版本时点的文件内容，而非工作区。已造成 4 次冤案：小渔「闲置」、小冈「mock 未清」（两次点名）、阿仁「三列透传未做」（记了完工不实第 2 次，本轮已撤销）。根因完全相同＝拿过期 HEAD 下结论。macOS 环境一律 grep -aE 或 Grep 工具，禁 BRE \|（静默失效）。【小齐 23:1x 补记：纪律 6 的新变种＝并行工具调用竞态，本轮差点造成第 5 次误判】 派工岗在同一批里并行发出了 git fetch origin main 与依赖它的 git show origin/main:<path> | grep 核验 ⇒ 核验读到的是 fetch 完成前的旧 origin/main 引用（冈子 5549114，里面仍是「七条纪律」），于是「八条纪律」在远端零命中，看起来像我的改动没落库。分辨手法（三步，缺一不可）：①换肯定命中词自检——查 ^## 三、 取标题行实际内容，立刻看到是「八条纪律」而非缺失，说明是引用滞后不是内容缺失 ②落地到临时文件再查（git show > /tmp/x.md 后 grep），排除管道/编码因素 ③串行重跑（fetch 与核验分成两次调用）后全部命中。⇒ 规矩：git fetch 与任何依赖 origin/* 引用的读取禁止并行发出，必须先 fetch 返回、再核验；「落库失败」类结论同属纪律 6 前置三步管辖，先自检再定论。【小齐 09-08 00:5x 补记第三个变种：显式 URL 推送后 origin/main 引用不更新】 本项目铁律要求推送必显式 URL（git push https://<user>:<token>@doc.kailashi.cn/git/kailash.git HEAD:main，禁 SSH），而显式 URL 推送成功后 git 不会更新本地的 origin/main 追踪引用（git 无法判断该 URL 属于哪个 remote）⇒ 紧接着用 git show origin/main:<path> | grep 核验会读到推送前的旧版本，表现为「推送明明成功（78e2229..fce6aab 已回显、git ls-remote origin main 也显示远端 HEAD 已是我的提交），但远端内容全部零命中」，极易误判成「改动没落库」而重复提交或错误告警。本轮派工岗自己就中招一次（9 项核验全零，含刚入库的脚本「exists on disk, but not in origin/main」）。分辨手法（三步，同前）：①git ls-remote origin main 取远端真 HEAD 与本地 HEAD 比对——相等即已落库，这一步不受追踪引用滞后影响，是最硬的判据 ②自检 git log -1 origin/main 看它停在谁的提交（停在别人＝引用滞后，不是内容缺失）③串行重跑 git fetch origin main 后再核验，全部命中。规矩（追加）：**显式 URL 推送之后、任何 origin/* 内容核验之前，必须先单独 git fetch origin main 刷新追踪引用；或直接改用 git ls-remote origin main 比 HEAD 作为「是否落库」的判据，不得用滞后的 origin/main 内容零命中来断言「没推上去」。【小齐 09-08 01:0x 补记第四个变种：验收别人的提交，扫错树】 第三个变种是「推送后引用不更新」，第四个是「验收前工作区未对齐」：小冈 5f24cfb 已在远端，但派工岗本地 HEAD 仍停在 fce6aab（未 fetch、未 rebase），于是直接对工作区文件跑 grep -raicF -e "#ff4d4f"，扫到的是改动前的旧文件，得出「残留 18 处、小冈只改了 12 处」的错误结论，差点据此开出「执行侧漏改 6 处」的冤案（真值＝改后仅剩 5 处，且小冈那 12 处替换全部生效）。分辨手法：验收他人提交，一律在提交树上扫，不扫工作区——git fetch origin main 后用 git grep -aiE 带 rev 扫（git grep -aiE "#(1890FF|52C41A|FAAD14|FF4D4F)" origin/main -- miniprogram/miniprogram）；要看「改前 vs 改后」就分别扫两个 rev（… fce6aab -- … 与 … origin/main -- …），两次都带 rev，完全不依赖工作区状态。规矩（追加）：验收前置第 0 步＝确认被验收的提交已在本地某个 rev 上，且 grep 命令里写明该 rev；「工作区 grep 结果」只能用于自己尚未提交的改动，禁止用于判定他人交付。另附本轮两个工具层坑：①git grep -E 里的 | 是正则交替、不是裸竖线，在 -E 下安全（与工作区 grep 的 BRE \| 陷阱不同），但仍一律加 -a 防二进制误判 ②zsh 里 set -- $p 不做词分割（未加 -o shwordsplit），要拆成多参数须用 ${=p} 或逐条显式调用，本轮 --pair A B 传参因此失败一次。【小齐 09-08 02:0x 补记：计「次数」必须用 grep -aoF … | wc -l，grep -c 计的是行数】 本轮派工岗自己又踩一次：文档与提交信息里写的「NOW.html 污染 36 处 / 小齐.html 7 处 / 小冈.html 2 处」全是 grep -c 的行数，而这些 HTML 一个段落挤在一个超长行里，真实出现次数是 1116 / 1232 / 18（差 31 倍、175 倍、9 倍）；同理「全库 19 份合计 2948 处」也不成立——实测真值＝修前全库 152 份 HTML 中 21 份受污染、合计 5216 处（2c89920 批 2 份 2348 + 8c11e98 批 19 份 2868，两数相加自洽）。⇒ 规矩：报「N 处」必须是出现次数，命令固定为 grep -aoF "<字面量>" <file> | wc -l（-o 每命中输出一行）；用 grep -c 得到的一律称「N 行」，禁止写成「N 处」**。docs/precheck/<工单号>-astra.md，开工登记行尾注明「已阅预审」并逐条写明采纳/反驳——预审意见不采信自报，双向适用；不能出网的沙箱由派工岗代审。首例：docs/precheck/WIP-224-astra.md（含材料缺陷自首：端点盘点插值失败，astra 未被糊弄）。> 【🔴 小齐 23:0x 派工岗裁决：采纳精神、修正口径三条（逐条实测，全文见 WIP-228 行尾同批注）】
> ① 分级预审，不再「逐单必审」：原文「每个 AI 接到任务，动手前」＝无例外逐单强制，与 astra 手册 :101「别拿它跑批量的小问题（固定开销 4460 不划算）」直接冲突；该通道另有 120 秒硬超时（🔴 21:2x 实测更正：此说法只在 effort=high 档成立——medium 档实测 163.3 秒成功、finish_reason=stop、HTTP 200，见手册 v1.2 与纪律 10）、502 失败也全额计费。⇒ 必审＝涉钱 / 生产迁移 / 跨域契约 / C端页面批量改动 / 五类必派单（WIP-227、WIP-229 属必审）；免审＝文案改字、行尾批注、回执更新、单文件卫生批（WIP-228①②④ 属免审）。审前查额度，连续 2 次 502 立即停 + 退避≥10 分钟 + 降级免费通道，禁为凑留痕空烧。🟢 21:2x 补充：本轮 WIP-230 属必审类（C端批量改动 + 跨域契约），已按本条完成预审并入库 docs/precheck/WIP-230-astra.md（纪律 8 首例实物证据到位——此前冈子自称首例 WIP-224-astra.md 全历史从未入库，仍责令补交）。
> ② 首例证据文件不存在，责令补交：git log --all --diff-filter=A -- docs/precheck/* = 空（全历史从未入库）、ls docs/precheck = No such file or directory、git status --untracked-files=all = 干净（排除"忘提交"）⇒ 一条要求留痕的纪律当下无一份实物可核。不废纪律，责令冈子补交 WIP-224 预审实录（含「端点盘点插值失败」自首段原样留痕），入库后方可称首例已立。
> ③ 署名须正：条文自称「小冈令」，但该纪律入库提交 5300a5c 的 author=冈子。小冈（C端执行）与冈子（派工岗候补）是两个不同账号/身份，按身份链铁律（子 agent 禁顶他人身份）不得混署 ⇒ 请冈子确认本条系自拟，并把「小冈令」改为「冈子立」或写明实际下令人。
grep -c 行数口径冒充出现次数（真值 5216 处 / 1116 处）。三条硬要求：(a) 报数必带口径（出现次数 / 行数 / 份数 / 字节 / 闭包）；(b) 报数必带可复跑命令或脚本（如 python3 scripts/fix_html_double_escape.py --list、audit_image_assets.py --mainpack），他人能一键复核；(c) 派工岗给出去的数字，自己先跑一遍——账面数直接进派工单会让执行侧照错目标返工（本轮「33 处」即让 G10 第一批的目标从一开始就不准）。已推送的提交信息发现错数不改历史（8c11e98 的「2948」保留原样），但必须在文档 + 脚本注释留痕纠正，并据实归功（TASKS.html 的 8598 处污染是一号 e6e400c 顺手清零的，不是我修的）。 > 🔴 21:2x 增补两个变种（同一条纪律，第四、第五实例）：④ 口径翻案——同一对象换了统计口径却沿用旧标签：「主包 3572KB」其实是最小必需闭包下限，被当成上传体积报了好几轮，真值 7966KB（差 2.2 倍）⇒ 规矩：报体积/规模类数字必须写明「量的是哪个集合、扣了什么、由谁计量」（本地 du / 脚本闭包 / 微信工具计量 三者不可互换）。⑤ 四则运算错——「余量 708KB」，实测 2048−1339=709；「超上限 3.9 倍」，实测 7966/2048=3.8896 ⇒ 规矩：加减除的结果一律用命令算，不心算（python3 -c "print(2048-1339)"）；中文「超 N 倍」有歧义，改写为「为上限的 X 倍」或「超出 Y%」。两处均由 astra 预审纠出，不是我方自查发现的 ⇒ 见纪律 10。
effort=medium、--timeout 别用默认小值、材料 ≤200 行）。并行后台跑，人同时做文档与实测，不再串行等。git grep、author=committer 身份链核验——这些是「跑命令取回显」，模型没有手、碰不到服务器。「不采信自报」这条纪律对模型输出同样适用：模型说「已修复」「无问题」一律不算数。docs/precheck/WIP-230-astra.md）：astra 揪出派工岗自己 5 处错——2 个后端真 bug（upload.py:36 缺桶名抛 KeyError 逃逸 503 降级；@lru_cache 缓存住 None ⇒ 补配密钥后不重启仍持续 503）+ 1 个方案性误判（我把「wxml 静态 src 可直接写 HTTPS URL」错写成「必须改数据绑定」，把工程选择写成了技术约束）+ 2 个数字错（见纪律 9 ④⑤）。⇒ 结论：这条纪律对派工岗自己同样有效，且模型审比人审更容易抓到自己看不见的前提错误。effort=high 档成立，medium 档实测 163.3s 成功（finish_reason=stop）；②max_tokens 不是硬截断——设 3500、实测 completion_tokens=5344（超 53%）⇒ 控输出体积只能靠指令限定条数/字数。③手册 §9.1「单次判据点 ≤2 个」偏保守：实测单次喂 3 大段、15+ 判断点成功 ⇒ 拆题理由改为「控输出质量与便于逐段人工核」，非避超时。grep 命令）⇒ 文档内不复写禁传关键词字面量，改为指向手册 §六。docs/TASKS.md / docs/NOW.md 的长行（工单表格行）必须脚本化「读全文 → 定位该行 → 只在行尾追加 → 写回」，禁用编辑器整行替换或截断式粘贴（小齐 09-08 23:5x 立，因同类覆盖事故已发生两次）：事故一（22:5x 发现）：小冈 b9f155c/ca19d96 提交把派工岗 21:2x 批注尾部整段截断覆盖（丢了「③远程依赖上线后缺真机故障验收…—— 小齐 21:2x」）。事故二（23:5x 发现）：小冈 ef3e64c 在 WIP-230 行追加批 1 登记时，把该行既有的「④遗留」整段删除（实测 git show ca19d96:docs/TASKS.md 命中 1、git show a2b78db:docs/TASKS.md 命中 0）；同时因派工岗 22:5x/23:2x 批注（合计 6370 字符）尚未推送，若直接以对方版本为准就会永久丢失。事故三（2026-09-09 22:0x 波波发现并恢复）：小冈 2be68c4（「刘总质询修正」）把 WIP-236 行内波波的 823 字符复核批注整段删除（实测 git show 669fd0c:docs/TASKS.md 命中 1、git show 2be68c4:docs/TASKS.md 命中 0，author=committer=小冈），根因＝编辑脚本用 c.find('⑨') 定位、返回 -1 时 c[:-1] 静默截断（与 4d3ce02 自述的第二次事故同根因）。🔴 第 3 次「宣称落地零实现」记档（纪律 12 同族）：4d3ce02 提交信息声称「纪律 11 升级：长行插入禁用 find 返回 -1 的定位，必须行号锚定+assert」，实测该提交对 NOW.md 的 diff 只新增「⑧-三裁/四裁」两段、纪律 11 正文零改动（改后 grep -c "禁用 find" docs/NOW.md = 0、grep -c "行号锚定" = 0）；前两次同族＝WIP-230 批 1「双保险回退」宣称不成立、WIP-236「verify-c 第五项」宣称落地而 blob 哈希未变。下方规矩⑥即为该升级的真实落地（波波 09-11 执行，刘总 09-09 授权），与配套硬闸 check_tasks_table.py --fingerprints 同批入库、且已过缺陷注入自测。 > 为什么肉眼与 git diff --stat 都发现不了：工单批注全部挤在一个超长单行内（WIP-230 行合并后达 24192 字符），--stat 只报「1 insertion(+), 1 deletion(-)」＝看起来只改了一行，实际行内被删掉几千字符（同纪律 9 的「口径」问题：量的是行数不是内容）。
> 规矩（全员适用，含派工岗自己）：①改长行一律用脚本（python 读全文 → 按首列工单号定位该行 → 行尾追加 → 写回），不要用编辑器整行替换、不要从别处粘贴覆盖；②追加前先 git fetch 并把远端该行与本地该行做「公共前缀 + 各自独有段」比对，若远端有己方没有的段 ⇒ 先三方合并再写，禁直接覆盖；③合并后必须逐段 assert（每个历史批注的关键句命中恰好 1 次、竖线数不变、行首行尾格式不变）通过后才允许写盘——本轮 13 项断言中曾有 1 项因新批注里引用了原句字面量而误报命中 2，改法是把引用改成描述式（计数口径要求字面量唯一，同纪律 9）；④提交前必跑 python3 scripts/check_tasks_table.py --diff-head（已入库）确认没把别人的内容带走、没引入列错位；⑤派工岗的批注写完必须当批推送，不得留在工作区过夜（本轮正是「批注没推 ⇒ 对方看不到要求 ⇒ 按旧版本施工 ⇒ 又覆盖我方」的连环）。⑥长行定位禁用 find()/index() 的返回值直接切片——c.find(x) 未命中返 -1，此时 c[:-1] 会静默截掉最后一个字符、c[i:] 会从倒数第一字符开始，两种都不报错（4d3ce02/2be68c4 两次事故同根因）；必须行号锚定：先 hits=[i for i,l in enumerate(lines) if l.startswith('| WIP-xxx ')] 取行号、assert len(hits)==1，再对该行做行尾追加（line[:-1].rstrip()+note+' |'），写盘前逐段 assert（既有批注关键句各命中恰好 1 次 + 竖线数不变 + 行首行尾格式不变 + 防重放）。为什么 assert 真能救：波波本轮被自己的 assert 在写盘前拦下 4 次（f-string 内嵌 len() 语法错／举证文本引用了被断言的字面量致计数为 2／断言预期把续行内容当成主行内容／自测样本按指纹段数而非锚点数筛选），四次文件均未污染——assert 的价值不在「通过」，在「拦下时文件还没坏」。⑦配套硬闸（波波 09-11 同批入库，已实现非宣称）：python3 scripts/check_tasks_table.py --fingerprints ＝ 历史批注指纹校验，把 HEAD 版每个 WIP 行按「署名+日期时间」锚点切成批注片段逐段算 sha1，断言 HEAD 片段集合 ⊆ 当前集合（追加只增不减，故合法行尾追加不报警），指纹消失即报「疑似覆盖丢失」并 exit 1 ⇒ 让覆盖事故从「无报错」变成「必报错」；合法删改（如删自己误注入的重复段）加 --allow-loss 显式放行并在提交信息写明理由。改该脚本后必跑 --selftest（缺陷注入自测：A 删中段片段／B 整行消失 须 exit 1、C 合法行尾追加 须 exit 0，三类同时满足才算工具有效）——这套自测当初就抓到本工具自身两个真缺陷（时间锚点不认 23:5x 的 x 占位、片段尾部装饰符未归一化 ⇒ 合法追加被误报），验收工具本身也要被验收（小齐 00:5x 立的口径）。
> 性质认定：不追责个人（两次都不是恶意，都是长行编辑手法的必然结果），但手法必须换——这类事故的代价是别人的验收结论与待办清单凭空消失，而消失后没有任何报错。
files changed 总数（小齐 09-09 00:5x 立，因 WIP-236 抓到「宣称 5 项实落 4 项」）： > 教训：009b77c 提交信息称「治理五项全采纳落地…③verify-c 增第五项状态倒挂扫描」，写得极具体（连基线规则与「后续随批扩展」都写了），而实测 docs/tools/verify-c.sh 在本次 diff 中零改动——git diff --stat 报「41 files changed, 85 insertions(+), 2 deletions(-)」，总数完全正常、看不出少一项，因为 --stat 对「未变的文件」根本不报（纪律 9 的口径问题再现：量的是「变了多少」，不是「该变的有没有变」）。
> 规矩（可复跑，全员适用）：宣称改了某文件 ⇒ git rev-parse <基线>:<路径> 与 git rev-parse <新提交>:<路径> 两值必须不同（相同＝零改动＝宣称不实）；宣称加了功能 ⇒ 对该文件 git show <新提交>:<路径> 后数行数与 grep -acE <关键词>，两个数都要能被命令还原；宣称批量处理 N 份 ⇒ 数产物份数（本轮靠「新增含 ⛔ 的行恰好 38 行、分布 38 份」证实了①项、也靠同法证伪了③项）。不追责「说错」，但「说了没做」必须当批退回——本轮第 2 次同族（WIP-230 批 1「双保险回退」宣称亦不成立）。
> 两条教训同一批：①009b77c 改 41 份 md、0 份 html，其中 22 份有同名 html 在树却未重生成 ⇒ 读者打开 html 看不到横幅、md 里有，同一文档两个版本口径不一致，正是该批要治的病本身（违反铁律「md/html 双版本同步」）；补法成本为零：for f in ...; do python3 scripts/md2html.py "$f"; done（单参数）。②派工岗代补时自己踩坑：while read -r f; do …; done < 清单 会漏读最后一行（清单末尾无换行符时），首次跑只成功 21/22，靠「逐份核 mtime」才发现第 22 份 603407 秒未更新 ⇒ 批量操作完成后必须逐份核验产物（mtime/哈希/份数），不能只看循环回显的成功计数。
> 🟡 附一条工具口径（派工岗本轮自查、坑清单第⑨条升格）：凡含中文路径的 git ls-tree / git grep / git show 一律显式加 -c core.quotepath=false，否则中文被转义成八进制 ⇒ grep 字面量与 .endswith(".md")（转义后行尾是 .md"）双双假阴性。本轮派工岗首核 docs/ 规模时漏加，算出「22 份 md／58 万字符」并当场判「报告称 213 份不实」——这个结论是错的，补参数后得 215 份／184.8 万字符（报告基本准确） ⇒ 零命中或量级异常时，必须先怀疑自己的命令、再怀疑别人的数据。
> 🟢 附核验工具（小齐 00:5x 入库·提交前必跑，与 check_tasks_table.py、fix_html_double_escape.py 并列）：python3 scripts/check_md_syntax.py --diff-head <文件…> ＝ markdown 语法体检，只报相对 HEAD 新引入的问题（历史债自动抑制），覆盖七类：bold_odd（ 计数为奇＝粗体未闭合）、star4（*/** 连排＝闭合星紧贴开启星缺空格）、glue（标题黏连）、fence（代码围栏未闭合）、conflict（行首冲突标记）、backtick（反引号为奇）、bare_pipe（TASKS 工单表列数 ≠ 6）。为什么必须固化成脚本：本轮派工岗自己验收 markdown 时连踩三次口径坑——①判四星若先删反引号代码段，会把合法的「粗体包行内码」误拼成四星＝假阳性；②判关键词是否进了 html，若不同步去掉 md 语法符与 html 标签，则「## 三、…」在 md 命中、在 html 变标题标签后零命中＝假阴性；③工具自身的 diff-head 过滤一度用集合差，历史债行已有同一条 star4 便把新注入的 star4 静默放过（自测注入 3 类只报出 1 类），改成多重集差 + 行签名才归因准确 ⇒ 验收工具本身也要被验收**：造缺陷注入自测，确认「0 问题」是真没问题、而非工具失效。
## ⚠️ 本节部分失效（2026-09-28 时效治理 · 冈子核实）
>
① 行号引用已失效：本节原引「代码层无条件（miniapp_orders.py:534）」——实测该行现已
是福钥冻结逻辑，不是券款强制线下。行号类引用随代码演进必然失效，核验时请直接搜代码，勿信行号。
>
② 语义已演进：本节写「券款（预售券）→ 强制线下」，但当前代码已含
平台自营 1P（online）/ 商户 3P（offline）双轨拆单逻辑（miniapp_orders.py 拆单分组 +
platform_payment_gate 全局总闸），不再是「一律线下」。>
③ 仍有效的部分：orders.payment_mode/merchants.payment_mode的取值域（见下方迁移文件）
与「平台零触碰券款资金」原则。
>
核验真源：backend/sql/025_order_domain_dual_track.sql（orders 约束）、
backend/sql/040_dual_track_keys.sql（含 mixed）、backend/app/routers/miniapp_orders.py（运行时逻辑）。
1111804382，采购关系须签协议）或线下收费。orders.payment_mode CHECK('online','offline')；merchants.payment_mode CHECK('online','offline','mixed')，默认 offline。沿用库内值，不为此发迁移。库内值 ↔ 刘总规则口径对照（WIP-223/225 验收依据，禁再凭文档推断）
| 刘总终版规则 | 库内实际值 | 语义 | 强制方式 |
|---|---|---|---|
| 券款（预售券）强制线下 | orders.payment_mode='offline' | 商户线下收，平台零触碰 | 代码层无条件（miniapp_orders.py:534，无视 gate 与商户开关）；B 端券类区块不显示开关 |
| 商品类·线下收费 | merchants.payment_mode='offline' | 同上 | 商户在 B 端自选（WIP-223 已交付） |
| 商品类·平台采购模式 | merchants.payment_mode='online' | 钱进平台自有商户号 1111804382，须签采购协议（采购价+结算周期） | 商户在 B 端自选，切换落 audit_log 留痕（WIP-225 已交付） |
| （历史值，未启用） | merchants.payment_mode='mixed' | 商户同时有两种品类，下单时按品类定 | 当前商品类订单路径未建，兜底 offline 不 reject（波波 R1-2 决策表，WIP-208 已判过） |
merchant_mch | 已作废（刘总「只有两条路」） | 全库零命中（WIP-222 已清） |
⚠️ 库内无 platform 值——「平台采购模式」在代码中就是 online。不为此发迁移（遵 09-07 实测真值定案）。B 端界面文案对用户显示「平台收款 / 线下收款」，不暴露库内枚举名。
5f86ba2），派工权与验收权归派工岗。page.$('.cf') 只查页面直连元素，自定义组件内部元素必须先取组件标签再下查（page.$('m-content-feed').$('.cf') ✓ 实证 cf-item=3）components/foundation/f-gallery/ 已落五版式（uniform/masonry/quilted/strip/stack）+ 空态铁律兜底；三页重排版式一律走 f-gallery，页面只组合禁手搓（刘总 17:59 令）。modules/m-image-gallery 已改纯委托 f-gallery；DSL 配置 layout:'scroll'/'grid' 继续可用（别名映射 scroll→strip、grid→uniform 在组件内做，A 端已存配置不受影响）。feedItems（{src,title,sub,id}），chips 未动（filterpills 替换另单）。pages/debug-gallery（dev-only 不进 tabBar）+ 复验脚本 scripts/shot_fgallery.cjs（automator 端口 9451；mp.close() 会关端口须重挂 cli auto）。