thincoder 0.12.30 → 0.12.31

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "thincoder",
-  "version": "0.12.30",
+  "version": "0.12.31",
   "description": "Thin coding agent - zero dependencies, no build step, Node.js native. Sharp code, zero bloat.",
   "keywords": [
     "ai",

package/src/agent-tools/consult.mjs

@@ -164,7 +164,7 @@ export const consultStartTool = {
   readonly: false,
   sideEffectExempt: true,
   description:
-    "Start a parallel multi-model consultation for a hard problem you are stuck on (repeated failures, no headway). " +
+    "Start a parallel multi-model consultation (会诊) for a hard problem you are stuck on (repeated failures, no headway). " +
     "Several configured models (agent.consultModels) analyze the same problem INDEPENDENTLY and in parallel. " +
     "Non-blocking: returns immediately with a consult id. Then call consult_check(id) to read each reply as it " +
     "arrives, judge/verify it yourself with your own tools, and call consult_stop(id) once a reply is good enough.\n" +

package/src/prompts/advisor-round1.md

@@ -5,7 +5,11 @@ You have a budget of 30 tool rounds (chat turns) — plan your exploration accor
 
 Review workflow:
 1. The files to review are listed in the review scope. Read them in full. The review scope defines exactly which files to inspect.
-2. **READ THE PROJECT GUIDE FIRST** — the `## Project Guide (AGENTS.md)` section in the review context maps the project's structure and tells you where its requirements/design documents live. Read the requirements documents it points to (whatever the guide names — no fixed file names are assumed). **The user's requirements live in those documents; the conversation background is only a supplement.** If the guide says none exist, judge from the conversation background and say so explicitly if requirements are unclear.
+2. **READ THE PROJECT GUIDE FIRST** — the `## Project Guide (AGENTS.md)` section in the review context maps the project's structure.
+   - It tells you where the requirements/design documents live.
+   - Read whatever documents the guide names — no fixed file names are assumed.
+   - **The user's requirements live in those documents; the conversation background is only a supplement.**
+   - If the guide names none, judge from the conversation background and say so explicitly if requirements are unclear.
 3. Read the specified files for full context. **Batch independent `read` calls in a SINGLE reply** — do not read files one at a time. Each round-trip counts against your limit.
 4. Use grep or lsp to trace callers, imports, and dependencies — only where genuinely needed.
 5. Produce your review table.
@@ -17,11 +21,18 @@ Budget rules:
 - **Batch everything**: multiple `read` calls in one reply, multiple `grep` calls in one reply. Serializing tool calls wastes your round budget.
 
 Rules:
-- First judge the task from the conversation background: if the changes are clearly non-code and cannot affect runtime behavior, reply immediately with the all-clear phrase — `"All clear — no code changes to review."` (the host recognizes it via the "all clear" / "no 🔴" / "review passed" / "no issues found" markers, matched case-insensitively) — do NOT spend tool calls exploring. This applies to static docs, README, and CHANGELOG files. Prompts and configs that shape behaviour are NOT exempt — review them normally.
+- First judge the task from the conversation background.
+  - If the changes are clearly non-code (static docs, README, CHANGELOG), reply immediately with the all-clear phrase — `"All clear — no code changes to review."` — and do NOT spend tool calls exploring.
+  - The host recognizes it via the "all clear" / "no 🔴" / "review passed" / "no issues found" markers, matched case-insensitively.
+  - Prompts and configs that shape behaviour are NOT exempt — review them normally.
 - **Requirement fit**: check the implementation against what the user actually asked for — a review is not only about "is the code correct" but also "is this what the user wanted". Two comparisons:
   - (a) **Claim vs implementation**: the implementer's stated intent (conversation background / response table / commit message) vs what the implementation actually does — claiming X but delivering Y is a gap.
-  - (b) **Expectation vs shape**: the requirements documents named by the Project Guide (AGENTS.md) and explicit user expectations vs the delivered shape — "asked for A, got B" (e.g. "the record must keep the real order" vs a summary appended at the end) is a gap. **The requirements documents are the primary reference — read them (workflow step 2) before judging fit; do not judge against expectations you cannot see.**
-  - **Known limit**: the conversation background only includes the last 3 user–assistant exchanges — older user expectations may not be visible, which is why the requirements documents are the primary reference. (a) is the primary check (needs only recent context); (b) is best-effort — check what the docs/background show, do NOT treat an invisible expectation as a gap.
+  - (b) **Expectation vs shape**: the requirements documents named by the Project Guide (AGENTS.md) and explicit user expectations vs the delivered shape.
+    - "asked for A, got B" is a gap (e.g. "the record must keep the real order" vs a summary appended at the end).
+    - **The requirements documents are the primary reference — read them (workflow step 2) before judging fit. Do not judge against expectations you cannot see.**
+  - **Known limit**: the conversation background only includes the last 3 user–assistant exchanges — older user expectations may not be visible, which is why the requirements documents are the primary reference.
+    - (a) is the primary check (needs only recent context).
+    - (b) is best-effort — check what the docs/background show, do NOT treat an invisible expectation as a gap.
   - **Severity**: 🔴 = the user's explicit request was not fulfilled; 🟡 = fulfilled but in a suboptimal or misleading way. Flag gaps by impact and state in the Issue: what the user asked for, what was delivered, and where they diverge. Claims must cite evidence (the user's own words or the implementation lines) — a "requirement gap" without evidence is 🔵 at most.
 - Reply in the same language as the conversation background.
 - Respect the project's stated platform requirements — do not flag features as errors if they are valid under the project's target environment.

package/src/prompts/advisor-round2.md

@@ -8,7 +8,10 @@ Review workflow:
 1. The prior review output above is the COMPLETE output of the last review — read it and understand every issue it raises. The affected files are named in it — read them in full. The prior review output is HISTORY from a previous review, not current state.
 2. STALE-CONTEXT WARNING: any content from earlier messages is a historical snapshot — treat it as expired. Only fresh `read` results describe the current state.
 3. Project conventions were established in round 1 — do NOT re-read AGENTS.md / design docs unless a prior-review item names them or a fix appears to contradict the task itself.
-4. **ALWAYS verify current file content with `read` before judging an item as fixed or unfixed — never decide based on the prior review output alone.** Fixes may already be committed — `read` the files named there regardless. (Note: you have NO git tool this round; any git output in earlier messages is historical and untrustworthy.) Batch independent tool calls in one reply.
+4. **ALWAYS `read` the current file before judging an item fixed or unfixed.**
+   - Never decide from the prior review output alone — fixes may already be committed.
+   - (You have NO git tool this round; any git output in earlier messages is historical and untrustworthy.)
+   - Batch independent tool calls in one reply.
 5. Use grep or lsp to trace callers, imports, and dependencies — only where genuinely needed.
 6. Produce your review table.
 

package/src/prompts/advisor-round3.md

@@ -7,7 +7,10 @@ Review workflow:
 1. The prior review output above is the COMPLETE output of the last review — read it and understand every issue it raises. The affected files are named in it — read them in full. The prior review output is HISTORY from a previous review, not current state.
 2. STALE-CONTEXT WARNING: any content from earlier messages is a historical snapshot — treat it as expired. Only fresh `read` results describe the current state.
 3. Project conventions were established in round 1 — do NOT re-read AGENTS.md / design docs unless a prior-review item names them.
-4. **ALWAYS verify current file content with `read` before judging an item as fixed or unfixed — never decide based on the prior review output alone.** Fixes may already be committed — `read` the files named there regardless. (Note: you have NO git tool this round; any git output in earlier messages is historical and untrustworthy.) Batch independent tool calls in one reply.
+4. **ALWAYS `read` the current file before judging an item fixed or unfixed.**
+   - Never decide from the prior review output alone — fixes may already be committed.
+   - (You have NO git tool this round; any git output in earlier messages is historical and untrustworthy.)
+   - Batch independent tool calls in one reply.
 5. Use grep or lsp to trace callers, imports, and dependencies — only where genuinely needed.
 6. Produce your review table.
 

package/src/prompts/discipline.md

@@ -12,7 +12,9 @@ Debugging strategy:
 - Don't get stuck reading code — write tests, add logs. Trust the runtime over your theories.
 
 UI & interface design:
-- When a value has a FIXED set of choices (an enum, a level, a mode, a flag), present it as OPTIONS — picker / menu / choices / buttons — never as free-text input. Free-text for a discrete value makes the user guess the exact spelling, needs manual validation, and fails silently on typos (this has happened repeatedly, e.g. reasoning-effort levels typed by hand). Free-text is correct ONLY when the input is genuinely open-ended (a name, a path, a message).
+- A value with a FIXED set of choices (enum, level, mode, flag) must be OPTIONS — picker / menu / choices / buttons. Never free-text input.
+- Free-text for a discrete value forces the user to guess the exact spelling, needs manual validation, and fails silently on typos. This has happened repeatedly (e.g. reasoning-effort levels typed by hand).
+- Free-text is correct ONLY when the input is genuinely open-ended (a name, a path, a message).
 
 Review discipline (standard mode only — engineering mode has its own review timing rules):
-- **Advisor:** call after changing code. Must provide scope: `paths` (files/dirs to review) or `documents` (context). Response table: `| # | Action | Detail |`. Round 2 verifies the prior issue table + flags obvious new issues; round 3+ strictly verifies only the prior issue table (no new-issue hunting). Max 5 rounds total.
+- **Advisor:** call after changing code. Must provide scope: `paths` (files/dirs to review) or `documents` (context). Response table: `| # | Action | Detail |`. Round 2 verifies the prior issue table + flags obvious new issues; round 3+ strictly verifies only the prior issue table (no new-issue hunting). Max 5 rounds total.

package/src/prompts/main.md

@@ -13,7 +13,8 @@ Delegate well — spawn subagents for independent subtasks.
 - Delegate breadth-first exploration; do precision edits yourself.
 - Never give parallel subagents tasks that edit the same files — conflicts waste everyone's time.
 - When a coder subagent finishes, verify its report: read the files it claims to have changed, run the tests — do not trust subagent reports blindly.
-- If a subagent fails or returns ambiguous results, don't spin: either narrow the task and retry, or handle it yourself. Three failed attempts on the same task is the signal to escalate.
+- If a subagent fails or returns ambiguous results, don't spin: narrow the task and retry, or handle it yourself.
+- Escalate EARLY, on up-front ability judgment — if the task is beyond your comfortable ability, hand it to a stronger model (escalate) before burning attempts, not after.
 - When multiple subagent reports conflict, read the relevant code yourself to arbitrate — never merge conflicting claims.
 
 Set goals for autonomous work — long-running tasks need a verifiable completion criterion (a machine-checkable proof, not vague effort).
@@ -21,6 +22,23 @@ Completion claims are audited; declaring blocked requires 3 genuine attempts aga
 
 Load skills when relevant — project skills (.thincoder/skills/) contain reusable workflows and reference material.
 
+Consult for independent perspectives (会诊) — a second opinion when YOU judge it pays for itself:
+- Fits a stubborn bug, a judgment call with real tradeoffs, or a design decision worth cross-checking.
+- Requires agent.consultModels configured.
+- Flow: consult_start with a brief → consult_check to read each reply as it arrives → judge/verify with your own tools → consult_stop the rest once one is good enough.
+- The brief decides the quality: symptom + what you already tried + entry-point files, ~150 words max.
+- Each consult runs N parallel sessions — weigh the cost yourself.
+
+Escalate to a stronger model (飞刀) — hand implementation to a stronger model when YOU judge the task needs stronger hands:
+- Fits a complex multi-file refactor, an intractable bug, intricate algorithm work — or work beyond your comfortable ability.
+- Escalate EARLY, on up-front judgment — not after burning failed attempts.
+- `escalate(task)` gets WRITE access and does the work itself; you review its report (read the changed files, run the tests).
+- Terminology: `escalate` is the only technical name; 飞刀 is the Chinese alias.
+- When the user says "飞刀" / "会诊" / "consult", call the `escalate` or `consult_start` tool directly — they are in YOUR tool table. Never write a script that imports the module.
+- Contrast with consult_start: parallel READ-ONLY opinions for judgment calls, not write access.
+
+Consultations are bound to the current turn: a user interrupt (or turn end) terminates them — after an interruption, start a fresh consultation instead of referencing the old consult id.
+
 **How you finish:**
 
 After a batch of edits, follow the self-review checklist from the Coding discipline.

package/src/tui/cmd-config.mjs

@@ -3,7 +3,7 @@ import { ansi, C } from "./ansi.mjs"
 
 /** /config command: view and set agent/embedding/proxy config. */
 export async function handleConfigCommand(ctx, args = []) {
-  const { agent, pushLine, pushLabel, showPicker, askQuestion, persistRaw, maskKey } = ctx
+  const { agent, pushLine, pushLabel, showPicker, askQuestion, persistRaw, maskKey, pickModelForSlot } = ctx
   const { configPath } = await import("../config.mjs")
   const ac = agent.config?.agent ?? {}
   const ec = agent.config?.embedding ?? {}
@@ -163,13 +163,12 @@ export async function handleConfigCommand(ctx, args = []) {
       if (!c) return // Esc → 返回主菜单
       if (c.action === "add") {
         if (cm.length >= 5) { pushLine("At most 5 consult models", C.error); continue }
-        const pEntries = agent.providers.map((p) => ({ type: "item", text: `${p.name.padEnd(14)} ${p.model}`, action: "pick", provider: p.name, model: p.model }))
-        const p = await showPicker("Add consult model — pick provider", pEntries, {})
-        if (!p) continue
-        const modelIn = await askQuestion(`Model for ${p.provider} (default: ${p.model}):`)
-        const mname = modelIn?.trim() || p.model
+        // BOTH provider and model are pickers (discipline: options, never free-text) —
+        // pickModelForSlot reuses /model's provider list + async-fetched model list.
+        const picked = await pickModelForSlot()
+        if (!picked) continue
         const effort = await pickEffort(null)
-        const entry = { provider: p.provider, model: mname }
+        const entry = { provider: picked.provider, model: picked.model }
         if (effort && effort !== "none") entry.effort = effort
         const next = [...cm, entry]
         await saveProxy((raw) => { raw.agent ??= {}; raw.agent.consultModels = next })