wandering1/STM32F4-Base
1
0
Fork 0
Code Issues 30 Pull Requests Actions Packages Projects 2 Releases Wiki Activity
679 Commits 3 Branches 0 Tags
95beaab31310f85a3f8c37e9bc171a8cf35886d6
Commit Graph

12 Commits

Author SHA1 Message Date
wandering1 0f7b5a87fb chore(编号): 存量编号全量转语义短语，门禁识别面与语料同批重打 
登记簿、文档与代码注释里的存量字母加数字编号（N-x / S-x / T-x / E-x / A-x / 卡号）
一律改写为语义短语，净删 2,028 处引用；删除基线与待确认、并行分道方案、排期详述、
采集保护收尾 4 篇（内容已并入 docs/任务规划/README 与登记簿）。

门禁机器与三张账同批重打：check_ids.py 新增变更记录行豁免与第二根护栏
undecidable_total_ceiling；check_test_traceability.py 只加 stdout/stderr UTF-8
reconfigure（TC_RE 未动）；check_cubemx_survival.py 的 --write 固定 newline=LF；
id_registry / id_aliases（+19 条 retired-to-phrase）/ id_known_backlog 重打。

test/ 56 个文件同步 TC 标签语义化，其中 18 个 TU 改了 CHECK / printf 里的标签文字，
是本批唯一改变构建产物的文件集合。

为什么合成一笔、不拆四笔（实测撞闸，非偏好）：pre-commit 跑钩子前会 stash 未 staged
部分，拆开后中间提交必然是「新规则 + 旧语料」——实跑可判定 85.15% < 基线 86.00%、
不可判定 1,453 > 上限 1,166，编号门禁直接拦下。编号识别面与它描述的语料只能同码移动。

实跑基线（工作区全量）：754 文件 / 8,230 处编号字面量 / 可判定 7,079 = 86.01%
（基线 86.0%，容差 0.1pp）/ 不可判定绝对数 1,151（上限 1,166）/ 校验 1-6 错误级 0 /
告警 = 悬空 2（App/algo/freq.c 的 S2，属 §4.4 同号不同义）+ 孤儿 50。

基线从 84.0 抬到 86.0 的理由见 docs/门禁说明/id-check.md §7.6：本批真删了 2,028 处
引用，可判定面随真实内容上升，不是把分母做小。同批新增排除 docs/硬件平台/ 语料，使
识别面少 264 处——芯片手册位号与网表料号不属编号空间（registry 有 excluded_paths_note）。

⚠ 余量只剩 0.11pp（约 10 处）与绝对数 15 处：把「可判定的引用」改成散文会立刻撞第二
根护栏。另遗留一项：id_aliases 里 retired 的 N / S / T / A 别名没有 scope（U1~U5 有），
今后有人新写一个 A-4，校验 3 不会响，只能靠人，建议下批补 scope。

固件不变证据：115 个 .c/.h 剥注释并归一字符串后与 HEAD 逐字节全等，残留代码差异 0；
App / Src / Drivers 的字符串字面量零改动。@build 0 错误 0 警告；40/40 主机套件、2,889
断言全通过；覆盖率 line 89.2% / func 92.6%；pre-commit 48 钩子 --all-files 全绿；
check_doc_links --all 通过（176 文档，章节引用无法判定 0）；逐字节卫生核过：14 个带
BOM 文件与 HEAD 一致、0 个 CR、0 个 U+FFFD，字符串字面量纯 ASCII。

.cubemx_survival_baseline.json 的 watchdog-module 哈希 56bf27 变 2bb051 属合法：
Src/freertos.c 的 USER CODE 区内只有注释文字随编号改写，代码未变。

同批带上体积同码凭证与 RAM 台账行（@build 之后盖戳）：RW_IRAM1 79,008 B / 60.3%，
RW_CCM 57,376 B / 87.9%，阈值 92%。
 2026-10-26 12:28:14 +08:00
wandering1 db9f256fd0 docs(收口): 批 1 台架记录与门禁/产物分家口径落档（道C 文案兑现） 
- test/board/ch395f_test.h：f3 轮台架记录追加——VERDICT PASS，
  task stall 468→14（net 类 431→0，掩码复活实锤），余 13 条为
  netTask 自挂起前喂一次 vs 精确匹配判据的语义打架 + 1 条 uiTask
  瞬态 + 1 条设计内 P2 留痕；lead 裁决不放宽超集判定
- 主机单测覆盖率口径.md：中间产物路径 L80 与坑 12 重写为
  %TEMP%/dtu_host/<工作树哈希>/ 分家 + runs 独占（adabb6a 落地，
  旧固定共享名作废；判据正文指向 harness 顶部）
- 并行任务工作树方案.md §5 表：单测产物一行——不需要锁但必须
  按树分家（对照 build/bench 真独占）
- 门禁说明/cubemx-survival.md §6：新增第 7 条「基线漏项=静默不检」
  （net-msgq-adopt 实证，--write 后抽查新增条目）
- 门禁说明/id-check.md §5：拦下过真事追加——P1-10 注释裸编号被
  校验 6 拦（紧邻写法在 C 注释同样生效）
 2026-10-25 06:12:02 +08:00
wandering1 d07a9a4d67 docs(P1-10): sync 追平后补记四档复测数字（产品基线已前进，旧注保留） 
sync 到 59da40b / 891ca81 之后重测四档 CH395F 配置（全部 0 错误 0 警告、链接通过）：
  默认 11/14   Code=219,112  RW_IRAM1 78,072 B 59.6%   距 92% 线 42,514 B
  NET 全开     Code=220,636  RW_IRAM1 85,688 B 65.4%   距线 34,898 B
  HW 全开      Code=230,900  RW_IRAM1 91,088 B 69.5%   距线 29,498 B（最坏态）
  HW 无 PC     Code=216,888  RW_IRAM1 78,808 B 60.1%   距线 41,778 B
产品基线同期前进到 Code=215,744 / RO=21,396 / RW=1,224 / ZI=131,984，RW_IRAM1
75,784 B / 57.82%（与 lead 信号里给的主干数字逐项相同）。04 点那组旧记录按"历史
不追改"原则留着，只标注基线已前进；两组差值都在 +136~+152 B，来自新增 adc_cal 的
数据段，所以**结论不变**：最坏态仍余约 29 KB，不需要把 scatter 扩到 192 KB。
PHASE5 三块静态缓冲依旧在链上（hw_full 的 ch395f_test_task.o 数据段仍 12,285 B）。

四档复测都走**朴素行注释切换**（改宏 = 行首加/去 //），顺带二次确认 16917bf 修
的开关行注释陷阱没有复发。跑完 test_config.h 与 ch395f_test.h 均按字节还原，
产品固件重建后回到基线数字。

RAM 增量：0 B（纯注释）。gate：test-cppcheck / id-check / no-mojibake /
trailing-whitespace / end-of-file-fixer / doc-links / mem-budget 全 0；
未用 --no-verify。
 2026-10-25 05:50:45 +08:00
wandering1 5f1057ac74 test(P1-10): 套件回归 forbidden 换成显式四 Fault 标签 + 台架记录 21/21 
台架第一轮（boot log 20261025_050539）判 VERDICT FAIL，命中 469 条 [ERR]，两类：
  1) [ERR][CH395] ch395f P2 boundary fault @get_state sn —— **设计内**：Phase 15 的
     sn 越界负向用例故意命中驱动守卫（Drivers/BSP/CH395F/ch395f.c 的
     ch395f_p2_fault_note()：首次 DBG_ERROR、之后只计数），用例本身 PASS；
  2) [ERR][WD] task stall ×468 —— **设计外**，已在 a9ba8ec 单独修（掩码死分支），
     不用豁免去掩盖它。
本笔只管判据：套件回归这条路要豁免的是"设计内守卫 [ERR]"，不是崩溃。

为什么不能只是把 [ERR] 从 forbidden 里删掉（核过 verify_log 源码与固件崩溃行）：
四种 Fault 的崩溃行是 [ERR] HARDFAULT / MEMFAULT / BUSFAULT / USAGEFAULT
（Src/stm32f4xx_it.c 的 hard_fault_report 先打 "[ERR] " 再打标签），而 verify_log 的
forbidden 是**大小写不敏感的子串匹配**（fl in ln.lower()）→ 默认集合
HardFault;assert;[ERR] 里的 HardFault 只兜得住硬Fault，**MEM/BUS/USAGE 三种平时
完全靠 [ERR] 兜**。据此：
- 新增 FORBIDDEN_SUITE =
  HardFault;MEMFAULT;BUSFAULT;USAGEFAULT;assert;bring-up FAIL
- CH395F 用它（原来吃默认值，含 [ERR]）；
- GD5F 也用它——旧值 "HardFault;assert" 正是上面那个漏法（当初只为豁免
  TC-GD5F-704 的设计内 [ERR] 就把整条 [ERR] 摘了，等于顺手放走了三种 Fault），
  现在既保留豁免意图，又把崩溃判定补齐；
- STORAGE / RTC 不动（它们没有设计内 [ERR]，继续吃含 [ERR] 的默认判据）。
边界写死在注释里：产品 @test 的判据（.serialtest/config.json 的 forbidden 含 [ERR]）
**一个字节没动**，豁免只活在"套件回归"这条路上，渗不回产品路径。

test/board/ch395f_test.h：
- Phase 15 汇总实测 21/21（旧注释写"台架 20/20 PASS"是历史记录，已按本轮改正）；
- 记一条台架档案：镜像 ch395f_hw_nopc_v2.hex 单次开机跑完 1/12/15，汇总行
  9/9、1/1、21/21，failed=0，全程无 Fault；并记下同轮暴露的掩码死分支结论与它的
  证据位置，后来人切阶段时不必再踩一遍。

验证：
- py_compile 通过；test/run_all_suites.py --check-build --suites CH395F 走**官方编排**
  实跑 PASS（BUILD_OK 0 错 0 警，Code=217468 RO=21452 RW=1268 ZI=134076），脚本自己
  还原 test_config.h 并重建产品固件；这个 Code 与上一笔实测表里"默认阶段 11/14"一行
  逐项相同 → 两个独立工具互证同一组数字。
- gate：id-check / no-mojibake / trailing-whitespace / end-of-file-fixer /
  doc-links / cppcheck(test/) / test-suite-switch（产品态 Skipped）全 0；
  未用 --no-verify。
- RAM/Flash 增量：0 B（Python 与注释，不进固件；test/board/*.h 的注释不改代码）。

下一轮台架等 lead：f2 镜像我会在 sync 到 A-3/B-3 之后重编（现在这份
ci-artifacts/p110_fw/ch395f_hw_nopc_f2.hex 戳 05:23:03，若中途主干动过固件就要重编），
判据用上面的 FORBIDDEN_SUITE；请顺手带回两个数：[ERR][WD] 总条数、mask 含 bit4(ui)
缺位的条数。
 2026-10-25 05:36:25 +08:00
wandering1 16917bf165 test(P1-10): CH395F 套件三档构建实测 + 修阶段开关行尾跨行注释的切换陷阱 
P1-10 剩余①「CH395F 套件实际构建确认链接通过」今天才真正有数：产品基线 + 三档
测试配置（ARMCC，全部 0 错误 0 警告；.sct 保持 128 KB 未动，符合 P1-10 写的
"不建议扩到 192KB"）：

  配置（TEST_SUITE_CH395F + 阶段）    Code      ZI      RW_IRAM1      距 92% 余量
  产品基线（阶段全关）                214,104   131,852   75,632 57.7%   44,954 B
  默认阶段 11/14（只切套件宏）        217,468   134,076   77,920 59.5%   42,666 B
  NET 层全开 6~11/13/14              218,992   141,688   85,552 65.3%   35,034 B
  HW  层全开 1~5/12/15（最坏态）      229,256   147,176   90,952 69.4%   29,634 B
  HW  层无需 PC 1/12/15（冒烟用）     215,244   134,896   78,672 60.0%   41,914 B

P1-10  specifically 关心的 PHASE5 三块静态缓冲（3 x PHASE5_CHUNK_SIZE = 3 x 4093）
确实进了链接，不是"理论上会在"：hw_full 的 ch395f_test_task.o 数据段 = 12,285 B
（12,279 + 该 TU 其余 6 B）。于是"理论余量足够但未实测"改成了实测：最坏态仍余
29,634 B（RW_IRAM1 上限 131,072 B，92% 线 120,586 B）。RW_CCM 四档恒为 57,376 B /
87.9%——测试代码不进 CCM，但该区已经贴着红线，将来往 CCM 加东西要单独核算。

顺手修掉一个把实测挡了三年的坑（就是它让第一轮 hw 配置炸掉的）：
ENABLE_PHASE11/14 两行的说明是**挂在行尾的跨行块注释**。而"关掉一个阶段"的标准动
作是在行首加 //，// 只注释到行尾 → 块注释从第二行起变成裸代码，实测 188 条
error #7: unrecognized token，报点落在注释续行上，看着像头文件坏了、其实只是注释
被腰斩。run_all_suites.py 的 _rewrite_config 只改 TEST_SUITE_* 行（那些行没有行尾
跨行注释）所以一直没暴露；ch395f_test.h 恰是"人手工切阶段"的入口，必须自身安全。
修法：把两段说明挪到 #define 行的上一段，行尾只留同行闭合的短注释；并在开关区后面
写清"开关行注释规范"+ 上面这张实测表（同一事实只在这一处，销项时文档引它）。

验证（_wt/P1-10-test-fw，每步都实跑 @build）：
- V1 产品态（改注释后）：0/0，Code/RO/RW/ZI = 214104/20388/1204/131852，与主干
  2026-10-25 台账行逐项相同 → 本改动零体积增量。
- V2 只切套件宏（默认阶段 11/14）：0/0，RW_IRAM1 77,920 B / 59.5%。
- V3 **朴素行注释切换**（正是炸掉第一轮的那个动作）改到 HW 1/12/15：0/0，且尺寸与
  用 #undef/#define 覆盖法得到的 hw_nopc 逐字节相同（215244/23656/1200/134896）
  → 陷阱确认已消除，两条改法等价。
- V4 还原后产品重建：0/0，数字回到基线；test_config.h 与 ch395f_test.h 均按字节还原
  （git status 只剩本文件这一处改动，测试宏没有留在树里，test-suite-switch 无需放行）。
- 产物身份戳实测：hw_nopc = "Oct 25 2026 04:32:16 suite=CH395F dstr=off"、产品态 =
  "Oct 25 2026 04:32:25 suite=NONE dstr=off" → dstr=off 三档一致，破坏性开关全程关。

RAM 增量：0 B。gate：改动只命中 no-mojibake / trailing-whitespace / end-of-file-fixer /
check-added-large-files / id-check / mem-budget，全部 0；未用 --no-verify。

P1-10 剩余②（@test 烧录抓日志）需要 bench 锁，已把镜像与锚点清单交给 lead 执行；
真机跑 Phase 2~5 / 8 / 11 / 13 / 14 需 PC 端 tcp_server / peer 配合（Phase 11 还要
制造死对端，E11），属"实际测量采样"类，按用户指示本轮跳过，不在本提交声称做过。
 2026-10-25 04:49:19 +08:00
wandering1 d770e36c7c refactor(NET): 源码注释去阶段化 + 网络两份文档重构 + 不稳根因图更新 
- 源码注释：删去自愈收敛阶段
1/1.5/3等 scaffolding 称谓，改为语义引用
  （E-02 收口 / F-NET-2/3/4 / docs/网络/网络自愈架构设计.md §5.2 E13）；
  涉及 net_socket/.h、net_events、net_listener、net_pending、net_types、
  net_config、ch395f、time_sync、iec104_serv、ui_net_sink、lftpd、
  simulator/sim/net_socket_sim、board/host 测试与探针
- 文档重构：网络自愈架构设计.md 与 Net层阻塞模型架构设计.md 改为现状口径
  （删历史节与阶段叙事），NET/README.md、docs/README.md 同步
- 工具与配图：gen_net_instability_svg.py 与
  docs/images/网络不稳根因总览.svg 随源码口径一并更新
- 门禁：@build 0 错误 0 警告
 2026-10-14 22:05:53 +08:00
wandering1 a12367981d fix(N34): E14 丢中断复核——芯片不丢事件；listen 排事件挪至 LISTEN 前+全局读收口+全库归因更正 
48 轮直读 SINT 矩阵（8 周期×6 变体）复核历史"丢中断"说法：芯片侧事件
丢失 = 0。归类：drain 读清消费 3/48（drain-int 探针现场抓获）、门控
竞态 2/48、主机同步 1/48、幽灵态 0/48 未复现。

根除性修复：net_listen_locked / net_listener_try 的排事件读清从
listen 后挪至 LISTEN 命令之前——新连接 CONNECT 落进该窗即被本方读清
吞掉，即"数据被吞"的生产侧自伤机制（台架 3/48 为同形态放大版）。

全局读收口：全局中断寄存器唯一读者 = net_poll（I7）；生产/测试/台架
游离全局读全部删除，ch395f.h 声明处加护栏注释。

归因更正：17 文件约 40 处"丢中断"措辞改为"事件未收到/读清消费竞态"
（机制全部保留，仅归因更正）；设计文档 §5.2 新增 E14 锚点；Trap
Records TRAP-NET-17/-20/B3 归因更正段；配图生成器与 SVG 重生成。

台架：事件未收到复核探针保留（drain-int / SINT 补读×3 / 超时归类），
下次跑矩阵自动归类；实验注册（main.c/uvprojx）已完全还原。

验证：@build 0 错误 0 警告；ci_local L0 32/0 + gitlint + L0.5
953/953；doc-links --all --sections-strict 通过；@test PASS（无
[ERR]，net init 619ms）；回归 :7003 300ms×10 = 10/10、:21 n30×50 =
0/50 失败。
 2026-10-14 02:48:50 +08:00
wandering1 f7f17931c9 feat(N34 阶段2): ch395f 五原语只加不接线 + Phase 15 套件 20/20 
实施方案 docs/网络/N34-自愈审计/实施方案.md §4 五原语，形态按
E2/E3/E4 定案（实验方案.md）：
1. 类型化状态回读 + 每 Socket 缓存（open=0 时 tcp_state 哨兵
   0xFF；sn>7 边界返 {00,FF} 计 fault）；
2. 事件护栏 ch395f_sock_events：只读本 Socket SINT，全局寄存器
   唯一读者=net_poll（F-NET-7 契约）；
3. ch395f_sock_reset_begin/poll 非阻塞状态机：读空 RX -> CLOSE
   -> 排空事件(quiescent 2 轮) -> 轮询 byte0=00H；GRACEFUL/
   QUARANTINE 最短等待 100/400ms（Trap 23）；WAIT_CLOSE 内置
   LISTEN 态二段 CLOSE 补发（TC1502b 实证 ~180ms 落定）；
4. ch395f_cmd_done 状态回读判据（E3：GET_CMD_STATUS 对
   OPEN/LISTEN/CLOSE 无判别力）；
5. 链路态缓存 ch395f_glob_event_feed + link_up/变化计数
   （B9 判据 PHY!=DISCONN）。

Phase 15 板测（硬件层模式，Socket 7，无需 PC）：20/20 PASS，
含二段关闭语义断言（一段 05/00、二段 byte0=00）。

RAM +56B < 64B（g_sock_state 16B + g_rst 32B + 链路/fault 8B）；
产品 Code 与阶段 2 前逐字节同 209780（无调用者被链接器裁剪）。
@test PASS；relisten_stress 20/20、n30 3/3 零回归。
RAM 台账同步：RW_IRAM1 97952B 74.7% / RW_CCM 57376B 87.9%。
 2026-10-13 12:43:17 +08:00
wandering1 33405a57b5 docs(N34)+test: E13 僵尸会话根因坐实；Phase 11 判据修正+一次性报告 
E13（实验方案.md 新增 + E8/E11/E12 口径修正）：
- 风暴态根因=僵尸会话，非芯片残渣：PC 网卡禁用/链路断开时
  Windows 直接丢弃 socket 不发 FIN/RST → 芯片侧 ESTABLISHED 僵尸
  → 单连接监听被占（:21 拒连）→ 下一 PASV 重监听与僵尸竞态
  （accept 为垂死僵尸开枪 20ms 后 DISCONNECT）→ lftpd 5s 窗空转
  → 425；每失败轮再生僵尸 → 自续数分钟
- "残渣跨烧录存活/需断电冷启动"口径作废：板上 CH395F RSTI 接
  MCU NRST（V0.0 网表 :174），每次烧录即芯片硬件复位；"存活"是
  锤击再生错觉。正确控制=下一臂前静置 ≥90s 清僵尸窗
- 自愈链端到端验证：TIMEOUT(在途 TX ≈30s)/keepalive(空闲 60/5/3)
  → pump → relisten → 端口恢复；E11 产品路径验证 17s 判死 PASS
- 4 元组复用假设被否（pasv_probe.py：PASV 端口递增、PC 源端口随机）
- e02_probe listener=FAIL 重解读：探针挂起 socket 未关（PC 内核
  代 ACK keepalive）→ 拒连是单连接正确行为；真缺口=应用无法主动
  拆会话 → 阶段 2 sock_reset 职责

Phase 11 测试修复（net_test_task.c，实跑暴露）：
- 判据 >=60000ms 是按手册公式写的，实测判死 18~31s 会在正确固件
  上假 FAIL → 改有界窗 10s~120s（下限防误杀存活空闲会话，上限
  防判死缺位）
- 报告后不释放 phase_active → 对已死连接 10ms 节奏刷 594 条假
  FAIL → phase11_run 返回完成态，主循环释放等新连接再测
- 复跑两轮验证：30137ms 单次 PASS → 自动等新连接 → 二轮 accept 正常
- Test_Guide TC-NET-1101 判据/耗时同步；ch395f_test.h Phase 14
  共存安全性注释（有整体超时不永久挡 accept）

工具：test/host/pasv_probe.py（每轮打印 PASV 端口+PC 源端口+结果）
 2026-10-13 11:23:40 +08:00
wandering1 13a4a40a14 feat(net): 服务器侧 KeepAlive 转正（§5.56，E11）+ Phase 11 重开回归 
E11（d96113b）证据链："链路在、对端静默"注入下生产参数 60/5/3 实测
判死 ≈30s → TIM_OUT → QUARANTINE → pump 重建；静默但存活对端不误杀。
handle_connect_event LISTENING 分支按手册规定位置开启；反汇编确认
编译器把两分支尾部合并（LISTENING 跳入含 keepalive+fire_event 的公共
尾部，hex 全片仅该分支偏移 1 行差异，Code 尺寸不变属填充巧合）。
Phase 11 重开时发现其拉入 32KB s_rx_buf 超产品 RAM 余量（L6406E 链接
失败）→ 改专用 64B 探针缓冲（本 Phase 仅 64B 探针读，门控注释已留
"勿加回"警示），套件恢复 0 错 0 警；TC-NET-1101 步骤同步死对端注入法
（禁用网卡；Windows 防火墙规则对已建立连接无效，E11 实证）。
验证：产品/套件双构建 0 错 0 警 + 反汇编确认调用落地；台架确认
（:7003 静默对端判死 + Phase 11 实跑）待设备冷启动断电重上电后补做。
 2026-10-13 09:25:06 +08:00
wandering1 2055de0303 测试：落地测试架构改进 T-1~T-5（套件开关门禁/汇总行校验/通用 harness/公共断言宏/多套件编排） 
背景：L0.5 主机侧单测落地后复审测试架构，给出 6 条改进意见（P0~P3），
登记进 docs/待处理内容.md「测试与验证基础设施」后逐条实施。

- T-1(P0) 测试套件开关门禁：新增 scripts/check_test_suite.py + pre-commit 钩子
  test-suite-switch，默认要求产品构建（全部 TEST_SUITE_* 注释），跑套件回归用
  --allow-test-build / ALLOW_TEST_BUILD=1 显式放行。顺带把 test_config.h 中长期
  开启的 TEST_SUITE_CH395F 改回注释（仓库此前躺着的是测试固件）。
- T-2(P1) verify_log.py 增加 --require-suite-summary：要求
  "=== <名称>: N/M PASSED (failed=0) ===" 且 N>0，堵住"套件没跑到汇总行/
  断言数为 0 仍判 PASS"的盲区；run_boot_test.py 同名参数透传。不传参向后兼容。
- T-3(P1) 抽取通用 harness test/host/common/unit_test_harness.py（工具链探测/
  INCLUDE-LIB 拼接/wd4819/GBK 解码/退出码契约）；watchdog 运行器 170→55 行，只声明 TestBuild。
- T-4(P2) 新增 test/board/test_common.h 集中断言内核（TEST_CHECK_IMPL/TEST_REPORT_IMPL），
  4 套件各用一行宏绑定自身统计变量（保持 g_xxx_stats 独立、防跨套件串数）。
  刻意不 include dbg_log.h——否则冻结 DBG_TAG 默认值触发 #47-D 重定义警告。
- T-5(P2) 新增 test/run_all_suites.py 多套件回归编排，try/finally 无条件还原套件开关。

验证：@build 产品构建 0 错 0 警；4 套件逐一构建均 0/0；看门狗单测 39/39 PASS；
pre-commit 14 钩子全通过；编排脚本 dry-run/开关切换/异常还原均实测通过。
 2026-10-01 07:28:57 +08:00
wandering1 22559365b9 整理 App 与 test 目录：按职责分子目录并同步全库引用 2026-09-26 12:52:39 +08:00