cc-viewer 1.7.13 → 1.7.14

package/dist/index.html

@@ -21,7 +21,7 @@
     // 整体显示大小已弃用 CSS zoom：Electron 改用 webFrame.setZoomFactor（首屏抢占见
     // electron/tab-content-preload.js），纯浏览器交由用户用浏览器自带快捷键缩放，故此处不再设 zoom。
   </script>
-  <script type="module" crossorigin src="./assets/index-DSTQIMmZ.js"></script>
+  <script type="module" crossorigin src="./assets/index-CPLS-pSI.js"></script>
   <link rel="modulepreload" crossorigin href="./assets/vendor-antd-DADYo_zg.js">
   <link rel="modulepreload" crossorigin href="./assets/vendor-codemirror-tF6HNoR6.js">
   <link rel="modulepreload" crossorigin href="./assets/vendor-mdxeditor-CFAmRN3Y.js">

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "cc-viewer",
-  "version": "1.7.13",
+  "version": "1.7.14",
   "description": "Claude Code logging, visualization, and management toolkit — launch a web viewer alongside Claude Code with full request/response tracing, proxy, and mobile support",
   "license": "MIT",
   "main": "server.js",

package/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

package/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