Clarify execution-agent-dispatch scope and harden gateway rules

This commit is contained in:
2026-03-12 19:33:24 +10:00
parent 6ba8353506
commit 22e6292aba
5 changed files with 31 additions and 1 deletions
@@ -0,0 +1,6 @@
# 2026-03-12 execution-agent-dispatch status
- Tao confirmed the remembered conclusion: `execution-agent-dispatch` was tested before and did not solve the real inter-agent communication problem.
- Durable conclusion: the skill only helps with dispatch structure, worker reply format, escalation rules, and main-to-Tao forwarding discipline.
- It does **not** provide stable bidirectional communication between OpenClaw agents/subagents/ACP sessions.
- Current policy: freeze further development of this skill as a communication-layer solution; wait until OpenClaw ACP/runtime support is stable before resuming work in that direction.
+5
View File
@@ -0,0 +1,5 @@
# 2026-03-12
- Tao explicitly reinforced a hard rule after gateway disruption: on Tao's machine, do not run `openclaw gateway stop`, and do not assume `openclaw gateway restart` is safe. Treat restart-style lifecycle control as disruptive and approval-required.
- Durable lesson: before any gateway intervention, first run `openclaw gateway status`, report findings, prefer non-disruptive diagnosis, and get Tao approval for the exact lifecycle command if one is still necessary.
- Trigger for this rule: attempted gateway restart led to service becoming unavailable and Tao needing to manually reinstall/restore gateway service again. This is a high-friction failure and must not be repeated.