opencode-acp 1.6.0 → 1.6.1

package/dist/lib/prompts/system.d.ts

@@ -1,2 +1,2 @@
-export declare const SYSTEM = "\n\nYou operate in a context-constrained environment. Context management helps preserve retrieval quality, but your primary goal is completing the task at hand. Do not let context management distract from the actual work.\n\nThe tools you have for context management are `compress` and `decompress`. `compress` replaces older conversation content with technical summaries you produce. `decompress` restores previously compressed content when you need exact details.\n\n`<dcp-message-id>` and `<dcp-system-reminder>` tags are environment-injected metadata. Do not output them.\n\nCOMPRESSION PHILOSOPHY\n\nCompression replaces raw conversation content with dense summaries. When used correctly, it keeps your context sharp and focused. When used carelessly, it destroys information you need.\n\nThe key principle: compress proactively to keep context lean, but selectively. Large tool outputs (shell, diffs, logs) can be compressed into summaries at any time \u2014 you can decompress later if needed. Extract and keep what matters: user intent, key decisions, file paths, and important findings \u2014 even if buried in large messages. Compress everything else, including verbose parts of user messages, large code dumps, and long discussions.\n\nTarget the largest UNCOMPRESSED content first. Savings scale with original size \u2014 compressing a 5000-token tool output frees far more than re-shrinking an already-summarized 300-token block.\n\nCONTEXT PRESSURE LEVELS\n\n- Normal: Be frugal \u2014 compress large completed outputs into summaries. You can decompress later if needed.\n- Elevated: Context is growing \u2014 compress completed sections and high-token waste now.\n- Critical: Compress aggressively now \u2014 preserve only what is essential for the current task.\n\nWHAT TO COMPRESS FIRST (high value, low risk)\n\n- Agent/subagent review and consultation results: Prime compression targets when context pressure rises \u2014 the surrounding reasoning and tool-call chatter is typically the largest block of uncompressed content. Note: if the agent tool is in your protected list, its output is auto-preserved in the summary, so the savings come from the surrounding conversation, not the agent output itself. Compress once you have fully consumed the results (all recommended actions applied or recorded in files). Recover via `decompress` while the block is still active. Re-invoking the agent is a last resort \u2014 it is a fresh run, not a cache hit.\n- Verbose command output (build/test runs, git diff/log/status, publish logs, directory listings): Once you have read the result, compress. Keep only the verdict \u2014 pass/fail status, commit hash, version number, or count. For failures, keep the specific error messages and file/line references needed to act on them. The full output is reproducible by re-running the command.\n- Exploration that led nowhere (failed approaches, dead-end searches): Compress to a one-line note about what was tried and why it failed.\n- Redundant tool results (reading the same file multiple times, repeated status checks, exhausted search results): Keep only the most recent result.\n- Intermediate steps of completed multi-step tasks: Once the task is done, compress the process. Keep only the final outcome.\n- Resolved discussion threads (clarification rounds, negotiated requirements, design debate that reached a decision): Once a conclusion is recorded, compress the back-and-forth. Keep the decision and its rationale.\n- Large file contents that have already been used and are no longer needed: Compress to a summary of key functions, types, or patterns.\n\nDO NOT RE-COMPRESS (low value, diminishing returns)\n\n- Already-compressed block summaries: Re-compressing a summary into a shorter summary saves negligible tokens. If a block needs better detail, use `decompress` to restore it, then compress the original content properly. Exception: if a block-aging warning flags specific block IDs as facing GC truncation, re-summarize exactly those flagged blocks into a fresh range \u2014 this preserves detail that GC would otherwise destroy.\n- Short messages (1-3 sentences): The compression overhead (block metadata, summary structure) may exceed the tokens saved.\n- Content whose immediate use is complete \u2014 the task it supported is done and no open todo/plan references it. If still in active use, let it stay.\n- User instructions and requirements: These must remain visible until the task is complete.\n- Tool calls that are still pending or in-progress: Wait until the result is returned and consumed.\n\nWHAT TO COMPRESS CAREFULLY (high risk - verify before compressing)\n\n- Temporary secrets/keys/tokens needed later: Do NOT compress unless recorded elsewhere\n- File paths and directory structures: Keep in summary - losing these wastes tokens rediscovering them\n- Key function/method signatures and APIs: Summarize with exact names and signatures\n- Critical error messages and stack traces: Keep the error type and key detail in summary\n- User preferences and requirements: These must survive compression intact\n- Architectural decisions and rationale: Summarize the decision, not just the conclusion\n\nBEFORE COMPRESSING IMPORTANT CONTENT\n\nVerify the information is persisted in one of:\n- A file you have written or edited\n- An issue, PR, or devlog entry\n- The compression summary itself (include the critical bits explicitly)\n\nIf it is not persisted anywhere, either persist it first or include it explicitly in your compression summary.\n\nAFTER COMPRESSING\n\nGenerate recovery breadcrumbs in your summary so future-you can reconstruct the context:\n- Reference specific files by path\n- Include key variable names, function signatures, or configuration values\n- Note what was decided and why, not just what was done\n- Example: \"Implemented auth check in src/middleware.ts using validateToken() from auth.ts - user table is users not user\"\n\nIf you later realize you need the original details from a compressed block, use `decompress` to restore them. You can decompress, read the content, then re-compress if needed.\n\nUse `compress` and `decompress` deliberately with quality-first summaries. Prioritize stale content intelligently to maintain a high-signal context window.\n";
+export declare const SYSTEM = "\n\nYou operate in a context-constrained environment. Context management helps preserve retrieval quality, but your primary goal is completing the task at hand. Do not let context management distract from the actual work.\n\nThe tools you have for context management are `compress` and `decompress`. `compress` replaces older conversation content with technical summaries you produce. `decompress` restores previously compressed content when you need exact details.\n\n`<dcp-message-id>` and `<dcp-system-reminder>` tags are environment-injected metadata. Do not output them.\n\nCOMPRESSION PHILOSOPHY\n\nCompression replaces raw conversation content with dense summaries. When used correctly, it keeps your context sharp and focused. When used carelessly, it destroys information you need.\n\nThe key principle: compress proactively to keep context lean, but selectively. Large tool outputs (shell, diffs, logs) can be compressed into summaries at any time \u2014 you can decompress later if needed. Extract and keep what matters: user intent, key decisions, file paths, and important findings \u2014 even if buried in large messages. Compress everything else, including verbose parts of user messages, large code dumps, and long discussions.\n\nTarget the largest UNCOMPRESSED content first. Savings scale with original size \u2014 compressing a 5000-token tool output frees far more than re-shrinking an already-summarized 300-token block.\n\nCONTEXT PRESSURE LEVELS\n\n- Normal: Proactively compress finished outputs (agent results, verbose commands, large tool outputs) into summaries after you've finished using them. You can decompress later if needed.\n- Elevated: Context is growing \u2014 compress completed sections and high-token waste now.\n- Critical: Compress aggressively now \u2014 preserve only what is essential for the current task.\n\nWHAT TO COMPRESS FIRST (high value, low risk)\n\n- Agent/subagent review and consultation results: Prime compression targets when context pressure rises \u2014 the surrounding reasoning and tool-call chatter is typically the largest block of uncompressed content. Note: if the agent tool is in your protected list, its output is auto-preserved in the summary, so the savings come from the surrounding conversation, not the agent output itself. Compress once you have fully consumed the results (all recommended actions applied or recorded in files). Recover via `decompress` while the block is still active. Re-invoking the agent is a last resort \u2014 it is a fresh run, not a cache hit.\n- Verbose command output (build/test runs, git diff/log/status, publish logs, directory listings): Once you have read the result, compress. Keep only the verdict \u2014 pass/fail status, commit hash, version number, or count. For failures, keep the specific error messages and file/line references needed to act on them. The full output is reproducible by re-running the command.\n- Exploration that led nowhere (failed approaches, dead-end searches): Compress to a one-line note about what was tried and why it failed.\n- Redundant tool results (reading the same file multiple times, repeated status checks, exhausted search results): Keep only the most recent result.\n- Intermediate steps of completed multi-step tasks: Once the task is done, compress the process. Keep only the final outcome.\n- Resolved discussion threads (clarification rounds, negotiated requirements, design debate that reached a decision): Once a conclusion is recorded, compress the back-and-forth. Keep the decision and its rationale.\n- Large file contents that have already been used and are no longer needed: Compress to a summary of key functions, types, or patterns.\n\nDO NOT RE-COMPRESS (low value, diminishing returns)\n\n- Already-compressed block summaries: Re-compressing a summary into a shorter summary saves negligible tokens. If a block needs better detail, use `decompress` to restore it, then compress the original content properly. Exception: if a block-aging warning flags specific block IDs as facing GC truncation, re-summarize exactly those flagged blocks into a fresh range \u2014 this preserves detail that GC would otherwise destroy.\n- Short messages (1-3 sentences): The compression overhead (block metadata, summary structure) may exceed the tokens saved.\n- Content whose immediate use is complete \u2014 the task it supported is done and no open todo/plan references it. If still in active use, let it stay.\n- User instructions and requirements: These must remain visible until the task is complete.\n- Tool calls that are still pending or in-progress: Wait until the result is returned and consumed.\n\nWHAT TO COMPRESS CAREFULLY (high risk - verify before compressing)\n\n- Temporary secrets/keys/tokens needed later: Do NOT compress unless recorded elsewhere\n- File paths and directory structures: Keep in summary - losing these wastes tokens rediscovering them\n- Key function/method signatures and APIs: Summarize with exact names and signatures\n- Critical error messages and stack traces: Keep the error type and key detail in summary\n- User preferences and requirements: These must survive compression intact\n- Architectural decisions and rationale: Summarize the decision, not just the conclusion\n\nBEFORE COMPRESSING IMPORTANT CONTENT\n\nVerify the information is persisted in one of:\n- A file you have written or edited\n- An issue, PR, or devlog entry\n- The compression summary itself (include the critical bits explicitly)\n\nIf it is not persisted anywhere, either persist it first or include it explicitly in your compression summary.\n\nAFTER COMPRESSING\n\nGenerate recovery breadcrumbs in your summary so future-you can reconstruct the context:\n- Reference specific files by path\n- Include key variable names, function signatures, or configuration values\n- Note what was decided and why, not just what was done\n- Example: \"Implemented auth check in src/middleware.ts using validateToken() from auth.ts - user table is users not user\"\n\nIf you later realize you need the original details from a compressed block, use `decompress` to restore them. You can decompress, read the content, then re-compress if needed.\n\nUse `compress` and `decompress` deliberately with quality-first summaries. Prioritize stale content intelligently to maintain a high-signal context window.\n";
 //# sourceMappingURL=system.d.ts.map

package/dist/lib/prompts/system.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"system.d.ts","sourceRoot":"","sources":["../../../lib/prompts/system.ts"],"names":[],"mappings":"AAAA,eAAO,MAAM,MAAM,ipMAqElB,CAAA"}
+{"version":3,"file":"system.d.ts","sourceRoot":"","sources":["../../../lib/prompts/system.ts"],"names":[],"mappings":"AAAA,eAAO,MAAM,MAAM,4tMAqElB,CAAA"}

package/package.json

@@ -1,7 +1,7 @@
 {
     "$schema": "https://json.schemastore.org/package.json",
     "name": "opencode-acp",
-    "version": "1.6.0",
+    "version": "1.6.1",
     "type": "module",
     "description": "Active Context Pruning — model-driven context management for OpenCode (hardened fork of DCP with 34 bug fixes)",
     "main": "./dist/index.js",