* Run dashboard Terminal commands through PowerShell on Windows
subprocess.run(..., shell=True) uses cmd.exe on Windows by default,
which doesn't understand PowerShell syntax like $env:VAR or
$env:USERPROFILE - commands using it failed with 'cannot find the
file specified' since cmd took it as a literal filename. Invoke
powershell.exe explicitly on Windows instead; POSIX behavior is
unchanged.
* Replace command-runner Terminal with a real interactive PTY
The previous Terminal ran one command at a time via subprocess.run
and returned its output - it couldn't run interactive programs
(colors, live input, TUIs like gemini's chat/auth flow), which is
what a terminal actually needs to do.
Backend: new /ws/terminal WebSocket endpoint spawns a real shell
attached to a pseudo-terminal (stdlib pty on POSIX, pywinpty/ConPTY
on Windows) and streams raw I/O bidirectionally, with resize support.
Replaces the old POST /api/terminal/run and GET /api/terminal/session
endpoints entirely.
Frontend: terminal.js now loads xterm.js + the fit addon from CDN
and renders a real terminal emulator wired to the WebSocket, instead
of a scrollback div with a single input line.
Verified on this Linux sandbox via raw WebSocket tests: shell spawns
correctly, commands execute and echo real output, resize propagates
to the PTY (confirmed via ), and closing the connection
cleanly kills the shell process with no orphans (interactive bash
ignores SIGTERM by default, so cleanup uses SIGKILL). Could not
visually verify the xterm.js browser rendering in this sandbox since
its egress policy blocks the CDN (cdn.jsdelivr.net) outright - same
CDN this app already uses for chart.js, so expected to work on a
normal machine; please confirm on Windows.
* Remove demo/sample Kanban tasks
These were placeholder seed data shipped with the repo (a demo
'Fix login bug' task and a 'Test kanban task' with a canned
'Waiting for API review' block reason) - not real tasks. Clearing
them so the board starts empty.
* Add missing DELETE /api/kanban/tasks/{id} endpoint
The Kanban detail modal's Delete button called api.deleteKanbanTask(),
which didn't exist on the client, and there was no backend route for
it either - clicking Delete just threw 'api.deleteKanbanTask is not
a function'. Add both the client method and the backend endpoint.
* Bridge Hermes invocation through WSL when only installed there
The dashboard runs as a native Windows process, but Hermes' official
installer is Bash-only and typically only gets set up inside WSL -
a plain PATH lookup for 'hermes' on Windows will never find it there.
Add hermes_cli_args(), which checks the native PATH first (so Mac/
Linux/WSL-native setups are unaffected) and falls back to routing
through 'wsl -e bash -lc' (a login shell, so PATH additions like
uv's ~/.local/bin are sourced) only when hermes isn't found natively
but wsl.exe is available. Wire both the chat/dispatch invocation and
the agent-health check through it, replacing the plain shutil.which
check that always reported Hermes offline in this setup.
* Make Skills Hub context files editable and add skill creation
Two real gaps: the Skills Hub had no way to create a new skill (with
a SKILL.md) at all - the only 'Install' flow was the Plugin registry,
which just records a name in a JSON file, not an actual skill folder.
And the Context Files panel was read-only, just listing filenames
with no way to view, edit, add, or delete their contents.
Adds POST /api/skills (create, with SKILL.md content), PUT
/api/skills/{name} (edit SKILL.md), and GET/PUT/DELETE
/api/skills/{name}/context/{filename} for context files - all
validated through the same regex-allowlist + resolved-path
containment pattern already used for kanban tasks. Dashboard gets a
'+ New Skill' button, an editable SKILL.md view, and per-file
edit/delete plus 'Add File' in the Context Files panel.
* Verify native hermes is actually the right agent before trusting it
hermes_cli_args() previously trusted any 'hermes' found on native PATH
without checking what it actually was. Windows machines can have an
unrelated tool also named 'hermes' (softwarepub/HERMES, an academic
software-publication tool with harvest/process/curate/deposit
subcommands - confirmed to be what was actually on this machine's
PATH), which would silently get used instead of the real NousResearch
agent installed in WSL, producing the misleading 'Hermes needs setup'
message.
Now check that a native 'hermes' actually exposes the agent's 'chat'
subcommand before using it directly, falling back to the WSL bridge
otherwise.
---------
Co-authored-by: Claude <noreply@anthropic.com>
hermes_cli_args() previously trusted any 'hermes' found on native PATH
without checking what it actually was. Windows machines can have an
unrelated tool also named 'hermes' (softwarepub/HERMES, an academic
software-publication tool with harvest/process/curate/deposit
subcommands - confirmed to be what was actually on this machine's
PATH), which would silently get used instead of the real NousResearch
agent installed in WSL, producing the misleading 'Hermes needs setup'
message.
Now check that a native 'hermes' actually exposes the agent's 'chat'
subcommand before using it directly, falling back to the WSL bridge
otherwise.
Two real gaps: the Skills Hub had no way to create a new skill (with
a SKILL.md) at all - the only 'Install' flow was the Plugin registry,
which just records a name in a JSON file, not an actual skill folder.
And the Context Files panel was read-only, just listing filenames
with no way to view, edit, add, or delete their contents.
Adds POST /api/skills (create, with SKILL.md content), PUT
/api/skills/{name} (edit SKILL.md), and GET/PUT/DELETE
/api/skills/{name}/context/{filename} for context files - all
validated through the same regex-allowlist + resolved-path
containment pattern already used for kanban tasks. Dashboard gets a
'+ New Skill' button, an editable SKILL.md view, and per-file
edit/delete plus 'Add File' in the Context Files panel.
The dashboard runs as a native Windows process, but Hermes' official
installer is Bash-only and typically only gets set up inside WSL -
a plain PATH lookup for 'hermes' on Windows will never find it there.
Add hermes_cli_args(), which checks the native PATH first (so Mac/
Linux/WSL-native setups are unaffected) and falls back to routing
through 'wsl -e bash -lc' (a login shell, so PATH additions like
uv's ~/.local/bin are sourced) only when hermes isn't found natively
but wsl.exe is available. Wire both the chat/dispatch invocation and
the agent-health check through it, replacing the plain shutil.which
check that always reported Hermes offline in this setup.
The Kanban detail modal's Delete button called api.deleteKanbanTask(),
which didn't exist on the client, and there was no backend route for
it either - clicking Delete just threw 'api.deleteKanbanTask is not
a function'. Add both the client method and the backend endpoint.
These were placeholder seed data shipped with the repo (a demo
'Fix login bug' task and a 'Test kanban task' with a canned
'Waiting for API review' block reason) - not real tasks. Clearing
them so the board starts empty.
The previous Terminal ran one command at a time via subprocess.run
and returned its output - it couldn't run interactive programs
(colors, live input, TUIs like gemini's chat/auth flow), which is
what a terminal actually needs to do.
Backend: new /ws/terminal WebSocket endpoint spawns a real shell
attached to a pseudo-terminal (stdlib pty on POSIX, pywinpty/ConPTY
on Windows) and streams raw I/O bidirectionally, with resize support.
Replaces the old POST /api/terminal/run and GET /api/terminal/session
endpoints entirely.
Frontend: terminal.js now loads xterm.js + the fit addon from CDN
and renders a real terminal emulator wired to the WebSocket, instead
of a scrollback div with a single input line.
Verified on this Linux sandbox via raw WebSocket tests: shell spawns
correctly, commands execute and echo real output, resize propagates
to the PTY (confirmed via ), and closing the connection
cleanly kills the shell process with no orphans (interactive bash
ignores SIGTERM by default, so cleanup uses SIGKILL). Could not
visually verify the xterm.js browser rendering in this sandbox since
its egress policy blocks the CDN (cdn.jsdelivr.net) outright - same
CDN this app already uses for chart.js, so expected to work on a
normal machine; please confirm on Windows.
subprocess.run(..., shell=True) uses cmd.exe on Windows by default,
which doesn't understand PowerShell syntax like $env:VAR or
$env:USERPROFILE - commands using it failed with 'cannot find the
file specified' since cmd took it as a literal filename. Invoke
powershell.exe explicitly on Windows instead; POSIX behavior is
unchanged.
The regex allow-list alone wasn't enough for CodeQL's path-injection
sanitizer recognition. Resolve the candidate path and verify it's
still a direct child of the resolved kanban directory before
returning it, which is the pattern CodeQL's py/path-injection query
recognizes as clearing taint.
CodeQL flagged path-traversal risk (uncontrolled data used in path
expression) across the kanban endpoints: task_id/parent_id/child_id
path parameters were spliced directly into KANBAN_DIR paths with no
validation. Task ids are always server-generated 8-char hex strings,
so add kanban_task_path() which validates against that shape and
raises 400 otherwise, and route every kanban file path through it.
Assigning a task to opencode, hermes, or gemini now actually runs it:
creating or PATCHing a task with one of those assignees moves it to
in_progress and hands the title+body to execute_agent() in a
background thread. On completion the agent's response is appended as
a task comment and the task is marked done (success) or blocked
(timeout/error), matching the existing block/complete state machine.
Adds POST /api/kanban/tasks/{id}/dispatch for manual dispatch/retry,
and makes the previously-stubbed POST /api/kanban/dispatch actually
scan todo/ready tasks with an agent assignee and dispatch each one.
Dashboard: the assignee field is now a select of the three agents,
the task detail modal shows an activity log of past agent runs and a
Dispatch button, and polls every 3s while a task is in_progress. Also
fixed a pre-existing bug where the detail modal read a nonexistent
kanbanData.tasks field (the board API only returns columns), so
clicking a card silently did nothing before this fix.
Adds a real shell terminal to the dashboard sidebar: POST
/api/terminal/run executes a command via subprocess in a
server-tracked working directory (with cd support), and GET
/api/terminal/session returns the current cwd. The frontend renders
a scrollback panel with command history (up/down arrows) styled to
match the existing chat UI.
Local-only power feature: it executes arbitrary shell commands, same
trust model as the existing agent CLIs the dashboard already shells
out to.
- install.ps1: wrap desktop shortcut creation in try/catch so a COM
failure doesn't abort the whole installer (ErrorActionPreference=Stop)
- start.ps1: coerce dashboard.port to int on the Python side so a float
value in settings.json doesn't crash the [int] cast
- start.sh: fail loudly with a clear error if no free port is found in
20 attempts, instead of silently launching on an unverified port
start.ps1/start.sh now fall back to the next free port instead of
crashing when the configured port is already taken (e.g. by another
local app), and auto-open the dashboard in the browser once it's up.
install.ps1 also creates a desktop shortcut (Launch-Dashboard.bat) so
the dashboard can be started without typing any commands.
New features:
- Kanban Board: Visual task management with drag-and-drop, filter, priority, block/unblock
- Goals: Project targets with progress tracking, auto-sync to brain/active-projects.md
- Journal: Daily entries stored as brain/journal/YYYY-MM-DD.md with search
- Agent Health: Real-time monitoring of 3 agents (opencode/hermes/gemini)
- Smart Router: Keyword-based task routing with confidence scoring
- Learning Analytics: Skill evaluation scores and performance trends
- Session Replay: Browse and replay past opencode sessions
Technical changes:
- 30 new API endpoints across all 7 features
- api.patch() method added for PATCH support
- UI modernization: glass morphism cards, gradients, glow effects, skeleton loaders, empty states
- New CSS section (v0.2.0) with kanban board, goal cards, journal entries, agent health cards, smart router suggestions, chart cards, session messages
- 7 new sidebar nav items under Workflow and Monitoring sections
- All changes are additive (zero breaking changes to existing 13 pages / 28 endpoints)
- Full smoke test verified: every endpoint returns correct data
zumayaaustin
devin-ai-integration[bot]
Claude
modimihir07