Animated welcome screen

[scoobynko]

Summary

Explore animating the banner as it's drawn on shell launch — e.g. typewriter reveal, gradient sweep, fade-in — instead of printing the finished block in one shot.

Motivation

The banner is currently a single print() of a fully-composed block. An entrance animation is the kind of detail that makes a terminal feel bespoke, and it's the main remaining visual axis the config doesn't touch.

Constraints

This lands in welcome_banner.py, which runs on every interactive Ghostty shell open, so the bar is high:

• Fast and non-blocking. Shell startup latency is the hard budget. An animation that delays the prompt by a perceptible amount is worse than no animation. Needs a measured budget (target and ceiling) before any implementation.
• No third-party imports. The generated renderer is pure-Python-stdlib by design and guarded by test_generated_banner_is_self_contained. Any animation must be hand-rolled ANSI (cursor moves, redraws, time.sleep) — no rich, no curses dependency.
• Degrades to static. Non-TTY stdout, dumb terminals, and piped output must fall through to today's single-shot print.
• Optional via config. Off by default; opt-in through a new [animation] section in welchost.toml, with the schema round-trip staying lossless.
• Interrupt-safe. Ctrl-C mid-animation must leave the terminal in a sane state (cursor visible, no leaked escape sequences).

Open questions

• Which effects are worth the complexity? Typewriter and gradient sweep are cheap; fade-in needs truecolor and degrades badly on 256-color terminals.
• Can the animation be previewed WYSIWYG in the TUI, or is it inherently only verifiable in a real shell? A preview that can't show the effect weakens the wizard's core guarantee.
• Does it interact with the deferred runtime width fallback (both add logic to the generated script)?

Areas

Feature, Rendering · Effort XL