用途：reflect 用于把一次会话中获得的经验固化为仓库内的持久改动，而不是写入独立的记忆库。该仓库没有单独的记忆库，下一个智能体需要知道的内容都放在仓库里，像代码一样被审查。
主要能力：扫描会话中的错误与收到的纠正、产品负责人的偏好、获得的代码库知识（坑点、某处为何如此）、库或工具的特殊行为（vendor/boring/、Flue、模型提供方）、技能（verify-app、new-agent）或 verify CLI 中的摩擦、重复的手动步骤。跳过琐碎或已记录的内容（可 grep AGENTS.md、docs/、skills）。
使用方式：按“最小持久形式优先”的顺序为每条经验选择落点：能写成结构就写成结构，例如 lint 规则（.oxlintrc.json）、架构规则（scripts/verify/ARCHITECTURE.json）、单元测试、verify 检查步骤、智能体 index.mjs 中的校验器、带证据的法则（docs/INVARIANTS.md + scripts/verify/VERIFY.json）或模型（formal/），此时不写散文；智能体重复犯的错误应成为 scripts/verify/ARCHITECTURE.json 中的规则，并附上其执行的法则或决策、修复提示，以及在 test/unit/architecture.test.mjs 中证明其会触发的夹具；更好的是让错误不可能发生（类型、单一辅助函数、约束），从而无需规则。其次是技能（向 hachej/boring-stack 提交 PR，修改 skills/<skill>/SKILL.md）；再次是功能地图（docs/verify/<area>.md）；然后是 docs/DECISIONS.md（决策及原因）；再是 AGENTS.md（每个智能体每项任务都需要的规则，保持简短，细节移到技能中）；上游缺口应作为 issue 或 PR 提交到 hachej/boring-ui-v3，绝不直接编辑 vendor/；模板（hachej/boring-app）相关的经验应说明以便进入模板，现有应用通过普通 PR 获取。改动放在当前分支或新分支，并说明改了什么。最后输出 Reflect summary，列出结构性改动、技能改动、文档条目、上游或模板事项。
限制：资料未提供具体安装命令、收费、价格、平台或效果信息。