openclaw/reporting-governance-plugin
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Clarify externalized silent long-task policy

Browse Source
This commit is contained in:
Eve
2026-04-22 14:46:11 +08:00
parent 83be99a6bb
commit 52f7f0a557
3 changed files with 26 additions and 17 deletions
Download Patch File Download Diff File Expand all files Collapse all files

16
skills/long-task-governor/SKILL.md
View File

@@ -144,10 +144,13 @@ A silent long-task must define at startup:
- what to report if not yet complete
- what status transition to use if there is no new evidence
- how final owner handoff will happen if a decision is expected
- whether an externalized checkpoint mechanism is actually bound, or whether the task must remain non-silent
Silent long-tasks must not rely on memory, intention, or implied future follow-up.
If the user later has to ask where the update went, the flow is considered failed.
If no externalized checkpoint path can be created safely, do not launch the task in silent mode.
---
## 6. No-fake-progress rule
@@ -190,11 +193,12 @@ When this skill applies:
2. if long task, create/update a task record
3. choose one of the five valid states
4. if the task is silent, define the first forced checkpoint before proceeding
5. if reporting progress, use the 5-part checkpoint structure
6. before claiming progress, check for real evidence
7. if no evidence and no concrete action, stop the clock
8. if the run is clearly heading toward a user pass/fail or accept/reject judgement on Telegram, prepare a button-path before the final handoff
9. if the entire test itself exists to validate Telegram decision closure, run it as a button-driven flow rather than a normal long plain-text report
5. if the task is silent, externalize the checkpoint path or keep the task non-silent
6. if reporting progress, use the 5-part checkpoint structure
7. before claiming progress, check for real evidence
8. if no evidence and no concrete action, stop the clock
9. if the run is clearly heading toward a user pass/fail or accept/reject judgement on Telegram, prepare a button-path before the final handoff
10. if the entire test itself exists to validate Telegram decision closure, run it as a button-driven flow rather than a normal long plain-text report
---
@@ -227,7 +231,7 @@ This prevents governed long-task flows from degrading back into ambiguous text-o
This skill is working correctly when:
- non-chat work always enters a governed state
- silent long-tasks never go dark without a predeclared checkpoint
- silent long-tasks never go dark without a predeclared and externalized checkpoint path
- checkpoints no longer cause silent stalls
- no-evidence updates are not mislabeled as progress
- stalled work becomes `paused` / `blocked` instead of fake-`active`