feature-request: add 'barista config' runtime TUI for post-install reconfiguration

[pstuart]

Why

Step 5e first competitive pass (autoscan 2026-05-08) — runtime TUI configurators are now table-stakes in the Claude Code statusline space:

• ccstatusline ships an interactive TUI runnable any time post-install (live theme/widget tweaking, fuzzy widget picker)
• CCometixLine ships ccline --config with real-time preview and Nerd-Font selection
• claude-powerline ships a web visual configurator at powerline.owloops.com
• Barista has a polished interactive arrow-key installer (in install.sh) but no post-install runtime TUI — users either re-run the installer or hand-edit barista.conf

The friction shape: a user discovers a new module via README/release-notes, wants to enable it, and currently has to either:

1. Re-run install.sh (which is interactive but does much more than just config),
2. Or hand-edit barista.conf keys with no preview.

Competitors all let you tweak in seconds with live preview.

What

Add a barista config (or barista.sh --config) subcommand that opens a runtime TUI for editing barista.conf with the same UX as the install.sh wizard:

• Arrow-key navigation through configurable keys (theme, modules, layout mode, separators, etc.)
• Live preview of the resulting statusline rendered in a sample line below the picker
• Save back to barista.conf on confirm
• Cancel without write on Ctrl-C / Escape

Implementation notes

• Reuse the existing arrow-nav code from install.sh — extract into a shared modules/_tui.sh helper if not already factored
• The "live preview" can call barista.sh --render-preview (or invoke the renderer with BARISTA_TEST=1 to skip claude-context-fetching)
• Per-directory .barista.conf overrides should also be editable (with a "scope: global / this directory" toggle)

Acceptance

• barista config subcommand opens a TUI editor
• All keys currently editable via install.sh are editable here too (theme, modules, layout, separators, color thresholds, opt-in WAN-IP)
• Live preview renders the statusline as keys change
• Save writes back to barista.conf; cancel leaves file untouched
• Per-directory .barista.conf editable with a scope toggle
• README "Configuration" section updates to point users at barista config rather than the hand-edit path

Tier

Vertical-slice eligible Phase 1 — extract the install.sh's arrow-nav into a reusable helper + wire it as a barista.sh subcommand. ≤6 files (1 new TUI helper module + 2 modified scripts + README + CHANGELOG + tests). Internally complete (TUI works for global config) — Phase 2 adds per-directory scope and live preview if Phase 1 ships without them.

Priority: HIGH — second-largest competitive-parity gap; competitors all ship runtime TUIs. Post-install reconfiguration friction is real and recurring.

Source

Filed by autonomous scanner — Step 5e first competitive pass (2026-05-08). GAP-2 of 7 surfaced; ranked High by competitive-parity analysis. Competitor evidence cited in companion issue.

[pstuart]

9-day re-ping (autonomous scan 2026-05-17)

9.61 days author-silent, past the dossier's 5-day re-ping threshold by 4 days. Re-confirming Phase 1 scope is still the right slice:

Extract the install.sh's arrow-nav into a reusable helper + wire it as a barista.sh config subcommand. ≤6 files (1 new TUI helper module + 2 modified scripts + README + CHANGELOG + tests). Live preview + per-directory scope deferred to Phase 2.

Smallest unblock ask (refined from the original)

The original filing didn't have an explicit unblock ask — the implementation path is clear, so the question is scope decision, not engineering:

1. Do you want Phase 1 to include live preview, or defer to Phase 2? Without live preview, the TUI is essentially "an editor with arrow-nav and validation" — useful but less impressive than competitors' real-time rendering.
2. Per-directory .barista.conf editability — Phase 1 or Phase 2? If Phase 1, the TUI needs a scope toggle in the UI from day one; if Phase 2, the TUI can land as global-config-only first.

A one-line answer on each ("Phase 1: yes/no" × 2) unblocks the slice. If silent through 14 days (2026-05-22), the next re-ping defaults to "Phase 1 = global config only, no live preview" as the minimal-internally-complete slice.

Re-ping recipe applied per dossier protocol

First re-ping at 9-day mark. Next tier at ~14-day mark (2026-05-22) escalates to defaulted scope.

Companion issue #23 (Homebrew/npx distribution) re-pinged in parallel under the same protocol.