@xingular/harness 1.1.1 → 1.3.1-unstable.0

package/CHANGELOG.md

@@ -1,5 +1,53 @@
 # 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.
+- Let plan mode run Bash in a read-only OS sandbox (no writes except a discarded temp folder, no network, nothing that widens it), so plans can check claims with commands such as `git log` (PROP-0043).
+- Make plan mode evidence-grounded and allow bounded read-only research delegation. Rehydrate the active checklist and plan instructions after compaction, and retain the latest subagent status until the next run.
+- Give plugin-owned terminal commands stable owner namespaces and make Harness-owned routes first-class core commands. Prior command forms remain hidden compatibility aliases for one release; update scripts and keybindings to canonical routes.
+- Extend page annotations into open shadow roots while preserving existing document-only annotation targets. Closed shadow roots and frames remain unsupported.
+- Record each run's resolved workspace root as an additive run-record field; older records remain readable.
+- Add a searchable saved-session picker and composer history for user prompts, Bash commands and executed slash commands, restoring the draft, cursor, mode and attachments while browsing. Fix compact question-dock sizing/scrolling and narrow-page footer rendering.
+- 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
 
 The first published release of the 1.1 line, and npm `latest`. It follows the 1.0.0 baseline; earlier 2.x–4.x numbers keep their existing meaning and are not reused. The 1.1.0 tag was pushed, but its release run stopped before publishing, so nothing was published under 1.1.0. This release carries the same changes, plus the release-pipeline fixes below.

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.
@@ -161,7 +161,8 @@ working folder brings.
   and `editor` become the run's question events; `notify`, `setStatus` and `setWidget` become
   `extension.notice` run events. What needs a terminal (custom components, key handlers, themes)
   does nothing. A tool an extension registered is offered to the model and asks before every
-  call. A command it registered runs when a message starts with it.
+  call. A terminal command runs as `/<owner-prefix>:<command>`; package extensions use their
+  normalized package name, or an optional `harness.commandPrefix` from `package.json`.
 - **The gate runs last.** In an SDK session it is an inline extension, loaded after those on
   disk. A terminal retains its final prepared `--extension` bridge argument; the owned frontend
   loads that bridge as the final trusted inline factory. A plugin that changes a tool call's
@@ -271,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
@@ -304,29 +310,29 @@ worktree: a detached checkout under `<state dir>/worktrees/` that carries your u
 changes, copies ignored files named in `.worktreeinclude`, and runs the repository's
 `.xharness/worktree-setup` once you trust it (`xagent worktree trust-setup`). The 15 most recent
 managed worktrees per repository are kept; older ones are pruned, and unsaved work is kept as a
-snapshot you can restore. `/plugin:worktree` in a session, `xagent worktree <command>` in a shell, and
+snapshot you can restore. `/worktree` in a session, `xagent worktree <command>` in a shell, and
 the `worktrees.*` server methods offer the same actions: new, switch, create branch, hand off to
 or from the main checkout, remove, restore, prune and adopt. An application passes a worktree's id
 as `run.worktreeId` and the session works in it. See
 [PROP-0016](docs/architecture/proposals/PROP-0016-managed-worktrees.md).
 
-### Page notes
+### Web annotations
 
-`/plugin:annotate [url]` opens a visible capture browser (its own window and profile, separate from the
-agent's browser). Note the whole page, select a passage, or click an element there, then write the
-note in the terminal. `/plugin:notes` lists, edits, resolves, reveals and deletes notes. A note is private
+`/annotate:` (or `/annotate:annotate [url]`) opens a visible capture browser (its own window and profile, separate from the
+agent's browser). Annotate the whole page, select a passage, or click an element there, then write a
+comment in the terminal. `/annotate:notes` lists, edits, resolves, reveals and deletes annotations. An annotation is private
 until you share it with the session; its agent then reads it with `page_notes_list` and
-`page_notes_read`, with quoted page text marked untrusted. Notes live in `<data root>/annotations/`
+`page_notes_read`, with quoted page text marked untrusted. Annotations live in `<data root>/annotations/`
 and the `annotations.*` server methods give a host the same store. A host with its own web view
 runs the same page helper (`annotations.pageScript`). See
 [PROP-0017](docs/architecture/proposals/PROP-0017-page-annotations.md).
 
-`/plugin:annotate` turns this into an inspector:
+`/annotate:` opens the inspector:
 - Hover a component in the browser or an app window, click it, and write a comment in the popover.
 - Then keep it as a note, add it to the agent's queue, or send it now. The agent reports back with `page_notes_mark_fixed`.
 - App windows work two ways:
-  - **DevTools port:** start an Electron app with `--remote-debugging-port=9229` and run `/plugin:annotate --app 9229`.
-  - **Page bridge:** for a macOS web view such as Tauri, run `/plugin:annotate --bridge` and load the script tag it shows while developing the app. Allow `http://127.0.0.1:<port>` in the app's `script-src` and `connect-src`.
+  - **DevTools port:** start an Electron app with `--remote-debugging-port=9229` and run `/annotate:annotate --app 9229`.
+  - **Page bridge:** for a macOS web view such as Tauri, run `/annotate:annotate --bridge` and load the script tag it shows while developing the app. Allow `http://127.0.0.1:<port>` in the app's `script-src` and `connect-src`.
 - A host drives the same flow with `annotations.capture.*`, and sends to its own sessions with `annotations.compose` and `annotations.delivered`.
 
 See [PROP-0018](docs/architecture/proposals/PROP-0018-annotation-queue-and-app-targets.md).
@@ -346,9 +352,13 @@ Pi supplies the persistent execution runtime, native history and rich content co
 existing isolated account, compiled context, approval gate, telemetry and Wiki/socket commands
 remain behind the terminal. No Pi `InteractiveMode` is constructed.
 
-Core terminal commands stay unprefixed. Built-in and Pi extension plugin commands use
-`/plugin:<command>`; for example, annotate a page with `/plugin:annotate https://example.com`.
-Old unprefixed plugin command forms are no longer aliases.
+Harness terminal commands stay unprefixed: `/doctor`, `/worktree`, `/trajectory`, `/subagents`,
+`/agents`, and `/mcp`. `/history` continues to navigate session branches. These commands are
+registered independently of feature-plugin command metadata. Other plugin-owned commands use
+`/<owner-prefix>:<command>`; for example, annotate a page with `/annotate:annotate
+https://example.com`, or open the default annotation pane with `/annotate:`. Former owner-qualified
+and `/plugin:<command>` routes for promoted Harness commands remain hidden compatibility aliases for
+one release; help and completion show only canonical forms.
 
 `/resume` stays inside the prepared account history and working folder. Cancel an active response
 before changing or reloading a session. Full OMP visual parity is not established by the current
@@ -363,10 +373,10 @@ To keep an existing message and attachments, open Ctrl+K, choose Skills, then Us
 Variant inspection distinguishes the pinned session version from the latest saved version.
 Adding a library skill or rule creates a validated version for future sessions.
 
-`/accounts`, `/permissions`, `/settings`, `/plugin:trajectory` and `/log` retain their own centered pages.
+`/accounts`, `/permissions`, `/settings`, `/trajectory` and `/log` retain their own centered pages.
 `/permissions` reviews device-local Pi terminal grants and the Full Permission switch; tool grants
 apply across terminal sessions sharing this Harness state, and Full Permission requires confirmation.
-`/plugin:trajectory` opens recorded runs for the current native conversation,
+`/trajectory` opens recorded runs for the current native conversation,
 with event navigation and a detail inspector. `/log` shows a static, redacted snapshot of Harness
 diagnostics and run events for the current conversation; press Escape to close. See
 [terminal architecture and evidence](docs/terminal-tui.md),
@@ -496,24 +506,22 @@ omit this option retain the existing lifecycle and direct-write contract.
 
 ## Readiness diagnostics
 
-Use `/plugin:doctor` in the terminal for local readiness checks and explicitly selected live probes. The same
+Use `/doctor` in the terminal for local readiness checks and explicitly selected live probes. The same
 structured jobs are available through `harness.doctor` and `doctor.*` server methods. See
 [Doctor](docs/doctor.md) for coverage, consent, isolation, and provider callbacks.
 
-## Public 4.0.0 release candidate
+## Public package
 
-The public package is ESM: import from `@xingular/harness` or supported subpaths such as
+The package is ESM: import from `@xingular/harness` or supported subpaths such as
 `@xingular/harness/variant/seed`. JavaScript and declarations are shipped in `dist/sdk`; a
-TypeScript loader is not required. Node 22.19 or later is required. The interactive terminal
-also requires Bun (release builds use 1.4.2); the CLI reports its version with `xagent --version`.
+TypeScript loader is not required. Node 22.19 or later is required. The interactive terminal also
+requires Bun (release builds use 1.4.2); the CLI reports its version with `xagent --version`.
 Original project code is Apache-2.0. See LICENSE, NOTICE.md and THIRD_PARTY_LICENSES.md.
 
 A host providing its own browser tools sets `browser: false` on `createHarness` to disable the
 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.
 
-This additive release follows the published 1.0.0 baseline, which intentionally reset development
-numbering while preserving older published versions. See [4.0.0 release notes](docs/releases/4.0.0.md),
-[1.0.0 release notes](docs/releases/1.0.0.md), and the [release procedure](docs/releases/README.md).
-Publication requires registry verification, green CI on supported operating systems, and approval of
-the exact candidate and tag push.
+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.