Project / Architecture
O mapa mostra as partes grandes. Architecture mostra como elas trabalham juntas.
Esta página não tenta republicar ARCHITECTURE.md inteiro. Ela pega duas estruturas que o documento canônico declara de forma explícita — as quatro camadas e o pipeline de mudança do sistema — e torna o fluxo legível sem inventar interfaces futuras.
Quatro camadas canônicas
A arquitetura é empilhada para preservar limites claros.
Os títulos abaixo são extraídos diretamente de ARCHITECTURE.md. O texto curto ao lado só explica o papel público de cada camada; ele não cria um contrato técnico novo.
Quatro camadas canônicas
- 1
Camada 1
Distribution foundation
Base da distribuição e limites que vêm antes das experiências gráficas.
- 2
Camada 2
Felunyx platform
Estado, política e serviços compartilhados entre interfaces e perfis.
- 3
Camada 3
Desktop experiences
As experiências gráficas oficiais que consomem a mesma plataforma.
- 4
Camada 4
Delivery and recovery infrastructure
Instalação, atualização, recuperação e o caminho que leva mudanças ao sistema com evidência.
Mudança de sistema
Uma ação destrutiva não pula direto para “executar”.
O pipeline canônico possui onze passos ordenados. Ele começa normalizando o pedido, passa por resolução, risco, proposta e confirmação, e termina verificando e registrando o resultado.
- Passo 1
normalize the request
- Passo 2
resolve source candidates
- Passo 3
calculate dependencies and conflicts
- Passo 4
classify risk
- Passo 5
decide snapshot scope
- Passo 6
present an exact proposal
- Passo 7
request confirmation
- Passo 8
execute source-specific stages in a controlled order
- Passo 9
verify results
- Passo 10
record action history
- Passo 11
set reboot-pending state when required
Este fluxo explica política de alto nível. Nomes de serviços, interfaces D-Bus, crates e armazenamento interno pertencem às especificações das fases que realmente os aprovarem — não a esta página.