@mjasnikovs/pi-task 0.38.23 → 0.38.25

package/README.md

@@ -9,7 +9,7 @@
 [![npm](https://img.shields.io/npm/v/@mjasnikovs/pi-task?color=cb3837&logo=npm)](https://www.npmjs.com/package/@mjasnikovs/pi-task)
 [![license](https://img.shields.io/badge/license-AGPL--3.0-blue.svg)](./LICENSE)
 [![pi extension](https://img.shields.io/badge/pi-extension-7c3aed)](https://www.npmjs.com/package/@earendil-works/pi-coding-agent)
-[![tests](https://img.shields.io/badge/tests-3771%20passing-3fb950)](#development)
+[![tests](https://img.shields.io/badge/tests-4320%20passing-3fb950)](#development)
 [![types](https://img.shields.io/badge/TypeScript-strict-3178c6?logo=typescript&logoColor=white)](./tsconfig.json)
 
 </div>
@@ -243,7 +243,7 @@ them checked in.
 
 ```sh
 bun install
-bun run test       # 3772 tests across 212 files
+bun run test       # 4321 tests across 242 files
 bun run lint       # prettier + eslint + tsc --noEmit
 bun run build      # tsc → dist/
 ```

package/dist/config/reasoning-args.d.ts

@@ -1,3 +1,14 @@
+/**
+ * The live-config bridge for reasoning profiles: group in, argv fragment out.
+ *
+ * Separate from reasoning.ts because that module must stay import-free — see its
+ * header. This file is the one hop that reads `getConfig()`, so it imports both
+ * and neither imports it back: a tree, not a cycle.
+ *
+ * Read PER CALL, never cached at module scope, so a /task-config change lands on
+ * the next child without a restart — the same contract childBaseArgs states.
+ */
+import { type PiTaskConfig } from './config.js';
 import { type ReasoningGroup } from './reasoning.js';
 /**
  * The `['--thinking', level]` fragment for a group, or `[]` when the group is
@@ -7,4 +18,4 @@ import { type ReasoningGroup } from './reasoning.js';
  * themselves — an argv builder that resolves its own policy is one that cannot
  * be told to do something else, which is how childBaseArgs became universal.
  */
-export declare function groupThinkingArgs(group: ReasoningGroup): string[];
+export declare function groupThinkingArgs(group: ReasoningGroup, cfg?: PiTaskConfig): string[];

package/dist/config/reasoning-args.js

@@ -18,6 +18,9 @@ import { resolveReasoning, thinkingArgs } from './reasoning.js';
  * themselves — an argv builder that resolves its own policy is one that cannot
  * be told to do something else, which is how childBaseArgs became universal.
  */
-export function groupThinkingArgs(group) {
-    return thinkingArgs(resolveReasoning(group, getConfig()));
+export function groupThinkingArgs(group, cfg) {
+    // The default is EVALUATED HERE, per call, which is the contract this module
+    // exists to keep. Hoisting the read to module scope would leave every test
+    // green, so the parameter is what makes the contract assertable at all.
+    return thinkingArgs(resolveReasoning(group, cfg ?? getConfig()));
 }

package/dist/config/reasoning.d.ts

@@ -142,13 +142,41 @@ export declare const DEFAULT_REASONING_TABLE: Readonly<Record<ReasoningGroup, Gr
  */
 export declare function sanitizeReasoningMode(value: unknown): ReasoningMode;
 /**
- * The group each research worker reads its level from, keyed by the section
- * heading its output is assembled under (task/phases.ts `workerSpecs`).
- *
- * Exported so the wiring is one table rather than four string literals spread
- * through the phase code, and so a test can assert every value is a real group.
+ * Child NAME → reasoning group, for every child that goes through
+ * `runPhaseChild` / `runPlanningChild`.
+ *
+ * WHY KEYED ON THE NAME
+ * ---------------------
+ * The name is the only identifier in scope at all three spawn paths (phases,
+ * /task-auto planning, /task-plan), it is what the loader and the debug trail
+ * already print, and it is the one thing a reader can check against the phase
+ * list without following the call graph. Threading a group parameter through
+ * `PhaseDeps` / `AutoDeps` instead would touch both orchestrators' dep bags to
+ * express something the call site already says out loud.
+ *
+ * AN UNMAPPED NAME IS A BUILD FAILURE, not a silent `inherit`.
+ * `reasoning-groups.test.ts` scans every literal child name in src/ and fails if
+ * it is missing here. A defaulting lookup would let a phase added next year opt
+ * itself out of a measured setting without anyone deciding to — which is exactly
+ * how `/no_think` ended up applied to eight prompts and read by none of them.
+ *
+ * The gate and extraction groups are NOT here: those children reach the model
+ * through `runWorker` / `focusedChildArgs` at a site with no name in scope, so
+ * the group is passed directly. The four RESEARCH workers do have a name — their
+ * `spec.label` — and so they are here.
+ */
+export declare const REASONING_GROUP_BY_CHILD: Readonly<Record<string, ReasoningGroup>>;
+/**
+ * The group a named child belongs to.
+ *
+ * Returns `undefined` for a name the table does not know, and the CALLER decides
+ * what that means. `runPhaseChild` treats it as `inherit` — a child that reaches
+ * the model with today's argv is always safe — while the test treats it as a
+ * failure. That split is deliberate: the guard belongs at build time, where
+ * someone can fix it, not at run time, where it would abort a user's task over a
+ * missing table row.
  */
-export declare const RESEARCH_WORKER_GROUPS: Readonly<Record<string, ReasoningGroup>>;
+export declare function reasoningGroupForChild(name: string): ReasoningGroup | undefined;
 /**
  * Always returns a COMPLETE record, never a partial one.
  *
@@ -167,6 +195,19 @@ export declare function sanitizeReasoningLevels(value: unknown): Record<Reasonin
  * `groupThinkingArgs` from reasoning-args.ts.
  */
 export declare function resolveReasoning(group: ReasoningGroup, cfg: PiTaskConfig): GroupSetting;
+/**
+ * The WHOLE table, as this config will actually run it.
+ *
+ * This is the question every caller has — the settings menu when it repaints,
+ * the mismatch warning when it scans, the custom-mode seeder when it freezes the
+ * table — and each of them used to write the same loop over `resolveReasoning`.
+ * A per-key accessor with no whole-table companion is also how a THIRD shape got
+ * invented (`Array<{group, setting}>`) and leaked into `reasoningMismatches`.
+ *
+ * `resolveReasoning` stays: one group is still a fair question, and it is the
+ * only place the four modes are interpreted.
+ */
+export declare function effectiveReasoning(cfg: PiTaskConfig): Record<ReasoningGroup, GroupSetting>;
 /**
  * The argv fragment for a setting. `inherit` is the empty fragment — no flag at
  * all — which is what makes an all-`inherit` config byte-identical to the

package/dist/config/reasoning.js

@@ -711,18 +711,75 @@ export function sanitizeReasoningMode(value) {
     return REASONING_MODES.includes(value) ? value : 'default';
 }
 /**
- * The group each research worker reads its level from, keyed by the section
- * heading its output is assembled under (task/phases.ts `workerSpecs`).
+ * Child NAME → reasoning group, for every child that goes through
+ * `runPhaseChild` / `runPlanningChild`.
  *
- * Exported so the wiring is one table rather than four string literals spread
- * through the phase code, and so a test can assert every value is a real group.
+ * WHY KEYED ON THE NAME
+ * ---------------------
+ * The name is the only identifier in scope at all three spawn paths (phases,
+ * /task-auto planning, /task-plan), it is what the loader and the debug trail
+ * already print, and it is the one thing a reader can check against the phase
+ * list without following the call graph. Threading a group parameter through
+ * `PhaseDeps` / `AutoDeps` instead would touch both orchestrators' dep bags to
+ * express something the call site already says out loud.
+ *
+ * AN UNMAPPED NAME IS A BUILD FAILURE, not a silent `inherit`.
+ * `reasoning-groups.test.ts` scans every literal child name in src/ and fails if
+ * it is missing here. A defaulting lookup would let a phase added next year opt
+ * itself out of a measured setting without anyone deciding to — which is exactly
+ * how `/no_think` ended up applied to eight prompts and read by none of them.
+ *
+ * The gate and extraction groups are NOT here: those children reach the model
+ * through `runWorker` / `focusedChildArgs` at a site with no name in scope, so
+ * the group is passed directly. The four RESEARCH workers do have a name — their
+ * `spec.label` — and so they are here.
  */
-export const RESEARCH_WORKER_GROUPS = {
-    FILES: 'research:files',
-    APIS: 'research:apis',
-    CONTEXT: 'research:context',
-    TOOLING: 'research:tooling'
+export const REASONING_GROUP_BY_CHILD = {
+    // ── phase: task/phases.ts + task/title-label.ts ──────────────────────────
+    refine: 'phase',
+    'verify-tooling': 'phase',
+    'grill-auto': 'phase',
+    'grill-gen': 'phase',
+    compose: 'phase',
+    critique: 'phase',
+    'critique-triage': 'phase',
+    'compress-label': 'phase',
+    // ── planning: task/auto-orchestrator.ts ──────────────────────────────────
+    'clarify-triage': 'planning',
+    'auto-clarify': 'planning',
+    'auto-decompose': 'planning',
+    'requirement-extract': 'planning',
+    'decompose-coverage': 'planning',
+    'coverage-map': 'planning',
+    'contract-extract': 'planning',
+    'launch-extract': 'planning',
+    // ── plan: task/plan-orchestrator.ts ──────────────────────────────────────
+    'plan-question': 'plan',
+    'plan-answer': 'plan',
+    // ── research: task/phases.ts `workerSpecs`, keyed on the spec's LABEL ─────
+    // These were a second table (`RESEARCH_WORKER_GROUPS`) keyed on the section
+    // heading, with a silent `?? 'research'` fallback and a guard that sliced
+    // phases.ts source between two string offsets from the config directory.
+    // The label is the same name the loader, the debug trail and the A/B ledgers
+    // already print, so they belong here with every other named child.
+    'worker:files': 'research:files',
+    'worker:apis': 'research:apis',
+    'worker:context': 'research:context',
+    'worker:tooling': 'research:tooling'
 };
+/**
+ * The group a named child belongs to.
+ *
+ * Returns `undefined` for a name the table does not know, and the CALLER decides
+ * what that means. `runPhaseChild` treats it as `inherit` — a child that reaches
+ * the model with today's argv is always safe — while the test treats it as a
+ * failure. That split is deliberate: the guard belongs at build time, where
+ * someone can fix it, not at run time, where it would abort a user's task over a
+ * missing table row.
+ */
+export function reasoningGroupForChild(name) {
+    return REASONING_GROUP_BY_CHILD[name];
+}
 /**
  * For a `research:*` group, the group a stored config falls back to when its own
  * key is missing. Every other group maps to `undefined`.
@@ -795,6 +852,24 @@ export function resolveReasoning(group, cfg) {
             return DEFAULT_REASONING_TABLE[group];
     }
 }
+/**
+ * The WHOLE table, as this config will actually run it.
+ *
+ * This is the question every caller has — the settings menu when it repaints,
+ * the mismatch warning when it scans, the custom-mode seeder when it freezes the
+ * table — and each of them used to write the same loop over `resolveReasoning`.
+ * A per-key accessor with no whole-table companion is also how a THIRD shape got
+ * invented (`Array<{group, setting}>`) and leaked into `reasoningMismatches`.
+ *
+ * `resolveReasoning` stays: one group is still a fair question, and it is the
+ * only place the four modes are interpreted.
+ */
+export function effectiveReasoning(cfg) {
+    const out = {};
+    for (const group of REASONING_GROUPS)
+        out[group] = resolveReasoning(group, cfg);
+    return out;
+}
 /**
  * The argv fragment for a setting. `inherit` is the empty fragment — no flag at
  * all — which is what makes an all-`inherit` config byte-identical to the

package/dist/config/register.d.ts

@@ -59,7 +59,18 @@ declare class BorderedBox implements Component {
  * because both read `format`.
  */
 export interface ConfigItem {
-    id: keyof PiTaskConfig;
+    /**
+     * The row's id. A `keyof PiTaskConfig` for a fixed setting; a prefixed
+     * string (`reason:`, `tool:`, `ext:`) for a DISCOVERED one.
+     *
+     * It is `string`, not `keyof PiTaskConfig`, and that is what lets the three
+     * dynamic families BE rows instead of bypassing them. While the id was
+     * narrow, each family re-invented both directions by hand — a builder, an
+     * apply function, and an arm in a four-way prefix ladder 300 lines away —
+     * and the round-trip property `config-items.test.ts` runs over `ITEMS`
+     * covered none of them.
+     */
+    id: string;
     /**
      * Which titled block of the menu this row sits under. Rows are grouped by
      * section in {@link panelItems}, in the order the sections first appear in
@@ -75,6 +86,11 @@ export interface ConfigItem {
     format: (cfg: PiTaskConfig) => string;
     /** Write the chosen label back. A value it does not recognise is ignored. */
     apply: (cfg: PiTaskConfig, chosen: string) => void;
+    /**
+     * What the headless one-line rendering calls this row, when `label` reads
+     * only in the panel. See {@link PanelItem.headlessLabel}.
+     */
+    headlessLabel?: string;
 }
 /**
  * The titled blocks the settings menu is divided into.
@@ -102,22 +118,10 @@ export declare const SECTION_ID_PREFIX = "section:";
  * either of the two ladders this replaced.
  */
 export declare const ITEMS: ConfigItem[];
-export declare function extensionItems(extensions: InstalledExtension[], whitelist: readonly string[]): {
-    id: string;
-    label: string;
-    description: string;
-    currentValue: string;
-    values: string[];
-}[];
+export declare function extensionItems(extensions: InstalledExtension[]): ConfigItem[];
 /** Apply an extension toggle to the config's whitelist (idempotent both ways). */
 export declare function applyExtensionToggle(whitelist: readonly string[], entryPath: string, on: boolean): string[];
-export declare function toolItems(tools: readonly GuardableTool[], exempt: readonly string[]): {
-    id: string;
-    label: string;
-    description: string;
-    currentValue: string;
-    values: string[];
-}[];
+export declare function toolItems(tools: readonly GuardableTool[]): ConfigItem[];
 /** Apply a per-tool watchdog toggle to the exemption list (idempotent both ways). */
 export declare function applyToolToggle(exempt: readonly string[], toolName: string, watched: boolean): string[];
 /**
@@ -138,7 +142,7 @@ export declare function applyToolToggle(exempt: readonly string[], toolName: str
  * Leading spaces survive: SettingsList pads the label right, never trims it.
  */
 export declare function reasoningRowLabel(group: ReasoningGroup): string;
-export declare function reasoningItems(cfg: PiTaskConfig): PanelItem[];
+export declare function reasoningItems(): ConfigItem[];
 /**
  * Apply one group row's new value.
  *
@@ -149,16 +153,6 @@ export declare function reasoningItems(cfg: PiTaskConfig): PanelItem[];
  * it, nudging `research` while in `off` would silently return the other six to
  * whatever the stored table happened to hold.
  */
-/**
- * Write every `think:` row's displayed value back from the config.
- *
- * Called after ANY change, not just a reasoning one, because the mode row and
- * the seven group rows are one control split across eight lines: cycling
- * `reasoning` to `off` changes what all seven of them run at, and cycling one
- * group row flips the mode, which changes the other six. A row showing a level
- * the run will not use is worse than no row.
- */
-export declare function refreshReasoningRows(cfg: PiTaskConfig, list: SettingsList): void;
 export declare function applyReasoningLevel(cfg: PiTaskConfig, group: ReasoningGroup, chosen: string): void;
 /**
  * Tallest body the settings list can render, so {@link BorderedBox} can pad
@@ -204,7 +198,37 @@ export declare function createSettingsPanel(items: PanelItem[], theme: Theme,
  * beside seven rows still claiming `inherit` — which is what it did.
  */
 onChange: (id: string, newValue: string, list: SettingsList) => void, onCancel: () => void): BorderedBox;
+/**
+ * Every settings row for this session, fixed and DISCOVERED, in menu order.
+ *
+ * One list of `ConfigItem`s — so a row's display, its write-back and its section
+ * are one object, the dispatch is a lookup by id, and the round-trip properties
+ * in `config-items.test.ts` cover the reasoning, tool and extension families
+ * that used to bypass the row type entirely.
+ *
+ * Fixed rows come before discovered ones within a section, which is the order
+ * the hand-written `extra` map produced.
+ */
+export declare function configRows(installed: InstalledExtension[], tools?: readonly GuardableTool[]): ConfigItem[];
+/** Render `rows` for the current config, grouped under their section headers. */
+export declare function renderRows(cfg: PiTaskConfig, rows: readonly ConfigItem[]): PanelItem[];
 /** The full settings row list for the current config, in menu order. */
 export declare function panelItems(cfg: PiTaskConfig, installed: InstalledExtension[], tools?: readonly GuardableTool[]): PanelItem[];
+/**
+ * Re-ask every row what it now displays, and write the answers back.
+ *
+ * A row's `currentValue` in the live list is a snapshot taken when the panel was
+ * built, and rows describe each other: cycling `reasoning` to `off` changes what
+ * all seven `think:` rows run at, and cycling one group row flips the mode,
+ * which changes the other six.
+ *
+ * This runs after ANY change, over EVERY row. Its predecessor,
+ * `refreshReasoningRows`, ran after any change too — but hard-coded the seven
+ * reasoning ids plus `reasoningMode` and touched none of the other ~30 rows, so
+ * the next cross-row dependency would have needed a fifth function. Re-reading a
+ * `format` costs nothing, which is why there is still no list of "changes that
+ * need a refresh" to keep correct.
+ */
+export declare function syncRows(cfg: PiTaskConfig, rows: readonly ConfigItem[], list: SettingsList): void;
 export declare function registerConfig(pi: ExtensionAPI): void;
 export {};

package/dist/config/register.js

@@ -5,7 +5,7 @@ import { SEARCH_PROVIDERS, SEARCH_PROVIDER_LABELS, providerForLabel } from '../w
 import { COMMAND_TIMEOUT_OPTIONS, DEBUG_LOG_OPTIONS, getConfig, sanitizeDebugLogs, saveConfig, STREAM_INACTIVITY_OPTIONS } from './config.js';
 import { listInstalledExtensions } from './extension-list.js';
 import { listGuardableTools } from './tool-list.js';
-import { REASONING_GROUPS, REASONING_MODES, sanitizeReasoningMode, REASONING_GROUP_HELP, REASONING_SETTINGS, resolveReasoning } from './reasoning.js';
+import { REASONING_GROUPS, REASONING_MODES, sanitizeReasoningMode, REASONING_GROUP_HELP, REASONING_SETTINGS, effectiveReasoning, resolveReasoning } from './reasoning.js';
 // Version in the title so a bug report or screenshot says which build it came
 // from without anyone having to go look it up.
 const CONFIG_TITLE = `pi-task ${readPkgVersion()} settings`;
@@ -253,16 +253,22 @@ export const ITEMS = [
  * can tell an extension toggle from a PiTaskConfig field.
  */
 const EXT_ID_PREFIX = 'ext:';
-export function extensionItems(extensions, whitelist) {
+export function extensionItems(extensions) {
     return extensions.map(e => ({
         id: EXT_ID_PREFIX + e.path,
+        section: 'extensions',
         label: `ext: ${e.label}`,
         description: `Load this ${e.origin} extension in the helper sessions pi-task spawns. They run `
             + 'with extensions off by default, so turn this on when the extension provides the '
             + 'model they need (pi-lmstudio, for example). They also inherit its tools and '
             + `hooks, so only enable ones you trust. ${e.path}`,
-        currentValue: whitelist.includes(e.path) ? 'on' : 'off',
-        values: ['on', 'off']
+        values: ['on', 'off'],
+        format: cfg => (cfg.extensionWhitelist.includes(e.path) ? 'on' : 'off'),
+        apply: (cfg, chosen) => {
+            if (chosen !== 'on' && chosen !== 'off')
+                return;
+            cfg.extensionWhitelist = applyExtensionToggle(cfg.extensionWhitelist, e.path, chosen === 'on');
+        }
     }));
 }
 /** Apply an extension toggle to the config's whitelist (idempotent both ways). */
@@ -280,18 +286,24 @@ export function applyExtensionToggle(whitelist, entryPath, on) {
  * the config matches nothing.
  */
 const TOOL_ID_PREFIX = 'tool:';
-export function toolItems(tools, exempt) {
+export function toolItems(tools) {
     return tools.map(t => ({
         id: TOOL_ID_PREFIX + t.name,
+        section: 'timeouts',
         label: `watch: ${t.name}`,
         description: `Apply the command timeout to this tool. Leave it on unless the tool runs its own `
             + `bounded, cancellable work for longer than the timeout — turning it off means a `
             + `genuine hang in this tool will never be caught, and nothing else is watching `
             + `while a tool runs. ${t.origin}`,
+        values: ['on', 'off'],
         // Stored inverted: the config records the EXEMPTIONS, so an empty list
         // (and any tool pi-task has never heard of) stays guarded by default.
-        currentValue: exempt.includes(t.name) ? 'off' : 'on',
-        values: ['on', 'off']
+        format: cfg => (cfg.commandTimeoutExemptTools.includes(t.name) ? 'off' : 'on'),
+        apply: (cfg, chosen) => {
+            if (chosen !== 'on' && chosen !== 'off')
+                return;
+            cfg.commandTimeoutExemptTools = applyToolToggle(cfg.commandTimeoutExemptTools, t.name, chosen === 'on');
+        }
     }));
 }
 /** Apply a per-tool watchdog toggle to the exemption list (idempotent both ways). */
@@ -339,17 +351,20 @@ export function reasoningRowLabel(group) {
     const nextIsSibling = REASONING_GROUPS[REASONING_GROUPS.indexOf(group) + 1]?.startsWith(`${parent}:`);
     return `   ${nextIsSibling ? '├─' : '└─'} ${group.slice(colon + 1)}`;
 }
-export function reasoningItems(cfg) {
+export function reasoningItems() {
     return REASONING_GROUPS.map(group => ({
         id: REASON_ID_PREFIX + group,
+        section: 'reasoning',
         label: reasoningRowLabel(group),
         headlessLabel: `think: ${group}`,
         description: REASONING_GROUP_HELP[group],
+        values: [...REASONING_SETTINGS],
         // The EFFECTIVE level, not cfg.reasoningLevels[group]: in default/on/off
         // the stored table is not what runs, and a row that shows a value the
-        // run does not use is worse than no row.
-        currentValue: resolveReasoning(group, cfg),
-        values: [...REASONING_SETTINGS]
+        // run does not use is worse than no row. As a FUNCTION rather than a
+        // snapshot, so `syncRows` can re-ask after any change.
+        format: cfg => resolveReasoning(group, cfg),
+        apply: (cfg, chosen) => applyReasoningLevel(cfg, group, chosen)
     }));
 }
 /**
@@ -362,29 +377,13 @@ export function reasoningItems(cfg) {
  * it, nudging `research` while in `off` would silently return the other six to
  * whatever the stored table happened to hold.
  */
-/**
- * Write every `think:` row's displayed value back from the config.
- *
- * Called after ANY change, not just a reasoning one, because the mode row and
- * the seven group rows are one control split across eight lines: cycling
- * `reasoning` to `off` changes what all seven of them run at, and cycling one
- * group row flips the mode, which changes the other six. A row showing a level
- * the run will not use is worse than no row.
- */
-export function refreshReasoningRows(cfg, list) {
-    for (const group of REASONING_GROUPS) {
-        list.updateValue(REASON_ID_PREFIX + group, resolveReasoning(group, cfg));
-    }
-    list.updateValue('reasoningMode', cfg.reasoningMode);
-}
 export function applyReasoningLevel(cfg, group, chosen) {
     if (!REASONING_SETTINGS.includes(chosen))
         return;
     if (cfg.reasoningMode !== 'custom') {
-        const seeded = {};
-        for (const g of REASONING_GROUPS)
-            seeded[g] = resolveReasoning(g, cfg);
-        cfg.reasoningLevels = seeded;
+        // Freeze the table exactly as it runs today, then switch to custom, so
+        // opening one row cannot silently move the other six.
+        cfg.reasoningLevels = effectiveReasoning(cfg);
         cfg.reasoningMode = 'custom';
     }
     cfg.reasoningLevels = { ...cfg.reasoningLevels, [group]: chosen };
@@ -518,38 +517,70 @@ onChange, onCancel) {
     const list = new SettingsList(items, MAX_VISIBLE, makeTheme(theme, label => headerLabels.has(label.trimEnd())), (id, newValue) => onChange(id, newValue, list), onCancel);
     return new BorderedBox(new SkipInertRows(list, items.map(i => (i.values?.length ?? 0) > 0)), CONFIG_TITLE, s => theme.fg('borderMuted', s), s => theme.fg('accent', theme.bold(s)), settingsBodyHeight(items.map(i => i.description), MAX_VISIBLE, OVERLAY_WIDTH - 8));
 }
-/** The full settings row list for the current config, in menu order. */
-export function panelItems(cfg, installed, tools = []) {
-    // The discovered rows belong to a section too — the per-tool watchdog
-    // exemptions under `timeouts` (they are exemptions FROM that timeout), and
-    // the per-extension toggles under their own heading.
-    const extra = {
-        reasoning: reasoningItems(cfg),
-        timeouts: toolItems(tools, cfg.commandTimeoutExemptTools),
-        extensions: extensionItems(installed, cfg.extensionWhitelist)
-    };
+/**
+ * Every settings row for this session, fixed and DISCOVERED, in menu order.
+ *
+ * One list of `ConfigItem`s — so a row's display, its write-back and its section
+ * are one object, the dispatch is a lookup by id, and the round-trip properties
+ * in `config-items.test.ts` cover the reasoning, tool and extension families
+ * that used to bypass the row type entirely.
+ *
+ * Fixed rows come before discovered ones within a section, which is the order
+ * the hand-written `extra` map produced.
+ */
+export function configRows(installed, tools = []) {
+    // The discovered rows carry a section like every other row — the per-tool
+    // watchdog exemptions under `timeouts` (they are exemptions FROM that
+    // timeout), and the per-extension toggles under their own heading.
+    return [...ITEMS, ...reasoningItems(), ...toolItems(tools), ...extensionItems(installed)];
+}
+/** Render `rows` for the current config, grouped under their section headers. */
+export function renderRows(cfg, rows) {
     const out = [];
     for (const { key, title } of SECTIONS) {
-        const rows = [
-            ...ITEMS.filter(i => i.section === key).map(({ id, label, description, values, format }) => ({
-                id: id,
-                label,
-                description,
-                currentValue: format(cfg),
-                values: values ?? ['on', 'off']
-            })),
-            ...(extra[key] ?? [])
-        ];
+        const inSection = rows
+            .filter(i => i.section === key)
+            .map(i => ({
+            id: i.id,
+            label: i.label,
+            description: i.description,
+            currentValue: i.format(cfg),
+            values: i.values ?? ['on', 'off'],
+            ...(i.headlessLabel === undefined ? {} : { headlessLabel: i.headlessLabel })
+        }));
         // An empty section prints no header. `extensions` has no fixed rows at
         // all, so with nothing installed the heading would otherwise sit alone.
-        if (rows.length === 0)
+        if (inSection.length === 0)
             continue;
         if (out.length > 0)
             out.push(sectionGap(title));
-        out.push(sectionHeader(title), ...rows);
+        out.push(sectionHeader(title), ...inSection);
     }
     return out;
 }
+/** The full settings row list for the current config, in menu order. */
+export function panelItems(cfg, installed, tools = []) {
+    return renderRows(cfg, configRows(installed, tools));
+}
+/**
+ * Re-ask every row what it now displays, and write the answers back.
+ *
+ * A row's `currentValue` in the live list is a snapshot taken when the panel was
+ * built, and rows describe each other: cycling `reasoning` to `off` changes what
+ * all seven `think:` rows run at, and cycling one group row flips the mode,
+ * which changes the other six.
+ *
+ * This runs after ANY change, over EVERY row. Its predecessor,
+ * `refreshReasoningRows`, ran after any change too — but hard-coded the seven
+ * reasoning ids plus `reasoningMode` and touched none of the other ~30 rows, so
+ * the next cross-row dependency would have needed a fifth function. Re-reading a
+ * `format` costs nothing, which is why there is still no list of "changes that
+ * need a refresh" to keep correct.
+ */
+export function syncRows(cfg, rows, list) {
+    for (const row of rows)
+        list.updateValue(row.id, row.format(cfg));
+}
 async function handleTaskConfig(_args, ctx, getTools = () => []) {
     const cfg = {
         ...getConfig(),
@@ -585,34 +616,19 @@ async function handleTaskConfig(_args, ctx, getTools = () => []) {
         ctx.ui.notify(lines.join('  |  '), 'info');
         return;
     }
-    await ctx.ui.custom((_tui, theme, _kb, done) => createSettingsPanel(panelItems(cfg, installed, tools), theme, (id, newValue, list) => {
-        // Header rows carry no `values`, so SettingsList never
-        // cycles them and this can only be a real setting.
-        if (id.startsWith(SECTION_ID_PREFIX))
-            return;
-        if (id.startsWith(EXT_ID_PREFIX)) {
-            cfg.extensionWhitelist = applyExtensionToggle(cfg.extensionWhitelist, id.slice(EXT_ID_PREFIX.length), newValue === 'on');
-        }
-        else if (id.startsWith(REASON_ID_PREFIX)) {
-            applyReasoningLevel(cfg, id.slice(REASON_ID_PREFIX.length), newValue);
-        }
-        else if (id.startsWith(TOOL_ID_PREFIX)) {
-            cfg.commandTimeoutExemptTools = applyToolToggle(cfg.commandTimeoutExemptTools, id.slice(TOOL_ID_PREFIX.length), newValue === 'on');
-        }
-        else {
-            // Every setting parses its own value. There is no generic
-            // fallback: the ladder this replaces ended in one that
-            // wrote `newValue === 'on'` into whatever field it was
-            // handed, so a new enum setting silently became a boolean
-            // until someone noticed.
-            ITEMS.find(item => item.id === id)?.apply(cfg, newValue);
-        }
-        // The reasoning rows describe each other, so they are
-        // re-read from the config after every change — including
-        // changes to unrelated rows, which costs nothing and means
-        // there is no list of "changes that need a refresh" to keep
-        // correct.
-        refreshReasoningRows(cfg, list);
+    // Built ONCE and shared by the renderer, the dispatch and the refresh, so
+    // all three necessarily agree about which rows exist.
+    const rows = configRows(installed, tools);
+    await ctx.ui.custom((_tui, theme, _kb, done) => createSettingsPanel(renderRows(cfg, rows), theme, (id, newValue, list) => {
+        // Every row parses its own value. There is no generic
+        // fallback and no prefix ladder: the ladder this replaces
+        // ended in one that wrote `newValue === 'on'` into whatever
+        // field it was handed, so a new enum setting silently became
+        // a boolean until someone noticed. A header row carries no
+        // `values`, so SettingsList never cycles it and it matches
+        // no row here anyway.
+        rows.find(row => row.id === id)?.apply(cfg, newValue);
+        syncRows(cfg, rows, list);
         saveConfig(cfg).catch(() => { });
     }, () => done(undefined)), { overlay: true, overlayOptions: { width: OVERLAY_WIDTH } });
 }

package/dist/shared/reasoning-capability.d.ts

@@ -24,7 +24,7 @@
  * transitive package to get twenty lines of arithmetic. SOURCE OF TRUTH is that
  * module; `reasoning-capability.test.ts` is where a change upstream shows up.
  */
-import type { ReasoningGroup, GroupSetting } from '../config/reasoning.js';
+import { type ReasoningGroup, type GroupSetting } from '../config/reasoning.js';
 /**
  * pi's own level ladder, in order. The order is the whole algorithm: an
  * unsupported level is resolved by walking UP first, then down.
@@ -80,7 +80,4 @@ export interface ReasoningMismatch {
  * about one direction while staying silent about the other would ship this
  * feature with its own measured failure mode unreported.
  */
-export declare function reasoningMismatches(model: ReasoningModelFacts | undefined, settings: ReadonlyArray<{
-    group: ReasoningGroup;
-    setting: GroupSetting;
-}>): ReasoningMismatch[];
+export declare function reasoningMismatches(model: ReasoningModelFacts | undefined, levels: Readonly<Record<ReasoningGroup, GroupSetting>>): ReasoningMismatch[];