kanban: materialize a named board's workspaces root when the board is created

[iammichaelhype]

Summary

hermes kanban boards create <slug> creates the named board metadata and kanban.db, but does not materialize the board's canonical workspaces/ directory. The directory is only created lazily by scratch-workspace resolution.

That leaves a valid named board in a state where the worker dispatcher exports HERMES_KANBAN_WORKSPACES_ROOT=<kanban-home>/boards/<slug>/workspaces, but the exported directory does not exist when the task uses an explicit dir workspace. Consumers that correctly require this exported root to exist then fail before worker startup.

I reproduced this with official Hermes 0.18.2 at 4281151ae859241351ba14d8c7682dc67ff4c126 and confirmed the relevant behavior is still present on current main at af250d84948179834820a62bfd870c0df6f264a1.

Reproduction

export HERMES_KANBAN_HOME="$(mktemp -d)"
hermes kanban boards create workspace-root-repro --name "Workspace Root Repro"

test -f "$HERMES_KANBAN_HOME/boards/workspace-root-repro/board.json"
test -f "$HERMES_KANBAN_HOME/boards/workspace-root-repro/kanban.db"
test -d "$HERMES_KANBAN_HOME/boards/workspace-root-repro/workspaces"

The first two checks pass; the final check fails. A later worker lane may still export that absent final path.

Expected behavior

Creating a named board should also materialize its canonical workspaces/ root safely and idempotently, or the supported dispatcher should materialize and validate it before exporting it to a worker.

Suggested invariants:

• create only the final workspaces leaf under the already-selected physical board directory;
• use an owner-only mode such as 0700;
• accept an existing physical directory only when its owner and mode are safe;
• reject symlinks, wrong file kinds, unsafe ownership/mode, and ambiguous replacement;
• keep creation idempotent under repeated or concurrent board creation;
• add a regression test covering named-board creation followed by an explicit dir workspace task, not only scratch-workspace resolution.

This report is an upstream behavior note only; I have not changed or forked Hermes source locally.

[GottZ]

This was generated by AI during triage.

Summary

One PR addresses #63863 by eagerly creating a named board’s canonical workspaces/ directory during board creation and metadata writes. The diff establishes eager materialization, but it does not demonstrate or test the reported explicit-dir consumer failure and does not make the invariant reliable when creation errors occur.

Related pull requests

• fix(kanban): materialize board workspaces/ root on create_board #63882 best fix — (+38/-0) — partial fix: The diff adds _ensure_board_workspaces_root() and invokes it for non-default boards, but silently swallows most OSErrors, leaves existing-directory ownership and mode unvalidated, and contains none of the regression coverage claimed in the PR body. Consistent with the contributor keep_open review on fix(kanban): materialize board workspaces/ root on create_board #63882, current main already resolves explicit-dir workspaces independently, so the PR still needs a failing consumer test or an explicit re-scope to an eager-materialization invariant before merge.

Suggested consolidation

Do not merge yet; consolidate the fix on #63882 because it is the only PR and the verify-selected best fix. Keep #63882 open until it addresses the contributor review by adding diff-visible regression coverage for the actual failing consumer or re-scoping the change, and by making the promised materialization and owner-only mode behavior enforceable rather than best-effort; there are no duplicate PRs to close.

Complex graph

flowchart LR
    classDef open fill:#dbeafe,stroke:#1d4ed8,color:#1e3a8a
    classDef merged fill:#dcfce7,stroke:#15803d,color:#14532d
    classDef closed fill:#e5e7eb,stroke:#6b7280,color:#1f2937
    classDef unverified fill:#f3f4f6,stroke:#9ca3af,color:#374151
    classDef best stroke-width:3px,stroke:#b45309
    classDef target stroke-width:3px,stroke:#4338ca
    I63863(["issue #63863 (open)"])
    P63882["PR #63882 (open)"]
    P63882 -->|best fix| I63863
    class I63863 open
    class I63863 target
    class P63882 open
    class P63882 best
    click I63863 "https://github.com/NousResearch/hermes-agent/issues/63863"
    click P63882 "https://github.com/NousResearch/hermes-agent/pull/63882"

Loading

Graph: solid arrow = fixes / best fix, dashed arrow = partial or unverified (see edge label); boxed group = PRs duplicating each other; amber border = best fix; indigo border = target; gray node = closed or no verify verdict yet (state tag in the node label).

Cross-PR triage: Reviewed 1 pull request and 1 issue in this complex. Each diff was read against this issue; Assessment working set: 2 kB of PR diffs, 4 kB of issue/PR text, 2 kB of discussion (2 comments), 2 verify verdicts. verdicts reflect diff content, not PR titles. Part of an automated triage batch.