@cerebriline/core 4.100.254 → 4.100.256

package/dist/extensions/config/prompt-template-review.d.ts

@@ -1,7 +1,7 @@
 import { type PromptTemplate } from "@cerebriline/shared";
 import { type CompactionPromptSources } from "./prompt-template-compaction";
 export declare const DEFAULT_REQUIRED_REWRITES: readonly ["read_files", "search_codebase", "editor", "apply_patch", "run_commands", "fetch_web_content", "check_file", "ask_lsp", "grep", "sed", "awk"];
-export declare const PROMPT_TEMPLATE_REVIEW_INSTRUCTIONS = "You are being shown the prompt Cline gives you when it uses you as a coding agent: a system prompt and a set of tool descriptions. You are the intended reader of this text. Rewrite it into the form you would rather receive.\n\nThis is not a copy-editing task. The prompt below was written by someone reasoning about how you read, and they may have been wrong. Where a section is phrased in a way you would skim, reorder or restate it. Where a rule matters and is buried, put it where you would be when you are about to break it. Where something is repeated to no effect, cut it.\n\nFour failures are observed in practice with models in your family, and the rewrite is judged on whether it prevents them:\n\n1. Reaching for shell commands to do file work \u2014 'cat' to read, 'sed -i' or 'echo >' to write, 'grep' to search \u2014 when dedicated tools exist and are always available.\n2. Serialising independent work across turns: one read, wait, one read, wait, when all of them were known at the start.\n3. Announcing an intention instead of acting on it, or claiming a task is finished without reading back what was written.\n4. Answering a question about a symbol with a text search. Asking where something is defined, what uses it, what implements it, or what a name means, and then grepping for it and reading several files to work out which hit was the real one \u2014 when the IDE's language servers already know the answer exactly and will give it in one call. The same failure in its other form: running a compiler or a linter through the shell to find out whether one file is valid, and waiting for a whole-project build to answer a one-file question.\n\nOne thing you must get right, and which prompts written for this get wrong in both directions:\n\nA coding agent is multi-turn, and the end of a turn is never in itself the end of the work. What is final is the completion of the assigned work \u2014 the task, the work package, the milestone, the request. An end of turn may be a milestone reached, a point where you need direction, guidance or a clarification from the user, or simply an intermediate step between two things the user asked for. So:\n\n- Do not treat \"I have stopped emitting tool calls\" as \"the work is done\". It is not a signal about the work at all.\n- Do not write a rule that makes stopping feel like failure, such as \"a response without a tool call is considered complete\". A rule like that buys one more unnecessary tool call on every finished task, and it teaches the wrong thing: that continuing is always correct.\n- Keep your attention on the long horizon of the assigned work rather than on the current turn. Ending a turn to ask a question is correct when you need the answer. Ending it while work you were asked to do remains untouched, and saying nothing about that, is not.\n\nFour more things are settled by measurement rather than by opinion, and a rewrite is judged on whether it keeps them:\n\n- The checker and the run belong in the same turn. Call 'check_file' and the thing that executes the code - 'run_commands', or 'browser' for a page - together, not one or the other. Running it says *that* something is broken and where the parser gave up; the checker says *which line* to edit. Each is half the answer, and the half you skip is the half the turn gets spent guessing at.\n- A tool's report outranks your own reasoning about the same question. Where a tool has measured something - a delimiter scan naming the line to edit, a diagnostic naming a type - that is the measurement, and re-deriving it yourself is an estimate. Where the two disagree, it is the estimate that is wrong. Measured twice: a model called a delimiter scan a false positive, counted brackets by hand instead, and was wrong both times, at over 30,000 thinking tokens a turn. If you doubt a report, do not re-derive it - act on it and run the result. That costs milliseconds and settles it either way.\n- Make the planned changes one at a time, and confirm each one before starting the next. The cheap check that does not execute the code goes after every edit; the thing that runs the code is what settles whether the change was right. Six edits made together and checked once leave six things to undo and no way to tell which one was wrong - measured across ten runs, the template that said otherwise drew 13.6 'restore_file' calls per run against 0.23 for the family that did not.\n- Do not re-read a file to confirm your own edit. The edit call already reports whether it landed and what changed, and that is the confirmation. Measured on one session: 'read_files' was called 33 times, 31 of them byte-identical, returning 440,013 characters against a file of 14 KB - four times the tokens that session spent on all of its reasoning. Read again when the call failed, or when you need content you have not seen. A rule that says to read a file back after every edit is the one thing here you must not write.\n\nHard constraints:\n\n- Keep every placeholder exactly as written, including the braces: {{PLATFORM_NAME}}, {{CURRENT_DATE}}, {{IDE_NAME}}, {{CWD}}, {{CLINE_RULES}}, {{CLINE_METADATA}}, {{DEFAULT}}. They are substituted at runtime; a renamed or dropped placeholder breaks the prompt.\n- Keep the tool names exactly as written. They are the wire names of real tools.\n- Do not invent tools, parameters, or capabilities. Describe only what is described below.\n- Keep the file structure: YAML frontmatter between --- markers, then '# system', then one '# tool: <name>' section for EVERY tool listed below. Not only the ones you want to change \u2014 every one of them.\n- Covering every tool is a hard requirement. A tool with no section keeps its built-in description, and that fallback exists for exactly one situation: Cline gains a new tool and the templates have not been regenerated yet. It is not a way to skip tools you have nothing to say about. A template that covers six of thirty-one tools is not using the fallback, it is relying on it, and nothing in the file shows which twenty-five were left out.\n- '{{DEFAULT}}' expands to the tool's built-in description at runtime, and it is how you cover a tool cheaply. Where you would improve on the built-in wording, write your own and put '{{DEFAULT}}' on its own line where the built-in text should follow. Where you would not, the entire section body may be just '{{DEFAULT}}'. Either is a covered tool; an absent section is not.\n- These eight tools must be written in your own words, and a section containing only '{{DEFAULT}}' is not acceptable for any of them: read_files, search_codebase, editor, apply_patch, run_commands, fetch_web_content, check_file, ask_lsp. They are the tools models in your family are observed to misuse, so they are the whole reason this template exists. For these eight, your own text \u2014 not the inherited text \u2014 has to carry the three things listed below: every value of any closed set, every argument and when to use it, and what comes back. Adding '{{DEFAULT}}' after your text is allowed and does not excuse you from any of that.\n- For 'ask_lsp', say when to reach for it, not only what it does. List at least three concrete situations as the reader actually meets them \u2014 \"about to search for a name to find where it is defined\", \"about to open a file just to read a signature\", \"about to scroll or count brackets to work out a file's structure\" \u2014 each pointing at the operation that answers it, and name 'search_codebase' as the thing those situations would otherwise go to. This is not padding: measured across a whole session against a real bug, a template that described all eight operations correctly and said only \"prefer this over search_codebase for anything about a symbol\" produced zero calls to the tool, while the model hand-rolled the same answers in the shell twenty times. It could not recognise the moment.\n- Do not copy a built-in description out word for word. That is a snapshot: it says the same thing today and stops tracking the built-in text tomorrow, so the next edit to it reaches every model except you. If you would not change the wording, write '{{DEFAULT}}' \u2014 that is what it is for.\n- Where you rule a use of a tool out, name the tool that replaces it. 'run_commands' in particular must name 'read_files', 'editor' and 'search_codebase' in your own text: \"do not use this for file operations when dedicated tools exist\" is a rule the reader has to already know the answer to in order to follow, which is the same as not writing it.\n- Two of those eight \u2014 'run_commands' and 'skills' \u2014 must keep '{{DEFAULT}}' in the section as well. Their built-in descriptions are not fixed text: 'run_commands' is composed against the shell that will actually run the commands, so PowerShell, cmd and a POSIX shell get different quoting and sequencing advice, and 'skills' appends the skills installed on that machine. Replace either outright and you freeze one machine's answer into every machine's prompt, silently. Write your own text and put '{{DEFAULT}}' on its own line where the built-in text should follow.\n- For the other tools, a section whose body is exactly '{{DEFAULT}}' is a complete and correct answer. Do not pad them. Nothing about how you read changes what 'team_finalize_outcome' should say.\n- Emit every section exactly once. Do not repeat '# system', and do not write two '# tool: <name>' headings for the same tool. Only the last copy of a repeated section survives, so a duplicate silently throws away your own work.\n- Leave the 'match:' block in the frontmatter exactly as it is. It is what routes this template to you; change it and your rewrite reaches a different model, or none.\n\nReplace a description and you inherit everything it was carrying:\n\nIf a '# tool:' section contains '{{DEFAULT}}' anywhere, the built-in description is still delivered and you are only adding emphasis on top of it. Nothing further is asked of you for that tool \u2014 unless it is one of the eight above, which are judged on your words alone.\n\nIf it does not, your text is the only thing a model will ever see about that tool, so it must not lose what the built-in description said. Specifically, and only where the built-in text below says it:\n\n1. Closed sets. Where the built-in description lists the values an argument accepts \u2014 the operations of a language-server tool, the actions of a task tool, the statuses of a run \u2014 your replacement must list all of them too. Naming four of eight hides half the tool and a model cannot guess the rest.\n2. How to address the tool. Where the built-in description names the arguments, and says which one to use when, your replacement must say the same. A tool that can be addressed three ways needs all three, and what each is for.\n3. What comes back. Where the built-in description states an output, your replacement must state one: the shape, what the fields hold, and what an empty or failed result means. A model that cannot map a result back onto its request spends a turn working it out, and then stops trusting the tool.\n\nNothing is required of you that the built-in text did not already provide. Reproducing what is there is always enough; improving on it is better; dropping it is the one thing that is not allowed.\n\nDo not write 'Output:' followed by nothing, or by a single word. An empty label reads as an empty result, which is worse than saying nothing at all.\n\nFor any tool outside the eight, if restating all of that is not worth it to you, do not replace its description. Write your emphasis and leave '{{DEFAULT}}' in the section, or write nothing but the marker. That is cheaper and it is always correct.\n\nReply with the complete template file and nothing else: no preamble, no explanation, no code fence.";
+export declare const PROMPT_TEMPLATE_REVIEW_INSTRUCTIONS = "You are being shown the prompt Cline gives you when it uses you as a coding agent: a system prompt and a set of tool descriptions. You are the intended reader of this text. Rewrite it into the form you would rather receive.\n\nThis is not a copy-editing task. The prompt below was written by someone reasoning about how you read, and they may have been wrong. Where a section is phrased in a way you would skim, reorder or restate it. Where a rule matters and is buried, put it where you would be when you are about to break it. Where something is repeated to no effect, cut it.\n\nFour failures are observed in practice with models in your family, and the rewrite is judged on whether it prevents them:\n\n1. Reaching for shell commands to do file work \u2014 'cat' to read, 'sed -i' or 'echo >' to write, 'grep' to search \u2014 when dedicated tools exist and are always available.\n2. Serialising independent work across turns: one read, wait, one read, wait, when all of them were known at the start.\n3. Announcing an intention instead of acting on it, or claiming a task is finished without reading back what was written.\n4. Answering a question about a symbol with a text search. Asking where something is defined, what uses it, what implements it, or what a name means, and then grepping for it and reading several files to work out which hit was the real one \u2014 when the IDE's language servers already know the answer exactly and will give it in one call. The same failure in its other form: running a compiler or a linter through the shell to find out whether one file is valid, and waiting for a whole-project build to answer a one-file question.\n\nOne thing you must get right, and which prompts written for this get wrong in both directions:\n\nA coding agent is multi-turn, and the end of a turn is never in itself the end of the work. What is final is the completion of the assigned work \u2014 the task, the work package, the milestone, the request. An end of turn may be a milestone reached, a point where you need direction, guidance or a clarification from the user, or simply an intermediate step between two things the user asked for. So:\n\n- Do not treat \"I have stopped emitting tool calls\" as \"the work is done\". It is not a signal about the work at all.\n- Do not write a rule that makes stopping feel like failure, such as \"a response without a tool call is considered complete\". A rule like that buys one more unnecessary tool call on every finished task, and it teaches the wrong thing: that continuing is always correct.\n- Keep your attention on the long horizon of the assigned work rather than on the current turn. Ending a turn to ask a question is correct when you need the answer. Ending it while work you were asked to do remains untouched, and saying nothing about that, is not.\n\nFour more things are settled by measurement rather than by opinion, and a rewrite is judged on whether it keeps them:\n\n- The checker and the run belong in the same turn. Call 'check_file' and the thing that executes the code - 'run_commands', or 'browser' for a page - together, not one or the other. Running it says *that* something is broken and where the parser gave up; the checker says *which line* to edit. Each is half the answer, and the half you skip is the half the turn gets spent guessing at.\n- A tool's report outranks your own reasoning about the same question. Where a tool has measured something - a delimiter scan naming the line to edit, a diagnostic naming a type - that is the measurement, and re-deriving it yourself is an estimate. Where the two disagree, it is the estimate that is wrong. Measured twice: a model called a delimiter scan a false positive, counted brackets by hand instead, and was wrong both times, at over 30,000 thinking tokens a turn. If you doubt a report, do not re-derive it - act on it and run the result. That costs milliseconds and settles it either way.\n- Make the planned changes one at a time, and confirm each one before starting the next. The cheap check that does not execute the code goes after every edit; the thing that runs the code is what settles whether the change was right. Six edits made together and checked once leave six things to undo and no way to tell which one was wrong - measured across ten runs, the template that said otherwise drew 13.6 'restore_file' calls per run against 0.23 for the family that did not.\n- Do not re-read a file to confirm your own edit. The edit call already reports whether it landed and what changed, and that is the confirmation. Measured on one session: 'read_files' was called 33 times, 31 of them byte-identical, returning 440,013 characters against a file of 14 KB - four times the tokens that session spent on all of its reasoning. Read again when the call failed, or when you need content you have not seen. A rule that says to read a file back after every edit is the one thing here you must not write.\n\nHard constraints:\n\n- Keep every placeholder exactly as written, including the braces: {{PLATFORM_NAME}}, {{CURRENT_DATE}}, {{IDE_NAME}}, {{CWD}}, {{CLINE_RULES}}, {{CLINE_METADATA}}, {{DEFAULT}}. They are substituted at runtime; a renamed or dropped placeholder breaks the prompt.\n- Keep the tool names exactly as written. They are the wire names of real tools.\n- Do not invent tools, parameters, or capabilities. Describe only what is described below.\n- Keep the file structure: YAML frontmatter between --- markers, then '# system', then one '# tool: <name>' section for EVERY tool listed below. Not only the ones you want to change \u2014 every one of them.\n- Covering every tool is a hard requirement. A tool with no section keeps its built-in description, and that fallback exists for exactly one situation: Cline gains a new tool and the templates have not been regenerated yet. It is not a way to skip tools you have nothing to say about. A template that covers six of thirty-one tools is not using the fallback, it is relying on it, and nothing in the file shows which twenty-five were left out.\n- '{{DEFAULT}}' expands to the tool's built-in description at runtime, and it is how you cover a tool cheaply. Where you would improve on the built-in wording, write your own and put '{{DEFAULT}}' on its own line where the built-in text should follow. Where you would not, the entire section body may be just '{{DEFAULT}}'. Either is a covered tool; an absent section is not.\n- Text you write beside '{{DEFAULT}}' is sent in addition to the built-in description, not instead of it, on every request. So write only what you add: the rule a model in your family breaks, the case it misreads, the one example that settles it. Do not restate or paraphrase what the built-in text already says; it follows anyway, and a restatement means the reader takes in the same thing twice. If you want to say everything in your own words, drop '{{DEFAULT}}' and write the whole description instead.\n- These eight tools must be written in your own words, and a section containing only '{{DEFAULT}}' is not acceptable for any of them: read_files, search_codebase, editor, apply_patch, run_commands, fetch_web_content, check_file, ask_lsp. They are the tools models in your family are observed to misuse, so they are the whole reason this template exists. For these eight, your own text \u2014 not the inherited text \u2014 has to carry the three things listed below: every value of any closed set, every argument and when to use it, and what comes back. Adding '{{DEFAULT}}' after your text is allowed and does not excuse you from any of that.\n- For 'ask_lsp', say when to reach for it, not only what it does. List at least three concrete situations as the reader actually meets them \u2014 \"about to search for a name to find where it is defined\", \"about to open a file just to read a signature\", \"about to scroll or count brackets to work out a file's structure\" \u2014 each pointing at the operation that answers it, and name 'search_codebase' as the thing those situations would otherwise go to. This is not padding: measured across a whole session against a real bug, a template that described all eight operations correctly and said only \"prefer this over search_codebase for anything about a symbol\" produced zero calls to the tool, while the model hand-rolled the same answers in the shell twenty times. It could not recognise the moment.\n- Do not copy a built-in description out word for word. That is a snapshot: it says the same thing today and stops tracking the built-in text tomorrow, so the next edit to it reaches every model except you. If you would not change the wording, write '{{DEFAULT}}' \u2014 that is what it is for.\n- Where you rule a use of a tool out, name the tool that replaces it. 'run_commands' in particular must name 'read_files', 'editor' and 'search_codebase' in your own text: \"do not use this for file operations when dedicated tools exist\" is a rule the reader has to already know the answer to in order to follow, which is the same as not writing it.\n- Two of those eight \u2014 'run_commands' and 'skills' \u2014 must keep '{{DEFAULT}}' in the section as well. Their built-in descriptions are not fixed text: 'run_commands' is composed against the shell that will actually run the commands, so PowerShell, cmd and a POSIX shell get different quoting and sequencing advice, and 'skills' appends the skills installed on that machine. Replace either outright and you freeze one machine's answer into every machine's prompt, silently. Write your own text and put '{{DEFAULT}}' on its own line where the built-in text should follow.\n- For the other tools, a section whose body is exactly '{{DEFAULT}}' is a complete and correct answer. Do not pad them. Nothing about how you read changes what 'team_finalize_outcome' should say.\n- Emit every section exactly once. Do not repeat '# system', and do not write two '# tool: <name>' headings for the same tool. Only the last copy of a repeated section survives, so a duplicate silently throws away your own work.\n- Leave the 'match:' block in the frontmatter exactly as it is. It is what routes this template to you; change it and your rewrite reaches a different model, or none.\n\nReplace a description and you inherit everything it was carrying:\n\nIf a '# tool:' section contains '{{DEFAULT}}' anywhere, the built-in description is still delivered and you are only adding emphasis on top of it. Nothing further is asked of you for that tool \u2014 unless it is one of the eight above, which are judged on your words alone.\n\nIf it does not, your text is the only thing a model will ever see about that tool, so it must not lose what the built-in description said. Specifically, and only where the built-in text below says it:\n\n1. Closed sets. Where the built-in description lists the values an argument accepts \u2014 the operations of a language-server tool, the actions of a task tool, the statuses of a run \u2014 your replacement must list all of them too. Naming four of eight hides half the tool and a model cannot guess the rest.\n2. How to address the tool. Where the built-in description names the arguments, and says which one to use when, your replacement must say the same. A tool that can be addressed three ways needs all three, and what each is for.\n3. What comes back. Where the built-in description states an output, your replacement must state one: what each entry is named by, what it holds, and what an empty or failed result means. A model that cannot map a result back onto its request spends a turn working it out, and then stops trusting the tool. Say it in words, as the built-in text does: do not name fields such as 'query', 'result' or 'success', and do not write the result as an object like '{query, result, success, error?}'. A session receives tool results as text or as JSON, chosen when it starts, so a description of one format is false in the other.\n\nNothing is required of you that the built-in text did not already provide. Reproducing what is there is always enough; improving on it is better; dropping it is the one thing that is not allowed.\n\nDo not write 'Output:' followed by nothing, or by a single word. An empty label reads as an empty result, which is worse than saying nothing at all.\n\nFor any tool outside the eight, if restating all of that is not worth it to you, do not replace its description. Write your emphasis and leave '{{DEFAULT}}' in the section, or write nothing but the marker. That is cheaper and it is always correct.\n\nReply with the complete template file and nothing else: no preamble, no explanation, no code fence.";
 export declare function buildPromptTemplateReviewPrompt(defaultTemplate: string, familyTemplate: string | undefined, familyTemplateName: string | undefined, 
 /** What this model is, so a new template can be told how to claim itself. */
 target?: {
@@ -202,6 +202,39 @@ export interface AuditPromptTemplateProposalArgs {
  * audit cannot drift apart.
  */
 export declare function findBatchedEditRules(system: string): string[];
+/**
+ * Lines that describe a tool's result by its JSON fields.
+ *
+ * Results reach the model as text or as JSON, chosen per session, and the
+ * text form has no `query`, `result` or `success` in it: an entry is its query
+ * on one line, then `→ ` and what came back, or `→ failed: ` and why. A
+ * description that says "`success: false` means the file was not touched" is
+ * false for every text session. Every shipped template said it, because the
+ * built-in descriptions did and the review instructions asked for "the shape,
+ * what the fields hold". Exported for the same reason as
+ * `findBatchedEditRules`: the shipped-template test and the proposal audit
+ * must use one detector.
+ */
+export declare function findResultFieldClaims(text: string): string[];
+/** Whether `own`, sent beside the marker, is longer than an addition should be. */
+export declare function exceedsAdditionCap(own: string, builtin: string): boolean;
+/**
+ * The built-in sentences, 40 characters or longer, that `own` repeats verbatim
+ * (ignoring whitespace and case). Next to '{{DEFAULT}}' each one is sent twice.
+ */
+export declare function findRestatedBuiltinSentences(own: string, builtin: string): string[];
+/**
+ * Lines in a `run_commands` section that say a non-zero exit is not a failure.
+ *
+ * It is one: the command throws `CommandExitError`, the entry comes back
+ * failed with the exit in its reason, and a text session reads `→ failed:`
+ * above the output. deepseek-v4.1-flash wrote "has not failed as a tool call"
+ * and then "is not a failed tool call" on two separate runs on 2026-10-22,
+ * the second after being told the result format, and nothing flagged either.
+ * The point it means to make -- read the output, the error is in it -- is the
+ * right one, and saying it does not need the denial.
+ */
+export declare function findNonZeroExitDenials(text: string): string[];
 export declare function auditPromptTemplateProposal(args: AuditPromptTemplateProposalArgs): PromptTemplateProposalAudit;
 /**
  * Hand a model its own file back with the list of what is wrong with it.
@@ -312,6 +345,13 @@ export interface GeneratePromptTemplateResult {
     audit: PromptTemplateProposalAudit;
     /** How many model calls it took. */
     attempts: number;
+    /**
+     * Which of those calls produced `raw`. The same as `attempts` for a clean
+     * result; for one that never got clean it is the cleanest attempt, which
+     * is often an early one. The two used to share a field, and a run that
+     * spent four calls was logged as "NOT CLEAN after 1 attempt(s)".
+     */
+    bestAttempt: number;
     /**
      * The compaction sections the file carries, and the ones that were removed
      * because they still failed the check after the last attempt. Present only

package/dist/extensions/context/agentic-compaction.d.ts

@@ -1,4 +1,4 @@
-import type { BasicLogger, MessageWithMetadata } from "@cerebriline/shared";
+import type { BasicLogger, MessageWithMetadata, ToolResultFormat } from "@cerebriline/shared";
 import type { CoreCompactionContext, CoreCompactionResult, CoreCompactionSummarizerConfig } from "../../types/config";
 import type { ProviderConfig } from "../../types/provider-settings";
 import { type BudgetProjectionResult } from "./budget-projection";
@@ -126,4 +126,5 @@ export declare function describeReplaySpan(input: {
     cutIndex: number;
     keepRecentMessages: boolean;
     pinnedMessage?: MessageWithMetadata;
+    toolResultFormat?: ToolResultFormat;
 }): string;

package/dist/extensions/context/capped-thinking.d.ts

@@ -17,9 +17,10 @@
  * managed to make came back as. Short enough to be read, and framed as
  * conclusions rather than as a transcript to resume.
  */
-import type { BasicLogger, DiscardedTurnCondensation, DiscardedTurnInput, MessageWithMetadata } from "@cerebriline/shared";
+import type { BasicLogger, DiscardedTurnCondensation, DiscardedTurnInput, MessageWithMetadata, ToolResultFormat } from "@cerebriline/shared";
 import type { CoreCompactionSummarizerConfig } from "../../types/config";
 import type { ProviderConfig } from "../../types/provider-settings";
+import { type ToolLedgerMessage } from "./tool-ledger";
 /**
  * Whether this reasoning ended because the thinking budget ran out.
  *
@@ -145,12 +146,26 @@ export declare const CAPPED_THINKING_SYSTEM_PROMPT = "You are condensing a train
  * sized to the think and the room (`resolveCondensedThinkingNoteTokens`), so a
  * replacement prompt gets it too.
  */
-export declare const DEFAULT_CAPPED_THINKING_PROMPT = "Your thinking on this turn has reached its budget, and the reasoning below is about to be replaced by what you write now. Write the reasoning that takes its place.\n\nIt goes back into **your own thinking channel**, as the thinking you are in the middle of. Your next pass reads it as its own train of thought and carries on from the end of it, so write it the way you think: in the **first person, present continuous tense**, in plain prose, one thought after another, the same voice as the reasoning it replaces.\n\nWrite every step as the step itself, then what is coming back. These are the shapes \u2014 reuse them:\n\n- \"I'm working out why the collision check misses the left wall.\"\n- \"I'm reading `game.js` around line 274, and the bounds test there compares against `width` where it needs `width - size`.\"\n- \"I'm running `check_file` on it, and it is reporting an unterminated regular expression at line 274.\"\n- \"I'm setting the loop rewrite aside: the fault is in the bounds test, and the loop is sound.\"\n- \"The bounds test is the cause, so what I'm doing next is editing line 274.\"\n\nEvery sentence holds that voice, the middle as much as the first and the last.\n\nCarry all of this:\n\n- **What you are being asked to do**, in a sentence.\n- **Every tool call in this turn**, by name, with the argument that matters and what it is returning: the file and what is at the line you are looking at, the edit and whether it is applying, the command and what it is printing. These results are not in front of your next pass any more, so this is the only place they survive.\n- **What you are treating as settled**, stated as settled.\n- **What you are setting aside, and why**, a clause each. This is what keeps the next pass off ground this one has already covered.\n- **Where you are**, ending on the one question still open and the single next action, stated concretely.\n\nName files and lines and say what you are concluding about them; the files themselves are on disk, and the next tool result is what shows their current state.\n\nBegin with the problem itself and end on the next action.";
+export declare const DEFAULT_CAPPED_THINKING_PROMPT = "Your thinking on this turn has reached its budget, and the reasoning below is about to be replaced by what you write now. Write the reasoning that takes its place.\n\nIt goes back into **your own thinking channel**, as the thinking you are in the middle of. Your next pass reads it as its own train of thought and carries on from the end of it, so write it the way you think: in the **first person, present continuous tense**, in plain prose, one thought after another, the same voice as the reasoning it replaces.\n\nWrite every step as the step itself, then what is coming back. These are the shapes, taken from a task that is not yours \u2014 reuse the shapes, and take every name, line and value from your own reasoning:\n\n- \"I'm working out why the invoice total comes out a cent short.\"\n- \"I'm reading `billing/invoice.py` around line 58, and the rounding there happens on every line item where it needs to happen once, on the sum.\"\n- \"I'm running the tests on it, and `test_invoice_total` is failing with 99.99 against 100.00.\"\n- \"I'm setting the currency conversion aside: the fault is in the rounding, and the conversion is sound.\"\n- \"The rounding is the cause, so what I'm doing next is editing line 58.\"\n\nEvery sentence holds that voice, the middle as much as the first and the last.\n\nCarry all of this:\n\n- **What you are being asked to do**, in a sentence.\n- **Every tool call in this turn**, by name, with the argument that matters and what it is returning: the file and what is at the line you are looking at, the edit and whether it is applying, the command and what it is printing. These results are not in front of your next pass any more, so this is the only place they survive.\n- **What you are treating as settled**, stated as settled.\n- **What you are setting aside, and why**, a clause each. This is what keeps the next pass off ground this one has already covered.\n- **Where you are**, ending on the one question still open and the single next action, stated concretely.\n\nName files and lines and say what you are concluding about them; the files themselves are on disk, and the next tool result is what shows their current state.\n\nBegin with the problem itself and end on the next action.";
 interface ToolOutcome {
     name: string;
     input: string;
     result: string;
 }
+/**
+ * What the task's tools have done so far, as the harness recorded each call:
+ * the compaction ledger, over the calls since the last compaction plus the
+ * ones that compaction carried.
+ *
+ * A note asked for in a request of its own sees the capped reasoning and the
+ * capped turn's own calls, and a capped turn usually has none that ran -- its
+ * call is the part the cap cut. Reasoning rarely names the file it is about,
+ * so the note filled the gap itself: on pandorum (lfw1t, 2026-10-20) a 34,572-
+ * character think that named no file came back as a note about `game.js` in a
+ * task on `manic_miner.html`. The record is the harness's account, not the
+ * model's, so the names and results in it are the ones that happened.
+ */
+export declare function recordedToolCalls(messages: readonly ToolLedgerMessage[], format?: ToolResultFormat): string;
 /**
  * Why a look for a capped turn came back with nothing.
  *
@@ -193,6 +208,13 @@ export declare function buildCappedThinkingRequest(options: {
     partialAnswer?: string;
     /** The note's length target, in tokens (`resolveCondensedThinkingNoteTokens`). */
     noteTokens?: number;
+    /**
+     * What the user typed. Only for a request of its own: the conversation's
+     * next turn already has them in front of it.
+     */
+    userRequests?: readonly string[];
+    /** The task's tool record (`recordedToolCalls`), on the same terms. */
+    toolRecord?: string;
 }): string;
 export interface CappedThinkingCondenserConfig {
     enabled?: boolean;

package/dist/extensions/context/compaction-shared.d.ts

@@ -1,6 +1,6 @@
 import type { ModelInfo, ReasoningHistoryMode, ToolResultContent } from "@cerebriline/llms";
 import { resolveDefaultMaxOutputTokens } from "@cerebriline/llms";
-import { CHARS_PER_TOKEN, estimateThinkingTokens, estimateTokens, type MessageWithMetadata } from "@cerebriline/shared";
+import { asStructuredToolResultEntry, CHARS_PER_TOKEN, estimateThinkingTokens, estimateTokens, type MessageWithMetadata, type StructuredToolResultEntry, type ToolResultFormat } from "@cerebriline/shared";
 export { CHARS_PER_TOKEN, estimateThinkingTokens, estimateTokens };
 import type { CoreCompactionSummarizerConfig } from "../../types/config";
 import type { ProviderConfig } from "../../types/provider-settings";
@@ -50,6 +50,15 @@ export declare const MAX_SUMMARY_OUTPUT_TOKENS = 8192;
 export declare const SUMMARY_OUTPUT_WINDOW_SHARE = 0.08;
 export declare const TOOL_RESULT_CHAR_LIMIT = 2000;
 export declare const FILE_CONTENT_CHAR_LIMIT = 2000;
+/**
+ * The longest a single argument of a tool call is written into a transcript
+ * pasted into a compaction request. Reasoning and file contents already had a
+ * bound there and arguments did not: f099u (pandorum, 2026-10-22) put two
+ * refused edits of 141,009 and 272,888 characters into every summary and
+ * reviewer request, 571,425 characters each. What a call was for is in its
+ * other arguments; what it wrote is in the file, or was never applied.
+ */
+export declare const TOOL_INPUT_VALUE_CHAR_LIMIT = 4000;
 export declare const MIN_TRUNCATED_MESSAGE_TOKENS = 8;
 export declare function resolveSummaryMaxOutputTokens(maxInputTokens: number | undefined): number;
 export interface CompactionOutputBudgets {
@@ -287,17 +296,28 @@ export declare function truncateText(text: string, limit: number): string;
  * happened, so a session whose checker returned `ok:false` three times was
  * summarised as "the game is running" and the next context believed it.
  */
-export interface StructuredToolResultEntry {
-    query?: unknown;
-    result?: unknown;
-    success?: unknown;
-    error?: unknown;
+export type { StructuredToolResultEntry };
+export { asStructuredToolResultEntry };
+/**
+ * How a session's tool results are rendered, for the parts of compaction the
+ * model reads: the summarizer's transcript, the call record, a condensed
+ * note's outcomes. Absent, or `json`, is the rendering they always had.
+ */
+export interface ToolResultRendering {
+    format?: ToolResultFormat;
+    /** The block's `serialized` mark, so a codec-written string is parsed back. */
+    serialized?: string;
 }
-export declare function asStructuredToolResultEntry(block: unknown): StructuredToolResultEntry | undefined;
-export declare function flattenToolResultContent(content: ToolResultContent["content"]): string;
+export declare function flattenToolResultContent(content: ToolResultContent["content"], rendering?: ToolResultRendering): string;
 export declare function truncateToolResultContentForCompaction(content: ToolResultContent["content"]): ToolResultContent["content"];
 export declare function formatToolInput(input: Record<string, unknown>): string;
-export declare function serializeMessage(message: MessageWithMetadata): string;
+/**
+ * A call's arguments for a transcript: each string value past
+ * {@link TOOL_INPUT_VALUE_CHAR_LIMIT} keeps its beginning and its end, and
+ * says how much of it was left out.
+ */
+export declare function formatToolInputForTranscript(input: Record<string, unknown>): string;
+export declare function serializeMessage(message: MessageWithMetadata, format?: ToolResultFormat): string;
 /**
  * Render the discarded reasoning against what it produced.
  *
@@ -311,8 +331,8 @@ export declare function serializeMessage(message: MessageWithMetadata): string;
  * about method has no use for the contents of a file, and on the transcripts this
  * was built against the results are most of the bytes.
  */
-export declare function serializeReasoningWithOutcomes(messages: MessageWithMetadata[]): string;
-export declare function serializeConversation(messages: MessageWithMetadata[]): string;
+export declare function serializeReasoningWithOutcomes(messages: MessageWithMetadata[], format?: ToolResultFormat): string;
+export declare function serializeConversation(messages: MessageWithMetadata[], format?: ToolResultFormat): string;
 export declare function createTokenEstimator(): EstimateMessageTokens;
 export declare function isCompactionSummaryMessage(message: MessageWithMetadata): boolean;
 /**
@@ -364,6 +384,20 @@ export declare function isTurnStartMessage(message: MessageWithMetadata): boolea
  */
 /** The most any single quoted request may take before its middle is cut. */
 export declare const MAX_USER_REQUEST_CHARS = 2000;
+/**
+ * Every instruction, as fully as the budget allows.
+ *
+ * Nothing is dropped, because a missing instruction is the one loss this block
+ * exists to prevent and a reader cannot tell an absent one from one that was
+ * never given. What happens under pressure instead is elision: each request
+ * keeps its head and its tail and says in the middle how much was cut, which
+ * is a statement a reader can act on.
+ *
+ * The share is spread evenly rather than favouring the newest. The standing
+ * task is usually the first thing typed and the steering is usually the last,
+ * and there is no general rule about which of them the next turn needs.
+ */
+export declare function renderUserRequests(requests: readonly string[], budgetChars?: number): string[];
 export declare function collectUserRequests(messages: readonly MessageWithMetadata[]): string[];
 export declare function findFirstUserMessageIndex(messages: MessageWithMetadata[]): number;
 export declare function findLastTurnStartIndex(messages: MessageWithMetadata[]): number;
@@ -724,6 +758,8 @@ export declare function seedCalibrationFromTranscript(request: {
     messages: MessageWithMetadata[];
     tools?: unknown[];
     reasoningHistory?: ReasoningHistoryMode;
+    /** As the request path renders tool results; see `ToolResultFormat`. */
+    toolResultFormat?: ToolResultFormat;
     /** Whose transcript this is, so the seeded count answers only to it. */
     sessionId?: string;
 }): void;

package/dist/extensions/context/compaction.d.ts

@@ -200,7 +200,7 @@ export declare function resolveMessageTargetOnTriggerScale(input: {
 export declare function scaleEstimateToObserved(estimate: number, estimateOfObserved: number, observed: number | undefined): number;
 /** Test seam: the latch is process-wide, so a suite has to be able to clear it. */
 export declare function resetStarvedOutputCapLatch(): void;
-export declare function createContextCompactionPrepareTurn(config: Pick<CoreSessionConfig, "providerConfig" | "providerId" | "modelId" | "apiKey" | "baseUrl" | "headers" | "compaction" | "logger" | "telemetry" | "sessionId"> & Partial<Pick<CoreSessionConfig, "thinking" | "reasoningEffort" | "thinkingBudgetTokens" | "temperature">>, options?: ContextCompactionPrepareTurnOptions): ((context: ContextPipelinePrepareTurnInput) => Promise<ContextPipelinePrepareTurnResult | undefined>) | undefined;
+export declare function createContextCompactionPrepareTurn(config: Pick<CoreSessionConfig, "providerConfig" | "providerId" | "modelId" | "apiKey" | "baseUrl" | "headers" | "compaction" | "logger" | "telemetry" | "sessionId"> & Partial<Pick<CoreSessionConfig, "thinking" | "reasoningEffort" | "thinkingBudgetTokens" | "temperature" | "toolResultFormat">>, options?: ContextCompactionPrepareTurnOptions): ((context: ContextPipelinePrepareTurnInput) => Promise<ContextPipelinePrepareTurnResult | undefined>) | undefined;
 /**
  * Compaction policy for resuming a session imported from another coding agent.
  * The imported transcript keeps that agent's tool names and input schemas

package/dist/extensions/context/council-compaction.d.ts

@@ -34,7 +34,7 @@
  *   was given. A council that cannot run leaves an unreviewed summary, which
  *   is exactly what shipped before it existed.
  */
-import type { BasicLogger, MessageWithMetadata } from "@cerebriline/shared";
+import type { BasicLogger, MessageWithMetadata, ToolResultFormat } from "@cerebriline/shared";
 /** What a reviewer and the synthesiser are told they are. */
 export declare const COUNCIL_SYSTEM_PROMPTS: {
     readonly critic: "You are rewriting one half of an account of your own work, with the record of that work in front of you. Correct what the record contradicts, add what it shows missing, fix every quotation against it, and improve the prose where it has drifted out of voice. You return your half and only your half: another writer is rewriting the other one, and the two will be joined into a single continuous replay.";
@@ -200,6 +200,8 @@ export declare function runCouncilReview(input: {
     summary: string;
     thinkingSummary?: string;
     messages: readonly MessageWithMetadata[];
+    /** How the conversation's tool results read; the critics see the same. */
+    toolResultFormat?: ToolResultFormat;
     /**
      * One model call. Throwing is allowed and is handled as a decline.
      *

package/dist/extensions/context/replay-compaction.d.ts

@@ -55,7 +55,7 @@
  * and any disagreement is visible rather than silent.
  */
 /** The instruction, when the recency tail is kept. */
-export declare const DEFAULT_REPLAY_COMPACTION_PROMPT = "Your transcript has grown too long and the earlier part of it is about to be discarded. Write the replay that takes its place.\n\nYour replay will be **prepended directly to the messages that remain** \u2014 your own most recent turns, which are still there and which you will read immediately after this. Write it so that seam is invisible.\n\nWrite in the **first person, present continuous tense**, in your own voice, in the same prose as the turns it sits in front of. You are not reporting on a session to someone else and you are not recounting something finished: you are picking the work back up, and everything in the replay is the situation as it stands right now.\n\nWrite **every step** as the step itself, then what came back. The opening of a\nstep is what you are about to do; the outcome is its own short sentence after\nit. These are the shapes \u2014 reuse them:\n\n- \"The user is asking me to fix the collision.\"\n- \"Let me start by reading the file.\"\n- \"Let me read a large chunk of the file.\" \u2014 then what it showed.\n- \"Let me try reconstructing the script section. It failed: `check_file` reports an unterminated regular expression at line 274.\"\n- \"Now the editor is warning me this change shifted the line numbers by +11.\"\n- \"The file parses now, so what is left is the collision check.\"\n\nThis holds for the middle of the replay and not only its first and last\nsentences. A step that opens by reporting itself has changed voice, and the\nseam this replay exists to remove is back.\n\nWritten in the past tense the replay reads as history, and history is something you are entitled to doubt: you will re-read files you already know, re-derive what you have already settled, and treat a warning that is still in force as something that merely once happened. Written in the present it is the state of play, which is what it actually is. Every sentence, not only the first and the last.\n\nCarry all of this:\n\n- **What you are asked to do, verbatim.** Quote the instructions you have been given word for word. Everything else here can be rebuilt from the files or from the record below your replay; what was asked exists nowhere else once these messages are gone.\n- **What you have done, in order.** Narrate it, and **cite the calls instead of writing them out.** Every call you made, with its arguments and what it returned, is numbered in the record below. Where a call belongs in your account, put its number in square brackets with a `#`, and carry on:\n\n  \"Let me run the checker. [#3] It reports a `SyntaxError` at line 90.\"\n\n  The harness puts call 3 in at that point, exactly as it happened. Writing the call out yourself instead would spend your budget copying a record that is already exact, and yours would be the less accurate of the two. Cite each call once, in the order you made them. Where a run of calls in sequence belongs at the same point \u2014 the same check repeated, a read and the edit that followed it \u2014 cite the span as `[#2-5]` rather than one at a time; the harness puts all of them in there. A number you leave out is not lost \u2014 it is added at the end \u2014 but then it sits away from the step it belongs to.\n\n  **The record is complete and closed.** Every call you have made is in it, and nothing else is. The highest number in it is the last call you made, so there is no `[#N]` past the end to cite \u2014 if you find yourself reaching for one, the step you are about to describe is a step you have not taken yet, and it does not belong in an account of what you have done. Cite only a number that is actually in the record, and leave a step with no call behind it uncited rather than attaching it to a number that names someone else's work.\n- **What is coming back wrong**, and what you are doing about it. A call that was refused or returned an error is the most important kind to keep \u2014 without it you will simply make it again.\n- **What you have concluded**, including anything you have ruled out and why. An approach that failed, omitted here, is an approach you will try again.\n- **Where you are now**, and what you are about to do next.\n\nDo not invent anything you are not sure of. In particular, do not report a result you cannot see: a call whose output is not in front of you is a call whose outcome you do not know, and writing that it succeeded is the one error here that the next turn cannot recover from.\n\nDo not write instructions to yourself to rewrite or restore content that this replay does not itself contain \u2014 you would be reconstructing from memory something that is still on disk, and producing a worse version of it.\n\nWrite the replay and stop. Do not continue the transcript that follows these instructions, and do not copy any part of it back: it is what you are replacing.";
+export declare const DEFAULT_REPLAY_COMPACTION_PROMPT = "Your transcript has grown too long and the earlier part of it is about to be discarded. Write the replay that takes its place.\n\nYour replay will be **prepended directly to the messages that remain** \u2014 your own most recent turns, which are still there and which you will read immediately after this. Write it so that seam is invisible.\n\nWrite in the **first person, present continuous tense**, in your own voice, in the same prose as the turns it sits in front of. You are not reporting on a session to someone else and you are not recounting something finished: you are picking the work back up, and everything in the replay is the situation as it stands right now.\n\nWrite **every step** as the step itself, then what came back. The opening of a\nstep is what you are about to do; the outcome is its own short sentence after\nit. These are the shapes, taken from a task that is not yours \u2014 reuse the\nshapes, and take every name, line and value from your own transcript:\n\n- \"The user is asking me to fix the invoice rounding.\"\n- \"Let me start by reading the file.\"\n- \"Let me read a large chunk of the file.\" \u2014 then what it showed.\n- \"Let me try rewriting the totals function. It failed: `test_invoice_total` expects 100.00 and is getting 99.99.\"\n- \"Now the editor is warning me this change shifted the line numbers by +11.\"\n- \"The tests pass now, so what is left is the currency conversion.\"\n\nThis holds for the middle of the replay and not only its first and last\nsentences. A step that opens by reporting itself has changed voice, and the\nseam this replay exists to remove is back.\n\nWritten in the past tense the replay reads as history, and history is something you are entitled to doubt: you will re-read files you already know, re-derive what you have already settled, and treat a warning that is still in force as something that merely once happened. Written in the present it is the state of play, which is what it actually is. Every sentence, not only the first and the last.\n\nCarry all of this:\n\n- **What you are asked to do, verbatim.** Quote the instructions you have been given word for word. Everything else here can be rebuilt from the files or from the record below your replay; what was asked exists nowhere else once these messages are gone.\n- **What you have done, in order.** Narrate it, and **cite the calls instead of writing them out.** Every call you made, with its arguments and what it returned, is numbered in the record below. Where a call belongs in your account, put its number in square brackets with a `#`, and carry on:\n\n  \"Let me run the tests. [#3] `test_invoice_total` fails at line 58.\"\n\n  The harness puts call 3 in at that point, exactly as it happened. Writing the call out yourself instead would spend your budget copying a record that is already exact, and yours would be the less accurate of the two. Cite each call once, in the order you made them. Where a run of calls in sequence belongs at the same point \u2014 the same check repeated, a read and the edit that followed it \u2014 cite the span as `[#2-5]` rather than one at a time; the harness puts all of them in there. A number you leave out is not lost \u2014 it is added at the end \u2014 but then it sits away from the step it belongs to.\n\n  **The record is complete and closed.** Every call you have made is in it, and nothing else is. The highest number in it is the last call you made, so there is no `[#N]` past the end to cite \u2014 if you find yourself reaching for one, the step you are about to describe is a step you have not taken yet, and it does not belong in an account of what you have done. Cite only a number that is actually in the record, and leave a step with no call behind it uncited rather than attaching it to a number that names someone else's work.\n- **What is coming back wrong**, and what you are doing about it. A call that was refused or returned an error is the most important kind to keep \u2014 without it you will simply make it again.\n- **What you have concluded**, including anything you have ruled out and why. An approach that failed, omitted here, is an approach you will try again.\n- **Where you are now**, and what you are about to do next.\n\nDo not invent anything you are not sure of. In particular, do not report a result you cannot see: a call whose output is not in front of you is a call whose outcome you do not know, and writing that it succeeded is the one error here that the next turn cannot recover from.\n\nDo not write instructions to yourself to rewrite or restore content that this replay does not itself contain \u2014 you would be reconstructing from memory something that is still on disk, and producing a worse version of it.\n\nWrite the replay and stop. Do not continue the transcript that follows these instructions, and do not copy any part of it back: it is what you are replacing.";
 export interface CutTranscript {
     text: string;
     /** How much of the summary was the request, copied back. */

package/dist/extensions/context/tool-ledger.d.ts

@@ -27,6 +27,7 @@
  * **Legibility.** The reader is a small model that has just lost its memory.
  * One line per call, the failures marked, no JSON it has to parse.
  */
+import { type ToolResultFormat } from "@cerebriline/shared";
 /**
  * Any message with a content array, in either of the two block shapes this
  * repository carries — see {@link normaliseCall}.
@@ -90,6 +91,11 @@ export interface ToolLedgerLimits {
 export declare const DEFAULT_TOOL_LEDGER_LIMITS: ToolLedgerLimits;
 export interface ToolLedgerOptions {
     limits?: Partial<ToolLedgerLimits>;
+    /**
+     * Under `text`, a result the transcript codec stored as JSON is read back
+     * into the entry it was, so the key quotes the result and not its escapes.
+     */
+    toolResultFormat?: ToolResultFormat;
 }
 /**
  * The revisions held for one file, as a span like `#1–#7`.
@@ -133,6 +139,12 @@ export declare function mergeToolLedger(previous: readonly ToolLedgerEntry[], ne
  * something that did.
  */
 export declare function evictToolLedger(entries: readonly ToolLedgerEntry[], budgetChars: number): ToolLedgerEntry[];
+/**
+ * Which entries `evictToolLedger` keeps, by position, for a caller that has
+ * to keep its own numbering: the compaction cites a fold by the numbers it
+ * showed the writer, and stores only what survives.
+ */
+export declare function toolLedgerSurvivors(entries: readonly ToolLedgerEntry[], budgetChars: number): boolean[];
 /**
  * The ledger as the model will read it.
  *
@@ -154,7 +166,7 @@ export declare function renderToolLedgerEntry(entry: ToolLedgerEntry): string;
  * the tail, so the full ledger hands back a fragment the transcript had
  * deliberately cut.
  */
-export declare function renderToolLedgerKey(entries: readonly ToolLedgerEntry[]): string;
+export declare function renderToolLedgerKey(entries: readonly ToolLedgerEntry[], maxChars?: number): string;
 export interface LedgerSpliceResult {
     text: string;
     /** Entries the replay placed itself, in the order it placed them. */

package/dist/extensions/tools/check-on-failure.d.ts

@@ -26,6 +26,8 @@ export interface CheckOnFailureOptions {
     checker: Pick<AgentTool<{
         paths: string[];
     }, unknown>, "execute">;
+    /** Told which files the checker reported on, so they count as checked. */
+    onChecked?: (paths: readonly string[]) => void;
 }
 /**
  * Wrap a shell tool so failing commands come back with the checker's verdict.
@@ -46,4 +48,5 @@ export declare function joinCheckerToShell<TTool extends AgentTool<never, unknow
     cwd: string;
     shellName: string;
     checkerName: string;
+    onChecked?: (paths: readonly string[]) => void;
 }): TTool[];

package/dist/extensions/tools/edit-verification.d.ts

@@ -1,4 +1,4 @@
-import type { AgentTool } from "@cerebriline/shared";
+import { type AgentTool } from "@cerebriline/shared";
 /**
  * Files the model changed and has not checked since.
  *
@@ -35,6 +35,14 @@ export interface EditVerificationConfig {
      * aside: the model has been told twice and the work is the user's to judge.
      */
     attempts?: number;
+    /** Where relative paths resolve from, so `a.ts` and `/ws/a.ts` are one file. */
+    cwd?: string;
+    /**
+     * Whether a file is still on disk. A file the model deleted has nothing
+     * left to check: session y1t7j was asked to check six scratch scripts it
+     * had removed, and `check_file` called them clean.
+     */
+    fileExists?: (absolutePath: string) => boolean;
 }
 export declare const EDIT_VERIFICATION_ATTEMPTS = 2;
 /** Files edited since they were last checked, in the order they were edited. */
@@ -44,10 +52,12 @@ export interface EditVerificationState {
 /**
  * Every file path an argument bag names, whatever shape it names them in.
  *
- * `editor` sends `path`, `check_file` sends `paths`, and `read_files` sends
- * `files: [{ path }]`. Reading one shape would silently cover one tool, which
- * is the failure mode this whole module exists to answer, so all three are
- * read and anything unrecognised contributes nothing.
+ * `editor` sends `file_path` (`path` before 2026-10-20), `check_file` sends
+ * `paths`, and `read_files` sends `files: [{ path }]`. Reading one shape would
+ * silently cover one tool, which is the failure mode this whole module exists
+ * to answer, so all of them are read and anything unrecognised contributes
+ * nothing. Read as `path` alone, no editor edit was tracked after the rename
+ * and the unchecked-edit guard never fired.
  */
 export declare function extractPaths(input: unknown): string[];
 /** Tracks which edited files are still unverified. */
@@ -56,10 +66,21 @@ export declare class EditVerificationTracker {
     private readonly checkTools;
     /** Normalised path → the path as the model wrote it, for the message. */
     private readonly unchecked;
+    private readonly cwd?;
+    private readonly fileExists?;
     constructor(config: EditVerificationConfig);
+    private absolute;
+    private key;
     /** Whether this tracker can ever have anything to say. */
     get armed(): boolean;
     recordToolCall(toolName: string, input: unknown): void;
+    /**
+     * Files a checker reported on outside a checker call: the one a failing
+     * command runs on the file it names. Its report is in the model's hands
+     * either way (session y1t7j ran it after its last edit, clean, and was
+     * still asked to check the file).
+     */
+    recordChecked(paths: readonly string[]): void;
     getState(): EditVerificationState;
     reset(): void;
 }

package/dist/extensions/tools/executors/bash.d.ts

@@ -15,6 +15,13 @@ export interface DetachedCommandLogCleanupOptions {
     processStartTokenProbe?: ProcessStartTokenProbe;
     activeCommandPollIntervalMs?: number;
 }
+type DetachedCommandMarker = {
+    version: 1;
+    executionId: string;
+    pid: number;
+    processStartToken: string;
+    detachedAtMs: number;
+};
 /**
  * Reaps completed detached command logs outside the retention window,
  * schedules retained logs for their remaining lifetime, and follows active
@@ -97,6 +104,14 @@ export interface ShellExecutorOptions {
      * say what the command did to what the model believes.
      */
     receipts?: ReadReceipts;
+    /**
+     * A delegated agent's overlay, so the sweep above stamps the agent's copy
+     * of a file rather than the workspace file its commands no longer write.
+     * Only resolving is needed: the command itself runs through `wrapSpawn`.
+     */
+    overlay?: {
+        resolveRead(filePath: string): Promise<string>;
+    };
     /**
      * Optional host-scoped controller that can release an in-flight command
      * from its tool call while continuing to drain output to a bounded log.
@@ -129,6 +144,12 @@ export interface ShellExecutorOptions {
     /** Process identity provider used to enable safe command detachment. */
     processStartTokenProbe?: ProcessStartTokenProbe;
 }
+/** Exported for its own tests: the order of its writes is the contract. */
+export declare function createDetachedLog(retentionMs: number, marker: DetachedCommandMarker): {
+    path: string;
+    write(text: string): void;
+    complete: () => void;
+};
 /**
  * Create a shell executor using Node.js spawn
  *
@@ -143,3 +164,4 @@ export interface ShellExecutorOptions {
  * ```
  */
 export declare function createShellExecutor(options?: ShellExecutorOptions): ShellExecutor;
+export {};

package/dist/extensions/tools/executors/document/formats.d.ts

@@ -5,6 +5,12 @@ import type { ImageCollector } from "./images";
 export type DocumentFormat = "pdf" | "docx" | "pptx" | "xlsx" | "odt" | "odp" | "ods" | "odg" | "rtf" | "csv" | "html" | "epub" | "mobi" | "azw3" | "fb2" | "doc" | "xls" | "ppt";
 /** The names a format is known by, and the reader it goes to. */
 export declare const FORMAT_LABELS: Record<DocumentFormat, string>;
+/** Whether bytes are gzip: a book is often kept as `book.fb2.gz`. */
+export declare function isGzip(head: Uint8Array): boolean;
+/** A name without the `.gz` a gzipped document carries. */
+export declare function ungzippedName(filePath: string): string;
+/** The extension that says what a file is, under any `.gz` wrapped round it. */
+export declare function documentExtension(filePath: string): string;
 /** Every extension this tool reads, for the tool description and read_files. */
 export declare const DOCUMENT_EXTENSIONS: readonly string[];
 export type FormatVerdict = {

package/dist/extensions/tools/executors/read-receipts.d.ts

@@ -18,6 +18,18 @@
  */
 export type FileStamp = string;
 export declare function readFileStamp(filePath: string): Promise<FileStamp | undefined>;
+/**
+ * The stamp of a file as the caller sees it: through an agent's overlay, the
+ * copy the agent is working on once it has one, else the workspace file.
+ *
+ * Everything that stamps a file has to stamp the same one. The editor stamps
+ * the overlay copy it writes; a `grep` or a command that stamped the workspace
+ * file beside it left two stamps that could never agree, and the agent's next
+ * edit was refused as "something outside this session wrote to it" (ol-22).
+ */
+export declare function fileStampFor(filePath: string, overlay?: {
+    resolveRead(filePath: string): Promise<string>;
+}): Promise<FileStamp | undefined>;
 export interface ReadReceipts {
     /** Record that `filePath` was read over the given inclusive line span. */
     noteRead(filePath: string, first: number, last: number): void;

package/dist/extensions/tools/helpers.d.ts

@@ -20,6 +20,18 @@ export declare function getReadFileRangeError(request: ReadFileRequest): string
  * orphan range entries into the preceding file entry before validation.
  */
 export declare function coalesceOrphanReadRanges(input: unknown): unknown;
+/**
+ * Hand options written beside the file list to the files in it.
+ *
+ * Measured on pandorum (klbbz): `{end_line: 120, files: [{path, start_line: 80}]}`.
+ * The schema keeps only what is on each entry, so the `end_line` was dropped
+ * without a word and the read ran from line 80 to the end of the file. A
+ * `line_numbers: false` written there was dropped the same way, and a model
+ * that asked for clean text to copy into an edit got numbered lines instead.
+ * Each entry keeps any option it sets itself; only the ones it leaves out are
+ * taken from beside the list.
+ */
+export declare function applySharedReadOptions(input: unknown): unknown;
 /**
  * Read a path field whose value is a list rendered as a string.
  *

package/dist/extensions/tools/list-files.d.ts

@@ -38,7 +38,7 @@ import { type AgentTool } from "@cerebriline/shared";
  * and it reaches for `ls` for exactly the same reason.
  */
 export declare const LIST_FILES_TOOL_NAME = "list_files";
-export declare const LIST_FILES_TOOL_DESCRIPTION = "List the files in the workspace. Use this to find out what exists \u2014 do not run `ls`, `dir`, `find` or `Get-ChildItem` through `run_commands` to look around, because this is scoped to the workspace and those are not.\n\nTwo ways to ask:\n- `path` \u2014 list what is directly inside one directory. Omit it to list the workspace root.\n- `pattern` \u2014 a glob searched across the whole workspace, e.g. `**/*.html`, `src/**/*.ts`, `**/manic_miner.*`. Use this when you know part of a name but not where it lives.\n\nResults are limited to the workspace folders the user opened, and directories the user's settings exclude from search \u2014 `node_modules`, `.git`, build output \u2014 are left out. A path outside the workspace is refused rather than listed.\n\nThis tells you which files exist, not what is in them. To find files by their contents use `search_codebase`, which reports the line each match is on and is the right way to locate the part of a file worth reading.";
+export declare const LIST_FILES_TOOL_DESCRIPTION = "List the files in the workspace. Use this to find out what exists \u2014 do not run `ls`, `dir`, `find` or `Get-ChildItem` through `run_commands` to look around, because this is scoped to the workspace and those are not.\n\nTwo ways to ask:\n- `path` \u2014 list what is directly inside one directory. Omit it to list the workspace root.\n- `pattern` \u2014 a glob searched across the whole workspace, e.g. `**/*.html`, `src/**/*.ts`, `**/config.*`. Use this when you know part of a name but not where it lives.\n\nResults are limited to the workspace folders the user opened, and directories the user's settings exclude from search \u2014 `node_modules`, `.git`, build output \u2014 are left out. A path outside the workspace is refused rather than listed.\n\nThis tells you which files exist, not what is in them. To find files by their contents use `search_codebase`, which reports the line each match is on and is the right way to locate the part of a file worth reading.";
 export declare const LIST_FILES_TOOL_INPUT_SCHEMA: {
     readonly type: "object";
     readonly properties: {

package/dist/extensions/tools/schemas.d.ts

@@ -651,6 +651,38 @@ export declare const EditFileInputSchema: z.ZodObject<{
     occurrence: z.ZodOptional<z.ZodNullable<z.ZodCoercedNumber<unknown>>>;
     replace_all: z.ZodOptional<z.ZodNullable<z.ZodPreprocess<z.ZodBoolean>>>;
 }, z.core.$strip>;
+/**
+ * The editor's arguments as the model is shown them and writes them.
+ *
+ * The same arguments as {@link EditFileInputSchema}, with the file named
+ * `file_path` rather than `path` and listed first. `file_path` sorts before
+ * `new_text`, which `path` did not, and a template that renders a call's
+ * arguments by name puts it there: see `editorFilePath` in `@cerebriline/shared`
+ * for the runs this comes from. The executor still takes `path`;
+ * {@link toEditFileInput} is the one place the two meet.
+ */
+export declare const EditorToolInputSchema: z.ZodObject<{
+    occurrence: z.ZodOptional<z.ZodNullable<z.ZodCoercedNumber<unknown>>>;
+    start_line: z.ZodOptional<z.ZodNullable<z.ZodCoercedNumber<unknown>>>;
+    end_line: z.ZodOptional<z.ZodNullable<z.ZodCoercedNumber<unknown>>>;
+    new_text: z.ZodString;
+    old_text: z.ZodOptional<z.ZodNullable<z.ZodString>>;
+    start_column: z.ZodOptional<z.ZodNullable<z.ZodCoercedNumber<unknown>>>;
+    end_column: z.ZodOptional<z.ZodNullable<z.ZodCoercedNumber<unknown>>>;
+    insert_line: z.ZodOptional<z.ZodNullable<z.ZodCoercedNumber<unknown>>>;
+    insert_column: z.ZodOptional<z.ZodNullable<z.ZodCoercedNumber<unknown>>>;
+    replace_all: z.ZodOptional<z.ZodNullable<z.ZodPreprocess<z.ZodBoolean>>>;
+    file_path: z.ZodString;
+}, z.core.$strip>;
+export type EditorToolInput = z.infer<typeof EditorToolInputSchema>;
+/**
+ * A call that names its file with the old `path` is still aimed at that
+ * file. Applied before validation, like {@link withNewTextAlias}, so the
+ * schema the model is shown names one argument. `file_path` wins when both
+ * are present.
+ */
+export declare function withFilePathAlias(value: unknown): unknown;
+export declare function toEditFileInput(input: EditorToolInput): EditFileInput;
 /**
  * Schema for apply_patch tool input
  */