Proposal: use-case profiles for clearer CarWatch setups

[mvanhorn]

Motivation

HN asks what CarWatch is for. The README is rich but cloners still face an all-units install without a purpose-shaped path. Use-case profiles make the product claim concrete and seed which systemd units to enable.

Research Summary

Evidence Vault

• last30days: use-case clarity + trust.
• profiles/ directory exists but is not a first-class installer concept tied to units.

Proposed Solution

Three declarative profiles:

1. cabin-manual — voice + manual RAG (+ brain/listen/chat).
2. obd-companion — OBD + trips + chat agent (no 14GB model required).
3. dashcam-reporter — wolfbox clip pipeline + room posts.

install.sh --profile NAME (or doctor/profile helper) copies profile defaults into config notes and prints the exact systemctl enable set. README gains a "Pick your use case" section linking docs/use-cases.md.

Approach

Ideas Discussion to validate names and unit sets with maintainer.

Test Strategy

Profile JSON schema/required keys; CLI lists profiles; unknown profile errors.

Alternatives Considered

• Security-first install: deferred (Dashboard token travels in the URL query string #12–Systemd units ship zero hardening (NoNewPrivileges, ProtectSystem, ProtectHome) #18).
• Single mega default: status quo that confuses cloners.

PR Strategy

Ideas then PR.

Happy to open a draft PR if this shape looks right. Looking for maintainer signal before writing code.