@volter/supercode-frontend-vscode 0.1.58 → 0.1.61

package/NOTICE.md

@@ -16,4 +16,4 @@ The generated attachment client under `vendor/supercode-frontend/` is this repos
 Volter Harness-authored integration and presentation code is identified by this package's source history
 and remains under the repository's declared `MIT OR Apache-2.0` license.
 
-The bundled provider/harness SVG marks in media/ are derived from this repository's sdk/ui/src/logo.jsx. Brand marks identify the active provider; they do not imply affiliation.
+The provider SVG marks in media/ are written by the build (scripts/sync-marks.mjs) from this repository's one mark catalogue, sdk/ui/logo-data.mjs. Brand marks identify the active provider; they do not imply affiliation.

package/README.md

@@ -18,8 +18,14 @@ A click starts one install/sign-in operation for that agent. The host returns
 its exact structured terminal launch through the authenticated `/setup` door;
 a missing agent installs from its vendor package, then the same click continues
 to login. The frontend never interprets repair prose as a command.
+Installation output stays in its own native task terminal after the command
+ends, including failure. Retrying uses a new terminal; cancelling terminates
+only that click's active installation. Login keeps its native sign-in terminal.
 
 The host's `/state` supplies `setup: {ready, actions, agents, reason, cwd}`.
+After a native login exits, setup allows two inventory refreshes begun after
+that exit before reporting failure. Inventory-confirmed sign-in remains the
+success condition, including when the process exits with code zero.
 Each agent supplies `{harness, name, installed, signedIn, account}`; an unknown
 account is `null`. Each action supplies `{kind, harness, name, command}` with
 `kind` equal to `install` or `login`. The host revalidates the chosen action
@@ -53,13 +59,23 @@ in the disabled composer. Stock hosts retain native Markdown links. The
 editor's renderer/build is a separate integration; the frontend package alone
 does not claim those richer controls are installed in every host. A successful
 explicit sign-in publishes **Signed in with ChatGPT** or **Signed in with
-Claude** above the newly opened Chat.
+Claude** above the newly opened Chat, or **Signed in with <account>** when the
+host names the account that signs the agent in (a setup agent's `account`).
 
 Setup creates no transcript turns. The guarded readiness reveal preserves a
 newer draft or selection; a welcome-owned empty draft can give way to the first
 ready conversation. Hosts without the guarded reveal command report the
 limitation. Passive inventory polling retries a transient handoff failure until
 attachment and reveal both succeed for the same conversation.
+When the native guard cancels an automatic reveal, the same connected
+conversation/focus waits instead of repeating that navigation every three seconds.
+A changed focus, conversation, connection or live-turn state permits another
+attempt; the explicit `supercode.frontend.refreshSetup` command retries too.
+Cancellation leaves the handoff incomplete. Other refresh failures keep their
+warning and retry behavior, labeled as Chat setup. Inspect-mode runtime status
+includes the focused resource/generation and the last canceled reveal's basis.
+[Source and package evidence](../../docs/evidence/chat-canceled-reveal-2026-10-10.md)
+leaves the native restored-composer input and real Windows reopen unresolved.
 
 A bundling host can expose a private lifecycle endpoint through
 `SUPERCODE_FRONTEND_HOST_URL` and `SUPERCODE_FRONTEND_HOST_CREDENTIAL_FILE`.
@@ -72,22 +88,33 @@ The contract is in `src/host-controls.ts`.
 
 With that host, **New Session** / **Chat: New Chat: Choose Agent** lists all
 coding agents, including Codex and Claude Code when missing or signed out.
-Their rows say **Signed in with ChatGPT/Claude** or **Sign in with
-ChatGPT/Claude…**. A sign-in row starts the same install/login operation as the
+Their rows say **Signed in with ChatGPT/Claude** (**Signed in with <account>**
+when the host names one) or **Sign in with ChatGPT/Claude…**. A sign-in row starts the same install/login operation as the
 welcome. Selecting a ready agent leaves model and reasoning at its defaults;
 the separate **<agent>: model and reasoning…** rows retain explicit settings.
 The picker is titled **New chat**, with **Choose your coding agent** as its
 placeholder. Cancelling it starts no backend conversation. Initial automatic
 agent selection and last-used selection remain the host's responsibility.
 
-The native blank chat opens before the picker appears. First send waits for the
-choice and the host's new connection through Code-OSS's session-creation handler;
+The native blank chat opens before the picker appears. Sending before the choice
+finishes shows **Choose your coding agent before sending** and leaves the draft
+available. Choose the agent, then send again. A cancelled choice in the current
+window also refuses a send; it starts no backend. After selection, first send
+waits for the host's new connection through Code-OSS's session-creation handler;
 the composer keeps the draft until the request is accepted. There is no later
 conversation swap that can hide a message sent while the agent starts. This follows
 the pinned workbench's [first-send materialization](https://github.com/volter-ai/code-oss/blob/f16dc165c0dffe701a7bbf59aefb1c662b206cee/src/vs/workbench/contrib/chat/common/chatService/chatServiceImpl.ts#L1272)
 and [draft acceptance](https://github.com/volter-ai/code-oss/blob/f16dc165c0dffe701a7bbf59aefb1c662b206cee/src/vs/workbench/contrib/chat/browser/widget/chatWidget.ts#L3493)
 paths. A failed startup leaves the draft available to retry.
 
+The paired editor host also explains Enter when native session options are
+invalid and the submit keybinding cannot reach the extension. Its explanation
+uses the read-only `supercode.frontend.sendRefusal` command when available;
+older frontends receive the host's agent/model explanation. The extension alone
+cannot receive a keypress rejected by a host's keybinding precondition.
+[Source and qualification](../../docs/evidence/chat-unselected-send-2026-10-10.md)
+record the genuine published 0.1.58 source and the unperformed Windows reading.
+
 New Chat highlights the agent from the focused conversation (or an already
 chosen draft) before opening the blank chat. With no matching choice it keeps
 the host/native default. This is a source correction with
@@ -158,6 +185,33 @@ re-joined after a page reload (the conversation's active response) is answered t
 harnesses show **Harness permissions**. Previously answered requests cannot affect another
 connection. Native command-button fallback limitations are documented below.
 
+A lifecycle host can also select a project **YOLO** runtime policy. Model Editor reads
+`"volter.chat.runtimePolicy": "yolo"` from the project's `.vscode/settings.json`;
+user-wide values do not enable it. The next native Claude Code or Codex start or
+resume runs without asking anyone, including configured model and inference
+launches: Claude Code with its bypass flag; Codex with `approvalPolicy:
+"on-request"`, `sandbox: "danger-full-access"` and a thread config that hands
+every request to Codex's auto-reviewer (`approvals_reviewer = "auto_review"`)
+under an `auto_review.policy` that approves it, on thread start and resume.
+Never `never`, under which Codex refuses outright any command its own check
+flags as dangerous. A service must advertise `yolo_policy: true` before
+the host starts it this way. Other harnesses and existing endpoint attachments
+cannot acquire this policy from the project setting.
+
+The host records `ManagedChatSession.runtimePolicy` from the opened runtime.
+The permission group shows **YOLO** for that runtime and does not save the item
+as an approval choice. A saved Ask choice cannot restore prompts in a process
+already launched under YOLO (Claude Code's bypass flag, Codex's auto-reviewer). Changing the workspace setting to `default`
+applies on its next start or resume. `HostState.newChatRuntimePolicy` describes
+the next runtime; it does not relabel a running conversation. Default-policy
+chats retain their Ask and Auto approve choices. Auto approve also answers
+supported requests raised outside this window's turns, through the same frontend
+response door and with one answered-request set per connection.
+
+The [source and build evidence](../../docs/evidence/chat-project-yolo-2026-10-10.md)
+records successful compilation and the built service's capability replies. Real
+build-agent approval behavior and the embedded workbench remain unmeasured.
+
 Text files and selected ranges use native Add Context and attachment chips. Their current
 editor contents are serialized as explicitly labeled user-supplied context through the existing
 prompt protocol. Binary text, more than 256 KiB per attachment, or more than 1 MiB total is
@@ -220,8 +274,42 @@ Three paths, in precedence order.
 The generated client opens SSE **before** taking the attachment snapshot, so no event falls between
 history and live. Dropping or detaching never closes the runtime.
 
+After that snapshot arrives, the connection enters the session picker and follows
+events while an interactive attachment acquires control. `connect()` still waits
+for the control attempt before returning; early actions share that attempt.
+Input arriving in a rejoined response, or after a submitted turn's `turn_started`,
+appears as **Additional input** while the response runs. Reopening reads the
+runtime's user turns from history. The initial submitted prompt already has a
+native request turn. [Source and package evidence](../../docs/evidence/chat-attach-live-input-2026-10-10.md)
+records the remaining native timing and display qualification.
+
+When a snapshot supplies `pending_requests`, the attachment replaces its local
+request set at the exact snapshot capture boundary, then merges later retained
+request, resolution and turn events before committing state and cursor. An empty
+snapshot still clears old asks, while missing later events refuse attachment. Older runtimes retain
+the existing replay-based behavior. Actual stream and recovery failures are
+retained until a fresh attachment succeeds. They end the waiting Chat view with
+the error while preserving the native turn state; reopening also shows the
+failure in Chat. A failed initial attachment marks its saved session row failed.
+Approval and interrupt RPCs remain available under their existing authority.
+Fresh snapshots also restore retained `history_events` before replay at the
+runtime's cursor. Their original sequences and payloads are preserved. Recovered
+unseen events reach existing response listeners, and an authoritative idle
+snapshot releases a restored response even when its terminal event is no longer
+retained. Chat states when older events are outside the bounded display window.
+An unavailable saved runtime returns an error in Chat instead of a blank draft.
+These are implemented source paths; real editor recovery and pending approval
+interaction remain unqualified.
+
 ## API proposals, and what it does without them
 
+Saved transcript text parts (`text`, `input_text`, `output_text`) use the same
+bounded renderer as live payloads. Structured values display their JSON contents;
+the frontend does not coerce them into JavaScript's object label.
+[Published 0.1.35/0.1.42 comparison and source correction](../../docs/evidence/chat-structured-transcript-text-2026-10-09.md)
+record this history path. The original Windows approval-row report remains
+unattributed, and native approval behavior is separate.
+
 The extension asks for five proposals. A host grants them through
 `product.json#extensionEnabledApiProposals` (a Code-OSS derivative that bundles this extension) or
 `--enable-proposed-api volter-ai-dev.supercode-frontend-vscode`. **Stock VS Code grants none, and
@@ -269,20 +357,20 @@ it needs and the fallback it degrades to. Each arm names the producer it reads.
 | Event kind | Producer | Rendered as |
 |---|---|---|
 | `text_delta` | `crates/runtime/src/event.rs` `AgentEvent::TextDelta` | `response.markdown` (streamed) |
-| `user_message` | `crates/harness/src/server.rs` `submit_claimed` | the request turn in history; dropped live (VS Code already shows it) |
+| `user_message` | `sdk/interchange/agent-runtime-host.mjs` accepted-turn projection | the request turn in history; dropped live (VS Code already shows it) |
 | `turn_started` / `turn_completed` / `turn_succeeded` | `submit_claimed`; `AgentEvent::TurnCompleted` | lifecycle only — the handler resolves, nothing renders |
 | `turn_interrupted` | `submit_claimed` | an italic notice |
 | `turn_failed` | `submit_claimed` | `ChatResponseWarningPart` → blockquote |
 | `tool_call_started` / `tool_call_completed` | `AgentEvent::ToolCallStarted` / `ToolCallCompleted` | one `ChatToolInvocationPart` per call, updated in place with its result (`enablePartialUpdate`) → a progress line plus a labeled Markdown result |
 | `diff_updated` | `crates/codex-frontend/src/codex_app_server_v0_144.rs` (stock Codex `turn/diff/updated`) | `codeblockUri` + a fenced `diff` block, plus one stable `reference` per file the diff names → the fenced block alone |
-| `request` | `crates/harness/src/server.rs` `FrontendRequestBroker::publish` | a titled markdown block plus one **command button per answer** — stable API, no proposal |
+| `request` | `sdk/interchange/frontend-request-bridge.mjs` request publication | a titled markdown block plus one **command button per answer** — stable API, no proposal |
 | `cache_warning` | `AgentEvent::CacheWarning` | `ChatResponseWarningPart` → blockquote |
 | `usage` | `AgentEvent::Usage` | a progress line |
 | `background_output` | `AgentEvent::BackgroundOutput` | a fenced block, saying so when the runtime stopped retaining |
 | `scheduled_prompt_started` / `_deferred` / `_completed` | declared by `frontend_descriptor`'s `display.event_kinds` | a progress line |
 | `scheduler_error` | same | `ChatResponseWarningPart` → blockquote |
-| `reasoning` / `thinking` | no producer in this repository; read because `crates/frontend-model/src/transcript.rs` reads them | `ChatResponseThinkingProgressPart` → blockquote |
-| `stream_error` / `transport_error` / `watch_error` / `runtime_disconnected` | `crates/opencode-frontend/src/server.rs`; `crates/interchange/src/watch.rs`; synthesized by a frontend (`crates/frontend-tui/src/app.rs`); `stream_error` has no producer here | `ChatResponseWarningPart` → blockquote |
+| `reasoning` / `thinking` | no producer in this repository; read because `sdk/interchange/frontend-transcript.mjs` reads them | `ChatResponseThinkingProgressPart` → blockquote |
+| `stream_error` / `transport_error` / `watch_error` / `runtime_disconnected` | `crates/opencode-frontend/src/server.rs`; `crates/interchange/src/watch.rs`; synthesized by a frontend (`sdk/interchange/frontend-app.mjs`); `stream_error` has no producer here | `ChatResponseWarningPart` → blockquote |
 | anything else | opaque by contract | one **bounded** markdown cell that names the kind and shows the payload — never dropped |
 
 **Why `diff_updated` is not an edit part.** Measured: the payload carries one unified-diff *string*
@@ -317,7 +405,7 @@ can also be answered by typing.
 **A hosted harness runtime.** When the runtime is one Volter Harness HOSTS — a Claude Code, Codex, pi or
 opencode session it started through `harness.v1.runtimes.start` — an approval it raises is
 **answerable from this view** for every harness whose reply this runtime can translate
-(`crates/harness/src/runtime/hosted.rs`): the canonical `respond {decision}` becomes that harness's
+(`sdk/interchange/runtime-hosted.mjs`): the canonical `respond {decision}` becomes that harness's
 own envelope, which for Claude Code is `{behavior:'allow'}` / `{behavior:'deny', message}`. The
 request states which decisions its harness protocol actually carries, so this view offers exactly
 those and no button the runtime would refuse — Claude Code has an allow and a deny and no
@@ -350,6 +438,13 @@ needs it; a reader does not, and a collapsed block is still a reader's problem.
 one to a person, so `role: 'system'` is dropped outright and the transcript starts where the
 conversation does.
 
+Saved user-role records marked `isMeta`, `isCompactSummary` or
+`promptSource: system` are also context. They create no person-message bubble;
+ordinary quoted text without those flags stays a person message. Claude's
+unmarked, exact `[Request interrupted by user]` record becomes a short turn
+interruption notice. The native transcript remains authoritative and unchanged.
+[Source evidence and remaining qualification](../../docs/evidence/chat-native-notices-20261013.md).
+
 **Session times are real or nothing.** `frontend.v2` carries no session timestamp, and the editor's
 session list ALWAYS reads `timing.created`, rendering the epoch ("57 yrs ago") when a provider
 supplies none — there is no path in `agentSessionsViewer` that omits the time. So the item gets the
@@ -475,6 +570,13 @@ raw token. External attachments retain their exact identity across reloads.
 `supercode.frontend.status(true)` reports connection state, conversation view
 readiness/resource and rendered event cursor. View readiness follows history
 restoration and live-response subscription, rather than a socket alone.
+Its `selection` follows the focused draft or saved conversation; `selectionSource`
+names that source. A draft with no choice and an external attachment report no
+host selection. `hostSelection` retains the host's separate runtime choice.
+Conversation-creation failures show their native error immediately, before a
+request handler exists, and retain the refusal for that draft's handler.
+[Source and outstanding Windows qualification](../../docs/evidence/chat-start-failures-2026-10-10.md)
+record this change separately from the earlier native Windows launcher fixes.
 `supercode.frontend.disconnect(connectionId)` also forgets the saved attachment.
 IDs belonging to managed conversations cannot be reused for external attachments.
 Calling `connect` without arguments retains the interactive settings flow.

package/dist/chat-setup.js

@@ -30,8 +30,9 @@ export function setupPresentation(state, operations, notice) {
         const busy = phase === 'installing' || phase === 'signing-in';
         return { ...agent, provider: provider.provider, phase,
             buttonLabel: phase === 'installing' ? `Installing ${provider.name}…` : phase === 'signing-in' ? 'Finish signing in in your browser…'
-                : phase === 'failed' ? 'Try again' : `Sign in with ${provider.provider}`,
-            caption: busy ? 'Cancel' : phase === 'failed' ? "Sign-in didn't finish." : provider.caption,
+                : phase === 'failed' ? 'Try again' : phase === 'signed-in' ? `Signed in with ${agent.account || provider.provider}` : `Sign in with ${provider.provider}`,
+            // A row an account the host names signs in is not on a ChatGPT or Claude plan.
+            caption: busy ? 'Cancel' : phase === 'failed' ? "Sign-in didn't finish." : phase === 'signed-in' && agent.account ? `Runs ${provider.name} · ${agent.account}` : provider.caption,
             busy, operationId: operation?.id ?? null };
     });
     const visible = Boolean(state.setup && !state.setup.ready);