用途：当用户在运行中的应用观察到缺陷（视觉、行为、崩溃、性能）、一致性测试或单元测试失败、生成代码行为异常，或用户怀疑某个功能规格有误时使用。输入为模块名（对应 plain_modules/<module_name>/ 与 .plain 文件）和用户观察（缺陷描述、截图、测试失败、报错等），可选指定某个功能规格。
核心原则：plain_modules/ 与 conformance_tests/ 中的生成代码只读，仅作诊断证据；所有修复只写入 .plain 规格文件。流程为：观察 → 读生成代码 → 追溯到规格 → 修改规格。
流程：先读 .plain 文件（frontmatter、definitions、implementation reqs、test reqs、功能规格）及 import/requires 链，复述用户观察以确认预期与实际的差异。再读 plain_modules/<module_name>/ 生成代码，按 UI、逻辑、数据分别定位 widgets/views、业务逻辑/providers、models/repositories；必要时读 conformance_tests/ 或 test/ 中失败测试，判断测试期望是否符合规格。诊断五类根因：规格含糊、缺失规格、规格冲突、规格本身错误、缺少实现需求（implementation req）。
修复：含糊或错误的规格直接就地修改；缺失规格用 add-functional-spec；冲突用 resolve-spec-conflict；缺少实现需求用 add-implementation-requirement。修改应最小化、保留时间顺序、保持语言无关、遵守 200 LOC 限制，复杂时用 break-down-func-spec 拆分；修改后用 analyze-func-specs 检查是否引入新冲突，并逐一用 resolve-spec-conflict 解决。完成后重读 .plain 文件，并向用户汇报观察到的缺陷、生成代码的表现、涉及的规格、所做修改及重新渲染后的预期；不确定时先向用户确认。
使用前若尚未获取 ***plain 语法规则，需先用 load-plain-reference 技能。限制：不得修改生成代码或一致性测试；功能规格只描述行为，平台相关指引放在实现需求中；缺失事实资料未提供。