chore: bump version to 0.1.26 and update model references#137
Conversation
- Updated package version to 0.1.26. - Changed model references from `minimaxai/minimax-m2.7` to `minimaxai/minimax-m3` across various services and configurations. - Introduced `onStepFinish` callback in multiple AI service classes to enhance step tracking during tool execution. - Added a new `StepStatusRow` class for live status updates during AI operations, improving user feedback in the CLI. - Updated pricing and model information to reflect the new model version.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
There was a problem hiding this comment.
Your free trial has ended. If you'd like to continue receiving code reviews, you can add a payment method here.
WalkthroughIntroduces a new ChangesPer-step streaming TUI and provider onStepFinish
MiniMax M3 Model Upgrade
Estimated code review effort🎯 4 (Complex) | ⏱️ ~60 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Warning There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure. 🔧 ESLint
ESLint install failed. For unrecoverable errors, disable the tool in CodeRabbit configuration. 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 |
There was a problem hiding this comment.
Actionable comments posted: 11
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
apps/supercode-cli/server/src/cli/ai/minimax-service.ts (1)
42-49: 🎯 Functional Correctness | 🟠 Major | ⚡ Quick winForward
onStepFinishintoexecuteToolLoop().The parameter is accepted but not passed to the tool executor, so Minimax tool runs never close/update per-step UI through the new callback.
Proposed fix
system, tools, - { onChunk, onToolCall, onReasoning, onToolResult, signal }, + { onChunk, onToolCall, onReasoning, onToolResult, onStepFinish, signal }, )🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@apps/supercode-cli/server/src/cli/ai/minimax-service.ts` around lines 42 - 49, The Minimax tool path in `minimax-service.ts` accepts `onStepFinish` but does not forward it into `executeToolLoop`, so per-step completion updates never fire. Update the `executeToolLoop(...)` call inside the `tools && Object.keys(tools).length > 0` branch to pass the `onStepFinish` callback alongside the existing `onChunk`, `onToolCall`, `onReasoning`, `onToolResult`, and `signal` options, keeping the `executeToolLoop` and `Minimax` service wiring consistent.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@apps/supercode-cli/server/src/cli/ai/chat/chat.ts`:
- Around line 741-745: The Ctrl+T toggle in chat.ts is placed too late, after
the stdinResolve early return, so it never runs while streaming when activeChain
is available. Move the Ctrl+T handling in the keypress flow above the “No input
handler active” guard, keeping the existing activeChain check and redraw
behavior intact so the thought toggle works during active streaming.
- Around line 427-428: The abort cleanup path in the chat flow leaves
activeChain pointing at the cancelled turn while the success and non-abort error
paths already clear it. Update the abort handling near the
statusRow.stop/activeStatusRow cleanup in chat.ts to also reset activeChain to
null/undefined, matching the existing cleanup behavior used elsewhere in the
same turn execution flow.
In `@apps/supercode-cli/server/src/cli/ai/chat/step-status-row.ts`:
- Around line 156-159: The `render()` logic in `step-status-row` is writing
directly to the current cursor row from timer callbacks without reserving a
fixed line, which can overwrite streaming markdown/tool output. Update the
status rendering flow so `StepStatusRow` uses a dedicated persisted row (or
delegates row placement to the persistent footer) before calling the clear/write
sequence, and keep the cursor positioning stable within `render()` and its
caller setup.
In `@apps/supercode-cli/server/src/cli/ai/chat/thinking.ts`:
- Around line 512-516: Preserve failed-tool markers when toggling a thought by
ensuring `togglePrinted()` does not drop `ThoughtTool.flagged` state when it
re-renders via `renderThought(entry)`. Update the
`renderThought()`/`groupTools()` path so flagged tools still render with their
failed `✗` marker, or route flagged rows through the same per-tool rendering
logic used elsewhere. Verify the symbols `togglePrinted`, `renderThought`,
`groupTools`, and `ThoughtTool.flagged` keep the marker intact after Ctrl+T
re-emission.
- Around line 458-460: The collapse logic in thinking.ts ignores the exposed
keepExpanded option, so callers cannot force an entry to stay expanded unless
hadFlaggedTool is set. Update the entry.collapsed assignment in the chat
thinking flow to explicitly honor keepExpanded before autoCollapse, using the
existing keepExpanded/autoCollapse inputs alongside hadFlaggedTool so forced
expansion wins consistently.
- Around line 413-416: `ThoughtTree.beginAndPrint()` should not create a new
`ThoughtEntry` when a step is already open, since `chat.ts` may call it multiple
times per AI step. Add an idempotent guard in `beginAndPrint()` (and, if needed,
reuse the current open entry from the tree state) so repeated calls return the
existing live block instead of starting another one. Keep the behavior in sync
with `begin()`/`openInProgress` so only one thought block is active until it is
closed.
In `@apps/supercode-cli/server/src/cli/ai/concentrate-service.ts`:
- Around line 41-47: The Concentrate service is capturing onStepFinishRef but
never forwarding it from the SDK step-finish hook, so the chat UI never receives
step completion updates. Update the Concentrate flow in concentrate-service.ts
to wire the SDK’s step-finish callback through to onStepFinishRef, matching the
behavior already used by the Google service. Make sure the callback is invoked
with the step number, toolCalls, and toolResults so chat.ts can collapse/update
the per-step UI correctly.
In `@apps/supercode-cli/server/src/cli/ai/google-service.ts`:
- Around line 55-61: The Google service method is capturing onStepFinish but not
forwarding it into the step handler, so the chat flow never receives step-finish
updates. Update google-service’s streamText step handling to invoke
onStepFinishRef with the step details when a step completes, using the existing
onStepFinish parameter and its callback shape. Keep the fix localized around the
streamText handler and the onStepFinishRef usage so
apps/supercode-cli/server/src/cli/ai/chat/chat.ts can close the Thought block
and advance the status row.
In `@apps/supercode-cli/server/src/cli/ai/openrouter-service.ts`:
- Around line 315-329: The step completion callback in openrouter-service is
using the cumulative tool-call count as stepNumber, which causes multi-tool
iterations to report the wrong step index. Update the onStepFinish payload in
the step-finish block to use the actual per-iteration step index for the current
loop execution, and keep toolCalls/toolResults mapping unchanged. Use the
onStepFinish call site and the surrounding manual polling loop in
openrouter-service to locate the fix, since chat.ts consumes stepNumber as the
completed step count.
In `@apps/supercode-cli/server/src/cli/ai/server-proxy-service.ts`:
- Around line 192-200: The per-step finish callback in server-proxy-service
should report the current step index instead of the cumulative tool-call count.
Update the onStepFinish payload in the step-completion block to use the step’s
position for stepNumber, not this.collectedToolCalls.length, so the chat UI in
chat.ts receives sequential step numbers even when multiple tools are requested
in one step.
In `@apps/supercode-cli/server/src/cli/ai/tool-executor.ts`:
- Around line 164-175: The per-step finish payload in tool-executor’s
onStepFinish block is using a zero-based step index and losing per-call argument
pairing for repeated tool names. Update the step emission to report a 1-based
step count from iter, and build toolResults from the current iteration’s
executed calls/results so each result keeps its own args instead of using find()
by toolName.
---
Outside diff comments:
In `@apps/supercode-cli/server/src/cli/ai/minimax-service.ts`:
- Around line 42-49: The Minimax tool path in `minimax-service.ts` accepts
`onStepFinish` but does not forward it into `executeToolLoop`, so per-step
completion updates never fire. Update the `executeToolLoop(...)` call inside the
`tools && Object.keys(tools).length > 0` branch to pass the `onStepFinish`
callback alongside the existing `onChunk`, `onToolCall`, `onReasoning`,
`onToolResult`, and `signal` options, keeping the `executeToolLoop` and
`Minimax` service wiring consistent.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: bbc6fec9-e00e-41b7-84cc-26f820f362d0
📒 Files selected for processing (18)
apps/supercode-cli/server/package.jsonapps/supercode-cli/server/src/cli/ai/chat/chat.tsapps/supercode-cli/server/src/cli/ai/chat/step-status-row.tsapps/supercode-cli/server/src/cli/ai/chat/thinking.tsapps/supercode-cli/server/src/cli/ai/concentrate-service.tsapps/supercode-cli/server/src/cli/ai/context-windows.tsapps/supercode-cli/server/src/cli/ai/google-service.tsapps/supercode-cli/server/src/cli/ai/minimax-service.tsapps/supercode-cli/server/src/cli/ai/nvidia-service.tsapps/supercode-cli/server/src/cli/ai/openrouter-service.tsapps/supercode-cli/server/src/cli/ai/provider.tsapps/supercode-cli/server/src/cli/ai/server-proxy-service.tsapps/supercode-cli/server/src/cli/ai/tool-executor.tsapps/supercode-cli/server/src/cli/commands/slashCommands/help.tsapps/supercode-cli/server/src/cli/commands/slashCommands/model.tsapps/supercode-cli/server/src/config/nvidia.config.tsapps/supercode-cli/server/src/index.tsapps/supercode-cli/server/src/lib/pricing.ts
| statusRow.stop() | ||
| activeStatusRow = null |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
Clear activeChain on abort cleanup.
The success and non-abort error paths clear activeChain, but the abort path leaves it pointing at the cancelled turn.
Proposed fix
}
statusRow.stop()
activeStatusRow = null
+ activeChain = null
md.end()📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| statusRow.stop() | |
| activeStatusRow = null | |
| statusRow.stop() | |
| activeStatusRow = null | |
| activeChain = null |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@apps/supercode-cli/server/src/cli/ai/chat/chat.ts` around lines 427 - 428,
The abort cleanup path in the chat flow leaves activeChain pointing at the
cancelled turn while the success and non-abort error paths already clear it.
Update the abort handling near the statusRow.stop/activeStatusRow cleanup in
chat.ts to also reset activeChain to null/undefined, matching the existing
cleanup behavior used elsewhere in the same turn execution flow.
| // Ctrl+T — toggle the most recently printed Thought block (collapsed ↔ expanded). | ||
| // Cheap in-place redraw: clear the line at the current cursor, rewrite the | ||
| // chevron + body in the new state, then move the cursor back down. Only | ||
| // works on a TTY because the rendered Thought blocks live in ANSI scrollback. | ||
| if (key.ctrl && key.name === "t" && process.stdout.isTTY && activeChain) { |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
Move Ctrl+T handling before the stdinResolve guard.
This block is currently after if (!stdinResolve) return, but during streaming the input promise has already resolved, so Ctrl+T cannot reach activeChain while it is active. Move this handler above the “No input handler active” return.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@apps/supercode-cli/server/src/cli/ai/chat/chat.ts` around lines 741 - 745,
The Ctrl+T toggle in chat.ts is placed too late, after the stdinResolve early
return, so it never runs while streaming when activeChain is available. Move the
Ctrl+T handling in the keypress flow above the “No input handler active” guard,
keeping the existing activeChain check and redraw behavior intact so the thought
toggle works during active streaming.
| process.stdout.write("\x1b7") | ||
| process.stdout.write("\r\x1b[2K") | ||
| process.stdout.write(`${leftBorder} ${inner} ${fillLine}`) | ||
| process.stdout.write("\x1b8") |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | 🏗️ Heavy lift
Reserve a stable row before repainting the status line.
render() clears/writes the current cursor row from timer callbacks, but this component “reserves no row”. During streaming, the current cursor is also used by markdown/tool output, so the status timer can overwrite response text or leave artifacts. Mount a dedicated row or delegate positioning to the persistent footer before clearing/writing.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@apps/supercode-cli/server/src/cli/ai/chat/step-status-row.ts` around lines
156 - 159, The `render()` logic in `step-status-row` is writing directly to the
current cursor row from timer callbacks without reserving a fixed line, which
can overwrite streaming markdown/tool output. Update the status rendering flow
so `StepStatusRow` uses a dedicated persisted row (or delegates row placement to
the persistent footer) before calling the clear/write sequence, and keep the
cursor positioning stable within `render()` and its caller setup.
| beginAndPrint(): ThoughtEntry | null { | ||
| if (!process.stdout.isTTY) return null | ||
| const entry = this.begin() | ||
| entry.openInProgress = true |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
Make beginAndPrint() idempotent while a step is open.
chat.ts calls this for every tool call in a step, but this implementation always starts a new ThoughtEntry. Multiple tool calls in one AI step will leave earlier live blocks visually unclosed and only collapse the last one.
Proposed fix
beginAndPrint(): ThoughtEntry | null {
if (!process.stdout.isTTY) return null
+ if (this.current?.openInProgress) return this.current
const entry = this.begin()
entry.openInProgress = true📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| beginAndPrint(): ThoughtEntry | null { | |
| if (!process.stdout.isTTY) return null | |
| const entry = this.begin() | |
| entry.openInProgress = true | |
| beginAndPrint(): ThoughtEntry | null { | |
| if (!process.stdout.isTTY) return null | |
| if (this.current?.openInProgress) return this.current | |
| const entry = this.begin() | |
| entry.openInProgress = true |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@apps/supercode-cli/server/src/cli/ai/chat/thinking.ts` around lines 413 -
416, `ThoughtTree.beginAndPrint()` should not create a new `ThoughtEntry` when a
step is already open, since `chat.ts` may call it multiple times per AI step.
Add an idempotent guard in `beginAndPrint()` (and, if needed, reuse the current
open entry from the tree state) so repeated calls return the existing live block
instead of starting another one. Keep the behavior in sync with
`begin()`/`openInProgress` so only one thought block is active until it is
closed.
| // keepExpanded (e.g. when a tool was denied/empty) wins over autoCollapse. | ||
| entry.collapsed = | ||
| entry.hadFlaggedTool ? false : (opts?.autoCollapse ?? true) |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
Honor the keepExpanded option.
The comment and signature expose keepExpanded, but entry.collapsed only checks hadFlaggedTool, so callers cannot force expansion unless a tool was flagged.
Proposed fix
// keepExpanded (e.g. when a tool was denied/empty) wins over autoCollapse.
entry.collapsed =
- entry.hadFlaggedTool ? false : (opts?.autoCollapse ?? true)
+ entry.hadFlaggedTool || opts?.keepExpanded ? false : (opts?.autoCollapse ?? true)📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| // keepExpanded (e.g. when a tool was denied/empty) wins over autoCollapse. | |
| entry.collapsed = | |
| entry.hadFlaggedTool ? false : (opts?.autoCollapse ?? true) | |
| // keepExpanded (e.g. when a tool was denied/empty) wins over autoCollapse. | |
| entry.collapsed = | |
| entry.hadFlaggedTool || opts?.keepExpanded ? false : (opts?.autoCollapse ?? true) |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@apps/supercode-cli/server/src/cli/ai/chat/thinking.ts` around lines 458 -
460, The collapse logic in thinking.ts ignores the exposed keepExpanded option,
so callers cannot force an entry to stay expanded unless hadFlaggedTool is set.
Update the entry.collapsed assignment in the chat thinking flow to explicitly
honor keepExpanded before autoCollapse, using the existing
keepExpanded/autoCollapse inputs alongside hadFlaggedTool so forced expansion
wins consistently.
| onStepFinish?: (params: { stepNumber: number; toolCalls: Array<{ toolName: string; args: unknown }>; toolResults: Array<{ toolName: string; args: unknown; result: string }> }) => void, | ||
| ) { | ||
| try { | ||
| const systemMessages = messages.filter(m => m.role === "system") | ||
| const nonSystemMessages = messages.filter(m => m.role !== "system") | ||
| const system = systemMessages.map(m => m.content).join("\n") | ||
| const onStepFinishRef = onStepFinish |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
Propagate the new onStepFinish callback here too.
Like the Google service, this method captures onStepFinishRef but never invokes it from the SDK's step-finish hook. That means apps/supercode-cli/server/src/cli/ai/chat/chat.ts:307-311 never gets the signal to collapse/update the per-step UI for Concentrate sessions.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@apps/supercode-cli/server/src/cli/ai/concentrate-service.ts` around lines 41
- 47, The Concentrate service is capturing onStepFinishRef but never forwarding
it from the SDK step-finish hook, so the chat UI never receives step completion
updates. Update the Concentrate flow in concentrate-service.ts to wire the SDK’s
step-finish callback through to onStepFinishRef, matching the behavior already
used by the Google service. Make sure the callback is invoked with the step
number, toolCalls, and toolResults so chat.ts can collapse/update the per-step
UI correctly.
| onStepFinish?: (params: { stepNumber: number; toolCalls: Array<{ toolName: string; args: unknown }>; toolResults: Array<{ toolName: string; args: unknown; result: string }> }) => void, | ||
| ) { | ||
| try { | ||
| const systemMessages = messages.filter(m => m.role === "system") | ||
| const nonSystemMessages = messages.filter(m => m.role !== "system") | ||
| const system = systemMessages.map(m => m.content).join("\n") | ||
| const onStepFinishRef = onStepFinish |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
Forward onStepFinish instead of just capturing it.
This method now exposes the callback, but the streamText step handler below never calls onStepFinishRef. For Google-backed turns, apps/supercode-cli/server/src/cli/ai/chat/chat.ts:307-311 will never receive the step-finish signal that closes the live Thought block and advances the status row.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@apps/supercode-cli/server/src/cli/ai/google-service.ts` around lines 55 - 61,
The Google service method is capturing onStepFinish but not forwarding it into
the step handler, so the chat flow never receives step-finish updates. Update
google-service’s streamText step handling to invoke onStepFinishRef with the
step details when a step completes, using the existing onStepFinish parameter
and its callback shape. Keep the fix localized around the streamText handler and
the onStepFinishRef usage so apps/supercode-cli/server/src/cli/ai/chat/chat.ts
can close the Thought block and advance the status row.
| // Notify chat loop of step finish (OpenRouter uses a manual polling | ||
| // loop, so each iteration is a "step" for our purposes). | ||
| if (onStepFinish && result.toolCalls.length > 0) { | ||
| onStepFinish({ | ||
| stepNumber: toolCallsThisTurn, | ||
| toolCalls: result.toolCalls.map((c: any) => ({ toolName: c.toolName, args: c.args })), | ||
| toolResults: result.toolCalls.map((c: any) => { | ||
| const tr = allToolResults.find((r) => r.toolName === c.toolName) | ||
| return { | ||
| toolName: c.toolName, | ||
| args: c.args, | ||
| result: tr?.result ?? "", | ||
| } | ||
| }), | ||
| }) |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
Use a real step index here, not the cumulative tool-call count.
toolCallsThisTurn grows with tool invocations, so a single step that emits multiple tools reports stepNumber 2/3/... instead of 1. apps/supercode-cli/server/src/cli/ai/chat/chat.ts:307-311 uses that value as the completed step count, so the live status row will skip numbers for multi-tool steps.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@apps/supercode-cli/server/src/cli/ai/openrouter-service.ts` around lines 315
- 329, The step completion callback in openrouter-service is using the
cumulative tool-call count as stepNumber, which causes multi-tool iterations to
report the wrong step index. Update the onStepFinish payload in the step-finish
block to use the actual per-iteration step index for the current loop execution,
and keep toolCalls/toolResults mapping unchanged. Use the onStepFinish call site
and the surrounding manual polling loop in openrouter-service to locate the fix,
since chat.ts consumes stepNumber as the completed step count.
|
|
||
| // Per-step finish notification for the chat loop's live per-step UI. | ||
| if (onStepFinish && result.toolCalls.length > 0) { | ||
| onStepFinish({ | ||
| stepNumber: this.collectedToolCalls.length, | ||
| toolCalls: result.toolCalls.map((c: any) => ({ toolName: c.toolName, args: c.args })), | ||
| toolResults: stepResults, | ||
| }) | ||
| } |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
Report the step index here, not total tool calls.
this.collectedToolCalls.length is a cumulative tool-call counter, so the first completed step can already report 2 when the model requested two tools at once. The chat UI in apps/supercode-cli/server/src/cli/ai/chat/chat.ts:307-311 treats this as the step count and will show skipped numbers.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@apps/supercode-cli/server/src/cli/ai/server-proxy-service.ts` around lines
192 - 200, The per-step finish callback in server-proxy-service should report
the current step index instead of the cumulative tool-call count. Update the
onStepFinish payload in the step-completion block to use the step’s position for
stepNumber, not this.collectedToolCalls.length, so the chat UI in chat.ts
receives sequential step numbers even when multiple tools are requested in one
step.
| // Per-step finish notification — used by the chat loop to close | ||
| // and auto-collapse the live per-step Thought block. | ||
| if (callbacks.onStepFinish && toolCalls.length > 0) { | ||
| callbacks.onStepFinish({ | ||
| stepNumber: iter, | ||
| toolCalls: toolCalls.map((tc) => ({ toolName: tc.toolName, args: tc.args })), | ||
| toolResults: allToolResults.slice(-toolCalls.length).map((r) => ({ | ||
| toolName: r.toolName, | ||
| args: toolCalls.find((tc) => tc.toolName === r.toolName)?.args ?? {}, | ||
| result: r.result, | ||
| })), | ||
| }) |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win
Preserve per-call result args and use a 1-based step count.
stepNumber: iter reports the first completed step as 0, and find() by toolName assigns the first matching args to every same-named tool result. Keep a current-iteration result list while executing tools and emit iter + 1.
Proposed fix
// Execute each tool call
+ const currentToolResults: Array<{ toolName: string; args: unknown; result: string }> = []
for (const tc of toolCalls) {
callbacks.onToolCall?.({ toolName: tc.toolName, args: tc.args })
@@
allToolResults.push({ toolName: tc.toolName, result: resultStr })
+ currentToolResults.push({ toolName: tc.toolName, args: tc.args, result: resultStr })
@@
if (callbacks.onStepFinish && toolCalls.length > 0) {
callbacks.onStepFinish({
- stepNumber: iter,
+ stepNumber: iter + 1,
toolCalls: toolCalls.map((tc) => ({ toolName: tc.toolName, args: tc.args })),
- toolResults: allToolResults.slice(-toolCalls.length).map((r) => ({
- toolName: r.toolName,
- args: toolCalls.find((tc) => tc.toolName === r.toolName)?.args ?? {},
- result: r.result,
- })),
+ toolResults: currentToolResults,
})
}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| // Per-step finish notification — used by the chat loop to close | |
| // and auto-collapse the live per-step Thought block. | |
| if (callbacks.onStepFinish && toolCalls.length > 0) { | |
| callbacks.onStepFinish({ | |
| stepNumber: iter, | |
| toolCalls: toolCalls.map((tc) => ({ toolName: tc.toolName, args: tc.args })), | |
| toolResults: allToolResults.slice(-toolCalls.length).map((r) => ({ | |
| toolName: r.toolName, | |
| args: toolCalls.find((tc) => tc.toolName === r.toolName)?.args ?? {}, | |
| result: r.result, | |
| })), | |
| }) | |
| // Execute each tool call | |
| const currentToolResults: Array<{ toolName: string; args: unknown; result: string }> = [] | |
| for (const tc of toolCalls) { | |
| callbacks.onToolCall?.({ toolName: tc.toolName, args: tc.args }) | |
| // ...existing execution logic... | |
| allToolResults.push({ toolName: tc.toolName, result: resultStr }) | |
| currentToolResults.push({ toolName: tc.toolName, args: tc.args, result: resultStr }) | |
| } | |
| // Per-step finish notification — used by the chat loop to close | |
| // and auto-collapse the live per-step Thought block. | |
| if (callbacks.onStepFinish && toolCalls.length > 0) { | |
| callbacks.onStepFinish({ | |
| stepNumber: iter + 1, | |
| toolCalls: toolCalls.map((tc) => ({ toolName: tc.toolName, args: tc.args })), | |
| toolResults: currentToolResults, | |
| }) | |
| } |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@apps/supercode-cli/server/src/cli/ai/tool-executor.ts` around lines 164 -
175, The per-step finish payload in tool-executor’s onStepFinish block is using
a zero-based step index and losing per-call argument pairing for repeated tool
names. Update the step emission to report a 1-based step count from iter, and
build toolResults from the current iteration’s executed calls/results so each
result keeps its own args instead of using find() by toolName.
minimaxai/minimax-m2.7tominimaxai/minimax-m3across various services and configurations.onStepFinishcallback in multiple AI service classes to enhance step tracking during tool execution.StepStatusRowclass for live status updates during AI operations, improving user feedback in the CLI.Summary by CodeRabbit
New Features
/verbosecommand for more detailed tool logging.Bug Fixes
Updates