svelte-kit-vice/routes/web/marketing.md

# Active Ecosystem

## Enfoque de contenido

Active es un ecosistema para construir aplicaciones Svelte con una separacion clara entre
runtime de aplicacion y runtime de interfaz.

La forma mas honesta de venderlo en la web es esta:

> Active no es solo una coleccion de componentes. Es una arquitectura de producto para crear
> aplicaciones reactivas, semanticas y mantenibles, con un nucleo pequeño, servicios opt-in e
> interfaces que entienden lo que ocurre.

El ecosistema se divide en dos areas principales:

- **ActiveApp**: el runtime de aplicacion. Organiza servicios, preferencias, logging, eventos,
  sesiones, almacenamiento, permisos, cache, HTTP, conexiones y orquestacion.
- **ActiveUix**: el runtime de interfaz. Define componentes desde contratos estructurales,
  comportamiento headless, semantica de eventos, accesibilidad, preferencias sensoriales y capa
  visual.

La venta debe apoyarse en una idea central: Active reduce acoplamiento sin renunciar a una
experiencia rica. Cada modulo tiene una responsabilidad concreta, cada servicio se declara de forma
explicita y la interfaz deja de ser una suma de divs para convertirse en una superficie semantica.

## Mensaje principal

### Claim corto

**Construye aplicaciones que saben que estan haciendo.**

### Subclaim

Un ecosistema Svelte para componer servicios de aplicacion e interfaces semanticas con contratos
claros, dependencias limitadas y una arquitectura preparada para crecer sin convertirse en una masa
de estado, estilos y efectos.

### Hero copy

**Active Ecosystem**

Aplicaciones reactivas, interfaces semanticas y servicios componibles sobre un nucleo pequeño.

Active une dos capas complementarias:

- **ActiveApp**, para el runtime, los servicios y la orquestacion de la aplicacion.
- **ActiveUix**, para componentes accesibles, visuales y semanticamente expresivos.

El resultado es una base de producto donde el estado, los eventos, las preferencias, los estilos y
los servicios no compiten entre si: colaboran bajo contratos explicitos.

### CTAs sugeridos

- Explorar ActiveApp
- Ver ActiveUix
- Revisar arquitectura
- Abrir componentes
- Ver modulos

## Propuesta de valor

Active esta pensado para equipos que necesitan algo mas que una libreria visual. El objetivo no es
solo pintar componentes bonitos, sino construir una plataforma de aplicacion donde cada parte tenga
un lugar:

- los servicios viven en ActiveApp,
- la estructura de los componentes vive en Morfo,
- el comportamiento vive en Soma,
- la semantica de eventos vive en Sema,
- la experiencia visual vive en Eidos,
- las mutaciones DOM transversales pasan por ADom,
- la composicion global ocurre en ActiveUix.

Esta separacion permite evolucionar la aplicacion sin meter autenticacion, cache, permisos,
validacion, temas, componentes, sonidos, haptica, foco y eventos en el mismo saco.

## Las dos areas del ecosistema

### ActiveApp

ActiveApp es la capa de composicion de aplicacion. Su trabajo es crear un runtime estable y
predecible, con un core fijo y servicios declarados de forma explicita.

El core de ActiveApp cubre:

- **Logger**: diagnostico, niveles, transporte y eventos de observabilidad.
- **Bus**: comunicacion interna tipada entre partes del runtime.
- **Timers**: planificacion determinista para intervalos, timeouts y tareas reactivas.
- **Orca**: orquestacion de flujos y presets de aplicacion.
- **Prefs**: preferencias transversales como direccion, movimiento, sonido y haptica.

Sobre ese core se componen servicios opt-in. Si una aplicacion no declara cache, auth o
connections, esos servicios no existen en su superficie publica. La arquitectura evita cargar
capacidad por defecto solo porque podria usarse algun dia.

#### Servicios destacados de ActiveApp

- **Langs**: internacionalizacion, codigos BCP47, plurales, textos y referencias localizadas.
- **Format**: numeros, moneda, unidades, fechas y formatos dependientes de locale.
- **ADom**: escritura DOM controlada para atributos, preferencias, scroll lock y entorno visual.
- **Clipboard**: capacidad de copia con adaptadores inyectables.
- **Sium**: validacion de esquemas, issues tipados, introspeccion y compatibilidad con contratos de
  schema.
- **Storage**: almacenamiento reactivo, adaptadores, migraciones, TTL, validacion y sincronizacion.
- **HTTP**: resultados tipados, hooks, retry, timeouts, validacion y fetch compatible con SvelteKit.
- **Session**: adopcion, refresh, revocacion, rescate de 401 y puente SSR/cookie.
- **Connections**: realtime, transports, reconexion, heartbeat, channels y request/reply.
- **Auth**: flujos de autenticacion, CSRF, sesiones, dispositivos y handlers de servidor.
- **Perm**: autorizacion, politicas, snapshots, cache de permisos y helpers de UI.
- **Cache**: claves, scopes, politicas, stale/revalidate, tags y adaptadores.

#### Argumento de venta

ActiveApp da una forma clara de montar el backend emocional de la aplicacion: todo eso que no se ve
en una captura, pero que decide si el producto escala bien o se rompe por dentro.

No obliga a usar todos los modulos. Permite componer solo los servicios necesarios, con errores
tipados, diagnostico comun y dependencias visibles.

### ActiveUix

ActiveUix es la capa donde la interfaz se vuelve sistema. No se limita a exportar componentes:
define como se estructuran, como se comportan, como emiten significado, como se tematizan y como se
integran con preferencias globales de la aplicacion.

ActiveUix organiza la UI en capas:

- **Morfo**: contrato estructural de cada componente.
- **Soma**: comportamiento headless, estado, foco, teclado, puntero y accesibilidad.
- **Sema**: semantica de eventos, intenciones, familias y canales sensoriales.
- **Eidos**: capa visual, tokens, temas, recetas y CSS.
- **ADom**: ejecucion controlada de mutaciones transversales en el DOM.
- **ActiveUix**: composicion de servicios UI y puente con ActiveApp.

#### Argumento de venta

ActiveUix permite crear componentes que no dependen de una estetica fija ni de una demo aislada. Un
componente tiene contrato DOM, semantica, comportamiento, accesibilidad y visualizacion por capas.

Eso permite cambiar el tema sin cambiar el comportamiento, cambiar el comportamiento sin romper la
semantica y conectar eventos visuales, sonoros o hapticos sin mezclar efectos dentro del componente.

## La arquitectura semantica

Uno de los puntos diferenciales de ActiveUix es que los eventos no son solo callbacks.

Sema define un vocabulario para expresar que ha pasado y como deberia sentirse:

- **Familias**: contacto, confirmacion, señal, manejo, aparicion, cambio y sostenimiento.
- **Intenciones**: neutral, afirmacion, cumplimiento, riesgo, amenaza y perdida.
- **Canales**: visual, sonido y haptica.

Un boton no solo ejecuta `onClick`. Puede emitir una accion de contacto, una confirmacion, una señal
de riesgo o una respuesta de cumplimiento. Esa informacion se puede proyectar a:

- atributos `data-event-*` temporales,
- animaciones visuales,
- feedback sonoro,
- feedback haptico,
- logs de interaccion,
- pruebas de comportamiento.

Esta capa semantica es clave para vender ActiveUix como algo superior a un kit visual. La interfaz
no solo muestra estado: comunica significado.

## Morfo: contratos antes que improvisacion

Morfo define la forma publica de los componentes:

- partes del componente,
- atributos `data-*`,
- estados DOM,
- roles ARIA,
- reglas de foco,
- eventos esperados,
- textos y traducciones,
- variantes estructurales.

La idea comercial:

> Cada componente tiene una anatomia documentada. No dependes de mirar el CSS o el HTML generado
> para entender como integrarlo, testearlo o extenderlo.

Morfo es especialmente importante para una web de marketing porque permite explicar que ActiveUix no
vende componentes opacos. Vende componentes con contrato.

## Soma: comportamiento sin encierro visual

Soma contiene el comportamiento de los componentes:

- estado,
- contexto,
- navegacion por teclado,
- puntero,
- focus management,
- accesibilidad,
- seleccion,
- apertura/cierre,
- sincronizacion con formularios,
- emision de eventos semanticos.

La venta:

> Soma permite que la logica de un componente sea reutilizable y testeable sin atarla a una capa
> visual concreta.

Esto habilita componentes headless, adaptables a temas, densidades, modos y experiencias distintas.

## Eidos: visuales con contrato

Eidos es la capa visual del ecosistema UIX. Gestiona:

- tokens,
- temas,
- modos claro/oscuro,
- densidades,
- roles visuales,
- recetas de componente,
- CSS generado o externo,
- custom properties,
- adaptacion visual desde atributos DOM.

La clave de venta:

> Eidos no secuestra la interfaz. La estiliza a partir de contratos.

Un componente puede exponer estados por Morfo y Soma, emitir significado por Sema y dejar que Eidos
traduzca todo eso en una experiencia visual consistente.

## ActivePrefs: preferencias transversales

Active separa preferencias transversales y preferencias visuales:

- **Direccion**: `ltr` o `rtl`.
- **Motion**: comportamiento de movimiento y reduccion de animacion.
- **Sound**: activacion o silencio de feedback sonoro.
- **Haptic**: activacion o desactivacion de feedback tactil.
- **Theme, mode y density**: pertenecen a Eidos como preferencias visuales.

Esta separacion evita que el sistema visual se convierta en dueño de toda la experiencia. La app
puede decidir preferencias globales, y la UI puede interpretarlas sin acoplarse al resto del
runtime.

## Dependencias limitadas

Active esta pensado con una filosofia de dependencias contenidas:

- nucleo pequeño,
- servicios opt-in,
- imports separados por capas,
- factories explicitas,
- contratos antes que dependencias directas,
- separacion entre runtime de aplicacion y runtime de interfaz,
- modulos que no aparecen en el tipo publico si no se declaran,
- integraciones por adaptadores cuando una capacidad depende del entorno.

La idea para la web:

> Active no intenta ganar por acumulacion. Gana por composicion.

En lugar de arrastrar auth, cache, permisos, realtime, validacion y componentes en un unico paquete
mental, cada modulo tiene una entrada clara y una responsabilidad concreta.

## Observabilidad y diagnostico

Active usa logging y diagnostico como parte de la arquitectura, no como un añadido posterior.

Puntos a destacar:

- logger compartido,
- eventos diagnosticos tipados,
- catalogos de errores,
- servicios con estado `absent`, `present` o `failed`,
- errores especificos por artefacto,
- integracion con flujos de aplicacion,
- capacidad de registrar fallos de configuracion, validacion o entorno.

Para venderlo:

> Cuando una aplicacion crece, no basta con que funcione. Tiene que explicar que esta pasando.

## SSR, cliente y servidor

Active diferencia entre motores de cliente, servicios activos y contrapartes de servidor cuando
tiene sentido.

Ejemplos:

- autenticacion con handlers de servidor,
- permisos con motor y politicas,
- cache con contratos de scope y revalidacion,
- HTTP compatible con SvelteKit,
- sesion capaz de integrarse con cookies y SSR,
- conexiones realtime con puente de sesion.

Esto permite presentar Active como una base para aplicaciones reales, no solo para demos de
componentes.

## Modulos del ecosistema

### ActiveApp Core

| Modulo | Papel | Mensaje para web |
| --- | --- | --- |
| Logger | Diagnostico comun | Observabilidad integrada desde el inicio. |
| Bus | Comunicacion interna | Eventos internos sin acoplar modulos. |
| Timers | Planificacion | Tareas reactivas y temporales bajo control. |
| Orca | Orquestacion | Flujos y presets componibles para la app. |
| Prefs | Preferencias transversales | Direccion, motion, sound y haptic sin mezclar UI y app. |

### Servicios ActiveApp

| Modulo | Papel | Mensaje para web |
| --- | --- | --- |
| Langs | Idioma y textos | Internacionalizacion como servicio activo. |
| Format | Formatos regionales | Numeros, moneda, unidades y fechas coherentes con locale. |
| ADom | DOM transversal | Mutaciones globales controladas, no efectos dispersos. |
| Clipboard | Copia | Capacidades del navegador encapsuladas. |
| Sium | Validacion | Schemas, issues e introspeccion con contratos tipados. |
| Storage | Persistencia | Almacenamiento reactivo, validado y migrable. |
| HTTP | Red | Resultados tipados, retry, timeout, hooks y validacion. |
| Session | Sesion | Refresh, adopcion, revocacion y rescate de sesion. |
| Connections | Realtime | Canales, reconexion, heartbeat y mensajeria. |
| Auth | Autenticacion | Flujos de login, CSRF, dispositivos y handlers. |
| Perm | Permisos | Politicas, autorizacion y helpers de UI. |
| Cache | Cache | Revalidacion, tags, scopes y adaptadores. |

### ActiveUix

| Capa | Papel | Mensaje para web |
| --- | --- | --- |
| Morfo | Anatomia del componente | Contrato DOM, partes, datos, ARIA y estructura. |
| Soma | Logica headless | Estado, foco, teclado, puntero y accesibilidad. |
| Sema | Semantica de eventos | Interacciones con familia, intencion y canal. |
| Eidos | Visual system | Tokens, temas, recetas y CSS por contrato. |
| ADom | Mutacion DOM | Aplicacion controlada de preferencias y atributos. |
| ActiveUix | Composicion UI | Runtime de interfaz conectado o standalone. |

## Diferenciadores

### Frente a una libreria de componentes tradicional

Una libreria clasica suele partir del aspecto visual. ActiveUix parte del contrato:

- primero define la anatomia,
- despues el comportamiento,
- despues la semantica,
- despues la expresion visual.

Eso reduce el riesgo de que cada componente invente sus propios atributos, estados, eventos y
convenciones.

### Frente a un framework de aplicacion cerrado

ActiveApp no fuerza una unica forma de aplicacion. Propone una composicion explicita:

- core estable,
- servicios declarados,
- factories por capacidad,
- lazy loading cuando procede,
- diagnostico compartido,
- tipos que reflejan lo que realmente se ha instalado.

La app no tiene que cargar con modulos que no usa.

### Frente a una capa visual sin runtime

Un sistema de tokens por si solo no resuelve:

- sesion,
- permisos,
- cache,
- validacion,
- logging,
- conexiones,
- preferencias,
- semantica de eventos,
- comportamiento headless.

Active ofrece una historia completa: aplicacion mas interfaz.

## Mensajes por audiencia

### Para producto

Active permite construir experiencias coherentes sin rediseñar la arquitectura cada vez que aparece
un nuevo requisito. El producto puede crecer en modulos: autenticacion, permisos, cache,
internacionalizacion, realtime o feedback sensorial sin mezclar responsabilidades.

### Para frontend

ActiveUix da componentes con anatomia, comportamiento, semantica y visuales separados. Eso ayuda a
testear, tematizar, adaptar y mantener interfaces complejas sin convertir cada componente en una
pieza aislada.

### Para arquitectura

ActiveApp centraliza servicios y observabilidad bajo contratos explicitos. Las dependencias son
visibles, los servicios son opt-in y el tipo publico de la app refleja lo que se ha compuesto.

### Para diseño

Eidos permite que el sistema visual lea estados y contratos, no implementaciones internas. Los temas,
densidades y modos se aplican sobre una estructura comun.

### Para accesibilidad

Soma y Morfo colocan foco, teclado, roles, atributos y estados en el centro del componente. La
accesibilidad no es una revision final: forma parte de la arquitectura.

## Copy reutilizable para la web

### Bloque 1: dos areas, un ecosistema

Active se divide en dos areas que trabajan juntas:

**ActiveApp** organiza los servicios de aplicacion. **ActiveUix** organiza la experiencia de
interfaz.

Una se ocupa de la infraestructura viva del producto. La otra se ocupa de que cada componente tenga
estructura, comportamiento, semantica y visuales coherentes.

### Bloque 2: servicios opt-in

No todos los proyectos necesitan las mismas capacidades. Active permite declarar solo los servicios
que la aplicacion necesita: auth, cache, permisos, HTTP, storage, session, realtime, format o langs.

Si un servicio no se declara, no contamina la superficie publica de la app.

### Bloque 3: interfaz semantica

ActiveUix entiende que una interaccion no es solo un click. Puede ser contacto, confirmacion, riesgo,
perdida, exito o cambio sostenido.

Esa semantica puede alimentar visuales, sonido, haptica, diagnostico y pruebas.

### Bloque 4: visuales sin acoplamiento

Eidos convierte contratos en experiencia visual. Los componentes no tienen que esconder su estado ni
atarse a un tema concreto. Exponen datos, roles y eventos; la capa visual los interpreta.

### Bloque 5: arquitectura que se puede explicar

Active esta organizado para que cada parte pueda explicarse:

- que responsabilidad tiene,
- de quien depende,
- que expone,
- que eventos emite,
- que errores produce,
- como se integra con el resto.

Esa claridad es parte del producto.

## Posibles titulares

- Build applications that know what they are doing.
- A small core for serious applications.
- Semantic UI for reactive products.
- Application services and interface semantics, composed.
- Less accidental coupling. More intentional runtime.
- Interfaces with structure, behavior, meaning and visual coherence.
- ActiveApp for the runtime. ActiveUix for the experience.

## Posibles subtitulos

- Compose application services and semantic interfaces without turning your frontend into a knot.
- A Svelte ecosystem for product-grade applications, explicit services and accessible components.
- Runtime, services, events, preferences and visual systems under clear contracts.
- Build with a small core, opt-in modules and UI components that expose meaning, not just markup.

## Secciones recomendadas para landing

### 1. Hero

Presentar Active como ecosistema de aplicacion e interfaz.

Contenido clave:

- ActiveApp + ActiveUix.
- Core pequeño.
- Servicios opt-in.
- UI semantica.
- Contratos explicitos.

### 2. Two areas

Comparar las dos areas sin enfrentarlas:

- ActiveApp: servicios y runtime.
- ActiveUix: componentes y experiencia.

### 3. Why it matters

Explicar el problema:

- apps con demasiadas dependencias ocultas,
- componentes que mezclan logica, estilos y efectos,
- eventos sin semantica,
- temas que no entienden estado,
- servicios duplicados por pantalla.

### 4. ActiveApp modules

Mostrar los servicios como tarjetas:

- Langs,
- Logger,
- Timers,
- Format,
- ADom,
- Clipboard,
- Sium,
- Storage,
- HTTP,
- Session,
- Connections,
- Auth,
- Perm,
- Cache.

### 5. ActiveUix layers

Mostrar la cadena:

> Morfo declara. Soma comporta. Sema significa. Eidos expresa. ADom aplica. ActiveUix compone.

### 6. Semantic events

Explicar Sema con ejemplos de intencion y canal:

- una accion afirmativa puede tener visual feedback,
- una accion de riesgo puede emitir una señal distinta,
- una interaccion sostenida puede activar estados temporales,
- sound/haptic pueden respetar preferencias globales.

### 7. Limited dependencies

Presentar la filosofia:

- usar poco por defecto,
- declarar lo necesario,
- aislar capacidades,
- evitar paquetes monoliticos,
- adaptar entorno por factories.

### 8. Designed for Svelte

Explicar que Active abraza Svelte 5 y su modelo reactivo, pero sin meter todo en componentes
visuales. La app mantiene servicios activos fuera del arbol visual cuando corresponde.

### 9. For real products

Cerrar con el mensaje de producto:

Active esta pensado para aplicaciones que necesitan crecer con sesion, permisos, cache, validacion,
internacionalizacion, realtime, preferencias y componentes complejos sin perder claridad.

## Frases guia

Usar:

- "contratos explicitos"
- "servicios opt-in"
- "runtime de aplicacion"
- "runtime de interfaz"
- "interacciones semanticas"
- "dependencias contenidas"
- "composicion por capacidades"
- "visual layer sobre contratos"
- "headless behavior"
- "diagnostico integrado"
- "preferencias transversales"

Evitar:

- "framework total"
- "todo incluido"
- "sin dependencias" si no es literalmente cierto
- "magico"
- "automatico" cuando depende de configuracion
- "solo componentes"
- "design system" como unica definicion

## Pitch corto

Active es un ecosistema Svelte dividido en dos areas: ActiveApp y ActiveUix.

ActiveApp compone el runtime de aplicacion con un core pequeño y servicios opt-in como langs,
logger, timers, format, storage, HTTP, session, auth, permisos, cache y conexiones.

ActiveUix compone la experiencia de interfaz con Morfo, Soma, Sema y Eidos: contratos DOM,
comportamiento headless, eventos semanticos y visuales basados en tokens.

La propuesta es construir productos con menos acoplamiento accidental, mas observabilidad y una UI
que no solo renderiza estado, sino que expresa significado.

## Pitch medio

Active es una base de arquitectura para aplicaciones Svelte que separa dos responsabilidades que a
menudo se mezclan: el runtime de aplicacion y el runtime de interfaz.

Con ActiveApp, la aplicacion declara los servicios que necesita y obtiene un nucleo consistente para
logging, eventos, timers, preferencias y orquestacion. A partir de ahi puede componer modulos como
internacionalizacion, formatos, storage, HTTP, sesion, auth, permisos, cache o realtime sin convertir
la app en un bloque monolitico.

Con ActiveUix, los componentes se construyen por capas: Morfo define su contrato, Soma su
comportamiento, Sema el significado de sus eventos y Eidos su expresion visual. Esta separacion hace
que la interfaz sea mas accesible, testeable, adaptable y coherente.

Active no vende acumulacion de features. Vende composicion, semantica y claridad.

## Pitch largo

Active es un ecosistema para crear aplicaciones Svelte con una arquitectura preparada para producto.
Su nucleo se divide en dos areas: ActiveApp y ActiveUix.

ActiveApp se encarga de la vida interna de la aplicacion: servicios, preferencias, diagnostico,
orquestacion, almacenamiento, red, sesion, permisos, cache, auth y conexiones. Su enfoque es
declarativo y opt-in: la aplicacion compone las capacidades que necesita, y cada servicio mantiene
una responsabilidad clara.

ActiveUix se encarga de la experiencia de interfaz. En lugar de tratar los componentes como piezas
visuales aisladas, los divide en capas. Morfo define la anatomia y el contrato DOM. Soma implementa
el comportamiento headless, la accesibilidad y el control de estado. Sema transforma las
interacciones en eventos con significado. Eidos convierte tokens, temas y atributos en experiencia
visual.

Esta estructura permite construir aplicaciones con interfaces mas expresivas, menos dependencias
ocultas y una separacion real entre estado, comportamiento, semantica y estilo.

Active es especialmente util cuando una aplicacion necesita crecer: mas idiomas, mas permisos, mas
sesion, mas cache, mas componentes, mas preferencias, mas integraciones. El ecosistema ayuda a que
ese crecimiento ocurra por composicion, no por acumulacion accidental.

## Claim final

**ActiveApp organiza la aplicacion. ActiveUix da significado a la interfaz.**

Juntos forman un ecosistema para construir productos Svelte con servicios explicitos, componentes
semanticos, visuales coherentes y una arquitectura que se puede mantener.