Kanban Worker Context Pollution Bug Report

Summary

Kanban workers fail to execute tasks due to context pollution from the dispatcher's session. Workers inherit the full conversation history of the parent session, causing them to ignore the task and exit prematurely without calling any kanban tools.

Priority

High - This is a bug fix (Priority #1 in CONTRIBUTING.md). Kanban is currently unusable for task execution.

Environment

• Hermes Version: Latest (as of 2026-05-16)
• Platform: Linux (Ubuntu)
• Python: 3.x
• Model: Claude Sonnet 4.5 (via custom provider)

Steps to Reproduce

1. Start a Hermes session with some conversation history (e.g., discussing recipes, Obsidian, etc.)
2. Create a simple Kanban task:

   hermes kanban create "测试任务：统计家常菜菜单里有多少道菜，按分类列出数量" --assignee default

3. Dispatch the task:

   hermes kanban dispatch --max 1

4. Check the task status:

   hermes kanban show <task_id>

Expected Behavior

The worker should:

1. Call kanban_show() to orient itself (per KANBAN_GUIDANCE step 1)
2. Read the菜单 file
3. Count dishes by category
4. Call kanban_complete() with results

Actual Behavior

The worker:

1. Says "我来查看任务详情" (I'll check the task details)
2. Does not call any tools (no kanban_show(), no read_file(), nothing)
3. Exits immediately (duration: 4-5 seconds)
4. Crashes with "pid not alive"
5. Retries once, crashes again
6. Gets auto-blocked after 2 consecutive crashes

Root Cause Analysis

Code Location

hermes_cli/kanban_db.py, lines 3931-4006:

prompt = f"work kanban task {task.id}"
# ...
cmd = [
    *_resolve_hermes_argv(),
    "-p", profile_arg,
    "--skills", "kanban-worker",
    # ... per-task skills ...
    "chat",
    "-q", prompt,  # ← THE PROBLEM
]

The Problem

1. Worker uses chat command: The dispatcher spawns workers with hermes chat -q "work kanban task <id>"
2. Context inheritance: The chat command inherits the full conversation history from the dispatcher's session
3. Context pollution: When the dispatcher is running inside an active Hermes session (e.g., via Gateway/Telegram), the worker sees:
   • All previous user messages
   • All previous assistant responses
   • Context compaction summaries
   • Unrelated work (菜谱, Obsidian, etc.)
4. Agent confusion: The worker agent sees this massive context, gets confused, and:
   • Responds with a vague acknowledgment ("我来查看任务详情")
   • Never calls any tools
   • Exits without completing the lifecycle

Evidence

From hermes kanban log <task_id>:

Query: work kanban task t_7e404f63
Initializing agent...
────────────────────────────────────────

╭─ ⚕ Hermes ───────────────────────────────────────────────────────────────────╮
    我来查看任务详情。
╰──────────────────────────────────────────────────────────────────────────────╯

Session:        20260516_113400_a0b7fa
Duration:       5s
Messages:       2 (1 user, 0 tool calls)  ← NO TOOL CALLS!

The session export shows the worker received:

• The task prompt: "work kanban task t_7e404f63"
• Plus context compaction summaries from the parent session
• Plus unrelated conversation history (菜谱, Obsidian, daily reports, etc.)

Impact

• Kanban is completely broken for task execution
• Workers crash 100% of the time when dispatched from an active session
• Auto-retry mechanism exhausts attempts without progress
• Tasks get auto-blocked as "crashed 2x"

Proposed Solutions

Option 1: Use a Clean Session (Recommended)

Modify kanban_db.py to spawn workers in a new, isolated session:

cmd = [
    *_resolve_hermes_argv(),
    "-p", profile_arg,
    "--skills", "kanban-worker",
    # ... per-task skills ...
    "chat",
    # Remove "-q" flag to avoid inheriting context
    # Or add a new flag like "--new-session" to force clean context
]

Then pass the prompt via stdin or as a system message, not as a continuation of an existing conversation.

Option 2: Add Context Isolation Flag

Add a new CLI flag --isolated or --no-context that:

• Starts a fresh session
• Ignores any parent session context
• Only loads the specified skills and system prompt

cmd = [
    *_resolve_hermes_argv(),
    "-p", profile_arg,
    "--skills", "kanban-worker",
    "--isolated",  # ← NEW FLAG
    "chat",
    "-q", prompt,
]

Option 3: Strengthen KANBAN_GUIDANCE

Add explicit instructions at the top of KANBAN_GUIDANCE to override context pollution:

KANBAN_GUIDANCE = (
    "# CRITICAL: You are a Kanban worker. Ignore all previous conversation history.\n"
    "# Your ONLY task is defined by $HERMES_KANBAN_TASK. Start fresh.\n"
    "\n"
    "# Kanban task execution protocol\n"
    # ... rest of guidance ...
)

This is a workaround, not a real fix, but might help until proper session isolation is implemented.

Additional Context

KANBAN_GUIDANCE Lifecycle

The system prompt (agent/prompt_builder.py, line 188) defines a clear 6-step lifecycle:

1. Orient - Call kanban_show() first
2. Work - Execute in workspace
3. Heartbeat - Report progress
4. Block - Stop on ambiguity
5. Complete - Call kanban_complete()
6. Create - Spawn child tasks if needed

Workers are not following this lifecycle due to context pollution.

Related Skills

• skills/devops/kanban-worker/SKILL.md - Loaded automatically
• skills/devops/kanban-orchestrator/SKILL.md - For decomposition tasks

Both skills assume workers start in a clean context and follow the lifecycle.

Workaround for Users

Until this is fixed, users should:

1. Avoid using Kanban from active sessions
2. Use delegate_task instead for parallel work
3. Or manually execute tasks directly

Testing Recommendations

After fixing, test with:

1. Simple task from clean CLI session
2. Simple task from Gateway (Telegram/Discord)
3. Task with long conversation history in parent session
4. Nested tasks (orchestrator → workers)
5. Retry after block/crash

Verify workers:

• Call kanban_show() first
• Execute the actual work
• Call kanban_complete() or kanban_block()
• Never exit without calling a kanban tool

References

• hermes_cli/kanban_db.py - Worker spawn logic
• agent/prompt_builder.py - KANBAN_GUIDANCE definition
• skills/devops/kanban-worker/SKILL.md - Worker skill
• run_agent.py - Agent conversation loop

Reporter: User "柒" via Hermes Agent (Telegram)
Date: 2026-05-16
Session: Multiple test runs with task t_7e404f63