lovife/xiaotutongxue
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
64 Commits 1 Branch 0 Tags
4a5790d900318c98ffe5a0936dff56a91d1f6037
Commit Graph

4 Commits

Author SHA1 Message Date
lovife 4a5790d900 chore(clean): 测试数据三本账清完（库 / 磁盘 / 七牛桶）+ 100 条问题全部核销 
一、dev-clean-e2e.py：加「在用组织保护」后执行
  · 先算「仍被存活任务引用的组织」并保留 —— 当前演示态就挂在其中一个
    「E2E 24数控1班」上，删了它演示态就坏（保留 3 个，演示态完好：
    任务 1449 / 名册 3 人 / 组织 43 都在）
  · 已执行 --apply --demo-tasks --orphan-files：
    49 个 e2e 租户 + 147 个测试组织 + 84 个【演示·旧】任务，
    共 3714 行 / 27 个文件（业务表按 information_schema 动态枚举，不写死清单）

二、dev-clean-qiniu.py（新增）：清真实桶里本项目前缀的测试对象
  · 只动 xiaotutongxue/ 前缀；默认 dry-run；删前核实库中零引用、
    数量异常（>5000）直接停
  · 已执行：2036 个对象 / 116 MB 全部删除，删后复验 0 个（F-93「删库不删桶」）
  · 签名按官方文档逐字核对 —— 踩了两个 401 才对：旧 QBox 格式（一个换行 +
    "QBox " 前缀）不对，是「两个换行 + Qiniu 前缀」；batch 的 Body 必须进
    签名串（列举无 Body 能过、批删全 401 —— 同一签名函数一好一坏，线索在 Body）
  · 列举在 rsf.qiniuapi.com，不在 rs（打错 host 报「Bad method: list」）

三、xt-minio 容器已删（F-2）—— 代码早已不用 S3，deploy 里也没有它

四、文档核销与记录
  · docs/08：F-3/4/7/10（小节）与 F-14/26/29/30/31/38/51/57/64/65/71/72/93
    （表格行）全部标「已闭环」；F-5 补执行记录；F-28 备案维持两级（→D-11）；
    变更记录补两行 —— **F-1~F-100 至此无未决项**，剩余全部等外部输入
  · docs/01：新增 E4「国标职业库数据来源待客户确认」（F-34，字典页如实显示 0 项）
  · 交接摘要：新增 §一·三十一（17 项决策执行记录）
  · AGENTS.md：清理一节写清三个工具与「在用组织保护」

验证：python scripts/verify-all.py --with-e2e →
      通过 8 / 失败 0 / 跳过 0（37 个 E2E 脚本 / 1577 条断言 / 0 失败，291s；
      prodguard 9/9；test profile 能起）
 2026-09-30 12:38:55 +08:00
lovife 28dedb4c16 docs: 补测结论回填与限流口径同步（docs/01 E2 / docs/08 F-99·F-100 / docs/09 §9 / 交接摘要 §一·三十） 
- docs/09 §9 重排为 9.1 结果 / 9.2 结论 / 9.3 门禁两次修正 / 9.4 怎么跑 /
  9.5 补测记录（上传并发、5000 行导入、导出大包、长跑）/ 9.6 仍然没测的；
  补记机器规格（12 物理核 / 59.6GB，全在同一台机器上）。
- docs/01 E2 二次修正备案：成功侧 200→600，附实测证据。
- docs/08：F-99（压测工具自己撒的 8 次谎）、F-100（门禁成功上限卡年级量级）、
  F-5/F-6 核销与更新，变更记录补 3 行；问题清单到 F-1~F-100。
- 交接摘要：§一·二十九（提交入库+文档小账）之后补 §一·三十（四项补测+门禁二次修正+磁盘清理）。
- AGENTS.md：清理残留一节写清 dry-run 默认与「演示态挂在 E2E 班下面」的风险。

验证：python scripts/verify-all.py --quick → 通过 5 / 失败 0
 2026-09-30 11:10:06 +08:00
lovife db6a51d617 docs: 清掉三处"会静默过期"的小账 + check-test-profile 加固（F-98） 
一、附录 A 从"手抄表"改成"可再生成的命令"
   check-api-parity.py 加 --extra，现算"代码有、契约 §4 没有"的接口 = 41 个
   （旧手抄表写 83/62/21，已差近一倍，而且没人会记得回来改它）。
   并按"谁去改什么"分六类 —— 只有 E 类（8 个）要客户定口径，其余是文档侧补记。

二、F-6 已修：frontend-pc 的 Mock 说明
   AGENTS.md 那句改正之外，连带修了 .agents/skills/project-api/SKILL.md ——
   它整篇仍以 vite-plugin-mock / mock/** 为主线，而该项目里 mock/ 目录与插件都已删除。
   只改指路牌、不改路的尽头，等于没改。

三、docs/03 两处文档内部口径冲突加 ⚠️ 注（不改口径，只把冲突摆明）
   §2 notifyBizType 的 5/6 与 §13.5、落库值不一致 → 实现以 §13.5 为准（催报去重按 5）；
   §3.6/§9.5 的 collect_file.source 字段表（入口来源）与建表注释（谁传的）冲突 →
   实现以建表口径为准。两处都写明"待客户确认"，见 F-30 / F-38 / F-39。

四、check-test-profile.py 加固（新增 F-98）
   · 子进程输出落盘（不再用没人读的 PIPE）：失败时能看见"停在哪一行"，
     成功时打出启动用时（基线 ~10 秒 / 72 行 / 9.5KB）；
   · 开跑前按 jar + profile 清残留 JVM，且保留 dev 后端（E2E 正打着它）；
   · 等待期间每 15 秒报一次进度，卡住时不留沉默。
   教训：随机端口这个防撞设计把残留 JVM 藏起来了 —— 撞不到端口就永远发现不了，
   于是表现成"时好时坏"，而失败时连日志都读不到。

验证：python scripts/verify-all.py --with-e2e → 通过 8 / 失败 0 / 跳过 0
      （E2E 36 脚本 / 1548 断言 / 278s；prodguard 9/9；test profile 能起）
      python scripts/verify-docs.py → 22 项全部通过
 2026-09-30 09:10:34 +08:00
lovife 8debf371bf docs: 完成度盘点（F-1~F-97）、确认函 E 组、交接摘要 §一·二十八与 AGENTS 更新 
docs/08 是计划与现实的对账：完成度表、未完成按「能不能上线」排序（P0/P1/P2 + 卡点→找谁→编号）、
97 条编号问题、施工记录 6.1~6.4（每条都带验证方式，不写没有证据的「已完成」）。

docs/01 新增 E 组第二轮待确认：E1 union_id（H5 与小程序不能同时上线的阻断项）、
E2 D3 限流口径更新、E3 二期时点；D3 那行划掉。

交接摘要 §一·二十八 把坐标从「M5 后端」刷新到「一期功能收口」：120/121、V17、
27 实体/33 表、36 脚本/1548 断言，以及这 20 多轮最该记住的 7 条（含 F-96：
三处「没断言就往下走」把排查引向了完全错误的方向）。

AGENTS.md：H5 那条「没有可直接联调的独立 dev server」已过时，改为三端行为的说明。
 2026-09-30 09:02:58 +08:00