v0.1.0

dsh-stm32 的首次公开发布。

亮点

• 给 DSH 补齐 STM32F103C8T6 的整条开发链：一次注册 15 个工具、5 条斜杠命令、1 个 stm32-workflow 技能，从体检 → 建工程 → 改配置 → 生成代码 → 编译 → 烧录 → 调试 → 读回寄存器，全程在对话里完成。
• .ioc 只走事务：stm32_ioc_plan 只读算出逐键 diff 与源文件 SHA-256，确认后才 stm32_ioc_apply 原子替换并备份；源文件变过就拒绝写入。手改 .ioc 文本这条路被堵死。
• 烧录与调试分离：stm32_flash 只烧不调试、烧完立刻复位并释放探针；调试会话按需开启、空闲自动关闭，不长期霸占 CMSIS-DAP，用完随时能在 VS Code 里按 F5。
• 改代码只准碰 USER CODE 块：块内替换/追加，块外字节原样保留；写前自动备份，避免被 CubeMX 重新生成时静默覆盖。
• 烧完能自证：stm32_regs_read 读物理地址寄存器、stm32_debug_eval 在已开会话里跑 gdb 命令，用观测值确认固件真的在跑，而不是只看编译日志。
• 体检给到可执行结论：stm32_env_probe 逐项报 gcc / gdb / OpenOCD / CMake / Ninja / CubeMX / 内置 JRE 的路径、版本与缺失时的修复提示，只读、可重复调用。

安装

dsh plugin --profile desktop add dsh-stm32

装完需重启 dsh 才会加载插件。开发版（跟随仓库 main 分支）：

dsh plugin --profile desktop add github:JingYu-er/dsh-stm32#main

环境要求：Node.js ≥ 20；本机需自备 arm-none-eabi-gcc、arm-none-eabi-gdb、OpenOCD、CMake、Ninja（推荐 MSYS2 UCRT64）。
STM32CubeMX 可选，仅 stm32_generate 需要。装好后先跑 stm32_env_probe 体检，或用 /stm32-doctor 一次看齐工具链、探针占用、端口与 .elf/.ioc 告警。

验证

• npm run build（tsc -p tsconfig.json）通过；lib/ 与 src/ 的一致性由 CI 强制校验，产物过期即失败。
• npm test 通过：10 个离线套件，不需要开发板、CubeMX 或工具链。
• npm publish --dry-run 核对过打包白名单：仅含 lib/、templates/、docs/、cordis.patch.yml、README.md、README_EN.md、LICENSE，不含 src/ 与 test/。
• 在干净的 DSH profile 中按上面的安装命令安装并重启，dsh plugin --profile desktop why dsh-stm32 显示 0.1.0，15 个 stm32_* 工具全部可见。
• 已在 STM32F103C8T6（蓝丸）+ CMSIS-DAP 探针上跑通：环境体检 → 编译 → 只烧录 → 调试会话 → 寄存器读回。

边界

本插件是工具层，不代替工具链：编译、烧录、调试分别依赖宿主机器上的 gcc / OpenOCD / gdb，插件只负责调用与结果归纳，不会替你安装任何外部程序。

面向范围是 STM32F103C8T6（64 KiB Flash / 20 KiB RAM）+ CMSIS-DAP 探针 + CubeMX 生成的 CMake 工程；其他型号、其他探针、非 CMake 工程均未验证。

.ioc必须走plan → apply` 事务，代码只能写在 USER CODE 块内——块外内容会被 CubeMX 重新生成时覆盖，且覆盖后编译不报错，故障表现为"改了不生效"。

stm32_generate 要求用 CubeMX 自带的 JRE 无头调用（jre/bin/java.exe -jar STM32CubeMX.exe -q <script>）；直接执行 STM32CubeMX.exe 会 detach 出 JVM 后假退出，看起来成功其实没有生成。

支持的 Node.js 版本：>=20。当前只在 Windows 上验收过（测试套件与目标工具链均为 Windows/msys64 路径）。

实现与发布准备过程中使用了 AI 辅助；发布前的文件内容、事实性声明与各项校验均已人工复核。