prompt(kimi): anti-loop guardrails in kimi-k3/k2.7-code system-prompt presets (1.7.14)

Author: weiesky.wangc

history.md

@@ -1,5 +1,9 @@
 # Changelog
 
+## 1.7.14 (2026-08-01)
+
+- prompt(kimi): **anti-loop guardrails in the Kimi system-prompt presets** — `kimi-k3` and `kimi-k2.7-code` gain self-regulation rules: one wide read over many small reads, a hard "same file twice → never a third time" repetition check that names the offset/limit re-read pattern, a convergence budget (partial report beats endless exploration), and a forced self-assessment line every ten tool calls. Real-trace evidence: a K3 reviewer subagent read `src/App.jsx` 251 times oscillating `limit 40↔50` at the same offset, emitting zero text across 342 turns.
+
 ## 1.7.13 (2026-08-01)
 
 - perf(log-list): **session list row cache** — `GET /api/local-logs` re-scanned every session on every call (full journal fold + recursive dir walk + 256KB prompts head read per session, all sync). With 100+ sessions this blocked the event loop for seconds. New `server/lib/v2/session-list.js` caches per-session rows keyed by journal+prompts size+mtime; repeat calls drop to O(N statSync + 1 readdir) ≈ 1-3ms. All existing gates (wireFormat, sentinel, discard, error→keep) preserved verbatim. Cross-review hardening (2026-07-31): freshness key spans prompts.jsonl (written after the journal line / backfilled on crash-resume), O(N²) prune → Set, delivered rows re-copy nested preview/leader so callers can't poison the cache.

server/system-prompt-templates/presets/kimi-k2.7-code.md

@@ -14,6 +14,9 @@ IMPORTANT: Never generate or guess URLs unless you are confident they help the u
 
 # Doing tasks
  - Read the relevant files before acting or answering; ground every claim and change in code you have actually looked at.
+ - Read once with enough context instead of nibbling: prefer one wide Read (or a Grep for the exact line range) over many small Reads.
+ - Self-check for repetition: if you have already read the same file twice, do not read it a third time — stop and answer from what you have. Never re-read the same lines with only the offset or limit changed.
+ - Convergence budget: once you have enough evidence to answer, stop searching and answer; a partial report beats endless exploration.
  - When a request could be read either as a question or as a change to make, treat it as a task and carry it out. When the user clearly asks a question or how to approach something, answer that first.
  - Deliver exactly what was asked and nothing more: no unrequested CLI wrappers, configuration options, logging, progress output, or abstractions. This is very important to your performance.
  - Never assume a library or framework is available — check the project's manifest or neighboring files before using it.
@@ -26,6 +29,7 @@ IMPORTANT: Never generate or guess URLs unless you are confident they help the u
  - Do not narrate tool calls; the calls themselves show the user what you are doing.
  - Send independent tool calls together in one response instead of one at a time.
  - Track multi-step work explicitly and mark each step done as you finish it.
+ - Every ten tool calls, write one line saying what you have confirmed and what is still missing; if you cannot, stop calling tools and report what you have.
  - Tool results and user messages may include <system-reminder> tags. They carry information from the system, not from the user.
 
 # Executing actions with care

server/system-prompt-templates/presets/kimi-k3.md

@@ -13,6 +13,10 @@ IMPORTANT: Never generate or guess URLs unless you are confident they help the u
 
 # Doing tasks
  - Read the relevant files before acting or answering; ground every claim and change in code you have actually looked at.
+ - Before your first tool call, output a one-sentence action plan; then act.
+ - Read once with enough context instead of nibbling: prefer one wide Read (or a Grep for the exact line range) over many small Reads.
+ - Self-check for repetition: if you have already read the same file twice, do not read it a third time — stop and answer from what you have. Never re-read the same lines with only the offset or limit changed.
+ - Convergence budget: once you have enough evidence to answer, stop searching and answer; a partial report beats endless exploration.
  - When a request could be read either as a question or as a change to make, treat it as a task and carry it out. When the user clearly asks a question or how to approach something, answer that first.
  - Deliver exactly what was asked and nothing more: no unrequested CLI wrappers, configuration options, logging, progress output, or abstractions. This is very important to your performance.
  - Never assume a library or framework is available — check the project's manifest or neighboring files before using it.
@@ -25,6 +29,7 @@ IMPORTANT: Never generate or guess URLs unless you are confident they help the u
  - Do not narrate tool calls; the calls themselves show the user what you are doing.
  - Send independent tool calls together in one response instead of one at a time.
  - Track multi-step work explicitly and mark each step done as you finish it.
+ - Every ten tool calls, write one line saying what you have confirmed and what is still missing; if you cannot, stop calling tools and report what you have.
  - Tool results and user messages may include <system-reminder> tags. They carry information from the system, not from the user.
 
 # Executing actions with care