input-kanban 0.0.9 → 0.0.12

package/ENVIRONMENT.md

@@ -8,16 +8,18 @@ CLI options take precedence over environment variables. Environment variables ta
 
 - `PORT`: HTTP server port. Default: `8787`. CLI option: `--port`.
 - `HOST`: HTTP bind host. Default: `127.0.0.1`. CLI option: `--host`.
-- `KANBAN_DEFAULT_REPO`: Default target repository path for new runs. Default: the current working directory when `input-kanban` is launched. CLI option: `--repo`. Creating a run validates that this path is inside a Git work tree.
+- `KANBAN_DEFAULT_WORKSPACE`: Default workspace path for new runs. Default: the current working directory when `input-kanban` is launched. CLI option: `--workspace`. `KANBAN_DEFAULT_REPO` remains as a compatibility alias. Creating a run only requires this path to exist and be a directory; Git is detected and marked when available.
 - `KANBAN_RUNS_DIR`: Directory for run state, logs, and artifacts. Default: `.input-kanban/runs` under the user's home directory. CLI option: `--runs-dir`.
 - `KANBAN_CODEX_BIN`: Codex CLI executable name or path. Default: `codex`. CLI option: `--codex-bin`.
 - `KANBAN_RUNNER`: Runner mode. Supported values: `headless`, `tmux`. Default: `headless`. CLI option: `--runner`.
+- `KANBAN_AUTO_POLL_MS`: Poll interval for the Web server background scheduler. Default: `3000`.
+- `KANBAN_AUTO_MAX_RETRIES`: Maximum automatic retries for recoverable failed/unknown tasks in the scheduler. Default: `1`.
 
 ## Environment Example
 
 ```bash
 PORT=8787 \
-KANBAN_DEFAULT_REPO=/path/to/child-repo \
+KANBAN_DEFAULT_WORKSPACE=/path/to/workspace \
 KANBAN_RUNS_DIR=/path/to/kanban-runs \
 KANBAN_CODEX_BIN=codex \
 KANBAN_RUNNER=headless \
@@ -29,7 +31,7 @@ input-kanban
 ```bash
 input-kanban \
   --port 8787 \
-  --repo /path/to/child-repo \
+  --workspace /path/to/workspace \
   --runs-dir /path/to/kanban-runs \
   --codex-bin codex \
   --runner headless
@@ -37,9 +39,11 @@ input-kanban \
 
 ## Notes
 
-- `KANBAN_DEFAULT_REPO` / `--repo` should point to the actual git repository where work should run.
+- `KANBAN_DEFAULT_WORKSPACE` / `--workspace` should point to the local directory where work should run; `KANBAN_DEFAULT_REPO` / `--repo` remain compatibility aliases.
+- `input-kanban serve` starts a lightweight background scheduler that uses the same orchestrator auto-advance path as CLI `submit --auto` / `input-kanban auto <runId>`. It advances planned runs, serial batches, final judge startup, and bounded automatic retries without relying on an open browser tab.
 - `KANBAN_RUNNER` / `--runner tmux` runs Codex tasks inside tmux windows while keeping scheduling and status tracking in the Node.js orchestrator.
 - `KANBAN_RUNNER=tmux` is optional. Use it when you want live terminal visibility into planner, worker, and final judge sessions.
+- With `KANBAN_RUNNER=tmux`, stopping and restarting `input-kanban serve` does not interrupt already-running Codex sessions; tmux keeps them alive and the scheduler resumes after restart. Do not assume the same safety for `headless` runner child processes.
 - tmux mode uses one session per run and one window for planner, each batch, and judge. Batch windows contain an overview pane plus worker panes.
 - tmux role windows stay open after the Codex command exits. The runner writes `exit_code` before entering the keep-open shell so Node.js status refresh can continue to advance from filesystem state.
 - The dashboard exposes the run-level `tmux attach-session` copy action after tmux metadata is available. File viewer panels do not repeat tmux terminal details.

package/PROJECT_GUIDE.md

@@ -33,9 +33,9 @@ The intended use case is:
 
 ## Important Boundaries
 
-- If the current workspace is a multi-repo umbrella, the target repo must be a concrete child repository, not the umbrella root.
-- Workers can modify the target repository. Failed workers are not automatically retried because a partial modification may already exist.
-- The planner only creates a plan and does not modify the target repo. Planner failures, invalid output, and empty plans can be safely retried before any worker or judge starts.
+- If the current workspace is a multi-repo umbrella, the target workspace must be a concrete child directory, not the umbrella root.
+- Workers can modify the target workspace. Failed workers are not automatically retried because a partial modification may already exist.
+- The planner only creates a plan and does not modify the target workspace. Planner failures, invalid output, and empty plans can be safely retried before any worker or judge starts.
 - Local process state, `exit_code`, logs, and artifacts are the source of truth. Codex App Server session lookup is auxiliary.
 - tmux mode changes terminal visibility only. Node.js still owns scheduling, batch barriers, `maxParallel`, stop/archive, `judge_input.json`, and status refresh from `exit_code` plus artifacts.
 - tmux windows stay open after command completion for human inspection, but `exit_code` is written before the keep-open shell starts so state can advance without closing the window.
@@ -58,6 +58,7 @@ Supported serve options:
 ```text
 --host <host>
 --port <port>
+--workspace <path>
 --repo <path>
 --runs-dir <path>
 --codex-bin <path>
@@ -113,6 +114,7 @@ Supported stop options:
 Supported submit options:
 
 ```text
+--workspace <path>
 --repo <path>
 --label <label>
 --task <text>
@@ -128,11 +130,11 @@ Supported submit options:
 --poll-ms <ms>
 ```
 
-`input-kanban submit` creates a run and starts the planner. Task content can come from `--task <text>` or `--task-file <path|->`; omitting `--repo` uses the current working directory as the target Git work tree. Omitting `--label` derives the run label from the first non-empty task line. Auto mode is the default for submit: it keeps polling the run, dispatches batches when the plan is ready, and starts the final judge once all batches complete. `--no-auto` keeps submit to create + plan only. `-d` / `--detach` starts a background supervisor process for the auto loop and lets the submitting terminal return immediately. The submit output includes `input-kanban status <runId> --watch` for terminal-side observation. Because it writes to the same runs directory as the Web server, CLI-created runs are visible in the 8787 dashboard when both processes use the same `--runs-dir`.
+`input-kanban submit` creates a run and starts the planner. Task content can come from `--task <text>` or `--task-file <path|->`; omitting `--workspace` uses the current working directory as the target workspace, and `--repo` remains a compatibility alias. Omitting `--label` derives the run label from the first non-empty task line. Auto mode is the default for submit: it keeps polling the run through the shared orchestrator auto-advance path, dispatches batches when the plan is ready, and starts the final judge once all batches complete. `--no-auto` keeps submit to create + plan only. `-d` / `--detach` starts a background supervisor process for the same auto loop and lets the submitting terminal return immediately. The Web server also starts a lightweight scheduler that uses this shared path, so serial batch advancement does not depend on an open browser tab. The submit output includes `input-kanban status <runId> --watch` for terminal-side observation. Because it writes to the same runs directory as the Web server, CLI-created runs are visible in the 8787 dashboard when both processes use the same `--runs-dir`.
 
 Default behavior:
 
-- default repo: current working directory when `input-kanban` is launched; run creation validates that the selected repo is inside a Git work tree;
+- default workspace: current working directory when `input-kanban` is launched; run creation only validates that the selected directory exists and is a directory; Git is detected and labeled when available;
 - default host: `127.0.0.1`;
 - default port: `8787`;
 - default runs directory: `~/.input-kanban/runs`;
@@ -308,7 +310,7 @@ Risk notes:
 
 - A stale-lock timeout that is too short can accidentally steal a lock from a slow or paused process; too long slows recovery.
 - `child.onExit` callbacks must continue to take the write lock.
-- If the repository ever moves to shared network storage, the current single-machine exclusive-file assumptions should be re-evaluated.
+- If the workspace ever moves to shared network storage, the current single-machine exclusive-file assumptions should be re-evaluated.
 
 ## Stop and Archive
 
@@ -500,13 +502,13 @@ change. Record the exact commands, run ids, and artifact paths in the release
 notes or handoff.
 
 1. Headless runner:
-   - Start the app with `input-kanban --runner headless --runs-dir <tmp-runs-dir> --repo <target-repo> --port <free-port>`.
+   - Start the app with `input-kanban --runner headless --runs-dir <tmp-runs-dir> --workspace <target-workspace> --port <free-port>`.
    - Create a small run, plan it, dispatch at least one worker, and run the final judge if the plan requires it.
    - Verify the run state reports `runner: headless`, no task exposes `tmux` metadata, and role directories contain the expected `prompt.md`, `events.jsonl`, `events_timed.jsonl`, `stderr.log`, `last_message.md`, and `exit_code` files.
    - Stop the run and verify no unrelated local process is affected.
 
 2. tmux runner, only when `tmux -V` succeeds:
-   - Start the app with `input-kanban --runner tmux --runs-dir <tmp-runs-dir> --repo <target-repo> --port <free-port>`.
+   - Start the app with `input-kanban --runner tmux --runs-dir <tmp-runs-dir> --workspace <target-workspace> --port <free-port>`.
    - Create a small run and click Plan. Verify a session named `input-kanban-<runId>` exists and has a planner window.
    - Dispatch workers. Verify each batch gets its own window with an overview pane plus worker panes, and each role directory writes `run.sh` and `tmux.json` with the expected `sessionName`, `windowName`, `target`, and `attachCommand`.
    - Verify `run.sh` writes `exit_code` before printing the keep-open summary, then keeps the window open for manual inspection.
@@ -527,7 +529,7 @@ Keep a single repository-level `RELEASE_NOTES.md` with recent version history. D
 ## Change Guidelines
 
 - Do not add automatic worker retry unless there is a verified rollback or idempotency mechanism.
-- Do not default to `--skip-git-repo-check`; prefer a concrete target child repository.
+- Do not default to bypassing workspace validation; prefer a concrete target child workspace.
 - Preserve batch barriers when modifying scheduling logic.
 - Decide clearly between soft archive and physical directory archive before changing archive semantics.
 - Keep the frontend buildless unless there is a strong reason to introduce a build pipeline.

package/README.en.md

@@ -2,7 +2,7 @@
 
 [中文](README.md) | English
 
-Input Kanban is a local Codex orchestration dashboard. The recommended path is to install it from npm, run `input-kanban` inside the target repository, and use the browser UI to manage planning, worker execution, and final judging.
+Input Kanban is a local Codex orchestration dashboard. The recommended path is to install it from npm, run `input-kanban` inside the target workspace, and use the browser UI to manage planning, worker execution, and final judging. If the workspace is a Git repository, the UI marks it as such.
 
 ## Recommended Usage
 
@@ -18,12 +18,12 @@ Verify the installation:
 input-kanban --help
 ```
 
-### 2. Start in the Target Repository
+### 2. Start in the Target Workspace
 
-Enter the repository you want Codex to modify or inspect:
+Enter the workspace you want Codex to modify or inspect:
 
 ```bash
-cd /path/to/your/repo
+cd /path/to/your/workspace
 input-kanban
 ```
 
@@ -35,14 +35,16 @@ http://127.0.0.1:8787
 
 Open that URL in your browser to use the dashboard.
 
-### 3. Start with an Explicit Repository
+### 3. Start with an Explicit Workspace
 
-If you do not want to `cd` into the target repository first, pass it explicitly:
+If you do not want to `cd` into the target workspace first, pass it explicitly:
 
 ```bash
-input-kanban --repo /path/to/your/repo
+input-kanban --workspace /path/to/your/workspace
 ```
 
+`--repo` remains available as a compatibility alias.
+
 ## CLI Auto Execution
 
 To submit a task from the terminal and let it advance automatically, use `submit`. Task content supports two input modes:
@@ -52,7 +54,9 @@ input-kanban submit --task-file task.md --label "Fix login issue"
 input-kanban submit --task "Fix the login issue and add regression tests" --label "Fix login issue"
 ```
 
-`submit` creates a run, starts planning, dispatches all batches, and starts the final judge after all workers finish by default. The default repo is the current directory. If `--label` is omitted, the run label is generated from the task text. It uses the same runs directory, so CLI-created runs are visible in the Web dashboard on port 8787 as long as the dashboard uses the same `--runs-dir`.
+`submit` creates a run, starts planning, dispatches all batches, and starts the final judge after all workers finish by default. The default workspace is the current directory. If `--label` is omitted, the run label is generated from the task text. It uses the same runs directory, so CLI-created runs are visible in the Web dashboard on port 8787 as long as the dashboard uses the same `--runs-dir`.
+
+`input-kanban serve` starts a lightweight background scheduler that keeps refreshing and advancing unfinished runs: it dispatches batches when a plan is ready, starts the next serial batch after the previous one completes, and starts the final judge after all batches complete. CLI `submit --auto` / `input-kanban auto <runId>` and the Web server share the same orchestrator auto-advance path, so progress no longer depends on whether a browser page is open or refreshed.
 
 To return immediately and let a background supervisor continue the auto loop, pass `-d` / `--detach`:
 
@@ -87,7 +91,7 @@ input-kanban --json retry <runId> [taskId]
 input-kanban stop <runId>
 ```
 
-Use `runs` to discover visible run batches first; `runs --active` shows only runs that have not reached a terminal state or still have running tasks, which lets an agent find `runId` values before calling `status <runId>`. Without a `runId`, `status` and `result` use the latest run by default. `result --copy` copies the final judge result. `retry` preserves the failed attempt and retries failed/unknown tasks. `--json` is handy for agents/scripts that need structured output. Stopping requires an explicit `runId` to avoid stopping the wrong run.
+Use `runs` to discover visible run batches first; `runs --active` shows only runs that have not reached a terminal state or still have running tasks, which lets an agent find `runId` values before calling `status <runId>`. To focus on one workspace, use `input-kanban runs --workspace /path/to/workspace`; the Web sidebar has the same workspace filter. Without a `runId`, `status` and `result` use the latest run by default. `result --copy` copies the final judge result. `retry` preserves the failed attempt and retries failed/unknown tasks. `--json` is handy for agents/scripts that need structured output. Stopping requires an explicit `runId` to avoid stopping the wrong run.
 
 ## Common Startup Options
 
@@ -102,7 +106,7 @@ input-kanban --open
 
 Defaults:
 
-- target repository: the current directory where `input-kanban` is launched; creating a run validates that it is inside a Git work tree
+- workspace: the current directory where `input-kanban` is launched; creating a run only requires an existing directory, and Git is shown as an optional capability when detected
 - host: `127.0.0.1`
 - port: `8787`
 - runs directory: `~/.input-kanban/runs`
@@ -113,14 +117,16 @@ Defaults:
 
 tmux mode still leaves batch barriers, `maxParallel`, final judge sequencing, and `judge_input.json` generation in Node.js. Each role output directory gets `run.sh` and `tmux.json`; status continues to be driven by `events.jsonl`, `stderr.log`, `last_message.md`, `exit_code`, and existing artifact files. After a tmux role command finishes, it writes `exit_code` first and then keeps the window open for inspection; the user closes the window manually from tmux.
 
-tmux mode is optional and intended for live terminal viewing of each Codex role. `codex exec` is currently non-interactive and does not normally show manual approval prompts; if you select `danger-full-access` when creating a run, you explicitly relax the worker sandbox and should only do so in a controlled test repository.
+If you are using `--runner tmux`, stopping and restarting `input-kanban serve` does not interrupt Codex sessions that are already running; the tmux session keeps going, and the scheduler resumes orchestration after the server comes back. With the `headless` runner, do not assume that restarting the service is safe for in-flight child processes.
+
+tmux mode is optional and intended for live terminal viewing of each Codex role. `codex exec` is currently non-interactive and does not normally show manual approval prompts; if you select `danger-full-access` when creating a run, you explicitly relax the worker sandbox and should only do so in a controlled test workspace.
 
 After run-level tmux metadata is available, the dashboard shows `Copy tmux attach command`. The file viewer no longer repeats tmux terminal details; use the run detail header to copy the attach command and inspect the tmux session.
 
 ## Using the Dashboard
 
 1. Click `New Run`.
-2. Enter a label, target repository, worker sandbox, and task description.
+2. Enter a label, workspace, worker sandbox, and task description.
 3. Click `Create Run`.
 4. The dashboard automatically starts `Plan` so the Codex planner can generate batches and workers.
 5. After planning completes, Web auto mode dispatches workers by batch barrier and concurrency limits by default.
@@ -159,7 +165,7 @@ runs/<runId>/
     └── verdict.json
 ```
 
-These files are local run records and do not need to be committed to your application repository.
+These files are local run records and do not need to be committed to your application workspace.
 
 ## Requirements
 

package/README.md

@@ -2,7 +2,7 @@
 
 中文 | [English](README.en.md)
 
-Input Kanban 是一个本地 Codex 编排看板。推荐通过 npm 安装，然后在目标代码仓库里运行 `input-kanban`，用浏览器管理任务拆分、并发执行和最终验收。
+Input Kanban 是一个本地 Codex 编排看板。推荐通过 npm 安装，然后在目标工作区里运行 `input-kanban`，用浏览器管理任务拆分、并发执行和最终验收；如果工作区恰好是 Git 仓库，界面会额外标识出来。
 
 ## 推荐使用方式
 
@@ -18,12 +18,12 @@ npm install -g input-kanban
 input-kanban --help
 ```
 
-### 2. 在目标仓库启动
+### 2. 在目标工作区启动
 
-进入你希望 Codex 修改或检查的代码仓库：
+进入你希望 Codex 修改或检查的工作区：
 
 ```bash
-cd /path/to/your/repo
+cd /path/to/your/workspace
 input-kanban
 ```
 
@@ -35,14 +35,16 @@ http://127.0.0.1:8787
 
 打开浏览器访问这个地址即可使用看板。
 
-### 3. 指定目标仓库启动
+### 3. 指定目标工作区启动
 
-如果不想先 `cd` 到目标仓库，也可以显式指定：
+如果不想先 `cd` 到目标工作区，也可以显式指定：
 
 ```bash
-input-kanban --repo /path/to/your/repo
+input-kanban --workspace /path/to/your/workspace
 ```
 
+`--repo` 仍可作为兼容别名使用。
+
 ## CLI 自动执行
 
 如果希望从终端直接提交任务并自动推进，可以使用 `submit`。任务内容支持两种输入方式：
@@ -52,7 +54,9 @@ input-kanban submit --task-file task.md --label "修复登录问题"
 input-kanban submit --task "修复登录问题，并补充回归测试" --label "修复登录问题"
 ```
 
-`submit` 默认会创建任务批次、发起拆分、自动派发所有批次，并在全部完成后自动发起最终验收。默认 repo 是当前目录；如果不传 `--label`，任务批次名称会从任务内容自动生成。它使用同一个 runs 目录，所以只要 8787 Web 看板也使用相同的 `--runs-dir`，CLI 创建的任务会在 Web 界面里可见。
+`submit` 默认会创建任务批次、发起拆分、自动派发所有批次，并在全部完成后自动发起最终验收。默认 workspace 是当前目录；如果不传 `--label`，任务批次名称会从任务内容自动生成。它使用同一个 runs 目录，所以只要 8787 Web 看板也使用相同的 `--runs-dir`，CLI 创建的任务会在 Web 界面里可见。
+
+`input-kanban serve` 会启动一个轻量后台 scheduler，持续刷新并推进未完成的 run：plan ready 后派发 batch、串行 batch 完成后启动下一批、全部 batch 完成后启动 final judge。CLI `submit --auto` / `input-kanban auto <runId>` 与 Web server 共用同一套 orchestrator 自动推进逻辑，因此任务推进不再依赖浏览器页面是否打开或刷新。
 
 如果希望提交后立即返回，让任务在后台自动执行，可以加 `-d` / `--detach`：
 
@@ -87,7 +91,7 @@ input-kanban --json retry <runId> [taskId]
 input-kanban stop <runId>
 ```
 
-`runs` 用来先列出可见任务批次，`runs --active` 只列出未进入终态或仍有子任务运行的批次，便于 agent 先发现 `runId`，再用 `status <runId>` 查详情。不传 `runId` 时，`status` 和 `result` 默认查看最近一次任务批次。`result --copy` 会复制最终验收结果；`retry` 会保留失败现场并重试失败/未知任务；`--json` 适合给 agent/脚本做结构化读取；停止任务请显式传入 `runId`，避免误停。
+`runs` 用来先列出可见任务批次，`runs --active` 只列出未进入终态或仍有子任务运行的批次，便于 agent 先发现 `runId`，再用 `status <runId>` 查详情。要只看某个工作区，可用 `input-kanban runs --workspace /path/to/workspace`；Web 左栏也提供了工作区筛选。不传 `runId` 时，`status` 和 `result` 默认查看最近一次任务批次。`result --copy` 会复制最终验收结果；`retry` 会保留失败现场并重试失败/未知任务；`--json` 适合给 agent/脚本做结构化读取；停止任务请显式传入 `runId`，避免误停。
 
 ## 常用启动参数
 
@@ -102,7 +106,7 @@ input-kanban --open
 
 默认值：
 
-- 目标仓库：启动 `input-kanban` 时的当前目录；创建批次时会校验它必须位于 Git work tree 内
+- 工作区：启动 `input-kanban` 时的当前目录；创建批次时只要求它是一个存在的目录，若检测到 Git 会额外显示 Git 标识
 - host：`127.0.0.1`
 - port：`8787`
 - runs 目录：`~/.input-kanban/runs`
@@ -113,14 +117,16 @@ input-kanban --open
 
 tmux 模式仍由 Node.js 负责 batch barrier、`maxParallel`、final judge 顺序和 `judge_input.json` 生成。每个角色输出目录会写入 `run.sh` 和 `tmux.json`，状态继续由 `events.jsonl`、`stderr.log`、`last_message.md`、`exit_code` 和既有 artifact 文件驱动。tmux 角色命令完成后会先写入 `exit_code`，再保留 window，方便查看现场；需要关闭时由用户在 tmux 里手动退出。
 
-tmux 模式是可选能力，主要用于在终端里实时查看每个 Codex 角色的执行过程。`codex exec` 当前属于非交互模式，默认不会弹出人工 approval；如果创建任务时选择 `danger-full-access`，表示显式放开 worker sandbox 限制，应只在受控测试仓库中使用。
+如果当前使用的是 `--runner tmux`，中断并重新启动 `input-kanban serve` 不会中断正在执行中的 Codex 会话；tmux session 会继续运行，服务重启后 scheduler 会重新接管后续推进。若使用 `headless` runner，则不应假设服务重启对正在运行的子进程是安全的。
+
+tmux 模式是可选能力，主要用于在终端里实时查看每个 Codex 角色的执行过程。`codex exec` 当前属于非交互模式，默认不会弹出人工 approval；如果创建任务时选择 `danger-full-access`，表示显式放开 worker sandbox 限制，应只在受控测试工作区中使用。
 
 看板会在 run 生成 tmux 元数据后显示 `复制tmux attach指令`。文件查看区域不再重复展示 tmux 终端信息；如需查看现场，请从批次详情顶部复制 attach 指令进入 tmux session。
 
 ## 在看板里如何使用
 
 1. 点击 `新建任务批次`。
-2. 输入批次名称、目标仓库、Worker 沙箱和任务说明。
+2. 输入批次名称、工作区、Worker 沙箱和任务说明。
 3. 点击 `创建批次`。
 4. 看板会自动发起 `拆分任务`，让 Codex planner 生成 batches 和 workers。
 5. 拆分完成后，Web 默认自动派发执行，按 batch barrier 和并发限制运行 workers。
@@ -159,7 +165,7 @@ runs/<runId>/
     └── verdict.json
 ```
 
-这些文件是本地运行记录，不需要提交到你的业务仓库。
+这些文件是本地运行记录，不需要提交到你的业务工作区。
 
 ## 使用前提
 

package/RELEASE_NOTES.md

@@ -1,5 +1,68 @@
 # Release Notes
 
+## v0.0.12
+
+### Highlights
+
+- Fix Windows startup/static serving by resolving `APP_ROOT` with `fileURLToPath(import.meta.url)` instead of URL pathname parsing.
+- Add a regression test for serving `/` and `/api/health` from the HTTP server.
+- Add task-detail hover guidance for sandbox and network capability issues, clarifying that sandbox-denied errors are not necessarily task failures.
+- Remember the last selected Web worker sandbox mode in browser local storage, so users do not need to reselect `danger-full-access` or other modes each time.
+- Auto-scroll the execution process view to the end when opened, while preserving the user's scroll position during refresh if they have scrolled upward.
+
+### Verification
+
+- `npm run check` passed with 64 tests.
+- `npm pack --dry-run` passed before release prep.
+
+## v0.0.11
+
+### Highlights
+
+- Simplify the Web sidebar header: show `任务批次` as the section title with a compact `新建` action on the right, removing repeated wording.
+- Document safe `input-kanban serve` restarts for `tmux` runner: already-running Codex sessions in tmux continue while the server is down, and the scheduler resumes after restart.
+- Clarify that `headless` runner does not provide the same safe-restart guarantee for in-flight child processes.
+
+### Verification
+
+- `npm run check` passed with 63 tests.
+- `npm pack --dry-run` passed before release prep.
+
+## v0.0.10
+
+### Highlights
+
+- Adopt a workspace-first model: `workspace` / `--workspace` are now the primary identity for runs, while `repo` / `--repo` remain compatibility aliases.
+- Allow non-Git workspace directories and show Git only as an optional capability marker when detected.
+- Add workspace filtering to CLI/API/Web: `input-kanban runs --workspace <path>` and `/api/runs?workspace=<path>` filter runs by workspace.
+- Add a server-side background scheduler for `input-kanban serve` so unfinished runs continue to advance without relying on an open browser tab.
+- Share auto-advance logic between CLI `submit --auto` / `input-kanban auto <runId>` and the Web server scheduler through the orchestrator.
+- Make `/api/runs` lightweight by reading run summaries without refreshing every historical run, improving cold-start list loading.
+- Simplify the Web sidebar: workspace filtering is a compact dropdown, the redundant list refresh button is removed, list load timing is available via a small hover icon, and Git is shown as a simple marker.
+
+### Verification
+
+- `npm run check` passed with 62 tests.
+- `npm pack --dry-run` passed before publishing.
+
+## v0.0.9
+
+### Highlights
+
+- Add MIT license and include it in the published npm package.
+- Add agent-friendly `--json` output for discovery, status lookup, result reading, stop, submit, and auto commands.
+- Add `runs` / `runs --active` to list visible and active run IDs before querying details.
+- Add `retry <runId> [taskId]` with preserved failed attempts and a one-shot auto retry path for blocked batches.
+- Add per-run `run_state.lock` protection around state writes to reduce CLI/Web/supervisor lost-update races.
+- Keep Web auto mode enabled by default after planning: dispatch planned work and auto-start the final judge while the page is open.
+- Keep CLI auto mode enabled by default for `submit`, with `--no-auto` as the create-and-plan-only escape hatch.
+- Add `result --copy` for copying final judge output, and keep version display in both CLI and Web footer.
+
+### Verification
+
+- `npm run check` passed with 58 tests.
+- `npm pack --dry-run` included the MIT `LICENSE` file.
+
 ## v0.0.8
 
 ### Highlights

package/bin/input-kanban.js

@@ -43,7 +43,7 @@ function splitCommand(argv) {
 }
 
 function parseServeArgs(argv) {
-  const args = { host: '127.0.0.1', port: undefined, repo: undefined, runsDir: undefined, codexBin: undefined, runner: undefined, open: false, json: false, help: false };
+  const args = { host: '127.0.0.1', port: undefined, workspace: undefined, repo: undefined, runsDir: undefined, codexBin: undefined, runner: undefined, open: false, json: false, help: false };
   for (let i = 0; i < argv.length; i++) {
     const arg = argv[i];
     const next = () => argv[++i];
@@ -53,6 +53,7 @@ function parseServeArgs(argv) {
     else if (arg === '--no-open') args.open = false;
     else if (arg === '--host') args.host = next();
     else if (arg === '--port' || arg === '-p') args.port = Number(next());
+    else if (arg === '--workspace') args.workspace = next();
     else if (arg === '--repo' || arg === '-r') args.repo = next();
     else if (arg === '--runs-dir') args.runsDir = next();
     else if (arg === '--codex-bin') args.codexBin = next();
@@ -63,13 +64,15 @@ function parseServeArgs(argv) {
 }
 
 function parseRunsArgs(argv) {
-  const args = { runsDir: undefined, active: false, includeArchived: false, limit: 20, json: false, help: false };
+  const args = { runsDir: undefined, workspace: undefined, repo: undefined, active: false, includeArchived: false, limit: 20, json: false, help: false };
   for (let i = 0; i < argv.length; i++) {
     const arg = argv[i];
     const next = () => argv[++i];
     if (arg === '--help' || arg === '-h') args.help = true;
     else if (arg === '--json' || arg === '-j') args.json = true;
     else if (arg === '--runs-dir') args.runsDir = next();
+    else if (arg === '--workspace') args.workspace = next();
+    else if (arg === '--repo' || arg === '-r') args.repo = next();
     else if (arg === '--active') args.active = true;
     else if (arg === '--include-archived') args.includeArchived = true;
     else if (arg === '--limit') args.limit = Number(next());
@@ -144,7 +147,7 @@ function parseStopArgs(argv) {
 }
 
 function parseAutoArgs(argv) {
-  const args = { host: '127.0.0.1', port: 8787, runsDir: undefined, codexBin: undefined, runner: undefined, runId: undefined, json: false, pollMs: 3000, maxRetries: 1, help: false };
+  const args = { host: '127.0.0.1', port: 8787, workspace: undefined, runsDir: undefined, codexBin: undefined, runner: undefined, runId: undefined, json: false, pollMs: 3000, maxRetries: 1, help: false };
   for (let i = 0; i < argv.length; i++) {
     const arg = argv[i];
     const next = () => argv[++i];
@@ -152,6 +155,7 @@ function parseAutoArgs(argv) {
     else if (arg === '--json' || arg === '-j') args.json = true;
     else if (arg === '--host') args.host = next();
     else if (arg === '--port' || arg === '-p') args.port = Number(next());
+    else if (arg === '--workspace') args.workspace = next();
     else if (arg === '--runs-dir') args.runsDir = next();
     else if (arg === '--codex-bin') args.codexBin = next();
     else if (arg === '--runner') args.runner = validateRunner(next(), '--runner');
@@ -165,7 +169,7 @@ function parseAutoArgs(argv) {
 
 function parseSubmitArgs(argv) {
   const args = {
-    host: '127.0.0.1', port: 8787, repo: undefined, runsDir: undefined, codexBin: undefined,
+    host: '127.0.0.1', port: 8787, workspace: undefined, repo: undefined, runsDir: undefined, codexBin: undefined,
     runner: undefined, label: undefined, taskText: undefined, taskFile: undefined, maxParallel: 3,
     workerSandbox: 'workspace-write', auto: true, detach: false, watch: true, json: false, pollMs: 3000, maxRetries: 1, help: false
   };
@@ -176,6 +180,7 @@ function parseSubmitArgs(argv) {
     else if (arg === '--json' || arg === '-j') args.json = true;
     else if (arg === '--host') args.host = next();
     else if (arg === '--port' || arg === '-p') args.port = Number(next());
+    else if (arg === '--workspace') args.workspace = next();
     else if (arg === '--repo' || arg === '-r') args.repo = next();
     else if (arg === '--runs-dir') args.runsDir = next();
     else if (arg === '--codex-bin') args.codexBin = next();
@@ -199,8 +204,15 @@ function parseSubmitArgs(argv) {
 function applyRuntimeEnv(args) {
   if (args.port) process.env.PORT = String(args.port);
   if (args.host) process.env.HOST = args.host;
-  if (args.repo) process.env.KANBAN_DEFAULT_REPO = path.resolve(args.repo);
-  else if (!process.env.KANBAN_DEFAULT_REPO) process.env.KANBAN_DEFAULT_REPO = process.cwd();
+  const workspace = args.workspace || args.repo;
+  if (workspace) {
+    const resolvedWorkspace = path.resolve(workspace);
+    process.env.KANBAN_DEFAULT_WORKSPACE = resolvedWorkspace;
+    process.env.KANBAN_DEFAULT_REPO = resolvedWorkspace;
+  } else {
+    if (!process.env.KANBAN_DEFAULT_WORKSPACE) process.env.KANBAN_DEFAULT_WORKSPACE = process.env.KANBAN_DEFAULT_REPO || process.cwd();
+    if (!process.env.KANBAN_DEFAULT_REPO) process.env.KANBAN_DEFAULT_REPO = process.env.KANBAN_DEFAULT_WORKSPACE || process.cwd();
+  }
   if (args.runsDir) process.env.KANBAN_RUNS_DIR = path.resolve(args.runsDir);
   if (args.codexBin) process.env.KANBAN_CODEX_BIN = args.codexBin;
   if (args.runner) process.env.KANBAN_RUNNER = args.runner;
@@ -231,7 +243,8 @@ Usage:
 Serve options:
   --host <host>              Host to bind, default 127.0.0.1
   -p, --port <port>          Port to bind, default 8787
-  -r, --repo <path>          Default target repository, default current directory
+  --workspace <path>         Default workspace, default current directory
+  -r, --repo <path>          Alias for --workspace
   --runs-dir <path>          Runtime runs directory, default ~/.input-kanban/runs
   --codex-bin <path>         Codex CLI executable, default codex
   --runner <mode>            Runner mode: headless or tmux, default headless
@@ -270,7 +283,8 @@ Stop options:
   -j, --json                 Emit JSON output instead of human text
 
 Submit options:
-  -r, --repo <path>          Target Git work tree, default current directory
+  --workspace <path>         Target workspace, default current directory
+  -r, --repo <path>          Alias for --workspace
   -l, --label <label>        Task batch name, default generated from task text
   --task <text>              Task description text
   --task-file <path>         Read task description from file, use - for stdin
@@ -292,12 +306,13 @@ function printSubmitHelp() {
   console.log(`input-kanban submit
 
 Usage:
-  input-kanban submit --repo <path> --task-file task.md
-  input-kanban submit --repo <path> --task "fix the bug" --label "bugfix"
+  input-kanban submit --workspace <path> --task-file task.md
+  input-kanban submit --workspace <path> --task "fix the bug" --label "bugfix"
   input-kanban submit --task-file task.md -d
 
 Options:
-  -r, --repo <path>          Target Git work tree, default current directory
+  --workspace <path>         Target workspace, default current directory
+  -r, --repo <path>          Alias for --workspace
   -l, --label <label>        Task batch name, default generated from task text
   --task <text>              Task description text
   --task-file <path>         Read task description from file, use - for stdin
@@ -318,11 +333,14 @@ function printRunsHelp() {
 
 Usage:
   input-kanban runs
+  input-kanban runs --workspace <path>
   input-kanban runs --active
   input-kanban --json runs --active
 
 Options:
   --runs-dir <path>          Runtime runs directory shared with the Web UI
+  --workspace <path>         Filter by workspace path
+  -r, --repo <path>          Alias for --workspace
   --active                   Show only active or pending-action runs
   --include-archived         Include archived runs
   --limit <n>                Maximum rows to print, default 20
@@ -467,7 +485,7 @@ function printRunStatus(state) {
   console.log(`任务批次: ${state.label || '-'}`);
   console.log(`Run ID: ${state.runId}`);
   console.log(`状态: ${displayStatus(state.status)}`);
-  console.log(`仓库: ${state.repo || '-'}`);
+  console.log(`工作区: ${state.workspacePath || state.repo || '-'}`);
   console.log(`当前批次: ${currentBatchText(state)}`);
   console.log(`进度: ${counts.completed}/${counts.total} ｜执行中 ${counts.running} ｜失败 ${counts.failed}`);
   if (state.judge?.status && state.judge.status !== 'pending') console.log(`验收: ${displayStatus(state.judge.status)}`);
@@ -476,7 +494,7 @@ function printRunStatus(state) {
 function printRunsTable(runs) {
   if (!runs.length) { console.log('没有找到任务批次'); return; }
   for (const run of runs) {
-    console.log(`${run.runId}｜${run.label || '-'}｜${displayStatus(run.status)}｜进度 ${run.completed}/${run.total}｜执行中 ${run.running}｜失败 ${run.failed}｜runner ${run.runner || '-'}｜沙箱 ${run.workerSandbox || '-'}｜仓库 ${run.repo || '-'}`);
+    console.log(`${run.runId}｜${run.label || '-'}｜${displayStatus(run.status)}｜进度 ${run.completed}/${run.total}｜执行中 ${run.running}｜失败 ${run.failed}｜runner ${run.runner || '-'}｜沙箱 ${run.workerSandbox || '-'}｜工作区 ${run.workspacePath || run.repo || '-'}`);
   }
 }
 
@@ -510,11 +528,12 @@ async function confirmFailureTerminal(runId, state, refreshRun, pollMs) {
 }
 
 async function watchRun(runId, { auto = false, pollMs = 3000, quiet = false, maxRetries = 1 } = {}) {
-  const { dispatchRun, refreshRun, retryRun, startJudge } = await import('../src/orchestrator.js');
+  const { autoAdvanceRun, refreshRun } = await import('../src/orchestrator.js');
   let lastStatus = '';
-  let judgeStarted = false;
   while (true) {
-    const state = await refreshRun(runId);
+    const state = auto
+      ? await autoAdvanceRun(runId, { startCreated: true, maxRetries, retryReason: 'auto retry from CLI' })
+      : await refreshRun(runId);
     if (!state) throw new Error(`run not found: ${runId}`);
     const line = statusLine(state);
     if (line !== lastStatus) {
@@ -522,26 +541,6 @@ async function watchRun(runId, { auto = false, pollMs = 3000, quiet = false, max
       lastStatus = line;
     }
 
-    if (auto && state.status === 'batch_blocked') {
-      try {
-        const retryState = await retryRun(runId, { reason: 'auto retry from CLI', maxRetries, auto: true });
-        if (!quiet) console.log(`自动重试任务: ${retryState.retriedTaskIds?.join(', ') || '-'}`);
-        lastStatus = '';
-        continue;
-      } catch (error) {
-        if (!quiet) console.log(`自动重试跳过: ${error.message || String(error)}`);
-      }
-    }
-
-    if (auto && state.status === 'planned') {
-      if (!quiet) console.log('自动派发任务...');
-      await dispatchRun(runId);
-    } else if (auto && state.status === 'batches_completed' && state.judge?.status !== 'running' && !judgeStarted) {
-      if (!quiet) console.log('自动发起最终验收...');
-      judgeStarted = true;
-      await startJudge(runId);
-    }
-
     if (isTerminal(state)) {
       if (isFailureTerminal(state)) {
         const result = await confirmFailureTerminal(runId, state, refreshRun, pollMs);
@@ -562,13 +561,15 @@ async function serve(args) {
   const { startServer } = await import('../src/server.js');
   const instance = await startServer({ host: process.env.HOST, port: Number(process.env.PORT || 8787), log: false });
   if (args.json) {
-    printJson({ ok: true, command: 'serve', version: instance.version, url: instance.url, repo: instance.defaultRepo, runsDir: instance.runsDir, runner: instance.runner });
+    printJson({ ok: true, command: 'serve', version: instance.version, url: instance.url, defaultWorkspace: instance.defaultWorkspace, defaultRepo: instance.defaultRepo, runsDir: instance.runsDir, runner: instance.runner, scheduler: instance.scheduler });
   } else {
     console.log(`Input Kanban v${PACKAGE_VERSION} started`);
     console.log(`URL:  ${instance.url}`);
-    console.log(`Repo: ${instance.defaultRepo}`);
+    console.log(`Workspace: ${instance.defaultWorkspace}`);
+    console.log(`Repo alias: ${instance.defaultRepo}`);
     console.log(`Runs: ${instance.runsDir}`);
     console.log(`Runner: ${instance.runner}`);
+    console.log(`Scheduler: ${instance.scheduler ? 'enabled' : 'disabled'}`);
   }
   if (args.open) openBrowser(instance.url);
   const shutdown = () => { instance.stop().finally(() => process.exit(0)); };
@@ -606,10 +607,11 @@ async function runs(args) {
   applyRuntimeEnv(args);
   const { listRuns } = await import('../src/orchestrator.js');
   const limit = Number.isFinite(Number(args.limit)) && Number(args.limit) > 0 ? Number(args.limit) : 20;
-  const allRuns = await listRuns({ includeArchived: !!args.includeArchived });
+  const workspace = args.workspace || args.repo || '';
+  const allRuns = await listRuns({ includeArchived: !!args.includeArchived, workspace });
   const filtered = (args.active ? allRuns.filter(isActiveRunSummary) : allRuns).slice(0, limit);
   if (args.json) {
-    printJson({ ok: true, command: 'runs', active: !!args.active, includeArchived: !!args.includeArchived, limit, count: filtered.length, runs: filtered });
+    printJson({ ok: true, command: 'runs', active: !!args.active, includeArchived: !!args.includeArchived, workspace: workspace || undefined, limit, count: filtered.length, runs: filtered });
     return;
   }
   printRunsTable(filtered);
@@ -730,6 +732,7 @@ async function submit(args) {
   const state = await createRun({
     label: args.label,
     taskText,
+    workspace: process.env.KANBAN_DEFAULT_WORKSPACE || process.env.KANBAN_DEFAULT_REPO,
     repo: process.env.KANBAN_DEFAULT_REPO,
     maxParallel: args.maxParallel,
     workerSandbox: args.workerSandbox