feat: [ENG-2123] brv curate view / brv query-log view truncate long c…

[bao-byterover]

No description provided.

[github-actions]

Claude finished @bao-byterover's task in 2m 0s —— View job

---

PR Review: feat: [ENG-2123] brv curate view / brv query-log view — remove truncation in detail view

• Gather context and read changed files
• Analyze code changes for correctness, security, and quality
• Post inline comments for specific issues
• Post general summary with overall score

---

Summary

This PR removes truncation from the detail view (brv curate view <id> and brv query-log view <id>) for both context (was capped at 200 chars) and response (was capped at 500 chars). The list/table view still correctly truncates the query column to fit column width — that truncate() usage is intentional and untouched.

The changes are small, correct, and properly tested using TDD. Tests were updated before or alongside the implementation changes, following the project's strict TDD requirement.

---

Findings

Correctness — No bugs introduced. The logic simplification is straightforward: remove inline .slice()/truncate() calls and let the string pass through directly.

Security — No concerns. This is terminal output formatting with no user input reaching execution paths.

Dead import — truncate in query-log-use-case.ts is not dead; it's still used in showList() for the query column. Import is fine.

Inline comments posted:

• query-log-use-case.ts:118 — multiline response indentation: only the first line gets the two-space indent when entry.response contains \n (suggestion, non-blocking)
• curate-log-use-case.ts:113 — same multiline indentation concern for context (suggestion, non-blocking)
• curate-log-use-case.test.ts:247 — semantic mismatch using makeProcessingEntry to test context display (nitpick, non-blocking)

Minor observation — PR title: The title reads "truncate long content" but the actual change removes truncation. The intent is clear from the diff, but the wording is inverted. Not a blocker.

---

Overall Score: 4 / 5

Clean, focused, well-tested change. The only non-trivial concern is the multiline indentation gap now exposed by removing truncation — worth a follow-up if responses or context values are ever multi-line in practice.

[github-actions]

suggestion (non-blocking): If entry.response contains newlines, only the first line will receive the two-space indent. This was less visible before since truncation would clip multi-paragraph responses. You may want to indent every line:

Suggested change

	this.log(` ${entry.response}`)
	this.log(entry.response.split('\n').map(line => ` ${line}`).join('\n'))

Low priority — depends on whether responses are ever multi-line in practice.

[github-actions]

Claude finished @bao-byterover's task in 2m 6s —— View job

---

PR Review: feat: [ENG-2123] brv curate view / brv query-log view — multi-line indentation fix

• Gather context and read changed files
• Analyze code changes for correctness, security, and quality
• Post inline comments for specific issues
• Post general summary with overall score

---

Summary

This revision directly addresses all three suggestions raised in the previous review cycle:

Previous concern	Resolved?
query-log-use-case.ts — only first line of response was indented	✅ Fixed with split/map/join
curate-log-use-case.ts — only first line of context was indented	✅ Fixed with split + multi-call loop
curate-log-use-case.test.ts — makeProcessingEntry semantic mismatch	✅ Replaced with makeCompletedEntry

New tests (4 added across both test files) cover the corrected behaviour: full content with no truncation, correct header label (Response: not Response (truncated):), and proper two-space indentation of every continuation line.

---

Findings

Correctness — All changes are correct. Both the split-and-loop pattern (context) and the split/map/join pattern (response) produce identical terminal output. No regressions.

Security — No concerns. Terminal formatting, no execution paths.

Dead import — truncate in query-log-use-case.ts is still used in showList() at line 167 (truncate(entry.query, queryWidth)). Import is fine.

Inline comment posted:

• curate-log-use-case.ts:141 — minor style inconsistency: context uses multi-call approach, response uses single-call with embedded \n. Both produce the same output; just a consistency note, non-blocking.

No other issues found.

---

Overall Score: 5 / 5

All previous feedback addressed. The implementation is clean, correct, and well-tested. The only note is a cosmetic style inconsistency between the two multi-line formatting approaches within curate-log-use-case.ts, which has no behavioural impact.