Add silent long-task checkpoint gate

WORKFLOW_GATES.md

@@ -31,6 +31,31 @@ This especially applies to:
 
 If the endpoint is predictably a user decision, the assistant should structure the run so that the final user-facing handoff is already prepared as a button interaction.
 
+### Silent Long-Task Checkpoint Gate
+
+If a long-task is started and it will **not naturally produce an immediate next user-visible message**, it must define a forced reporting checkpoint at startup.
+
+This applies to any silent long-task pattern, including but not limited to:
+- research
+- investigation
+- debugging
+- delegation / waiting on subagents
+- background execution
+- staged analysis
+- long-running verification
+- full tests / regression tests
+- any "I’ll go do this and report back" workflow
+
+At startup, the task must define:
+1. the **first checkpoint trigger** (time, stage, or event)
+2. what to report if the task is **not yet finished** by that checkpoint
+3. how to downgrade status if there is **no new evidence** (`paused` / `blocked`)
+4. how final owner handoff will work if a user decision is expected
+
+### Failure rule
+
+If a silent long-task was started without a forced reporting checkpoint, and the user later has to ask "why is there no update?", treat that as a workflow failure / checkpoint-lost condition.
+
 ### Button-driven test rule
 
 If a test or validation flow is known in advance to end in a Telegram pass/fail, accept/reject, or rerun/stop decision, do not start that test in the ordinary text-reply lane.
@@ -53,6 +78,7 @@ These are violations when used as the closing interaction on Telegram:
 - saying buttons will be used, but not actually sending them
 - sending explanation first, and only later sending buttons after being corrected
 - running a full test/report in plain text even though the result is obviously heading toward a pass/fail owner decision
+- starting a silent long-task without any explicit forced reporting checkpoint
 
 ### Required interpretation
 
@@ -63,14 +89,17 @@ The gate applies to:
 - next-step choices
 - accept / rerun / stop style decisions
 - pass / fail verdict requests
+- silent long-task launches
 
 ### Violation standard
 
 If the assistant reaches a user-decision closure and no real inline buttons were delivered first, treat it as a workflow violation even if the reply mentioned buttons in text.
 
+If a silent long-task goes dark because no forced reporting checkpoint was defined, treat it as a workflow violation even if the task later resumes.
+
 ### Corrective rule
 
 If this violation happens:
 - acknowledge the violation plainly
-- immediately send the real button message
+- immediately send the real button message or status recovery update
 - record the lesson into workflow / memory if it exposed a missing rule