input-kanban 0.0.6 → 0.0.8

package/PROJECT_GUIDE.md

@@ -51,9 +51,9 @@ The npm CLI entry is:
 bin/input-kanban.js
 ```
 
-It parses CLI options, sets environment variables before importing backend modules, and starts the HTTP server.
+It parses CLI options and sets environment variables before importing backend modules. Without a subcommand, or with `serve`, it starts the HTTP server. With `submit`, it creates a run directly in the shared runs directory and can optionally run an auto loop.
 
-Supported options:
+Supported serve options:
 
 ```text
 --host <host>
@@ -61,10 +61,62 @@ Supported options:
 --repo <path>
 --runs-dir <path>
 --codex-bin <path>
+--runner <headless|tmux>
 --open
 --no-open
 ```
 
+Supported status options:
+
+```text
+[runId]
+--runs-dir <path>
+--watch
+--poll-ms <ms>
+```
+
+`input-kanban status` refreshes and prints a run summary. If no `runId` is provided, it uses the latest run from the shared runs directory. `--watch` keeps polling until the run reaches a terminal state.
+
+Supported result options:
+
+```text
+[runId]
+--runs-dir <path>
+--copy
+```
+
+`input-kanban result [runId]` prints the final judge result. It prefers `judge/verdict.json` and falls back to `judge/last_message.md`. If no `runId` is provided, it uses the latest run. `--copy` sends the result to the system clipboard.
+
+Supported stop options:
+
+```text
+<runId>
+--runs-dir <path>
+--reason <text>
+```
+
+`input-kanban stop <runId>` calls the same orchestrator stop path as the Web dashboard. Stop requires an explicit run id. The backend first asks the active runner to stop known processes and then falls back to killing live stored PIDs, so Web and CLI processes can stop each other's headless workers.
+
+Supported submit options:
+
+```text
+--repo <path>
+--label <label>
+--task <text>
+--task-file <path|->
+--max-parallel <n>
+--worker-sandbox <read-only|workspace-write|danger-full-access>
+--runner <headless|tmux>
+--runs-dir <path>
+--auto
+--no-auto
+--detach / -d
+--watch
+--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`.
+
 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;
@@ -147,6 +199,7 @@ Recovery options:
 - Inspect `events.pretty`, `stderr.log`, `last_message.md`, and artifacts.
 - Manually mark `failed` or `unknown` workers as completed if the user confirms the work is actually done.
 - Manual completion writes `workers/<taskId>/manual_completion.json`.
+- If the user pastes a manual success result, it is saved as `workers/<taskId>/manual_result.md` and included in final judge input.
 - The UI preserves the original failed or unknown status while also showing the manual completion marker.
 
 ## Stop and Archive
@@ -255,6 +308,8 @@ runs/<runId>/planner/
 runs/<runId>/planner_attempts/attempt-XX/
 runs/<runId>/workers/<taskId>/
 runs/<runId>/judge/judge_input.json
+runs/<runId>/workers/<taskId>/events_timed.jsonl
+runs/<runId>/workers/<taskId>/manual_result.md
 runs/<runId>/judge/verdict.json
 ```
 
@@ -271,6 +326,7 @@ runs/<runId>/judge/verdict.json
 - `POST /api/runs/:runId/judge`
 - `POST /api/runs/:runId/stop`
 - `POST /api/runs/:runId/archive`
+- `PATCH /api/runs/:runId/label`
 - `GET /api/runs/:runId/task-text`
 - `GET /api/runs/:runId/tasks/:taskId/file?name=...`
 - `POST /api/runs/:runId/tasks/:taskId/mark-completed`
@@ -336,7 +392,7 @@ 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>`.
    - 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`, `stderr.log`, `last_message.md`, and `exit_code` files.
+   - 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:
@@ -354,6 +410,10 @@ notes or handoff.
    - Verify the package includes `bin/`, `src/`, `public/`, `README.md`, `README.en.md`, `PROJECT_GUIDE.md`, `ENVIRONMENT.md`, and `package.json`.
    - Verify no runtime run directories, local logs, or unrelated temporary artifacts are included.
 
+## Release Notes
+
+Keep a single repository-level `RELEASE_NOTES.md` with recent version history. Do not add one tracked `RELEASE_NOTES.vX.Y.Z.md` file per release. When creating a GitHub Release, use a temporary notes file or copy the relevant version section from `RELEASE_NOTES.md` into `gh release create --notes-file`.
+
 ## Change Guidelines
 
 - Do not add automatic worker retry unless there is a verified rollback or idempotency mechanism.

package/README.en.md

@@ -43,6 +43,46 @@ If you do not want to `cd` into the target repository first, pass it explicitly:
 input-kanban --repo /path/to/your/repo
 ```
 
+## CLI Auto Execution
+
+To submit a task from the terminal and let it advance automatically, use `submit`. Task content supports two input modes:
+
+```bash
+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`.
+
+To return immediately and let a background supervisor continue the auto loop, pass `-d` / `--detach`:
+
+```bash
+input-kanban submit --task-file task.md -d
+```
+
+To create the run and start planning without dispatching or judging, pass `--no-auto`.
+
+Common examples:
+
+```bash
+input-kanban submit --task "Fix login issue"
+input-kanban submit --task-file task.md --max-parallel 2 --worker-sandbox workspace-write
+input-kanban submit --runs-dir ~/.input-kanban/runs --runner tmux -d
+```
+
+Check and stop:
+
+```bash
+input-kanban status
+input-kanban status --watch
+input-kanban status <runId> --watch
+input-kanban result
+input-kanban result <runId> --copy
+input-kanban stop <runId>
+```
+
+Without a `runId`, `status` and `result` use the latest run by default. `result --copy` copies the final judge result. Stopping requires an explicit `runId` to avoid stopping the wrong run.
+
 ## Common Startup Options
 
 ```bash
@@ -76,7 +116,7 @@ After run-level tmux metadata is available, the dashboard shows `Copy tmux attac
 1. Click `New Run`.
 2. Enter a label, target repository, worker sandbox, and task description.
 3. Click `Create Run`.
-4. Click `Plan` to let the Codex planner generate batches and workers.
+4. The dashboard automatically starts `Plan` so the Codex planner can generate batches and workers.
 5. Click `Dispatch` to run workers by batch barrier and concurrency limits.
 6. Inspect execution logs, final messages, error logs, and artifacts.
 7. After all batches complete, click `Final Judge`.

package/README.md

@@ -43,6 +43,46 @@ http://127.0.0.1:8787
 input-kanban --repo /path/to/your/repo
 ```
 
+## CLI 自动执行
+
+如果希望从终端直接提交任务并自动推进，可以使用 `submit`。任务内容支持两种输入方式：
+
+```bash
+input-kanban submit --task-file task.md --label "修复登录问题"
+input-kanban submit --task "修复登录问题，并补充回归测试" --label "修复登录问题"
+```
+
+`submit` 默认会创建任务批次、发起拆分、自动派发所有批次，并在全部完成后自动发起最终验收。默认 repo 是当前目录；如果不传 `--label`，任务批次名称会从任务内容自动生成。它使用同一个 runs 目录，所以只要 8787 Web 看板也使用相同的 `--runs-dir`，CLI 创建的任务会在 Web 界面里可见。
+
+如果希望提交后立即返回，让任务在后台自动执行，可以加 `-d` / `--detach`：
+
+```bash
+input-kanban submit --task-file task.md -d
+```
+
+如果只想创建并拆分，不自动派发和验收，可以加 `--no-auto`。
+
+常用参数：
+
+```bash
+input-kanban submit --task "修复登录问题"
+input-kanban submit --task-file task.md --max-parallel 2 --worker-sandbox workspace-write
+input-kanban submit --runs-dir ~/.input-kanban/runs --runner tmux -d
+```
+
+查看和停止：
+
+```bash
+input-kanban status
+input-kanban status --watch
+input-kanban status <runId> --watch
+input-kanban result
+input-kanban result <runId> --copy
+input-kanban stop <runId>
+```
+
+不传 `runId` 时，`status` 和 `result` 默认查看最近一次任务批次。`result --copy` 会复制最终验收结果；停止任务请显式传入 `runId`，避免误停。
+
 ## 常用启动参数
 
 ```bash
@@ -76,7 +116,7 @@ tmux 模式是可选能力，主要用于在终端里实时查看每个 Codex
 1. 点击 `新建任务批次`。
 2. 输入批次名称、目标仓库、Worker 沙箱和任务说明。
 3. 点击 `创建批次`。
-4. 点击 `拆分任务`，让 Codex planner 生成 batches 和 workers。
+4. 看板会自动发起 `拆分任务`，让 Codex planner 生成 batches 和 workers。
 5. 点击 `派发执行`，按 batch barrier 和并发限制运行 workers。
 6. 查看执行日志、最终回复、错误日志和产物。
 7. 所有 batch 完成后，点击 `汇总验收`。

package/RELEASE_NOTES.md

@@ -0,0 +1,86 @@
+# Release Notes
+
+## v0.0.8
+
+### Highlights
+
+- Add CLI `submit` workflow with two task input modes: `--task-file <markdown>` for Markdown files and `--task <text>` for inline task text.
+- Add CLI auto loop as the default `submit` behavior to create a run, start planning, dispatch batches, and run the final judge while keeping the run visible in the shared Web dashboard.
+- Add CLI `-d` / `--detach` to run the auto loop in a background supervisor, plus `--no-auto` for create-and-plan-only mode.
+- Add CLI `status [runId] [--watch]`, defaulting to the latest run when `runId` is omitted.
+- Add CLI `result [runId] [--copy]` to print or copy the final judge result.
+- Add CLI `stop <runId>` and make backend stop robust across CLI/Web processes by falling back to stored live PIDs.
+- Derive the run label from task text when `--label` / form label is omitted.
+- Add dashboard run-card archive confirmation without modal popups and replace the detail refresh text chips with a one-shot circle animation.
+
+### Verification
+
+- `npm run check` passed with 51 tests.
+
+## v0.0.7
+
+### Highlights
+
+- Improve the run list cards: replace `Run ID` with a repository chip and copy action, add frozen duration, and hide rename buttons until hover/focus.
+- Streamline dashboard flow: creating a run now automatically starts planning, selecting a task opens its execution log by default, and running-task conflicts show Chinese user-facing messages.
+- Improve task detail ergonomics: copy actions are available for both final replies and verdict JSON, and manual success completion stores pasted human evidence.
+- Add execution timing artifacts and summary chips, including `events_timed.jsonl`, command duration breakdowns, model/scheduler time, startup/teardown time, and system event counts.
+- Strengthen run creation validation by rejecting missing target paths and directories outside a Git work tree before planning starts.
+- Keep release notes in a single repository-level `RELEASE_NOTES.md` and include that file in the npm package.
+
+### Verification
+
+- `npm run check` passed with 43 tests.
+- `npm pack --dry-run` passed before publishing.
+
+## v0.0.6
+
+### Changes
+
+- Validate the target repository when creating a run, rejecting missing paths and directories outside a Git work tree before planning starts.
+- Add a compact copy button for the full repository path in the run detail header.
+- Document the Git work tree requirement in the README, English README, environment reference, and project guide.
+
+### Verification
+
+- `npm run check` passed with 38 tests.
+- `npm pack --dry-run` confirmed package contents before the version bump.
+
+## v0.0.5
+
+### Highlights
+
+- Add Input Kanban branding icons to the dashboard header and browser tab.
+- Add standard favicon and Apple touch icon assets so browsers can show the same visual identity as the page header.
+- Align left run-list metadata with the compact chip style used in run details.
+- Align batch-row metadata in the task table with the same chip style for `Batch ID`, `最大并发`, and `进度`.
+
+### Notes
+
+- This is a UI polish release after `v0.0.4`.
+- No runner, scheduler, tmux, sandbox, or Codex execution behavior changes are included.
+
+### Verification
+
+- `npm run check` passed.
+- `npm pack --dry-run` passed.
+
+## v0.0.4
+
+### Highlights
+
+- Add tmux batch layout: one session per run, windows for planner, each batch, and judge, with batch windows showing an overview pane plus worker panes.
+- Show formatted Codex execution output in tmux panes while keeping raw JSONL logs in `events.jsonl`.
+- Add worker sandbox selection in the create form, including explicit `danger-full-access` for controlled test repositories.
+- Refine the dashboard UI with compact run metadata chips, no redundant tmux badges, no file-viewer tmux panel, and role-specific file tabs.
+- Freeze run duration after terminal states such as final judge completion, instead of continuing to count on auto-refresh.
+
+### Notes
+
+- `codex exec` is treated as non-interactive; tmux mode provides live terminal visibility but does not implement manual approval prompts.
+- The dashboard exposes the run-level `tmux attach-session` copy action after tmux metadata is available.
+- Use `danger-full-access` only when you explicitly want to relax worker sandbox limits in a controlled environment.
+
+### Verification
+
+- `npm run check` passed.

package/bin/input-kanban-timestamp-events.js

@@ -0,0 +1,34 @@
+#!/usr/bin/env node
+import fs from 'node:fs';
+import path from 'node:path';
+import readline from 'node:readline';
+
+const [eventsFile, timedEventsFile] = process.argv.slice(2);
+if (!eventsFile || !timedEventsFile) {
+  console.error('usage: input-kanban-timestamp-events.js <events.jsonl> <events_timed.jsonl>');
+  process.exit(2);
+}
+
+await fs.promises.mkdir(path.dirname(eventsFile), { recursive: true });
+await fs.promises.mkdir(path.dirname(timedEventsFile), { recursive: true });
+
+const events = fs.createWriteStream(eventsFile, { flags: 'a' });
+const timed = fs.createWriteStream(timedEventsFile, { flags: 'a' });
+const rl = readline.createInterface({ input: process.stdin, crlfDelay: Infinity });
+
+for await (const line of rl) {
+  const rawLine = `${line}\n`;
+  events.write(rawLine);
+  process.stdout.write(rawLine);
+  const receivedAt = new Date().toISOString();
+  try {
+    timed.write(`${JSON.stringify({ receivedAt, event: JSON.parse(line) })}\n`);
+  } catch {
+    timed.write(`${JSON.stringify({ receivedAt, rawLine: line })}\n`);
+  }
+}
+
+await Promise.all([
+  new Promise(resolve => events.end(resolve)),
+  new Promise(resolve => timed.end(resolve))
+]);