opencode-acp 1.18.0-pr.394.154 → 1.18.0-pr.397.156

package/dist/index.js

@@ -6309,109 +6309,6 @@ function evaluatePreCommitQuality(rawMessages, messageIds, messageTokenById, sum
   }
 }
 
-// node_modules/context-compress-algorithms/dist/chunk-YCHW53QG.js
-var COMPRESS_PHILOSOPHY = `Compression Philosophy:
-- All compression serves the primary task, but be frugal.
-- Context capacity is precious. Save context by compressing consumed outputs, not by avoiding tools.
-- Compress by need, not by percentage.
-- Work from summaries, not raw tool outputs. All listed ranges (user prompts, tool outputs, code, logs, exploration, intermediate steps) should be compressed to summary format \u2014 the ONLY exceptions are protected content, content the current step is actively using, or critical content you cannot reconstruct.
-- Curate summaries like a well-structured document. User prompts, compressed tool outputs, code, logs, or skill-call intermediate results that are critically important should be preserved \u2014 not by exempting them from compression, but by embedding them in the summary via [[KEEP:mNNNNN]] (auto-expanded verbatim) and [[REF:mNNNNN|description]] (compact link).`;
-var HOW_TO_COMPRESS_RULES = `HOW TO COMPRESS
-
-When you call \`compress\`, the summary you write becomes the only record of the replaced conversation. Make it self-contained and complete: every user request, experiment purpose, and work task in the range must be accurately captured. A later reader (or you, after decompressing) should be able to continue the task WITHOUT needing the original.
-
-KEEP VERBATIM \u2014 never paraphrase or abbreviate these:
-- Full file paths with line numbers, directory prefix on every mention (\`lib/hooks.ts:347\`, \`src/index.ts:12-18\`, \`gatenet_v3/model.py:45\`). Never abbreviate to a bare filename (\`hooks.ts\`, \`model.py\`) \u2014 they are ambiguous and cannot be grepped or decompressed-to later.
-- Function, class, and type signatures (exact names, params, return types) AND critical code lines that encode logic \u2014 the line that IS the finding, not just the function name (e.g. \`kv_keys += define_gate * a_key[i](emb)\` is more useful than "see model_kvnet.py").
-- Error messages and stack traces (exact text \u2014 you need the literal string to grep for it later).
-- Key details from reports and analyses \u2014 not just the conclusion. Keep the comparison numbers and the mechanism, not "X is worse" alone (write "1.76\xD7 PPL gap because KV store is static", not "KVNet underperforms").
-- Decisions and their rationale ("chose X over Y because Z" \u2014 the "because" is load-bearing; without it the decision looks arbitrary).
-- Constraints discovered ("must support Node 22", "no new dependencies", "AGENTS.md forbids \`as any\`").
-- Exact values: versions, config keys, thresholds, magic numbers.
-- User intent \u2014 quote short user messages verbatim. When the message is too long to quote, preserve intent with extra care: do not change scope, constraints, priorities, acceptance criteria, or requested outcomes. Mark them clearly as past quotes (e.g., "User said: ..."), not as current directives. Losing these changes the task itself.
-- The user's overall goal and any changes to it \u2014 the big-picture objective plus how it evolved during the compressed range. Each summary must reflect the goal as it stood at the end of the range, including pivots (e.g., "initially: fix bug X \u2192 pivoted to: refactor module Y after discovering root cause"). Losing the goal or its evolution makes all subsequent work appear unmotivated.
-- Purpose behind each significant action \u2014 preserve not just what was done but why: the hypothesis behind each experiment, the question behind each exploration, the task goal behind each work action. Without purpose, the summary reads as disconnected technical steps with no through-line.
-- Open questions and unresolved TODOs \u2014 losing these changes what work appears to remain.
-- Message refs of key anchors (\`m00420\`, \`m00510\u2013m00520\`) \u2014 they let you or a later reader jump back via decompress to the exact original.
-
-DROP \u2014 extract the signal, discard the vessel:
-- Verbose logs (build/test/\`npm\` output) once you have captured the error line or the result.
-- Duplicate file reads once the needed content is recorded.
-- Consumed exploration \u2014 search hits, agent return values, successful tool outputs \u2014 once you have extracted the facts you need (same rule as dead-ends, but nothing went wrong; the content is simply spent).
-- Dead-end exploration \u2014 but PRESERVE the lesson in one line: "tried X, failed because Y".
-- Back-and-forth discussion and self-corrections once the final position is captured (keep the outcome, drop the journey to it).
-- Repeated status checks (\`git status\`, \`ls\`) once state is known.
-
-For each significant item you DROP (scripts, reports, large analyses, long tool outputs), add a one-line CONTENT description of what it covers \u2014 not where it lives. Bad: "probe script at /path/probe_kvnet.py". Good: "probe_kvnet.py: tests n-gram baseline, generation quality, long-range dependency, position sensitivity, op pipeline, QUERY attention." This lets a later decompress target the right block by relevance, not by guessing locations.
-
-KEEP MARKERS: \`[[KEEP:mNNNNN]]\` expands original message content into the summary (truncated to a max length). Do NOT use KEEP for verbose command output, diagnostic scripts, log dumps, or any content whose value is in the conclusion rather than the raw output \u2014 summarize these or use \`[[REF:mNNNNN|desc]]\` instead.
-
-PRIORITY \u2014 when the summary must be compact, preserve in this order:
-1. User's overall goal, goal evolution, intent, and hard constraints (losing these changes the task).
-2. Decisions and rationale.
-3. Exact technical artifacts: paths, signatures, errors, values.
-4. Conclusions and key findings.
-5. Lessons learned: what failed and why.
-
-Write dense, scannable bullets \u2014 not narrative prose. If the range spans distinct concerns (request \u2192 findings \u2192 decision), group bullets under short thematic headers so a reader can scan to the part they need. Every line must earn its place. Do not mimic the style of existing summaries in context; follow these rules.`;
-var TIER2_DISTILL_RULES = `TIER 2 COMPRESSION \u2014 DISTILLATION
-
-You are compressing historical summaries (not raw conversation). These summaries have already captured the details. Your job is to DISTILL them: write a holistic summary of what matters for future work, discarding the process.
-
-KEEP \u2014 these are the only things that survive distillation:
-- Decisions and their rationale ("chose X over Y because Z" \u2014 the "because" is load-bearing).
-- Final outcomes: version numbers shipped, PR numbers merged/closed, bugs fixed or deferred.
-- Key lessons: what failed and why ("tried X, failed because Y"). These prevent repeating mistakes.
-- Critical constraints discovered ("must support Node 22", "AGENTS.md forbids as any").
-- Design decisions with architectural impact ("chose compress-as-anchor over synthetic messages because prefix cache").
-- Whether content is OBSOLETE or SUPERSEDED \u2014 mark with one line: "[SUPERSEDED by PR #NNN]" or "[OBSOLETE: deleted in vX.Y.Z]".
-- Function/class/type names and module paths that are the SUBJECT of the work \u2014 e.g., "fixed filterCompressedRanges in prune.ts". Not exact line numbers or full signatures \u2014 just enough to LOCATE the code.
-- Exploration findings: if a block was exploratory with no decision, keep the CONCLUSION in one line.
-
-DROP \u2014 these were useful during the work but are no longer needed:
-- Exact line numbers, diffs, verbose function signatures, full code listings.
-- Build/deploy process details, test execution steps.
-- Review process details (who reviewed, what rounds, test counts).
-- Verbose logs, command output, intermediate debugging steps.
-
-FORMAT:
-- Write a HOLISTIC summary grouped by THEME, not by source block.
-- NO per-block headers. NO "Source: bN" lines. This is a review of what happened, not a catalog of blocks.
-- Group related work together: all releases in one section, all bug fixes in another, all architecture decisions in a third.
-- Start with the most important outcomes (shipped releases, merged PRs, critical bugs).
-- Dense, scannable bullets \u2014 no narrative prose.
-- Most blocks will collapse into 1-2 bullets within a theme group. Many will have nothing worth keeping \u2014 omit them entirely.`;
-var TIER3_CONDENSE_RULES = `TIER 3 COMPRESSION \u2014 ULTRA-CONDENSATION
-
-You are compressing distilled summaries (Tier 2) into ultra-condensed facts (Tier 3). The distilled summaries already contain only decisions and outcomes. Your job is to reduce them to bare factual references.
-
-PRIORITY \u2014 keep in this order:
-1. Shipped outcomes (versions released, PRs merged) \u2014 these are permanent record.
-2. Open work (PRs/issues still pending) \u2014 these may need follow-up.
-3. Key decisions with architectural impact ("chose X over Y because Z").
-4. Critical constraints ("must support Node 22").
-Drop everything else. Tier 3 is a lookup index, not a knowledge base.
-
-FORMAT:
-- Write a HOLISTIC list of bare facts, grouped by theme \u2014 not by source block.
-- NO per-block headers. NO "Source: bN" lines.
-- Each fact is a single line: "[PR/Issue/Version] \u2014 [outcome in \u22648 words]"
-- Merge related facts aggressively. If multiple blocks concern the same release/feature/bug, output ONE line covering all of them.
-- No explanations, no rationale, no process \u2014 just the fact.
-
-EXAMPLES:
-- "v1.13.0 shipped \u2014 quality gate + GC fix (7 PRs)"
-- "PR #196 merged \u2014 preserve-first-user (supersedes #169)"
-- "Bug 1214 fixed \u2014 compress consumed all user messages"
-- "Chose compress-as-anchor \u2014 prefix cache benefit over synthetic injection"
-- "Constraint: AGENTS.md forbids as any \u2014 never suppress types"
-
-DROP:
-- Multi-sentence context. If a fact needs >1 sentence, it's too detailed for Tier 3.
-- Lessons learned ("tried X, failed because Y") \u2014 drop UNLESS the failure is likely to recur and the block is <30 days old.
-- Design rationale details \u2014 keep the decision, drop the "because" unless it's a critical constraint.
-- Anything marked [OBSOLETE] or [SUPERSEDED] \u2014 drop entirely, note "[N blocks obsolete]" at the end.`;
-
 // lib/compress/quality-gate/rejection.ts
 function formatMetric(result, name) {
   const m = result.metrics.find((x) => x.name === name);
@@ -6438,6 +6335,7 @@ function computeStats(plan) {
 function buildQualityRejectionError(plan, result) {
   const stats = computeStats(plan);
   const metrics = [
+    `Reason: ${result.reason || "unknown"}`,
     `Original: ~${stats.originalTokens} tokens`,
     `Summary: ${stats.summaryChars} chars`,
     `Ratio: ${stats.ratio}:1`,
@@ -6451,17 +6349,7 @@ function buildQualityRejectionError(plan, result) {
 Range: ${plan.startId}\u2013${plan.endId}
 ${metrics.join("\n")}
 
-\u26A0\uFE0F CRITICAL: Compression is the ONLY mechanism for preserving historical context in this session.
-Once a compression is accepted, the original messages are permanently removed from visible context.
-Your summary becomes the SOLE record. If it fails, subsequent work is built on a broken foundation \u2014
-memory loss \u2192 wrong assumptions \u2192 entire reasoning chain collapse.
-Treat every compression with maximum care.
-
-${HOW_TO_COMPRESS_RULES}
-
-To retry: rewrite a more complete summary that preserves critical details (file paths, decisions,
-exact values, errors). Then add "acknowledgeRisk": true to the compress tool call parameters.
-Without acknowledgeRisk: true, the compression will be rejected again.`;
+Retry: rewrite a more complete summary that preserves critical details (file paths, decisions, exact values, errors) and call compress again on the same range \u2014 the gate re-evaluates automatically. Full compression rules are already in your system prompt. If you are confident the summary is correct despite the metrics, add "acknowledgeRisk": true to bypass this rejection once.`;
   return new Error(message);
 }
 
@@ -8333,6 +8221,109 @@ var ITERATION_CANDIDATE_GUIDANCE = `
 MICRO candidates are complete large messages or tool transactions. EPISODE candidates are contiguous historical segments. They are independent suggestions and may be batched, but preserve anything still needed for the current task. Do not compress active work or every candidate.
 `;
 
+// node_modules/context-compress-algorithms/dist/chunk-YCHW53QG.js
+var COMPRESS_PHILOSOPHY = `Compression Philosophy:
+- All compression serves the primary task, but be frugal.
+- Context capacity is precious. Save context by compressing consumed outputs, not by avoiding tools.
+- Compress by need, not by percentage.
+- Work from summaries, not raw tool outputs. All listed ranges (user prompts, tool outputs, code, logs, exploration, intermediate steps) should be compressed to summary format \u2014 the ONLY exceptions are protected content, content the current step is actively using, or critical content you cannot reconstruct.
+- Curate summaries like a well-structured document. User prompts, compressed tool outputs, code, logs, or skill-call intermediate results that are critically important should be preserved \u2014 not by exempting them from compression, but by embedding them in the summary via [[KEEP:mNNNNN]] (auto-expanded verbatim) and [[REF:mNNNNN|description]] (compact link).`;
+var HOW_TO_COMPRESS_RULES = `HOW TO COMPRESS
+
+When you call \`compress\`, the summary you write becomes the only record of the replaced conversation. Make it self-contained and complete: every user request, experiment purpose, and work task in the range must be accurately captured. A later reader (or you, after decompressing) should be able to continue the task WITHOUT needing the original.
+
+KEEP VERBATIM \u2014 never paraphrase or abbreviate these:
+- Full file paths with line numbers, directory prefix on every mention (\`lib/hooks.ts:347\`, \`src/index.ts:12-18\`, \`gatenet_v3/model.py:45\`). Never abbreviate to a bare filename (\`hooks.ts\`, \`model.py\`) \u2014 they are ambiguous and cannot be grepped or decompressed-to later.
+- Function, class, and type signatures (exact names, params, return types) AND critical code lines that encode logic \u2014 the line that IS the finding, not just the function name (e.g. \`kv_keys += define_gate * a_key[i](emb)\` is more useful than "see model_kvnet.py").
+- Error messages and stack traces (exact text \u2014 you need the literal string to grep for it later).
+- Key details from reports and analyses \u2014 not just the conclusion. Keep the comparison numbers and the mechanism, not "X is worse" alone (write "1.76\xD7 PPL gap because KV store is static", not "KVNet underperforms").
+- Decisions and their rationale ("chose X over Y because Z" \u2014 the "because" is load-bearing; without it the decision looks arbitrary).
+- Constraints discovered ("must support Node 22", "no new dependencies", "AGENTS.md forbids \`as any\`").
+- Exact values: versions, config keys, thresholds, magic numbers.
+- User intent \u2014 quote short user messages verbatim. When the message is too long to quote, preserve intent with extra care: do not change scope, constraints, priorities, acceptance criteria, or requested outcomes. Mark them clearly as past quotes (e.g., "User said: ..."), not as current directives. Losing these changes the task itself.
+- The user's overall goal and any changes to it \u2014 the big-picture objective plus how it evolved during the compressed range. Each summary must reflect the goal as it stood at the end of the range, including pivots (e.g., "initially: fix bug X \u2192 pivoted to: refactor module Y after discovering root cause"). Losing the goal or its evolution makes all subsequent work appear unmotivated.
+- Purpose behind each significant action \u2014 preserve not just what was done but why: the hypothesis behind each experiment, the question behind each exploration, the task goal behind each work action. Without purpose, the summary reads as disconnected technical steps with no through-line.
+- Open questions and unresolved TODOs \u2014 losing these changes what work appears to remain.
+- Message refs of key anchors (\`m00420\`, \`m00510\u2013m00520\`) \u2014 they let you or a later reader jump back via decompress to the exact original.
+
+DROP \u2014 extract the signal, discard the vessel:
+- Verbose logs (build/test/\`npm\` output) once you have captured the error line or the result.
+- Duplicate file reads once the needed content is recorded.
+- Consumed exploration \u2014 search hits, agent return values, successful tool outputs \u2014 once you have extracted the facts you need (same rule as dead-ends, but nothing went wrong; the content is simply spent).
+- Dead-end exploration \u2014 but PRESERVE the lesson in one line: "tried X, failed because Y".
+- Back-and-forth discussion and self-corrections once the final position is captured (keep the outcome, drop the journey to it).
+- Repeated status checks (\`git status\`, \`ls\`) once state is known.
+
+For each significant item you DROP (scripts, reports, large analyses, long tool outputs), add a one-line CONTENT description of what it covers \u2014 not where it lives. Bad: "probe script at /path/probe_kvnet.py". Good: "probe_kvnet.py: tests n-gram baseline, generation quality, long-range dependency, position sensitivity, op pipeline, QUERY attention." This lets a later decompress target the right block by relevance, not by guessing locations.
+
+KEEP MARKERS: \`[[KEEP:mNNNNN]]\` expands original message content into the summary (truncated to a max length). Do NOT use KEEP for verbose command output, diagnostic scripts, log dumps, or any content whose value is in the conclusion rather than the raw output \u2014 summarize these or use \`[[REF:mNNNNN|desc]]\` instead.
+
+PRIORITY \u2014 when the summary must be compact, preserve in this order:
+1. User's overall goal, goal evolution, intent, and hard constraints (losing these changes the task).
+2. Decisions and rationale.
+3. Exact technical artifacts: paths, signatures, errors, values.
+4. Conclusions and key findings.
+5. Lessons learned: what failed and why.
+
+Write dense, scannable bullets \u2014 not narrative prose. If the range spans distinct concerns (request \u2192 findings \u2192 decision), group bullets under short thematic headers so a reader can scan to the part they need. Every line must earn its place. Do not mimic the style of existing summaries in context; follow these rules.`;
+var TIER2_DISTILL_RULES = `TIER 2 COMPRESSION \u2014 DISTILLATION
+
+You are compressing historical summaries (not raw conversation). These summaries have already captured the details. Your job is to DISTILL them: write a holistic summary of what matters for future work, discarding the process.
+
+KEEP \u2014 these are the only things that survive distillation:
+- Decisions and their rationale ("chose X over Y because Z" \u2014 the "because" is load-bearing).
+- Final outcomes: version numbers shipped, PR numbers merged/closed, bugs fixed or deferred.
+- Key lessons: what failed and why ("tried X, failed because Y"). These prevent repeating mistakes.
+- Critical constraints discovered ("must support Node 22", "AGENTS.md forbids as any").
+- Design decisions with architectural impact ("chose compress-as-anchor over synthetic messages because prefix cache").
+- Whether content is OBSOLETE or SUPERSEDED \u2014 mark with one line: "[SUPERSEDED by PR #NNN]" or "[OBSOLETE: deleted in vX.Y.Z]".
+- Function/class/type names and module paths that are the SUBJECT of the work \u2014 e.g., "fixed filterCompressedRanges in prune.ts". Not exact line numbers or full signatures \u2014 just enough to LOCATE the code.
+- Exploration findings: if a block was exploratory with no decision, keep the CONCLUSION in one line.
+
+DROP \u2014 these were useful during the work but are no longer needed:
+- Exact line numbers, diffs, verbose function signatures, full code listings.
+- Build/deploy process details, test execution steps.
+- Review process details (who reviewed, what rounds, test counts).
+- Verbose logs, command output, intermediate debugging steps.
+
+FORMAT:
+- Write a HOLISTIC summary grouped by THEME, not by source block.
+- NO per-block headers. NO "Source: bN" lines. This is a review of what happened, not a catalog of blocks.
+- Group related work together: all releases in one section, all bug fixes in another, all architecture decisions in a third.
+- Start with the most important outcomes (shipped releases, merged PRs, critical bugs).
+- Dense, scannable bullets \u2014 no narrative prose.
+- Most blocks will collapse into 1-2 bullets within a theme group. Many will have nothing worth keeping \u2014 omit them entirely.`;
+var TIER3_CONDENSE_RULES = `TIER 3 COMPRESSION \u2014 ULTRA-CONDENSATION
+
+You are compressing distilled summaries (Tier 2) into ultra-condensed facts (Tier 3). The distilled summaries already contain only decisions and outcomes. Your job is to reduce them to bare factual references.
+
+PRIORITY \u2014 keep in this order:
+1. Shipped outcomes (versions released, PRs merged) \u2014 these are permanent record.
+2. Open work (PRs/issues still pending) \u2014 these may need follow-up.
+3. Key decisions with architectural impact ("chose X over Y because Z").
+4. Critical constraints ("must support Node 22").
+Drop everything else. Tier 3 is a lookup index, not a knowledge base.
+
+FORMAT:
+- Write a HOLISTIC list of bare facts, grouped by theme \u2014 not by source block.
+- NO per-block headers. NO "Source: bN" lines.
+- Each fact is a single line: "[PR/Issue/Version] \u2014 [outcome in \u22648 words]"
+- Merge related facts aggressively. If multiple blocks concern the same release/feature/bug, output ONE line covering all of them.
+- No explanations, no rationale, no process \u2014 just the fact.
+
+EXAMPLES:
+- "v1.13.0 shipped \u2014 quality gate + GC fix (7 PRs)"
+- "PR #196 merged \u2014 preserve-first-user (supersedes #169)"
+- "Bug 1214 fixed \u2014 compress consumed all user messages"
+- "Chose compress-as-anchor \u2014 prefix cache benefit over synthetic injection"
+- "Constraint: AGENTS.md forbids as any \u2014 never suppress types"
+
+DROP:
+- Multi-sentence context. If a fact needs >1 sentence, it's too detailed for Tier 3.
+- Lessons learned ("tried X, failed because Y") \u2014 drop UNLESS the failure is likely to recur and the block is <30 days old.
+- Design rationale details \u2014 keep the decision, drop the "because" unless it's a critical constraint.
+- Anything marked [OBSOLETE] or [SUPERSEDED] \u2014 drop entirely, note "[N blocks obsolete]" at the end.`;
+
 // lib/messages/inject/candidates.ts
 function partToolNames(message) {
   const names = /* @__PURE__ */ new Set();
@@ -10553,7 +10544,7 @@ import { writeFile as writeFile2, mkdir as mkdir2 } from "fs/promises";
 import { join as join4 } from "path";
 import { existsSync as existsSync4 } from "fs";
 import { homedir as homedir3 } from "os";
-var LOG_VERSION = true ? "1.18.0-pr.394.154" : "dev";
+var LOG_VERSION = true ? "1.18.0-pr.397.156" : "dev";
 var LEVEL_RANK = {
   debug: 10,
   info: 20,
@@ -13236,7 +13227,7 @@ var server = (async (ctx) => {
   }
   const logger = new Logger(config.debug, config.debug ? "debug" : config.logLevel);
   logger.info("ACP plugin initialized", {
-    version: true ? "1.18.0-pr.394.154" : "dev",
+    version: true ? "1.18.0-pr.397.156" : "dev",
     workspace: ctx.directory,
     logLevel: logger.level,
     debug: config.debug,