routine-taskboard
A sidebar-mounted routine board for the DSH Web GUI: every long-lived
scheduled job (Windows 计划任务 / KAi cron) renders as one row — schedule,
carrier, dependency scripts (numbered steps, clickable, individually
runnable), typed input/output artifacts, and a health lamp.
Fully self-contained since v0.1.9. The board is driven by the plugin's
own fixture registry — it does not depend on the official dsh-taskboard
plugin or its /dsh-taskboard/state API. All machine-specific mappings live
in a user config file outside the package, so upgrades never clobber them.
Install
dsh plugin --profile web add routine-taskboard
Restart dsh web. A 例行看板 entry appears in the sidebar; clicking it
toggles the board inside the conversation column (mutually exclusive with the
other dsh board panels).
What you get
- Board view — 计划名称 / 时间 / 载体 / 依赖脚本 / 输入文件 / 输出文件,
fed by the plugin's own
GET /routine-taskboard/fixtures registry.
- Row actions — ▶ 启动 (
schtasks /Run), ⏸ 停用 (/DISABLE),
↻ 重新上线 (/ENABLE) for Windows-scheduled carriers. Buttons adapt to
state: a disabled task only shows 重新上线; an active one shows 启动+停用.
- Script steps — multi-script jobs render as numbered steps (
1. 2. 3.);
each step is clickable (reveal in Explorer) and has its own ▶ to run just
that script (interpreter picked by extension: py/ps1/bat/vbs/mjs/js).
- Health lamps & badges — three states: 运行中 (green) / 已停用 (amber) /
异常 (red), with a text badge next to the plan name.
Fixture registry (the board's own data)
The board renders from $DSH_HOME/storages/routine-taskboard.json — an array
of placards (id / name / time / carrier / taskName / scripts / input / output / healthKey / status). Ships empty; register cards via the host API or seed the
file directly. It is fully independent of any other plugin.
User configuration (optional, recommended)
Machine-specific paths and curated mappings are not shipped. Create:
$DSH_HOME/storages/routine-taskboard.config.json
{
"pipelineFile": "D:/data/pipeline_status.json",
"scriptBases": [["^ops-automation[\\\\/", "D:\\work\\ops-automation\\"], ["^douyin_update\\.py$", "D:\\work\\douyin\\douyin_update.py"]],
"ioMap": { "douyin-update": { "input": "D:\\data\\门店记录表.xlsx", "output": "D:\\data\\维表.xlsx" } },
"ioByTitle": [{ "match": "临时区清理", "input": "D:\\work\\temp", "output": "" }],
"scriptMap": { "daily-report": [{ "label": "run.bat", "path": "D:\\work\\daily-report\\run.bat" }] },
"scriptByTitle": [{ "match": "会话守护", "scripts": [{ "label": "guard.ps1", "path": "D:\\x\\guard.ps1" }] }],
"pathHints": { "依赖文档": "D:\\data\\依赖文档\\" }
}
pipelineFile — business health ledger ({tasks:{key:{status,note}}});
RTB_PIPELINE_FILE env is the fallback.scriptBases — [regexSource, absoluteBase] pairs turning relative script
tokens from card descriptions into absolute paths.ioMap / ioByTitle — curated input/output overrides keyed by health key
or title substring (they beat regex extraction).scriptMap / scriptByTitle — curated script-step lists for cards whose
descriptions undersell the real pipeline.pathHints — folder bases used to complete relative artifact names.
Absent file = fully generic behavior (regex extraction only). The file is
read at plugin start and served to the client via GET /routine-taskboard/config.
Routes (host)
| Route | Method | Purpose |
|---|
/routine-taskboard/fixtures | GET | the board's own fixture registry |
/routine-taskboard/pipeline | GET | pipeline ledger contents |
/routine-taskboard/config | GET | user config for the client |
/routine-taskboard/open | POST | reveal a path in Explorer |
/routine-taskboard/run | POST | schtasks /Run |
/routine-taskboard/state | POST | `schtasks /Change /DISABLE |
/routine-taskboard/run-script | POST | run one script detached |
Development & contributing
Anyone can pick this up. Source of truth:
git clone https://github.com/Amoss-1/routine-taskboard.git
cd routine-taskboard
Layout
lib/index.js # host: routes + fixture registry + config loading (node)
lib/client.js # web client: board UI, sidebar entry, actions (browser)
cordis.patch.yml # bundle patch: registers the plugin row in a profile
README.md, LICENSE, package.json
How the host mounts
lib/index.js exports name, inject, and apply(ctx). Route registration
lives under the workspace/agent/web chain — mirror the official pattern:
ctx.inject(['workspaceRegistry'], (wsCtx) => {
wsCtx.inject(['agents'], (agentCtx) => {
agentCtx.inject(['webServer'], (webCtx) => {
webCtx.webServer.register({ kind: 'prefix', path: '/routine-taskboard', handler })
})
})
})
webServer is not available at the top level of a normal plugin's ctx.
Local iteration
- Edit
lib/*.js; syntax-check: node --check lib/index.js && node --check lib/client.js.
- Host changes: copy into the profile and restart
dsh web.
- Client changes: the browser hard-refresh (Ctrl+Shift+R) is enough.
- The start script only force-restarts when a profile
package.json/lock
file changed; after manual host edits, touch cordis.patch.yml (mtime) or
use a forced restart.
Release
- Bump
version in package.json.
npm publish (verify the tarball contains lib/index.js + lib/client.js
— a broken package missing lib/ was once published; check npm pack --dry-run).- Push the same files to the GitHub repo (
Amoss-1/routine-taskboard).
- Users update through the plugin market; upgrades never touch
$DSH_HOME/storages/routine-taskboard.config.json or the fixture registry.
Contributing
Contributions are welcome — bug reports, UI polish, docs, and features.
See CONTRIBUTING.md for the full guide (setup, issue/PR
flow, conventions, release checklist). The repo is
https://github.com/Amoss-1/routine-taskboard; MIT licensed.
License
MIT © Amoss-1
