jupyterlab_ai_code_assistants_extension 0.6.17 → 1.0.17

package/README.md

@@ -33,13 +33,14 @@ Chat-panel extensions re-implement the agent loop and trail the real tool. This
 - **Conversation switcher** - a right-click "Switch and Manage Sessions" submenu lists a project's other conversations by name and short id with last-activity time; "Manage Sessions..." opens a searchable popup over the full list with multi-select delete and per-row open and copy-id buttons
 - **Branch session** - fork the current conversation into a new named session via the right-click menu; each assistant forks its own way (Claude's native `--fork-session`, Codex's `codex fork`, server-side copies for Kimi and Gemini) behind the same menu item
 - **Launch modes under each assistant's own name** - Claude's skip-permissions, Codex's approval bypass, Kimi's `--yolo`, Gemini's YOLO and approval modes; unsafe variants carry a warning glyph
-- **Coloured terminal tabs** - each session's colour tints its terminal tab via the companion `jupyterlab_colourful_tab_extension` (installed automatically). Assistants without a colour concept get a stable colour from the extension's own store, and a branched session inherits its parent's colour
+- **Coloured terminal tabs** - each session's colour tints its terminal tab via the companion `jupyterlab_colourful_tab_extension` (installed automatically). Claude's own `/color` supplies its default, Kimi derives a stable colour from the conversation id; Codex and Gemini have no colour of their own until you set one, and a branched session inherits its parent's colour, which it keeps even if the parent's colour later changes or is reset
+- **Your own tab colour wins** - set a colour on a terminal tab and the extension remembers it for that conversation, overriding whatever the assistant chose. `Reset Tab Colour (n)` in the session's right-click menu hands back every colour you set by hand on that project's conversations, and appears once there is one to hand back. Use it rather than the tab menu's own Clear, which will not release a stored colour. A Codex or Kimi conversation that has never been resumed cannot be tracked yet, so a colour set on its tab is not kept
 - **Favorites** - star projects you keep coming back to via the right-click menu; favourites from the standalone extensions are migrated on first run
 - **Remove and clean up** - drop a project's history or a project's extra parallel sessions from the right-click menu, confirmation dialog first; removed files honour JupyterLab's "move files to trash" setting
 - **Activity at a glance** - each row shows its last activity in an aligned column; rows active within the last minute light up, rows idle for over a week dim, and rows with parallel conversations show a branch icon with the count
 - **Remote control indicator and background agents** (Claude) - a green dot marks sessions actively under remote control, and a conversation held by a running background agent shows a `bg` chip; clicking attaches to the agent instead of copying it
 - **Search** - fuzzy filter per panel, toggled by the funnel button
-- **Presentation modes** - label rows by session name, folder name, or path relative to the JupyterLab root
+- **Presentation modes** - label rows by session name or by path relative to the JupyterLab root
 - **Conflict-safe upgrade** - if a retired standalone extension is still installed, its panel wins and this extension stands down for that assistant instead of showing a duplicate
 - **Auto-disabled when absent** - an assistant whose CLI is not on `PATH` does not show a panel
 
@@ -74,6 +75,8 @@ This package supersedes `jupyterlab_claude_code_extension`, `jupyterlab_codex_ex
 pip uninstall jupyterlab_claude_code_extension jupyterlab_codex_extension jupyterlab_kimi_code_extension
 ```
 
+Tab colours stored by versions of THIS extension before 1.0.0 are carried over and keep tinting their tabs, but `Reset Tab Colour` will not offer them: the store from that version cannot tell a colour you set from one a branch inherited, and offering the wrong one would strip a branch of the colour it was forked with. Set the colour on that tab once more and it becomes yours to reset.
+
 While a standalone extension is still installed, its panel is shown and this extension's panel for that assistant stays out of the way.
 
 ## Uninstall

package/lib/core/colour.d.ts

@@ -8,14 +8,24 @@ export declare const TAB_COLOUR_IDS: readonly string[];
 /** Map a conversation id onto one of the six colour ids. FNV-1a (32-bit) - a
  * stable string hash with good avalanche on short hex-ish ids; `Math.imul`
  * keeps the multiplication in 32-bit integer semantics. The same id always
- * yields the same colour, on every reload and in every browser. */
+ * yields the same colour, on every reload and in every browser.
+ *
+ * Hashed over the id's UTF-8 BYTES, which is what FNV-1a is defined over and
+ * what the Python half hashes too. The natural idiom on each side disagrees:
+ * `charCodeAt` walks UTF-16 units and Python's `ord` walks code points, so an
+ * id outside the BMP hashed differently on the two runtimes - measured, "𝕏id"
+ * tinted rose in the browser and peach on the server (DEF-52). Bytes are the
+ * one reading both languages spell naturally, so the drift cannot come back
+ * the next time somebody rewrites either loop. Every real conversation id is
+ * ASCII, where all three readings coincide, so no existing tab changes colour. */
 export declare function fnv1aColour(sessionId: string): string;
 /** Colour the user set by hand on a terminal tab, or null.
  *
  * The colourful-tab extension stores its right-click menu choices as
  * `{ "terminal:<session name>": <index into TAB_COLOUR_IDS> }`. Reading it is
  * what makes "set the colour on the tab" register as the conversation's
- * colour for assistants whose CLI has no colour concept at all. */
+ * colour - for every assistant, including one whose CLI has a colour concept
+ * of its own. */
 export declare function readUserSetTabColour(terminalName: string): string | null;
 /** Resolve the ladder for one conversation. `userSet` is this extension's own
  * store, `native` the conversation's own colour (only ever populated by a
@@ -34,24 +44,107 @@ export declare function sessionForCwds(cwds: string[], sessions: ISession[]): IS
  * colours survive a reload and one assistant's colours can never be read or
  * written through another's routes. Reads are cached in memory and refreshed
  * with the session poll; writes go straight through and update the cache.
+ *
+ * Every request this store makes is queued behind the last - see `_run`. That
+ * one rule is what keeps the class small: with only one of its requests ever on
+ * the wire, no answer can be older than something the cache has already taken,
+ * so none of the ordering questions this class used to carry can be asked.
  */
 export declare class ColourStore {
     constructor(providerId: string, serverSettings: ServerConnection.ISettings);
     /** User-set colour for a conversation, from the in-memory cache. */
     get(sessionId: string | null | undefined): string | null;
+    /** Whether this conversation's colour is the user's own choice rather than
+     * one it inherited at fork time. Only a hand-set colour is offered for
+     * release: dropping an inherited one would un-inherit the branch. */
+    isOverride(sessionId: string | null | undefined): boolean;
+    /** Whether a write against this conversation is still unanswered - queued
+     * behind an earlier request of this store's, or on the wire.
+     *
+     * Read by the release affordance - see the filter in `_openContextMenu` for
+     * why it must not offer a colour still being written. Counted from the CALL
+     * rather than from the moment the request goes out: with the store
+     * serialised (DEF-30) a capture can sit in the queue before it is sent, and a
+     * release offered in that window is undone by the capture landing after it.
+     *
+     * Not consulted by the capture gate - the cache holds only confirmed values,
+     * so reading it is already the confirmation. */
+    isPending(sessionId: string | null | undefined): boolean;
     /** Reload the whole store. Failures leave the previous cache in place - a
-     * momentarily unreachable server must not clear every user colour. */
+     * momentarily unreachable server must not clear every user colour.
+     *
+     * The answer is taken whole. It is the only answer whose snapshot the caller
+     * ordered, and nothing this store wrote can be missing from it: the GET is
+     * not sent until every earlier write of this store's has been answered. */
     load(): Promise<void>;
+    /** Queue one request behind every request this store has already issued, and
+     * answer what it answers.
+     *
+     * This is the store's entire ordering discipline (DEF-30). Only one of its
+     * requests is ever on the wire, so an answer can never describe a moment
+     * older than one the cache has already taken. The monotonic write counter,
+     * the per-id record of the latest write and the reload generation that used
+     * to live here could only ever describe interleavings that are now
+     * unconstructible.
+     *
+     * A failed request must not poison the queue - one refused write stopping
+     * every later load, capture and release for the rest of the session is the
+     * same defect this change removes, relocated. Two things hold that, and only
+     * the first is reachable by test: each op catches its own failure and answers
+     * false, so no link rejects today; and the tail waits for SETTLEMENT rather
+     * than success, so `_chain` still cannot reject if a later edit puts throwing
+     * code outside an op's own `try` - `forget`'s filter already sits there.
+     *
+     * `requestAPI` bounds every request at `REQUEST_TIMEOUT_MS` (DEF-72), so a
+     * queued op waits a bounded time even against a server that never answers.
+     * The ceiling is per request, so K ops queued behind a dead server wait K
+     * times it, not it.
+     *
+     * An op must never call `load`, `set` or `forget` - it would wait on a chain
+     * that is waiting on it. `inherit` delegates to `set` from OUTSIDE the queue,
+     * which is why it is not itself queued. */
+    private _run;
+    /** Open a write against one or more ids. Counted, not flagged: two writes to
+     * one id can be queued at once, and a flag would let the first to settle
+     * clear the second's guard. */
+    private _openWrite;
+    /** Close it. */
+    private _closeWrite;
     /** Record a colour as this conversation's own. Passing null drops the entry,
-     * which is also how a deleted conversation leaves no orphan key behind. */
-    set(sessionId: string, colour: string | null): Promise<void>;
-    /** Drop stored colours for conversations that no longer exist. */
-    forget(sessionIds: string[]): Promise<void>;
+     * which is also how a deleted conversation leaves no orphan key behind.
+     * `handSet` false marks it inherited - written on a fork's behalf rather
+     * than chosen on its tab.
+     *
+     * Answers whether the store now HOLDS the colour, which is what
+     * `reconcileColours` gates its paint on.
+     *
+     * The cache is written only once the server has confirmed. Writing it
+     * eagerly and undoing that on failure looks cheaper and is not: nothing here
+     * reads the cache before this promise settles, while an unconfirmed entry is
+     * indistinguishable from a stored one to every reader - which is exactly the
+     * mistake the gate above exists to catch.
+     *
+     * "Did not throw" is not the test - the answer carries the whole store, so
+     * it is checked for the value that was just written. A server that accepted
+     * the request and then failed to persist it would otherwise be believed. */
+    set(sessionId: string, colour: string | null, handSet?: boolean): Promise<boolean>;
+    /** Drop stored colours - conversations that no longer exist, or overrides
+     * the user released. One request for the whole list, so a release is never
+     * left half applied. Same contract as `set`: the answer is checked for the
+     * absence of every id, and the cache is touched only once it agrees. */
+    forget(sessionIds: string[]): Promise<boolean>;
     /** Copy the parent's EFFECTIVE colour onto a fresh branch, so a branch of a
      * branch inherits whatever its immediate parent actually shows, user-set
-     * override included. Called at the fork sites, once the new id is known. */
+     * override included. Called at the fork sites, once the new id is known.
+     */
     inherit(parentColour: string | null, childId: string): Promise<void>;
     private readonly _providerId;
     private readonly _serverSettings;
     private _colours;
+    private _overrides;
+    /** Unanswered writes per id, counted from the call. Read by the release
+     * affordance, which must not offer a colour still being written. */
+    private _pending;
+    /** Tail of this store's request queue - see `_run`. Never rejects. */
+    private _chain;
 }

package/lib/core/colour.js

@@ -29,11 +29,20 @@ const TAB_COLOUR_STORAGE_KEY = 'jupyterlab-colourful-tab-colours';
 /** Map a conversation id onto one of the six colour ids. FNV-1a (32-bit) - a
  * stable string hash with good avalanche on short hex-ish ids; `Math.imul`
  * keeps the multiplication in 32-bit integer semantics. The same id always
- * yields the same colour, on every reload and in every browser. */
+ * yields the same colour, on every reload and in every browser.
+ *
+ * Hashed over the id's UTF-8 BYTES, which is what FNV-1a is defined over and
+ * what the Python half hashes too. The natural idiom on each side disagrees:
+ * `charCodeAt` walks UTF-16 units and Python's `ord` walks code points, so an
+ * id outside the BMP hashed differently on the two runtimes - measured, "𝕏id"
+ * tinted rose in the browser and peach on the server (DEF-52). Bytes are the
+ * one reading both languages spell naturally, so the drift cannot come back
+ * the next time somebody rewrites either loop. Every real conversation id is
+ * ASCII, where all three readings coincide, so no existing tab changes colour. */
 export function fnv1aColour(sessionId) {
     let hash = 0x811c9dc5; // FNV offset basis
-    for (let i = 0; i < sessionId.length; i++) {
-        hash ^= sessionId.charCodeAt(i);
+    for (const byte of new TextEncoder().encode(sessionId)) {
+        hash ^= byte;
         hash = Math.imul(hash, 0x01000193); // FNV prime
     }
     return TAB_COLOUR_IDS[(hash >>> 0) % TAB_COLOUR_IDS.length];
@@ -43,7 +52,8 @@ export function fnv1aColour(sessionId) {
  * The colourful-tab extension stores its right-click menu choices as
  * `{ "terminal:<session name>": <index into TAB_COLOUR_IDS> }`. Reading it is
  * what makes "set the colour on the tab" register as the conversation's
- * colour for assistants whose CLI has no colour concept at all. */
+ * colour - for every assistant, including one whose CLI has a colour concept
+ * of its own. */
 export function readUserSetTabColour(terminalName) {
     var _a;
     try {
@@ -106,10 +116,21 @@ export function sessionForCwds(cwds, sessions) {
  * colours survive a reload and one assistant's colours can never be read or
  * written through another's routes. Reads are cached in memory and refreshed
  * with the session poll; writes go straight through and update the cache.
+ *
+ * Every request this store makes is queued behind the last - see `_run`. That
+ * one rule is what keeps the class small: with only one of its requests ever on
+ * the wire, no answer can be older than something the cache has already taken,
+ * so none of the ordering questions this class used to carry can be asked.
  */
 export class ColourStore {
     constructor(providerId, serverSettings) {
         this._colours = new Map();
+        this._overrides = new Set();
+        /** Unanswered writes per id, counted from the call. Read by the release
+         * affordance, which must not offer a colour still being written. */
+        this._pending = new Map();
+        /** Tail of this store's request queue - see `_run`. Never rejects. */
+        this._chain = Promise.resolve();
         this._providerId = providerId;
         this._serverSettings = serverSettings;
     }
@@ -121,70 +142,217 @@ export class ColourStore {
         }
         return (_a = this._colours.get(sessionId)) !== null && _a !== void 0 ? _a : null;
     }
+    /** Whether this conversation's colour is the user's own choice rather than
+     * one it inherited at fork time. Only a hand-set colour is offered for
+     * release: dropping an inherited one would un-inherit the branch. */
+    isOverride(sessionId) {
+        return !!sessionId && this._overrides.has(sessionId);
+    }
+    /** Whether a write against this conversation is still unanswered - queued
+     * behind an earlier request of this store's, or on the wire.
+     *
+     * Read by the release affordance - see the filter in `_openContextMenu` for
+     * why it must not offer a colour still being written. Counted from the CALL
+     * rather than from the moment the request goes out: with the store
+     * serialised (DEF-30) a capture can sit in the queue before it is sent, and a
+     * release offered in that window is undone by the capture landing after it.
+     *
+     * Not consulted by the capture gate - the cache holds only confirmed values,
+     * so reading it is already the confirmation. */
+    isPending(sessionId) {
+        var _a;
+        return !!sessionId && ((_a = this._pending.get(sessionId)) !== null && _a !== void 0 ? _a : 0) > 0;
+    }
     /** Reload the whole store. Failures leave the previous cache in place - a
-     * momentarily unreachable server must not clear every user colour. */
+     * momentarily unreachable server must not clear every user colour.
+     *
+     * The answer is taken whole. It is the only answer whose snapshot the caller
+     * ordered, and nothing this store wrote can be missing from it: the GET is
+     * not sent until every earlier write of this store's has been answered. */
     async load() {
-        var _a;
-        try {
-            const data = await requestProvider(this._providerId, 'colours', this._serverSettings, { cache: 'no-store' });
-            const next = new Map();
-            for (const [id, colour] of Object.entries((_a = data.colours) !== null && _a !== void 0 ? _a : {})) {
-                if (typeof colour === 'string' && colour) {
-                    next.set(id, colour);
+        return this._run(async () => {
+            var _a, _b;
+            try {
+                const data = await requestProvider(this._providerId, 'colours', this._serverSettings, { cache: 'no-store' });
+                const next = new Map();
+                for (const [id, colour] of Object.entries((_a = data.colours) !== null && _a !== void 0 ? _a : {})) {
+                    if (typeof colour === 'string' && colour) {
+                        next.set(id, colour);
+                    }
                 }
+                // A store with no hand-set ids named predates the distinction, and
+                // nothing in it counts as hand-set - `colour_store._read` carries the
+                // asymmetry argument for that choice.
+                this._overrides = new Set(((_b = data.overrides) !== null && _b !== void 0 ? _b : []).filter(id => next.has(id)));
+                this._colours = next;
+            }
+            catch (_err) {
+                // Keep the cache; the next poll retries.
             }
-            this._colours = next;
+        });
+    }
+    /** Queue one request behind every request this store has already issued, and
+     * answer what it answers.
+     *
+     * This is the store's entire ordering discipline (DEF-30). Only one of its
+     * requests is ever on the wire, so an answer can never describe a moment
+     * older than one the cache has already taken. The monotonic write counter,
+     * the per-id record of the latest write and the reload generation that used
+     * to live here could only ever describe interleavings that are now
+     * unconstructible.
+     *
+     * A failed request must not poison the queue - one refused write stopping
+     * every later load, capture and release for the rest of the session is the
+     * same defect this change removes, relocated. Two things hold that, and only
+     * the first is reachable by test: each op catches its own failure and answers
+     * false, so no link rejects today; and the tail waits for SETTLEMENT rather
+     * than success, so `_chain` still cannot reject if a later edit puts throwing
+     * code outside an op's own `try` - `forget`'s filter already sits there.
+     *
+     * `requestAPI` bounds every request at `REQUEST_TIMEOUT_MS` (DEF-72), so a
+     * queued op waits a bounded time even against a server that never answers.
+     * The ceiling is per request, so K ops queued behind a dead server wait K
+     * times it, not it.
+     *
+     * An op must never call `load`, `set` or `forget` - it would wait on a chain
+     * that is waiting on it. `inherit` delegates to `set` from OUTSIDE the queue,
+     * which is why it is not itself queued. */
+    _run(op) {
+        const result = this._chain.then(op);
+        const settled = () => undefined;
+        this._chain = result.then(settled, settled);
+        return result;
+    }
+    /** Open a write against one or more ids. Counted, not flagged: two writes to
+     * one id can be queued at once, and a flag would let the first to settle
+     * clear the second's guard. */
+    _openWrite(ids) {
+        var _a;
+        for (const id of ids) {
+            this._pending.set(id, ((_a = this._pending.get(id)) !== null && _a !== void 0 ? _a : 0) + 1);
         }
-        catch (_err) {
-            // Keep the cache; the next poll retries.
+    }
+    /** Close it. */
+    _closeWrite(ids) {
+        var _a;
+        for (const id of ids) {
+            const open = ((_a = this._pending.get(id)) !== null && _a !== void 0 ? _a : 1) - 1;
+            if (open > 0) {
+                this._pending.set(id, open);
+            }
+            else {
+                this._pending.delete(id);
+            }
         }
     }
     /** Record a colour as this conversation's own. Passing null drops the entry,
-     * which is also how a deleted conversation leaves no orphan key behind. */
-    async set(sessionId, colour) {
+     * which is also how a deleted conversation leaves no orphan key behind.
+     * `handSet` false marks it inherited - written on a fork's behalf rather
+     * than chosen on its tab.
+     *
+     * Answers whether the store now HOLDS the colour, which is what
+     * `reconcileColours` gates its paint on.
+     *
+     * The cache is written only once the server has confirmed. Writing it
+     * eagerly and undoing that on failure looks cheaper and is not: nothing here
+     * reads the cache before this promise settles, while an unconfirmed entry is
+     * indistinguishable from a stored one to every reader - which is exactly the
+     * mistake the gate above exists to catch.
+     *
+     * "Did not throw" is not the test - the answer carries the whole store, so
+     * it is checked for the value that was just written. A server that accepted
+     * the request and then failed to persist it would otherwise be believed. */
+    async set(sessionId, colour, handSet = true) {
         if (!sessionId) {
-            return;
-        }
-        if (colour) {
-            this._colours.set(sessionId, colour);
-        }
-        else {
-            this._colours.delete(sessionId);
-        }
-        try {
-            await requestProvider(this._providerId, 'colours', this._serverSettings, {
-                method: 'POST',
-                body: JSON.stringify({ session_id: sessionId, colour })
-            });
-        }
-        catch (_err) {
-            // The cache already reflects the intent; the next load reconciles.
+            return false;
         }
+        const ids = [sessionId];
+        // Marked before the op is queued, not inside it - the queue window is part
+        // of the window in which no release may be offered. See `isPending`.
+        this._openWrite(ids);
+        return this._run(async () => {
+            var _a;
+            try {
+                const data = await requestProvider(this._providerId, 'colours', this._serverSettings, {
+                    method: 'POST',
+                    body: JSON.stringify({
+                        session_id: sessionId,
+                        colour,
+                        hand_set: handSet
+                    })
+                });
+                if (((_a = data.colours) !== null && _a !== void 0 ? _a : {})[sessionId] !== (colour !== null && colour !== void 0 ? colour : undefined)) {
+                    return false;
+                }
+                // Only this conversation's entry is taken from the answer. The rest of
+                // the map is a snapshot of a moment this caller did not order, and a
+                // reload is how the caller orders one.
+                if (colour) {
+                    this._colours.set(sessionId, colour);
+                }
+                else {
+                    this._colours.delete(sessionId);
+                }
+                this._overrides.delete(sessionId);
+                if (colour && handSet) {
+                    this._overrides.add(sessionId);
+                }
+                return true;
+            }
+            catch (_err) {
+                return false;
+            }
+            finally {
+                this._closeWrite(ids);
+            }
+        });
     }
-    /** Drop stored colours for conversations that no longer exist. */
+    /** Drop stored colours - conversations that no longer exist, or overrides
+     * the user released. One request for the whole list, so a release is never
+     * left half applied. Same contract as `set`: the answer is checked for the
+     * absence of every id, and the cache is touched only once it agrees. */
     async forget(sessionIds) {
-        const present = sessionIds.filter(id => this._colours.has(id));
-        if (present.length === 0) {
-            return;
-        }
-        present.forEach(id => this._colours.delete(id));
-        try {
-            await requestProvider(this._providerId, 'colours', this._serverSettings, {
-                method: 'DELETE',
-                body: JSON.stringify({ session_ids: present })
-            });
-        }
-        catch (_err) {
-            // Same as `set`: the cache is authoritative until the next load.
-        }
+        return this._run(async () => {
+            // Filtered INSIDE the op, not at the call: a capture queued ahead of this
+            // release has landed by the time this runs, so the cache is the current
+            // answer to "does the store hold one". `isPending` still counts, but only
+            // for a write queued BEHIND this release - that id is in no cache yet and
+            // would otherwise be left out of a request that is going out anyway.
+            const present = sessionIds.filter(id => this._colours.has(id) || this.isPending(id));
+            if (present.length === 0) {
+                return true;
+            }
+            this._openWrite(present);
+            try {
+                const data = await requestProvider(this._providerId, 'colours', this._serverSettings, {
+                    method: 'DELETE',
+                    body: JSON.stringify({ session_ids: present })
+                });
+                if (present.some(id => { var _a; return ((_a = data.colours) !== null && _a !== void 0 ? _a : {})[id] !== undefined; })) {
+                    return false;
+                }
+                for (const id of present) {
+                    this._colours.delete(id);
+                    this._overrides.delete(id);
+                }
+                return true;
+            }
+            catch (_err) {
+                return false;
+            }
+            finally {
+                this._closeWrite(present);
+            }
+        });
     }
     /** Copy the parent's EFFECTIVE colour onto a fresh branch, so a branch of a
      * branch inherits whatever its immediate parent actually shows, user-set
-     * override included. Called at the fork sites, once the new id is known. */
+     * override included. Called at the fork sites, once the new id is known.
+     */
     async inherit(parentColour, childId) {
         if (!parentColour || !childId) {
             return;
         }
-        await this.set(childId, parentColour);
+        await this.set(childId, parentColour, false);
     }
 }

package/lib/core/icons.js

@@ -40,8 +40,14 @@ export const removeIcon = new LabIcon({
 // Marks the unsafe launch variants. A shield reads as "protected", which is
 // the inverse of what these entries do, so the caution triangle carries them
 // instead. Material "warning" outline.
-const warningSvgStr = `<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" width="13" height="13">
-  <path class="jp-icon3" fill="#616161" d="M1 21h22L12 2 1 21zm12-3h-2v-2h2v2zm0-4h-2v-4h2v4z"/>
+//
+// 16x16 and `jp-icon-warn0`, like every other icon in these menus and unlike
+// them in colour: authored at 13x13 in `jp-icon3` it rendered smaller than
+// its neutral siblings AND in the identical grey, measured rgb(97,97,97) in
+// the light theme and rgb(189,189,189) in the dark one - the one glyph whose
+// whole job is to say "this differs" was the least conspicuous in the menu.
+const warningSvgStr = `<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" width="16" height="16">
+  <path class="jp-icon-warn0" fill="#f57c00" d="M1 21h22L12 2 1 21zm12-3h-2v-2h2v2zm0-4h-2v-4h2v4z"/>
 </svg>`;
 export const warningIcon = new LabIcon({
     name: `${ICON_PREFIX}:warning`,

package/lib/core/limits.d.ts

@@ -0,0 +1,12 @@
+/** The ONE home for the Recent section's size bounds. `src/core/panel.ts`
+ * clamps with them, `src/index.ts` defaults with them, and
+ * `scripts/generate-schema.mjs` writes them into `schema/plugin.json`, so a
+ * change here is the only change needed.
+ *
+ * Keep this module import-free. The schema generator loads the compiled
+ * `lib/core/limits.js` under plain Node, exactly as it loads the provider
+ * barrel; a single browser-only import would break that.
+ */
+export declare const DEFAULT_RECENT_LIMIT = 10;
+export declare const MIN_RECENT_LIMIT = 1;
+export declare const MAX_RECENT_LIMIT = 100;

package/lib/core/limits.js

@@ -0,0 +1,12 @@
+/** The ONE home for the Recent section's size bounds. `src/core/panel.ts`
+ * clamps with them, `src/index.ts` defaults with them, and
+ * `scripts/generate-schema.mjs` writes them into `schema/plugin.json`, so a
+ * change here is the only change needed.
+ *
+ * Keep this module import-free. The schema generator loads the compiled
+ * `lib/core/limits.js` under plain Node, exactly as it loads the provider
+ * barrel; a single browser-only import would break that.
+ */
+export const DEFAULT_RECENT_LIMIT = 10;
+export const MIN_RECENT_LIMIT = 1;
+export const MAX_RECENT_LIMIT = 100;

package/lib/core/modes.d.ts

@@ -1,4 +1,12 @@
 import { ILaunchMode } from './types';
+/** A resolved launch mode, with what to call it and whether to warn. */
+export interface IResolvedLaunchMode {
+    mode: ILaunchMode;
+    /** What the menu should call it - the value, or the mode's own label. */
+    label: string;
+    /** Whether this widens what the assistant may do without asking. */
+    unsafe: boolean;
+}
 /**
  * The single launch-mode token for one action, or undefined for a plain launch.
  *
@@ -11,3 +19,14 @@ import { ILaunchMode } from './types';
  * the CLI would do unasked.
  */
 export declare function resolveLaunchMode(launchModes: ILaunchMode[], values: Record<string, boolean | string>, force?: string): string | undefined;
+/**
+ * The mode a PLAIN launch would carry right now, as a descriptor entry.
+ *
+ * The panel marks and labels its plain menu items from this. A mode left on in
+ * settings applies to the plain items too, so deciding the warning glyph from
+ * the menu's `force` argument instead puts it on the safer-looking of two
+ * entries that build an identical launch - and leaves the one the user clicks
+ * unmarked. Answers the entry rather than the token so the caller can use the
+ * assistant's own wording.
+ */
+export declare function resolvedLaunchModeEntry(launchModes: ILaunchMode[], values: Record<string, boolean | string>): IResolvedLaunchMode | null;

package/lib/core/modes.js

@@ -34,3 +34,39 @@ export function resolveLaunchMode(launchModes, values, force) {
     }
     return undefined;
 }
+/**
+ * The mode a PLAIN launch would carry right now, as a descriptor entry.
+ *
+ * The panel marks and labels its plain menu items from this. A mode left on in
+ * settings applies to the plain items too, so deciding the warning glyph from
+ * the menu's `force` argument instead puts it on the safer-looking of two
+ * entries that build an identical launch - and leaves the one the user clicks
+ * unmarked. Answers the entry rather than the token so the caller can use the
+ * assistant's own wording.
+ */
+export function resolvedLaunchModeEntry(launchModes, values) {
+    var _a, _b;
+    const token = resolveLaunchMode(launchModes, values);
+    if (!token) {
+        return null;
+    }
+    const [id, value] = token.split('=');
+    const mode = launchModes.find(m => m.id === id);
+    if (!mode) {
+        return null;
+    }
+    // A boolean mode with a menu label IS the assistant's skip-approval switch;
+    // an enum only widens on the values its provider declared. `plan` resolves
+    // to a mode and is stricter than the default, so "resolved at all" is the
+    // wrong question to ask about danger.
+    const unsafe = value
+        ? ((_a = mode.unsafeValues) !== null && _a !== void 0 ? _a : []).indexOf(value) !== -1
+        : !!mode.menuLabel;
+    // Name the VALUE where there is one - three enum values sharing the mode's
+    // title render as one indistinguishable label.
+    return {
+        mode,
+        label: (_b = value !== null && value !== void 0 ? value : mode.menuLabel) !== null && _b !== void 0 ? _b : mode.title,
+        unsafe
+    };
+}