timebox

Timebox

结果

在规定时限内完成用户请求的全部工作及其决定性验证。这是硬性验收约束，而不是要求先做一段时间的部分工作。只有在截止时间前完成、验证并记录时间戳的工作才算通过。

适用情形

当用户使用 /timebox 并同时指定任务和时长或确切截止时间时使用，例如 /timebox 10 minutes fix and test the parser 或 /timebox by 16:00 EDT verify the release artifact。

如果缺少任务或时限，请先提出一个简洁的问题。通过 always-current-datetime 处理有歧义的日期或时间。时限必须为正数，且精确到足以计算一个绝对截止时间。

必需的准备

在接收任务前：

1. 加载 always-current-datetime 并获取其最新的本地时钟锚点。其 captured_at 值就是 timebox 的起始时间。使用工具而非心算，根据该锚点计算绝对截止时间。
2. 加载 starting-point。明确完整结果、决定性证据、范围、权限、未知事项和禁止的结果。
3. 加载 outcome-bounded-work。固定完整结果和证据，同时允许采用更快且安全的路径。
4. 加载 logic-audit。检查范围冲突、截止时间是否不可能、是否缺少证据，以及依赖项是否无法在时限内完成。

如果无法加载任何必需的技能，则停止并返回 contract-unavailable: <skill-name>。切勿用记忆中的文本替代其当前指令。

准入门槛

仅当以下条件全部满足时，才接受 timebox：

• 任务、验收标准和截止时间均明确无歧义。
• 所有必需的权限、输入、凭证、依赖项和人工决策均已具备，或有经过验证且能在时限内满足的时长上限。
• 所选路径保留完整的请求范围、安全规则和决定性验证。
• 每次工具调用、命令、重试和外部等待都有明确的最长时长。
• 预留了受保护的验证时间，用于决定性检查、结果审查和记录完成时间戳。
• 有界执行计划加上验证预留时间能够在截止时间前完成。

如果任何一项不满足，请勿开始。返回 TIMEBOX_NOT_STARTED，说明未满足的准入条件，并要求延长时限或明确变更范围。切勿基于无界估算承诺保证完成。

执行约定

1. 在首次执行工作前，记录开始时间、绝对截止时间、工作截止点、验证预留时间、结果和证据。
2. 从截止时间倒推。工作截止点为截止时间减去受保护的验证预留时间。
3. 选择能够保留所有已接受要求的最快路径。不得暗中降低范围、质量、安全性或证据要求。
4. 每次操作前，将其最长时长与剩余工作时间进行比较。不得开始可能超出工作截止点的操作。
5. 将命令和工具的超时时间设为不晚于适用的截止点。避免无限重试、等待、轮询和后台工作。
6. 子 Agent、排队任务、审批、重启和远程处理均视为未完成，直至其最终证据在 timebox 时限内可用。
7. 如果必需步骤已无法在时限内完成，仅当更快的路径仍保留完整约定时才可采用；否则立即停止并报告 TIMEBOX_FAILED。
8. 最迟在工作截止点开始决定性验证。不得占用受保护的验证预留时间进行实施工作。
9. 所有决定性检查通过后，记录完成时间戳。不得因重试、澄清、工具延迟或失败而重置或延长截止时间。

完成判定

仅当以下条件全部得到证实时，才返回 TIMEBOX_PASS：

• 所有已接受的结果均已完成。
• 每项决定性验证检查均已通过。
• 最终证据在绝对截止时间前已具备。
• 完成时间戳不晚于截止时间。
• 没有任何必需工作仍处于排队、已委派、等待批准或未经验证的状态。

如果已开始执行，但截至截止时间仍有任何条件未得到证实，则返回 TIMEBOX_FAILED。说明已完成的工作、已运行的验证、剩余工作、副作用和准确的时间结果，不要将部分进展描述为完成。

如果准入失败，则返回 TIMEBOX_NOT_STARTED。当无法在时限内支持所请求的保证时，这是正确的结果。

失败与安全规则

• 不要因为主要编辑已完成，而测试或检查仍未完成，就声称成功。
• 不要将队列提交、派发、工具确认或后台进程计为已完成的工作。
• 不要跳过、弱化验证，也不要将验证推迟到截止时间之后来制造通过结果。
• 不要隐瞒错过截止时间的事实。即使之后成功，本次执行仍属于 TIMEBOX_FAILED。
• 停止时应保留安全的中间状态，并报告该状态。不要为了赶上时限而仓促执行不可逆或敏感操作。
• 新任务或变更后的任务会使准入失效。只有在获得用户指定的新时限后，才能开始新的限时任务。

输出

准入时，说明开始时间、截止时间、完整结果、决定性验证以及受保护的验证预留时间。结束时，以 TIMEBOX_PASS、TIMEBOX_FAILED 或 TIMEBOX_NOT_STARTED 开头，然后给出完成时间戳、截止时间、证据和任何剩余工作。

渐进式披露

资源门槛：使用此处列出的软件包文件前，先运行 mise run validate。

PD-101：evals/cases.json 是客观压力测试用例及验收标准的权威文件。在测试、审查或更改此技能前，先加载它。此文件定义运行时行为，并链接到负责评估的文件。

验证

• 时钟基准来自当前的 always-current-datetime 指令。
• 准入评估涵盖了完整任务及其验证，而不只是实现工作。
• 在开始工作前，已计算绝对截止时间和验证预留时间。
• 每项操作都设定了界限，以确保在其截止时间前完成。
• 通过要求在时限内完成任务、决定性验证并取得最终证据。
• 部分完成、排队中、逾期或未经验证的工作均不能通过。

资源

• 记录准入或结束信息前，请阅读限时任务记录。
• 使用 assets/timebox-record.json 作为机器可读的字段模板。
• 使用 examples/ 查看准入、拒绝和通过的响应格式。
• 在此技能目录中运行 mise run ci，以执行 mise run test 检查。

工厂执行契约

可接受的结果是：只接纳能在硬性时间限制内达到完成条件的工作，并记录完成时间戳。更改其最小责任主体的同时，保留当前硬性时间限制行为。

1. 使用 mise run ci 冻结当前软件包并记录其摘要。
2. 运行 mise run domain-research-policy，然后判断当前硬性时间限制的来源和反证。
3. 针对指定的硬性时间限制操作运行 mise run agentic-request。将语义选择留给模型。
4. 运行 mise run decision-policy、mise run ci 和行为评估。返回到最低层的失败责任主体。
5. 运行 mise run invocation-policy -- <receipt>，并说明每项任务的处理情况，或说明其领域特定的不适用原因。
6. 可选择运行 mise run improvement-policy。仅当没有受保护维度出现退化时，才保留一个变更维度。

仅在需要其契约时，才通过 mise run use-case-policy 加载 assets/use-case-contract.json，并通过 mise run evals 加载 evals/evals.json。

Mise 负责可重复的机制、顺序、回执和检查。模型负责代码无法提供的解读、因果判断、创造性工作和直接感知。若缺少授权、证据过时或某个关卡未通过，则停止。