admin/danyang-match
1
0
Fork 0
Code Issues Pull Requests Actions 2 Packages Projects Releases Wiki Activity
137 Commits 2 Branches 8 Tags
76a152bccfbb722f06f100a369e951aa9ea0445e
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 f63e579a8d ci(e2e): 落地「活栈供给方式」决策 — Compose in CI，并修掉 6 处真实缺陷 
决策：E2E 活栈在 runner 内用 docker compose 起全栈（postgres + redis + minio + backend），
与本地验证路径完全一致；未采纳「service containers + runner 上 mvn package 后 java -jar」——
那需要为后端另写一套 host 网络配置，等于制造第二条与本地不一致的路径。

本机实测（与 CI 同一序列）：中间件三项 healthcheck 全 Healthy（pg_isready / redis-cli ping /
mc ready local）→ backend /api/v1/health/live 返回 200 → seed 幂等可执行（INSERT 0 0）
→ pytest tests/e2e → 49 passed。
（本机限制：Docker Hub 不可达且无 temurin 基础镜像，未复现 --build；改用本地既有镜像为底座、
挂载当日 16:24 构建的 jar，使被验证的代码版本与 CI 一致 —— 否则是拿 09-09 的旧代码验 09-18 的用例。）

修掉的 6 处缺陷：
1. minio/minio:latest 是滚动 tag → pin RELEASE.2025-09-07T16-13-09Z（否则 CI 拉到的镜像
   与本地验证时不同，表现为不可复现的偶发失败）
2. up 未显式列出 minio（靠 depends_on 隐式拉起），而 minio 的 healthcheck 正是 backend
   能否启动的前置条件
3. up --build 把构建与起栈耦合，失败日志混杂 → 拆为 build / up 两步
4. 就绪窗口 5min 偏紧（首次构建后仍需 Spring 启动 + Flyway 46 个迁移）→ 7.5min
5. 缺 down -v 前置清卷：seed 用 ON CONFLICT (username) DO NOTHING，残留卷会让账号口令
   停留在上一轮 → 登录 401，并伪装成业务失败
6. job 无 timeout（GH Actions 默认 360 分钟）→ timeout-minutes: 30

另：pytest -v → pytest tests/e2e -v。原以为从仓库根收集会误收 tests/*_test.py
（其在 import 期依赖 psycopg2 与 E2E_DB_PASSWORD），实测否定：pytest.ini 的
testpaths = tests/e2e 已限定范围，从根收集正是 49 个用例且无 error。显式传参作为兜底保留。

计划 Task 2.3 由「依赖基础设施决策」改为「已决策并落地」，仅余 Step 3（CI 上实测一次绿）。
 2026-09-18 21:58:56 +08:00
WorkBuddy d707fb1f60 ci(ui): 把 14 个 UI 契约门禁接入 CI，并新增统一执行器 
Phase 23 收尾计划 批 1 Task 1.1 —— 此前 ui-tests/*.mjs 只在本地手工逐个执行，没有任何 CI
把关：改动破坏了源码结构契约也不会有任何信号。

- 新增 scripts/run-ui-contracts.mjs：逐个 spawn 子进程运行守卫 → 汇总 → 任一失败即非零退出，
  并打印失败守卫的原始输出便于定位。零 npm 依赖（守卫只用 node 内建模块）。
- 两条防退化设计：
  ① 子进程 cwd 固定为仓库根 —— 守卫里 6 个用相对路径、8 个用 import.meta.dirname 自锚定，
     不固定 cwd 会在 CI 上假红；
  ② 守卫数量下限校验（MIN_GUARDS=14，可用 UI_GUARDS_MIN 覆盖）—— 防止守卫被删除或改名后
     依然报绿（Phase 19 教训：扫描清单本身会漏）。
- ci.yml 新增 ui-contracts job（checkout + setup-node + 跑执行器），与既有 test-shell-guard
  同属「守门」类 job。
- 生产 compose 缺失的既有兜底确认可复用：ui-document-baseline-contracts.mjs 对不在版本控制内的
  infrastructure/docker-compose.prod.yml 已做 existsSync 判定并显式打印跳过原因，CI 上不会假红。

验证：
- 基线 node scripts/run-ui-contracts.mjs → PASS 14/14，退出码 0；
- 负向注入（.workbuddy/tmp 下必然失败的守卫）→ FAIL、退出码 1，失败详情可见；
- 数量下限分支以 UI_GUARDS_MIN=99 自检 → 正确拒绝报绿（退出码 1）；
- .github/workflows/ci.yml 经 yaml.safe_load 解析通过，jobs 含 ui-contracts。
 2026-09-18 21:30:15 +08:00
WorkBuddy 730dddde30 test(e2e): Phase 23B — rebuild E2E infrastructure; fix 6 real prod defects it exposed 
Phase 23 closed as PARTIAL: fake coverage was gone, but the E2E layer itself
was still empty — no conftest.py anywhere, ~15 fixtures that never existed,
6 files crashing at import on os.environ["E2E_PASSWORD"], and CI never ran E2E.
STATUS's "10 E2E files / ~80+ cases ✅" described files that had never executed.

Infrastructure delivered:
- tests/e2e/conftest.py: ApiClient (trust_env=False — a host http_proxy turns
  localhost calls into 502), operator_token(username) / new_user / admin_token
  fixtures, and a session probe that calls pytest.exit(4) when the stack is
  unreachable. NOT skip: skip would launder "did not run" into "passed".
- pytest.ini, tests/e2e/requirements.txt, and tests/e2e/sql/
  seed_e2e_operators.sql — migrations contain NO operator seed at all, so a
  fresh database has zero logins; the seed creates 6 e2e accounts with role
  bindings, idempotent, password injected via `psql -v pwd`.
- CI job `e2e`: compose up -> poll /health/live (timeout = fail) -> seed ->
  pytest -> always teardown. Gate D-23-D is now closed.
- 8 E2E files migrated off import-time env reads; tautological assertions
  (`x == t or not x`), a counselor token standing in for content_editor, and a
  bare `status_code == 200` claiming to prove INV-020 were replaced with real
  permission/behavior assertions.

Six real production defects found only by running against real PostgreSQL
(H2 has zero coverage for all of them):
- D-23B-A (Critical): stale V042__add_appointment_operator_register_permission.sql
  left in target/classes; src had replaced it with V042__add_service_location_
  announcements.sql. Packing without clean put two V042 in the jar -> Flyway
  "Found more than one migration with version 042" -> app would not start.
  Guard added: testBuildOutputHasNoDuplicateMigrationVersions scans build output
  (src is clean, so only this catches it).
- D-23B-B (High): non-UUID path variable reached the DB -> 500 + leaked
  `invalid input syntax for type uuid`. Now rejected at the controller.
- D-23B-C (High): 6 E2E files raised KeyError at import -> never collected.
- D-23B-E (Critical): permissions = 48, role_permissions for super_admin = 18,
  matchmaker = 0. V015's "grant all to super_admin" was a point-in-time snapshot;
  the 30 permissions added later were never granted. On a fresh stack an admin
  cannot create a service station and matchmakers can do nothing. V044 restores
  super_admin to its documented definition (not an expansion); the matchmaker
  permission set needs a product decision and is left as a residual.
- D-23B-I (Medium): IllegalArgumentException (e.g. invalid activity type) was
  unmapped -> 500. Now BAD_REQUEST.
- D-23B-J (High): `operator does not exist: uuid = character varying` — Java
  ids are String, columns are uuid, PostgreSQL does not implicitly cast in
  comparisons. Fixed at the source with JDBC `stringtype=unspecified` (docker
  profile); production datasource comes from deploy env and needs the same.

One judgement retracted: an initial read suggested service_appointment.register
was missing. It is not — the endpoint uses service.assisted_registration, seeded
in V029, and the code deliberately avoids a duplicate permission. Nothing was
changed on that basis.

Verification: 33 E2E passed against a live stack; unreachable stack and a
missing operator password both exit 4 (never skip/pass); backend regression
656 / 0 failures / 0 errors / 3 skipped (baseline 655, +1 guard, negatively
validated by injecting a duplicate V042 -> exactly one test turned red).
 2026-09-18 13:50:19 +08:00
WorkBuddy ae1bd2b734 test(phase23): KEEP-VERIFY — remove 44 pass shells + fake INV tests, add shell guard 
Phase 23 "可信系统测试重建 (REFACTOR)" re-audit. STATUS claimed "10 E2E
files / ~80+ cases" and "INV-011~020 ✅"; measurement showed the opposite.

D-23-A (Critical): V11InvariantsTest's 14 cases asserted only Constants
strings. INV-016 "Banner target types" actually asserted ARTICLE_STATUS_*;
INV-017 "home 8 entries" declared local arrays then asserted
firstRow.length == 4 (tautology, never called the home service);
INV-018/019/020 used appointment/article/account status constants as
stand-ins for permission and data-scope checks. Rewritten to 12 cases:
4 real service-behavior guards (INV-013 via real CounselingService.getDetail
— Matchmaker sees null userRequestSummary, with an assigned-Counselor
counter-proof so global sanitization cannot fake a pass; INV-016 reads the
production ALLOWED_TARGET_TYPES whitelist and asserts no external/http/url/
web entry; INV-017 calls real getHome and pins all 8 codes + order;
INV-019 asserts content_editor reads null), plus assertBehaviorTestExists
turning "行为验证见 XxxTest" pointers into executable Class.forName contracts.

D-23-B (High): 44 `pass` shells across 6 files in tests/e2e (4 files were
100% shells). Gate forbids skip/pass shells. Rewritten in place as honest
placeholders with the full scenario lists preserved.

D-23-C (High, residual): the pytest E2E suite is not executable at all —
no conftest.py anywhere, ~15 fixtures (api_client/verified_user/
banner_factory/...) do not exist. Only run_v11_tests.py really runs
(16 cases, needs a live stack + E2E_PASSWORD).

D-23-D (High, residual, NOT fixed): CI does not chain E2E as the plan
requires. Needs an infrastructure decision on how CI provisions a live
stack; not implemented rather than written unverified.

D-23-E (Medium): the CI migration job claimed to "验证 migration SQL 语法"
but only checked file non-emptiness, while the real syntax/baseline checks
live in MigrationValidationTest (already run by the backend job). Replaced
with a real sequence check (naming / non-empty / unique versions / no
gaps); verified by extracting the exact inline script and running it.

New gate: scripts/check-no-empty-tests.py (AST scan, blocks pass-only and
unconditionally skipped tests) + a CI test-shell-guard job. Verified both
ways: 0 findings on the real tree, 2 precise findings on injected shells.

Negative validation: 3 injected production defects (external_url in the
banner whitelist, swapped home entry order, isMatchmaker returning the full
record) turned exactly inv016/inv017/inv013 red, 9 others green, zero
unrelated failures; md5sum -c confirmed byte-identical restore.

Full regression: 655 tests / 652 passed / 0 failures / 0 errors / 3 skipped
(baseline 657; -2 because 14 vacuous cases were merged into 12). The 3
skips carry explicit reasons (2x @EnabledIfEnvironmentVariable(CI=true),
1x @Disabled "需要完整数据库连接") — none is a shell.

Phase 23 is PARTIALLY closed: fake coverage is gone, but the UAT gate
requires the end-to-end chain to actually execute, so "失败为零可进入 UAT"
is NOT claimed.
 2026-09-18 11:49:18 +08:00
admin b46b48eb33 chore: establish V1.1 recovery baseline 2026-09-09 22:05:00 +08:00