Arquitetura desagregada: quatro módulos frontend tornam-se autônomos + espelho OSS reforçado

R4: dividindo o frontend em módulos verdadeiramente independentes

A interface do estúdio cresceu o suficiente para que seus quatro pacotes mais pesados ​​– chat, workbench, settings, dashboard – fossem todos incorporados no repositório principal, compilados juntos e lançados juntos. Para os desenvolvedores, alterar uma linha no chat significava esperar a reconstrução de todo o frontend; arquitetonicamente, as dependências emaranhadas entre os quatro blocos tornaram-se cada vez mais difíceis de desembaraçar. O plano R4 de hoje registrou cada um desses quatro pacotes como submódulos independentes, cada um com seu próprio repositório, sua própria versão, seu próprio CI. O benefício foi imediato: cada módulo pode iterar e testar de forma independente, e tocar no chat não força a reconstrução do ambiente de trabalho. A desvantagem também é clara: mais submódulos para gerenciar. Mas para um projeto que passasse de “protótipo rápido” para “manutenção de longo prazo”, essa etapa teria que ocorrer mais cedo ou mais tarde, e quanto mais cedo melhor.

O fechamento da dependência CLI também é independente

Não apenas o front-end. Este dia também extraiu o fechamento de dependência da CLI – contratos, agente-host, plataforma-io, núcleo – do repositório principal para repositórios de submódulos independentes. Anteriormente, eles viviam como subdiretórios do repositório principal, compartilhando um node_modules e um pipeline de construção; mas a CLI é fundamentalmente um produto independente que precisa permanecer compatível entre diferentes versões do Studio, e ser incorporada ao monorepo restringe sua flexibilidade. Uma vez extraída, a CLI pode versionar e testar de forma independente, e o espelho OSS só precisa sincronizar esses repositórios para construir completamente — antes disso, as dependências ausentes faziam com que a instalação do bun do espelho público continuasse falhando.

O espelho OSS: de “navegável” a “construível”

Este dia deu ao espelho OSS público (ForgeaX-Games/forgeax-studio) um endurecimento completo. A maior mudança: enviar o código para o repositório público não vai mais direto para o principal — ele deve passar por um fluxo de PR + mesclagem automática, o que significa que cada sincronização recebe uma verificação de CI, uma trilha de revisão e um ponto de reversão. Ao mesmo tempo, o repositório público obteve CI de construção real pela primeira vez: verificação de tipo, bun fx setup, testes de fumaça, execução de ponta a ponta para garantir que o código que os usuários de código aberto recebam realmente seja compilado. Uma falha de segurança também foi corrigida: anteriormente, os administradores podiam ignorar a proteção da filial e enviar push diretamente; agora enforce_admins=true fecha esse caminho. O vazamento MIRROR_TOKEN também foi corrigido e um portão de simulação de espelho PR-time foi adicionado. Em uma frase: o espelho passou de “código que você pode navegar, mas pode não construir” para “CI garante que ele será construído, o processo garante que ele será rastreável”.

Redesenho da viewport 2×2: executar × exibir modos ortogonais

Este dia também trouxe uma importante especificação de design: o redesenho da janela de visualização 2×2. A ideia central é dissociar o “modo de execução” (Editar/Reproduzir) do “modo de exibição” (Cena/Jogo) em duas dimensões ortogonais, formando uma matriz 2×2. Anteriormente, Editar e Reproduzir do editor eram dois estados mutuamente exclusivos, com toda a janela de visualização reconstruída no switch; o novo design permite que você veja a visualização da cena e a visualização do jogo simultaneamente, impulsionada por diferentes estados de execução. Este é um passo em direção à experiência de edição do UE5 – edição e visualização em uma tela sem alternar para frente e para trás.

v0.3.3 lançamento noturno automático + uma pilha de correções de compilação

O pipeline de lançamento noturno produziu v0.3.3 automaticamente com sucesso neste dia. Mas o processo também expôs e corrigiu um bom número de problemas ao longo do caminho: a compilação do desktop não tinha o binário secundário do Bun, a verificação recursiva do submódulo falhou intermitentemente e precisava de um mecanismo de nova tentativa, os caminhos de alias do Vite não acompanharam a reestruturação do nome do pacote e a compilação do Tauri não conseguiu encontrar definições de tipo que foram migradas dos contratos. Também foram corrigidos um bug de remapeamento de GUID do ambiente de trabalho do lado do servidor e uma raiz de ativos da plataforma io off-by-one. Cada correção é pequena por si só, mas juntas são a etapa principal de "o pipeline de liberação automática pode ser executado" até "o pipeline de liberação automática é executado de maneira confiável".

O que este dia significa

A palavra-chave deste dia é “limites”. Quando um projeto passa da prototipagem rápida para a maturidade, uma das coisas mais importantes a fazer é traçar limites claros no código: quais peças são módulos independentes, quem depende de quem, quais podem ser lançadas por conta própria. A divisão R4 e a extração de dependência CLI traçam limites dentro do repositório principal; fortalecer o espelho OSS traça uma fronteira entre os repositórios internos e públicos; a proteção da filial e o fluxo de relações públicas traçam uma fronteira entre “pessoas” e “mudanças de código”. Uma vez claros os limites, cada parte pode evoluir, testar e lançar de forma independente, e o projeto pode passar de “uma pessoa empurrando uma grande bola de lama” para “um conjunto de módulos claros, cada um avançando por conta própria”.