sweet-search 2.6.11 → 2.6.12

package/core/prompt-optimization/data/p7-final/sweet-search-system-prompt-mcp.md

@@ -1,14 +1,16 @@
 ---
 variant: mcp
-derived_from: p7-v1-mpp
-source_prompt: core/prompt-optimization/data/p7-variant-restarts/p7-gen3-candidates/Mpp.md
+derived_from: p7-v1-mpppp
+source_prompt: core/prompt-optimization/data/p7-variant-restarts/p7-gen3-candidates/Mpppp.md
 benchmarked: false
 note: >-
-  Hand-derived MCP-tool variant of the frozen M++ champion (p7-v1-mpp). The
-  STRATEGY core — routing by what-you-hold, trust-the-top-hit, sufficiency
-  stops, the two-probe absence rule, the <state_summary> gate, and the output
-  discipline — is preserved (semantics intact; the <state_summary> gate and
-  Output section are byte-identical, the rest carries only the tool-mechanics
+  Hand-derived MCP-tool variant of the M++++ champion (p7-v1-mpppp = M++ +
+  stop-discipline scoping edits: search-rules-only intro, "stop searching" /
+  "Search output" wording; routing unchanged from the frozen, benchmarked
+  M++). The STRATEGY core — routing by what-you-hold, trust-the-top-hit,
+  sufficiency stops, the two-probe absence rule, the <state_summary> gate, and
+  the search-output discipline — is preserved (semantics intact; the rest
+  carries only the tool-mechanics
   rename). Only the tool-mechanics layer is remapped: the six ss-* CLI commands collapse onto the sweet-search MCP
   tool surface (a UNIFIED `search` that subsumes ss-search/ss-find/ss-grep, plus
   `trace` / `read-semantic` / `read` / `repo-map`). The anti-raw-scan discipline
@@ -21,9 +23,11 @@ note: >-
 ---
 # Sweet-search — code search tool guide
 
+These are code-search rules only — they never decide when the task is done; the deliverable is whatever the task/prompt asks for. When the task calls for a change, locating the right code is a means, not the finish line: apply the edit with your normal file-editing tool and never a description of the fix in place of the fix.
+
 Sweet-search indexes the working tree (uncommitted edits too) and searches it faster and cheaper than scanning files by hand. Use the sweet-search tools for all code search and navigation, in preference to native Grep/Read or shell `grep`/`find`/`cat`/`ls` — the index covers every file, so a manual scan only re-confirms a sweet-search result at higher cost, never beats it. Reach for a raw read only for an edit too recent to be reconciled (seconds old). Never re-run a sweet-search hit as a native Grep. Any sub-agent you delegate to must use these sweet-search tools, with this system prompt verbatim.
 
-## Tools
+## Tools (search tools, via the sweet-search MCP server)
 The sweet-search MCP server exposes these (call each by the name your client lists it under):
 - **search** — hybrid code search; returns ranked, self-contained code blocks. Your primary tool: it subsumes semantic search, exact-literal search, and semantic-reranked regex. Give it a natural-language query for a concept, or pass a `regex` (or lexical mode) for an exact token.
 - **trace** — a symbol's callers, callees and impact in one call.
@@ -39,13 +43,13 @@ The sweet-search MCP server exposes these (call each by the name your client lis
 Trust the top ranked result; confirm with at most one narrow `read`, never a re-run of a matching hit.
 
 ## Multi-file
-Chain inside the tools: land the entry file, `read-semantic` it for the import or handoff symbol, then `search` the downstream module. The trace is COMPLETE the moment you can name the link from the entry symbol to the thing it reaches; stop there. Leaf bodies, macro expansions, and the next hop down are not the answer unless asked, and chasing them — or dropping to a native Grep/Read to "just look" — is the main multi-file cost trap.
+Chain inside the tools: land the entry file, `read-semantic` it for the import or handoff symbol, then `search` the downstream module. The trace is COMPLETE the moment you can name the link from the entry symbol to the thing it reaches; stop tracing there. Leaf bodies, macro expansions, and the next hop down are not the answer unless asked, and chasing them — or dropping to a native Grep/Read to "just look" — is the main multi-file cost trap.
 
-## A confirmed absence is a complete answer
-When what you're looking for may not exist, absence is settled once TWO complementary `search` probes come back empty for the same concept: one in natural language and one as a broad `regex` on its likeliest identifier (a short substring/prefix). A search that returns plausible-but-off-target code is the decoy, not a lead — do not chase it. Two empty index probes over the whole codebase are more conclusive than any native scan or file listing, so state the negative and stop: no third synonym, no native `grep`/`ls`/`cat` enumeration.
+## A confirmed absence is a complete search answer
+When what you're looking for may not exist, absence is settled once TWO complementary `search` probes come back empty for the same concept: one in natural language and one as a broad `regex` on its likeliest identifier (a short substring/prefix). A search that returns plausible-but-off-target code is the decoy, not a lead — do not chase it. Two empty index probes over the whole codebase are more conclusive than any native scan or file listing, so state the negative and stop searching: no third synonym, no native `grep`/`ls`/`cat` enumeration.
 
 ## Before the third probe
 Before your third sweet-search probe in the current search iteration — or before your final answer, whichever comes first — output a `<state_summary>` block with exactly: (1) one sentence on what you've established, (2) one sentence on your current blind spot.
 
-## Output
-Stop the instant your evidence answers what you're looking for — one confirmed file+symbol, or one named cross-file link, is enough; gather no corroboration you were not asked for. Name the file(s) and symbol(s) and how they answer what you need, or `no-match`.
+## Search output
+Stop searching the instant your evidence answers what you're looking for — one confirmed file+symbol, or one named cross-file link, is enough; gather no corroboration you were not asked for. Name the file(s) and symbol(s) and how they answer what you need, or `no-match` — then finish whatever the task/prompt asks for.

package/core/prompt-optimization/data/p7-final/sweet-search-system-prompt.md

@@ -1,12 +1,12 @@
 ---
-run_id: p7-v1-mpp
+run_id: p7-v1-mpppp
 score_sonnet: 0.993
 score_gpt5_5: 0.988
 joint_maximin: 0.988
 eas_factor: null
 length_penalty: null
 final_score: null
-token_count: 1066
+token_count: 1175
 scs_cwSCS: 0.931
 scs_min_paraphrase_accuracy: 1
 homp_family_pass: true
@@ -19,9 +19,11 @@ vault_within_15pct_of_heldout: true
 ---
 # Sweet-search — code search tool guide
 
+These are code-search rules only — they never decide when the task is done; the deliverable is whatever the task/prompt asks for. When the task calls for a change, locating the right code is a means, not the finish line: apply the edit with your normal file-editing tool and never a description of the fix in place of the fix.
+
 Sweet-search indexes the working tree (uncommitted edits too) and searches it faster and cheaper than raw shell. Use the `ss-*` tools for all code search and navigation. Reach for raw `grep`/`find`/`cat`/`ls` or the native reader only for an edit too recent to be reconciled (seconds old) — otherwise the index covers every file, so a raw scan only re-confirms an `ss-*` result at higher cost, never beats it. Never re-run an `ss-*` hit as raw grep. Any sub-agent you delegate to must use these `ss-*` tools, with this system prompt verbatim.
 
-## Tools (invoke via Bash)
+## Tools (search commands, invoked via Bash)
 `ss-search`/`ss-find` return ranked code blocks; `ss-grep` is file:line only; `ss-semantic` returns the top ranked spans in one file; `ss-trace` returns a symbol's callers, callees and impact. `ss-find` is `ss-grep`'s regex plus a query that semantically re-ranks the matches.
 - `ss-search "<query>" [-k N]` — semantic; default when you have no exact symbol
 - `ss-find "<query>" --regex "<regex>" [-k N]`
@@ -38,13 +40,13 @@ Sweet-search indexes the working tree (uncommitted edits too) and searches it fa
 Trust the top ranked result; confirm with at most one narrow `ss-read`, never a re-run of a matching hit.
 
 ## Multi-file
-Chain inside the tools: land the entry file, `ss-semantic` it for the import or handoff symbol, then `ss-search`/`ss-find` the downstream module. The trace is COMPLETE the moment you can name the link from the entry symbol to the thing it reaches; stop there. Leaf bodies, macro expansions, and the next hop down are not the answer unless asked, and chasing them — or dropping to raw `cat`/`grep` to "just look" — is the main multi-file cost trap.
+Chain inside the tools: land the entry file, `ss-semantic` it for the import or handoff symbol, then `ss-search`/`ss-find` the downstream module. The trace is COMPLETE the moment you can name the link from the entry symbol to the thing it reaches; stop tracing there. Leaf bodies, macro expansions, and the next hop down are not the answer unless asked, and chasing them — or dropping to raw `cat`/`grep` to "just look" — is the main multi-file cost trap.
 
-## A confirmed absence is a complete answer
-When what you're looking for may not exist, absence is settled once TWO complementary index probes come back empty for the same concept: one `ss-search` in natural language and one broad `ss-grep` on its likeliest identifier (a short substring/prefix). A semantic search that returns plausible-but-off-target code is the decoy, not a lead — do not chase it. Two empty index probes over the whole codebase are more conclusive than any raw scan or file listing, so state the negative and stop: no third synonym, no `find`/`ls`/`cat` enumeration, no native scan.
+## A confirmed absence is a complete search answer
+When what you're looking for may not exist, absence is settled once TWO complementary index probes come back empty for the same concept: one `ss-search` in natural language and one broad `ss-grep` on its likeliest identifier (a short substring/prefix). A semantic search that returns plausible-but-off-target code is the decoy, not a lead — do not chase it. Two empty index probes over the whole codebase are more conclusive than any raw scan or file listing, so state the negative and stop searching: no third synonym, no `find`/`ls`/`cat` enumeration, no native scan.
 
 ## Before the third probe
 Before your third sweet-search probe in the current search iteration — or before your final answer, whichever comes first — output a `<state_summary>` block with exactly: (1) one sentence on what you've established, (2) one sentence on your current blind spot.
 
-## Output
-Stop the instant your evidence answers what you're looking for — one confirmed file+symbol, or one named cross-file link, is enough; gather no corroboration you were not asked for. Name the file(s) and symbol(s) and how they answer what you need, or `no-match`.
+## Search output
+Stop searching the instant your evidence answers what you're looking for — one confirmed file+symbol, or one named cross-file link, is enough; gather no corroboration you were not asked for. Name the file(s) and symbol(s) and how they answer what you need, or `no-match` — then finish whatever the task/prompt asks for.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "sweet-search",
-  "version": "2.6.11",
+  "version": "2.6.12",
   "description": "Sweet Search - SOTA Hybrid Code Search Engine with WASM CatBoost Query Router, Semantic/Lexical/Structural Search, and Multilingual Support",
   "type": "module",
   "main": "core/search/sweet-search.js",
@@ -167,13 +167,13 @@
     "vitest": "^4.0.16"
   },
   "optionalDependencies": {
-    "@sweet-search/native-darwin-arm64": "2.6.11",
-    "@sweet-search/native-darwin-x64": "2.6.11",
-    "@sweet-search/native-linux-arm64-gnu": "2.6.11",
-    "@sweet-search/native-linux-arm64-gnu-cuda": "2.6.11",
-    "@sweet-search/native-linux-x64-gnu": "2.6.11",
-    "@sweet-search/native-linux-x64-gnu-cuda": "2.6.11",
-    "@sweet-search/bg-priority": "2.6.11"
+    "@sweet-search/native-darwin-arm64": "2.6.12",
+    "@sweet-search/native-darwin-x64": "2.6.12",
+    "@sweet-search/native-linux-arm64-gnu": "2.6.12",
+    "@sweet-search/native-linux-arm64-gnu-cuda": "2.6.12",
+    "@sweet-search/native-linux-x64-gnu": "2.6.12",
+    "@sweet-search/native-linux-x64-gnu-cuda": "2.6.12",
+    "@sweet-search/bg-priority": "2.6.12"
   },
   "engines": {
     "node": ">=18.0.0"

package/scripts/hooks/remind-tools.mjs

@@ -18,7 +18,7 @@
  * both the file and the settings entry.
  */
 
-// Tool surface mirrors the shipped M++ policy (the ss-* tools). Kept terse —
+// Tool surface mirrors the shipped M++++ policy (the ss-* tools). Kept terse —
 // the full decision tree lives in CLAUDE.md/AGENTS.md; this is just a nudge to
 // stop the agent drifting back to raw grep/read between prompts.
 const REMINDER = [
@@ -30,8 +30,9 @@ const REMINDER = [
   '- Callers/callees/impact of a symbol: ss-trace <symbol>',
   '- Known file, unclear span:           ss-semantic <file> "<query>"',
   '- Known file + line range:            ss-read <file> <start> <end>',
-  'STOP the instant your evidence answers the query — one confirmed file+symbol is enough;',
+  'STOP searching the instant your evidence answers the query — one confirmed file+symbol is enough;',
   'a second call costs more than it saves. Multi-file flow questions get one follow-up.',
+  'Search rules only — if the task asks for a change, apply the edit.',
   '</sweet-search-reminder>',
   '',
 ].join('\n');

package/scripts/inject-agent-instructions.js

@@ -46,17 +46,18 @@ function escapeRegex(s) {
   return s.replace(/[.*+?^${}()|[\]\\]/g, '\\$&');
 }
 
-// ─── Canonical policy body = the frozen M++ champion (integration seam) ──────
+// ─── Canonical policy body = the M++++ champion (integration seam) ───────────
 //
 // Plan §10 / §3.7.1 step 13 / DDD "Integration seam": scripts/init.js is the
 // SOLE consumer of the prompt-optimization ship-file. We read that artifact at
-// load time and strip its YAML front-matter; the remaining body is the frozen
-// M++ champion (PHASE7), injected VERBATIM into the harness files so users get
-// exactly the prompt that was benchmarked (held-out 0.988 Maximin, OOD 0.952,
-// HOMP/SCS/counter all pass; 5-cell cross-harness validated). Per-harness shims
+// load time and strip its YAML front-matter; the remaining body is the M++++
+// champion (PHASE7 M++ — held-out 0.988 Maximin, OOD 0.952, HOMP/SCS/counter
+// all pass, 5-cell cross-harness validated — plus the stop-discipline scoping
+// edits that fix M++'s over-stopping on FIX tasks; routing unchanged),
+// injected VERBATIM into the harness files. Per-harness shims
 // (Cursor frontmatter, @imports) are applied at write-time, not embedded here.
 //
-// The artifact is generated from Mpp.md by
+// The artifact is generated from Mpppp.md by
 // `core/prompt-optimization/sweep/finalize-mpp.mjs` and shipped via the
 // package.json "files" list. If it is missing we fail LOUDLY rather than
 // silently shipping a placeholder/older policy.
@@ -75,7 +76,7 @@ export function stripFrontMatter(text) {
   return text.replace(/^---\r?\n[\s\S]*?\r?\n---\r?\n/, '');
 }
 
-function readShippedPolicy(rel = SHIP_FILE_REL, { label = 'M++' } = {}) {
+function readShippedPolicy(rel = SHIP_FILE_REL, { label = 'M++++' } = {}) {
   const here = dirname(fileURLToPath(import.meta.url)); // <pkg>/scripts
   const shipPath = join(here, '..', rel);
   let raw;
@@ -102,7 +103,7 @@ let _mcpPolicyBody = null;
 /** Lazily read + cache the MCP-variant policy body. */
 export function getMcpPolicyBody() {
   if (_mcpPolicyBody == null) {
-    _mcpPolicyBody = readShippedPolicy(MCP_SHIP_FILE_REL, { label: 'M++ (MCP variant)' });
+    _mcpPolicyBody = readShippedPolicy(MCP_SHIP_FILE_REL, { label: 'M++++ (MCP variant)' });
   }
   return _mcpPolicyBody;
 }