* feat: store reasoning in conversation history for all providers
* refactor: address review feedback
- Move comments inside else block
- Combine reasoning checks into single if block
- Make comments more concise
* refactor: make comments more concise
* Fix preserveReasoning flag to control API reasoning inclusion
Changes:
1. Removed hardcoded <think> tag logic in streaming
- Previously hardcoded reasoning into assistant message text
- Now passes reasoning to addToApiConversationHistory as parameter
2. Updated buildCleanConversationHistory to respect preserveReasoning flag
- When preserveReasoning: true → reasoning block included in API requests
- When preserveReasoning: false/undefined → reasoning stripped from API
- Reasoning stored in history for all cases
3. Added temporary debug logs to base-openai-compatible-provider.ts
- Shows preserveReasoning flag value
- Logs reasoning blocks in incoming messages
- Logs <think> tags in converted messages sent to API
* Fix: Use api.getModel() directly instead of cachedStreamingModel
Addresses review comment: cachedStreamingModel is set during streaming but
buildCleanConversationHistory is called before streaming starts. Using the
cached value could cause stale model info when switching models between requests.
Now directly uses this.api.getModel().info.preserveReasoning to ensure we
always check the current model's flag, not a potentially stale cached value.
* Clean up comments in Task.ts
Removed outdated comment regarding model's preserveReasoning flag.
* fix: remove unnecessary reasoningBlock variable in task reasoning logic
- Filter out complete environment_details blocks before appending fresh ones
- Check for both opening and closing tags to ensure we're matching complete blocks
- Prevents stale environment data from being kept during task resume
- Add tests to verify deduplication logic and edge cases
* Improve read_file tool description with examples
- Add explicit JSON structure documentation
- Include three concrete examples (single file, with line ranges, multiple files)
- Clarify that 'path' is required and 'line_ranges' is optional
- Better explain line range format (1-based inclusive)
This addresses agent confusion by providing clear examples similar to the XML tool definition.
* Make read_file tool dynamic based on partialReadsEnabled setting
- Convert read_file from static export to createReadFileTool() factory function
- Add getNativeTools() function that accepts partialReadsEnabled parameter
- Create buildNativeToolsArray() helper to encapsulate tool building logic
- Update Task.ts to build native tools dynamically using maxReadFileLine setting
- When partialReadsEnabled is false, line_ranges parameter is excluded from schema
- Examples and descriptions adjust based on whether line ranges are supported
This matches the behavior of the XML tool definition which dynamically adjusts
its documentation based on settings, reducing confusion for agents.
