@zhivex-ai/harness 1.1.1 → 1.2.0-rc.13

package/docs/ACP.md

@@ -0,0 +1,55 @@
+# Experimental ACP text sessions
+
+The harness provides an experimental Agent Client Protocol v1 **subset** for an editor or other local client: initialization, new sessions, text prompts, one-time permissions and cancellation. It runs over JSON-RPC 2.0, one JSON message per line on stdio.
+
+This is not full ACP conformance. In particular, ACP requires support for client-supplied stdio MCP servers; this adapter rejects them. Test compatibility with your editor before relying on it. The negotiation response marks the subset in `_meta.zhivex`.
+
+## Launch
+
+From a source checkout:
+
+```sh
+bun src/acp-cli.ts --workspace /absolute/project --provider openai --model YOUR_MODEL
+```
+
+After building:
+
+```sh
+node dist/acp-cli.js --workspace /absolute/project --provider openai --model YOUR_MODEL
+```
+
+Use existing host configuration flags and environment credentials. `--profile` loads an existing CLI profile. The service does not open interactive credential prompts. It writes only protocol messages to stdout; startup failures and help go to stderr. SIGINT, SIGTERM and closing stdin request cancellation and close the adapter and harness.
+
+The client must wait for each setup response:
+
+```json
+{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":1,"clientCapabilities":{}}}
+{"jsonrpc":"2.0","id":2,"method":"session/new","params":{"cwd":"/absolute/project","mcpServers":[]}}
+```
+
+Use the returned `sessionId` in subsequent `session/prompt` requests with `prompt: [{"type":"text","text":"Your task"}]`. Completed assistant text arrives as a `session/update` notification before the prompt response. This implementation buffers output until the durable run completes; it does not stream individual tokens or tool updates.
+
+## Permissions and cancellation
+
+A durable pending approval produces a `session/request_permission` request. The client can select only `allow_once` or `reject_once`, or return a cancelled outcome. The adapter translates that decision using the pending approval's exact ID, digest and run revision. The existing harness verifies expiration, revision and file digests before execution. Approval requests expose the pending action as `toolCall.rawInput`; clients should render that action for review.
+
+`session/cancel` is a notification. It stops an active run or pending permission request and returns the original prompt with `stopReason: "cancelled"`. Permission responses time out after 15 minutes and cancel the pending run. Closing the connection also cancels outstanding work. A cancellation does not undo effects already committed.
+
+Only one prompt executes at a time per connection. Other simultaneous prompts receive a busy error. Unknown sessions, stale approvals and invalid permission choices cannot authorize operations.
+
+## Supported boundary
+
+- Host owns the workspace, provider, model, credentials, policies and tools. `session/new.cwd` must match the configured workspace.
+- Text prompts only; no image, audio or embedded resources.
+- No client-provided MCP servers, client filesystem operations or client terminals.
+- No session load/resume, model switching, modes, or authentication protocol. Durable sessions remain accessible through existing harness interfaces.
+- Frames are limited to 1 MiB, prompts to 64 KiB, concurrent protocol handlers to 64 and sessions to 256 per connection. Oversized frames or handler floods terminate the connection and cancel work.
+- A transport connection should belong to a single trusted local client. This is not an unauthenticated network service.
+
+## Embedding
+
+Create the existing `createHarnessClientAdapter(harness)`, then call `createAcpConnection(adapter, { workspace, notify, requestPermission })`. Pass decoded requests into `handle`; route returned responses back to the client. `requestPermission(params, signal)` should cancel its pending client request when the signal aborts. Call `cancelActive()` before closing a connection. The host remains responsible for `adapter.close()` and `harness.close()`.
+
+`serveAcpStdio(adapter, { workspace, input, output })` supplies framing and permission-response correlation for Node readable/writable streams.
+
+Protocol references: [initialization](https://agentclientprotocol.com/protocol/v1/initialization), [session setup](https://agentclientprotocol.com/protocol/v1/session-setup), [prompt lifecycle and cancellation](https://agentclientprotocol.com/protocol/v1/prompt-turn), [permissions](https://agentclientprotocol.com/protocol/v1/tool-calls).

package/docs/CLI.md

@@ -72,6 +72,12 @@ Start with `zhx`. Use `/help` inside the conversation. For scripting, use `zhx r
 
 ### Interactive daily workflow
 
+The Focus layout keeps a single conversation column in terminal scrollback. Model
+and reasoning appear above the input, with approval state and selected attachments.
+An empty draft shows a muted task hint. Shortcuts sit below the complete draft,
+adapt to terminal width, and give way to command and history searches. Sending or
+cancelling removes these editor hints before model output or approval questions.
+
 The console opens with the Zhivex logo and a compact welcome panel. Project/model context sits beside the logo when space permits. Before each task, the composer shows the model, approval mode, pending approval state and attachment count. Long labels are bounded to the terminal width; full configuration remains available through `/status`. Type `/` to open the command menu; keep typing to search names and descriptions, use Up/Down to select, Tab to insert, and Enter to submit. Escape dismisses the menu. Enter on a partial command inserts its selection; a separate Enter submits it, including approval commands. Only commands supported by the connected runtime appear. Narrow terminals use a compact logo; `NO_COLOR` disables logo color. The console completes slash-command prefixes with Tab. `/paste` captures a bounded
 multiline draft: finish with `.end` on a separate line, review the preview, then type
 `send` at the separate confirmation prompt. Slash commands inside the draft remain
@@ -89,14 +95,17 @@ Ctrl+R searches that in-memory history. Type a filter, use Up/Down to choose, th
 Left/Right and Home/End edit the draft in the supported Node terminal runtime;
 resizing the terminal preserves it. Ctrl+C discards the current draft (including
 an unfinished paste), or cancels the active operation and returns after cleanup.
-During an operation, typed input is ignored without echoing over the stream.
+During an operation, typed input is retained as a background draft; Enter queues a
+literal task for the next turn. Draft previews appear in the transient activity line.
+Approval questions require fresh input and never consume the task queue.
 
 Text streams progressively, including partial lines during provider pauses. Activity,
 approval requests and completion remain separate labelled events. Partial output is
 flushed before errors or returning to the prompt, and terminal controls from the
 provider are escaped. After a provider error, Up recalls the submitted task for
-editing/retry; history stays in memory only. Markdown styling is best effort when
-a provider pauses inside markup; text is never replayed to restyle it.
+editing/retry; history stays in memory only. Markdown emphasis and inline code wait for a matching closing marker within a bounded
+span. Unclosed markers are preserved literally when interrupted, at a newline, or
+at the size limit. Ordinary text is coalesced into short frames and never replayed.
 
 Reproduce this flow offline with `bun run build` followed by
 `python3 scripts/console-pty-smoke.py` (Python 3 and Node on macOS/Linux). The PTY
@@ -130,7 +139,11 @@ their status. Review groups retain the status reported by their group runtime.
 `/diff` colors additions, removals, and hunk headers on eligible terminals, respects
 `NO_COLOR`, and escapes untrusted terminal controls. Model text also escapes terminal
 controls and renders bounded Markdown headings, emphasis, and fenced code on a
-TTY; JSON/JSONL retain their existing data contracts.
+TTY. Tables with leading pipes and a Markdown separator row render with aligned
+borders and wrapped cells at the current terminal width; narrow terminals use
+stacked labels and values. Table blocks buffer up to 128 lines (8 KiB per line)
+before rendering; incomplete or oversized syntax stays readable as literal text.
+Redirected output and JSON/JSONL retain their existing data contracts.
 
 Contributor validation: `bun run smoke:package` also runs a real PTY workflow
 against the installed CLI, including approval recovery after process restart.
@@ -200,7 +213,9 @@ For the rationale and reference patterns, see [Console UX](https://github.com/Zh
 
 `/resume` opens the searchable conversation menu; `/resume last` and `/resume <id>` remain shortcuts. `TERM=dumb` and non-TTY selection fall back to numbered lists. The service console offers navigation for conversations and session tools; provider/model policy remains with the service host.
 
-Activity is compact in the direct console: tool actions, approvals, errors and final run status remain visible; repeated provider and per-step transport notices are hidden. `/verbose` toggles full activity for that console process. One-shot and JSON/JSONL outputs retain their contracts.
+Activity is compact in the direct console: tool actions appear only as a temporary TTY status; approvals, errors and final run status remain visible; repeated provider and per-step transport notices are hidden. `/verbose` toggles full activity for that console process. One-shot and JSON/JSONL outputs retain their contracts.
+
+The agent is instructed to give brief progress updates unless the requested output format or silent execution prevents them; their frequency depends on the model. Model text is shown in compact mode too. Direct CLI runs and continuations return unknown tool names as error receipts so the model can select an exposed tool. Unknown tools are never executed or aliased, and error/step budgets and approval requirements still apply. Library callers retain their configured tool-error policy.
 
 Each console session is a scoped, durable chain of immutable run IDs. The session index stores provider/model/status metadata and never stores prompts, model messages, tool payloads, or provider data; those remain in the governed run store. `zhx chat --continue` opens the latest session and `--session <id>` selects one explicitly.
 
@@ -319,21 +334,24 @@ Personal CLI profile schema `1` is separate from resolved Harness configuration
 
 The default state directory is `<workspace>/.zhivex-harness/runs` and the default backend is scoped SQLite at `operations.sqlite`. Explicit external state directories are supported, but the workspace root, filesystem root, sensitive workspace paths, regular files, and symbolic-link targets are rejected before the run store is created. See [DURABLE_OPERATIONS.md](./DURABLE_OPERATIONS.md) for state migration and operations, and [EXTENSIBILITY.md](./EXTENSIBILITY.md) for capability, MCP, subagent, and review-group configuration.
 
-### Runtime repair policy
+### Required verified delivery
 
-`--agent-profile <strict|repair>` selects the runtime policy (default `strict`;
-`ZHIVEX_HARNESS_AGENT_PROFILE` provides the environment default). `repair` enables
-bounded schema/tool recovery, cumulative model accounting, exploration controls,
-and up to two retries of recoverable approved verifier failures. A successful
+The assistant uses one general-purpose execution loop with bounded schema/tool
+recovery and cumulative accounting. `--require-verified-delivery` adds an explicit
+completion obligation, exploration controls and up to two retries of recoverable
+approved verifier failures. A successful
 approved verification/import can finish from its durable receipt. It does not
 auto-approve tools, bypass checks, or recover cancellations/integrity violations.
-The selected profile is persisted in resume configuration and the harness binding.
+The delivery requirement is persisted in resume configuration and the harness binding.
+The former `--agent-profile`, `agentProfile` and `ZHIVEX_HARNESS_AGENT_PROFILE`
+configuration have been removed; there is no profile alias. Saved connection
+profiles (`--profile`) and optional subagent roles are independent and unchanged.
 
 ```sh
-bun run src/cli.ts run "Fix the regression and verify it" --agent-profile repair --execution oci
+bun run src/cli.ts run "Fix the regression and verify it" --require-verified-delivery --execution oci
 ```
 
-Library callers select `agentProfile: "repair"` in `createHarness` and can observe
+Library callers select `requireVerifiedDelivery: true` in `createHarness` and can observe
 bounded timings/accounting with `runHarness(..., { onDiagnostics })`. Telemetry
 observer exceptions do not alter the execution result. A stricter caller can
 explicitly override tool-error behavior or terminal receipt settings.
@@ -373,10 +391,14 @@ into a new CLI result. Approval output remains untrusted repository text.
 
 ### Compact tool activity
 
-Interactive chat groups tool activity between assistant messages into one summary.
-On a TTY, a single bounded line updates while tools run; redirected output receives
-plain summaries without cursor controls. `/verbose` restores individual events.
-Tool failures, check receipts, and approval requests remain individually visible.
+Interactive chat keeps successful tool bookkeeping out of the conversation.
+On a TTY, one temporary line shows Reading files, Exploring the project, or Thinking
+and is erased before the next assistant text. Redirected compact output omits this
+status entirely. Reads, searches and listings accumulate into one summary when
+the run finishes or requests approval, rather than interrupting every assistant
+message. Edits, check receipts and failures remain visible; known tool failures
+show a short actionable reason without dumping their payload. `/verbose` restores
+individual tool events for subsequent activity. Approval requests remain visible.
 Budget and step-limit failures show their known runtime cause; arbitrary provider
 error payloads are not printed in activity events.
 
@@ -388,15 +410,256 @@ subsequent model calls, rather than guaranteeing a pre-request input-token ceili
 
 ### Runs without cumulative token budgets
 
-Use `zhx --no-token-budget` for the interactive console or
-`zhx run --no-token-budget "Your task"` for a single task. This explicitly disables
-cumulative input, output, and total token ceilings for the main run and all its
-subagents, including the repair controller's token closure reserve. Usage is still
-measured and persisted; the setting survives approval resume and conversation continuation.
-Numeric token settings remain stored but inactive while this mode is enabled.
-Default token budgets are unchanged for runs without this flag.
-
-Compaction, per-request model/provider limits, cost budgets, step/tool limits,
-timeouts, and approvals still apply. This is not an unlimited context window or
-an unlimited single response. Library callers use `unlimitedTokens: true` in
-`HarnessConfigInput`; `false` restores enforcement of the numeric token budgets.
+New local interactive sessions (`zhx` or `zhx chat`) have no cumulative token
+ceiling by default. Automatic compaction continues, and usage is measured and
+persisted. This avoids ending a repository analysis solely because repeated
+requests have consumed 100,000 input tokens.
+
+`zhx run`, `zhx review`, SDK callers and service hosts retain their bounded
+defaults. Use `--token-budget` in the local console to opt into those budgets.
+Explicit numeric token flags or token-limit environment variables also enable
+bounded console execution unless `--no-token-budget` is explicitly supplied.
+Saved conversations retain their stored policy, including older bounded sessions;
+start a new session to use the new default.
+
+`--no-token-budget` disables cumulative input, output and total token ceilings for
+the main run and children, including token closure reserves. Numeric settings remain
+stored but inactive. Step/tool limits, timeouts, monetary limits and approvals still
+apply. Library callers use `unlimitedTokens: true`; `false` restores token limits.
+
+`--context-tokens <n>` sets the estimated context compaction threshold independently
+of cumulative usage. The default is 40,000. It can be adjusted for the selected model;
+it does not change the provider's actual context window. The local catalog does not
+yet declare verified model context windows, so the harness does not infer larger
+windows from model names. Saved sessions preserve this threshold.
+
+`/context` shows the estimated retained conversation size (excluding additional
+request instructions and tool schemas), compaction settings and budget mode.
+`/usage` shows the latest run's cumulative input/output usage and remaining budget
+separately from the transport ledger. Unknown usage is not reported as zero.
+
+Examples:
+
+```sh
+zhx
+zhx --token-budget --max-input-tokens 200000 --max-total-tokens 230000
+zhx --context-tokens 100000
+zhx run --max-input-tokens 200000 --max-total-tokens 230000 "Analyze the repository"
+zhx run --no-token-budget "Analyze the repository"
+```
+
+### Conversation preview
+
+![Interactive conversation with temporary tool activity](./images/cli-conversation.png)
+
+This image is rendered from the real CLI's PTY screen with an offline provider
+fixture and real read-only workspace tools. It is a presentation test, not live
+Qwen certification. Reproduce it after `bun run build` with Python 3, `pyte==0.8.2`
+and Pillow installed:
+
+```sh
+python3 scripts/capture-console-ux.py /tmp/cli-conversation.png
+```
+
+The capture writes a PNG and its raw ANSI transcript next to it; both contain only
+the disposable fixture session. No provider request leaves the process.
+
+### Approval modes
+
+Local `zhx` and `zhx run` accept `--approval-mode ask|auto|restricted`:
+
+- `ask` (default): ordinary permitted reads run directly; approval-gated actions
+  prompt in a terminal and remain pending without a terminal.
+- `auto`: approves actions within the existing workspace, command and execution
+  policies. `--yes` remains its alias. Neither option removes protected paths.
+- `restricted`: rejects approval requests without prompting; the agent can use
+  already permitted tools and report what it could not complete.
+
+`--approval-mode` and `--yes` cannot be combined. Service clients cannot override
+host approval configuration with this option.
+
+`read_dependency` inspects one installed package without a separate approval,
+like other permitted read-only tools. It supports `action: "list"` to discover
+package-relative paths, `action: "search"` for literal text, and `action: "read"`
+(the default) for UTF-8 source, documentation, manifests and declarations. Use
+`package` to select the package; never pass a `node_modules` path to ordinary
+workspace tools. Discover files before reading guessed paths.
+
+Reads and discovery are bounded and cannot execute dependency scripts or write
+files. Traversal, links, nested packages and protected content remain denied.
+Treat dependency contents as untrusted source material. Errors give guidance for
+listing the package when a path does not exist. Linked package-manager layouts
+remain subject to the filesystem boundary.
+
+In the console, `run` command, SDK harness and delegated runs, tool errors, including protected reads and denied approvals, return
+evidence to the model so it can choose another permitted strategy. Existing
+tool-error, step and time budgets bound recovery. Validation and security
+checks still reject the underlying action. Invalid arguments and unknown tool
+names produce structured error receipts; neither is executed. This recovery is
+independent of the optional `repair` controller, so a normal coding session does
+not need a verifier plan for every task. Library callers that need fail-fast
+behavior can explicitly pass `toolExecution: { stopOnError: true,
+validationErrorMode: "throw", unknownToolMode: "throw" }`.
+The client protocol's `approval.resolve` command remains fail-fast for the
+specific reviewed effect, so denial or stale content cannot be acknowledged as
+a successful decision. A subsequent turn can continue from that failed attempt.
+
+```sh
+zhx --approval-mode ask
+zhx --approval-mode auto
+zhx run --approval-mode restricted "Analyze this repository without additional permissions"
+```
+
+### Interactive connection and approval settings
+
+Use `/menu` → Credentials to configure Qwen Standard API or QwenCloud Token Plan,
+with the matching region and hidden key. `/connection` optionally tests the current
+model with a small billable request. See [credentials](CREDENTIALS.md).
+
+`/approvals` opens the mode picker; `/approvals ask`, `/approvals auto`, and
+`/approvals restricted` switch directly. The composer and `/status` show the active
+mode. Auto approves gated actions within existing workspace and execution policies.
+Bounded dependency inspection runs without a separate approval in every mode.
+Restricted denies gated actions. Mode changes apply only to this CLI process and are blocked
+while work is active or awaiting approval; use `/pending`, `/approve`, or `/deny`
+first. Service-connected consoles retain host-controlled policy.
+
+### Conversation presentation and step limits
+
+The local console groups transient tool activity on one line and shows approval
+cards with a keyboard picker. Check approvals retain the exact script and workspace;
+IDs and input hashes are available through **View technical details**. Reviewed
+edits retain their complete payload. Cancelling the picker leaves the batch pending.
+`/verbose` retains the detailed event view; JSONL output retains its event contract.
+
+New local conversations, API runs, automation, and service runs default to a finite
+limit of 50 model iterations per turn. Explicit
+`--max-steps` and `ZHIVEX_HARNESS_MAX_STEPS` take precedence. Saved runs retain their
+limits. `/limits` opens a picker and `/limits 100` sets the limit for subsequent
+turns. Step limits accept any positive safe integer, with no separate ceiling of 50.
+Explicit parent and child step/tool-call budgets can exceed the former configuration
+ceilings; defaults remain finite and tool calls still accept zero to prohibit calls.
+Active runs and pending
+approvals must be resolved first. More steps can increase API costs; other budgets
+still apply. A failed run reaching its step limit now shows the persisted cause
+and the current/maximum counts. Continue with a new message after adjusting the
+limit; this does not rewrite the failed run or certify unfinished work.
+
+Compact activity remains visible while the model is silent: the terminal shows
+its current step and elapsed wait, followed by grouped counts of completed tool
+operations. Successful reads and searches remain in the transcript instead of
+being erased. Tool arguments, file contents, and private reasoning are not printed
+in these progress summaries. Checks and errors retain their separate receipts.
+
+### Interactive continuity and session permissions
+
+New local `chat` sessions default to 50 model steps, 200 tool calls, 20 tool
+errors and 60 minutes per run. Explicit CLI/environment limits and saved run
+policies take precedence. Automation and service share the 50-step default but
+retain their separate tool, token and time budgets.
+`/usage` shows all these ceilings separately from cumulative token usage.
+
+After an interrupted or failed turn, `/continue` starts a new run with retained
+messages and recorded results. The previous run keeps its actual terminal status
+for diagnostics. Pending approvals must be resolved first. Missing tool receipts
+are marked as unknown outcomes: continuation must inspect state before proposing
+another action. Continuation is explicit, including when the previous run reached
+a configured token or cost budget; it starts a fresh per-run budget.
+
+In the approval picker, **Allow this exact check for this session** remembers the
+workspace, provider, child agent, check name and exact expected script. A changed
+script prompts again; executor script validation still applies. Grants live only
+in the CLI process and are not saved with conversations. Bounded dependency
+inspection does not require a grant. Leaving a batch pending discards its new grants.
+
+Three consecutive failed calls with the same tool request stop the local turn;
+a different request or successful tool result resets the counter. This tolerates
+ordinary exploratory errors while bounding unproductive loops. New chat turns
+allow two SDK transport retries with 500 ms initial backoff. This does not restart
+an agent run or automatically replay executed tools or interrupted streams.
+
+Context remains a separate limit. Use `--context-tokens 100000` when the selected
+model and endpoint support the full request plus output reserve. The current
+catalog has no verified context-window metadata, so the fallback remains 40000
+estimated conversation tokens; no model capacity is guessed. Qwen reasoning
+fragments are normalized losslessly before estimation, followed by adaptive
+compaction at safe tool/approval boundaries. Identical unsigned final reasoning
+summaries are deduplicated against their streamed text. The compaction target
+has a floor for instructions and the newest complete interaction so that a
+target alone cannot abort useful work. Actual context admission and configured
+run budgets remain authoritative; protected groups are never silently discarded.
+## Configurable model-assisted compaction
+
+Automatic compaction remains deterministic unless explicitly selected. Use
+`--compaction-model <id>` and optionally `--compaction-provider <provider>` on
+`zhx run` or `zhx chat`. The provider defaults to the primary provider. Example:
+
+```sh
+zhx chat --provider openai --compaction-provider openai --compaction-model gpt-6-luna
+```
+
+In the direct console, `/compaction` shows the selection, `/compaction recommend`
+shows evidence-backed advice, `/compaction provider:model` selects a route, and
+`/compaction off` restores deterministic compaction. Changes require no active or
+pending turn and apply to subsequent turns in this CLI session. A paused run keeps
+its exact original route. Custom model IDs are accepted; account access and summary
+quality are not implied. Recommendations check credential presence, not live access.
+Advice reserves 8,000 input and 1,024 output tokens and reports price scope, evidence
+dates and unknown/stale metadata; it never changes the selected model automatically.
+
+The selected provider receives bounded, redacted user/assistant excerpts, local
+read/search code excerpts, diagnostic observations and deterministic context.
+Code and diagnostic excerpts are untrusted data for summarization, not permission
+or proof of correctness. Arbitrary tool objects, external-tool payloads and raw
+provider responses are excluded. All excerpts share the existing input and byte
+reservation limits.
+Calls use the run's budgets and per-model usage ledger, including rejected summaries
+and partial usage. Unknown usage stops continuation. Use per-route `--pricing-file`
+and `--usage-limit-usd` for monetary caps; the legacy single-price cost budget cannot
+be combined with a utility model. Manual `/compact` remains deterministic.
+
+The experimental `zhx-acp` binary exposes text sessions to ACP clients; see
+[ACP](ACP.md) for supported methods and limitations.
+
+## Model reasoning
+
+The interactive model picker continues to a reasoning picker. Escape returns to the
+model list without changing the active configuration. `/reasoning` adjusts the
+current model; `/reasoning low` and `--reasoning low` select an explicit level.
+Supported values are `default`, `none`, `minimal`, `low`, `medium`, `high`, `xhigh`
+and `max`, but only adapter-declared levels are offered or accepted for that model.
+`default` sends no override. Adapters without an explicit level inventory show
+only `default`; a generic reasoning capability does not establish supported levels.
+Higher effort can increase latency and token consumption. No effort is silently
+lowered. The composer displays the setting. Onboarding stores it in the personal
+profile; conversation runs persist it for resume. Switching models resets the
+selection unless a new level is chosen. Explicit CLI configuration wins over a
+profile. Active or approval-pending runs retain their original configuration.
+
+Reviewed edits with missing read references can reuse a rejected candidate via
+`retryToolCallId` after a successful reread, optionally specifying `createPaths`
+for genuinely new files. The runtime rebinds references and requests approval for
+the complete edit. Candidates are bounded to four / 1 MiB per invocation; durable
+validation-failed calls seed recovery on resume. Unknown or unavailable candidates
+require a fresh proposal. Explicit digests are never silently refreshed, and
+stale files remain rejected. No edit occurs merely by retaining a candidate.
+
+Qwen requests replay the local conversation instead of retaining a remote response
+chain. This makes compacted context and current system guidance authoritative.
+Reasoning and tool payloads remain intact; local replay does not guarantee a
+particular cache hit rate or response latency.
+
+### Activity and queued tasks
+
+`/activity` shows a bounded in-memory history of tool outcomes, approvals and applied
+file receipts; `/activity clear` clears it. `/queue` lists tasks submitted while the
+agent was busy, and `/queue clear` clears tasks and the unsent draft. Enter queues,
+Alt+Enter adds a newline, Up retrieves the last queued task from an empty background
+draft, and Ctrl+C cancels the operation and clears the queue. Queued slash text is
+always a literal task, never an approval command. Pending approvals pause delivery.
+The queue is limited to eight tasks / 256 KiB; each draft is limited to 64 KiB.
+
+Activity shows phase and total elapsed time. Preparing edits, waiting for approval,
+applied file changes and verification are distinct states. `/diff` reviews workspace
+changes, including changes outside the current run; file receipts identify mutations
+recorded by this harness.