Arquitectura desagregada: cuatro módulos frontales se vuelven independientes + espejo OSS reforzado

R4: dividir el frontend en módulos verdaderamente independientes

La interfaz del estudio había crecido lo suficiente como para que sus cuatro paquetes más pesados ​​(chat, banco de trabajo, configuración, panel) estuvieran integrados en el repositorio principal, compilados y lanzados juntos. Para los desarrolladores, cambiar una línea en el chat significaba esperar a que se reconstruyera toda la interfaz; Arquitectónicamente, las enredadas dependencias entre los cuatro bloques se hicieron cada vez más difíciles de desenredar. El plan R4 de este día registró cada uno de estos cuatro paquetes como submódulos independientes, cada uno con su propio repositorio, su propia versión y su propio CI. El beneficio fue inmediato: cada módulo puede iterarse y probarse de forma independiente, y tocar el chat no obliga a reconstruir el banco de trabajo. La desventaja también es clara: más submódulos que administrar. Pero para que un proyecto pase de ser un "prototipo rápido" a ser "mantenible a largo plazo", este paso tenía que llegar tarde o temprano, y cuanto antes, mejor.

El cierre de dependencia CLI también es independiente

No sólo la interfaz. Este día también extrajo el cierre de dependencia de la CLI (contratos, agente-host, plataforma-io, núcleo) del repositorio principal a repositorios de submódulos independientes. Anteriormente vivían como subdirectorios del repositorio principal, compartiendo un node_modules y una canalización de compilación; pero la CLI es fundamentalmente un producto independiente que debe seguir siendo compatible con diferentes versiones de Studio, y estar integrada en monorepo limitó su flexibilidad. Una vez extraído, la CLI puede versionar y probar de forma independiente, y el espejo OSS solo necesita sincronizar estos repositorios para compilarse por completo; antes de esto, las dependencias faltantes causaban que la "instalación bun" del espejo público siguiera fallando.

El espejo OSS: de "navegable" a "construible"

Este día le dio al espejo OSS público (ForgeaX-Games/forgeax-studio) un endurecimiento completo. El mayor cambio: enviar código al repositorio público ya no va directamente al principal: debe pasar por un flujo de fusión automática PR +, lo que significa que cada sincronización recibe una verificación de CI, un seguimiento de revisión y un punto de reversión. Al mismo tiempo, el repositorio público obtuvo CI de compilación real por primera vez: verificación de tipos, "configuración de bun fx", pruebas de humo, ejecución de un extremo a otro para garantizar que el código de código abierto que los usuarios reciben realmente se compila. También se tapó un agujero de seguridad: anteriormente los administradores podían eludir la protección de sucursales y presionar directamente; ahora enforce_admins=true cierra ese camino. También se solucionó la fuga de MIRROR_TOKEN y se agregó una puerta de funcionamiento en seco del espejo en tiempo PR. En una frase: el espejo pasó de "código que se puede explorar pero que quizás no se pueda compilar" a "CI garantiza que se compila, el proceso garantiza que es rastreable".

Rediseño de ventana gráfica 2×2: ejecutar × mostrar modos ortogonales

Este día también llegó una importante especificación de diseño: el rediseño de la ventana gráfica 2×2. La idea central es desacoplar el "modo de ejecución" (Edición/Reproducir) del "modo de visualización" (Escena/Juego) en dos dimensiones ortogonales, formando una matriz de 2×2. Anteriormente, Editar y Reproducir del editor eran dos estados mutuamente excluyentes, con toda la ventana gráfica reconstruida en Switch; El nuevo diseño te permite ver la vista de escena y la vista del juego simultáneamente, impulsadas por diferentes estados de ejecución. Este es un paso para igualar la experiencia del editor de UE5: editar y obtener una vista previa en una pantalla sin alternar hacia adelante y hacia atrás.

v0.3.3 lanzamiento nocturno automático + un montón de correcciones de compilación

El proceso de lanzamiento nocturno produjo con éxito la versión 0.3.3 de forma automática este día. Pero el proceso también expuso y solucionó un buen número de problemas a lo largo del camino: a la compilación del escritorio le faltaba el binario del sidecar Bun, la verificación del submódulo recursivo fallaba de manera intermitente y necesitaba un mecanismo de reintento, las rutas de alias de Vite no habían seguido el ritmo de la reestructuración de nombres de paquetes y la compilación de Tauri no podía encontrar definiciones de tipos que se habían movido de los contratos. También se corrigió un error de reasignación del GUID del banco de trabajo del lado del servidor y una raíz de activos de plataforma io separada por uno. Cada solución es pequeña por sí sola, pero juntas son el paso clave desde que "el proceso de lanzamiento automático puede ejecutarse" hasta "el proceso de lanzamiento automático se ejecuta de manera confiable".

que significa este dia

La palabra clave de este día es "límites". Cuando un proyecto pasa de la creación rápida de prototipos a la madurez, una de las cosas más importantes que se deben hacer es trazar límites claros en el código: qué piezas son módulos independientes, quién depende de quién y cuáles pueden publicarse por sí solos. La división de R4 y la extracción de dependencias de CLI trazan límites dentro del repositorio principal; reforzar el espejo OSS traza un límite entre los repositorios internos y públicos; la protección de sucursales y el flujo de relaciones públicas trazan un límite entre "personas" y "cambios de código". Una vez que los límites estén claros, cada parte puede evolucionar, probarse y lanzarse de forma independiente, y el proyecto puede pasar de "una persona empujando una gran bola de barro" a "un conjunto de módulos claros, cada uno de los cuales avanza por su cuenta".