devstuff 1.16.0__tar.gz → 1.18.0__tar.gz

{devstuff-1.16.0 → devstuff-1.18.0}/.github/workflows/test-installs.yml

@@ -52,6 +52,7 @@ jobs:
       matrix:
         tool:
           - aws
+          - commitizen  # uvx tool, requires uv
           - eza
           - gh
           - git-lfs
@@ -61,6 +62,7 @@ jobs:
           - java
           - lazygit
           - mkcert
+          - nerd-font
           - nvm
           - php
           - pi          # installs nvm first via its declared `requires`

{devstuff-1.16.0 → devstuff-1.18.0}/CHANGELOG.md

@@ -1,3 +1,16 @@
+## v1.18.0 (2026-08-01)
+
+### Features
+
+- **configure**: add commitizen tool and configuration wizard
+
+## v1.17.0 (2026-07-31)
+
+### Feat
+
+- starship config font validation and install
+- **configure**: add a starship prompt setup wizard with live preview
+
 ## v1.16.0 (2026-07-24)
 
 ### Feat

{devstuff-1.16.0 → devstuff-1.18.0}/CLAUDE.md

@@ -21,8 +21,10 @@ uv run pytest tests/test_catalog.py::test_user_catalog_overrides_bundled_tool_in
 ```
 
 `pip` is not available in this dev environment — `uv pip install -e .` / `uv run` are the way in.
-Interactive commands (`install`, `add`, `remove`, `delete`) open questionary/click prompts and
-hang in non-TTY shells; don't try to drive them from a piped/non-interactive shell.
+Interactive commands (`install`, `add`, `remove`, `delete`, `configure`) open questionary/click
+prompts and hang in non-TTY shells; don't try to drive them from a piped/non-interactive shell.
+To exercise one end-to-end anyway, fork a pty (`pty.fork()`) and write keystrokes to the fd —
+that is how the starship wizard's full flow was verified.
 
 ### Integration tests (real installs, Docker-isolated)
 
@@ -60,6 +62,7 @@ src/dev_setup/
 ├── generic.py       # GenericTool — the ONE engine that implements every install type
 ├── tools.yaml       # Bundled built-in catalog (core/tools/languages categories)
 ├── ui.py            # Rich console + questionary wrappers (spinners, prompts, styled output)
+├── configure/       # Per-tool setup wizards (see "Configurators" below)
 └── commands/        # One Click command per file: list, install, remove, add, delete, docs, catalog
 ```
 
@@ -167,6 +170,122 @@ non-interactive `bash <tmpfile>`, so `~/.bashrc`/nvm's shell init never runs on
 Not yet built: an `add` wizard and `catalog import`/`export` for functions, analogous to the
 ones tools already have.
 
+## Configurators (`configure/`) — tool-specific wizards, deliberately *not* catalog-driven
+
+`src/dev_setup/configure/` holds per-tool setup wizards (`devstuff configure <tool>`), registered
+in a `CONFIGURATORS` dict keyed by catalog tool key. There are two:
+`configure/starship/{model,render,preview,wizard}.py` and
+`configure/commitizen/{model,render,detect,validate,wizard}.py`.
+
+**Why this one breaks the YAML-catalog rule.** Installation generalises into ~7 mechanisms, which
+is what makes `GenericTool` possible. Configuration does not: starship's config is a TOML file of
+format strings, palette tables and powerline transition glyphs; another tool's would be shell
+exports or `git config` calls. Expressing this wizard in YAML would need conditional questions, an
+ordered section model with colour roles, and a template language — a programming language spelled
+in YAML. So configurators are Python, dispatched from a dict, the same shape as `_INSTALLERS` in
+`generic.py`. Full reasoning in `docs/specs/starship-config/stack-decisions.md` (SD-1).
+
+A configurator that finds a missing *prerequisite* should offer to install it through
+`install_cmd.install_by_key(key)` rather than telling the user to run a second command — that is
+what the starship wizard does for `nerd-font`.
+
+**Adding a configurator** — a new module plus one dict entry. The module must expose
+`run(*, target: Path | None = None)` (returns `None` if the user cancelled; writes nothing until
+they confirm) and `config_path() -> Path`. Everything generic — the picker, install-state check,
+`--list`/`--path`/`--output`, and the post-install offer in `install_cmd.py` — reads the registry,
+so none of it needs touching. There is deliberately **no `configure:` field in `tools.yaml`**: user
+catalogs are strictly validated, so a catalog naming a nonexistent configurator would add a
+load-time failure mode for nothing.
+
+**Within the starship configurator, `model.py` is the data and everything else reads it.**
+`SECTIONS` (ordered — declaration order *is* prompt order), `PALETTES` and `PRESETS` drive both the
+TOML emitter and the offline preview, which is what stops those two from drifting. Adding a section
+or palette is one entry; no other file changes.
+
+**Things learned from the real binary — don't "simplify" these away:**
+- `symbol` is emitted for every section whose body contains `$symbol`, *including as an empty
+  string*. Omit it and starship's built-in Nerd Font glyph leaks into the `plain` preset. The
+  converse is unit-tested: a section carrying an icon its body can't render is a bug (that's why
+  `directory`, which has no `symbol` key at all, has no icon).
+- Not every module spells the colour key `style` — hence `Section.style_key` (`username` wants
+  `style_user`). `battery` is deliberately absent: it accepts neither `style` nor `symbol` (both
+  live in its `[[battery.display]]` array), so it would cost three quirk fields for one section.
+- `kubernetes`, `time`, `azure`, `status` and `shlvl` ship *disabled*; listing them in `format`
+  isn't enough, they need `disabled = false`. `os` and `git_metrics` are absent for the same
+  reason `battery` is: `os` takes its symbol from an `[os.symbols]` distro table, `git_metrics`
+  has `added_style`/`deleted_style` instead of `style`.
+- Format strings are emitted as TOML **literal** strings (`'…'`) so starship's `$`, `[`, and `\[`
+  grammar needs no escaping. The multi-line top-level `format` is the one basic string, and it
+  contains no backslashes of its own beyond the line continuations.
+- Powerline transitions are emitted per **run of consecutive sections sharing a palette role**, not
+  per section — otherwise two adjacent language segments draw an arrow between two identical
+  backgrounds. The three powerline presets differ *only* in the four glyphs in their `Powerline`
+  record (`POWERLINES` in `model.py`); nothing in the emitter knows which variant it is drawing.
+- Any literal text the emitter writes into a format string is escaped with `_escape_format()`.
+  This is not theoretical: `success_symbol = '[$](bold fg:ok)'` made starship read `$` as the start
+  of a variable name, so the `plain` preset shipped with *no prompt symbol at all* until it was
+  caught by sweeping every combination and asserting empty stderr.
+- A custom module (`custom.compose`) is a normal `Section`, but its dotted key has to be written
+  `${custom.compose}` in `format` — hence `Section.ref`. It also runs a shell command on **every**
+  prompt, so it carries a `when` guard, and anything needing the network is disqualified.
+- Symbols for new sections come from `starship print-config --default` — the module's own shipped
+  glyph — rather than being picked from a Nerd Font chart that can't be verified without the font.
+- The sample project must never gain a `bun.lock`: starship's `nodejs` module lists it as a
+  *negative* detector, so it silently switches the Node section off in previews.
+- The live preview runs `starship prompt` with `STARSHIP_SHELL=nu`, not `bash`: for bash, starship
+  wraps escapes in readline's `\[`/`\]` markers, which are invisible inside a `PS1` and print
+  literally anywhere else. It also overrides `PWD` (starship prefers it over the real cwd) and
+  makes a second `--right` call, since `right_format` is not part of the left prompt.
+- Every preview failure path returns `None` and degrades to the offline renderer. A preview must
+  never be able to end the wizard.
+- The Nerd Font gate (`configure/starship/fonts.py`) is allowed to answer "don't know": without
+  fontconfig there is nothing to enumerate, and `None` means *stay silent* rather than warn. It
+  also refuses to install over SSH — the glyphs are drawn by the client's terminal — and always
+  says that installing a font does not repoint the terminal at it. The install itself goes through
+  the ordinary catalog path (`nerd-font` in `tools.yaml` → `install_cmd.install_by_key`), never a
+  private download (SD-10).
+
+**Within the commitizen configurator, the object being configured is a list of commit types, not
+a settings sheet.** `TYPES` in `model.py` is ordered (declaration order *is* prompt order, changelog
+order and regex-alternation order), and `render.py` derives all nine `cz_customize` settings from
+it — so adding a type is one `ChangeType` record and it reaches `bump_pattern`, `bump_map`,
+`schema_pattern`, `change_type_map`, `change_type_order`, `commit_parser` and `questions` with no
+other edit. Full reasoning in `docs/specs/commitizen-config/`.
+
+**Things learned from the real binary — don't "simplify" these away:**
+- `bump_map` is an **ordered** map and commitizen `break`s at the first key that `re.match`es, so
+  the two breaking-change rules (`^.+!$`, `^BREAKING[\-\ ]CHANGE`) must be emitted first. Reorder
+  them and `feat(api)!:` silently ships as a MINOR.
+- What `bump_map`'s keys are matched against is **group 1 of `bump_pattern`** (`feat(api)!`), not
+  the commit message. That is why `^.+!$` works at all, and why every selected type belongs in the
+  pattern even when it has no map entry.
+- `schema_pattern` must always accept the `bump:` prefix (`ALWAYS_ACCEPTED` in `model.py`):
+  `cz bump` writes its own commit with that prefix, and `cz check --rev-range` over a release
+  otherwise rejects commitizen's own commit. `cz_conventional_commits` accepts `bump` for exactly
+  this reason without ever offering it in the picker.
+- `commit_parser`'s trailing `|\w+!` alternative is load-bearing: it is what keeps `docs!: …` (a
+  breaking change on a type with no changelog section) in the release notes at all. Verified — it
+  lands in an unlabelled group rather than vanishing.
+- The `BREAKING CHANGE` changelog heading only collects commits with a **footer**. A `feat!:` still
+  bumps the major but is written up under Features, because that is the type it declared.
+- Regexes are emitted as TOML **literal** strings (`'…'`) so no backslash needs doubling;
+  `message_template` and `schema` are the exceptions (they carry real newlines, so they are basic
+  strings). A user-supplied value containing a quote falls back to a basic string automatically.
+- `config_path()` mirrors `commitizen.config.read_cfg`: search order *and* the rule that a file
+  without a `commitizen` section doesn't count — otherwise every Python project on disk looks
+  already-configured because it has a `pyproject.toml`.
+- The `pyproject.toml` splice is line-based, so it verifies itself by parsing the result back and
+  comparing the settings; a mismatch returns `None` and the caller writes `.cz.toml` instead. Don't
+  replace that check with reasoning about which files it can handle.
+- `validate.py` is the "measured, not assumed" half: it replays commits through the real
+  `cz bump --dry-run` in a throwaway repo. It runs on an explicit menu action plus once at save
+  time — not on every redraw (~3s, unlike starship's millisecond preview) — and a disagreement
+  *warns*, it never vetoes a save. Keep that distinction in the comments.
+
+Not yet built: configurators for anything other than starship and commitizen, and round-tripping an
+existing hand-edited config back into wizard state (the timestamped backup is the safety net
+instead).
+
 ## Specs (`docs/specs/`)
 
 Design documents live in `docs/specs/<feature>/` — `specifications.md` (numbered, testable
@@ -258,6 +377,12 @@ Not yet built: an `add` wizard for agent tools, and `catalog import`/`export` fo
 - **No new runtime dependencies for the agent.** The Ollama transport is stdlib `urllib` against
   `/api/chat`; the REPL uses `prompt_toolkit`, already vendored via questionary. devstuff is a
   globally installed CLI, so every dependency is a cost paid by users who never run `agent`.
+- **Configuration is Python, installation is YAML.** The no-per-tool-code rule covers *install
+  mechanisms*, which generalise; per-tool config formats don't. `configure/` is a registry of
+  Python wizards on purpose — see the section above before trying to fold it into `tools.yaml`.
+- **A config wizard previews with the real binary, not an approximation.** `starship prompt`
+  against a temp config in a throwaway project is the source of truth; the offline renderer is a
+  labelled fallback for when the tool isn't installed (and is what unit tests exercise).
 - **Functions get a parallel catalog/registry instead of extending `GenericTool`.** The
   schemas diverge enough (no `requires` inference, a `params` list, no install/remove
   lifecycle) that folding them into the tool catalog would be lossy; some duplication with

{devstuff-1.16.0 → devstuff-1.18.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: devstuff
-Version: 1.16.0
+Version: 1.18.0
 Summary: Development environment setup CLI for Linux
 Project-URL: Repository, https://github.com/thesawdawg/dev-setup-py
 Author-email: Sawyer <sawyerksu@gmail.com>
@@ -188,6 +188,201 @@ for confirmation before doing this.
 
 ---
 
+### `configure`
+
+Set up an installed tool through a guided wizard, previewing the result before anything is
+written. Installing a tool that has a wizard also offers to run it there and then.
+
+```bash
+devstuff configure                       # pick from the tools that have a wizard
+devstuff configure starship              # run starship's prompt wizard
+devstuff configure --list                # which tools have a wizard
+devstuff configure starship --path       # print the config file path
+devstuff configure starship --output /tmp/try.toml   # write elsewhere, leave the live config alone
+```
+
+| Tool | What it configures |
+|------|-------------------|
+| `commitizen` | Commit types, what each one bumps, git tags, and changelog sections |
+| `starship` | Prompt style, colour palette, which sections appear, and layout |
+
+#### Commitizen wizard
+
+Commitizen needs a config file before it does anything, and everything past its built-in
+Conventional Commits rules means `cz_customize` — nine coupled regexes where `bump_map`'s keys
+are matched against **group 1** of `bump_pattern`, the two breaking-change rules have to come
+*first* because commitizen stops at the first key that matches, and `schema_pattern` has to
+accept whatever `message_template` produces. Get the order wrong and `feat(api)!:` quietly ships
+as a minor release.
+
+The wizard asks about commit types and version rules, and derives all nine settings from the
+answers:
+
+| Step | Options |
+|------|---------|
+| **Convention** | `cz_conventional_commits` (commitizen's fixed rules — nothing to configure) · `cz_customize` (your types, your bump rules) |
+| **Commit types** | Checkbox over `feat`, `fix`, `refactor`, `perf`, `docs`, `style`, `test`, `build`, `ci` (all on, matching Conventional Commits) plus `chore`, `revert`, `deps`, `security` — and you can add your own |
+| **Per type** | What it bumps (`MAJOR` / `MINOR` / `PATCH` / no release), whether it appears in the changelog, under which heading, and its hotkey in `cz commit` |
+| **Versioning** | Where the version lives (`commitizen`, `scm`, `pep621`, `uv`, `poetry`, `cargo`, `npm`, `composer`) · scheme (`semver`, `semver2`, `pep440`) · tag format · other files carrying the version |
+| **Release** | Changelog on bump · `0.x` mode · annotated tags · GPG signing · incremental changelog · prerelease merging · `allow_abort` · hotkeys · changelog file · bump commit message |
+| **Prompt** | Which questions `cz commit` asks — scope, body, footer |
+| **Destination** | `pyproject.toml` (spliced in place) or a standalone `.cz.toml` |
+
+The custom branch **starts as an exact copy of Conventional Commits** — the built-in type table
+reproduces `commitizen.defaults.BUMP_MAP` and its picker, read out of the installed package and
+pinned by a test. Switching to custom to add one type does not cost you the convention.
+
+Before it asks anything, the wizard reads the project: git root, any existing commitizen config
+(in commitizen's own search order, ignoring files without a `commitizen` section), the version
+provider and current version from `pyproject.toml`/`package.json`/`Cargo.toml`/`composer.json`,
+the latest git tag, and an existing changelog.
+
+The review screen shows a sample `cz commit` message, the bump table, and the changelog sections:
+
+```
+  what each type does to 1.4.2
+
+  commit                       increment  new version
+  feat: …                      MINOR      1.5.0
+  fix: …                       PATCH      1.4.3
+  docs: …                      —          1.4.2
+  feat!: …                     MAJOR      2.0.0
+  BREAKING CHANGE: … (footer)  MAJOR      2.0.0
+```
+
+**That table is checked against the real thing.** "Check these rules against the real cz" builds
+a throwaway git repo tagged at 1.4.2, replays one commit per bump level plus both breaking forms
+through `cz bump --dry-run`, and reports whether commitizen agrees rule by rule. The same check
+runs automatically before saving — a disagreement is reported and asks for confirmation, but
+never blocks the save. "Preview a generated changelog" runs the real `cz changelog --dry-run`
+over one sample commit per type. Without `cz` installed the wizard still works; the checks say so
+rather than failing.
+
+On save:
+
+- Into `pyproject.toml`, every `[tool.commitizen…]` table is replaced and **the rest of the file
+  is left byte for byte**. The result is parsed back and compared to what was meant; if it does
+  not match, the write falls back to a standalone `.cz.toml` and the original is untouched.
+- Any existing file is copied to `<name>.bak.<timestamp>` first, and a config that wasn't written
+  by this wizard asks before being replaced.
+- If more than one commitizen config now exists, you're told which one commitizen will actually
+  read — `.cz.toml` beats `pyproject.toml`, so a new dotfile can silently shadow settings you
+  forgot about.
+- In a git repo with no `commit-msg` hook, you're offered one running `cz check`. An existing
+  hook is never replaced.
+
+The output is meant to be hand-edited afterwards: commented, ordered, and with regexes written as
+TOML literal strings so `^((BREAKING[\-\ ]CHANGE|feat)(\(.+\))?!?):` reads as itself instead of
+with every backslash doubled.
+
+```toml
+# Commitizen configuration
+# Generated by `devstuff configure commitizen` — edit freely, or re-run the wizard.
+# Convention: Custom types and bump rules · Types: feat, fix, docs, deps
+# Option reference: https://commitizen-tools.github.io/commitizen/config/
+[tool.commitizen]
+name = 'cz_customize'
+version_provider = 'pep621'
+version_scheme = 'pep440'
+tag_format = 'v$version'
+update_changelog_on_bump = true
+# …
+
+# Prefix -> version increment. Order matters: commitizen stops at the first
+# key that matches, so the two breaking-change rules have to lead.
+[tool.commitizen.customize.bump_map]
+'^.+!$' = 'MAJOR'
+'^BREAKING[\-\ ]CHANGE' = 'MAJOR'
+'^feat' = 'MINOR'
+'^fix' = 'PATCH'
+'^deps' = 'PATCH'
+```
+
+Design notes, including why this one isn't catalog-driven and why the checks warn rather than
+veto: [`docs/specs/commitizen-config/`](docs/specs/commitizen-config/).
+
+#### Starship prompt wizard
+
+Four questions, with the prompt re-rendered after each one:
+
+| Step | Options |
+|------|---------|
+| **Style** | `Plain text` · `Bracketed segments` (both ASCII, any font) · `Icons` · `Icons, bracketed` (Nerd Font glyphs) · `Powerline`, `Powerline, rounded`, `Powerline, slanted` (solid colour bars) |
+| **Palette** | `Terminal colours` (inherits your terminal theme) · Catppuccin Mocha · Nord · Gruvbox Dark · Tokyo Night · Dracula · Rosé Pine · Catppuccin Latte (light) |
+| **Sections** | Grouped checkbox over ~35 modules — see the table below |
+| **Layout** | Single line · Two lines · Two lines with shell info right-aligned (needs zsh/fish/nushell — bash has no right prompt) |
+
+| Group | Sections |
+|-------|----------|
+| **Context** | username, hostname (over SSH), container (Docker/toolbox/distrobox) |
+| **Location** | current directory |
+| **Git** | branch, commit hash (when detached), status (dirty/ahead/behind), operation in progress |
+| **Languages** | Node.js, Deno, Bun, Python, Rust, Go, Java, PHP, Ruby, Elixir, .NET, package version |
+| **Infrastructure** | Docker context, **Docker Compose project**, Kubernetes context, AWS profile, Google Cloud project, Azure subscription, Terraform workspace, Nix shell |
+| **Shell** | command duration, exit code of the last command, background jobs, nested shell depth, clock |
+
+The review menu adds two content toggles: the blank line between prompts, and whether language
+sections show **version numbers** or just the runtime's symbol.
+
+If you pick a style that needs a Nerd Font and there isn't one on the machine, the wizard says
+so in the style list itself (`Needs a Nerd Font — none installed here.`) and offers to install
+`nerd-font` right there — once per run, whether you say yes or no. Two cases it handles rather
+than pretending otherwise: over SSH it points you at [nerdfonts.com](https://www.nerdfonts.com/)
+instead, because the glyphs are drawn by the terminal on *your* machine, not the one you're
+configuring; and after installing it reminds you to actually select the font in your terminal's
+settings, which is a preference no shell can change for you. Without `fontconfig` there is no way
+to enumerate fonts, so the wizard says nothing rather than guessing.
+
+The Compose section is a starship [custom module](https://starship.rs/config/#custom-commands)
+rather than a built-in one — it reports the project name `docker compose` in that directory would
+actually use (`$COMPOSE_PROJECT_NAME`, else a top-level `name:` in the compose file, else the
+lowercased directory name), and it only runs at all when there is a compose file next to you.
+
+The preview is the real thing: the candidate config is written to a temp file and rendered by
+your installed `starship` binary inside a throwaway sample project (a git repo with language
+marker files), so what you see is the bytes your prompt will produce. Without starship installed
+the wizard still works and falls back to a labelled approximation.
+
+A review menu then lets you revisit any answer, dump the generated TOML, or save. On save:
+
+- Written to `$STARSHIP_CONFIG`, or `~/.config/starship.toml`.
+- Any existing file is copied to `starship.toml.bak.<timestamp>` first — and if it wasn't written
+  by this wizard, you're asked before it's replaced.
+- If `~/.bashrc` has no starship hook, you're offered one (using the same marker
+  `devstuff install starship` uses, so `devstuff remove starship` still cleans up).
+
+The output is meant to be hand-edited afterwards: it's commented, ordered, and colours are
+referenced through nine semantic palette roles (`dir`, `git`, `lang`, `infra`, `shell`, `ok`,
+`err`, `muted`, `bar_text`), so retheming everything is nine edits in one table.
+
+```toml
+# Starship prompt configuration
+# Generated by `devstuff configure starship` — edit freely, or re-run the wizard.
+# Style: Powerline · Palette: Nord · Layout: Two lines
+# Module reference: https://starship.rs/config/
+"$schema" = 'https://starship.rs/config-schema.json'
+
+add_newline = true
+palette = 'nord'
+
+format = """
+[](fg:dir)\
+$directory\
+[](fg:dir bg:git)\
+$git_branch\
+[](fg:git)\
+$line_break\
+$character"""
+
+# Semantic colour roles — swap these to retheme every section at once.
+[palettes.nord]
+dir = '#81a1c1'
+git = '#a3be8c'
+# …
+```
+
+---
+
 ### `add`
 
 Guided wizard to register a new custom package. Supports six install types:
@@ -586,16 +781,18 @@ Optional utilities you may want on some machines.
 | Key | Name | Description | Help |
 |-----|------|-------------|------|
 | `aws` | AWS CLI | Amazon Web Services CLI v2 | `aws help` |
+| `commitizen` | Commitizen | Conventional-commit prompt, semantic version bumping, and changelog generation (`devstuff configure commitizen`) | `cz --help` |
 | `eza` | eza | Modern ls replacement with git status, icons, and tree view | `eza --help` |
 | `gh` | GitHub CLI | GitHub's official CLI | `gh --help` |
 | `htop` | htop | Interactive process and resource monitor | `man htop` |
 | `mkcert` | mkcert | Zero-config local HTTPS certificates | `mkcert --help` |
+| `nerd-font` | JetBrainsMono Nerd Font | Patched font supplying the icons Starship and other CLI tools draw | `fc-list \| grep -i "nerd font"` |
 | `ollama` | Ollama | Run large language models locally | `ollama --help` |
 | `php` | PHP 8.4 | PHP 8.4 + common extensions via ondrej/php PPA | `php --help` |
 | `pi` | Pi Coding Agent | AI coding agent npm package | `pi --help` |
 | `pre-commit` | pre-commit | Git hook manager for automated code quality checks | `pre-commit --help` |
 | `saml2aws` | saml2aws | SAML → AWS STS credentials CLI (Versent) | `saml2aws --help` |
-| `starship` | Starship | Fast, cross-shell customizable prompt | `starship --help` |
+| `starship` | Starship | Fast, cross-shell customizable prompt (`devstuff configure starship`) | `starship --help` |
 | `yq` | yq | Portable command-line YAML/JSON/XML processor | `yq --help` |
 
 ### Languages
@@ -740,6 +937,13 @@ dev-setup-py/
         ├── functions_registry.py # Loads bundled + user YAML into the live function registry
         ├── function_runner.py    # Param resolution + script/eval/bashrc rendering & execution
         ├── functions.yaml        # Bundled built-in function catalog
+        ├── configure/              # Per-tool setup wizards (see "configure" above)
+        │   ├── __init__.py         # CONFIGURATORS registry: tool key -> wizard module
+        │   └── starship/
+        │       ├── model.py        # presets, palettes, sections, StarshipConfig
+        │       ├── render.py       # starship.toml emitter + offline preview renderer
+        │       ├── preview.py      # live preview via `starship prompt` in a sample project
+        │       └── wizard.py       # the interactive flow, backup + save
         ├── agent_tools.yaml       # Bundled agent tool catalog
         ├── agent/                 # Local-model agent (see "Agent" above)
         │   ├── config.py          # agent.yaml load/validate/save