docs/cloud-billing-guide.md (1)

13-19: Consider verifying pricing URLs periodically.

The official pricing links are valuable references. Since pricing pages can change URLs over time, consider adding a note to verify these links if the guide hasn't been updated recently, or integrate link checking into CI.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@docs/cloud-billing-guide.md` around lines 13 - 19, Add a short note under the
"## Official Pricing References" section advising readers to periodically verify
the listed pricing URLs (Anthropic/Claude, Google/Gemini, OpenAI) because
pricing pages can change, and optionally mention enabling automated
link-checking in CI to catch broken/updated links; update the markdown near the
existing list items to include this verification guidance.

personas/onboarding-guide.md (1)

76-78: Curl-pipe-to-shell pattern has inherent risks.

While curl -fsSL https://ollama.com/install.sh | sh is the official Ollama installation method, curl-pipe-to-shell is generally discouraged for security-conscious users. Consider adding a note about verifying the script or pointing to Ollama's documentation for alternative installation methods.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@personas/onboarding-guide.md` around lines 76 - 78, Replace the raw
curl-pipe-to-shell install suggestion with a safer note: keep the existing
commands but add a short caution after the Linux line explaining the security
risks of piping remote scripts into sh and advise users to inspect the script
first (e.g., curl -fsSL https://ollama.com/install.sh -o install.sh && less
install.sh) or to follow alternative installation methods linked on Ollama's
official docs page; ensure the snippet still lists the macOS brew/download
options and add a link to Ollama's installation documentation for
verification/alternatives.

tools/tui/main.go (2)

762-789: Consider log rotation for unbounded file growth.

The task log file (~/.config/nexus/logs/mcp-tasks.jsonl) will grow indefinitely. While capping display to 50 entries is good for the UI, the file itself could become large over time.

Consider adding log rotation (e.g., truncate to last N entries periodically, or rotate by date) in a future iteration.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@tools/tui/main.go` around lines 762 - 789, loadTaskLog currently reads the
entire mcp-tasks.jsonl file without bounding its on-disk size; implement simple
rotation/truncation to prevent unbounded growth by trimming the file to the last
N lines (e.g., 5000) or rotating by date whenever the file exceeds a size
threshold. Inside loadTaskLog or a helper referenced from it (use logFile,
loadTaskLog, taskLogEntry, taskLogMsg to locate), detect file size/line count,
read only the tail (last N lines) or read all and then write back only the tail
to the same path (atomic write via temp file + rename) to truncate/rotate;
ensure concurrent reads are safe by using a temp file + os.Rename and preserve
file permissions.

---

119-141: Apple Silicon detection may false-positive on Intel Macs.

The system_profiler SPHardwareDataType command will succeed on Intel Macs, but won't have the "Chip:" line. However, if "Memory:" is found without "Chip:", the function returns an empty info.Name which correctly triggers the if info.Name != "" check at line 138, falling through to AMD detection.

The logic is correct, but consider adding a check for Intel processors to return early, or document that Intel Macs will fall through to "unknown" platform.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@tools/tui/main.go` around lines 119 - 141, The system_profiler parsing block
can misclassify Intel Macs as Apple Silicon when only Memory is present; update
the parsing in tools/tui/main.go (the gpuInfo parsing block that sets
info.Platform = "apple") to detect Intel-specific lines (e.g., lines starting
with "Processor Name:" or containing "Intel") and, when found, set info.Platform
= "intel" and return that info (or return an "unknown" platform sentinel)
immediately so Intel machines don't fall through as Apple; reference the gpuInfo
struct and the parsing block that checks "Chip:" and "Memory:" to implement this
early-detection/early-return behavior.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

personas/onboarding-guide.md (1)

77-80: Prefer the inspected installer path as the default recommendation.

You already include a security note; make the inspect-first flow the primary command and keep curl | sh as an explicitly “quick path” alternative.

As per coding guidelines personas/**: Review persona files for PII, hardcoded secrets, prompt injection patterns, and unsafe command examples.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@personas/onboarding-guide.md` around lines 77 - 80, Change the onboarding
guide to make the inspect-first installer the primary recommendation and
relegate the curl|sh shortcut to a clearly labeled "quick path" alternative:
replace the current primary Linux line `curl -fsSL https://ollama.com/install.sh
| sh` with the inspected flow `curl -fsSL https://ollama.com/install.sh -o
install.sh && less install.sh && sh install.sh`, keep the original piped command
but move it under a "Quick install (less secure)" note, and preserve the
existing security note text. Also scan the personas files for PII/hardcoded
secrets, prompt-injection patterns, and other unsafe command examples as per the
personas/** guidelines and remove or remediate any findings.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

tools/tui/main.go (2)

107-117: NVIDIA detection: Consider handling multi-GPU and malformed output.

If the system has multiple GPUs, nvidia-smi returns multiple lines. The current code only parses the first line (correct behavior), but if the output format differs (e.g., comma in GPU name), SplitN(..., 2) may misparse.

Additionally, if parts[1] doesn't parse as an integer, mem stays 0, which would cause incorrect model recommendations (the ≤4GB tier).

This is a minor edge case since the fallback is safe, but worth noting.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@tools/tui/main.go` around lines 107 - 117, The NVIDIA parsing code should
handle multi-line output and malformed names: read the command output, pick the
first non-empty line, and split the GPU name and memory by the last comma (not
SplitN) to avoid breaking when the name contains commas; parse memory with
strconv.Atoi and check the error before using it (fall back to 0 only on parse
failure). Update the block around exec.Command(...) that produces line/parts and
the mem variable and return path that builds gpuInfo (referencing the
exec.Command call, the line variable, the parts split logic, the mem integer,
and the gpuInfo return) to implement these fixes.

---

838-852: Long tool/model names may break column alignment.

The %-24s and %-22s format specifiers left-align but don't truncate. If a tool or model name exceeds these widths, the table columns will misalign.

Consider truncating long values:

♻️ Optional: truncate long values for consistent alignment

+func truncateStr(s string, max int) string {
+	if len(s) > max {
+		return s[:max-1] + "…"
+	}
+	return s
+}
+
 // In taskLogView:
-s += fmt.Sprintf("  %-24s %-22s %8s  %s  %s\n",
-	e.Tool, e.Model, dur, status, m.styles.subtle.Render(ts))
+s += fmt.Sprintf("  %-24s %-22s %8s  %s  %s\n",
+	truncateStr(e.Tool, 24), truncateStr(e.Model, 22), dur, status, m.styles.subtle.Render(ts))

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@tools/tui/main.go` around lines 838 - 852, Long tool/model names in the table
break alignment because fmt.Sprintf uses "%-24s" and "%-22s" without truncation;
update the rendering to truncate e.Tool to 24 characters and e.Model to 22
characters (e.g., add a small helper like truncate(s, n) or inline substring
logic) before passing them into fmt.Sprintf in the loop over m.taskLog so the
columns remain aligned; reference e.Tool, e.Model and the fmt.Sprintf call that
builds the line and ensure truncation appends an ellipsis or simply cuts to the
specified width to preserve alignment.

tools/tui/main.go (1)

778-785: ⚠️ Potential issue | 🟠 Major

Keep task-log rotation out of the TUI or make it atomic.

This read/trim/write/rename sequence can still drop concurrent appends from the MCP server, and os.Rename is still unchecked. Since this process is only a reader, the safest fix is to stop rotating here or guard the whole sequence with a real lock and checked filesystem operations.

As per coding guidelines, **/*.go: Review Go code for error handling, resource leaks, and adherence to Bubbletea v2 patterns. This is a TUI application using the Charm ecosystem.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@tools/tui/main.go` around lines 778 - 785, The log-rotation snippet that
reads/trims/writes/renames (using maxLines, lines, tmp, os.WriteFile and
os.Rename against logFile) can drop concurrent appends and ignores errors;
either remove/disable this rotation from the TUI reader entirely (since this
process should only read logs), or make it atomic and safe: acquire a
filesystem/process-level lock around the entire read-trim-write-rename sequence,
check and handle all errors from os.ReadFile/os.WriteFile/os.Rename, write to a
temp file and fsync before rename, and only perform the rotation from a single
responsible writer (or move rotation into the MCP server) so this code in the
TUI (where lines and maxLines are used) no longer races with concurrent
appenders.

tools/tui/main.go (1)

1275-1279: Use display-width truncation here, not byte slicing.

len and s[:max-1] can split UTF-8 and still misalign columns for wide glyphs, so this only fixes ASCII cases. In this Charm/Lip Gloss UI, a width-aware truncation helper would be safer.

As per coding guidelines, **/*.go: Review Go code for error handling, resource leaks, and adherence to Bubbletea v2 patterns. This is a TUI application using the Charm ecosystem.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@tools/tui/main.go` around lines 1275 - 1279, The truncateCol function uses
byte-length and slicing which can split UTF-8 and mis-handle wide glyphs; change
truncateCol to use a display-width aware truncation (e.g.,
github.com/mattn/go-runewidth) instead of len and s[:..]. Replace the body of
truncateCol to call runewidth.Truncate(s, max, "…") (or implement a
rune-iteration that accumulates runewidth.StringWidth per rune and appends "…"
when exceeding max) so columns align correctly for multibyte and wide
characters.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes