admin/danyang-match
1
0
Fork 0
Code Issues Pull Requests Actions 1 Packages Projects Releases Wiki Activity
129 Commits 2 Branches 8 Tags
d9c08d85f949a38c7b7bf1e013fb3f56ca1f7492
Commit Graph
7 Commits
Author SHA1 Message Date
WorkBuddy b67a56479e fix(miniapp): 修 P0 请求层崩溃（一个下划线致所有请求卡死）+ 组件 WXSS 违规选择器，再补 3 项门禁 
═══ 缺陷 1（P0，运行期）：utils/api.js 成功回调调用不存在的方法 ═══

控制台：
  TypeError: _this._releaseIdempotencyKey is not a function

根因：类中定义的是 `releaseIdempotencyKey()`，成功回调写成了
`this._releaseIdempotencyKey(...)`（**多一个下划线**）。

**为什么一个字符的笔误是 P0**：该调用位于 `wx.request` 的 success 回调内、
且在 `resolve()` **之前**。抛错 → `resolve` 永不执行 → 该 Promise **永不 settle**
→ 所有页面永远停在 loading，同时 App.onError 刷屏。
即「一次成功请求」本应推进流程，实际把前端整成不可用。

修复不只是改名，而是纠正结构：
- **先 `resolve(body.data)`，再执行收尾动作** —— 收尾逻辑不允许挡在响应路径上；
- 释放动作自带 try/catch + console.warn：释放失败最多是"下次操作没拿到新键"，
  不得升级为业务失败。
- 语义未变（勿改）：成功→释放（下次同域操作是新的一次）；失败→刻意不释放
  （重试复用同一把键，后端才能识别重复投递）。

═══ 缺陷 2（编译期警告）：组件 wxss 用了标签选择器 ═══

  Some selectors are not allowed in component wxss ... (components/recommend-card/index.wxss:1:1092)

实测违规 1 处（23 个组件样式文件全扫）：`.compact-like image` —— 组件 wxss 只允许类选择器。
改为 `.compact-like__icon` 并**同步在 WXML 补上类名**
（只改 wxss 会让样式静默落空，是另一种"假成功"）。

═══ 门禁：15 → 18（既有的全是源码内容断言，抓不到上述两类）═══

- 第15 `wxml-structure-contracts`（上一提交新增，本轮 MIN_GUARDS 基线顺带对齐）
- 第16 `miniapp-self-method-contracts`：扫描 `this._x(` / `self._x(` 等私有调用，
  要求同文件有定义（方法简写 / 类字段 / `this._x = 值` / prototype 四种形态）。
  **判据先自证假阳性**：首版正则不允许 `.` 前缀，把 `this._unsub = store.bind(this)`
  形式误报为未定义（3 个页面）；修正并加反向自检样例固化了该坑。
- 第17 `wxss-component-selector-contracts`：组件 wxss 禁标签/ID/属性选择器。
  **作用域刻意只限 miniapp/components/**（page 的 wxss 允许标签选择器，套上去必有误报）。
- 第18 `miniapp-api-client-behavior`：**唯一的行为断言** —— 桩掉 `wx.request` 真跑 api.js，
  验证成功 resolve / 失败 retain 键 / 成功 release 键 / 收尾抛错不影响响应路径 4 组。
  含 1s settle 超时，直接编码"永不 settle"这一失败模式。
- 新增 `scripts/lib/wxss-selectors.mjs` + `scripts/check-wxss-component-selectors.mjs`（CLI）。
- `MIN_GUARDS` 15 → 18；执行器措辞改为「源码结构与关键行为断言」。

═══ 验证 ═══

- `node scripts/run-ui-contracts.mjs` → **PASS 18 / 18**，退出 0；
- 负向注入：未定义私有方法 / 标签+ID+属性选择器 / 多余闭合标签 → 均精准变红，
  且**合法样例（`this._x = 值`、纯类选择器、属性内含 `>`）不被误报**；
  行为守卫的负向自证见下一提交/记录；`UI_GUARDS_MIN=99` 拒绝报绿。
- 文档口径同步：AGENTS.md、STATUS.md（4 处当前口径 + 新增 1.1.0-rc.18 行）、ci.yml 注释。
- **未验证**：微信开发者工具真实编译与真机渲染（本机无该环境）。
 2026-09-19 11:40:38 +08:00
WorkBuddy d036c9b986 fix(miniapp): 修复 2 个页面 WXML 结构缺陷，并补第 15 项门禁（WXML 结构守卫） 
现象：微信开发者工具报
  [ WXML 文件编译错误] ./pages/service-history/service-history.wxml
  get tag end without start, near `</`

真实缺陷（实测 2 处，非 1 处）：
- pages/service-history/service-history.wxml 多 1 个 </view>
- pages/service-program/service-program.wxml  多 1 个 </view>
（均为单行压缩写法，随更早提交入库；全仓另外 84 个 WXML 结构自洽）

根因不是这两个文件写错，而是**门禁覆盖盲区**：
既有 14 项 UI 契约全是「源码内容 / 清单断言」，没有任何一条会解析 WXML，
所以「14/14 全绿」与「小程序能不能编译」之间没有因果关系。

修复：
1. 删掉两处多余闭合标签 → 86 个 WXML 结构全部自洽。
2. 新增 scripts/lib/wxml-structure.mjs：按**引号状态机**逐字符扫描标签。
   不能用懒惰正则 —— 属性值里可以合法出现 `>`（`subtitle="{{unreadTotal > 0 ? ...}}"`），
   正则会在引号内的 `>` 处提前收尾，把自闭合标签的 `/` 读掉，报出假阳性。
   （首版实现即踩此坑，曾把合法的 messages.wxml 误判为坏文件；已复核排除。）
3. 新增 scripts/check-wxml-structure.mjs（CLI，退出码 0/1/2）。
4. 新增 ui-tests/wxml-structure-contracts.mjs：全量扫描 + **3 组内置自检样例**
   （正向样例故意在属性值内放 `>`，把「假阳性」这个坑钉进门禁）。
5. scripts/run-ui-contracts.mjs：MIN_GUARDS 14 → 15（守卫被删/改名仍会拒绝报绿）。
6. 文档口径同步：AGENTS.md、STATUS.md（4 处当前口径 + 新增 rc.17 版本行）；
   ci.yml ui-contracts job 注释 14 → 15。历史时点行保留原值。

负向验证（三项，全部通过）：
- 注入「多余闭合 / 未闭合」→ 退出 1，且只报坏文件、合法的 `>` 属性文件未被误报；
- UI_GUARDS_MIN=99 → 拒绝报绿（数量下限分支可自检）；
- CLI 直扫坏目录 → 退出 1。

验证：node scripts/run-ui-contracts.mjs → PASS 15 / 15，0 失败，退出码 0。
未跑：微信开发者工具真实编译（本机无该环境），结论仅由结构判据支撑。
 2026-09-19 11:25:05 +08:00
WorkBuddy ae2405f645 docs: 状态文件同步到 2026-09-18 实况（方案任务三） 
- STATUS.md：顶部权威行由 "PHASE 20 COMPLETE"（09-17）更新为 09-18 口径（Phase 01~22 关闭 /
  Phase 23 部分关闭 / 三轮横向加固 / 669 tests / 停在 Phase 24 门前）；版本演进表补 rc.11~rc.16；
  **合并三处重复的「V1.1 本地部署完成 (2026-09-09)」区块为一处**（996 行 → 946 行）并加
  「历史记录边界」声明；清「Phase 04~05 ⏳ 待开发」等与实测矛盾项。契约锚点全部保住
  （UI REDESIGN ACCEPTED BY USER / Phase 07 已通过用户验收 / 管理后台: http://localhost:13520/）。
- AGENTS.md + STATUS.md：UI 契约门禁口径 13/13 → **14/14**（历史时点行保留原值并注明，
  不篡改史实）。
- JIRA_BACKLOG.md：Epic 总览表补 P14/P15/P19~P23 的 ✅（P23 标「部分关闭」）。
- 客户需求基线计划：Phase 07 标题去 "UI REOPENED"；Phase 10~15/19 补 ✅；Phase 20/21 勾选
  checkbox 并注日期；**Phase 22 如实标「未复验」**（口径澄清：计划的 Deployment/Ops 与 STATUS 的
  「部署运维配置扩展（Feature Flag）」是两份不同工作，后者复验结论不构成本节证据）；
  Phase 23 标「部分关闭」，第 3/5 项（E2E 场景实现、CI 串联）**不虚勾**。
- PENDING_DECISIONS.md：历史部署声明 10 项按各 Phase Recovery 报告证据回写处置结果
  （9 项已关闭 / 1 项部分）；补登 HTTP 与幂等检修遗留的第三方开放待决策 7 项。
- REMAINING_WORK.md：整体重写 —— 原文称 CHANGELOG 3.3MB（实为 4234 字节）、P1-3 指向从未存在的
  Phase-23-Completion-Report.md；改为「已关闭 / 仍未完成 / 原编号索引 / 验收标准」四段，保留原编号
  以便对照历史引用。
- database 两份：TABLE_INVENTORY 40 表 → **59 表**（带「来源迁移」列）；MIGRATION_GUIDE
  V001~V011 → **V001~V046（46 个）**；两份均标注「以 backend/src/main/resources/db/migration/ 为准」。
 2026-09-18 21:15:29 +08:00
Codex 60eeb8aef5 docs(brand): 全仓库 Codex 署名统一为 WorkBuddy + 5 个文件重命名 
## 背景
用户指令：「先将 codex 的任务一并改为 workbuddy 的任务」。
Codex 已不再运行，当前由 WorkBuddy 承担开发执行，文档署名需同步。

## 判定规则（用大小写精确区分）
| 类别 | 写法 | 处置 |
|---|---|---|
| 工具署名 | 大写 Codex | → WorkBuddy |
| 分支名 | codex/ui-v11-fidelity | → workbuddy-ui-v11-fidelity（去斜杠，规避本仓库 ref 清理） |
| 已删除文件的历史路径 | 小写 2026-09-11-codex-baseline-cleanup* | 保持原样（记录真实曾存在的文件名，改了即失真） |

结果：26 个文件、126 处署名替换。残留小写 codex 仅 8 处，全部是历史路径。

## 文件重命名（git mv，保留历史）
- Codex开发执行总指令、项目规则与任务拆解.md → WorkBuddy 同名
- Codex首轮启动提示词 + Phase 01～Phase 26 Jira级任务清单 + 每阶段验收条件.md → WorkBuddy 同名
- docs/善缘丹阳 V1.1 Codex 开发执行计划修订版.md → docs/善缘丹阳 V1.1 WorkBuddy 开发执行计划修订版.md
- docs/善缘丹阳 V1.1 Codex-Jira 最终开发任务增量清单.md → docs/善缘丹阳 V1.1 WorkBuddy-Jira 最终开发任务增量清单.md
- docs/善缘丹阳 V1.1 Codex最终主启动提示词（整合版）.md → docs/善缘丹阳 V1.1 WorkBuddy最终主启动提示词（整合版）.md

引用已同步：AGENTS.md 6 处、AGENTS_SUMMARY.md、以及 4 份计划/规格文档。

## AGENTS.md 两处特别处理
- 「git config user.name = Codex」一句改为不点名工具的表述
- 「feature/ fix/ codex/ ui/ 前缀」示例去掉 codex/

## 有意未改动
- ui-tests/ui-document-baseline-contracts.mjs 的废弃清单仍列 codex-baseline-cleanup*
  那是「必须不存在」的断言目标，改了会让哨兵失去意义
- 仓库 git config user.name 仍是 Codex —— 未擅自改动环境身份。
  如需彻底交接：git config user.name WorkBuddy && git config user.email workbuddy@local

验证：UI 契约门禁 13/13；AGENTS.md 零 Codex 残留；5 个新文件名与全部引用一致
 2026-09-16 14:37:44 +08:00
Codex 6ae08b89fb docs(agents): 新增「版本控制约定」强制节 + 修正 UI 验收口径 
## 背景：refs/heads 嵌套分支名被实时清理，导致 HEAD 悬空

提交 bc4531a 后，refs/heads/codex/ui-v11-fidelity 被某个常驻监听进程删除（连 codex/ 目录一起），
HEAD 悬空 → `git log` 报 does not have any commits yet，`git status` 把全仓库文件标成新增。
`git update-ref` 重建返回退出码 0，但 0.2 秒内文件又消失（假成功）。

定向实验（14:06~14:10）定位的真实规则，与最初判断完全不同：

| ref 位置                        | 结果                     |
|---------------------------------|--------------------------|
| refs/heads/<单段名>             | 存活（连续观测 30s 稳定）|
| refs/heads/<任意>/<子名>        | 0.2s 内删除（连父目录）  |
| refs/tags/<任意深度>            | 存活                     |
| .git 下非 refs 的普通子目录     | 存活                     |

→ 删除器只针对 refs/heads 的子目录，且是事件驱动（0.2s），不是定时轮询（schtasks 无匹配项）。
→ 推论：标准 Git Flow 的 feature/ fix/ codex/ ui/ 前缀在本仓库全部不可用。

## 更正一处此前的错误结论

refs/codex/turn-diffs/checkpoints/... 是 09-11 / 09-14 的存量 ref，不代表有活跃 Codex 进程；
且仓库 git config user.name 本来就是 Codex，故 reflog 中所有条目都署名 Codex
（包括非 Codex 工具产生的提交）→ **reflog 署名不能用来判断是否存在并发进程**。

## 仓库处置

- HEAD 由悬空的 refs/heads/codex/ui-v11-fidelity 改为有效的 refs/heads/main
  （symbolic-ref + reset -q，仅同步索引，未触碰任何工作区文件）
- main 由 b8c33b9（09-11）快进至 bc4531a —— 纯快进：main 是 bc4531a 的严格祖先，
  `git rev-list --left-right --count main...bc4531a` = 0 58，无分叉、零冲突、零文件变化
- 保留顶层分支 feat-ui-v11 与 tag ui-v11-accepted-and-me-routes 作为冗余锚点

## AGENTS.md 变更

- 新增「版本控制约定（本机环境强制，务必先读）」一节：
  分支命名约束（禁用斜杠）、提交后自保清单（tag + bundle + 回读验证）、悬空 HEAD 的恢复方式
- 修正 UI 口径：首批范围（小程序 11 页 + 管理端框架/工作台）已于 2026-09-16 通过用户验收
  （基本达标），关闭「视觉否决 / REOPENED」判定；管理端桌面端目视复验仍待用户执行
- 头部日期更新为 2026-09-16

## STATUS.md

- 分支引用由已不存在的 codex/ui-v11-fidelity 改为 main

验证：UI 契约门禁 13/13；工作区 vs bc4531a 差异 0 行
 2026-09-16 14:31:26 +08:00
Codex c66e42dd8a docs: retire conflicting UI baselines 2026-09-13 21:12:50 +08:00
admin b46b48eb33 chore: establish V1.1 recovery baseline 2026-09-09 22:05:00 +08:00