@xingular/harness 1.2.0 → 1.3.1-unstable.0

package/CHANGELOG.md

@@ -1,5 +1,39 @@
 # Changelog
 
+## Unreleased
+
+- Keep subagent progress through Esc, failures and restarts. A parent continues a stopped child with
+  `spawn_subagent { continue: <runId> }`, which reopens that child's own conversation with its
+  profile, tools, account and variant, instead of starting it again. The next reply hears about
+  stopped children before it answers. A reopened terminal conversation still adopts children an
+  earlier launch started. The `/subagents` page now shows the main agent as a `main` row (a
+  reserved profile name), and both the page and the rows under the status line come back when a
+  conversation is reopened, until the next run starts. Run records keep their `model` and `effort`
+  (ADR-0043).
+
+- Make the shell, write and edit tools work on Windows right after install. Commands run in Git
+  Bash when it is installed and in PowerShell otherwise; the tool keeps the name `bash`. Windows has
+  no write-boundary sandbox, so each command asks for a one-call approval unless Full Permission is
+  on, and plan-mode Bash is refused there. Write and edit run their atomic helper with Node
+  directly. `/doctor` names the Windows shell instead of reporting it as delegated to Pi (ADR-0042).
+
+- Make `/doctor` check the use of Bash, not only that the executable exists. The local shell check
+  now also reports the platform write-boundary backend (sandbox-exec on macOS, bubblewrap on Linux)
+  whose absence stops every Bash call before it runs. The new live check runs one fixed command the
+  harness wrote (`printf`) in the working folder through the same root, hard-link scan and sandbox a
+  real Bash call takes, after the policy gate, and reports only the exit status. A diagnostic never
+  widens the boundary, so a command that the boundary refuses before the shell starts is reported
+  as blocked with that reason.
+
+## 1.3.0 — todo progress, bounded work, and plugin management
+
+- Make session naming and progress guidance concrete: name a session before the first tool call when work needs tools or changes state, and keep a todo list for multi-step work. Prompt and tool descriptions use the same wording; guidance remains advisory and subagents retain the parent's title.
+- Rename the run checklist to todo: `todo_write`, `todo.updated`, `runs.todo`, the `todo` plugin and a todo block in the terminal. Add `/todo` (alias `/checklist`) to show the current list in the terminal and App without a model request. Existing runs still read `checklist.updated`; pinned `checklist_write` calls continue through `todo_write`; `runs.checklist` and `continuation.checklist` remain deprecated aliases for one release (PROP-0045).
+- Raise work-slice defaults to 320 tool calls and 60 minutes, with no token ceiling unless configured. Make stall detection progress-aware, bound plan research to eligible read-only profiles, and restore the latest plan/todo context after compaction (PROP-0044–0046; ADR-0039).
+- Separate `/plugins` local package management from `/hub` Community catalog discovery. Preserve all-channel Hub receipts and visible cache/refresh state; keep Hub-owned package removal receipt-aware and prevent floating updates (PROP-0047; ADR-0041).
+- Improve terminal skill completion and highlighting while preserving command and argument distinctions.
+- Make Doctor's Bash readiness check verify the required write-boundary sandbox and add a fixed, no-network live probe through the same workspace boundary; report policy blocks accurately without widening permissions.
+
 ## 1.2.0 — workspace safety and terminal capabilities
 
 - Scope model-controlled file writes and Bash to the active project workspace by default; reject the filesystem root as a workspace. Native writes use revalidated atomic replacement; Bash fails closed on incomplete hard-link scans or unavailable sandboxing (macOS also blocks workspace-local hard links). Explicit outside-scope Bash requires approval before one execution, showing the complete escaped command; output never triggers approval or retry.
@@ -12,6 +46,7 @@
 - Add reproducible PTY and session-runtime profiling plus [EXP-0003's baseline report](docs/experiments/EXP-0003-performance-audit/results.md); it measures 1.1.1 on a dirty worktree, not 1.2.0.
 - Update the pinned Pi runtime to 1.4.0, with the terminal adapter's private hooks and HTTP dispatcher chunk rechecked against it.
 - Fix the work-slice stall guard reporting a reply's own checklist updates as repeated work. A call's identity is its name and every argument, hashed, instead of six fixed field names that made every `checklist_write` look alike; the counts and the nudge start fresh in each reply, so a terminal session no longer carries a repeat from one reply into the next. Three identical calls are still named once, and a repeat after that still ends the slice.
+- Raise the work-slice defaults to 320 tool calls and 60 minutes, and drop the token cap by default: calls and the clock are the bound, and a token ceiling is available per run with `workSlice.maxNewTokens` for whoever wants one. A continuation keeps the policy, and eight slices still cap unattended work. See PROP-0044.
 
 ## 1.1.1 — agent profiles and named subagents
 

package/README.md

@@ -45,9 +45,9 @@ index](docs/README.md) links the architecture and other project records.
 - `providers: false` runs a session with the harness's own tools only.
 - `variant: { scope }` runs the session on that scope's head variant (or `{ scope, version }`, or `{ dir }` for a variant on disk). The version is pinned for the run and recorded on it.
 - On the caller, `recallExcludeAgents` hides those agents' conversations from history and trajectory tools.
-- `harnessTools: false` runs a session without the History, Wiki and skill tools (and without `ask_user` and `checklist_write`).
-- Every session with harness tools gets `checklist_write`: the model sends its whole checklist (`pending`, `in_progress`, `completed`, at most 50 steps) and the run records it as a `checklist.updated` event. `checklistOf(events)` or the `runs.checklist` method reads the latest one. Plan mode allows it.
-- `continueFrom: <run id>` continues a run that stopped before it finished (interrupted or failed) as a new run. `harness.recovery.interruptedRunIds` lists the runs `open` marked interrupted, and `continuationOf(root, runId, sessionDir)` (`runs.continuation`) says whether one can be continued and what it left: checklist, unanswered approvals and questions, the last tool and whether it finished, unfinished subagents. The new run reopens the same native history, records `resumedFromRunId`, keeps the account, variant version and capability set (`continuation_mismatch` otherwise), and the model is told where the earlier run stopped. The harness never continues a run by itself; which runs to continue, and when, is the application's choice.
+- `harnessTools: false` runs a session without the History, Wiki and skill tools (and without `ask_user` and `todo_write`).
+- Every session with harness tools gets `todo_write`: the model sends its whole todo list (`pending`, `in_progress`, `completed`, at most 50 steps) and the run records it as a `todo.updated` event. `todoOf(events)` or the `runs.todo` method reads the latest one. Plan mode allows it. The pre-rename `checklist_write` and `checklist.updated` are still read, `runs.checklist` is a deprecated alias, and `checklistOf`/`CHECKLIST_WRITE` remain deprecated exports for one release (PROP-0045).
+- `continueFrom: <run id>` continues a run that stopped before it finished (interrupted or failed) as a new run. `harness.recovery.interruptedRunIds` lists the runs `open` marked interrupted, and `continuationOf(root, runId, sessionDir)` (`runs.continuation`) says whether one can be continued and what it left: todo list, unanswered approvals and questions, the last tool and whether it finished, unfinished subagents. The new run reopens the same native history, records `resumedFromRunId`, keeps the account, variant version and capability set (`continuation_mismatch` otherwise), and the model is told where the earlier run stopped. The harness never continues a run by itself; which runs to continue, and when, is the application's choice.
 - The first-party `lessons` plugin (off by default) reflects on a completed top-level run with enough tool calls and may keep one general lesson in the Wiki under `library/lessons/`, in refinement's cue/lesson shape. It uses the run's own account and model, read-only file tools, and is capped (`minToolCalls`, `maxLessons`, `maxChars`). See PROP-0008.
 
 Every session also gets `trajectory_search` and `trajectory_read` from the built-in History plugin.
@@ -272,6 +272,11 @@ The machine needs Node 22.19 or newer and Bun 1.3.14 or newer. Harness runs its
 terminal frontend with Bun, using its pinned Pi SDK; no separate global `pi` installation is
 required. On first launch, it creates a `Default` isolated account. Use `/accounts` to sign in.
 
+On Windows the shell tool works without extra setup: it uses Git Bash when Git for Windows is
+installed and PowerShell otherwise. Windows has no sandbox the harness can use to keep commands
+inside the project, so each command asks for approval unless Full Permission is on, and plan mode
+does not run commands. File edits work as usual.
+
 Provider sign-in progress lives in the running Harness process. An embedding application can call
 `accounts.loginStatus` after reconnecting to recover the current device code or prompt by account;
 the status carries a revision so it can be safely merged with streamed login events. Progress is
@@ -517,6 +522,6 @@ A host providing its own browser tools sets `browser: false` on `createHarness`
 generic backend and prevent tool-name collisions. The desktop App uses this for shared tabs.
 The default standalone Harness keeps its isolated browser backend enabled.
 
-See the [1.2.0 release notes](docs/releases/1.2.0.md), [1.1.1 release notes](docs/releases/1.1.1.md),
-and the [release procedure](docs/releases/README.md). Publication requires pre-tag review of the exact candidate, two-OS CI, a separate protected
+See the [1.3.0 release notes](docs/releases/1.3.0.md), [1.2.0 release notes](docs/releases/1.2.0.md),
+[1.1.1 release notes](docs/releases/1.1.1.md), and the [release procedure](docs/releases/README.md). Publication requires pre-tag review of the exact candidate, two-OS CI, a separate protected
 `npm-publish` approval, registry verification, and npm provenance.