> ## Documentation Index
> Fetch the complete documentation index at: https://docs.delixon.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Technology selection

> Estados del catálogo, dependencias y cómo se eligen tecnologías al crear un proyecto

Al crear un proyecto (GUI, shell o CLI) primero defines la **plataforma**
(web, CLI, escritorio, móvil), la **forma** (frontend, API o fullstack, para
web) y la **arquitectura del repo** (repo único, monorepo, polyrepo o
metarepo, según la forma); luego eliges tecnologías de un catálogo. No todas
están al mismo nivel de madurez ni todas tienen sentido por sí solas: Nexenv
modela eso con un **status** por tecnología, con **dependencias** entre ellas,
y con un filtro de **relevancia** según la plataforma y la forma que elegiste.

## Status de una tecnología

Cada entrada del catálogo (`src-tauri/src/core/catalog/technologies/*.yaml`)
declara un `status`:

| Status         | Seleccionable  | Qué significa                                                                                               |
| -------------- | -------------- | ----------------------------------------------------------------------------------------------------------- |
| `stable`       | Sí             | Probada; produce un proyecto funcional.                                                                     |
| `experimental` | Sí (con aviso) | Presente y usable, pero sin garantía completa de las recipes/plantillas asociadas. Lleva un badge `exp`.    |
| `planned`      | **No**         | Declarada pero **todavía no implementada**. Aparece deshabilitada con un aviso amarillo **"Próximamente"**. |
| `deprecated`   | **No**         | Ya no recomendada; bloqueada para proyectos nuevos.                                                         |

La regla la aplica una única fuente de verdad en el backend
(`validate_stack`), que usan la GUI, el comando `validate` y el wizard del
CLI. Además, la generación (`generate_project`) **rechaza** un stack que
incluya tecnologías no usables, así que ni la API ni `nexenv new --techs`
pueden colar una tecnología "próximamente".

## Dependencias entre tecnologías

Hay dos tipos de dependencia, ambos codificados en el catálogo:

* **`requires` (todas):** la tecnología necesita otra concreta, que se
  **autoañade** al seleccionarla. Ej.: `prisma` requiere `nodejs`.
* **`requires_any` (una de varias):** la tecnología solo es usable si **al
  menos una** de una lista está seleccionada, y como no se puede elegir cuál
  por ti, queda **no seleccionable hasta que elijas una base**. Ej.: **Vite**
  necesita un framework frontend (React, Vue, Svelte, Solid o Qwik); los
  bundlers y los runners E2E siguen la misma regla.

## Relevancia por plataforma y forma

El catálogo tiene \~90 tecnologías, pero no todas aplican a lo que estás
construyendo. En el paso de stack, Nexenv muestra por defecto solo las
**relevantes** para tu plataforma + forma y oculta el resto:

* Un **frontend** oculta backends, bases de datos y ORMs.
* Una **API** oculta frameworks de frontend y estilos.
* **Móvil** oculta bundlers y meta-frameworks web.
* **CLI** oculta web, estilos y bases de datos.

Las categorías se ordenan por flujo lógico (runtime → frontend → estilos →
backend → DB → ORM → auth → testing → devops), no alfabético. Un toggle
**"Mostrar todas / Solo relevantes"** te deja ver el catálogo completo cuando
quieras algo atípico. Lo que ya tengas seleccionado siempre se muestra.

## Estados de las tarjetas (GUI)

En el paso de stack del wizard, las tarjetas tienen tamaño uniforme y:

* **Sin selección:** sin borde.
* **Seleccionada:** borde verde (resalta).
* **Sugerida** (compatible con tu selección): borde gris plateado.
* **`planned`:** deshabilitada, badge **`soon`**, y al pasar el ratón un
  tooltip amarillo **"¡Próximamente!"**.
* **Bloqueada por dependencia / incompatibilidad:** deshabilitada con un
  tooltip explicando qué falta ("elige una de…").

Los **starter packs** que referencian alguna tecnología no usable se ocultan
automáticamente (la disponibilidad la dirige el status del catálogo).

## En el CLI

El wizard de `nexenv new` (y el de la shell interactiva, `nexenv shell` →
`/new`) sigue el **mismo modelo que la GUI**: plataforma → forma → arquitectura
del repo (con las mismas opciones válidas) → perfil → stack. Solo ofrece
tecnologías usables; lista las `planned` como "Próximamente" y las `deprecated`
como aviso, pero no permite elegirlas. Los flags `--platform`, `--type` (forma),
`--repo-arch` y `--profile` permiten saltarse los pasos.
`nexenv validate <techs...>` reporta incompatibilidades, dependencias
`requires`/`requires_any` sin satisfacer y status no usable.

## Idiomas

Los textos están internacionalizados (i18n). El idioma por defecto es
**inglés** ("Coming soon"); el español muestra "¡Próximamente!".