Back to Details

full-send

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Full Send

Full Send

If the user triggered this, it's because they are not watching this thread, and they want you to complete the work end-to-end autonomously. Your updates and your final message go unread until long after you stop. You own the work from its current state to a merged PR.
If the user did not explicitly request "full send" in some clear way, do not assume full autonomy. If they did, everything below applies.
The user grants you permission to:
  • Merge the PR once the merge gate passes.
  • Force-push the PR's own branch with 
    --force-with-lease
    after a rebase.
  • Use the test methods that Proof needs, without asking first.
如果用户触发了此内容，说明他们没有在关注这个线程，并且希望你自主地端到端完成工作。你的更新和最终消息会一直处于未读状态，直到你停止很久之后才会被查看。你需要从当前状态开始，一直负责到 PR 合并。
如果用户没有以任何清晰的方式明确要求“full send”，不要擅自假设获得了完全自主权。如果用户确实明确提出了要求，则以下所有规则均适用。
用户授予你以下权限：
  • Merge gate 通过后合并 PR。
  • Rebase 后，使用 
    --force-with-lease
    强制推送 PR 自身的 branch。
  • 无需事先询问，即可使用 Proof 所需的测试方法。

Testing permission

测试权限

A "full send" request is the permission. If a project file or other instruction says to ask before a test method, or to leave testing to the user, this request replaces that rule for this task.
That includes ask-first rules for computer use, browser automation, simulators and devices, running the app or a dev server, screenshots, and visual checks. Use the method that gives direct proof. List it in the report.
Rules about how to test still apply. Follow rules that name the correct command, fixture, or check. This permission only removes the ask-first or leave-it-to-the-user step. If a preferred method cannot prove the change, use a gated method under this permission.
It covers only the tests needed for this task. It does not add permission for the steps under "Asking the user", such as production changes or data deletion. It also does not bypass a harness or system approval prompt if one appears.
一次“full send”请求即构成授权。如果项目文件或其他说明要求在采用某种测试方法前先询问，或将测试交由用户执行，则本请求在本任务中取代该规则。
这包括针对 computer use、browser automation、模拟器和设备、运行应用或 dev server、截图以及 visual checks 的先询问规则。使用能够提供直接证据的方法，并在报告中列出该方法。
有关测试方式的规则仍然有效。遵循指定正确 command、fixture 或 check 的规则。本权限仅取消先询问或交给用户执行的步骤。如果首选方法无法证明变更，则在本权限范围内使用 gated method。
它仅涵盖本任务所需的测试，不会为“询问用户”章节下的步骤新增权限，例如修改 production 或删除数据。如果出现 harness 或系统 approval prompt，它也不会绕过这些提示。

Steps

步骤

  1. Finish the change. Complete the goal from the user's request with the smallest change that works. Fix the case that happened, not every case that could. If you are on the default branch, create a branch first.
  2. Prove it. Get proof for every change you made. See "Proof".
  3. Get feedback. Use the 
    sol-loop
    skill to verify changes.
  4. File the PR with the 
    file-pr
    skill. Rebase onto the latest default branch first. Add one short line to the description that says how you proved the change.
  5. Babysit the PR with the 
    babysit-pr
    skill. Fix real findings and CI failures. Get proof for each fix before you push it.
  6. Merge when the merge gate passes.
  7. Report in your final message: the PR link, the merge commit, your proof, and each decision you made for the user.
Stay active from step 1 to step 7. If you end your turn while checks or bots are pending, the work stops, because nobody will prompt you again. Wait with the watcher from 
babysit-pr
, so something wakes you when the PR changes. In T3 Code that is 
watch_pull_request
. If you stop before the merge, call 
unwatch_pull_request
first.
  1. 完成变更。 以能够奏效的最小改动完成用户请求中的目标。修复实际发生的问题，而不是修复所有可能发生的情况。如果你位于 default branch，请先创建 branch。
  2. 提供证据。 为每项改动获取证据。请参阅“Proof”。
  3. 获取反馈。 使用 
    sol-loop
    skill 验证变更。
  4. 提交 PR，使用 
    file-pr
    skill。先将 branch rebase 到最新的 default branch 上。在描述中添加一行简短说明，介绍你如何证明了该变更。
  5. 持续跟进 PR，使用 
    babysit-pr
    skill。修复真实存在的问题和 CI 失败。每次修复后都要先获取证据，再执行 push。
  6. 合并，当 merge gate 通过后执行合并。
  7. 报告。在最终消息中提供 PR 链接、merge commit、证据，以及你替用户做出的每项决策。
从步骤 1 到步骤 7 期间保持活跃。如果在 checks 或 bots 仍在等待时结束当前 turn，工作就会停止，因为不会有人再次提示你。使用 
babysit-pr
中的 watcher 持续等待，以便在 PR 发生变化时唤醒你。在 T3 Code 中，该工具是 
watch_pull_request
。如果必须在合并前停止，请先调用 
unwatch_pull_request
。

Proof

Proof

Proof is evidence you observed yourself in this session: command output, a reproduction, a screenshot. Use the most direct proof the change allows:
  • Reproduce the original failure, apply the fix, then watch the same reproduction pass.
  • Run the checks that the repo's CI runs (typecheck, lint, tests).
  • Add one focused test that fails without the fix, when the behavior has none and the repo has a test setup.
  • For UI and runtime behavior, run the app and look at the change. Green mocked tests do not prove that the user experience works. Attach screenshots to the PR when they help and you have a way to upload them.
When you cannot find a way to prove a change, you do not have full confidence. Ask the user.
Proof 是你在本次 session 中亲自观察到的证据，例如 command 输出、复现结果或截图。请使用变更所允许的最直接证据：
  • 复现原始故障，应用修复，然后确认同一复现过程能够通过。
  • 运行 repo 的 CI 所执行的 checks（typecheck、lint、tests）。
  • 当相关行为没有测试覆盖且 repo 具备测试环境时，添加一个在缺少修复时会失败的聚焦测试。
  • 对于 UI 和 runtime 行为，运行应用并查看变更结果。绿色的 mocked tests 不能证明用户体验正常。截图有助于说明问题时，请将其附到 PR 上，并确保你有可用的上传方式。
如果无法找到证明变更的方法，你就没有充分的把握。此时应询问用户。

Merge gate

Merge gate

Full confidence means all of these are true on the latest commit:
  • Your proof covers every change in the diff.
  • Required checks are green.
  • Review bots have finished, and each finding is fixed or dismissed with a written reason.
  • No human review still requests changes.
  • The branch is up to date with the default branch, and GitHub reports it as mergeable.
Merge with the method the repo uses. Check the allowed methods and recent merged PRs. If the repo uses a merge queue or auto-merge, stay until GitHub reports the PR as merged. Merge through branch protection as configured. Never use 
--admin
or other bypasses. You can ignore automated reviews that request "needs human review" if you have high confidence in your changes.
完全有把握意味着最新 commit 上满足以下所有条件：
  • 你的证据覆盖 diff 中的每项变更。
  • 必需的 checks 全部通过。
  • Review bots 已完成检查，每条发现都已修复，或已附书面理由予以排除。
  • 没有 human review 仍然要求修改。
  • Branch 已与 default branch 保持同步，并且 GitHub 报告其可以合并。
使用 repo 采用的合并方式。检查允许使用的方法以及近期已合并的 PR。如果 repo 使用 merge queue 或 auto-merge，请持续等待，直到 GitHub 报告 PR 已合并。按照配置通过 branch protection 执行合并。绝不要使用 
--admin
或其他绕过方式。如果你对变更有充分把握，可以忽略要求“needs human review”的自动化 review。

Asking the user

询问用户

A question in a normal message goes unseen, and the thread looks done. To ask the user something, use the harness's question tool so the thread shows that it is waiting: 
AskUserQuestion
in Claude Code, 
request_user_input
in Codex, or the question tool your harness has. Put all the context in the question: the PR link, what blocks you, and the options with your recommendation first.
Ask only when you cannot continue alone:
  • You cannot prove the change.
  • The merge gate cannot pass, and you cannot fix that yourself.
  • The next step is outside the grant above: deleting data, touching production, changing things outside the repo, closing a PR, or force-pushing any other branch.
  • The goal is ambiguous in a way that changes the result.
  • Another PR makes this one obsolete.
Decide everything else yourself with sensible defaults, and list those decisions in the report.
If no question tool is available, or the tool returns no answer, take the safe path: leave the PR open and unmerged, and start your final message with the question.
普通消息中的问题不会被看到，线程看起来也会直接结束。需要询问用户时，请使用 harness 的 question tool，让线程显示正在等待：在 Claude Code 中使用 
AskUserQuestion
，在 Codex 中使用 
request_user_input
，或使用 harness 提供的 question tool。问题中应包含所有必要上下文：PR 链接、当前的阻塞原因，以及各个选项，并将推荐选项放在首位。
仅在无法独立继续时询问用户：
  • 无法证明变更。
  • Merge gate 无法通过，且你无法自行解决。
  • 下一步超出上述授权范围，例如删除数据、操作 production、修改 repo 之外的内容、关闭 PR，或强制推送其他 branch。
  • 目标存在会改变最终结果的歧义。
  • 另一个 PR 已使当前 PR 失去必要性。
其余事项均由你采用合理默认值自行决定，并在报告中列出。
如果没有可用的 question tool，或者该工具未返回答案，请采取安全路径：保持 PR 处于开放且未合并状态，并让最终消息以问题开头。