improve-loop 是一个自主循环技能，用于逐条完成 Windows 应用中的开发故事。每轮循环的处理顺序为：选取故事 → 规划 → 编码 → 运行 ./build.ps1 → 自测 → 截图 → 对比 → 修复 → 提交 → 更新 STORIES.md。循环在用户指定的里程碑完成后停止；如果未指定，则在当前里程碑完成后停止，然后向用户汇报。
用途与工作方式
- 选取：打开 docs/STORIES.md，在当前里程碑中取第一个依赖项已完成的待办故事，并将其状态设为 doing。
- 规划：如果故事新增界面、操作或文案且尚无 UX: block，则先调用 ux-design 技能。规划时写明哪些文件会变化、新增哪些模型字段、新增哪条命令和快捷键、哪个截图页面会体现它。若需要新增数据库列，要添加带 DEFAULT 的迁移步骤，保证已有数据库仍能加载。
- 编码：遵循 csharp-winui 和 windows-design 技能、故事的 UX: block，以及应用若有 design/DESIGN-SYSTEM.md 时的该文件。系统钩子遵循 os-integrations。每个页面文件保持约 300 行 XAML 和 300 行 code-behind 以内。新页面要加入 SidebarPage 枚举，以便截图模式访问。
- 构建、测试与截图：遵循 build-and-verify 技能。若故事包含逻辑，先添加单元测试或自测步骤（test-windows-app 技能）并观察其失败。使用种子数据（APP_SEED=1）让页面显示真实内容。
- 对比：用 Read 工具并排打开快照与故事的参考截图，按以下顺序记录有意义的差异：验收标准中缺失或错误的行为及错误数据；与 UX: block 或 docs/GLOSSARY.md 不同的文案与流程；布局问题（列错、顺序错、元素缺失、网格检查的每个 FAIL）；层级（最大、最粗、最先）；间距与对齐；颜色与细节。目标是使用 WinUI 自身控件实现相同结构与行为，而非像素级复制；当参考使用 Web 风格自定义控件而 WinUI 有原生控件（NavigationView、CommandBar、MenuFlyout、CalendarDatePicker、InfoBar）时，使用原生控件。若无参考截图（未克隆应用），则对比故事的验收条目与 windows-design 规则。只截取故事涉及的页面（tools/snap.ps1 -Pages ...），每个里程碑结束时截取完整集合。修复、重建并再次对比，每个故事最多三轮；若仍不匹配，将故事重置为 todo 并注明阻塞原因，然后继续。
- 提交与记录：执行 git add -A 与 git commit；在 docs/STORIES.md 中将故事设为 done 并与代码一起提交。每个故事一个提交，便于单独回滚；M1 的故事若共享同一骨架（模型、页面、列表、持久化）可作为一次提交，从 M2 起每个故事一个提交。
- 汇报：循环结束时向用户报告：已完成的故事（每条一行及对应快照路径）；被阻塞的故事及原因；用户应手动尝试的内容（全局快捷键、拖放）；下一条待办故事。最后运行 ./build.ps1 -Open 让用户试用新构建。
里程碑检查
当里程碑的最后一条故事完成时，在开始下一里程碑前调用 improve-architecture 技能。无人值守时，只执行其最强建议中标记为 Strong 的项，其余留在审查文件中供用户处理。当故事修复缺陷时，在 docs/FIXLOG.md 添加条目：症状、原因、修复，以及最后一行 Rule: <应始终或绝不要做什么>。修复日志的生命周期长于压缩后的历史记录，检查时会读取它。
无人值守运行
循环可在无人看管下运行，因为每一步都自我检查：构建、自测、快照、验收标准。要让它运行更久，启动时给出明确限制（如“完成 M2 后停止”），开始前确保工作树已提交，绝不让它接触用户的真实数据库。保持电脑解锁并唤醒：锁屏会导致快照渲染为空白。每个故事是独立提交，用户可在早上查看历史并回滚不满意的内容。
要同时构建多个功能（一套功能，或不同文件夹中的独立故事），给每个代理各自的 git worktree，并使用 tools/dev.ps1: ../../start/new-windows-app/suite.md 构建。
完成条件
当里程碑中每条故事都已完成，或在报告中以原因标记为阻塞；每条完成的故事都有独立提交；用户已收到报告时，循环完成。