Project / Architecture
El mapa muestra las partes grandes. Architecture muestra cómo trabajan juntas.
Esta página no intenta republicar todo ARCHITECTURE.md. Toma dos estructuras que el documento canónico declara explícitamente — las cuatro capas y el pipeline de cambio del sistema — y vuelve el flujo legible sin inventar interfaces futuras.
Cuatro capas canónicas
La arquitectura está organizada en capas para preservar límites claros.
Los títulos de abajo se extraen directamente de ARCHITECTURE.md. El texto corto solo explica el papel público de cada capa; no crea un contrato técnico nuevo.
Cuatro capas canónicas
- 1
Capa 1
Distribution foundation
Base de la distribución y límites que existen antes de las experiencias gráficas.
- 2
Capa 2
Felunyx platform
Estado, política y servicios compartidos entre interfaces y perfiles.
- 3
Capa 3
Desktop experiences
Experiencias gráficas oficiales que consumen la misma plataforma.
- 4
Capa 4
Delivery and recovery infrastructure
Instalación, actualizaciones, recuperación y el camino que lleva cambios al sistema con evidencia.
Cambio del sistema
Una acción destructiva no salta directamente a “ejecutar”.
El pipeline canónico tiene once pasos ordenados. Empieza normalizando la solicitud, pasa por resolución, riesgo, propuesta y confirmación, y termina verificando y registrando el resultado.
- Paso 1
normalize the request
- Paso 2
resolve source candidates
- Paso 3
calculate dependencies and conflicts
- Paso 4
classify risk
- Paso 5
decide snapshot scope
- Paso 6
present an exact proposal
- Paso 7
request confirmation
- Paso 8
execute source-specific stages in a controlled order
- Paso 9
verify results
- Paso 10
record action history
- Paso 11
set reboot-pending state when required
Este flujo explica política de alto nivel. Nombres de servicios, interfaces D-Bus, crates y almacenamiento interno pertenecen a las especificaciones de las fases que realmente los aprueben — no a esta página.