chore: fix content

2025-12-18 01:58:49 +00:00 · 2025-12-18 01:58:49 +00:00 · b3bd0acb7e
commit b3bd0acb7e
parent 5f51b5f2c4
4 changed files with 84 additions and 907 deletions
--- a/README.md
+++ b/README.md
@ -8,13 +8,18 @@ A powerful, standalone library and CLI tool for creating interactive forms and p

 ## Features

- **3 Backends**: CLI, TUI (Terminal UI), Web (HTTP)
 - **8 Prompt Types**: text, confirm, select, multi-select, password, custom, editor, date
- **TOML-based Forms**: Declarative UI definitions
- **Dynamic Logic**: Conditional fields, smart defaults, real-time updates
- **Multi-language**: Fluent (.ftl) and TOML translations
- **Multiple Outputs**: JSON, YAML, TOML, text formats
- **Zero Dependencies**: Works everywhere, no Nushell required
+- **Declarative Forms**: TOML-based UI definitions with fragments & composition
+- **Dynamic Logic**: Conditional fields, smart defaults, real-time validation
+- **Multi-Language Support**: Fluent (.ftl) translations with automatic locale detection
+- **Multiple Output Formats**: JSON, YAML, TOML, and Nickel output
+- **Zero Runtime Dependencies**: Core library runs anywhere, no external tools required
+- **3 Backends**: CLI (inquire), TUI (ratatui), Web (axum)
+
+### Integration Key
+
+- **Type-Safe Schemas**: Bidirectional [Nickel](https://nickel-lang.org) integration to manage configurations and settings files.<br />
+  It requires [Nickel CLI](https://nickel-lang.org/getting-started/)

 ## Quick Start

@ -43,7 +48,10 @@ just test::all
 cargo run --example form
 ```

-### CLI Example
+## Backends at a Glance
+
+### CLI Backend (inquire)
+Interactive terminal prompts for scripting and automation.

 ```bash
 # Simple prompt
@ -56,23 +64,60 @@ typedialog select "Choose role" Admin User Guest
 typedialog text "Email" --format json
 ```

-### TUI Example
+**Use for:** Scripts, CI/CD pipelines, server tools, piping between tools
+**See:** [`examples/04-backends/cli/`](examples/04-backends/cli/)

-Interactive multi-panel form:
+### TUI Backend (ratatui)
+Full terminal UI with keyboard navigation and mouse support.

 ```bash
 cargo run -p typedialog-tui --example form_with_autocompletion
 ```

-### Web Example
+**Use for:** Interactive dashboards, system administration tools, complex forms
+**See:** [`examples/04-backends/tui/`](examples/04-backends/tui/)

-Start HTTP server:
+### Web Backend (axum)
+HTTP server with browser-based forms.

 ```bash
 cargo run -p typedialog-web -- --config config/web/dev.toml
 # Open http://localhost:3000
 ```

+**Use for:** SaaS platforms, public forms, mobile-friendly interfaces
+**See:** [`examples/04-backends/web/`](examples/04-backends/web/)
+
+**Complete backend guide:** [Backend-Specific Examples](examples/04-backends/)
+
+## Nickel Integration
+
+**Type-safe configuration management** with bidirectional Nickel schema support.
+
+Generate interactive forms from Nickel schemas, collect user input, and produce validated configuration output:
+
+```bash
+# 1. Define schema in Nickel
+nickel eval config.ncl > schema.toml
+
+# 2. Run interactive form
+typedialog form schema.toml --backend tui
+
+# 3. Get validated output in any format
+# JSON, YAML, TOML, or back to Nickel with type preservation
+```
+
+**Benefits:**
+- Schema validation before/after collection
+- Type contracts enforced throughout pipeline
+- Documentation embedded in schemas
+- Deterministic configuration generation
+
+**Learn more:**
+- [Nickel Integration Guide](docs/CONFIGURATION.md#nickel-integration)
+- [Examples: 06-integrations/nickel/](examples/06-integrations/nickel/)
+- [Nickel Lang Documentation](https://nickel-lang.org/)
+
 ## Documentation

 Complete documentation in [`docs/`](docs/):
@ -83,21 +128,23 @@ Complete documentation in [`docs/`](docs/):
 | [**DEVELOPMENT.md**](docs/DEVELOPMENT.md) | Development workflows |
 | [**BUILD.md**](docs/BUILD.md) | Building & cross-compilation |
 | [**RELEASE.md**](docs/RELEASE.md) | Release process |
-| [**CONFIGURATION.md**](docs/CONFIGURATION.md) | Backend configuration |
+| [**CONFIGURATION.md**](docs/CONFIGURATION.md) | Backend & Nickel configuration |

 ## Examples

 Complete working examples in [`examples/`](examples/):

- [**01-basic**](examples/01-basic/) - Getting started
- [**02-advanced**](examples/02-advanced/) - Conditional logic
- [**03-styling**](examples/03-styling/) - Custom appearance
- [**04-backends**](examples/04-backends/) - Backend-specific examples
- [**05-fragments**](examples/05-fragments/) - Reusable components
- [**06-integrations**](examples/06-integrations/) - Nickel & i18n
- [**09-templates**](examples/09-templates/) - Production templates
+| Category | Path | Contents |
+|----------|------|----------|
+| **Getting Started** | [01-basic](examples/01-basic/) | Form syntax, sections, validation |
+| **Advanced Features** | [02-advanced](examples/02-advanced/) | Conditional logic, dynamic fields |
+| **Styling** | [03-styling](examples/03-styling/) | Themes, borders, visual design |
+| **Backends** | [04-backends](examples/04-backends/) | CLI, TUI, Web implementations |
+| **Composition** | [05-fragments](examples/05-fragments/) | Reusable components |
+| **Integrations** | [06-integrations](examples/06-integrations/) | [Nickel](examples/06-integrations/nickel/), [i18n](examples/06-integrations/i18n/) |
+| **Production** | [09-templates](examples/09-templates/) | Real-world use cases |

-See [examples/README.md](examples/README.md) for complete guide.
+**Quick start:** [examples/README.md](examples/README.md)

 ## Development

@ -187,12 +234,14 @@ typedialog/

 ## Key Technologies

- **Rust**    - Type-safe systems language
- **inquire** - Interactive prompt library
- **Ratatui** - TUI framework
- **Axum**    - Web framework
- **TOML**    - Configuration language
- **just**    - Command orchestration
+- **Rust** - Type-safe systems language
+- **inquire** - Interactive prompt library (CLI backend)
+- **Ratatui** - Terminal UI framework (TUI backend)
+- **Axum** - Web framework (Web backend)
+- **Nickel** - Type-safe configuration language (schema integration)
+- **TOML** - Form and configuration language
+- **Fluent** - Multi-language translation system
+- **just** - Command orchestration

 ## Commands at a Glance

@ -231,21 +280,20 @@ just distro::package-release    # Prepare release
 - Docker (or cargo-cross)

 ### Optional Tools
- **Nickel CLI** - For type-safe schemas
- **cargo-watch** - For hot-reload
- **cargo-cross** - For cross-compilation
+- **Nickel CLI** - For developing type-safe Nickel schemas (used with `06-integrations/nickel/` examples)
+- **cargo-watch** - For hot-reload during development
+- **cargo-cross** - For cross-compilation to other platforms

 See [docs/INSTALLATION.md](docs/INSTALLATION.md) for setup.

 ## License & Compliance

 - **Project License**: [MIT](LICENSE)
- **Dependency Licenses**: [LICENSE.md](LICENSE.md)
- **Dependency List**: [DEPENDENCIES.md](DEPENDENCIES.md)
- **SBOM (SPDX)**: [SBOM.spdx.json](SBOM.spdx.json)
- **SBOM (CycloneDX)**: [SBOM.cyclonedx.json](SBOM.cyclonedx.json)
+- **Dependency SBOM (SPDX)**: [SBOM.spdx.json](SBOM.spdx.json) - ISO/IEC 5962:2021
+- **Dependency SBOM (CycloneDX)**: [SBOM.cyclonedx.json](SBOM.cyclonedx.json) - ECMA standard
+- **Regenerate SBOMs**: `just distro::generate-sbom`

-All dependencies are compatible with MIT license.
+All dependencies are compatible with MIT license. Audit vulnerabilities: `just ci::audit`

 ## Getting Help

--- a/docs/project-definition.md
+++ b/docs/project-definition.md
@ -1,512 +0,0 @@
-# Project Definition - typedialog
-
-**Version**: 0.1.0
-**Date**: 2025-12-17
-**Status**: Production-ready, pre-publicación
-
---
-
-## Resumen Ejecutivo
-
-**Nombre Actual**: typedialog v0.1.0
-**Categoría**: Interactive Configuration Management System
-**Estado**: Production-ready, pre-publicación
-**Arquitectura**: Multi-backend Rust workspace (4 crates)
-
-**Propósito Central**: Facilitar la gestión de configuración para aplicaciones, proyectos y scripts mediante inputs interactivos (prompts individuales o forms completos), con integración bidireccional a Nickel para settings tipados y validados.
-
-**Diferenciador Único**: Único sistema en el mercado que integra Nickel schemas → Interactive collection → Multi-format output (YAML/JSON/TOML) con preservación de type contracts.
-
---
-
-## 1. Identidad del Proyecto
-
-### 1.1 Estado Actual
-
- **Nombre**: typedialog
- **Origen**: Extraído de `nu_plugin_inquire` (plugin de Nushell)
- **Etimología**: "form" + "inquire" (referencia al crate `inquire`)
- **Versión**: 0.1.0
- **Madurez**: Production-ready, 80+ tests passing, documentación completa
- **Publicación**: No publicado en crates.io aún
-
-### 1.2 Evolución Histórica
-
-```
-nu_plugin_inquire (Nushell plugin)
-    ↓
-typedialog (standalone library extraction)
-    ↓
-+ CLI backend (inquire-based)
-    ↓
-+ Nickel integration (bidirectional)
-    ↓
-+ TUI backend (ratatui)
-    ↓
-+ Web backend (axum + HTMX)
-    ↓
-Current: Multi-backend configuration management system
-```
-
-**Puntos de Inflexión**:
-1. Separación de Nushell → biblioteca standalone
-2. Adición Nickel integration → type-safe configuration focus
-3. Múltiples backends → multi-context positioning
-
-### 1.3 Descripción Técnica Precisa
-
-**Definición Formal**: Sistema de gestión de configuración interactiva que facilita la recolección, validación y transformación de settings mediante diálogo con el usuario, actuando como puente entre Nickel schemas tipados y formatos de configuración estándar (YAML/JSON/TOML), soportando múltiples interfaces (CLI/TUI/Web) para adaptarse a diferentes contextos de uso.
-
-**Componentes Core**:
- Form/Prompt engine con 8 tipos de inputs
- Nickel parser y code generator (bidirectional)
- Backend abstraction layer (trait-based)
- Template engine (Tera para metaprogramming)
- i18n system (Fluent con en-US, es-ES)
- Multi-format serialization (JSON/YAML/TOML/Nickel)
-
---
-
-## 2. Propósito y Problema que Resuelve
-
-### 2.1 Problema Space Completo
-
-**Problema Principal**: La configuración de aplicaciones, proyectos y scripts requiere:
-1. Recolección interactiva de datos del usuario
-2. Validación tipada de inputs
-3. Transformación entre formatos (schemas → forms → configs)
-4. Adaptación a diferentes contextos (CLI scripts, TUI setup, Web interfaces)
-5. Organización con componentes, templates, documentación
-
-**Problemas Secundarios**:
- Herramientas existentes limitadas a un solo backend (CLI-only o Web-only)
- No hay integración con lenguajes de configuración tipados (Nickel, KCL)
- Forms completos ineficientes para capturar un solo valor
- Prompts individuales no escalables para setup complejos
- Falta de preservación de type contracts entre transformaciones
- Configuración manual propensa a errores de tipo
-
-### 2.2 Solución Propuesta
-
-**Enfoque Único**:
-```
-Nickel Schema (typed, validated, documented)
-    ↓ [nickel-to-form]
-TOML Form Definition (declarative, reusable)
-    ↓ [interactive collection]
-User Dialog (CLI/TUI/Web según contexto)
-    ↓ [validation + transformation]
-Validated Output (JSON/YAML/TOML/Nickel)
-    ↓ [consumption]
-Application/Script/System
-```
-
-**Flexibilidad Clave**:
- **Single Prompt**: `nickelconf prompt --type password "API Key"` → captura un valor
- **Complete Form**: `nickelconf form setup.toml --backend tui` → multi-field wizard
- **Nickel Workflow**: Schema → Form → Config con type preservation
-
-### 2.3 Casos de Uso Concretos
-
-#### 1. Application Settings
- **User**: Developer configurando nueva app
- **Escenario**: Primera instalación de app Rust, necesita DB credentials, API keys, feature flags
- **Solución**: Nickel schema define settings → TUI form para setup inicial → config.yaml generado
- **Valor**: Type-safety, validación, documentación incluida en schema
-
-#### 2. Script Inputs
- **User**: DevOps engineer escribiendo Nushell script de deploy
- **Escenario**: Script necesita environment, region, instance type
- **Solución**: CLI prompts individuales integrados en script → validated JSON output
- **Valor**: Inputs validados on-the-fly, integración natural con script flow
-
-#### 3. Project Configuration
- **User**: Tech lead inicializando nuevo proyecto
- **Escenario**: Proyecto necesita 20+ settings (CI/CD, testing, deployment, monitoring)
- **Solución**: Nickel schema organizado con components → TUI complete form → project.toml
- **Valor**: Configuración completa guiada, validación, defaults inteligentes
-
-#### 4. Web-Based Setup
- **User**: SaaS admin configurando tenant
- **Escenario**: Configuración de tenant via web interface
- **Solución**: Same TOML form → Web backend → Settings guardados en DB
- **Valor**: Mismo form definition, diferente contexto de uso
-
-#### 5. Infrastructure as Code
- **User**: SRE provisionando recursos cloud
- **Escenario**: Crear configuración Terraform/Nickel para nueva infra
- **Solución**: Interactive prompts → Nickel output con contracts → Terraform consumption
- **Valor**: Type-safe IaC generation, validation antes de apply
-
---
-
-## 3. Arquitectura y Tecnología
-
-### 3.1 Tech Stack Completo
-
-**Core Language**: Rust 2021, MSRV 1.70+
-
-**Crate Structure** (Workspace):
-```
-typedialog/
-├── crates/
-│   ├── typedialog-core/     # Core library + backend trait
-│   │   ├── form engine (8 input types)
-│   │   ├── FormBackend trait
-│   │   ├── Nickel integration modules
-│   │   ├── Template engine (Tera)
-│   │   ├── i18n system (Fluent)
-│   │   └── Serialization (serde ecosystem)
-│   ├── typedialog/          # CLI binary
-│   │   └── InquireBackend impl
-│   ├── typedialog-tui/      # TUI binary
-│   │   └── RatatuiBackend impl
-│   └── typedialog-web/      # Web server binary
-│       └── AxumBackend impl
-```
-
-**Dependencies Clave**:
- `inquire` - Terminal prompts (CLI backend)
- `ratatui` + `crossterm` - Terminal UI (TUI backend)
- `axum` + `tower` - Web server (Web backend)
- `serde` ecosystem - Serialization (JSON/YAML/TOML)
- `tera` - Template engine (Jinja2-like)
- `fluent` + `fluent-bundle` - i18n/localization
- `clap` - CLI argument parsing
- `chrono` - Date/time handling
-
-**Backend Pattern** (Trait-based abstraction):
-```rust
-pub trait FormBackend {
-    fn execute_field(&mut self, field: &FormField) -> Result<Value>;
-    fn execute_form_complete(&mut self, form: &Form) -> Result<HashMap<String, Value>>;
-}
-
-// Implementations:
-impl FormBackend for InquireBackend { ... }   // CLI
-impl FormBackend for RatatuiBackend { ... }   // TUI
-impl FormBackend for AxumBackend { ... }      // Web
-```
-
-### 3.2 Características Técnicas Distintivas
-
-#### 1. Nickel Integration (Bidirectional)
- **nickel-to-form**: Parse Nickel schemas → Extract metadata → Generate TOML forms
- **form-to-nickel**: Convert form results → Generate Nickel code with contracts
- **Contract Preservation**: `std.string.NonEmpty`, `std.number.between` mantenidos
- **Component Support**: Nickel imports, merging, templates soportados
-
-#### 2. Multi-Backend Architecture
- **Same Form Definition**: Un TOML form funciona en CLI, TUI, Web
- **Identical Output**: Todos los backends producen mismo JSON/YAML/TOML
- **Display Modes**: FieldByField (step-by-step) o Complete (all at once)
- **Backend Selection**: `--backend cli|tui|web` en runtime
-
-#### 3. Form Engine Features
- **8 Input Types**: text, confirm, select, multiselect, password, custom, editor, date
- **Conditional Logic**: Fields con `depends_on` para flujo dinámico
- **Validation**: Regex, length, range, custom validators
- **Defaults**: Static, dynamic (desde otras respuestas), computed
- **Grouping**: Semantic grouping para mejor UX
-
-#### 4. i18n System
- **Fluent-based**: `.ftl` files para traducciones
- **Languages**: en-US (default), es-ES
- **Scopes**: Form UI, field labels, validation messages, help text
- **Fallback**: Graceful degradation a inglés
-
-#### 5. Template System
- **Tera Engine**: Jinja2-like syntax para metaprogramming
- **Nickel Templates**: `.ncl.j2` files para código generation
- **Variable Substitution**: Form results inyectados en templates
- **Conditionals/Loops**: Lógica de template para código complejo
-
-### 3.3 Formatos Soportados
-
-**Input Formats**:
- TOML (form definitions)
- Nickel (schemas para form generation)
-
-**Output Formats**:
- JSON (app configs, API consumption)
- YAML (configs, Kubernetes, Ansible)
- TOML (Rust configs, general settings)
- Nickel (type-safe configs con contracts)
- Plain text (simple key=value)
-
---
-
-## 4. Análisis de Mercado y Posicionamiento
-
-### 4.1 Target Audience Detallado
-
-**Audiencia Primaria**:
-
-1. **Application Developers** (40%)
-   - Stack: Rust, Go, Python apps
-   - Need: Settings management con type-safety
-   - Pain: Manual config files propensa a errores
-   - Value: Nickel schemas + interactive collection + validated output
-
-2. **Script Creators** (30%)
-   - Stack: Nushell, Bash, Python scripts
-   - Need: Interactive inputs para scripts
-   - Pain: Validación manual, error handling repetitivo
-   - Value: Validated prompts con minimal code
-
-3. **DevOps/SRE Engineers** (20%)
-   - Stack: Terraform, Kubernetes, Ansible
-   - Need: Interactive IaC generation
-   - Pain: Complex configs, no validation hasta runtime
-   - Value: Type-safe config generation, Nickel contracts
-
-4. **Project/Team Leads** (10%)
-   - Stack: Project setup, team onboarding
-   - Need: Consistent project configuration
-   - Pain: Manual setup guides, config drift
-   - Value: Reproducible project setup con forms
-
-**Audiencia Secundaria**:
- CLI tool developers agregando interactive features
- SaaS developers para user onboarding/config
- System administrators para server setup wizards
-
-### 4.2 Competitive Landscape
-
-**Categorías de Competidores**:
-
-1. **Terminal Prompt Libraries**: `inquire`, `dialoguer`, `questionary`
-   - Gap: Solo prompts, no forms. No type-safety. No multi-backend.
-
-2. **Form Libraries**: HTML forms, `react-hook-form`
-   - Gap: Web-only. No CLI/TUI. No Nickel integration.
-
-3. **Configuration Management**: Ansible, Terraform
-   - Gap: IaC-specific. No general-purpose forms. No type preservation.
-
-4. **Schema Languages**: JSON Schema, Nickel, KCL
-   - Gap: Schema definition only, no interactive collection.
-
-**Competitive Matrix**:
-
-| Feature | typedialog | inquire | HTML forms | Ansible | Nickel |
-|---------|-------------|---------|------------|---------|--------|
-| Interactive prompts | ✅ | ✅ | ❌ | ⚠️ | ❌ |
-| Complete forms | ✅ | ❌ | ✅ | ⚠️ | ❌ |
-| Multi-backend | ✅ (3) | ❌ | ❌ | ❌ | ❌ |
-| Type-safe schemas | ✅ | ❌ | ❌ | ⚠️ | ✅ |
-| Bidirectional schema | ✅ | ❌ | ❌ | ❌ | ❌ |
-| Multi-format output | ✅ (4) | ❌ | ⚠️ | ⚠️ | ✅ (1) |
-| i18n support | ✅ | ❌ | ⚠️ | ✅ | ❌ |
-| Template system | ✅ | ❌ | ❌ | ✅ | ✅ |
-| Declarative forms | ✅ | ❌ | ✅ | ⚠️ | N/A |
-
-### 4.3 Value Propositions Completo
-
-**Para Developers**:
- ✅ Type-safe configuration desde día 1 (Nickel schemas)
- ✅ Menos código de validación manual (schemas auto-validan)
- ✅ Documentación incluida en schemas (contratos son docs)
- ✅ Multi-format output (una fuente, múltiples consumidores)
-
-**Para DevOps/SRE**:
- ✅ Interactive IaC generation (menos errores de config)
- ✅ Validación antes de apply (Nickel contracts)
- ✅ Reproducible setup (TOML forms versionables)
- ✅ Script integration (CLI prompts en pipelines)
-
-**Para Organizations**:
- ✅ Consistent configuration (same forms across projects)
- ✅ Reduced onboarding time (guided setup wizards)
- ✅ Auditability (form definitions + results traceable)
- ✅ i18n support (international teams)
-
-**Unique Selling Points**:
-1. **Nickel Integration** - Único en mercado
-2. **Multi-Backend Flexibility** - Mismo form, diferentes contextos
-3. **Forms + Prompts** - No forzado a elegir uno u otro
-4. **Type-Safe Pipeline** - Contracts preserved end-to-end
-5. **Production-Ready** - i18n, templates, validación, docs
-
---
-
-## 5. Capacidades y Características
-
-### 5.1 Functional Capabilities
-
-**Input Collection**:
- ✅ 8 tipos de prompts (text, password, select, multiselect, confirm, custom, editor, date)
- ✅ Forms declarativos en TOML
- ✅ Conditional logic (depends_on)
- ✅ Dynamic defaults (computed fields)
- ✅ Validation (regex, range, length, custom)
- ✅ Help text y documentación inline
-
-**Backend Support**:
- ✅ CLI - inquire-based terminal prompts (stdin fallback)
- ✅ TUI - ratatui full-screen interface (3-panel layout, Tab navigation)
- ✅ Web - axum + HTMX browser forms (RESTful API)
- ✅ Display modes: FieldByField, Complete
-
-**Nickel Workflow**:
- ✅ nickel-to-form: Schema → TOML form generation
- ✅ form execution: Interactive collection
- ✅ form-to-nickel: Results → Nickel code generation
- ✅ Contract preservation: Type constraints maintained
- ✅ Component support: Imports, merging, templates
-
-**Output Formats**:
- ✅ JSON (structured data, API consumption)
- ✅ YAML (configs, k8s, ansible)
- ✅ TOML (rust configs, settings)
- ✅ Nickel (type-safe configs)
- ✅ Text (simple key=value)
-
-**i18n & Templates**:
- ✅ Fluent-based localization (en-US, es-ES)
- ✅ Tera template engine
- ✅ Nickel template metaprogramming (.ncl.j2)
- ✅ Variable substitution
- ✅ Conditional rendering
-
-### 5.2 Non-Functional Capabilities
-
-**Performance**:
- Fast compilation (Rust, release build <30s)
- Low memory footprint (CLI <5MB, TUI <10MB)
- Minimal startup time (<100ms)
-
-**Reliability**:
- 80+ passing tests (unit + integration)
- Type-safe Rust (no runtime crashes)
- Graceful error handling
- Fallback behaviors (stdin, default values)
-
-**Usability**:
- Intuitive TOML form syntax
- Clear error messages
- Help text contextual
- i18n for international users
-
-**Maintainability**:
- Modular workspace structure
- Clean trait-based architecture
- Comprehensive documentation
- Example forms included
-
-**Portability**:
- Cross-platform (Linux, macOS, Windows)
- Single binary distribution
- No runtime dependencies
- Docker support
-
---
-
-## 7. Métricas y Success Criteria
-
-### 7.1 Technical Metrics
-
-**Code Quality**:
- Test coverage > 80%
- Zero clippy warnings (enforce)
- Clean compilation all features
- Documentation coverage > 90%
-
-**Performance**:
- Binary size < 15MB (release)
- Startup time < 100ms
- Memory usage < 20MB (TUI)
- Form rendering < 50ms
-
-### 7.2 Adoption Metrics
-
-**Community**:
- GitHub stars > 100 (first 6 months post-publish)
- crates.io downloads > 1000/month
- Active issues/PRs
- Contributor growth
-
-**Usage**:
- Example forms created by users
- Integration stories shared
- Blog posts/tutorials written
- Conference talks
-
-### 7.3 Quality Metrics
-
-**Reliability**:
- Bug reports < 5/month
- Critical bugs = 0
- Response time < 48h
- Fix time < 7 days (non-critical)
-
-**User Satisfaction**:
- Positive feedback ratio > 80%
- Feature request alignment
- Documentation clarity
- Ease of use reports
-
---
-
-## 8. Roadmap y Future Considerations
-
-### 8.1 Immediate Focus (v0.1.x)
-
-**Naming Decision**:
- Decide: nickelconf vs nickeltalk vs keep typedialog
- Execute: Rename if chosen
- Update: All documentation and messaging
-
-**Stabilization**:
- Bug fixes from early users
- Documentation improvements
- Example forms expansion
- Performance optimizations
-
-### 8.2 Near-term Enhancements (v0.2.x)
-
-**Nickel Enhancements**:
- Deeper schema introspection
- More contract types supported
- Component template library
- Schema validation improvements
-
-**Backend Improvements**:
- TUI navigation enhancements
- Web backend styling/theming
- CLI colored output options
- Performance optimizations
-
-**New Features**:
- Form composition (reusable sections)
- Field dependencies (advanced logic)
- Custom validators library
- Plugin system for custom fields
-
-### 8.3 Long-term Vision
-
-**Ecosystem**:
- Form marketplace (shared forms)
- IDE integrations (VSCode extension)
- CI/CD integrations
- Cloud service (hosted forms)
-
-**Technology**:
- KCL integration (like Nickel)
- CUE language support
- GraphQL schema support
- Database schema integration
-
-**Beyond Configuration**:
- Survey/questionnaire system
- User onboarding workflows
- Admin panel generation
- API client generation
-
---
-
-## Conclusión
-
-typedialog es un proyecto maduro y bien posicionado que resuelve un problema real en la gestión de configuración. Su diferenciador único - la integración bidireccional con Nickel combinada con múltiples backends - lo posiciona de manera única en el mercado.
-
-El próximo paso crítico es una decisión de naming estratégica que refuerce esta posición única y comunique claramente el valor propuesto al mercado target.
--- a/docs/project-naming-analysis.md
+++ b/docs/project-naming-analysis.md
@ -1,359 +0,0 @@
-# Project Naming and Positioning Analysis
-
-**Version**: 1.0
-**Date**: 2025-12-17
-**Status**: Ready for decision
-
---
-
-## Executive Summary
-
-The current name **"typedialog"** undersells the project's unique value proposition. A strategic rename would better communicate the distinctive capabilities to the target market.
-
-**Key Finding**: Nickel integration is THE unique differentiator. Any new name should prominently feature Nickel while maintaining flexibility for the multi-backend and interactive aspects.
-
---
-
-## Problems with "typedialog"
-
-### 1. Backend-Specific Reference
- Name tied to `inquire` crate (just one of three backends)
- Misleading now that project has ratatui (TUI) and axum (Web) backends
- Doesn't reflect the multi-backend architecture innovation
-
-### 2. Form-Centric Positioning
- "form" emphasizes only forms, not prompts/single inputs
- Inaccurate: project equally supports individual prompts and complete forms
- Creates false expectation of form-only capability
-
-### 3. Missing Nickel Integration
- **CRITICAL**: No communication of THE unique differentiator
- Nickel integration is unique in the market - no competitor combines this
- Name should signal this exclusive feature
-
-### 4. Generic Sound
- "typedialog" sounds like "just another form library"
- Fails to communicate type-safety, configuration focus, or multi-backend capability
- Doesn't differentiate from competitive offerings (dialoguer, inquire, etc.)
-
-### 5. Hidden Value Propositions
- No hint at: interactive dialog, bridge between schemas/formats, facilitator role
- Configuration management focus not obvious
- App/project scope not apparent
-
---
-
-## Strategic Positioning Requirements
-
-### Dimensions to Communicate (by priority)
-
-1. **Nickel Integration** (MUST) - THE unique differentiator, único en mercado
-2. **Interactivo/Diálogo** (SHOULD) - Facilita mediante conversación con usuario
-3. **Bridge** (SHOULD) - Puente entre schemas, formatos, humano-máquina
-4. **Configuration/Settings** (SHOULD) - Core purpose
-5. **Flexibility** (NICE) - Forms Y prompts - no solo uno
-6. **Type-safety** (NICE) - Quality attribute from Nickel
-7. **Facilitador** (NICE) - Simplifica la gestión
-8. **Wide scope** (NICE) - Apps, scripts, DevOps - no limitado
-9. **Memorable** (MUST) - Pronounceable, distinctive
-
-**Key Constraint**: Es imposible capturar TODOS los aspectos en un nombre. El nombre debe priorizar los top 2-3 elementos y el positioning/messaging cubre el resto.
-
---
-
-## Top 3 Finalists
-
-### Option 1: **nickelconf** ⭐ PRIMARY RECOMMENDATION
-
-**Etymology**: "nickel" (core tech) + "conf" (configuration)
-
-#### Coverage Analysis
-```
-Nickel integration        ✅✅ Explicit (primary identifier)
-Interactivo/Diálogo      ❌  Messaging-covered
-Bridge                   ❌  Messaging-covered
-Configuration/Settings   ✅✅ Explicit (primary purpose)
-Flexibility              ✅  Neutral (conf = flexible container)
-Type-safety              ✅  Implicit (via Nickel)
-Facilitador              ⚠️  Neutral
-Wide scope               ✅  No limita dominio
-Memorable                ✅✅ Short, pronounceable, clear
-────────────────────────────────────────────────
-SCORE: 7/9 explicit + 2/9 via messaging = STRONG
-```
-
-#### Strengths
- Directly signals Nickel integration (THE key differentiator)
- Clear configuration/settings focus
- Not limited to "forms" (conf is neutral, covers prompts too)
- Short, memorable, pronounceable, technical but accessible
- Professional, credible positioning
- Clean crate names: `nickelconf-core`, `nickelconf-cli`, `nickelconf-tui`, `nickelconf-web`
-
-#### Weaknesses
- Interactive/dialog aspect relies on messaging
- Bridge concept must be conveyed in positioning/docs
-
-#### Positioning
-> "Interactive configuration powered by Nickel - bridging schemas and settings"
-
-#### Key Messaging
- "Dialoga con el usuario para configurar apps y proyectos con tipos validados"
- "Bridge: Nickel schemas → Interactive prompts/forms → YAML/JSON/TOML output"
- "Facilita settings tipados - single prompts o forms completos según necesidad"
- "CLI para scripts, TUI para setup, Web para interfaces - mismo config, diferentes contextos"
-
-#### Use Case Examples
- **Single prompt**: `nickelconf prompt --type password "API Key"` → captura un valor
- **Complete form**: `nickelconf form app-config.toml --backend tui` → multi-field setup
- **Nickel workflow**: `nickelconf nickel-to-form schema.ncl` → generates form from Nickel schema
- **Script integration**: Nushell/Bash scripts call `nickelconf` for validated inputs
- **Multi-format output**: Same input → JSON/YAML/TOML/Nickel depending on use
-
---
-
-### Option 2: **nickeltalk** ⭐ STRONG ALTERNATIVE
-
-**Etymology**: "nickel" (core tech) + "talk" (dialogue/interaction)
-
-#### Coverage Analysis
-```
-Nickel integration        ✅✅ Explicit (primary identifier)
-Interactivo/Diálogo      ✅✅ Explicit ("talk" = dialogue)
-Bridge                   ⚠️  Implied (talk = communication bridge)
-Configuration/Settings   ⚠️  Messaging-required
-Flexibility              ✅  Neutral (talk cubre prompts y forms)
-Type-safety              ✅  Implicit (via Nickel)
-Facilitador              ✅  Implicit (talk = facilita comunicación)
-Wide scope               ✅  No limita dominio
-Memorable                ✅  Short, pronounceable, friendly
-────────────────────────────────────────────────
-SCORE: 7/9 explicit + 2/9 via messaging = STRONG
-```
-
-#### Strengths
- Captures both top priorities: Nickel + Interactive/Dialog
- "Talk" enfatiza el aspecto de diálogo/conversación con usuario
- Friendly, approachable, less intimidating than "conf"
- Still short and memorable
- Implies facilitation and bridge (communication is connection)
- More distinctive than nickeLconf (fewer "talk" tools in ecosystem)
-
-#### Weaknesses
- "Talk" might sound less serious/technical than "conf"
- Configuration purpose less obvious (needs messaging)
- Could be mistaken for chat/AI tool rather than config tool
- Slightly less clear positioning
-
-#### Positioning
-> "Talk to Nickel - Interactive type-safe configuration through dialogue"
-
-#### Key Messaging
- "Conversa con Nickel para configurar apps y proyectos"
- "Dialog-driven configuration: prompts, forms, type-safe settings"
- "Bridge schemas and formats through interactive dialogue"
- "Nickel schemas → Interactive talk → YAML/JSON/TOML output"
-
-#### Best For
- If emphasizing UX and developer experience over technical positioning
- Projects that want friendlier, more approachable branding
- Organizations focused on ease-of-use
-
---
-
-### Option 3: **nickelbridge**
-
-**Etymology**: "nickel" (core tech) + "bridge" (connection/intermediary)
-
-#### Coverage Analysis
-```
-Nickel integration        ✅✅ Explicit
-Interactivo/Diálogo      ⚠️  Implied (bridge connects human & machine)
-Bridge                   ✅✅ Explicit (primary metaphor)
-Configuration/Settings   ⚠️  Messaging-required
-Flexibility              ✅  Neutral
-Type-safety              ✅  Implicit
-Facilitador              ✅  Implicit (bridge = facilitates)
-Wide scope               ✅  No limita dominio
-Memorable                ⚠️  Longer (3 syllables, but clear)
-────────────────────────────────────────────────
-SCORE: 6/9 explicit + 3/9 via messaging = GOOD
-```
-
-#### Strengths
- Explicitly captures bridge metaphor (schemas ↔ formats, human ↔ machine)
- Nickel prominently featured
- Professional, technical positioning
- Clearly a facilitator/connector
-
-#### Weaknesses
- "Bridge" is overused in tech naming (less distinctive)
- Longer word (12 characters vs 10 for nickelconf)
- Interactive aspect less obvious
- Configuration purpose needs heavy messaging
-
-#### NOT RECOMMENDED
-Less distinctive, longer, loses some positioning clarity compared to top 2 options.
-
---
-
-## Decision Matrix
-
-| Criterion | nickelconf | nickeltalk | nickelbridge |
-|-----------|-----------|-----------|----------|
-| Nickel prominence | ✅✅ | ✅✅ | ✅✅ |
-| Interactive aspect | ❌ | ✅✅ | ⚠️ |
-| Config focus | ✅✅ | ⚠️ | ⚠️ |
-| Memorability | ✅✅ | ✅ | ✅ |
-| Distinctiveness | ✅ | ✅✅ | ⚠️ |
-| Professional tone | ✅✅ | ✅ | ✅✅ |
-| Approachability | ✅ | ✅✅ | ⚠️ |
-| Future-proofing | ✅ | ✅ | ✅ |
-
---
-
-## Decision Framework
-
-### Choose nickelconf if:
- Configuration/settings focus is most important to your positioning
- Want maximum technical credibility with developers
- Emphasize type-safety and contracts as primary value
- Prefer professional/serious tone
- Target: Infrastructure, DevOps, technical users
-
-### Choose nickeltalk if:
- Interactive/dialog aspect is most important
- Want friendly, approachable, UX-focused positioning
- Emphasize ease-of-use and developer experience
- Prefer conversational/accessible tone
- Target: Broader audience, emphasize usability
-
-### Choose nickelbridge if:
- Bridge/connector metaphor is critical to your story
- Emphasize interoperability (schemas ↔ formats) over other aspects
- Professional but with strong facilitator positioning
- Comfortable with longer name
-
---
-
-## Recommendation: nickelconf ⭐
-
-### Rationale
-
-1. **Captures core identity**: Nickel (unique differentiator) + Config (core purpose) = clear positioning
-2. **Professional positioning**: Credible with technical audiences (developers, DevOps, architects)
-3. **Easy to explain**: "Type-safe configuration with Nickel" - immediately clear
-4. **Messaging flexibility**: Interactive, bridge, facilitator aspects easily conveyed in docs/positioning
-5. **Technical soundness**: Appeals to type-conscious developers and infrastructure engineers
-6. **Future-proof**: Name doesn't limit scope if expanding to other schema languages later
-
-### Alternative: nickeltalk
-
-Strong alternative if your organization prioritizes:
- User experience and approachability
- Developer delight and friendly positioning
- Market differentiation through accessibility
-
-Both are viable. The choice depends on whether you lead with **technical credibility** (nickelconf) or **user experience** (nickeltalk).
-
---
-
-## Implementation Path (if renaming)
-
-### Complexity: Complex
- Full workspace rename with dependencies
- Import path updates
- Binary artifact renames
- Documentation overhaul
-
-### Tasks Required
-1. Workspace `Cargo.toml` rename (precedes member crate renames)
-2. All internal imports across crates
-3. Binary artifacts in build scripts
-4. All documentation files
-5. Configuration paths (if hardcoded)
-6. Examples and templates
-7. Repository name (GitHub)
-8. Migration guide for any existing users
-
-### Risks
- Breaking existing users (unlikely given v0.1.0 status)
- Loss of existing references/documentation links
- SEO reset if already indexed
-
-### Mitigations
-1. Version bump to 0.2.0 (signals breaking change)
-2. Maintain `typedialog` as deprecated alias
-3. Create migration guide
-4. Comprehensive search/replace validation
-
-### Validation
-```bash
-# Must pass before release
-cargo check --all-targets --all-features
-cargo test --all-targets --all-features
-cargo build --release --all-targets
-cargo clippy -- -D warnings
-
-# Smoke tests
-nickelconf --version
-nickelconf-tui --version
-nickelconf-web --version
-```
-
---
-
-## Alternative: Enhanced Positioning (Keep typedialog)
-
-If rebranding costs outweigh benefits:
-
-### Approach
-1. Rewrite README with multi-backend focus
-2. Emphasize Nickel integration prominently
-3. Clarify not just an inquire wrapper
-4. Document multi-context use cases
-5. Create positioning explainer
-
-### Challenges
- Name still references one backend (confusing)
- Harder to communicate innovation without name change
- Missing strategic positioning opportunity
-
-### Benefits
- Zero technical disruption
- No migration costs
- Maintains existing references
- Faster execution
-
---
-
-## Naming Alternatives Analyzed (not recommended)
-
-### Considered but Rejected
-
- **formstack**: Exists as company (Formstack.com), trademark risk
- **formulate**: Good name but loses Nickel prominence
- **omniform**: Premium positioning but longer, less clear
- **formkit**: Conflicts with Vue.js FormKit library
- **formspec**: Clear but generic, doesn't emphasize Nickel
- **dialogconf**: Loses Nickel in name (critical mistake)
- **confkit**: Generic, doesn't differentiate with Nickel
-
---
-
-## Conclusion
-
-**nickelconf** is the recommended path forward. It clearly communicates the two most important aspects of the project (Nickel + Configuration) while remaining short, memorable, and technical.
-
-The secondary messaging around interactive dialog, bridge functionality, and facilitator role can be effectively conveyed through positioning statements, documentation, and examples.
-
-This strategic rename would:
-1. Immediately signal the unique market position
-2. Attract the right target audience
-3. Support long-term branding and differentiation
-4. Enable clearer communication of value proposition
-5. Position the project for successful market launch
-
-**Decision needed**: nickelconf vs nickeltalk vs keep typedialog
-
-The choice between nickelconf and nickeltalk depends on whether you prioritize **technical credibility** or **user experience** in your positioning.
--- a/4
+++ b/4
@ -12,8 +12,8 @@ mod ci "justfiles/ci.just"          # CI/CD pipeline (validate, test, build)
 mod distro "justfiles/distro.just"  # Distribution & packaging (release, cross-compile)

 # === SHARED VARIABLES ===
-WORKSPACE_ROOT := justfile_directory()
-CRATES := "typedialog-core typedialog typedialog-tui typedialog-web"
+# WORKSPACE_ROOT := justfile_directory()
+# CRATES := "typedialog-core typedialog typedialog-tui typedialog-web"

 # === ORCHESTRATION RECIPES ===