@leanspec/ui 0.2.5 → 0.2.6-dev.20251125010539

package/.next/standalone/packages/ui/dist/standalone/specs/archived/023-folder-structure-improvements/README.md

@@ -1,255 +0,0 @@
----
-status: complete
-created: 2025-11-03
-tags: [core, ux, multi-user]
-priority: high
-updated: 2025-11-03
----
-
-# Folder Structure: Polish & Multi-User Support
-
-> Polish the flexible folder structure implementation and add simple conflict warnings for multi-user workflows
-
-## Status Update (2025-11-03)
-
-✅ **Critical items completed:**
-- Date prefix default implementation
-- `lean-spec check` command with conflict detection
-- Auto-check integration across all spec-reading commands
-
-📋 **Minor polish issues tracked separately:**
-- [005-pattern-aware-list-grouping](../005-pattern-aware-list-grouping/) - Fix list.ts date grouping
-- [006-template-config-updates](../006-template-config-updates/) - Update template configs
-- [012-init-pattern-selection](../012-init-pattern-selection/) - Add pattern selection to init wizard
-
-This spec focused on solving the critical multi-user conflict issue. The minor polish items are now tracked individually for cleaner organization and focused work.
-
-## Problem
-
-The flexible folder structure (spec 001) is complete and working, but has issues affecting UX and multi-user workflows:
-
-### 🚨 Critical: Sequence Conflicts in Multi-User Workflows
-
-**Current behavior:**
-```bash
-# User A and User B work on same repo
-User A: lean-spec create feature-a  # Gets 001-feature-a
-User B: lean-spec create feature-b  # Also gets 001-feature-b (locally)
-
-# Both push to git → merge conflict!
-```
-
-**Root cause:** `getGlobalNextSeq()` scans local filesystem only, so two users on different branches get same sequence number.
-
-### ⚠️ Minor Polish Issues
-
-1. **`list.ts` hardcoded date grouping** - Doesn't adapt to flat or custom patterns
-2. **Template configs use legacy format** - Works but inconsistent
-3. **No pattern selection in `lean-spec init`** - Must manually edit config
-
-## Proposal
-
-Keep it **lean and simple**: Focus on prevention with good defaults + basic conflict detection.
-
-### 1. Use Date Prefix by Default (Prevention)
-
-Make `prefix: "{YYYYMMDD}-"` the default for flat pattern:
-
-```bash
-# Result:
-# User A on Nov 3: 20251103-001-feature-a
-# User B on Nov 3: 20251103-002-feature-b  # Different sequence
-# User A on Nov 4: 20251104-003-feature-c  # Different date
-```
-
-**Benefits:**
-- ✅ Prevents conflicts naturally (date + sequence)
-- ✅ Already implemented, just change default
-- ✅ Chronological sorting automatic
-- ✅ No extra complexity
-
-**Trade-off:**
-- Longer folder names (but clearer)
-
-### 2. Add Simple Conflict Warning
-
-Add `lean-spec check` command that warns about duplicate sequences:
-
-```bash
-$ lean-spec check
-⚠️  Sequence conflicts detected:
-   Sequence 001:
-     - specs/001-feature-a/
-     - specs/001-feature-b/
-
-Fix manually or use date prefix to prevent conflicts.
-```
-
-**Auto-check on relevant commands:**
-
-Commands that **should** auto-check (interact with specs):
-- ✅ `lean-spec create` - Just created a spec (might conflict)
-- ✅ `lean-spec list` - Browsing specs
-- ✅ `lean-spec board` - Viewing kanban
-- ✅ `lean-spec update` - Modifying a spec
-- ✅ `lean-spec search` - Searching specs
-- ✅ `lean-spec stats` - Viewing stats
-- ✅ `lean-spec timeline` - Viewing timeline
-- ✅ `lean-spec gantt` - Viewing gantt chart
-- ✅ `lean-spec deps` - Checking dependencies
-- ✅ `lean-spec files` - Viewing spec files
-- ✅ `lean-spec archive` - Archiving a spec
-
-Commands that **should NOT** auto-check (don't interact with specs):
-- ❌ `lean-spec init` - Initializing new project (no specs yet)
-- ❌ `lean-spec templates` - Managing templates only
-- ❌ `lean-spec check` - Already checking conflicts
-
-**Behavior:**
-- Non-blocking: Shows warning but doesn't fail
-- Contextual: Only shows if conflicts exist
-- Silent mode: Can disable with env var or config
-- Fast: < 10ms overhead
-
-**That's it.** No auto-fix, no complex strategies. Users can:
-- Rename folders manually
-- Use date prefix to prevent future conflicts
-- Live with conflicts if they don't care
-
-### 3. Pattern-Aware List Grouping
-
-Make `lean-spec list` adapt to the configured pattern (flat vs custom).
-
-### 4. Update Template Configs
-
-Use new config format consistently across all templates.
-
-### 5. Pattern Selection in Init
-
-Let users choose pattern during `lean-spec init`.
-
-## Design
-
-See [DESIGN.md](./DESIGN.md) for implementation details.
-
-**Summary:**
-1. Update `DEFAULT_CONFIG` to include `prefix: '{YYYYMMDD}-'`
-2. Add `--no-prefix` flag for solo devs who want clean numbers
-3. Implement simple `lean-spec check` command
-4. Auto-check on all spec-reading commands (11 total)
-5. Make `list` command pattern-aware
-6. Update templates
-7. Add pattern selection to init wizard
-
-## Plan
-
-- [ ] Update default config to use date prefix
-- [ ] Add `--no-prefix` flag to create command
-- [ ] Implement `lean-spec check` (detect only, no auto-fix)
-- [ ] Add auto-check to: create, list, board, update, search, stats, timeline, gantt, deps, files, archive
-- [ ] Add config option to disable auto-check
-- [ ] Fix list grouping to be pattern-aware
-- [ ] Update all template configs
-- [ ] Add pattern selection to init wizard
-- [ ] Update documentation
-- [ ] Add tests for all auto-check integrations
-
-## Test
-
-- [ ] Date prefix applied by default
-- [ ] `--no-prefix` works for solo devs
-- [ ] `lean-spec check` detects duplicate sequences
-- [ ] Auto-check runs on all 11 spec-reading commands
-- [ ] Auto-check is non-blocking (shows warning only)
-- [ ] Auto-check can be disabled via config
-- [ ] Auto-check doesn't run on init/templates/check commands
-- [ ] List groups correctly for flat/custom patterns
-- [ ] Templates use new format
-- [ ] Init wizard offers pattern choices
-- [ ] All existing tests pass
-
-## Success Criteria
-
-- [ ] New projects use date prefix by default (prevents conflicts)
-- [ ] Solo devs can opt out with `--no-prefix`
-- [ ] Conflicts detected via `lean-spec check`
-- [ ] Auto-check warns users in relevant commands
-- [ ] Auto-check is non-blocking and can be disabled
-- [ ] List command adapts to pattern
-- [ ] Templates consistent
-- [ ] Init offers pattern selection
-- [ ] Documentation clear and simple
-
-## Notes
-
-### Why Date Prefix is the Right Default
-
-**Pros:**
-- Natural conflict prevention
-- No complexity added
-- Works offline, always
-- Chronological sorting
-- Already implemented
-
-**Cons:**
-- Longer folder names
-- But: can opt out with `--no-prefix`
-
-### Why Not Auto-Fix?
-
-Keep it **lean**:
-- Manual fix is simple (rename folder)
-- Auto-fix adds complexity (strategies, reference updates, etc.)
-- If conflicts are rare (they are with date prefix), manual is fine
-- Users know their context best
-
-### Auto-Check Design
-
-**When to check:**
-- ✅ After `lean-spec create` - User just created a spec
-- ✅ Before `lean-spec list` - User browsing specs
-- ✅ Before `lean-spec board` - User viewing kanban
-- ✅ Before `lean-spec update` - User modifying spec
-- ✅ Before `lean-spec search` - User searching specs
-- ✅ Before `lean-spec stats` - User viewing statistics
-- ✅ Before `lean-spec timeline` - User viewing timeline
-- ✅ Before `lean-spec gantt` - User viewing gantt chart
-- ✅ Before `lean-spec deps` - User checking dependencies
-- ✅ Before `lean-spec files` - User listing spec files
-- ✅ Before `lean-spec archive` - User archiving spec
-
-**When NOT to check:**
-- ❌ `lean-spec init` - No specs exist yet
-- ❌ `lean-spec templates` - Template management only
-- ❌ `lean-spec check` - Already checking
-
-**Rationale:**
-Any command that reads/displays/modifies specs should check for conflicts. This gives users visibility into problems at natural interaction points without being intrusive.
-
-**How it works:**
-- Fast check (< 10ms for 100s of specs)
-- Non-blocking (shows warning, doesn't fail)
-- Appears at end of output
-- Can disable globally in config
-
-**Config option:**
-```json
-{
-  "autoCheck": false  // Disable auto-check
-}
-```
-
-**Example output:**
-```bash
-$ lean-spec create feature-c
-✓ Created: specs/001-feature-c/
-
-⚠️  Conflict warning: Sequence 001 used by multiple specs
-Run: lean-spec check
-```
-
-### Backward Compatibility
-
-- Existing projects continue working
-- No forced migration
-- Can opt in to date prefix by editing config

package/.next/standalone/packages/ui/dist/standalone/specs/archived/027-cli-ui-ux-optimization/README.md

@@ -1,454 +0,0 @@
----
-status: complete
-created: '2025-11-03'
-tags:
-  - cli
-  - ux
-  - enhancement
-priority: high
-completed: '2025-11-03'
----
-
-# cli-ui-ux-optimization
-
-> **Status**: ✅ Complete · **Priority**: High · **Created**: 2025-11-03 · **Tags**: cli, ux, enhancement
-
-**Project**: lean-spec  
-**Team**: Core Development
-
-## Overview
-
-The current CLI rendering has inconsistent UI/UX that lacks the polish and richness of modern CLI tools like Python's `rich` library. We want to create a **beautiful, feature-rich terminal experience** using Ink/React while maintaining consistency.
-
-**Current Problems:**
-
-1. **Inconsistent rendering**: Some commands use plain `console.log`, others use Ink - creating a jarring mix
-2. **Underutilized Ink**: Where we use Ink, we're not leveraging its full power (animations, layouts, interactions)
-3. **Poor visual design**: Awkward borders, fixed widths, cluttered spacing
-4. **Limited interactivity**: No way to navigate, filter, or interact with results
-5. **Missing rich features**: No syntax highlighting, progress indicators, live updates, or animations
-6. **Primitive components**: Current Board/Stats components are basic and don't showcase what's possible
-
-**Why now**: Modern CLI tools (GitHub CLI, Vercel CLI, `rich` in Python) set high UX standards. We should match that quality.
-
-## Design
-
-### Vision: `rich` for Node.js
-
-Create a **rich, beautiful CLI experience** inspired by Python's `rich` library:
-
-- **Beautiful tables** with automatic column sizing, borders, and alignment
-- **Rich panels** with rounded corners, padding, and titles
-- **Syntax highlighting** for code snippets and file content
-- **Progress bars** and spinners for async operations
-- **Live updating** displays (e.g., real-time build status)
-- **Interactive elements** (arrow keys to navigate, space to select)
-- **Color gradients** and visual flair (when appropriate)
-- **Responsive layouts** that adapt to terminal width
-
-### Unified Ink Architecture
-
-**ALL commands should use Ink/React** for consistent, rich rendering:
-
-Benefits:
-- Beautiful, modern UI with professional polish
-- Interactive features (keyboard navigation, selection)
-- Live updates without re-rendering full screen
-- Component reusability and composition
-- Consistent spacing, colors, and layouts
-- Easy to add animations and transitions
-
-### Visual Design Principles
-
-**Inspired by `rich` (Python):**
-
-1. **Beautiful typography**: Use box-drawing characters, rounded corners, proper spacing
-2. **Smart colors**: Gradients, semantic colors, and theme consistency
-3. **Visual hierarchy**: Clear structure with panels, tables, and sections
-4. **Responsive design**: Adapt to terminal width (80 cols minimum, expand to full width)
-5. **Rich information density**: Show more data in an organized, scannable way
-6. **Smooth interactions**: Animations for transitions, loading states
-
-### Component Library
-
-Build reusable Ink components:
-
-**`<Panel>`** - Rounded box with title, padding, and optional footer
-```tsx
-<Panel title="📊 Spec Statistics" border="rounded" padding={1}>
-  {content}
-</Panel>
-```
-
-**`<Table>`** - Auto-sized columns with headers, borders, alignment
-```tsx
-<Table
-  columns={[
-    { header: 'Spec', align: 'left', width: 'auto' },
-    { header: 'Status', align: 'center', width: 12 },
-    { header: 'Priority', align: 'left', width: 10 }
-  ]}
-  rows={rows}
-  border="rounded"
-/>
-```
-
-**`<ProgressBar>`** - Rich progress indicator with percentage, ETA
-```tsx
-<ProgressBar
-  current={15}
-  total={26}
-  label="Loading specs"
-  showPercentage
-  showETA
-/>
-```
-
-**`<KeyValueList>`** - Aligned key-value pairs
-```tsx
-<KeyValueList
-  items={[
-    { key: 'Status', value: 'In Progress', color: 'yellow' },
-    { key: 'Priority', value: 'High', color: 'red' }
-  ]}
-  keyWidth={15}
-/>
-```
-
-**`<Tree>`** - Hierarchical display with indent lines
-```tsx
-<Tree
-  data={specsByDate}
-  renderNode={(spec) => <SpecNode spec={spec} />}
-  expandable
-/>
-```
-
-**`<Tabs>`** - Multiple views with tab navigation
-```tsx
-<Tabs activeTab={activeTab} onChange={setActiveTab}>
-  <Tab name="board" label="📋 Board">
-    <Board specs={specs} />
-  </Tab>
-  <Tab name="list" label="📄 List">
-    <SpecList specs={specs} />
-  </Tab>
-</Tabs>
-```
-
-### Enhanced Commands
-
-**`lean-spec list`** - Interactive tree view:
-- Group by date with collapsible sections
-- Filter with `j/k` keys, select with space
-- Show inline previews (first line of spec)
-- Responsive columns that adapt to terminal width
-
-**`lean-spec stats`** - Rich dashboard:
-- Multiple panels (status, priority, tags, timeline)
-- Bar charts for distribution
-- Sparklines for trends over time
-- Color gradients for visual appeal
-
-**`lean-spec board`** - Enhanced kanban:
-- Prettier cards with rounded corners
-- Syntax-highlighted metadata
-- Drag-and-drop to change status (with arrow keys)
-- Live updates if specs change
-
-**`lean-spec search`** - Rich results:
-- Highlight matching text
-- Context snippets with line numbers
-- Preview pane for selected result
-- Fuzzy matching scores
-
-**`lean-spec timeline/gantt`** - Visual timeline:
-- Rich ASCII chart with colors
-- Milestone markers
-- Dependencies shown with lines/arrows
-- Zoom controls
-
-### Standardized UI Patterns
-
-**Panel Headers** (with rounded corners):
-```
-╭─ 📊 Spec Statistics ────────────────────────────────────╮
-│                                                          │
-│  Content here...                                         │
-│                                                          │
-╰──────────────────────────────────────────────────────────╯
-```
-
-**Tables** (auto-sized, aligned):
-```
-╭────────────────────────────┬──────────┬──────────┬────────────────╮
-│ Spec                       │  Status  │ Priority │ Tags           │
-├────────────────────────────┼──────────┼──────────┼────────────────┤
-│ 001-auth-system            │    ✅    │ high     │ api, security  │
-│ 002-ui-components          │    🔨    │ medium   │ frontend, ui   │
-│ 003-performance-opt        │    📅    │ low      │ optimization   │
-╰────────────────────────────┴──────────┴──────────┴────────────────╯
-```
-
-**Progress Bars**:
-```
-Loading specs ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 100% (26/26) ⠹
-```
-
-**Hierarchical Lists**:
-```
-📂 20251103/
-├─ 📄 001-feature-a/          ✅ high     [api, backend]
-├─ 📄 002-feature-b/          🔨 medium   [frontend]
-└─ 📄 003-feature-c/          📅 low      [docs]
-```
-
-**Status Cards**:
-```
-╭─ 📅 Planned (6) ──────────────╮
-│                               │
-│  • auth-system                │
-│    [api, security]            │
-│                               │
-│  • ui-components              │
-│    [frontend, ui]             │
-│                               │
-╰───────────────────────────────╯
-```
-
-**Key-Value Displays**:
-```
-Status:         🔨 In Progress
-Priority:       🔴 High
-Created:        2025-11-03
-Tags:           cli, ux, enhancement
-Assignee:       @alice
-```
-
-### Additional Ink Libraries
-
-Consider integrating:
-
-- **ink-box** - Beautiful boxes/panels with borders
-- **ink-gradient** - Gradient text effects
-- **ink-table** - Rich table rendering
-- **ink-spinner** - Enhanced spinners and loading states
-- **ink-select-input** - Interactive selection lists
-- **ink-text-input** - Text input for search/filter
-- **ink-progress-bar** - Progress indicators
-- **ink-big-text** - Large ASCII art text for headers
-
-## Plan
-
-### Phase 1: Component Library Foundation
-- [x] Audit current rendering patterns
-- [ ] Install additional Ink libraries (ink-box, ink-table, ink-gradient, ink-spinner, etc.)
-- [ ] Create shared component library in `src/components/ui/`:
-  - [ ] `Panel.tsx` - Rounded boxes with titles
-  - [ ] `Table.tsx` - Auto-sized table with borders
-  - [ ] `ProgressBar.tsx` - Rich progress indicator
-  - [ ] `KeyValueList.tsx` - Aligned key-value pairs
-  - [ ] `Tree.tsx` - Hierarchical tree view
-  - [ ] `StatusBadge.tsx` - Styled status indicators
-  - [ ] `Card.tsx` - Content cards with metadata
-- [ ] Document component usage patterns
-
-### Phase 2: Migrate Commands to Rich UI
-- [ ] Refactor `stats` command:
-  - [ ] Multi-panel dashboard layout
-  - [ ] Bar charts for distributions
-  - [ ] Sparklines for trends
-  - [ ] Color gradients
-- [ ] Refactor `board` command:
-  - [ ] Beautiful kanban cards with rounded corners
-  - [ ] Better column layout
-  - [ ] Interactive navigation (arrow keys)
-  - [ ] Smooth transitions
-- [ ] Refactor `list` command:
-  - [ ] Convert to Ink component
-  - [ ] Interactive tree view
-  - [ ] Collapsible date groups
-  - [ ] Filter/search capabilities
-- [ ] Refactor `search` command:
-  - [ ] Rich result cards
-  - [ ] Highlighted matches
-  - [ ] Preview pane
-  - [ ] Navigation controls
-
-### Phase 3: Interactive Features
-- [ ] Add keyboard navigation to all commands
-- [ ] Implement selection/multi-select where appropriate
-- [ ] Add live-updating displays (watch mode)
-- [ ] Add interactive filtering (press `/` to filter)
-- [ ] Add help overlays (press `?` for help)
-
-### Phase 4: Advanced Visualizations
-- [ ] Enhance `timeline` command with rich ASCII chart
-- [ ] Enhance `gantt` command with colors and dependencies
-- [ ] Add `deps` command visualization (dependency graph)
-- [ ] Add spec preview/quick view feature
-- [ ] Add diff view for spec changes
-
-### Phase 5: Polish & Testing
-- [ ] Ensure responsive layouts (80-200+ column terminals)
-- [ ] Test with various terminal emulators
-- [ ] Add loading states and transitions
-- [ ] Performance optimization for large spec counts
-- [ ] Accessibility considerations (high contrast mode)
-
-## Test
-
-### Visual Quality Tests
-- [ ] All commands render beautifully with rich UI
-- [ ] Tables auto-size correctly and align properly
-- [ ] Panels have proper rounded corners and padding
-- [ ] Colors are vibrant but not overwhelming
-- [ ] Typography is clean and readable
-
-### Interactive Tests
-- [ ] Keyboard navigation works (arrow keys, enter, esc)
-- [ ] Selection states are visually clear
-- [ ] Live updates don't cause flicker
-- [ ] Transitions are smooth
-- [ ] Help overlays appear on `?` key
-
-### Responsive Tests
-- [ ] Works in 80-column terminal (minimum)
-- [ ] Expands nicely in wide terminals (200+ columns)
-- [ ] Content doesn't overflow or wrap awkwardly
-- [ ] Tables adapt column widths intelligently
-- [ ] Mobile terminal emulators (Termux, etc.)
-
-### Terminal Compatibility
-- [ ] iTerm2 (macOS)
-- [ ] Terminal.app (macOS)
-- [ ] Windows Terminal
-- [ ] VS Code integrated terminal
-- [ ] Alacritty, Kitty, WezTerm
-- [ ] tmux/screen sessions
-
-### Performance Tests
-- [ ] 50+ specs render smoothly
-- [ ] 100+ specs don't cause lag
-- [ ] Interactive navigation is responsive
-- [ ] Live updates don't impact performance
-- [ ] Memory usage is reasonable
-
-### Edge Cases
-- [ ] Empty states look good (no specs)
-- [ ] Single spec displays properly
-- [ ] Very long spec names are truncated nicely
-- [ ] Many tags (10+) display without clutter
-- [ ] Unicode/emoji render correctly
-- [ ] Custom frontmatter fields display well
-
-### Integration Tests
-- [ ] All existing tests pass
-- [ ] Output can still be piped/redirected (fallback to plain text)
-- [ ] `--json` flags work alongside rich UI
-- [ ] CI/CD detects non-interactive terminals correctly
-- [ ] Works with `NO_COLOR` environment variable
-
-## Notes
-
-### Inspiration: Python's `rich` Library
-
-Python's `rich` is the gold standard for beautiful CLI UIs. Key features to emulate:
-
-- **Rich tables**: Auto-sized, aligned, with beautiful borders
-- **Syntax highlighting**: For code, JSON, YAML, Markdown
-- **Progress bars**: With percentage, ETA, visual appeal
-- **Panels**: Rounded boxes with titles and padding
-- **Tree views**: Hierarchical data with connecting lines
-- **Live displays**: Real-time updating without flicker
-- **Colors & gradients**: Vibrant but tasteful
-- **Typography**: Smart use of box-drawing characters
-
-### Ink Ecosystem
-
-Existing libraries to leverage:
-
-- **ink-box**: Rounded panels and boxes
-- **ink-table**: Feature-rich tables
-- **ink-gradient**: Text gradients
-- **ink-spinner**: Enhanced loading indicators
-- **ink-select-input**: Interactive lists
-- **ink-text-input**: Search/filter inputs
-- **ink-progress-bar**: Progress indicators
-- **ink-link**: Clickable terminal links
-- **ink-testing-library**: Component testing
-
-### Design Philosophy
-
-**"Rich but tasteful"** - We want beautiful, feature-rich UI that:
-- Delights users with polish and attention to detail
-- Makes information clear and scannable
-- Adds interactivity where it helps productivity
-- Looks professional and modern
-- Stays performant even with lots of data
-
-**Not** aiming for:
-- Over-the-top animations or effects
-- Complexity for complexity's sake
-- Slowness or lag
-- Unusable in non-interactive contexts
-
-### Current State Analysis
-
-**What works:**
-- Basic Ink integration for stats/board
-- Spinner for loading states
-- Color usage for status/priority
-
-**What needs improvement:**
-- Limited component reusability
-- Basic layouts (no panels, limited tables)
-- No interactivity (navigation, selection)
-- Inconsistent across commands (list uses console.log)
-- Fixed widths don't adapt to terminal
-- Missing advanced features (syntax highlighting, live updates)
-
-### Technical Considerations
-
-**Performance:**
-- Ink's React reconciliation is fast enough for our use case
-- Virtual rendering prevents full-screen redraws
-- Component memoization for optimal updates
-
-**Compatibility:**
-- Detect interactive vs non-interactive terminals
-- Fallback to plain output for pipes/redirects
-- Support `NO_COLOR` environment variable
-- Handle narrow terminals gracefully (80 col minimum)
-
-**Testing:**
-- Use ink-testing-library for component tests
-- Snapshot tests for visual regression
-- Integration tests for command output
-
-### Alternatives Considered
-
-1. **Blessed** - Lower-level, more complex, less React-like
-2. **Plain chalk/console.log** - Too simple, lacks richness
-3. **Charm's Bubble Tea (Go)** - Wrong language, but great inspiration
-4. **Textual (Python)** - Another Python rich library, good reference
-
-### Future Enhancements
-
-**Phase 2 (post-launch):**
-- Interactive spec editing (TUI editor)
-- Real-time collaboration indicators
-- Git diff visualization
-- Dependency graph visualization
-- Custom themes/color schemes
-- Plugin system for custom commands
-- Watch mode with live updates
-- Export to HTML/PDF with styling
-
-**Advanced features:**
-- Mouse support (click to navigate)
-- Split-pane views
-- Fuzzy search with live preview
-- Animated transitions
-- Sound effects (optional, for fun)
-- ASCII art banners