Files
reporting-governance-plugin/docs/runbooks/silent-long-task-reminder-contract.md

3.1 KiB

Silent Long-Task Reminder Contract

This runbook defines the minimum contract for any reminder / forced checkpoint used by a silent long-task.

Goal

A reminder must not be a vague "still working?" ping. It must carry enough context to force an honest state update.

Minimum fields

Every reminder / forced checkpoint should include:

  • this is a reminder / forced checkpoint
  • task name
  • original goal
  • what counts as evidence
  • what to do if still unfinished
  • what to do if there is no new evidence
  • how to hand off if owner judgement is needed

Contract shape

Recommended structure:

  1. Reminder: This is a forced checkpoint for a silent long-task.
  2. Task:
  3. Goal:
  4. Evidence that counts: <file change / verification output / decision / blocker change / external result>
  5. If unfinished: report current status, latest real evidence, next step, next report condition.
  6. If no new evidence: do not claim progress; downgrade to paused or blocked.
  7. If owner judgement is needed: use the planned handoff path (for Telegram, usually button-path).

Example reminder text

Example 1: Research task

Reminder: This is a forced checkpoint for a silent long-task. Task: Research OpenClawGovernor concepts Goal: Identify what concepts are worth borrowing into our current agent governance model. Evidence that counts: new findings, comparisons, extracted design principles, concrete conclusions. If unfinished: report current status, real findings so far, next step, and next report condition. If no new evidence: do not claim progress; mark paused or blocked. If owner judgement is needed: hand off with the planned decision path.

Example 2: Debugging task

Reminder: This is a forced checkpoint for a silent long-task. Task: Diagnose Telegram reply closure bug Goal: Find why button-first ordering still fails in some full-flow cases. Evidence that counts: reproduced failure, narrowed root cause, code/path identified, mitigation validated. If unfinished: report current status, latest concrete evidence, next debugging step, and next report condition. If no new evidence: stop pretending active progress; mark blocked or paused. If owner judgement is needed: summarize findings and use the planned handoff.

Example 3: Delegated / waiting task

Reminder: This is a forced checkpoint for a silent long-task. Task: Wait for delegated survey result Goal: Receive and validate the subagent survey result for next-step decisions. Evidence that counts: new subagent output, session history retrieved, re-dispatch done, blocker identified. If unfinished: report current waiting state, last real evidence, next action, and next report condition. If no new evidence: do not keep task cosmetically active; mark blocked or paused. If owner judgement is needed: use the planned Telegram decision handoff.

Writing guidance

  • Write reminder text so it reads naturally when fired.
  • Avoid internal jargon without context.
  • Make the task and goal explicit enough that the forced checkpoint is self-contained.
  • A reminder should force honesty, not enable fake activity.