Oneshot · 一次做完

一次请求就是一次完整工作。先恢复足够作出必要决定的上下文，再把实现、验证和交付 一次做完后交还。不要把半成品、未验证结果或一串本可自行决定的问题交回去。 范围停在请求本身；质量属于完成条件，不是以后再补的迭代。

先理解到能动手，再直接做完

恢复用户要的结果、验收依据、代码中的对应位置，以及项目已有的检查方式。探索只做到 能定位改动和取舍；不要巡览全仓，也不为“显得完整”先写长计划。请求来自 issue、PR 或验收列表时，以其正文为范围。

用现有计划或任务表记下关键步骤即可，不另建第二份权威计划，也不停下来等待对计划的 批准。现有模式能回答怎么做时，按它实现；命名、文件位置和接口形状从邻近代码恢复， 不发明另一套风格。

实现只覆盖请求所要求的行为。顺手重构、额外文档、相邻清理和“以后可能用到”的抽象， 都不在这次完成条件里。测试与注释只在没有它们就无法确认或理解这次改动时才加。

会改变结果的缺口才提问

技术默认、现有惯例和可逆选择直接作出，并在交付时用一两句话写明假设。只有缺少会 改变产物的用户偏好、公开契约、权限或不可逆授权时才停下提问。不要把“还可以有 另一种写法”升级成阻塞。

卡住时报告已尝试的路径、观察到的失败、仍有效的产物，以及继续所需的事实、能力或 授权。局部可完成的部分继续做完；不要用“已完成”包装缺口，也不要在同一错误上反复 空转。

请求实际包含多条可独立验收的工作流时，内部可按 divide-and-conquer 组织执行，但对用户仍一次交还整体结果。工作量大不是停下来改用另一种流程的理由。

交还前证明它已经成立

按项目已有方式定位并运行 lint、类型检查、测试和构建。优先跑与这次改动相关的检查； 声明了全量门禁或改动触及共享契约时，再跑相应范围。失败则只修自己引入的问题并重跑， 不把原有失败改称本次通过。

机械检查通过不等于行为成立。改了用户可见行为时，用项目已有测试、真实调用或运行 证据核对主路径和这次改动会碰到的边界。读过、检查过、测试通过和真实运行分别报告。

界面改动必须对着实际画面验收，不能只看源码或信测试通过。打开受影响的页面和状态， 走一遍真实操作，根据整屏与关键局部判断间距、对齐、层级、空态／错误／加载、深色 模式，以及与既有组件是否同一套语言。发现问题当场修再复看。需要更完整的视觉判断 时使用 interface-design； 多页面持续打磨使用 ui-improvement。 缺少预览条件时明确画面未验证，不能把源码正确说成界面已完成。

环境要求提交、推送或打开 PR 时，把这些当作交付的一部分，而不是实现之后另一次请示。 说明做了什么、验证了什么、哪些是假设。

完成条件

原请求的行为已经落地，必要检查已跑过，界面改动已经过画面判断，交付物（代码、验证 记录，以及环境所要求的提交或 PR）已经交还。未决假设写清，但不把已知缺陷留给下一轮。

核心设计被反例击穿、责任边界尚不成立时，使用 design-forge 或 architecture 处理那个未决判断，再回到本次实现；不要用一次做完跳过仍然未知的设计。 本方法组织一次交付，不替代领域方法。