tianemon/easymint/software-health

运行健康与 AI 契约

沿用户动作核对真实运行结果：完成是否真的完成、停止是否真的停止、状态属于谁、失败后能否继续，以及 Agent 的声明是否与执行能力一致。仅检查用户指定范围及解释该现象所必需的上下游。

选择专项

• 运行健康：读取 references/checks.md，检查状态、取消、失败恢复、资源和持续性能。
• Agent 行为或工具调用异常：读取 references/ai-contracts.md，检查最终上下文、工具注册、角色调度与配置生效时机。
• 只有问题跨越两类时才补另一份，不默认加载全部参考。

普通 diff、提交或模块功能正确性由变更审查处理；全仓缺陷、安全、结构与冗余普查由代码库审计处理。环境提供 code-review / ponytail-audit 时可按这些用途选择；不要为了完成一次健康检查连续调用它们。用户明确指定本技能时，在指定范围内检查相关健康风险，不因此扩大到全仓。专项本身不依赖其他技能安装。

建立可观察的判据

从实际入口追踪：用户动作 → 状态变化 → 外部操作与持久化 → 反馈 → 收尾。先选本次需要回答的问题，再找证据：

• 用户看到结束后，还有请求、进程或任务继续执行吗？取消后迟到结果还能写入吗？
• 关闭资源前，停止确认、输出排空和最终写入完成了吗？重复关闭会发生什么？
• 切换会话/账户/配置后，新旧操作的归属与生效时机一致吗？
• 操作失败或只枚举出部分结果，是否被当成正常空集合而触发清理？
• 反复打开/关闭或运行代表性负载后，监听、连接、计时器、缓存是否持续增长？
• 模型收到的工具、权限、角色和配置指令，是否对应运行时实际可用的能力？

这些是问题示例，不要求每次全部执行，也不把某个框架的行为推广到其他运行时。只验证与本次现象或后果有关的分支。

证据与执行边界

已有变更审查、审计或实测证据时，先列出已回答的问题与尚缺证据，只补缺口，不重复读完整材料或重跑相同检查。新增专项不能替代对原问题的直接核验。

区分已复现、源码可确定和未验证；退出成功、测试数量、短时内存变化都不能单独证明长期健康。性能用同环境基线和代表性负载；模拟服务结果不外推为真实供应商表现。

分析请求只交付分析；已授权修复只改相关链路。启动应用、真实服务/模型请求、发布和用户数据操作遵循已有授权，不因调用技能扩大范围。故障注入使用隔离数据与可控依赖，收尾释放自建资源；不改用户工作树制造反例。

交付

按发现说明触发条件、预期与实际、证据、用户影响，以及已修复或建议的最小动作。沿用项目严重度标准；项目未定义时直接说明后果与触发条件，不为评级复制一套标准。

没有发现时说明实际检查了什么及未覆盖什么；运行中取消、长时间负载或真实服务未验证时明确保留限制。不要把专项结果扩展成全程序无缺陷的保证，也不要为一次偶发问题另建持久化监控或检查框架。