feat(context): add CPG-10 large text-part tool-result projection - #26
feat(context): add CPG-10 large text-part tool-result projection#26Wibias wants to merge 9 commits into
Conversation
|
✅ Deterministic PR hygiene checks passed. |
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. 🗂️ Base branches to auto review (2)
Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
cb8ff73 to
99e0ede
Compare
CPG-10 first slice: Codex sometimes wraps file/tool output as a single text part instead of a bare string. Project that part when it is the only content, and leave mixed image+text or empty results untouched.
Codex probe A never delivered the 184KiB inventory as parsed tool text. Keep empty results and Responses file placeholders unprojected so CPG-10 cannot invent bytes that are not in context.
CPG-10 second slice: Codex may wrap file output as input_file instead of a bare string. Preserve that UTF-8 text so the projector can see it, and keep base64/data-URL attachments as placeholders.
When a likely file-read tool result parses empty, record only type and length metadata. This gives CPG-10 evidence for the next Codex probe without storing file contents.
The first Codex file-read probe produced an empty tool result but no capture line. Log type and length for any empty function_call_output, not only guessed file-read tool names.
…olders The Codex file-read turn produced an empty result but no capture line on function_call_output. Also inspect custom_tool_call_output and short file/encrypted placeholders so the next probe logs a wire shape.
Codex empty file-reads produced no function_call_output capture. Summarize the last input item types and output lengths before schema parse, with no file contents, so the next Codex probe can show the actual wire shape.
bd3cd91 to
26a29d9
Compare
![graphite-app[bot]](https://avatars.githubusercontent.com/in/158384?s=60&v=4){kind=small}
| output: unknown, | ||
| ): void { | ||
| const emptyContent = content === "" || (Array.isArray(content) && content.length === 0); | ||
| const placeholder = typeof content === "string" && content.length > 0 && content.length < 80 && (content.startsWith("[file:") || content.startsWith("[encrypted")); |
There was a problem hiding this comment.
The check content.startsWith("[encrypted") is incomplete and will incorrectly match unintended strings.
The condition checks for strings starting with "[encrypted" without completing the word or adding a delimiter. This would match unintended strings like "[encryptedXXX" or "[encryptedfile.txt]".
Looking at parser.ts line 258, the actual placeholder text is "[encrypted content omitted]". The check should match the actual format:
const placeholder = typeof content === "string" && content.length > 0 && content.length < 80 && (content.startsWith("[file:") || content.startsWith("[encrypted "));This ensures consistency with the "[file:" check (which includes the colon) and prevents false positives.
| const placeholder = typeof content === "string" && content.length > 0 && content.length < 80 && (content.startsWith("[file:") || content.startsWith("[encrypted")); | |
| const placeholder = typeof content === "string" && content.length > 0 && content.length < 80 && (content.startsWith("[file:") || content.startsWith("[encrypted ")); | |
Spotted by Graphite
Is this helpful? React 👍 or 👎 to let us know.
Identify the live 47-char custom_tool_call_output without storing file dumps. Record that Codex exec strips the 184 KiB inventory before /v1/responses.
Match the parser marker [encrypted content omitted] and ignore adjacent words like [encryptedfile.txt].
1 participant
Summary
Verification
Checklist