approved-checklist-executor

Approved Checklist Executor

Prerequisite: read and obey the repository parent policy at skill/global_rules/SKILL.md first.

Use When

• A checklist or one or more atomic slices have already been approved.
• The task is now in execution state.
• The run mode may be:
  • single-slice mode
  • pulse mode

Core Rule

• Default to pulse progression when the approved checklist is fully authorized and no blocker appears.
• Preserve atomic discipline at all times:
  • one slice
  • one verification
  • one commit
  • one git status --short
• Execution should stay attached to the current campaign tree.
• A child fix may pause the parent campaign, but it may not silently become the new root campaign.
• Default to continuous execution inside the approved campaign.
• Do not stop merely because new information appears. Stop only when that information crosses a declared red line, invalidates the slice's core assumption, or creates scope drift that would make further execution dishonest.
• If the project exposes an execution lock such as active_contract.json, treat it as the current execution truth and continue from it rather than narrating a fresh broad contract.
• If the project also exposes a contract runner such as openclaw_harness_contract_runner.py, use it as the default execution-state transition entrypoint.

Explicit Submode: One-Breath Mode / 一口气模式

This submode is not the default.

It activates only when the user explicitly says things like:

• one-breath mode
• push continuously
• do not stop; finish the approved checklist
• continue until blocked
• 一口气模式
• 开启一口气模式
• 用一口气模式推进
• 不要停，一口气做完

When active, add these stronger rules on top of the normal executor discipline:

• keep moving continuously until a real blocker, failed verification, missing secret, or crossed red line appears
• emit a concrete progress update at least every 3 minutes during long-running work
• stop only on a real blocker, failed verification, missing secret, or crossed red line
• if a red line is crossed, write the smallest possible delta sub-contract and continue from it
• after the delta sub-contract is resolved, automatically return to the main approved contract
• do not inflate the pause into a fresh broad plan unless continuing would be dishonest
• do not pause externally just because one commit or one slice has completed; archive it and keep moving
• write detailed slice-level bookkeeping into harness artifacts rather than turning every slice boundary into a conversational stop
• use progress reports only in this structure, translated to the user's working language:
  • Proven / 已证明
  • Not Proven / 未证明
  • Why It Did Not Complete / 为什么没做成