@xingular/harness 1.0.0 → 1.1.1

package/docs/decisions/ADR-0027-connected-sketch-display.md

@@ -0,0 +1,60 @@
+---
+id: ADR-0027
+title: Project structural ASCII sketch lines into connected terminal borders
+status: accepted
+created: 2026-10-24
+updated: 2026-10-24
+related: [PROP-0026, ADR-0026, ADR-0029, INV-RUN-3, INV-PAR-1, INV-PAR-2]
+supersedes: null
+superseded_by: null
+---
+
+# ADR-0027 — Project structural ASCII sketch lines into connected terminal borders
+
+**Design accepted by the product owner on 2026-10-24** with “yes, fix it” after screenshot review.
+This foundation presentation change is implemented and verified in isolated production fixtures;
+see [retained evidence](../evidence/terminal-connected-sketches/README.md).
+
+## Context
+
+ASCII `+|-` table frames appear disconnected in the terminal, and bare hyphen dividers do not
+reach the preview frame. ADR-0026's absolute literal-render promise prevents correcting those
+structural lines without a documented exception. Raw ASCII persistence and shared host metadata
+remain appropriate; the problem is terminal typography, not the question contract.
+
+## Decision
+
+Adopt [PROP-0026](../architecture/proposals/PROP-0026-connected-sketch-display.md). The terminal
+preview in `src/terminal/opentui/sketchPanel.ts` uses a bounded structural display projection:
+
+- Recognized ASCII table-border rows and enclosed vertical table edges become connected
+  box-drawing glyphs. Internal framed tables retain their original widths and positions.
+- Bare standalone hyphen divider rows expand to the larger of the panel viewport width and the
+  original sketch's widest line, joining the outer single-line preview frame with `├` and `┤`.
+- No global substitution: prose, content operators and ordinary pipes remain literal. Unrecognized
+  rows remain literal. Whitespace and geometry remain unchanged except for recognized structural
+  border glyphs and standalone-divider expansion, subject to the high-confidence boundary-cell
+  repair separately specified by [ADR-0029](ADR-0029-normalized-question-wireframe-borders.md).
+- Keep bounded two-axis panning, with no wrapping, reflow, truncation or markup interpretation.
+  Focus, selection, navigation and answers do not change.
+
+The validated source remains at most 80 printable ASCII columns by 24 lines. Persist that source
+literally, including whitespace; never save projected Unicode or divider expansion. No wire/schema
+or answer change is introduced. Hosts may retain literal previews of the same source. INV-PAR-1/2
+require equivalent capability and accepted metadata, not identical structural typography.
+
+## Consequences
+
+This amends only ADR-0026's terminal literal-render requirement and cross-surface typography
+promise; its bounds, raw persistence, layout and answer decisions remain in force. No migration or
+host code change is needed. Reverting the display projection does not affect saved events.
+Historical decisions and verification evidence remain unchanged.
+
+## Verification status
+
+The [PROP-0026 verification](../evidence/terminal-connected-sketches/README.md) covers structural
+recognition, content preservation, four terminal sizes, resizing/panning, original ASCII persistence
+and unchanged answers, alongside Harness and host checks. The later [ADR-0029 verification](../evidence/terminal-wireframe-normalization/README.md)
+covers title-bearing rules and bounded repair of missing or displaced frame edges. Prior PROP-0025
+evidence remains a record of the old presentation. Fixture verification is not owner visual
+acceptance, an every-font guarantee or evidence of live-model diagram quality.

package/docs/decisions/ADR-0028-xingular-agent-product-identity.md

@@ -0,0 +1,56 @@
+---
+id: ADR-0028
+title: Use Xingular Agent as the default Harness product identity
+status: accepted
+created: 2026-10-24
+updated: 2026-10-24
+related: [PROP-0027, INV-BND-2, 00-overview.md, 04-prompt.md, 11-terminal.md]
+supersedes: null
+superseded_by: null
+---
+
+# ADR-0028 — Use Xingular Agent as the default Harness product identity
+
+The product owner accepted [PROP-0027](../architecture/proposals/PROP-0027-xingular-agent-product-identity.md)
+on 2026-10-24.
+
+## Context
+
+The standalone terminal is Harness-owned, but its welcome and Harness-authored prompt identity used
+the default product name `Xingular Harness`. The requested product identity is `Xingular Agent`,
+with a terminal welcome that presents an orange `X` mark and blue `A G E N T` label. Changing the
+default affects product identity text beyond the welcome, including compiled prompts and Wiki text;
+embedding hosts may need their own name.
+
+## Decision
+
+Adopt PROP-0027:
+
+- Set `DEFAULT_PRODUCT_NAME` to `Xingular Agent`; continue honoring an explicit `productName` from
+  an embedding host.
+- Revise `INV-BND-2` to permit the exact canonical product identity `Xingular Agent` as the
+  default. Continue to prohibit application concepts, application-specific behavior and other
+  application names in Harness code and person/model-visible text.
+- Format a multiword product name in the empty welcome as the first letter of its first word in the
+  orange block mark and the remaining word(s), letter-spaced, in blue. Thus the default shows `X`
+  and `A G E N T`. A single-word name remains the mark without a subline.
+- Keep the centered greeting, tagline, `/help` hint, model/thinking status, composer and status bar;
+  use the existing orange and blue theme accents without adding tokens or changing other surfaces.
+
+## Consequences
+
+- Consumers that omit `productName` see `Xingular Agent` in Harness-authored product identity
+  text. Consumers that supply their own name are unchanged.
+- Existing prompt packs, runs and Wiki notes are not rewritten; newly compiled prompt identity and
+  new Wiki text use the default in effect at creation time.
+- No capability, API, storage layout or wire schema changes.
+
+## Verification status
+
+Implemented and verified on 2026-10-24.
+
+- Harness: `npm run typecheck`, `npm test` (143 files passed; 3 skipped), `npm run build`, and
+  `npm run prove` passed. Focused PTY verification passed at 40x20, 80x24 and 120x40, including
+  the `/help` transition.
+- Xingular Agent: `npm run typecheck`, `npm test` (566 renderer and 67 sidecar tests passed),
+  `npm run check:layers`, and `cd src-tauri && cargo test` passed.

package/docs/decisions/ADR-0029-normalized-question-wireframe-borders.md

@@ -0,0 +1,33 @@
+---
+id: ADR-0029
+title: Normalize high-confidence question wireframe borders in the terminal preview
+status: accepted
+created: 2026-10-24
+updated: 2026-10-24
+related: [PROP-0028, ADR-0026, ADR-0027, INV-PAR-1, INV-PAR-2]
+---
+
+# ADR-0029 — Normalize high-confidence question wireframe borders in the terminal preview
+
+## Context
+
+The terminal displays bounded, model-authored ASCII sketches. The existing connected-glyph projection misses text-bearing top rules and rows with missing or misaligned side edges. The raw source remains the right shared contract, but its terminal display needs a narrowly constrained frame-repair rule.
+
+## Decision
+
+Adopt [PROP-0028](../architecture/proposals/PROP-0028-normalize-question-wireframes.md). The terminal may normalize only high-confidence, explicitly framed sketch boundaries:
+
+- Recognize title-bearing border rows and establish outer columns from matched frame rules.
+- Align a boundary character only across whitespace, or fill a missing boundary cell only where it is whitespace.
+- Preserve interior text, nested frame geometry, ambiguous rows, and ordinary content literally; no global symbol replacement.
+- Keep the source ASCII byte-for-byte in persistence and retain the existing question schema, answer payload, viewport and panning behavior.
+
+Hosts may continue rendering the same source literally. This decision changes terminal typography only; it adds no capability or host contract.
+
+## Consequences
+
+A valid framed sketch can display connected corners and continuous vertical edges even when its source omitted or misplaced a boundary glyph. Repairs are projection-only and deliberately conservative; ambiguous or content-conflicting rows remain untouched. No migration is required.
+
+## Verification
+
+Use structural unit fixtures and isolated production PTY runs at compact and wide terminal sizes. Verify the displayed topology, panning/resizing, and byte-for-byte source and answer preservation. This does not claim that every emulator/font renders box glyphs identically or that live-model sketches always describe the intended design.

package/docs/decisions/ADR-0030-agent-profiles.md

@@ -0,0 +1,43 @@
+---
+id: ADR-0030
+title: Agent profiles, one checklist per agent, and the subagent roster under the status line
+status: accepted
+created: 2026-10-24
+updated: 2026-10-24
+related: [PROP-0029, PROP-0006, ADR-0003, INV-RUN-2, INV-CAP-1, INV-PAR-1]
+---
+
+# ADR-0030 — Agent profiles, one checklist per agent, and the subagent roster under the status line
+
+## Context
+
+People want to start subagents of a known kind, such as a worker that edits and an explorer that
+only reads, and to follow their progress from the terminal. Subagents were copies of the parent
+or instruction-only c5 definitions, the terminal did not register the checklist tool, and the
+roster sat above the composer with a heading and no indication of each child's kind or progress.
+
+## Decision
+
+- Adopt [PROP-0029](../architecture/proposals/PROP-0029-agent-profiles.md): agent profiles are
+  Markdown files (built-in, `<data root>/agents/`, `<project>/.xingular/agents/`, then c5 names)
+  that a spawn resolves by name. A profile narrows tools and plugins and may choose a variant,
+  model and effort. It never widens the parent's capabilities.
+- Progress stays **one checklist per run** (PROP-0006). The parent's list is the plan the person
+  watches. Each child keeps its own list, and the roster shows its `n of m tasks`. There is no
+  shared, claimable task pool.
+- The terminal registers `checklist_write`, shows each write as a checklist block, and the prompt's
+  Progress group asks the model to keep it current because the person follows work from it.
+- The roster sits under the status line after one blank line, with no heading. Each row reads: status
+  mark, profile name in its colour, session name, tasks.
+
+## Consequences
+
+Profiles are a foundation feature, not variant data: refinement does not change them. A project
+can carry profiles in its repository. The App gets the same capability through `agents.*` and
+`RunRecord.profile`; it has no Agents screen yet (parity `planned`).
+
+## Verification
+
+Unit tests for profiles, narrowing, spawn, the monitor, the roster and the Agents page;
+`npm run prove`; and a loopback PTY run that checks the blank row under the status line, the row
+order, and the profile colours.

package/docs/doctor.md

@@ -15,11 +15,17 @@ domain”. MCP checks connect/list only. Browser checks use a disposable headles
 offline synthetic page; configured CDP attachment is blocked. Computer input is blocked unless the
 host supplies a disposable diagnostic surface; the current desktop host supplies readiness only.
 
+The report keeps mode, progress, account/model and status counts visible above the findings. Wide
+layouts use aligned Status, Check, Category and Verification columns; evidence and any next step
+appear beneath each finding. Narrow layouts stack those fields. Status colors follow the active
+theme: pass is green, warning/blocked amber, fail red, disabled dim and unverified muted.
+
 `r` refreshes local readiness, `t` retries a selected local check, `c` cancels, and Escape closes
-and cancels pending work. Completed findings survive cancellation. Every finding includes evidence
-and, where useful, a next step. Doctor never signs in, switches accounts, installs, grants access,
-or repairs settings. Findings and jobs are retained in memory until shutdown; live run records
-and usage remain in normal Harness storage.
+and cancels pending work. Use Up/Down to scroll by line, PgUp/PgDn or the mouse wheel to scroll by
+page, and Home/End to jump to the first/last finding. Completed findings survive cancellation. Every finding includes
+evidence and, where useful, a next step. Doctor never signs in, switches accounts, installs, grants
+access, or repairs settings. Findings and jobs are retained in memory until shutdown; live run
+records and usage remain in normal Harness storage.
 
 ## Embedding
 

package/docs/features/README.md

@@ -16,5 +16,31 @@ binding and defines the contracts and invariants.
 | Integrations | Application extension points, plugins, connected apps and Hub | [Integrations](integrations/README.md) |
 | Interfaces | Node embedding, standalone terminal and JSON-lines server | [Interfaces](interfaces/README.md) |
 
+## Built-in plugin ownership
+
+PROP-0020 groups Harness-managed feature plugins by responsibility. These labels are an architecture
+taxonomy only; they are not runtime plugin categories or public metadata. Foundation-owned
+infrastructure remains the security and lifecycle boundary around each feature.
+
+| Category | Features |
+|---|---|
+| Foundation | Accounts, sessions, run recording, prompt/variant validation, gate, plugin loading/trust/attachments, resource browser, server and terminal framework |
+| World | Web tools, browser tools and page annotations; generic isolated browser engine stays in Foundation |
+| Memory | Wiki, history and trajectory |
+| Automation | Subagents, ask-user, checklist, lessons and refinement |
+| Integrations | Connected apps/MCP and Hub |
+| Operations | Doctor and worktrees |
+
+See [06 Plugins and capabilities](../architecture/06-plugins-and-capabilities.md#built-in-ownership-taxonomy-prop-0020) for the binding ownership boundary.
+
+## Planned: Agent Modes
+
+An **Agent Mode** selects one overall work style at a time; plugins remain stackable strategies and
+contributions. The first planned mode is **Router Agent Mode**: the user works through one continuous
+chat and browser experience with a router agent that proactively plans, delegates across persistent
+subagent threads, and receives their messages. This is a future direction, not an implemented
+capability. See [FW-0001](../future-work.md#fw-0001-agent-modes-starting-with-router-agent-mode) for
+the backlog entry and required architecture decisions.
+
 **Harness Variant (HV)** is the short name used in these feature pages. The architecture
 specification uses the canonical term *variant*.

package/docs/features/interfaces/README.md

@@ -17,7 +17,7 @@ for host-provided extension points.
 
 ## Standalone terminal
 
-`xharness` provides the Harness-owned OpenTUI terminal over a persistent Pi session. An embedding
+`xagent` provides the Harness-owned OpenTUI terminal over a persistent Pi session. An embedding
 application may host the terminal in its own PTY; the Harness owns the terminal UI and session
 behavior, while the host owns PTY and process supervision.
 

package/docs/future-work.md

@@ -0,0 +1,48 @@
+# Future feature backlog
+
+This backlog records candidate directions. An entry here does not change the binding architecture,
+approve implementation, or describe an available feature. A change to an architecture contract,
+invariant, layer boundary, extension point, or storage layout still requires a reviewed proposal.
+
+## FW-0001: Agent Modes, starting with Router Agent Mode
+
+**Status:** Candidate; future architecture proposal required before implementation.
+
+### Concept
+
+An **Agent Mode** selects one overall work style, with only one mode active at a time. Plugins remain
+stackable strategies and contributions that can be used within a mode; they do not select the
+agent's overall work style.
+
+The first planned mode is **Router Agent Mode**. The user interacts with one user-facing agent through
+one continuous chat and browser experience. That router proactively plans and delegates work across
+persistent subagent threads, receives their messages, and coordinates the overall work while the user
+can continue sending messages.
+
+### Intended ownership
+
+This is intended as a Harness foundation capability. The current architecture describes subagents as
+child runs and assigns persistent teams, broader orchestration, and the application's shared UI to
+the embedding application ([02 Sessions and runs](architecture/02-sessions-and-runs.md), [feature-gap
+review](study/feature-gap-review.md)). This backlog entry proposes revisiting that boundary; it does
+not change it.
+
+### Decisions required before a proposal
+
+- Define the mode selection scope and lifetime, including how one active mode applies to sessions,
+  runs, and child agents.
+- Define persistent subagent thread identity, history, communication, delegation, recovery, and
+  resource limits while preserving the run's account, variant, capability, and gate guarantees.
+- Define how the router receives worker messages and incorporates them while accepting continued
+  user input in one conversation.
+- Define how the single chat and browser experience maps to the Harness terminal, server protocol,
+  and embedding hosts, including which UI responsibilities remain with the host.
+- Identify the storage, run-event, and public API changes needed to support the mode and migrate or
+  coexist with current run-scoped subagents.
+
+### Next step
+
+When implementation is scheduled, write a formal architecture proposal from the proposal template,
+identify every affected contract and invariant, and obtain acceptance before changing code or binding
+specification pages. Record a lasting accepted architecture choice in an ADR. Until then, Agent Mode
+and Router Agent Mode are planning terms only; no runtime behavior or public interface is implied.

package/docs/parity.md

@@ -0,0 +1,78 @@
+# Capability parity register
+
+**Status:** descriptive register, as of 2026-10-24. The binding rules are
+[14 Surfaces and parity](architecture/14-surfaces-and-parity.md) (`INV-PAR-1`–`INV-PAR-4`).
+
+Every capability a person can use is a Harness capability. The standalone terminal (`xagent`)
+is the reference front end; a host such as the App presents the same capabilities with a richer
+UI. This page lists each capability, where the Harness owns it, how each front end shows it, and
+whether both pass. A gap has an ID (`PAR-NNN`) until it is closed.
+
+Host-only surfaces (presentation a terminal cannot show, `INV-PAR-4`) are not listed here; each
+host keeps its own register. The App's is
+[`App/docs/architecture/app-only-surfaces.md`](../../App/docs/architecture/app-only-surfaces.md).
+
+Status: **parity** (both surfaces pass), **terminal only**, **host only** (a gap), **planned**,
+**host-backed** (needs a host object; terminal fallback named).
+
+## Register
+
+| Capability | Harness owner | Method or tool | Terminal surface | App surface | Status | Gap |
+|---|---|---|---|---|---|---|
+| Sessions and turns | `sessions/` | `sessions.run`, `terminal.*` | the terminal itself | Solo chat | parity | — |
+| Plan mode | `sessions/planMode.ts` | `plan: true` | `/plan`, Shift+Tab, plan card | plan request, PlanCard | parity | — |
+| Bash command mode | `sessions/sessions.ts` | `initialBashCommand` | `!command` | `!command` in the composer | parity | — |
+| Side questions | `sessions/sideQuestions.ts` | `sideQuestions.start/read/interrupt`; terminal `terminal.sideQuestions.*` | `/btw` contextual dock with scroll and copy | side-question dock through the shared service | parity | — |
+| Approvals and standing approvals | `sessions/approvals.ts` | `approvals.*` | decision dock, `/permissions` | approvals dock, settings | parity | — |
+| Questions (`ask_user`) | `tools/askUser.ts` | `ask_user`; terminal `ask_user_question` | plan-mode dock: strict aligned columns, bounded body scroll, 80×24 source sketch viewport; connected structural projection with high-confidence boundary normalization (PROP-0026, PROP-0028) | plan-mode form accepts the same 80×24 ASCII source contract with literal preview and accessible overflow; no typography change required | parity; terminal projection verified in isolated fixtures | — |
+| Subagents | `sessions/subagentService.ts` | `spawn_subagent` (requires `title`, PROP-0030), `subagents.*` | `/subagents` page and live rows under the status line (mark, profile, parent-set title, `n of m tasks`) | reply trajectory | parity | — |
+| Agent profiles | `agents/profiles.ts` | `spawn_subagent { agent }`, `agents.list/get/create/remove`; terminal `terminal.agents.*` | `/agents` page: browse, create, edit in `$EDITOR`, copy, delete | not shown; `RunRecord.profile` available | terminal done; App planned | PAR-010 |
+| Run checklist | `tools/checklist.ts` | `checklist_write`, `runs.checklist`; terminal `checklist` telemetry | registered in terminal sessions and their subagents; each write shows as a checklist block in the transcript; a subagent row shows its `n of m tasks` | not shown | terminal done; App planned | PAR-001 |
+| Continuation of a stopped run | `sessions/continuation.ts` | `continueFrom`, `runs.continuation` | not offered (`/resume` reopens history only) | not offered | planned | PAR-003 |
+| Accounts | `accounts/` | `accounts.*` | `/accounts` | Accounts | parity | — |
+| Models and effort | `accounts/choices.ts` | — | `/model`, `/effort` | composer pickers | parity | — |
+| Skills | `plugins/`, `tools/dispatch.ts` | `skill_load` | `$name`, `/skill:name`, browser Skills tab | Capability, composer | parity | — |
+| Plugins and Hub | `plugins/`, `hub/` | `plugins.*`, `hub.*` | resource browser | Capability | parity | — |
+| Connected apps (MCP) | `mcp/` | `connections.*`, broker tools | resource browser Connections tab | Connections | parity | — |
+| Web search and page reading | `web/` | `web_search`, `web_fetch` | world tools | world tools | parity | — |
+| Isolated browser | `browser/` | `browser_*` | world tools, headed on request, `/settings` Browser tab | App WebKit tabs (host-backed) | host-backed | — |
+| Page annotations | `annotations/` (PROP-0017, PROP-0018) | `annotations.*`, `annotations.capture.*`, `page_notes_*` | `/plugin:annotate` pane (inspector, queue, app windows over DevTools or the page bridge), `/plugin:notes` | website tab Annotate panel (inspector, queue to the focused thread, app windows through `annotations.capture.*`) | parity in the working tree; native WKWebView gestures unaccepted | PAR-011 |
+| Managed worktrees | `worktrees/` (PROP-0016) | `worktrees.*` | `--worktree`, `/worktree`, `xagent worktree` | working group **Create worktree** (`worktrees.create`) | partial | PAR-012 |
+| Wiki notes (model tools) | `wiki/`, `tools/` | `wiki_*` | `xagent-wiki` shell command only | tools | host only | PAR-002 |
+| History and trajectory (model tools) | `history/` | `history_*`, `trajectory_*` | shell command, `/trajectory` page | tools, trajectory views | host only | PAR-002 |
+| Wiki browsing | `wiki/` | `wiki.*` | none | Wiki | host only | PAR-005 |
+| Variants and refinement | `variant/`, `refine/` | `harnesses.*`, `refine.*` | browser Variant tab (read-only), `xagent refine` | Harness screen | host only | PAR-004 |
+| Output trim and budget guard plugins | `plugins/firstParty.ts` | — | not loaded in terminals | loaded | host only | PAR-006 |
+| Doctor | `doctor/` | `doctor.*` | `/doctor` | diagnostics | parity | — |
+| Run inspection | `sessions/runStore.ts` | `runs.*` | `/trajectory`, `/log` | run views, analytics | parity | — |
+| Session catalog (sessions per folder) | — | — | per-folder history | Solo thread list | planned | PAR-008 |
+| Folder choice and recent folders | `core/projects.ts` | — | launch folder only | working groups | planned | PAR-009 |
+| Computer control | — | `computer_*` (host tools) | unavailable, with reason | macOS bridge (host-backed) | host-backed | PAR-007 |
+| Shared files vault | — | `files_*` (host tools) | none | Files | host only | PAR-007 |
+
+The terminal-only display amendments [PROP-0026](architecture/proposals/PROP-0026-connected-sketch-display.md)
+and [PROP-0028](architecture/proposals/PROP-0028-normalize-question-wireframes.md) permit connected
+structural glyphs, frame-attached standalone dividers, and high-confidence boundary normalization
+through whitespace while retaining literal ASCII persistence and unchanged answers. The App may
+keep its literal preview. This does not reopen the expanded metadata contract verified under
+PAR-013. Isolated production PTY evidence verifies bounded fixture topology, not every emulator/font
+or live-model sketch quality.
+
+## Gaps
+
+| ID | Gap | Planned change |
+|---|---|---|
+| PAR-001 | Checklist absent from the App | The terminal registers the tool and renders a checklist block; the App renders it too. |
+| PAR-002 | Wiki, history and trajectory reach terminal models only through a shell command | Register the harness tools in terminal sessions; retire the shell commands (drift D-4). |
+| PAR-003 | Continuation unused | `/resume` lists interrupted runs and continues one with `continueFrom`; the App offers Continue. |
+| PAR-004 | Refinement and adoption only in the App | Variant tab actions: start, candidates, adopt, trust. |
+| PAR-005 | Wiki browsing only in the App | A `/wiki` page over `wiki.*`. |
+| PAR-006 | First-party hook plugins not loaded in terminals | Load them through the terminal's trusted selection. |
+| PAR-007 | Host tools without a Harness owner | Decide each: computer control stays host-backed (terminal shows unavailable); the files vault becomes a Harness capability or is dropped. |
+| PAR-008 | Separate session catalogs | A Harness session catalog per folder, read by both front ends (needs a proposal). |
+| PAR-009 | Folder choice | Built on PAR-008: recent folders in both front ends. |
+| PAR-010 | Agent profiles absent from the App | An Agents screen over `agents.*`, and the profile name and colour on subagent rows (PROP-0029). |
+| PAR-011 | Page annotations | Harness, terminal and App source done (PROP-0017, PROP-0018, 2026-10-24): the App calls `annotations.*`, imports its old notes once, uses the `page_notes_*` tools, and has the Annotate panel. Open: acceptance of the inspector and selection gestures in the running App's WKWebView. |
+| PAR-012 | Managed worktrees | Harness and terminal done (PROP-0016). The App creates through `worktrees.create`; its groups do not yet offer hand off, prune, restore or managed worktrees per thread. |
+| PAR-014 | Connected terminal sketch display | Closed by [PROP-0026 verification](evidence/terminal-connected-sketches/README.md) and extended by [PROP-0028 verification](evidence/terminal-wireframe-normalization/README.md): production PTY fixtures cover connected corners/tees, title-bearing rules, missing and whitespace-shifted side edges, internal table widths, frame-attached dividers, resize/panning and unchanged raw persistence/answers. Harness and host checks passed. Host literal rendering remains permitted; no host implementation change was required. This is fixture verification, not an every-font or live-model guarantee. |
+| PAR-013 | Expanded question wireframes and terminal layout | Closed by [PROP-0025 verification](evidence/terminal-question-wireframes/README.md): four-size production PTY acceptance covers aligned compact columns, body scrolling, pinned controls, Shift+arrow sketch panning and live resizing. Host contracts accept 80×24 literal ASCII sketches (1,943 bytes); six isolated browser tests include exact-boundary content, accessible overflow and unchanged selection/answers. This is controlled fixture acceptance, not live-provider or native Tauri evidence. |

package/docs/releases/1.0.0.md

@@ -2,8 +2,8 @@
 
 This release establishes @xingular/harness@1.0.0 as the stable baseline and retains the xharness
 command. It intentionally resets the earlier development numbering; historical tags and published
-versions remain unchanged. This document describes the candidate until registry publication is
-verified.
+versions remain unchanged. The npm registry published 1.0.0 as the stable baseline; this file
+remains its release notes.
 
 ## Included
 

package/docs/releases/4.0.0.md

@@ -0,0 +1,46 @@
+# Xingular Harness 4.0.0
+
+This major release builds on the published 1.0.0 baseline. It extends Harness-owned terminal
+surfaces and adds generic worktree and page-annotation capabilities; it also changes the built-in
+terminal command namespace, documented below. Earlier published versions remain available.
+
+## Included
+
+- Managed Git worktrees for sessions and the terminal, with leases, guarded setup scripts, handoff,
+  pruning, restoration, and bounded snapshots that preserve uncommitted work.
+- Page annotations and queued notes, including capture, review, resolution, sharing, and delivery
+  through Harness methods and terminal `/plugin:annotate` and `/plugin:notes` pages.
+- A unified terminal resource browser with persistent full-screen sections for browser tabs,
+  plugins, skills, connectors, variants, and other Harness resources.
+- A full-screen `/trajectory` Runs/Events browser with searchable event details, selected-event
+  JSON, and a responsive split-pane layout.
+- Additional terminal controls for browser settings, plugin settings, and subagent activity.
+- Fix Node 22 SQLite parameter binding in recall and run indexes, and guard worktree Git calls
+  against early child-process exits while writing input.
+- Updated architecture and parity documentation for Harness capabilities and their terminal and
+  host surfaces.
+
+## Installation and requirements
+
+Use `npm install --global @xingular/harness@4.0.0`, then `xagent`. Node 22.19 or later is required.
+The interactive terminal also requires Bun; release CI uses Node 22.19.0 and Bun 1.4.2. Browser
+operation requires an installed compatible browser or a deliberately configured endpoint. Model
+credentials are configured inside an isolated Harness account.
+
+## Compatibility
+
+The new server methods are additive. The published executable is `xagent`, replacing the earlier
+`xharness` candidate command without a compatibility alias; scripts using that candidate name must
+be updated. Required built-in plugin commands use unprefixed names:
+`/subagents`, `/trajectory`, `/doctor`, and `/worktree`. Optional built-in and third-party extension
+commands use `/plugin:<command>`; the optional page-annotation commands remain `/plugin:notes` and
+`/plugin:annotate`. Update scripts and keybindings that used the earlier candidate's prefixed forms
+for required commands. Existing session, variant, account, plugin, and browser contracts remain in
+place. Install this exact version or use the `latest` tag; historical versions remain available.
+
+## Verification scope
+
+The Harness CI suite, standalone proof, App typecheck/tests/layer check/Rust tests, and App UI
+consistency check must pass for the reviewed release candidate. The release tag workflow separately
+builds and smoke-tests the exact tarball on its supported operating systems before publishing it
+with npm provenance.

package/docs/releases/README.md

@@ -1,7 +1,8 @@
 # Release procedure
 
-1. Review and commit completed Harness changes on release/1.0.0. Review App compatibility changes
-   separately. Preserve old tags and exclude outputs, external references and caches.
+1. Review and commit completed Harness changes on the active release branch. Review App
+   compatibility changes separately. Preserve old tags and exclude outputs, external references,
+   and caches.
 2. Run npm run ci and the required App checks on unrestricted macOS/Linux runners. Install Bun
    1.4.2 and use Node 22.19.0 for the release build. Do not waive failing checks.
 3. Run npm run release:pack. The unique output folder contains the candidate tarball, inventory,
@@ -9,10 +10,11 @@
    dependency installation and packaged SDK/server/terminal checks. --offline reuses the checkout's
    installed dependency tree and is only a local smoke check, not fresh-install acceptance.
 4. Run npm run release:preflight. Verify npm scope ownership and trusted-publisher settings for
-   tanntnny/xingular-harness, workflow release.yml, direct publishing enabled. No login is started
-   automatically. Existing 1.0.0 or an unreachable registry blocks publication.
+   tanntnny/xingular-harness and workflow release.yml, with direct publishing enabled. No login is
+   started automatically. An already-used target version or unreachable registry blocks publication.
 5. Present the exact commit, candidate inventory/hash, notes and check results for approval. Pushing
-   v1.0.0 triggers publication; do not push the tag before this approval. Preserve historical tags.
+   the matching v<version> tag triggers publication; do not push it before this approval. Preserve
+   historical tags.
 6. After approval, push the reviewed commits and tag. The workflow runs both OS checks, packages
    and tests one candidate, then publishes that same tarball with OIDC provenance and --tag latest.
    No local publishing token is needed. It verifies registry integrity/provenance and creates a
@@ -22,15 +24,18 @@ A published version cannot be replaced. Corrections require a later version. Thi
 intentional 1.0.0 reset does not rewrite historical decisions or claim an ordering above older
 2.x–5.x development versions. Publication status and local evidence belong in the candidate report.
 
-## Current preparation evidence
+## 4.0.0 candidate preparation
 
-Local package inspection and the offline-dependency consumer smoke check pass. App compatibility
-checks pass (592 renderer tests, 40 sidecar tests, 240 Rust tests with one ignored, and type/layer/UI
-checks). A focused Harness run has 100 passing tests and the standalone proof passes. The full
-Harness run is blocked by sandbox IPC and native HEIC encoding restrictions. The public GitHub
-repository and absence of a remote v1.0.0 tag were verified through the connected GitHub service.
-The npm registry and trusted-publisher settings could not be verified from this environment.
+Local checks on the candidate source passed: Harness `npm run ci` (typecheck, 134 test files with
+1,004 passing tests and 3 skipped, plus the standalone proof); App typecheck, `npm test` (566 renderer
+tests, 47 sidecar tests, and 7 dev-signing tests passed with 1 skipped), layer check, and Rust tests
+(168 passed, 1 ignored); and App UI consistency. The registry lists 1.0.0 as `latest` and 4.0.0 as
+unused. The clean-tree release preflight passed. Exact-tarball packaging and a fresh-install smoke
+test passed, including the packaged SDK, types, CLI, server and isolated terminal. The tagged
+preflight, two-OS CI, and exact-tarball smoke are enforced by the release workflow. The npm
+trusted-publisher configuration for `tanntnny/xingular-harness` and `release.yml` requires
+package-owner verification; `npm login` does not verify that setting.
 
-The release branch must run unrestricted CI and a fresh-install smoke check before a release-tag
-approval is requested. Branch upload itself is a separate approval because it shares the source
-with GitHub and starts CI; it does not publish npm. No local test failure is waived by this note.
+The release workflow runs its full CI and exact-tarball smoke test on both Ubuntu and macOS before
+publishing. Branch upload and the matching release-tag push are separate GitHub side effects; only
+the tag triggers publication. No local test failure is waived by this note.

package/docs/study/00-index.md

@@ -11,6 +11,11 @@ written and the claim moves to checked behavior. Cite material as
 
 ## Focused notes
 
+- [Proactive autonomy and three feature directions](proactive-autonomy.md) — scheduled initiative,
+  a human-readable agenda, UI repair, cleanup and product experiments; fresh
+  [proactive-system evidence](autonomy-sources.md) and
+  [autonomous-engineering evidence](autonomous-engineering-sources.md). Research hypotheses,
+  not an accepted architecture change.
 - [`/btw` side-question comparison](btw-comparison.md) — this terminal, the App-owned
   side question, and checked-out external implementations.
 - [Harness feature-gap review](feature-gap-review.md) — task/goal management, long-running work,