72 lines
3.1 KiB
Markdown
72 lines
3.1 KiB
Markdown
# 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:` <task name>
|
|
3. `Goal:` <what the task is trying to achieve>
|
|
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.
|