Roadmap de Óxido

Este roadmap desglosa las fases 0–14 de plan en unidades implementables. Es un plan de trabajo, no un informe de capacidades existentes.

Estado inicial

Fases 0–7: completadas en sus alcances verificados. Fase 8: en curso. Fase 9 en adelante: pendiente. La Fase 5 entrega una rebanada inicial ejecutable, no compatibilidad general con Rust. La Fase 6 completa alias y equivalencia de los modos de bloques para funciones/control; Fase 7 añade items indentados iniciales y aliases de prelude/macros. Fase 8 amplía la sintaxis estructural indentada y la interoperabilidad con Rust. Consulta los informes de cada fase y los documentos normativos enlazados abajo.

Reglas para avanzar

Cerrar cada subfase con evidencia verificable, limitaciones registradas y documentación actualizada.
No declarar compatibilidad por ejemplos ilustrativos; registrar funciones soportadas, parciales, rechazadas y no evaluadas.
Mantener el laboratorio desde las primeras fases. Las fases 10 y 12 lo amplían; no posponen las pruebas iniciales.
Las metas de seguridad, calidad y rendimiento aplican desde el inicio según el riesgo de cada componente. No requieren añadir servicios externos de telemetría.
No añadir tecnologías de backend que no formen parte de Óxido. Las dependencias se justifican por una necesidad concreta del compilador, CLI, LSP o extensión.
Una subfase puede dividirse en tareas más pequeñas; no se puede saltar un criterio de salida para empezar trabajo dependiente.
El portal documental estático es una superficie del producto separada de VS Code: se construye desde Markdown en website/, se despliega como archivos estáticos y se actualiza en cada fase. Su contenido solo presenta como disponibles las capacidades verificadas.

Fase 0. Auditoría del repositorio

Objetivo: conocer el estado real y separar especificación, código existente y propuestas.

Subfases

Inventario del repositorio: revisar archivos, ramas, historial, instrucciones y documentación; identificar archivos ajenos o duplicados.
Auditoría técnica: localizar workspace Cargo, crates, dependencias, toolchain, CI, fixtures, pruebas, extensión y LSP existentes.
Verificación de estado: ejecutar solo las comprobaciones existentes y seguras; registrar comandos y resultados, incluidos fallos previos.
Matriz de capacidades: clasificar cada característica como implementada, parcial, pendiente, no soportada o no evaluada.
Plan adaptado: identificar riesgos, decisiones bloqueantes, dependencias y la unidad mínima end-to-end.

Entregables: informe de auditoría, matriz de estado y plan de trabajo basado en evidencia.

Criterio de salida: el estado del repositorio está descrito sin asumir que una propuesta documental ya funciona; los problemas existentes y la primera unidad verificable están identificados.

Dependencia: ninguna.

Fase 1. Especificación

Objetivo: cerrar las decisiones que condicionan lexer, parser, backend y compatibilidad.

Subfases

Alcance de Rust: definir el frontend inicial. Decisión de partida: Óxido analiza estructura, bloques, alias e items propios; conserva expresiones y tipos como tokens de Rust y los valida con syn cuando corresponda.
Modos de sintaxis: especificar gramática de indentación y llaves, selección explícita, continuaciones, tabuladores, espacios, dedentación y errores.
Política por proyecto: el proyecto fija el modo. Los archivos no pueden contradecirlo; sin configuración de proyecto, cada archivo declara su modo al inicio.
Semántica de bloques: formalizar expresión final sin ; como valor y con ; como instrucción de valor (); definir los casos de continuación multilínea.
Alias e identificadores: inventariar palabras clave por edición de Rust; usar paquete para crate; definir reservadas, identificadores crudos r#..., colisiones y diagnósticos.
Macros y atributos: traducir nombres de macros estándar allowlisted; recorrer aliases en argumentos que son expresiones Rust, y mantener opacos los argumentos de macros externas/desconocidas y macros de metaprogramación. Los atributos solo se traducen con reglas allowlisted.
Compatibilidad: crear matriz de construcciones conservadas, transformadas, rechazadas y pendientes.
Diagnósticos y posiciones: definir códigos, severidad, rangos, etiquetas y contrato del mapa .ox ↔ .rs.
Backend: especificar generación con árboles de tokens/AST (proc_macro2/quote) y formato estructural (prettyplease), nunca por concatenación de texto no confiable.
Criterios de aceptación: preparar fixtures positivos y negativos para cada decisión formal.

Entregables: especificación, gramática, modos, alias y reservadas, compatibilidad, diagnósticos y mapa, pipeline y criterios de aceptación. La arquitectura y el scaffold documental están en architecture.md y ARCHITECTURE_RULES.md.

Criterio de salida: todas las decisiones arquitectónicas anteriores están cerradas y no hay reglas críticas que dependan de interpretación informal.

Dependencia: Fase 0.

Fase 2. Infraestructura del monorepo

Objetivo: preparar una base Rust mínima que compile y pueda crecer modularmente.

Subfases

Workspace y toolchain: crear Cargo.toml, Cargo.lock, versión de Rust y edición fijadas, solo después de aprobar la arquitectura.
Crates iniciales: materializar solo los límites reales de fuente, backend, aplicación y CLI. Lexer/parser propios se implementan en Fase 3; el pipeline inicial prueba el parser Rust real de Syn.
Interfaces internas: definir flujo de datos, errores y propiedad de rangos entre etapas.
Configuración: establecer carga segura de oxido.toml como datos declarativos y validación de campos.
Calidad base: formato, lints, pruebas mínimas y CI reproducible con --locked.
Laboratorio inicial: fixtures y harness que ejerciten parseo Rust, backend y configuración declarativa reales; agregar lexer Óxido al harness en Fase 3.

Entregables: workspace mínimo, CI base y laboratorio inicial del parser Rust/backend. No es aún un compilador de .ox.

Criterio de salida: workspace compila, interfaces no tienen dependencias circulares y una prueba verifica el pipeline real aunque todavía tenga alcance pequeño.

Dependencia: Fase 1.

Fase 3. Fuentes y lexer inicial

Objetivo: convertir texto fuente en tokens y rangos confiables.

Subfases

Modelo de fuentes: archivos, spans, offsets, líneas, columnas y manejo consistente de UTF-8.
Tokens básicos: identificadores, palabras clave inglesas/españolas, puntuación y operadores.
Literales y comentarios: números, cadenas, caracteres, comentarios y casos multilínea.
Identificadores crudos: reconocer r#nombre y distinguirlo de keywords.
Seguridad Unicode: rechazar controles bidireccionales y advertir sobre caracteres confundibles según la política de Fase 1.
Modo indentación: stack de indentación, dedentación, espacios/tabuladores y errores con spans.
Modo llaves: delimitadores de bloque sin dar significado semántico a la indentación.
Tokens opacos: preservar correctamente los grupos de macros, literales y atributos pertinentes.
Límites y recuperación: tamaño máximo, anidamiento, entradas incompletas y ausencia de pánicos.

Entregables: lexer funcional y pruebas positivas/negativas por token y modo.

Criterio de salida: los mismos bytes de entrada producen tokens/rangos deterministas; errores malformados son diagnósticos y no pánicos.

Dependencia: Fase 2.

Fase 4. Parser estructural inicial y AST

Objetivo: analizar el subconjunto definido y producir una representación intermedia común.

Subfases

AST inicial: items, bloques, declaraciones y spans de origen.
Items y funciones: visibilidad, firmas y cuerpos según la gramática admitida.
Expresiones y tipos Rust: preservar tokens que pertenecen a Rust y validarlos con syn dentro del alcance acordado.
Bloques: asociar indentación o llaves con la misma estructura de AST.
Semicolon/valor: representar de forma explícita la expresión final y el terminador ;.
Macros/atributos: conservar grupos y tokens sin traducir argumentos por defecto.
Errores y recuperación: spans precisos, errores múltiples cuando sea seguro y tolerancia a edición incompleta.
Pruebas del parser: corpus válido/inválido, anidamiento, Unicode, macros y casos de recuperación.

Entregables: parser/AST inicial para el subconjunto definido.

Criterio de salida: el corpus válido/inválido cubre AST, spans, recuperación, passthrough con atributos/visibilidad, macros, controles, nombres reservados y semicolon/tail en ambos modos; se verifican diagnósticos Syn y límites de recursión. Cumplido para el subconjunto inicial documentado en fase-4-parser.md; las formas fuera de ese subconjunto permanecen parciales o pendientes en compatibilidad.

Dependencia: Fase 3.

Fase 5. Primer compilador funcional

Objetivo: completar primero una rebanada vertical mínima: exportar, mapear, compilar y ejecutar un programa .ox «Hola, mundo». Después se amplía el subconjunto y se implementa la importación reversible.

Tareas incrementales

Emisor mínimo: completada para el subconjunto de Hola, mundo, con quote/proc_macro2, formateo prettyplease y validación Syn.
Mapa de posiciones: completada para spans de fragmentos e items, con serialización lateral y nombres de archivo sin rutas absolutas.
Exportar: completada; produce Rust inspeccionable y mapa lateral para el subconjunto admitido.
Adaptador Cargo: completada para el proyecto generado aislado, con Command, argumentos separados, límite de tiempo, modo offline y mensajes JSON.
Diagnósticos JSON: completada para errores de tipos y cabeceras de control; conserva diagnósticos externos que no se pueden mapear.
Compilar y ejecutar: completada; una prueba compila y ejecuta el ejemplo, compara la salida y comprueba propagación de errores.
Importar y vuelta redonda: completada para funciones libres admitidas; la prueba CLI verifica .ox → .rs → .ox → .rs normalizado y rechazos fuera del subconjunto.

Entregables: programa .ox real compilado y ejecutado, Rust generado inspeccionable, diagnósticos mapeados y prueba de ida y vuelta del subconjunto reversible.

Criterio de salida: cumplido para el alcance inicial descrito en informe de Fase 5. Ejecución automatizada local compara el resultado y no reporta éxito si falla Cargo o rustc. La CI remota pública ejecuta las verificaciones del repositorio.

Dependencia: Fase 4.

Fase 6. Sintaxis de bloques y bilingüismo

Objetivo: completar ambos modos y normalizar alias sin modificar tokens protegidos.

Subfases

Modo indentado: completado para funciones, controles anidados, continuaciones y terminadores.
Modo de llaves: completado con la misma AST, semántica de tail y formas de control admitidas.
Configuración: completada; se admite modo de proyecto sin cabecera y se rechaza una cabecera inicial que lo contradiga.
Alias: normalización tokenizada completada en firmas, visibilidad, tipos, patrones, expresiones y items Rust passthrough fuera de regiones opacas.
Escape: comprobados r#... y diagnósticos OX3001 con sugerencia en nombres de funciones, parámetros, patrones anidados, bindings y patrones de para.
Macros: comprobado que las invocaciones y atributos conservan nombre y tokens internos, incluidos grupos anidados.
Equivalencia: completada con pruebas que compilan y ejecutan el mismo caso en ambos modos y comparan su salida.
Formato: la salida Rust de ambos modos se valida y normaliza con Syn/prettyplease; el formateo no reescribe ni cambia silenciosamente el archivo fuente .ox.

Entregables: completados para el subconjunto inicial de funciones/control descrito en informe de Fase 6; matriz de sintaxis y bilingüismo con pruebas de equivalencia y regresión.

Criterio de salida: cumplido para el subconjunto indicado; pruebas verifican que los modos no mezclan delimitadores, conservan la regla ;/tail y compilan con comportamiento equivalente. Items con cuerpos indentados y nuevas formas de lenguaje quedan delimitados como Fase 7.

Dependencia: Fase 4; el emisor inicial de Fase 5 permitió verificar ambos modos end-to-end.

Fase 7. Lenguaje inicial

Objetivo: ampliar el subconjunto mediante capacidades con criterios independientes. El alcance inicial de Fase 7 está cerrado; las extensiones posteriores se registran como cambios acotados sin reabrir criterios ya aceptados.

Subfases

Variables y expresiones: completadas para let/dejar/variable, variable mutable, aliases &mutable, literales, llamadas y expresiones Rust; pruebas positivas/negativas y de tipo.
Funciones: completadas para funcion, principal→main, parámetros, tipos, retorno, visibilidad y semicolon/tail.
Control: condiciones y bucles iniciales en ambos modos, con equivalencia ejecutable verificada en Fase 6.
Tipos compuestos: tuplas, arrays y primitivos preservados como Rust y probados en ejecución.
Items: campos indentados de struct, variantes indentadas de enum; impl y métodos en passthrough Rust con llaves.
Referencias: referencias y borrowing delegados a Rust, con prueba end-to-end.
Módulos e imports: use indentado; módulos/imports Rust en modo llaves.
Errores y tipos comunes: Result, Option y ? probados mediante compilación y ejecución.
Aliases de prelude: completada para tipos, variantes, primitivos, traits, métodos y rutas std enumerados en aliases.
Macros/atributos: completada para aliases estándar y atributos allowlisted; los nombres Rust originales siguen válidos, se recorren aliases anidados en macros estándar expresivas y las DSL externas permanecen opacas. La prueba E2E de Fase 8 compila y ejecuta todas las aliases estándar ejecutables mediante Cargo/rustc; compile_error! tiene caso negativo.
Entrada principal y mutabilidad: completada para principal→main, variable/variable mutable y mutable en referencias/parámetros, más colisión y escape r#.
Errores y diagnóstico: completada para el inventario de códigos rustc común documentado; conserva códigos/spans JSON y no depende de salida humana.
Pruebas diferenciales: completada con corpus positivo/negativo, ejecución end-to-end, aliases y matriz reproducibles.

Entregables: completados; informe, matriz y ejemplos ejecutables cubren las subfases. Formato, pruebas de workspace, Clippy y build de documentación verdes.

Criterio de salida: cumplido para el alcance inicial; las familias de aliases tienen pruebas de conversión y ejemplos end-to-end para el subconjunto indicado. Los argumentos de macros estándar expresivas se normalizan selectivamente; las DSL externas permanecen opacas. Errores comunes se mapean desde JSON y no se declara compatibilidad general. La sintaxis indentada ampliada se implementa en Fase 8.

Dependencia: Fase 6; algunas características pueden desarrollarse en paralelo si no comparten gramática/backend.

Fase 8. Integración con Rust

Objetivo: ampliar la sintaxis estructural indentada y la interoperabilidad con Rust, preservando una sola semántica Rust.

Subfases

Estructura indentada: completada para el alcance inicial con impl y métodos, trait con firmas/defaults, módulos anidados y coincidir con brazos de expresión o bloque. La cobertura incluye receivers y funciones asociadas, genéricos/donde, varios bloques por tipo, visibilidad/atributos/docs, items asociados, bloque vacío e indentación inválida, regla del ; final, equivalencia con llaves y mapeo de errores rustc a .ox.
Dependencias Cargo reales y configuración reproducible. En curso (primer corte): oxido.toml declara dependencias locales por path, se canonicalizan dentro del proyecto y Cargo compila/ejecuta offline. Pendientes: dependencias de registro, lockfile persistente versionable y pruebas con crates de referencia.
Genéricos, traits y lifetimes dentro del alcance del frontend. Verificado para el corpus actual: firmas genéricas con lifetime, impl Fn, bounds where, trait e implementación genéricos y tipos asociados pasan por generación y Cargo.
Pattern matching, closures e iteradores, completando patrones y expresiones Rust preservados por el frontend. Verificado para el corpus actual: closure como argumento, Iterator::find, patrones Some/None y brazos indentados/llaves compilan y producen el mismo resultado.
Macros declarativas y atributos, preservando árboles de tokens. En curso (primer corte): macro_rules! opaco en nivel superior indentado y macro exportada desde crate local, invocada por ruta sin modificar la biblioteca, compilan/ejecutan mediante Cargo; también se prueba #[derive(Debug)]. Sin expansión propia ni traducción de sus cuerpos.
async/await y concurrencia según compatibilidad validada. En curso (primer corte): funciones async y .await compilan en Cargo; std::thread::spawn tiene prueba de ejecución. Sin runtime async propio ni matriz de futures.
Bibliotecas externas de referencia y pruebas de conformidad. En curso: crate local por ruta y su macro exportada compilan/ejecutan; crates de registro y corpus de bibliotecas reales aún pendientes.
unsafe: preservar semántica Rust; política opcional de rechazo y auditoría de superficie. En curso (corte léxico): oxido auditar-unsafe <archivo.ox|archivo.rs> [--rechazar] informa tokens con posición y puede rechazarlos sin compilar; no identifica aún build.rs, macros procedurales, FFI ni llamadas externas.
Actualizar matriz con límites por versión/edición de Rust.

Entregables: suites de conformidad, proyectos de referencia versionados y gramática indentada validada con Cargo/rustc.

Criterio de salida: ninguna característica se marca soportada sin pruebas con Rust/Cargo reales, límites documentados y cobertura de errores. No se inicia Fase 9 hasta cerrar todas las subfases de Fase 8.

Dependencia: Fase 7.

Fase 9. CLI y experiencia de proyecto

Objetivo: entregar comandos estables y seguros para tareas habituales.

Subfases

Definir nombres, argumentos, ayuda y códigos de salida.
Crear proyectos con plantillas mínimas verificables.
Implementar verificar, compilar, ejecutar y probar.
Implementar oxido formato y modo de comprobación; el formato debe ser idempotente, conservar comentarios ordinarios fuera de grupos opacos y nunca descartarlos silenciosamente. Los comentarios dentro de macros/atributos opacos deben conservarse o producir un diagnóstico claro.
Implementar diagnóstico y salida estructurada para CI.
Implementar exportación/importación del subconjunto reversible.
Implementar informe de superficie de riesgo (unsafe, build.rs, macros procedurales y llamadas externas detectables).
Endurecer rutas, enlaces simbólicos, configuración y ejecución de procesos.

Entregables: CLI documentada y pruebas de integración de comandos.

Criterio de salida: comandos producen efectos, salidas y errores consistentes; operaciones de archivo quedan dentro del workspace permitido.

Dependencia: Fases 5–8 según comando.

Fase 10. Laboratorio de validación

Objetivo: consolidar pruebas, compatibilidad, fuzzing y evidencia continua.

Subfases

Matriz de fixtures por lexer, parser, modos, alias, macros, backend y diagnósticos.
Pruebas de regresión de defectos previos.
Pruebas diferenciales frente a Rust para construcciones equivalentes.
Pruebas de ida y vuelta/exportación-importación.
Fuzzing con cargo-fuzz, corpus y regresiones.
Pruebas de tamaño, profundidad, Unicode, recuperación y cancelación.
Proyectos de referencia: CLI, API educativa solo si corresponde al ejemplo del lenguaje, y dependencias reales compatibles.
Informes reproducibles con versiones, commit, entorno, pruebas aprobadas/fallidas/pendientes y rendimiento medido.
Integración de suites en CI y detección de regresiones.

Entregables: laboratorio ejecutable y reportes sin métricas inventadas.

Criterio de salida: cada característica anunciada está cubierta por pruebas identificables; pendientes y fallos se muestran explícitamente.

Dependencia: el laboratorio base inicia en Fase 2; esta fase consolida capacidades avanzadas.

Fase 11. VS Code y LSP

Objetivo: construir una experiencia de edición que comparte análisis con el compilador.

Subfases

Extensión mínima: asociación de .ox, configuración y comandos.
Semantic tokens del lexer/parser de Óxido.
Servidor LSP en Rust con tolerancia a archivos incompletos.
Diagnósticos del compilador y Cargo con mapeo al .ox.
Integración con rust-analyzer para tipos/autocompletado sobre Rust generado cuando el mapeo sea fiable.
Navegación, símbolos, referencias y renombrado solo cuando puedan verificarse.
Formateador y acciones de código.
Workspace Trust: no ejecutar compilación/análisis que ejecute código sin confianza explícita.
Cancelación, límites de solicitudes, memoria y latencia.
Pruebas del protocolo y documentación de instalación.

Entregables: extensión/LSP probados contra compilador real.

Criterio de salida: los diagnósticos y tokens coinciden con el análisis del compilador; el editor permanece receptivo ante código incompleto y proyectos no confiables.

Dependencia: Fases 3–5; capacidades avanzadas dependen de Fases 6–9.

Fase 12. Seguridad y calidad avanzada

Objetivo: reducir riesgos de parser, cadena de suministro y artefactos distribuidos.

Subfases

Modelo de amenazas actualizado para .ox, configuración, dependencias/macros, LSP y playground.
Aplicar límites de tamaño, anidamiento, tokens, tiempo y frecuencia.
#![forbid(unsafe_code)] en el compilador y política de rechazo de unsafe en código analizado.
Detección de Unicode bidireccional y advertencias de caracteres confundibles.
Auditoría de rutas, symlinks, permisos y procesos hijos.
cargo-audit, cargo-deny, --locked y política de dependencias/licencias.
Fuzzing continuo, revisión de pánicos y límites de memoria/CPU.
Benchmarks de análisis, generación, memoria y latencia del LSP; optimizar según perfiles.
Builds reproducibles, SBOM y firma antes de distribución.
Informes CI sin secretos ni rutas absolutas; telemetría desactivada por defecto.
Sandbox de playground, solo si se aprueba ese producto.

Entregables: checklist de seguridad, resultados de auditoría y plan de corrección.

Criterio de salida: riesgos críticos corregidos o bloqueados/documentados; controles automáticos ejecutados y reproducibles.

Dependencia: controles base desde Fases 2–5; consolidación desde Fase 10.

Fase 13. Educación y documentación

Objetivo: convertir capacidades verificadas en materiales confiables dentro del portal documental Markdown desplegable en Cloudflare Pages.

Subfases

README, contribución, seguridad, licencia y changelog coherentes.
Especificación de lenguaje, gramática, alias, modos y diagnósticos.
Arquitectura, pipeline y compatibilidad con Rust.
Instalación, CLI, editor/LSP y solución de problemas.
Tutoriales progresivos con ejemplos que compilan en CI.
Ejercicios y criterios de evaluación.
Guías bilingües cuando exista capacidad de mantener ambas versiones.
Plan de pilotos educativos y evaluación con evidencia; no afirmar beneficios sin estudio.
Guía empresarial que enumera límites y controles reales, no aspiracionales.
Mantener website/ con Astro Starlight: portada, navegación, búsqueda, páginas para desarrolladores/empresas/estudiantes y casos de uso.
Publicar la referencia desde los Markdown canónicos de docs/ sin editarlos dos veces; verificar enlaces y build en CI.
Desplegar estáticamente en Cloudflare Pages con previews; configurar dominio al decidirlo, sin añadir backend ni telemetría.

Entregables: portal de documentación versionado, guías por audiencia, ejemplos vinculados a pruebas y despliegue estático.

Criterio de salida: portal accesible desde móvil/escritorio, navegación y búsqueda funcionan, build estático se reproduce, documentos coinciden con implementación y ejemplos pendientes se identifican como propuestas.

Dependencia: cada documento se actualiza durante su fase; consolidación depende de Fases 7–12.

Fase 14. Estabilización y lanzamiento

Objetivo: publicar solo un alcance cerrado y reproducible.

Subfases

Congelar el alcance de versión y matriz de compatibilidad.
Ejecutar suite completa, auditorías, fuzzing definido y proyectos de referencia.
Verificar instalación limpia y toolchain compatible.
Revisar seguridad, dependencias, licencias, SBOM, firma y reproducibilidad.
Confirmar que no hay regresiones bloqueantes ni criterios ignorados.
Finalizar changelog, notas de migración, limitaciones y soporte.
Preparar artefactos y procedimiento de publicación.
Publicar únicamente con autorización y evidencia de aceptación.

Entregables: candidato de versión reproducible, informe de aceptación y documentación de lanzamiento.

Criterio de salida: todos los criterios de la versión están satisfechos; cada excepción tiene dueño, justificación y estado explícito. Si hay bloqueos, no se declara el lanzamiento listo.

Dependencia: Fases 0–13 y aceptación formal del alcance.

Seguimiento del roadmap

Mantén una tabla de estado en cada revisión del proyecto:

Fase	Estado	Evidencia y comando de verificación	Bloqueos
0	Completada	Informe de auditoría; revisión documental histórica (no existía suite ejecutable)	Ninguno para iniciar Fase 1
1	Completada (decisiones normativas)	Especificación, gramática, aliases; `cargo test -p oxido-language --locked` valida fixtures de lexer/parser	Sin bloqueos dentro de las decisiones 0.1
2	Completada (infraestructura inicial)	Informe de Fase 2; `cargo test --workspace --locked`	Ninguno registrado
3	Completada (fuentes y lexer inicial)	Informe de Fase 3; `cargo test -p oxido-language --test lexer --locked`	No implica parser ni generación
4	Completada (parser estructural inicial)	Informe de Fase 4; `cargo test -p oxido-language --test parser --locked`	No genera Rust por sí sola
5	Completada (compilador inicial)	Informe de Fase 5; `cargo test -p oxido-cli --test cli --locked` comprueba exportar, compilar, ejecutar y roundtrip	Sin bloqueos dentro del subconjunto reversible y ejecutable
6	Completada (bloques y aliases iniciales)	Informe de Fase 6; `cargo test -p oxido-language -p oxido-rust-backend --locked`	La ampliación de items estructurales se documenta en Fases 7–8
7	Completada (alcance inicial del lenguaje)	Informe de Fase 7; `cargo test -p oxido-compiler --test pipeline --locked`	Alcance ampliado en Fase 8
Portal documental	Publicado en Cloudflare Pages	website/README.md, Astro Starlight; build y publicación estática operativos	Sitemap requiere configurar el dominio `site`; Starlight muestra un aviso informativo al resolver la ruta 404
8	En curso (integración con Rust)	Informe de Fase 8; `cargo test -p oxido-cli --test cli --locked` compila y ejecuta un crate local declarado en `oxido.toml`; pipeline verifica sintaxis y macros	Dependencias de registro/lockfile, subfases 5–9 y conformidad siguen abiertas; Fase 9 no inicia hasta cerrar esta fase
9–14	Pendiente	Añadir evidencia al cerrar cada fase	Registrar solo bloqueos concretos

Estados permitidos: pendiente, en curso, bloqueada, completada. No uses porcentajes sin una medición reproducible. Al cerrar una fase, registra commit, comandos ejecutados, resultados, criterios cumplidos y limitaciones.

Las fases 0–7 están completadas en los alcances indicados arriba. La Fase 8 es la fase activa; no avanzar a Fase 9 mientras sus subfases sigan abiertas.