Improve agent log parsing

[gjkim42]

What type of PR is this?

/kind bug

What this PR does / why we need it:

Improves agent log parsing for OpenCode JSON streams that emit nested step, tool, and token events. kelos logs now shows OpenCode step boundaries, tool summaries, usage, truncation, and non-zero exits without dumping full tool output.

This also updates reporting progress/activity and result capture so nested OpenCode text is recognized, and Gemini capture accepts total token stats.

Which issue(s) this PR is related to:

N/A

Special notes for your reviewer:

Validation:

• make test
• make verify
• git diff --check

Does this PR introduce a user-facing change?

Improve agent log parsing for OpenCode JSON streams so kelos logs, progress/activity reporting, and captured task responses handle nested OpenCode events.

---

Summary by cubic

Improves agent log parsing for OpenCode JSON streams. kelos logs now shows clear step boundaries, concise tool summaries, and usage stats without dumping noisy tool output; progress/activity and captured responses handle nested OpenCode text, and Gemini usage accepts total token stats.

• New Features
  • Print numbered step boundaries (“--- Step N ---”) for OpenCode runs.
  • Summarize tool_use events (bash/shell, read/write/edit, grep/glob, webfetch, websearch), include non‑zero exit and truncated, and suppress full tool output.
  • Emit [usage] on step_finish with input, cached, output, plus reasoning, cache_write, and total when present.
  • Parse nested OpenCode text for progress/activity and final response capture; accept Gemini totalInputTokens and totalOutputTokens in usage extraction.

^{Written for commit 76da819. Summary will update on new commits.}

[cubic-dev-ai]

2 issues found across 8 files

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="internal/cli/logparser_opencode.go">

<violation number="1" location="internal/cli/logparser_opencode.go:140">
P3: The new `openCodeToolInputSummary` is a near-verbatim duplicate of the existing `toolInputSummary` in internal/cli/logparser.go — same tool set, same field keys, same newline collapsing, and the same `maxSummaryLen` truncation. Only the tool-name casing differs. Consider consolidating into one shared helper (e.g., case-normalize the tool name inside `toolInputSummary`) so future tool/field additions don't have to be maintained in two places and risk drift.</violation>
</file>

<file name="internal/reporting/activity.go">

<violation number="1" location="internal/reporting/activity.go:364">
P2: `openCodeToolActivity` is a near-verbatim copy of the existing `claudeToolActivity` switch (same `bash`/`read`/`write`/`edit`/`grep`/`glob`/`webfetch`/`websearch` cases, identical message strings and `truncateActivity`/`shortenPath` calls, and an identical `default` branch). The two differ only in tool-name casing (`strings.ToLower` vs exact match) and field-name spellings (`filePath` vs `file_path`). Because the message text and truncation logic are duplicated, a future wording or formatting change (e.g. the "Running `...`..." template) must be edited in two places and can drift out of sync. Consider factoring the shared per-tool message/truncation logic into one helper that both Claude and OpenCode paths call, keeping only the tool-name/field mapping local.</violation>
</file>

<sub>Reply with feedback, questions, or to request a fix.

Re-trigger cubic</sub>

[cubic-dev-ai]

P2: openCodeToolActivity is a near-verbatim copy of the existing claudeToolActivity switch (same bash/read/write/edit/grep/glob/webfetch/websearch cases, identical message strings and truncateActivity/shortenPath calls, and an identical default branch). The two differ only in tool-name casing (strings.ToLower vs exact match) and field-name spellings (filePath vs file_path). Because the message text and truncation logic are duplicated, a future wording or formatting change (e.g. the "Running ......" template) must be edited in two places and can drift out of sync. Consider factoring the shared per-tool message/truncation logic into one helper that both Claude and OpenCode paths call, keeping only the tool-name/field mapping local.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At internal/reporting/activity.go, line 364:

<comment>`openCodeToolActivity` is a near-verbatim copy of the existing `claudeToolActivity` switch (same `bash`/`read`/`write`/`edit`/`grep`/`glob`/`webfetch`/`websearch` cases, identical message strings and `truncateActivity`/`shortenPath` calls, and an identical `default` branch). The two differ only in tool-name casing (`strings.ToLower` vs exact match) and field-name spellings (`filePath` vs `file_path`). Because the message text and truncation logic are duplicated, a future wording or formatting change (e.g. the "Running `...`..." template) must be edited in two places and can drift out of sync. Consider factoring the shared per-tool message/truncation logic into one helper that both Claude and OpenCode paths call, keeping only the tool-name/field mapping local.</comment>

<file context>
@@ -349,12 +349,67 @@ func extractOpenCodeActivity(r io.Reader) string {
 	return lastActivity
 }
 
+func openCodeToolActivity(toolName string, raw json.RawMessage) string {
+	var input map[string]interface{}
+	if len(raw) > 0 {
</file context>

[cubic-dev-ai]

P3: The new openCodeToolInputSummary is a near-verbatim duplicate of the existing toolInputSummary in internal/cli/logparser.go — same tool set, same field keys, same newline collapsing, and the same maxSummaryLen truncation. Only the tool-name casing differs. Consider consolidating into one shared helper (e.g., case-normalize the tool name inside toolInputSummary) so future tool/field additions don't have to be maintained in two places and risk drift.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At internal/cli/logparser_opencode.go, line 140:

<comment>The new `openCodeToolInputSummary` is a near-verbatim duplicate of the existing `toolInputSummary` in internal/cli/logparser.go — same tool set, same field keys, same newline collapsing, and the same `maxSummaryLen` truncation. Only the tool-name casing differs. Consider consolidating into one shared helper (e.g., case-normalize the tool name inside `toolInputSummary`) so future tool/field additions don't have to be maintained in two places and risk drift.</comment>

<file context>
@@ -52,28 +77,126 @@ func ParseAndFormatOpenCodeLogs(r io.Reader, stdout, stderr io.Writer) error {
+	return strings.Join(fields, ", ")
+}
+
+func openCodeToolInputSummary(toolName string, raw json.RawMessage) string {
+	if len(raw) == 0 {
+		return ""
</file context>