[terminal-stylist] Terminal Stylist: Console Output Analysis — pkg/ (Lipgloss, Huh, Bubble Tea)

[github-actions[bot]]

Summary

988 non-test Go files scanned across pkg/. Console output is highly consistent: the codebase has a mature, well-structured pkg/console package that wraps all Charmbracelet ecosystem interactions (Lipgloss, Huh, Bubble Tea, Bubbles). Direct fmt.Print* calls to os.Stdout/os.Stderr outside this package are minimal and deliberate.

---

Key Metrics

Metric	Count
Total non-test .go files in pkg/	988
Files in pkg/cli/ using console package	167
Files using huh interactively in pkg/cli/	9
Files using lipgloss directly in pkg/cli/	4 (2 meaningful)
Raw fmt.Print* to os.Stdout (not via console)	3
Hardcoded ANSI escape sequences outside console/	0
Hardcoded lipgloss.Color(...) outside styles/	0

---

Architecture Overview

The codebase follows a clean three-layer output architecture:

pkg/styles/      ← Adaptive color palette + Huh theme (Dracula-inspired)
pkg/console/     ← All terminal rendering logic (Lipgloss, Huh, Bubble Tea)
pkg/cli/         ← Business logic; calls console.* for all user-facing output

Lipgloss Usage Analysis

Strengths ✅

pkg/styles/theme.go defines a complete adaptive color system:

• All colors use a custom adaptiveColor type implementing color.Color with Light/Dark variants
• Light variants use darker/saturated colors; Dark variants use Dracula theme colors (e.g., #FF5555, #BD93F9)
• Windows safety: background probing is skipped on Windows to avoid ConPTY crashes
• Full semantic palette: ColorError, ColorWarning, ColorSuccess, ColorInfo, ColorPurple, ColorYellow, ColorComment, ColorForeground, ColorBackground, ColorBorder, ColorTableAltRow
• Pre-configured styles for all common cases: Error, Warning, Success, Info, FilePath, LineNumber, Command, Progress, Prompt, Verbose, ListItem, TableHeader, TableCell, Header, TreeEnumerator, etc.

pkg/styles/huh_theme.go provides a HuhTheme huh.ThemeFunc that:

• Uses lipgloss.LightDark() from Lipgloss v2 for proper adaptive rendering
• Maps the full pkg/styles palette to every Huh field state (focused, blurred, buttons, text input cursor/placeholder)
• Ensures forms match the CLI's visual identity

pkg/console/console.go correctly gates all styling through applyStyle():

• applyStyle / applyStyleWithTTY check TTY status before rendering ANSI
• Both stdout and stderr TTY checks available (isTTY / isStderrTTY)
• RenderTable correctly passes TTYFunc override for caller-controlled output stream

pkg/console/progress.go uses bubbles/v2/progress with:

• Scaled color blend (purple → cyan) with WithScaled(true) for progressive visual feedback
• Determinate and indeterminate modes, both with non-TTY text fallbacks
• EmptyColor set to styles.ColorComment for visual balance

pkg/console/spinner.go uses bubbletea/v2 idiomatically:

• tea.WithInput(nil) correctly disables stdin so the spinner doesn't consume key events before Huh forms
• Thread-safe Start/Stop with mutex + WaitGroup; safe to call Stop before Start
• Respects ACCESSIBLE env var and TTY detection

pkg/console/terminal.go exposes ANSI escape constants centrally (ansiClearScreen, ansiClearLine, ansiCarriageReturn) rather than scattering them across files.

Direct lipgloss in pkg/cli/ is minimal and legitimate:

• compile_schedule_calendar.go: intensityStyle() returns a lipgloss.Style selected from styles.* constants based on schedule heatmap intensity — appropriate since this is a rendering helper returning a style, not emitting output directly.
• status_command.go: Uses lipgloss/tree for renderWorkflowDependencyTree() with styles.TreeEnumerator and styles.TreeNode — correct usage.

No Issues Found ✅

• No hardcoded lipgloss.Color("...") strings outside pkg/styles/
• No raw ANSI escape sequences (\033[) outside pkg/console/terminal.go and pkg/console/spinner.go
• No hardcoded hex colors in CLI or workflow code

Huh Form Usage Analysis

Strengths ✅

All 9 files that import charm.land/huh/v2 directly in pkg/cli/ correctly apply:

.WithTheme(styles.HuhTheme).WithAccessible(console.IsAccessibleMode())

This is consistent across all form sites:

• add_interactive_auth.go, add_interactive_git.go, add_interactive_workflow.go
• add_interactive_orchestrator.go, add_interactive_engine.go, add_interactive_schedule.go
• run_interactive.go (3 form sites), engine_secrets.go (3 form sites), interactive.go (3 form sites)

pkg/console/confirm.go and pkg/console/list.go wrap standalone huh.Confirm and huh.Select with:

• TTY detection before running interactive forms
• Graceful non-TTY fallback (text-based prompts to os.Stderr)
• Theme and accessibility wiring via WithTheme(styles.HuhTheme).WithAccessible(IsAccessibleMode())

pkg/console/input.go correctly uses huh.EchoModePassword for secret input with inline Validate for non-empty check.

Observation (not an issue)

Multi-field forms in pkg/cli/ use huh directly rather than routing through pkg/console wrapper functions. This is acceptable: the console wrappers are for simple standalone prompts (single confirm/select/input); complex multi-field forms with custom validation and groups are correctly kept in the CLI layer where the business logic lives.

Raw fmt.Print* Usage (Outside console package)

Only 3 instances of fmt.Print* writing to stdout (not stderr) without a console.* wrapper were found in non-test production CLI files:

File	Line	Pattern	Assessment
pkg/cli/view_command.go:168	fmt.Print(output)	Prints pre-rendered timeline string	✅ Acceptable — output is already fully formatted by renderUnifiedTimelineStream()
pkg/cli/status_command.go:288	fmt.Print(console.RenderStruct(statuses))	Table via console.RenderStruct	✅ Acceptable — rendered by console package
pkg/cli/logs_report.go:551	fmt.Print(console.RenderStruct(data))	Table via console.RenderStruct	✅ Acceptable — rendered by console package

All 3 are fmt.Print(console.Render*(...)) — the content is still produced by the console package; only the final write to stdout bypasses a console wrapper. This is idiomatic in Go CLI tools.

All other fmt.Print* calls go to os.Stderr for informational/verbose/status messages, consistently wrapped through console.FormatInfoMessage, console.FormatWarningMessage, console.FormatSuccessMessage, etc.

The linter test files under pkg/linters/*/testdata/ that contain fmt.Println are intentional lint target programs, not production code.

Message Type Consistency

The console package provides a complete and consistently-used set of message formatters:

Function	Prefix	Color
FormatSuccessMessage	✓	Bold green
FormatInfoMessage	i	Bold cyan
FormatWarningMessage	⚠	Bold orange
FormatErrorMessage	✗	Bold red
FormatProgressMessage	▸	Yellow
FormatCommandMessage	$	Bold purple
FormatVerboseMessage	»	Italic muted
FormatPromptMessage	?	Bold green

These are used consistently throughout pkg/cli/ for all user-facing output. No files were found emitting raw status strings like "Error: ..." or "✓ done" without going through these helpers.

FormatErrorChain correctly handles wrapped error chains (via errors.Unwrap) and multi-line errors (from errors.Join) with consistent indentation for continuation lines.

---

Recommendations

The codebase is in excellent shape. The following are minor enhancement opportunities, not bugs or inconsistencies:

1. Consider console.FormatListItem for the safe-outputs summary in view_command.go

renderViewSafeOutputs in view_command.go:208 builds item lines manually (" " + item.Type). Using console.FormatListItem(item.Type + " " + url) would apply the styles.ListItem styling and the bullet prefix • consistently with other list outputs.

2. pkg/console/terminal.go ShowWelcomeBanner uses raw fmt.Fprintln(os.Stderr, header) for the header string

The TTY-gated styles.Header.Render(header) is applied correctly, but it is assigned to a local string then passed to fmt.Fprintln. This is fine as-is, but a future refactor could use console.FormatSectionHeader() for parity with other header output.

3. No non-TTY fallback for RenderComposedSections-style output in interactive commands

Commands that call console.ShowWelcomeBanner and console.RenderComposedSections already handle non-TTY correctly. No action needed.

4. compile_schedule_calendar.go:252 calls styles.TableHeader.Render(header) directly

This is the one place in pkg/cli/ that renders a style directly (not via a console.* helper). It could use console.FormatSectionHeader() for strict consistency, though the current approach is correct and intentional.

---

References

Workflow run: §28580475513

Generated by 💄 Terminal Stylist · 90.6 AIC · ⌖ 11.4 AIC · ⊞ 5.7K · ◷

• expires on Jul 3, 2026, 1:48 AM UTC-08:00