dsh-code-server-app 0.3.58 → 0.3.63

package/README.en.md

@@ -12,10 +12,12 @@
 
 A static profile plugin (npm package with host + client bundle) that ships the **VS Code server tree** from a [code-server](https://github.com/coder/code-server) release as a **platform-independent dependency package** (pack-time artifact `vendor/vscode` → `@jinsiyu/dshcs-vscode-server`, no install scripts, no postinstall). The code-server **Node service layer is replaced by the plugin's own `lib/launcher.mjs`**: it drives `<tree>/lib/vscode/out/server-main.js` (`loadCodeWithNls()` / `createServer()` / `handleRequest()` / `handleUpgrade()`) directly and re-adds the few HTTP endpoints code-server used to provide (`/healthz`, `/manifest.json`, `/_static/*`, `/proxy/:port`). The 16 native modules (node-pty / @vscode/sqlite3 / spdlog / …) come from `@jinsiyu/dshcs-*` sub-packages declared **directly on the plugin's dependency table** under their real names (os/cpu-gated per target), with the original import names restored by runtime junctions. VS Code's inner dependencies and the prebuilt native modules are **all installed by the package manager together with the plugin** — no global npm install, no `bin` configuration, no profile config changes, no second install command, **no argon2/C++ toolchain**.
 
-> Since 0.3.22 the ask panel renders the session's new content with **DSH's own Markdown renderer** (the same
-> renderer and design tokens as the DSH UI; new content only) and can **answer approval requests in place**
-> (writing outside the workspace / running commands). See "Working with DSH: the editor bridge" and section 21 of
-> `docs/analysis-code-server-as-dsh-plugin.md`.
+> **The "ask DSH" dialog** renders the session's new content with **DSH's own Markdown renderer** and can
+> **answer approval requests in place** (writing outside the workspace / running commands). The panel is a
+> hand-written React component inside `lib/client.js`: it requires `react-dom/client` and
+> `@deepseek-ai/dsh-client-ui-primitives` straight from the DSH page's module table (the very instance the UI
+> uses), so typography, highlighting and math match the UI and a renderer version mismatch is impossible.
+> There is **no build step anywhere on that chain**. See "Working with DSH: the editor bridge".
 
 ## UI carrier and required DSH version (0.2.3: right-sidebar DSH only)
 
@@ -48,7 +50,7 @@ A static profile plugin (npm package with host + client bundle) that ships the *
     the narrow-viewport handling). When the button is missing it keeps the current mode and logs one `console.warn` — panel
     rendering is never affected.
 - **Resident IDE (0.2.2, on by default)**: switching to another tab or collapsing the sidebar and coming back **no longer reloads** code-server — unsaved editor buffers, terminals and debug sessions all stay put (see "Why switching tabs no longer reloads" below).
-- The settings card has exactly **three settings**: "**Claim types**", "**Fullscreen on open**" and "Resident in background" — no other rows (0.2.7 removed the "Entry", "dependency install" and "environment check" rows).
+- The settings card has exactly **four settings**: "**Claim types**", "**Fullscreen on open**", "Resident in background" and "**FIM completion (experimental, off by default)**" — no other rows (0.2.7 removed the "Entry", "dependency install" and "environment check" rows).
   Open the IDE from the **Code Server box** on the sidebar's guide page, or by clicking DSH's own produced-file chips / delivered-file previews / inline file names;
   diagnostics stay out of the UI — the `[code-server]` lines in the DSH host log are the place to look (`/api/code-server/status` still returns `env` for scripts).
   The old `windowedOpen` (open in a window) and `reserveComposer` were **removed in 0.2.6**: leftover keys in an old settings document neither fail nor apply (they are no longer part of the schema).
@@ -225,62 +227,70 @@ only the editor knows, and lets editor gestures drive the current session.
 | Direction | Capability | Mechanism |
 |---|---|---|
 | editor → agent | **unsaved buffers** (disk ≠ what the user sees), active file and selection, **language-server diagnostics** with `file:line`, source and code | agent tools `editor_context` / `editor_diagnostics`; plus a notice attached before writing a dirty file |
-| editor → DSH | select code → context menu **"DSH: ask about selection"** → an **ask panel** opens (carrying `file:line` and the selection); the question enters the current session as **user input**, and that session's **new content** is rendered in the panel by DSH's own Markdown renderer | extension command `dsh-code-server.askAboutSelection` (one of the **top two** editor context-menu items) + a webview panel + `POST /ask` + the `thread` field of `/sync` |
-| DSH → editor (approval) | when the agent wants to **write outside the workspace or run a command**, the approval request shows up as a card in the panel (tool, reason, countdown); "allow once" / "reject" takes effect immediately | the `approvals` field of `/sync` + `POST /approve` (the bridge's **only** non-read-only route; constraints under "Security model") |
+| editor → DSH | select code → context menu **"DSH: ask about selection"** → an **ask dialog** opens in the DSH page (its title bar carries `file:line`); the question enters the current session as **user input**, and that session's **new content** is rendered in the dialog by DSH's own Markdown renderer | extension command `dsh-code-server.askAboutSelection` (one of the **top two** editor context-menu items) → bridge `POST /event {kind:'ask-open'}` → the client half's `POST /api/code-server/ask/send` |
+| DSH → editor (approval) | when the agent wants to **write outside the workspace or run a command**, the approval request shows up as a card in the dialog (tool, reason, countdown); "allow once" / "reject" takes effect immediately | the `approvals` field of `/api/code-server/ask/state` + `POST /api/code-server/ask/approve` (the plugin's **only** write route; constraints under "Security model") |
 | agent → editor | the agent changed a file → a **native diff** opens (left = the **full pre-write text**, right = what is on disk now); if that buffer has unsaved changes you get a warning and **no overwrite** | the host reads `result.value.before` (the complete pre-write text) in `tools/post-execute` into a bounded snapshot cache → the `tools/result` event carries an opaque key → the extension fetches the text and opens the diff |
 
 - The tools are only registered while the bridge is live (so the model never sees an unusable tool), and the
   system-prompt section renders only then too.
-- **Ask panel** (extension 0.2.0; the official renderer since 0.2.3; a **floating dialog over the DSH UI since
-  0.2.5**): the context-menu command no longer opens a panel inside the editor (that is always a tab or a column,
-  never a dialog) — the plugin's client half pops up a draggable, resizable floating chat window in the DSH page
-  itself (bottom-right, ✕ closes it), leaving the editor layout alone. Hosts without that capability fall back to
-  the in-editor webview panel. The selection can still be changed while the dialog stays open.
-  The two commands **remember their intent** (0.3.21): "ask about selection" carries a **line range + selection text**
-  only when something is actually selected, while "ask about file" **never carries line numbers or a selection** — the
-  cursor line is irrelevant to the question and only misleads the agent. With no selection, the selection command also
-  degrades to the plain file.
-- **Injected context is collapsed** (0.3.24): the location line plus the selection code block the bridge adds to the
-  message are split out into a collapsed Context row (click it to see the code), while the bubble keeps only the user's
-  own words — the same treatment the DSH UI gives injected context.
-- **The panel renders exactly what DSH renders** (0.3.22): the panel bundles DSH's official Markdown renderer
-  (`MarkdownText` from `@deepseek-ai/dsh-client-ui-primitives`) plus the official design tokens — the same
-  micromark/mdast pipeline, the same incremental streaming parser, the same shiki highlighting (boot set:
-  typescript / shellscript / json), KaTeX math and the same heading/table typography. Only **new content** is
-  rendered (from the moment the panel subscribes); history is **not replayed** and there is no "load earlier".
-- **Thinking shows up like in DSH** (0.3.23): assistant reasoning becomes a Think row — **collapsed by default**,
+- **Ask dialog**: the context-menu command only reports its intent to the host; the dialog itself is popped up by
+  the plugin's client half inside the DSH page — draggable, resizable (bottom-right, ✕ closes it), leaving the
+  editor layout alone. The selection can still be changed while the dialog stays open.
+  When the host cannot prove the dialog is alive (page not open / browser still running an old client) you get a
+  one-line notice telling you to open or refresh the Code Server tab — there is **no second ask UI** in the editor.
+- **The two commands remember their intent**: "ask about selection" carries a **line range + selection text**
+  only when something is actually selected, while "ask about file" **never carries line numbers or a selection** —
+  the cursor line is irrelevant to the question and only misleads the agent. With no selection, the selection
+  command also degrades to the plain file. The host takes that context from its cached editor state; the extension
+  only reports the intent.
+- **Follow-ups are delivered according to DSH's own setting**: `ui-conversation.busyEnter` (Settings → Conversation,
+  "Enter while busy") accepts `queue` (the default) or `steer`. Pressing Enter in the dialog is the same gesture as
+  pressing Enter in the main composer, so it reads the same value: `steer` ⇒ the host calls `agent.steer()` and the
+  follow-up is consumed at the **running turn's next step boundary** (answered within that turn); `queue` ⇒ the host
+  calls `agent.followup()` and the question becomes **its own later turn**, leaving the running one alone. If the
+  setting cannot be read (namespace unregistered / minimal composition) or the host has no `agent.steer`, delivery
+  falls back to `queue` — a setting never makes a question undeliverable. The panel's status row **says which one was
+  used** ("inserted into the current turn…" / "queued for the next turn…"), because while `queue` is in effect the
+  **DSH main UI cannot show that message yet**: it sits in the host-side pending queue (`next-turn`) and the main
+  client does not render pending queues (it joins the chat flow only once it becomes its own turn). The message is
+  not lost.
+- **Injected context is collapsed**: the location line plus the selection code block the bridge adds to the
+  message are split out into a collapsed Context row (click it to see the code), while the bubble keeps only the
+  user's own words — the same treatment the DSH UI gives injected context.
+- **The body is exactly what DSH renders**: it is handed to DSH's official Markdown renderer
+  (`MarkdownText` from `@deepseek-ai/dsh-client-ui-primitives`) — the same micromark/mdast pipeline, the same
+  incremental streaming parser, the same shiki highlighting (DSH's own lazily-loaded grammar set), KaTeX math and
+  the same heading/table typography. Only **new content** is rendered (from the moment the dialog subscribes);
+  history is **not replayed** and there is no "load earlier". If the official components cannot be resolved the
+  body degrades to plain-text `<pre>` instead of a blank panel.
+- **Thinking shows up like in DSH**: assistant reasoning becomes a Think row — **collapsed by default**,
   showing its first line (or the latest line while streaming) and expanding on a row click, built from the official
   `DisclosureRow` plus the official think icon and typography language.
-- **Approvals are handled right in the panel** (0.3.22; window fixed in 0.3.23): while the panel is open, that
-  session's approval requests ask the panel first (5 minutes by default). Clicking "allow once" / "reject" settles it
-  immediately; **closing the panel** or letting the window expire hands the request back **unchanged** to the official
-  path (the DSH UI shows the same card). 0.3.22's 8-second window was far too short for a human — the buttons went
-  grey before anyone could click (reported as "the approval box stopped working"); the window is now 5 minutes and
-  closing the panel hands off immediately instead of waiting it out.
+- **Approvals are handled right in the dialog**: while it is open, that
+  session's approval requests ask the dialog first (5-minute window). Clicking "allow once" / "reject" settles it
+  immediately; **closing the dialog** or letting the window expire hands the request back **unchanged** to the official
+  path (the DSH UI shows the same card).
   **Nothing is ever auto-approved** — `allowed-once` can only come from a click, and there is no "always allow".
-- The question enters the DSH session as a **plain user message** (`source: { kind: 'user' }`, host 0.3.19): earlier
-  versions used `{kind:'plugin'}`, which DSH renders as a *context update* — it did not look like something the user
-  said. Provenance stays in the first line of the text: `From the editor: <file>[:<line>]`.
-- **Read-only with one constrained exception**: the bridge never writes files, applies edits, or runs commands; the
-  single non-read-only route is `POST /approve`, which can only **answer an approval request that already exists**
-  (see invariant 2 below). The agent's writes still go through its own `fs` tools; the bridge only *knows about* them
-  and carries your answer back.
+- The question enters the DSH session as a **plain user message** (`source: { kind: 'user' }`): provenance stays in
+  the first line of the text (`From the editor: <file>[:<line>]`), and the panel folds it into the Context row.
+- **The bridge is completely read-only**: it never writes files, applies edits, or runs commands — all four routes
+  (`/health`, `/sync`, `/old`, `/event`) are reads. The only route that can change state is the DSH-same-origin
+  `POST /api/code-server/ask/approve`, which can only **answer an approval request that already exists**
+  (see invariant 2 below). The agent's writes still go through its own `fs` tools; the bridge only *knows about*
+  them and carries your answer back.
 - Status bar shows `$(plug) DSH` while connected (click it for the log in the "DSH Editor Bridge" output channel).
-- **The extension ships as a built-in** (fixed in 0.3.12): `dshcs-editor-bridge` is installed into
-  `<tree>/lib/vscode/extensions/` next to `dshcs-open-file`. 0.3.0–0.3.11 installed it as a *user* extension
-  instead, and the VS Code server marks any extension that sits in the user extensions folder but in no profile
-  manifest as removed (`.obsolete`, log line `Marked extension as removed`) and then skips it forever — re-marked on
-  every start, so **the bridge never reported any state**. To turn the bridge off use the plugin setting
-  `editorBridge=false` (no mount, no tools) rather than uninstalling the extension from the Extensions view.
+- **The extension ships as a built-in**: `dshcs-editor-bridge` is installed into
+  `<tree>/lib/vscode/extensions/` next to `dshcs-open-file` — an extension left in the *user* extensions folder is
+  marked `.obsolete` (log line `Marked extension as removed`) by the VS Code server and skipped forever.
+  To turn the bridge off use the plugin setting `editorBridge=false` (no mount, no tools).
 
 ### The channels (since 0.3.13 over **local IPC**: a Windows named pipe / unix socket)
 
 ```
-extension → host   POST /code-server-bridge/sync    one round trip: push editor state (+ which session the panel watches) + take events and thread deltas
-extension → host   POST /code-server-bridge/ask     push an editor question into the current session
-extension → host   POST /code-server-bridge/approve answer an approval request that **already exists** (the only non-read-only route)
+extension → host   POST /code-server-bridge/sync    one round trip: push editor state + take events and the capability bit
 extension → host   GET  /code-server-bridge/health  unauthenticated liveness probe
-extension → host   POST /code-server-bridge/event   extension reports open/close etc. (host log tail)
+extension → host   GET  /code-server-bridge/old     fetch one "pre-write text" snapshot (events carry an opaque key)
+extension → host   POST /code-server-bridge/event   report intent: open the dialog / open·close a file etc. (host log tail)
 host → extension   <extensionsDir>/.dshcs-bridge/bridge.json   endpoint + token, re-read every 5s
                    (the same content is also written **next to the built-in extension** in
                    `<tree>/lib/vscode/extensions/.dshcs-bridge/` — the env var is only injected when the host
@@ -289,14 +299,19 @@ host → extension   <extensionsDir>/.dshcs-bridge/bridge.json   endpoint + toke
 ```
 
 Requests use `http.request({ socketPath })` (`fetch` has no socket support) and **no port is ever opened**.
+All four routes are **read-only**; questions and approval answers do not go through the bridge but through the
+DSH-same-origin `/api/code-server/ask/*` (called by the plugin's client half inside the DSH page, under DSH's own
+cookie/Origin checks).
 
-The three `/sync` fields the panel actually consumes (0.3.22):
+The four state fields the dialog actually consumes (`GET /api/code-server/ask/state?rev=N`; an unchanged revision
+returns a single number):
 
 | Field | Content | How the panel uses it |
 |---|---|---|
-| `thread` | **new content** entries (user / assistant / tool / approval) of the session the panel watches; bounded: ≤120 entries per session, ≤8000 chars per body, ≤4 watched sessions | assistant bodies go to the official renderer; tools and approvals become compact summary rows |
-| `approvals` | pending approval requests `[{id, toolName, reason, at}]` (≤4) | renders the card with a countdown; a click posts `/approve` |
-| `approvalHoldMs` / `uiVersion` | the approval window (300000 ms = 5 minutes by default) / the DSH UI version | countdown basis; a renderer-version mismatch is surfaced in the panel |
+| `entries` | **new content** entries (user / assistant / tool / approval) of the session the dialog watches; bounded: ≤120 entries per session, ≤8000 chars per body, ≤4 watched sessions | assistant bodies go to the official renderer; tools and approvals become compact summary rows |
+| `approvals` | pending approval requests `[{id, toolName, reason, at}]` (≤4) | renders the card with a countdown; a click posts `/ask/approve` |
+| `approvalHoldMs` | the approval window (300000 ms = 5 minutes by default) | countdown basis |
+| `contextText` / `mode` | the title line (from the host's cached editor state) plus the ask intent | title text; `mode` decides whether line numbers / the selection travel with the question |
 
 > **Why not HTTP (settled in 0.3.13, all three measured)**
 > 1. **Desktop has no HTTP surface at all**: the renderer calls `host.fetch()` through Electron IPC
@@ -339,10 +354,15 @@ Regression: the "push → take → clear, twice" case in `scripts/test-bridge-ro
 The token lives in `<extensionsDir>/.dshcs-bridge/bridge.json`, **readable by any process of the same local
 user**, so:
 
-1. **`/code-server-bridge/*` is read-only, with `/approve` as the single exception.** No route writes files,
+1. **`/code-server-bridge/*` is read-only, with two bounded exceptions.** No route writes files,
    edits documents, runs commands, or spawns processes. A leaked token is therefore bounded to "sees information
    that is in the editor" and **can never** become arbitrary file writes or command execution. A whitelist
    assertion in `scripts/test-bridge-routes.mjs` guards this.
+   `/complete` (0.3.61, **experimental FIM completion, off by default**) is the one route that makes a **model
+   call**: it takes two strings (the text before/after the cursor) and returns one string. It still writes
+   nothing and runs nothing, is disabled unless the setting is on (403 otherwise), and is bounded by
+   length/rate/concurrency/timeout caps — so the worst case for a leaked token grows only to "spends a little
+   completion budget and reads back one completion".
    `/old` (added in 0.3.55) lives under the same invariant: it only reads the bounded cache of "pre-write copies of
    the last few agent writes" (≤8 entries, ≤1 MB each, ≤4 MB total, 5-minute TTL) by **opaque key**, 404s when it
    is gone, takes no path argument (so it cannot read arbitrary files) and does not consume (repeat polls get the
@@ -355,7 +375,7 @@ user**, so:
    (d) when no panel is watching, the panel is closed, or the window (5 minutes by default) expires, the request goes
    **back to the official
    path** — never auto-approved (DSH's `approval/request` itself fails closed; this bridge can only keep
-   "nobody answered" as "nobody answered"). `pnpm test:webview` asserts these four plus the host-side whitelist.
+   "nobody answered" as "nobody answered"). `pnpm test:ask-dialog` asserts these four plus the host-side whitelist.
 3. **Any request carrying `Origin` gets 403.** Browsers always send one (including a sandboxed iframe's literal
    `Origin: null`); the Node extension host never does. Origin is checked **before** the token — otherwise the
    bridge would be a "did you guess the token right" oracle for a web page.
@@ -379,6 +399,64 @@ as stated for the loopback port.
 Diagnostics: `GET /api/code-server/status` exposes
 `bridge: { enabled, live, toolsRegistered, supported, url, file }` — **never the token** (that only exists in the file).
 
+## FIM completion (experimental, since 0.3.61, **off by default**)
+
+When you pause while typing, a grey continuation appears after the cursor (Tab accepts, Esc discards).
+It is **off by default**; turn it on with that row in the settings card — it takes effect immediately
+(no host restart, no reinstall).
+
+| Item | Value |
+|---|---|
+| Endpoint | DeepSeek **FIM (Beta)**: `POST https://api.deepseek.com/beta/completions`, params `prompt` (prefix) + `suffix` (suffix) |
+| Model | `deepseek-flash` (the model the official FIM doc uses — also this deployment's default) |
+| Credential | Reuses the `DEEPSEEK_API_KEY` DSH already has: `ctx.get('credentials').resolve(...)`, the same path the official adapter takes (falling back to the launch environment) |
+| Measured latency | **112–416 ms** (non-streaming; streaming was *slower*, hence non-streaming on purpose) |
+| When it fires | After a ≥250 ms pause and only past the gates: non-empty selection / non-`file` document / empty context / document >20k lines — those **never send a request** |
+
+**How it is wired in (option A)**: FIM speaks the Completions API, while `ctx.llm.stream(GenerateOptions)`
+only knows `messages` (no `prompt`/`suffix`; `purpose` is a closed union of `'compaction' | 'session-title'`).
+So the plugin **registers its own LLM adapter route** `dshcs-fim`: the prefix/suffix travel inside a
+`messages` envelope with a fixed marker (`dshcs-fim/1 `), and the adapter decodes it before hitting that
+endpoint. The call therefore still goes **through DSH's LLM service** — cancellation, timeouts, terminal
+chunks and stable error codes all follow the service contract (instead of the plugin bypassing it with a
+raw fetch). Evidence and measurements: B6/B7 of `docs/analysis-continuedev-reuse.md`.
+
+**Three knobs (0.3.62, all in the settings card, effective immediately)**:
+
+| Setting | Default | Effect |
+|---|---|---|
+| Pause in ms | `250` | How long typing must stop before a request. Range 100–3000 ms (clamped on save); the endpoint round trip measured **112–416 ms**, so the pause *is* the perceived latency |
+| Allow multi-line | on | Off ⇒ the host returns the first line only; an empty first line means no completion. Turn it off to be less intrusive |
+| Disable by glob | empty | In these files **no request is sent at all**. Semantics: `*` does not cross directories, `**` does, a pattern without `/` matches the basename, a pattern with `/` matches any path suffix (so `vendor/**` and `src/*.ts` work at any depth), a trailing `/` means `/**`. Example: `*.md;vendor/**;**/dist/**` |
+
+> Both sides implement these semantics independently (the extension is a static file shipped with the package
+> and cannot import host code); `scripts/test-fim.mjs` pins their equivalence with one shared (pattern, path)
+> corpus.
+
+**Safety and bounds** (this is the only capability of the plugin that sends content out):
+
+- **Still read-only**: the extension never writes files and never runs commands — it only *proposes* text;
+  insertion happens when you press Tab;
+- The bridge gains its fifth route `POST /complete` (**the only route that makes a model call**) only while
+  the setting is on; with it off the route answers 403 and no request is made;
+- Bounded: prefix/suffix ≤6000/2000 chars (120/40 lines, whichever comes first), output ≤2000 chars,
+  4 s timeout, 120 ms minimum interval, concurrency 1, 60 calls/minute; over-limit requests are rejected
+  (409/429) and the extension simply shows no completion for that beat;
+- One more layer in the extension: turning the setting off disposes the provider immediately (no requests at
+  all), and identical context hits a local 2-minute cache;
+
+**Usage is visible in exactly two places**: these calls are **not session requests**, so they are not written
+to the session log and DSH's own token accounting (per-turn usage, context pressure, telemetry) **excludes
+them**. Usage therefore shows up in ① the IDE status bar's DSH item — a `$(zap) 1.2k` counter when on, with
+input/output/cache-read/last-latency/last-error on hover, and ② the `fim` field of
+`GET /api/code-server/status` (same snapshot).
+
+**Known limits**: the model occasionally invents an insertion where nothing is needed (2/2 reproduced at a
+cursor position that needed none); the filter pipeline strips code fences and control markers, but "should
+this be completed at all" stays your call — Esc or typing on makes it disappear. A more reliable shape needs
+a faster completion route, or DSH making completion a first-class request (at which point only the adapter's
+data call changes; the caller stays as it is).
+
 ## Legacy DSH (unsupported since 0.2.3)
 
 **Behaviour**: when `sidebarRightTabs` / `sidebarRight` cannot be found, the plugin registers a single settings card:
@@ -438,10 +516,11 @@ Diagnostics: `GET /api/code-server/status` exposes
   crash/exit updates status live; after a DSH host restart the plugin **adopts** a still-running instance (verifies pid + `/healthz`), without duplicate start or killing unrelated processes;
 - `node_modules` and the pack-time artifact `vendor/` are git-ignored; after cloning, follow
   "Install the plugin (script-free install; code-server bundled)" below — `pnpm install` → `pnpm run vendor:vscode` →
-  `pnpm run build:webview` → `pnpm pack` + `dsh plugin --profile web add` (the client half has no build step).
+  `pnpm pack` + `dsh plugin --profile web add` (after 0.3.58/0.3.59 the client half **and** the ask panel are
+  committed hand-written source: there is no build step anywhere on that chain).
 
 > Verified locally (BM: Windows 11 ARM64): the whole tree/dependency chain hangs directly off the plugin's
-> dependency table — the tree package `@jinsiyu/dshcs-vscode-server` (currently 4.137.0, a 50.8 MB tarball),
+> dependency table — the tree package `@jinsiyu/dshcs-vscode-server` (currently 4.138.0, a 50.9 MB tarball),
 > the pure-JS inner dependencies plus the 8 platform-independent repacks in `dependencies`, and the 8
 > platform-specific repacks (win32-arm64 / win32-x64) in `optionalDependencies` with their own os/cpu gates;
 > the original names are restored by junctions created at runtime (`lib/native.js`)
@@ -452,13 +531,12 @@ Diagnostics: `GET /api/code-server/status` exposes
 
 ```powershell
 cd C:\Users\User\Desktop\dsh-code-server-app
-pnpm install             # dev deps (esbuild + the official-renderer bundling deps); allowBuilds is explicit → no postinstall runs
-pnpm run build:webview   # ask panel: official Markdown renderer + panel shell → webview/thread.{js,css} (not committed; must be built first)
+pnpm install             # one dev dependency left (@deepseek-ai/schemastery); allowBuilds is explicit → no postinstall runs
 pnpm run vendor:check    # optional: show the bundled tree version vs the latest code-server release
 pnpm run vendor:vscode                            # ① produce vendor/vscode (the trimmed VS Code tree, ~197MB)
 pnpm run repack:build -- --target win32-arm64,win32-x64 --pack   # ② one script builds every sub-package
 pnpm run publish:repacks                         # ③ publish every @jinsiyu/* sub-package (default dist-tag: next)
-pnpm pack                                        # ④ → dsh-code-server-app-<version>.tgz (~750KB, including the panel renderer assets)
+pnpm pack                                        # ④ → dsh-code-server-app-<version>.tgz
 pnpm run publish:plugin                          # ⑤ publish the plugin itself (default dist-tag: next)
 # once the user has restarted dsh web and confirmed it works, promote latest:
 pnpm run promote -- <version>
@@ -473,13 +551,11 @@ pnpm run promote -- <version>
 > so their dist-tags do not affect resolution, but they default to `next` as well.
 > Inspect the current tags with `npm dist-tag ls dsh-code-server-app`.
 
-> `build:webview` bundles DSH's **official** Markdown renderer and design tokens into the panel assets
-> (~1.34MB: 996KB JS + 87KB CSS + 254KB KaTeX fonts), so it needs a local DSH deployment: the script reads the
-> `@deepseek-ai/dsh-web-frontend` version from that deployment and compares it with the renderer version pinned in
-> devDependencies — a mismatch **fails the build** (unless `--allow-version-mismatch`). Same convention as
-> `lib/client.js`: the artifacts are not committed and `prepack` rebuilds them.
-> Rationale (why not an iframe, where the tokens come from, size trade-offs) is section 21 of
-> `docs/analysis-code-server-as-dsh-plugin.md`.
+> **There is no build step on this chain**: `lib/client.js` — including the "ask DSH" dialog panel — is committed
+> hand-written source, and so is the extension (plain JS). `prepack` is down to `vendor:vscode`, the published
+> package carries no frontend bundle, and `devDependencies` holds exactly one entry (`@deepseek-ai/schemastery`,
+> used by the tests).
+> The per-version analysis of the panel and the DSH page lives in `docs/analysis-code-server-as-dsh-plugin.md`.
 
 `repack:build` (`scripts/vendor-repacks.mjs`) is the **single script that produces every sub-package**:
 
@@ -492,7 +568,7 @@ pnpm run promote -- <version>
 | Goal | Command |
 |---|---|
 | **Build from the latest upstream release** | `pnpm run vendor:latest` (= `--force`): pulls `code-server@latest`'s tree into `vendor/vscode`; afterwards you **must** re-run `repack:build` and republish every sub-package |
-| **Pin a version** | `pnpm run vendor:vscode -- --version 4.137.0` |
+| **Pin a version** | `pnpm run vendor:vscode -- --version 4.138.0` |
 | **Snapshot from an existing tree** | `pnpm run vendor:vscode -- --from <code-server dir>` (seconds) |
 | **Rebuild every sub-package** | `pnpm run repack:build -- --target win32-arm64,win32-x64 --pack` (without `--from` it npm-installs and compiles the source tree itself — slow) |
 | **Rebuild only the tree + dependency table** | `node scripts/vendor-repacks.mjs --reuse --target win32-arm64,win32-x64 --pack` (reuses the natives already in `repack/build`; also rewrites `lib/vendored.json` and the plugin dependency table) |
@@ -513,7 +589,7 @@ Both workflows live in `.github/workflows/`, and the regression list exists exac
 
 | Workflow | Trigger | What it does |
 |---|---|---|
-| `ci.yml` | push to `main` / PR / manual | `ubuntu-latest` + `windows-latest` matrix: `pnpm install --frozen-lockfile` → `build:webview` → `pnpm test` (the whole suite) → `vendor:check` (report only) → upload the panel assets |
+| `ci.yml` | push to `main` / PR / manual | `ubuntu-latest` + `windows-latest` matrix: `pnpm install --frozen-lockfile` → `pnpm test` (the whole suite; since 0.3.59 there is **no build step in front of it**) → `vendor:check` (report only) |
 | `release.yml` | push a `v<version>` tag / manual (rehearsal, never publishes) | prepares `vendor/vscode` **at the version pinned in `dependencies`** → builds → full suite → `pnpm pack` → verifies the tarball manifest → **really installs it twice** (windows-latest proves the 16 win32 sub-packages, ubuntu-latest the 10 Linux ones: each deploys a real DSH, installs via the official path `dsh plugin --profile web add <tgz>`, then runs the `test:installed` + `dump-config` assertions; both legs must pass before anything is published) → publishes to npm **`next`** → creates a GitHub Release with the tgz attached |
 | `linux-repack-probe.yml` | push to this file / manual | **feasibility probe (never publishes; superseded by the Linux legs of `repacks.yml`)**: on Linux, builds the platform-specific repack packages per target (`linux-x64` → `ubuntu-latest`, `linux-arm64` → `ubuntu-24.04-arm`) and reports which modules really produce a `.node` and which are Windows-only. It runs the existing `vendor-repacks.mjs` itself; all writes happen in a copy of the repo under `$RUNNER_TEMP`. **Note**: it emits one notice per module, which hits GitHub's ~20-annotations-per-check-run cap and leaves only the tail; for the full verdict use the Linux legs of `repacks.yml` (one summary line per target) |
 | `repacks.yml` | manual (`publish` and `probe_oidc` both default to **false**, the four `build_*` legs default to **true**) / push to this file / push `.github/oidc-probe.enabled` | **builds and publishes the platform-specific sub-packages** (`@jinsiyu/dshcs-*`): one host-architecture runner per target (`win32-x64` → `windows-latest`, `win32-arm64` → `windows-11-arm`, `linux-x64` → `ubuntu-latest`, `linux-arm64` → `ubuntu-24.04-arm`); by default it only builds and uploads `repack/tgz/*.tgz`, and only publishes to npm (default `next`) when `publish` is checked. Ownership and ordering (**five legs, disjoint sets**): the `independent` leg runs **first** (windows-latest; it produces the **VS Code tree package + the 8 platform-independent repacks**, which are the same artifact for all four targets and are therefore published only once); the four platform-specific legs `needs: independent`, build with `--skip-independent` and publish with `--only <their own target>` ⇒ a broken base layer blocks the rest (no half-published state) and no package name is ever published twice. **Auth**: with no `NPM_TOKEN` it uses OIDC (per-package trust entries, all with workflow `repacks.yml` — see below). The Linux legs additionally verify that the `lib/vendored.json` / `package.json` they generate match the committed ones (the platform policy is meant to be host-independent). A `probe-oidc` job additionally does a **staged-only** probe of that OIDC route, so the channel can be proven without publishing anything real |
@@ -612,8 +688,8 @@ pnpm test:apply              # apply() under a stub ctx
 pnpm test:claim-types        # claim-type syntax and defaults
 pnpm test:bridge-routes      # bridge route whitelist (read-only + /approve + /old) / Origin-vs-token order / token header agreement
 pnpm test:edit-snapshot      # pre-write snapshots: value.before from tools/post-execute, session-cwd path resolution, triple-bounded cache, /old's 400-404-200
-pnpm test:bridge-extension   # extension-side pure logic (dirty buffers, diagnostics, diff old-side priority, delivery, panel state)
-pnpm test:webview            # panel bundle: official renderer + tokens, version match, the four /approve constraints
+pnpm test:bridge-extension   # extension-side pure logic (dirty buffers, diagnostics, diff old-side priority, delivery, ask intent + "dialog unavailable" notice)
+pnpm test:ask-dialog         # ask-dialog wiring: no artifacts/build chain left, the host's four ask routes, the extension only reporting editor state, the four approval constraints, the bridge's safety invariants
 pnpm test:launcher-routes    # launcher HTTP surface (spawns a real process; slow)
 pnpm test:workspace-switch   # switching workspaces does not restart the process
 pnpm test:workspace-cwd      # "current workspace directory" resolution (DSH 0.1.6-alpha.2 sessionId vs. the older current)
@@ -726,9 +802,6 @@ one itself (with no `NPM_TOKEN` it uses OIDC):
   probe versions (`npm stage list`, then `npm stage reject <id>`; needs 2FA on your machine) — do **not**
   approve, since approving is what would turn a probe into a real version. Delete the sentinel file to
   return to "no automatic probe".
-- **Optional** repository variable `DSH_UI_VERSION` = the version of `@deepseek-ai/dsh-web-frontend` in the current
-  deployment: when set, `release.yml` enforces that the panel renderer matches the deployed UI (the local
-  `build:webview` always checks this; a runner has no DSH deployment).
 
 Things you must know:
 
@@ -741,8 +814,9 @@ Things you must know:
   assertion). Packing happens only in `release.yml`, after
   `node scripts/vendor-vscode-server.mjs --version <pinned>`.
 - **Release gates** (any failure stops the run; `next` is never advanced): tag ≠ `package.json.version`, the
-  version already exists on npm, the tree version does not match (`test:vendored`), the suite fails, or
-  `DSH_UI_VERSION` mismatches.
+  version already exists on npm, the tree version does not match (`test:vendored`), the suite fails, or the
+  tarball manifest / the two real-install legs disagree. (0.3.59 dropped one gate: the panel renderer no longer
+  needs to match the deployed DSH UI — it *is* that instance.)
 - `@deepseek-ai/schemastery` is a **devDependency** (pinned to 3.18.2, the version the deployment uses):
   `lib/index.js` normally takes it from the DSH deployment (in production, the copy hoisted inside the
   profile), and a clean clone / CI runner has no DSH at all — without this devDependency the `apply`-style
@@ -857,7 +931,7 @@ Costs and rules (read before editing `lib/client.js`):
 | Rule | Why | Enforced by |
 |---|---|---|
 | No top-level `import`/`export`/`await` | syntax errors in a classic script ⇒ the whole client half fails to load (empty UI) | `pnpm test:client-entry` E1 + the harness really loading it (E3) |
-| `require(...)` may only name `react` / `react/jsx-runtime` | the DSH module table is frozen; anything else throws "unknown module" | E1 |
+| `require(...)` may only name DSH module-table seed words (`react` / `react/jsx-runtime` / `react-dom/client` / `@deepseek-ai/dsh-client-ui-primitives`) | the DSH module table is frozen; anything else throws "unknown module" | E1 (and, when a local DSH install exists, it cross-checks the real `staticModules` list word by word) |
 | Every section's top-level identifiers share one scope | after inlining, a `var`/`function` collision is a **silent overwrite** (real hit: `state` existed in both the surface and the plugin body — the former is now `surfaceState`) | no automatic guard ⇒ grep before adding a top-level name |
 | The claim-types section is a **copy** | a classic script cannot reach the host module `lib/claim-types.js` | E2 compares both over a sample table |
 
@@ -865,8 +939,35 @@ Size: ~114 KB uncompressed (was a 49.7 KB minified artifact) — a one-time down
 unchanged. Test hook: the entry exports `__internals` only when `window.__dshcsTestHooks === true` (used by
 `test-workspace-cwd.mjs` / `test-sidebar-fullscreen.mjs` to call pure functions); DSH never sets that flag.
 
-> The ask-panel webview is **still a build artifact** (`thread.{js,css}` is untracked and produced by
-> `pnpm run build:webview`); removing that build is the next phase.
+### Why the "ask DSH" dialog has no build step
+
+The dialog's panel (conversation stream, collapsible thinking rows, approval cards, input box) lives **inside
+`lib/client.js`** — hand-written, committed, with no artifact, no `/ask/bundle`, no injected `<script>` and no fake
+`acquireVsCodeApi`.
+
+Why it can work that way: the dialog already runs **inside the DSH page**, and the shell's module table
+(`staticModules` of `dsh-web-frontend`) freezes `react` / `react/jsx-runtime` / `react-dom` / `react-dom/client` /
+`@deepseek-ai/dsh-client-ui-primitives` / … — so the panel simply requires them:
+
+- the renderer, the design tokens, the KaTeX styles and the shiki grammars **all come from the page** (the same
+  instance the DSH UI uses) ⇒ typography matches the UI and a version mismatch is impossible;
+- the panel creates its own React root via `require('react-dom/client')` (its container is the dialog's own div);
+- opening the dialog has no "fetch + parse + execute" step to wait for — there is no artifact.
+
+Costs and rules:
+
+| Rule | Why | Enforced by |
+|---|---|---|
+| CSS injected into the page may only target `.dshcs-*` | the styles land in DSH's own document; touching `:root`/`body` would restyle the whole UI | `pnpm test:ask-panel` P3 (every selector + a ban on at-rules) |
+| Every `var(--vscode-*)` needs a fallback | the DSH page has no `--vscode-*`; a bare `var()` is invalid at computed-value time ⇒ transparent buttons/inputs | P3 |
+| A component with hooks may only be written as `React.createElement(Name, …)` | there is no JSX here; `Name({…})` puts the child's `useState` into the parent's hook chain, and a changed branch throws "Rendered more hooks than during the previous render" | P4 (source-level lookbehind regex) |
+| Official components must be resolved as "function **or** `{$$typeof}` object" | `MarkdownText` is a `React.memo` product (an **object**); testing `typeof === 'function'` silently degraded every body to `<pre>` | P4's `askComponent` cases |
+| Missing seed words / official components must degrade | the panel is the primary path; a blank panel means asking is broken | P5 (`<pre>` body, native `button`) + an error boundary |
+| Three message routes (ask / approve / close) | panel and shell share one window (no postMessage), so messages must reach `/ask/send|approve|close` | P6 |
+
+The extension side has no build step either: it is plain JS (`extension.js` + `lib/*.js`) and only reports intent.
+Those two "no build step" claims are guarded by `pnpm test:client-entry` / `pnpm test:ask-panel` (the panel itself)
+and `pnpm test:ask-dialog` (the wiring, plus "not one trace of the build chain may remain").
 
 ### Development: install from source (changes take effect immediately)
 
@@ -879,13 +980,12 @@ dsh plugin --profile web add C:\Users\User\Desktop\dsh-code-server-app
 > too — but the not-yet-published local `@jinsiyu/*` packages must either be published first, or the
 > `repack/tgz/*.tgz` files must be installed into the profile as `file:` dependencies.
 >
-> **Changing the client half**: edit `lib/client.js` directly (since 0.3.58 it is **hand-written source** —
-> there is no build step and no `src/**` intermediate layer; the format rules are in that file's header and are
-> enforced by `pnpm test:client-entry`). After installing into a profile a hard refresh picks it up
-> (a host restart may be needed; the bundle rev is hashed at host start).
-> **Changing the ask panel**: edit `assets/extensions/dshcs-editor-bridge/webview/src/*` then run
-> `pnpm run build:webview` (this half is still a generated artifact, not tracked; the IDE must be restarted once
-> to pick it up, because the extension host caches the webview resources).
+> **Changing the client half / the ask dialog**: edit `lib/client.js` directly (it is **hand-written source**:
+> no build step, no `src/**` layer; the format rules are in that file's header and are enforced by
+> `pnpm test:client-entry` and `pnpm test:ask-panel`). After installing into a profile a hard refresh picks it up.
+> **Changing the extension**: edit `assets/extensions/dshcs-editor-bridge/{extension.js,lib/*.js}` (plain JS, no
+> build). The IDE side needs one restart to load the new extension code, because the extension host caches loaded
+> extensions.
 
 ### Pack-machine environment (the user machine needs nothing)
 
@@ -919,7 +1019,7 @@ dsh plugin --profile web add C:\Users\User\Desktop\dsh-code-server-app
 ### Upgrading the VS Code tree (upstream = a code-server release)
 
 - **The version is decided at pack time**: `pnpm run vendor:latest` (= `--force`) pulls the tree of the npm **latest**
-  release; or use `pnpm run vendor:vscode -- --version 4.137.0` / `DSHCS_CODE_SERVER_VERSION`.
+  release; or use `pnpm run vendor:vscode -- --version 4.138.0` / `DSHCS_CODE_SERVER_VERSION`.
   With an existing `vendor/vscode`, a plain `pnpm pack` never upgrades (it is a no-op).
   **Source-tree precedence (fixed in 0.2.13)**: an explicit `--from` uses that tree, while an explicit
   `--force`/`--version` now **always goes to the registry** — before the fix a local source tree won
@@ -934,13 +1034,14 @@ dsh plugin --profile web add C:\Users\User\Desktop\dsh-code-server-app
 - **A version bump means rebuilding and republishing the sub-packages** (all with the same script):
   1. `pnpm run repack:build -- --target win32-arm64,win32-x64 --pack` → the new tree package
      (`@jinsiyu/dshcs-vscode-server@<new version>`) and the natives rebuilt against the new inner dependencies (the
-     script also rewrites the plugin's pure-JS `dependencies` and both aggregator versions);
-  2. `pnpm run republish:repacks` (`pnpm run publish:repacks`) → publish; then bump the plugin version → `pnpm pack`
+     script also rewrites the plugin's pure-JS `dependencies`, writes the 16 repacks under their real names into
+     `dependencies` / `optionalDependencies`, and rewrites `lib/vendored.json`);
+  2. `pnpm run publish:repacks` → publish; then bump the plugin version → `pnpm pack`
      → publish the plugin.
 - `productPath` (`<quality>-<commit>`, part of the client WebSocket path) is **computed from `lib/vscode/product.json`**,
   so upgrading the tree needs no code change — but the routes are registered at activation, so restart `dsh web` afterwards.
 - **No runtime auto-upgrade anymore**: nothing fetches latest at startup; the version is fully determined by the bundled artifact.
-- Bundled locally right now: the tree of `code-server@4.137.0` (VS Code 1.137.0, `productPath=stable-b11dabda…`).
+- Bundled locally right now: the tree of `code-server@4.138.0` (VS Code 1.138.0, `productPath=stable-59c988c7…`).
 
 ### Compatibility with the old install locations
 
@@ -959,8 +1060,12 @@ persisted via the official settings domain (`settingsScope`, namespace `code-ser
 | `claimExtensions` | `*` + three exclusion groups (preview-friendly / executables / Office; full lists in the "Claim types" section) | **Claim types** (0.2.11, replaces 0.2.5's `fileOpenScope`): decides by extension which files go to VS Code, semicolon-separated; `*` claims every other type, `!ext` excludes (exclusion wins). The default leaves the four categories DSH's preview renders well (markdown/html/images/PDF) to DSH and sends everything else to the IDE; an empty value claims nothing. **Scope (session vs absolute) is no longer distinguished** |
 | `fullscreenOnOpen` | `true` | **Fullscreen on open** (0.2.9): opening the Code Server tab (including clicking a file) switches the right sidebar to fullscreen (fills the window); off keeps DSH's default push mode (side by side with the conversation). Only the moment of opening is affected — a manual "Exit fullscreen" is never fought back |
 | `keepResident` | `true` | **Resident in background**: on, the host preloads the IDE into a parked surface right after start — switching tabs or collapsing the sidebar never reloads it and the first open needs no cold start; off loads it only when the panel is opened (saves memory) |
+| `fim` | `false` | **FIM completion (experimental, 0.3.61)**: when on, pausing while typing shows a grey inline continuation (Tab accepts, Esc discards). **Off by default** — it is the only capability of this plugin that sends content out (a bounded slice of code around the cursor, per completion), and those calls **do not enter DSH's token accounting**, so usage is visible only in the IDE status bar. See the "FIM completion" section |
+| `fimDebounceMs` | `250` | **FIM · pause in milliseconds** (0.3.62): how long typing must stop before one completion request is sent. Effective range **100–3000 ms**, clamped on save (same rule as the host); empty/invalid falls back to 250 |
+| `fimMultiline` | `true` | **FIM · allow multi-line completions** (0.3.62): off means the host returns the first line only (an empty first line = no completion this time). The model does invent insertions where none are needed, and multi-line amplifies that noise |
+| `fimDisableGlobs` | empty | **FIM · disable by glob** (0.3.62): semicolon/newline separated. `*` does not cross directories, `**` does, a pattern without `/` matches the basename, a pattern with `/` matches any path suffix, and a trailing `/` means `/**`. Examples: `*.md`, `vendor/**`, `**/dist/**`. **Checked on both sides**: the extension first (no request at all), the host again |
 
-(Since 0.2.9 the card keeps only those three settings; `windowedOpen` and `reserveComposer` are gone — leftover keys in an old
+(Since 0.2.9 the card keeps only those settings (0.3.61 added FIM completion, 0.3.62 its three sub-rows); `windowedOpen` and `reserveComposer` are gone — leftover keys in an old
 settings document neither fail nor apply. `serve` remains a key in the settings namespace (usable from a settings document) but
 has **no card row** — see "Serving mode".)
 
@@ -1093,6 +1198,22 @@ What remains on the plugin side:
   **built-in** extension (in `lib/vscode/extensions`), so users cannot remove it from the extensions panel, and the
   installer re-syncs it whenever its content changes.
 
+## Third-party and license
+
+This project is **MIT**-licensed (see [`LICENSE`](LICENSE)). Its experimental **FIM completion** feature was
+**designed with reference to** [continuedev/continue](https://github.com/continuedev/continue)
+(Apache License 2.0, Copyright 2023 Continue) — specifically the settings taxonomy of upstream
+`tabAutocompleteOptions` (`debounceDelay`, `useAutocompleteMultilineCompletions`, `disableInFiles`) and its
+debounce / cursor-window / filtering / bounded-cache approach.
+
+**No source code, template strings or files from continuedev/continue are included here** (completion
+requests target DeepSeek's official FIM (Beta) endpoint; the prompt shape comes from DeepSeek's docs and
+local measurement). The standard Apache License 2.0 text ships as
+[`LICENSE-Apache-2.0.txt`](LICENSE-Apache-2.0.txt), and the per-location reference log is
+[`THIRD_PARTY_NOTICES.md`](THIRD_PARTY_NOTICES.md) — so Apache-2.0's obligations (notices, marking modified
+files, keeping an upstream NOTICE if one appears) are already satisfied should a code fragment ever be ported
+in. Apache-2.0 grants no trademark rights; this project does not use "Continue" as a name or in promotion.
+
 ## Known limitations
 
 - **~~The editor bridge needs DSH to provide `webServer`~~ no longer true (fixed in 0.3.13)**: the bridge now runs
@@ -1105,16 +1226,12 @@ What remains on the plugin side:
   or by simply calling `editor_context` — 0.3.0–0.3.11 sat in the state "health says bridge:true, extension never
   loaded" (cause above: the user-level install was marked `.obsolete`).
 - **Bridged state can lag by up to 600 ms**, and the tools say "stale" rather than serving data older than 10 s.
-- **The ask panel renders only "new content" (0.3.22)**: the subscription starts when the panel opens, the history
+- **The dialog renders only "new content"**: the subscription starts when the dialog opens, the history
   `records` from `follow`'s opening frame are discarded, and the panel has **no "load earlier"** (the history-paging
   API `sessionController.page()` is deliberately not called in this version). Switch to the DSH UI for older content.
-- **Panel highlighting ships only DSH's boot grammar set** (typescript / shellscript / json): the rest of the
-  official grammars load lazily through `import()` (~1.6MB total), and the panel is a single-file IIFE with no
-  lazy loading, so those languages render as plain text (exactly like DSH's own first render, no errors).
-  For the full set: `node scripts/build-webview.mjs --all-grammars`.
-- **Panel assets are pinned to the DSH version**: the renderer is bundled against the UI version of the deployed
-  DSH, so after upgrading DSH you must rebuild the panel (`pnpm run build:webview`; the build fails loudly on a
-  version mismatch). The panel also shows a mismatch notice at runtime instead of silently using the wrong renderer.
+- **Highlighting follows DSH's own lazily-loaded grammar set**: the panel uses the page's renderer instance, so
+  there is no "the artifact only carries a few grammars" limitation.
+- **A renderer version mismatch is impossible**: the panel requires the very instance the UI uses.
 - **The approval window in the panel is 5 minutes**: while the panel is open, approvals ask the panel first (the card
   shows a countdown); **closing the panel** or letting the 5 minutes run out hands the request back to the DSH UI —
   after that, that request can **only** be answered there (the card disappears from the panel and the thread keeps an