human-checkpoint

Human Checkpoint

Mission

Request human decisions only at meaningful risk or decision points, using executable options.

Interaction Channel Policy

For checkpoints that require user input, choose interaction channel in this order:

1. In moderate or detailed, prefer built-in user-question tool (request_user_input) for all required user interactions.
2. If the built-in tool is unavailable in the current runtime, degrade to concise plain-text questions in chat.
3. In full-auto, avoid non-essential questions and trigger checkpoints only by mode policy.
4. Never silently skip a required checkpoint because the preferred channel is unavailable.

Mode-Aware Trigger Policy

1. full-auto
   • Trigger only for hard blockers or major safety risks.
2. moderate
   • Trigger for plan-finalization confirmations.
   • Trigger before high-resource actions.
   • Trigger for major safety risks.
   • Trigger for required intake clarification and parameter confirmations.
   • Trigger for replan confirmations when route changes materially.
3. detailed
   • Trigger when path is unclear.
   • Trigger before high-resource actions.
   • Trigger for major safety risks.
   • Trigger for required intake clarification and parameter confirmations.
   • Trigger for replan confirmations when route changes materially.

Always trigger for shared-memory publication.

Major Safety Risk Examples

Treat these as major risks:

1. potential large-scale file deletion
2. likely secret leakage
3. destructive remote/shared resource mutation
4. actions with clear financial or operational damage potential

In all modes, checkpoint is required for major risks.

Request Format

Use this structure:

1. Decision Needed
2. Context
3. Options
4. Recommendation
5. If Approved
6. If Rejected

When using request_user_input, map the same structure into 1-3 short option-based questions. When using plain-text fallback, ask one concise direct question at a time.

Required Option Set for Risky Actions