design(config): customization surface is inconsistent — format templating is aws-only, SegmentConfig is one shared grab-bag

[lemtoc]

As of v0.3.0 (c73dc6c).

Summary

The project's stated philosophy includes broad customization, but today's config model is "placement (layout) + appearance (style/icon)" with per-segment exceptions that users can only discover from examples/config.toml:

• format templating ("$symbol$profile[ ($region)]", with optional bracket groups) exists only for aws (docs/aws-format.md). git_branch, dir, duration, etc. have no equivalent; users cannot reorder icon/text or add literal affixes except via segment-specific one-offs (prefix for duration, icon for some).
• SegmentConfig (src/config/mod.rs:53) is a single struct shared by all segments: character/characters are prompt_char-only, max_components is dir-only, show_counts/separator(inner) are git_status-only, min_ms is duration-only, force_display is aws-only. Nothing — not the type system, not nova check — tells a user which keys a segment actually reads (concrete detection of unknown keys/tables is tracked in feat(config): nova check silently accepts typo'd keys, unknown segment tables, and inapplicable options #28).

This is a design-level inconsistency: every new segment either overloads the shared struct further or invents another bespoke key.

Proposed direction

1. Decide the templating story once. Either promote the aws format mini-language to a shared facility (each segment exposes named variables; the parser already exists) or explicitly document that Nova does not do templating and remove the aws exception over a deprecation cycle. The current halfway state is the worst option.
2. Per-segment config types. Move to enum-dispatched or per-segment structs (e.g. DirConfig, GitStatusConfig) deserialized from the same [segments.<id>] tables. This makes key applicability machine-checkable ("max_components is not read by time" becomes a warning or error for free, completing what unknown-key detection alone cannot express) and keeps SegmentConfig from growing a new optional field per feature. An interim step, if full structs are too big a bite: a declared const key set per segment spec, checked by Config::warnings.
3. Out of scope here but related: user-defined command segments (arbitrary command output as an async segment) would be the real "wide customization" differentiator — the worker/cache/TTL/timeout infrastructure is already exactly what that feature needs. Worth a separate design discussion once 1–2 settle.

No behavior change proposed yet; this issue is for agreeing on the target model before more segments land.

---

🤖 Generated with Claude Code — Claude Fable 5