diff --git a/README.md b/README.md
index 3e2d569..dcf0352 100644
--- 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.
+ 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
diff --git a/docs/project-definition.md b/docs/project-definition.md
deleted file mode 100644
index 4ea5e48..0000000
--- a/docs/project-definition.md
+++ /dev/null
@@ -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;
- fn execute_form_complete(&mut self, form: &Form) -> Result>;
-}
-
-// 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.
diff --git a/docs/project-naming-analysis.md b/docs/project-naming-analysis.md
deleted file mode 100644
index 08521be..0000000
--- a/docs/project-naming-analysis.md
+++ /dev/null
@@ -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.
diff --git a/justfile b/justfile
index 881d169..cdb0f20 100644
--- a/justfile
+++ b/justfile
@@ -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 ===