Config-driven ops

Config-driven ops 表示操作命令、硬件目标、端口、artifact、backend 或运行策略优先通过 checked-in 配置声明，而不是让维护者每次手写临时命令。它适合 MCU flashing、服务端口、部署资源和多 Agent 协作场景。

这个 Topic 关心“可复现的操作入口”：配置文件必须能让后续 Agent 或维护者知道应该连接哪个设备、监听哪个端口、读取哪个 artifact、使用哪个 backend，以及哪些参数允许覆盖。它排除纯个人 shell history、一次性 README 命令和没有被项目工作流消费的示例配置（projects/loadlynx.md、projects/flux-purr.md）。

当项目 snapshot 中该模式影响运行、交付、硬件操作或跨仓库复用时使用；如果只是一次性脚本或历史残留，先保留在项目笔记里，不急着提升为 Topic。

如果配置会决定真实硬件 flash、服务端口租约、daemon target、部署资源或 artifact selection，就应命中本 Topic。若配置只是 library 默认值、测试 fixture 或没有运维含义的 prettier/eslint 设置，通常不需要提升为 Config-driven ops（projects/loadlynx.md、projects/flux-purr.md）。

• 配置文件应位于 repo root 或清晰的项目入口，并与实际消费者保持邻近。
• 配置要写出 backend、chip、artifact、selector cache、端口或运行策略，让 Agent 不必猜默认值。
• 命令行可以覆盖少量安全参数，但不要把底层工具所有参数都透传成不受控输入。
• 生成项目快照时要把配置和实际入口成对记录：只写“有配置文件”不够，必须说明它被哪个 CLI、daemon、workflow 或预览流程消费，否则后续 Agent 仍然无法判断配置是否 current（projects/loadlynx.md、projects/flux-purr.md）。
• 对硬件和端口类配置，默认把冲突处理写进项目记忆：设备 selector、串口/probe、工作目录、scope id、port lease 都是资源归属的一部分，不应隐含在口头约定中（projects/loadlynx.md、projects/flux-purr.md）。

• projects/loadlynx.md：同一 repo 中声明 ESP32-S3 和 STM32G431 两个 target。
• projects/flux-purr.md：设备控制台与 firmware target 共享项目配置，适合检查 Web、firmware、硬件研究如何在一个仓库内协作。
• projects/pd-sink-stm32g431cbu6-rs.md：PowerVista/STM32 target 的 flashing 与 artifact 选择需要配置证据支撑，不能只靠临时命令。

• 配置不入库会让硬件操作变成口头记忆。
• 配置过度透传会绕过安全策略。
• 多个项目复用同一 daemon 时，project id 不稳定会导致资源冲突。
• 只记录配置文件名、不记录消费者和生效路径，会让 Agent 误以为配置已经接入运行链路。修正方式是在项目快照中同时引用配置路径和消费它的 CLI/workflow/doc 入口（projects/loadlynx.md）。
• 把 project id、端口或硬件 selector 写死成默认值，会在多 worktree、多 Agent 或多设备环境里互相踩踏。配置应让资源归属可审计，并配合端口/设备租约流程使用（projects/loadlynx.md）。

• projects/loadlynx.md
• projects/flux-purr.md
• projects/pd-sink-stm32g431cbu6-rs.md