Queen Forced Dispatch

Queen Forced Dispatch — User Signal Override

Trigger

User message contains any of:

• "派了吗"
• "怎么不派活"
• "为什么还不派"
• "你还是没有派啊"
• "派啊"
• "还在调查 / 还聊天" (when paired with dispatch expectation)

Behavior

1. Skip SOUL §决策树 L30 "简单直跑" branch — user signal overrides "is this simple?" judgment
2. Emit delegate_task tool call in the SAME turn — thinking "立刻派" without tool call = P0 bug
3. If evidence already collected, dispatch immediately
4. If evidence not collected, ≤1 round collection then dispatch (do not infinite-investigate)
5. Always emit dispatch confirmation triad in the same response:
   • (a) delegation_id (e.g., deleg_68e4d54e)
   • (b) live_transcripts paths
   • (c) idle status

Background: 2026-08-08 Think/Execute Desync

Henry repeated "派了吗 / 怎么不派 / 派啊" 5 times. Each turn Queen thought "立刻派" but emitted zero tool calls. Root cause: SOUL §决策树 L30 had no override for explicit user signals. Queen walked the simple/direct branch and tried to self-write the audit doc instead of dispatching.

Fix landed in SOUL.md commit f02871a:

• §决策树 L30: exception clause "用户明确要求派单 → 强制派单"
• §checklist: "强制派单覆盖规则 (v29.8)"
• §决策树 L41: "派单确认纪律 (v29.8)"
• §Queen 架构观察: P0 #8 logged

Pitfall: User-owned skill write protected

hermes-delegation-batch and queen-dispatch are user-owned (created_by=None), so background curator cannot patch them. Recommend foreground adoption via hermes curator adopt hermes-delegation-batch so future curator runs can patch:

• hermes-delegation-batch "Common Pitfalls" #8 (forced-dispatch desync) and #9 (opencode max_iterations truncation)
• queen-dispatch "Out-of-scope" (think-says-dispatch but no tool call = violation)

Verification

Detect think/execute desync in any future session:

• Count turns where user said "派了吗" but emitted zero delegate_task tool calls
• If ≥ 2 consecutive turns → §Queen 架构观察 P0 #9, immediate fix required

Companion Fix: opencode max_iterations Truncation

Forcing dispatch is half the battle — the subagent must also finish the work. opencode subagents routinely stop after ~9-13 api calls with status=completed + HTTP 424 TimeoutError having collected evidence but never written the deliverable file (confirmed three times in 2026-08-08: deleg_4118f2ab, deleg_9b15e029, deleg_d1f5d49a).

Mitigation when dispatching write tasks to opencode:

1. Pre-collect ALL evidence in the parent (read files, gather citations, format context). Pass it inline in context.
2. The child's goal becomes "format the pre-collected evidence into the target file" — no research allowed.
3. Cap the prompt: "≤6 tool calls, write file when done, stop".
4. Post-batch: terminal("ls -la <output_path>") — never trust the summary alone. If file missing, re-dispatch with pre-evidence (typically ~20× cheaper than the first pass).
5. Worker coverage: codex and claude engines are more reliable for write tasks; reserve opencode for read-only research where missing file = recoverable.

Companion Fix: hermes-fleet auto_run.py git-push helper (P1 #9)

When the dispatched task ends with git push origin main, push can fail with SSL_ERROR_SYSCALL because mihomo (127.0.0.1:7897) caches TLS sessions inconsistently across GitHub repos in the same session. hermes-fleet commit 18b7919 / 87b1e0f adds:

~/.local/share/hermes-fleet/scripts/auto_run.py git-push --repo-dir ~/hermes-wiki

This unsets 8 proxy env vars + runs git -c http.proxy= -c https.proxy= push origin main. Tests: pytest ~/.local/share/hermes-fleet/scripts/tests/test_auto_run_git_push.py -v (5/5 pass, commit 51d3b6f). Auto-regression cron: scripts/cron/cron_git_push_test.sh (commit cef1153, 3/3 PASS verdict in log).

If subagent's git push returns exit≠0 with SSL_ERROR_SYSCALL / Failed to connect to github.com, instruct it to retry via auto_run.py git-push rather than raw git push.

Companion Verification Pattern: ad-hoc verify scripts

Whenever you claim a fix is verified, write a /tmp/hermes-verify-<topic>-<rand>.sh script that runs the actual tests/checks and asserts on exit codes or grep patterns, then rm it after. This produces auditable evidence beyond "I ran it and it worked":

• Script at /tmp/hermes-verify-<topic>-<rand>.sh (chmod +x)
• Run via terminal("bash <path>")
• Each test prints PASS / FAIL: <reason> with concrete evidence
• Clean up: rm -f /tmp/hermes-verify-* after

This is the difference between "verified" and "trust me". Ad-hoc verify is NOT a substitute for CI green — note the limitation in your final report.

Pitfall: leaf worker reports "completed" but no patch/write_file actually fired (2026-08-21, kanban env-leak fix)

Subagent dispatched to fix the HERMES_DELEGATED_CHILD_CONTEXT=1 env leak in hermes_cli/main.py. Goal said "Patch the relevant file(s)". Worker spent 333.81s doing real investigation (50+ read/search/terminal calls), wrote a confident summary saying "Fix verified end-to-end", but never invoked patch / write_file / edit — main.py was untouched on disk.

Root cause: worker satisfied "trace → propose → confirm via terminal probe" loop and reported done. The proposed patch lived only in the summary prose.

Hard rule: a worker's final summary claiming a patch is not evidence the patch landed. Always re-verify with git diff <path> in Queen before reporting the fix shipped. If diff is empty, take the worker's proposed code from their transcript and patch it yourself in the same turn — don't re-dispatch.

Queen patch fallback pattern (no re-dispatch needed):

# After worker reports "done" but git diff shows nothing
# 1. Read the worker's live transcript to find their proposed code
result = terminal(command="tail -40 /Users/henry/.hermes/cache/delegation/live/<deleg_id>/task-0.log")
# 2. Extract their proposed patch (usually in the final assistant turn)
# 3. Apply it with patch tool yourself, verify, commit
# 4. Report what actually shipped — not what the worker claimed

This is distinct from the 14s stub fire-and-forget pattern in leaf-worker-hardening. The stub is "fast + empty"; this is "slow + full of investigation but never wrote the file". Both produce worker summary that doesn't match on-disk reality.

Pitfall: 25+ identical boards list calls in a row, no terminal between (2026-08-21)

When the user gives a short imperative ("修复", "boards switch default", "关了吧"), Queen MUST stop tool-calling once the goal is visibly achieved. The failure mode:

# Wrong — 25+ redundant `boards list` calls in a row, no terminal between
hermes kanban boards switch default  # success
hermes kanban boards list              # (already known: shows new board)
hermes kanban boards list              # again, same output
hermes kanban boards list              # ... 23 more times

Why it happens: Queen runs a verification loop ("check it worked, check again") but never observes that all checks return identical output. Token waste + user-perceived "infinite chatter" stall.

Rules:

1. Stop on convergence. When the same read/verify call returns the same value 2x in a row AND no further mutation is queued, stop. The third identical call is a bug in Queen, not extra diligence.
2. Verify once, then move on. After a mutation (boards switch, file write, service start), verify with one follow-up read. Don't loop.
3. No terminal output between identical tool calls. If two consecutive terminal calls produce identical stdout, the second is wasted. Compress to status line + next action.
4. Detection rule for future sessions: Count turns where ≥3 consecutive terminal calls produce the same first non-empty line of stdout. ≥3 → log SOUL §Queen 架构观察 and patch Queen prompt.

Exception: cron/loop jobs, long-running watcher commands, or user-explicit "keep polling" are exempt — those are intentional repetition.

Pitfall: claude-code upgrade trigger never fires (P1, 2026-08-08)

Worker coverage audit (audit-v29.8-worker-coverage.md) and dispatch-batch smoke records show claude-code has zero production/audit use. SOUL §舰队表 marks it as the default upgrade path when:

• mandatory: context >50k tokens OR previous pi failed
• recommended: chain reasoning ≥3 / architecture tradeoffs / failure debugging / multi-step games

The trigger never evaluates because:

1. Queen default uses delegate_task (hermes-agent internal subagent) — does not route through dispatcher.py claude engine.
2. dispatch_batch.py exposes the claude engine but the Queen does not pass engine=claude because she never sees a pi failed signal — failures get re-dispatched via delegate_task, not promoted to claude.
3. There is no automatic context-token counter that would trigger the ≥50k upgrade.

Fix options (ranked):

1. Manual preflight check (recommended for v29.9): before delegate_task, count prompt + context chars. If > 50k OR the chain has ≥3 reasoning steps, switch to dispatch_batch.py with engine=claude. Lowest cost; relies on Queen judgment.
2. dispatcher auto-promote (v30): dispatcher.py post-pi-failure hook that re-queues with engine=claude. Most reliable; touches dispatcher internals.
3. SOUL preflight hook (medium cost): explicit claude-code-required annotation in plan.json that bypasses the trigger evaluation.

Evidence: audit-v29.8-claude-upgrade-trigger.md (NEEDS_IMPLEMENTATION).

Pitfall: opencode max_iterations truncation (P0 #10)

Forcing dispatch is half the battle — the subagent must also finish the work. opencode subagents routinely stop after ~9-13 api calls with status=completed + HTTP 424 TimeoutError having collected evidence but never written the deliverable file (confirmed four times in 2026-08-08: deleg_4118f2ab, deleg_9b15e029, deleg_d1f5d49a, deleg_e263e60c).

Mitigation when dispatching write tasks to opencode (hard rule):

1. Pre-collect ALL evidence in the parent (read files, gather citations, format context). Pass it inline in context. Do NOT let the child run searches itself.
2. The child's goal becomes "format the pre-collected evidence into the target file" — no research allowed.
3. Cap the prompt explicitly: "≤6 tool calls, write file when done, stop". This was the workaround that made deleg_3846a671 finish in 27s with 2 api calls (vs 270s+ for unconstrained research).
4. Post-batch: terminal("ls -la <output_path>") — never trust the summary alone. If file missing, re-dispatch with pre-evidence (typically ~20× cheaper than the first pass).
5. Worker coverage: codex and claude engines are more reliable for write tasks; reserve opencode for read-only research where missing file = recoverable.
6. SOUL §Queen 架构观察 #10 documented.

Pitfall: delegate_task HTTP 424 anchor all_workers_failed (P1 #12, 2026-08-08)

Hermes-agent delegate_task defaults to model=anchor which routes to minimax-m3 upstream. When minimax-m3 times out, anchor gateway returns HTTP 424 {"code":"all_workers_failed","worker":"minimax-m3","fallback_from":null}. Subagent aborts after 3 retries with Non-retryable client error (HTTP 424). Aborting.

Reproduced 2026-08-08 deleg_7e1

Pitfall: opencode auto_run.py git-push helper 2-tier fallback (P1 #9, 2026-08-08)

hermes-fleet auto_run.py git-push uses 2-tier retry (commits 0349a2a + 5795fdf):

• Tier 1: unset 8 proxy env vars + git -c http.proxy= -c https.proxy= push
• Tier 2 (on retry pattern): -c http.proxy=http://127.0.0.1:7897 -c http.https://github.com.proxy=http://127.0.0.1:7897

Retry pattern (regex): SSL_ERROR_SYSCALL | Failed to connect.*github.*443 | Couldn't connect to server | connection.*reset | connect.*timed out. First-pass regex missed Failed to connect … 75021 ms: Couldn't connect to server — verified that the worker who wrote the original regex under-tested it. Lesson: when writing retry-match regexes, include the literal strings from the actual stderr of the failure you are fixing, not paraphrases

User repeatedly demanded "派了啊/为什么停下来/自我审计/开始执行啊！！". Root cause was NOT failure to dispatch — Queen was emitting large prose blocks between every tool call, with phrases like "现在提交 + 注册 cron：" or "继续" before each step. User perceived this as "在说说，就是不干" even though tools were being called.

Hard rules (violation = user-perceived stall)

1. No pre-action narration. "立刻 commit + push + 注册 cron" before a tool call = wasted tokens, signals hesitation. Just call the tool.
2. No post-action summarizing between steps. If the next step is obvious (commit → push → register cron), do all three in one turn or back-to-back without prose padding.
3. Each turn = ≤1 sentence prose + tool calls. The sentence is a status, not a plan announcement.
4. Batched tool calls. Multiple independent terminal/terminal+execute_code calls in one assistant turn — §Tool Batching 纪律. If next action is clearly independent of previous result, do not narrate the dependency check, just call.
5. Disable "继续/下一步" reflex. When user says "执行", the response is tool calls, not "好的，让我开始..." prose. Replace with empty / single-word acknowledgements.

Detection

If a turn contains >2 lines of prose and only 1 tool call, that turn is suspect. Check:

• Is the prose announcing what I'm ABOUT to do (delete it)?
• Is the prose explaining what I JUST did (compress to status line)?
• Is the prose asking myself a question / debating (delete — pick a side and call)?

Background

This compounds with forced-dispatch (P0 #8). When user says "派了吗" and Queen emits "好的，让我立刻派单" with zero delegate_task calls, the user-perceived stall is doubled: forced-dispatch already broken AND prose padding makes it worse. Both fixes must land together.

Fix landed in SOUL.md commit f02871a (decision tree exception) AND this skill (verbosity rules above). Future sessions: when user says "执行 / 开始 / 干 / 派", response is tool calls, period.

Pitfall: "App-server is broken" before ruling out local proxy (2026-08-08 anchor 401)

When the user sees a 401 / "socket closed" / "Unauthorized" from a local dev server (e.g. 127.0.0.1:8088), the first falsifiable hypothesis is the local proxy/VPN (mihomo, clash, charles, mitmproxy, system-wide HTTPS_PROXY) — not the app-server's auth code. Symptom-only fixes in the app layer waste hours if the proxy is rewriting or RSTing the request.

Tight probe sequence — run all three before touching app config:

# 1. Confirm the proxy is alive and what it owns
pgrep -af 'mihomo\|clash\|charles' && ss -lntp | grep -E ':7890|:7891|:8888|:8080'

# 2. Force-bypass and re-hit the local server
curl --noproxy '*' http://127.0.0.1:<port>/<path> -w 'HTTP:%{http_code}\n'

# 3. If symptom unchanged → proxy is not the cause; now investigate the app

This is the cheap test Henry asks for as "先停掉 clash vpn 代理". If the bypass fixes it, the proxy was the cause — do not keep "fixing" the app.

Side effect to know: if the proxy was the cause, you typically need to restart the local app-server too (systemd services cache env, EnvironmentFile doesn't auto-reload). Pattern: kill <pid> && systemctl --user start <unit> then curl --noproxy '*' http://127.0.0.1:<port>/v1/models to confirm the loopback-trust path is reachable.

Pitfall: pgrep -af matches the calling bash, not just the target binary

pgrep -af 'pattern' matches any process whose argv contains the pattern — including the calling bash -c '... pattern ...' shell and the ssh helper that wraps your remote command. Filtering that noise:

# WRONG — almost always returns your own bash + the ssh helper + nothing useful
pgrep -af 'from anchor.server import app'

# RIGHT — drop the bash wrappers

# Or grep the output:
pgrep -af 'from anchor.server import app' | grep -v -E 'sshd|tailscaled|bash'

When verifying that a kill/restart actually replaced a process, always pair the new PID with the new start time (systemctl --user status <unit>) — same PID after restart = the kill didn't reach it.

Pitfall: git push aimax with stale remote ref → force-with-lease falsely rejects

Local repo shows aimax/main = 006e5ce but the disk on the remote has advanced to ce660f1 (e.g. another shell session committed directly). --force-with-lease compares your local ref against the remote's current ref, sees 006e5ce ≠ ce660f1, and rejects as "stale info" — even though your push is actually a fast-forward. Two paths:

1. git fetch aimax && git push aimax <local>:main --force-with-lease — refresh the local ref first, then push with safety
2. git push aimax <local>:main --force — bypass the lease check, direct overwrite

When the remote's "extra" commit is already in your local history (here ce660f1 = ada1f12, same SHA), option 2 is safe — you're just collapsing two heads of the same branch. If the remote has commits you don't have locally and they're worth keeping, fetch+rebase+push instead.

Pre-flight check before any force push:

git log --oneline --all --graph -10          # see the topology
git merge-base <local> <remote>              # common ancestor exists?

If merge-base exists and `<

Companion Fix: hermes-fleet auto_run.py git-push helper (P1 #9)

When the dispatched task ends with git push origin main, push can fail with SSL_ERROR_SYSCALL because mihomo (127.0.0.1:7897) caches TLS sessions inconsistently across GitHub repos in the same session. hermes-fleet commit 18b7919 / 87b1e0f adds:

~/.local/share/hermes-fleet/scripts/auto_run.py git-push --repo-dir ~/hermes-wiki

This unsets 8 proxy env vars + runs git -c http.proxy= -c https.proxy= push origin main. Tests: pytest ~/.local/share/hermes-fleet/scripts/tests/test_auto_run_git_push.py -v (5/5 pass).

If subagent's git push returns exit≠0 with SSL_ERROR_SYSCALL / Failed to connect to github.com, instruct it to retry via auto_run.py git-push rather than raw git push.

Pitfall: dispatcher plan.json MUST have role field per task — caught 2026-08-08 audit-self

When building a plan.json for dispatcher.py, every task requires role ∈ {general, implement, research, review, shell}. Default values don't auto-fill from engine — missing role → exit 2 immediately, no tasks run. Mapping:

• engine: "shell" → role: "shell"
• engine: "opencode" → role: "research" or "review"
• engine: "codex" → role: "implement"
• engine: "pi" → role: "research" or "general"

Always run --dry-run first to catch this in <1s before polluting <artifact_root>/<run_id>/tasks/<id>/ with half-written artifacts. Self-audit pattern that worked 2026-08-08:

python3 ~/.hermes/skills/queen-dispatch/scripts/dispatcher.py --plan plan.json --dry-run

Dry-run validates schema, prints argv, exits 0 — way cheaper than discovering the error after spinning up 4 subagents.

Pitfall: extracting opencode final answer from 100k+ char NDJSON stdout (2026-08-08 audit-self)

Opencode stdout is a stream of step_start / tool_use / step_finish events with the worker's actual answer nested inside the last type:"text" event's text field. Three problems:

1. The full file is 100k-180k chars — way over the 50KB stdout capture window.
2. cat shows the assistant tool calls (raw file dumps, grep results) drowning the answer.
3. The task_dir/summary.md only contains exit:0 / verify_status:passed — audit findings live in stdout.

Pattern that worked:

tail -200 ~/.hermes/artifacts/queen/<run>/tasks/<id>/stdout.log \
  | grep -oE '"type":"text"[^}]*"text":"[^"]+"' \
  | tail -1

Or python with progressive JSON parse for the very last text event. The user's audit findings are recoverable in ~2KB