Summary
In dispatched worker contexts, explicit kanban board overrides do not work.
Examples that should target another board:
- tool call:
kanban_show(board="bryceos", task_id="...")
- tool call:
kanban_list(board="bryceos")
- CLI:
hermes kanban --board bryceos show <task_id>
All of them still hit the worker's pinned DB when HERMES_KANBAN_DB is set.
Repro
Worker env contains:
HERMES_KANBAN_BOARD=mordecai-v2
HERMES_KANBAN_DB=/home/.../.hermes/kanban/boards/mordecai-v2/kanban.db
Inside that env:
from hermes_cli import kanban_db as kb
print(kb.kanban_db_path(board="bryceos"))
print(kb.kanban_db_path(board="mordecai-v2"))
Observed: both resolve to the same mordecai-v2 DB path.
Tool reproduction:
from tools import kanban_tools
print(kanban_tools._handle_show({"board": "bryceos", "task_id": "<bryceos-task-id>"}))
Observed:
{"error": "task <bryceos-task-id> not found"}
But outside the worker env, raw CLI works:
env -u HERMES_KANBAN_DB -u HERMES_KANBAN_BOARD -u HERMES_KANBAN_WORKSPACES_ROOT \
hermes kanban --board bryceos show <bryceos-task-id> --json
That returns the correct bryceos task.
Root cause
tools/kanban_tools.py passes board correctly into kb.connect(board=board), but hermes_cli/kanban_db.py::kanban_db_path() does this:
override = os.environ.get("HERMES_KANBAN_DB", "").strip()
if override:
return Path(override).expanduser()
So the explicit board argument is ignored whenever the worker env pins HERMES_KANBAN_DB.
There is also a test codifying this behavior:
assert kb.kanban_db_path(board="ignored") == forced
Why this is a problem
The tool/docs currently imply that explicit board can override the env-pinned active board for one call. That is not true in dispatched worker envs, which is exactly where cross-board diagnostics get attempted.
Suggested fixes
Option A:
- Make explicit
board / --board outrank HERMES_KANBAN_DB.
- Add regression tests for worker envs with DB pins.
Option B:
- Keep DB pin precedence, but reject explicit board overrides loudly when
HERMES_KANBAN_DB is set.
- Remove or narrow docs that currently promise per-call board override in those contexts.
Extra note
This affects both tool calls and raw CLI launched from inside the worker shell, because both share the same env pins.
Summary
In dispatched worker contexts, explicit kanban board overrides do not work.
Examples that should target another board:
kanban_show(board="bryceos", task_id="...")kanban_list(board="bryceos")hermes kanban --board bryceos show <task_id>All of them still hit the worker's pinned DB when
HERMES_KANBAN_DBis set.Repro
Worker env contains:
Inside that env:
Observed: both resolve to the same mordecai-v2 DB path.
Tool reproduction:
Observed:
{"error": "task <bryceos-task-id> not found"}But outside the worker env, raw CLI works:
That returns the correct bryceos task.
Root cause
tools/kanban_tools.pypassesboardcorrectly intokb.connect(board=board), buthermes_cli/kanban_db.py::kanban_db_path()does this:So the explicit
boardargument is ignored whenever the worker env pinsHERMES_KANBAN_DB.There is also a test codifying this behavior:
Why this is a problem
The tool/docs currently imply that explicit
boardcan override the env-pinned active board for one call. That is not true in dispatched worker envs, which is exactly where cross-board diagnostics get attempted.Suggested fixes
Option A:
board/--boardoutrankHERMES_KANBAN_DB.Option B:
HERMES_KANBAN_DBis set.Extra note
This affects both tool calls and raw CLI launched from inside the worker shell, because both share the same env pins.