PROYECTO WEB — TESIS 360°

Documento de contexto, propósito y alcance inicial

Proyecto: Dev Tesis RTL
Tesista: Raúl Andrés Trujillo Lucano
Universidad: Universidad Nacional de Ingeniería — Facultad de Ingeniería Civil
Estado: Documento de contexto para desarrollo de una web simple de lectura y navegación
Fecha base: 2026-09-19

1. QUÉ ES ESTE PROYECTO

Este proyecto busca construir una web sencilla para consultar, leer y navegar el desarrollo de una tesis de Ingeniería Civil relacionada con documentación fotográfica 360° en proyectos de construcción.

La web no es la tesis en sí misma ni debe convertirse en un sistema complejo de gestión documental.

Su función inicial es muy concreta:

mostrar de forma ordenada el contenido de un Markdown maestro de tesis y permitir navegar rápidamente entre capítulos, secciones, decisiones y pendientes.

El objetivo es evitar que el desarrollo de la tesis dependa exclusivamente de conversaciones dispersas en chats.

La fuente principal debe ser el repositorio.

2. PROBLEMA QUE QUEREMOS RESOLVER

Actualmente la tesis se está desarrollando mediante:

• conversaciones con ChatGPT;
• archivos Markdown;
• documentos de Plan de Tesis;
• matrices;
• revisiones bibliográficas;
• decisiones metodológicas;
• comentarios de posibles asesores;
• cambios progresivos de redacción.

Cuando esta información vive principalmente en chats, resulta difícil:

• recordar cuál es la versión vigente;
• encontrar decisiones anteriores;
• saber qué está definido y qué está pendiente;
• identificar qué fuentes respaldan cada decisión;
• visualizar la estructura completa de la tesis;
• detectar contradicciones;
• consultar rápidamente una sección específica.

Por ello se quiere trasladar el centro operativo del trabajo hacia:

GitHub + Markdown + una web Astro simple

y utilizar ChatGPT y Codex como herramientas de análisis y edición sobre esa base.

3. PRINCIPIO CENTRAL

La regla principal del proyecto es:

EL REPOSITORIO ES LA FUENTE DE VERDAD.

Los chats sirven para:

• investigar;
• analizar;
• discutir alternativas;
• revisar consistencia;
• proponer cambios;
• redactar;
• criticar.

Pero las decisiones vigentes deben terminar registradas en los Markdown del repositorio.

4. ARCHIVOS PRINCIPALES

4.1 TESIS_MAESTRA_360_v0_1.md

Es el archivo principal de contenido.

Contiene:

• estructura general de la tesis;
• Capítulo I;
• Capítulo II;
• Capítulo III;
• Capítulo IV;
• Capítulo V;
• conclusiones;
• recomendaciones;
• referencias;
• anexos;
• notas internas;
• estados;
• fuentes;
• pendientes;
• decisiones.

Por ahora se trabajará con un solo Markdown principal para facilitar:

• lectura completa;
• navegación;
• búsqueda mediante Ctrl+F;
• edición sencilla;
• revisión con Codex;
• acceso desde la web.

Más adelante podrá dividirse si su tamaño lo hace necesario.

4.2 ROADMAP_MAESTRO_TESIS_360_v0_1.md

Es el documento de contexto y dirección metodológica.

Su función es explicar:

• qué investigación se está desarrollando;
• cuál es la lógica de la tesis;
• qué decisiones están definidas;
• qué decisiones siguen provisionales;
• qué falta investigar;
• cómo se conectan OE1, OE2 y OE3;
• qué bibliografía cumple cada función;
• qué elementos deben mantenerse trazables.

No necesariamente todo su contenido aparecerá en la tesis final.

5. QUÉ QUEREMOS QUE HAGA LA WEB

La primera versión debe ser deliberadamente simple.

5.1 Página inicial

Debe mostrar:

• título del proyecto;
• breve descripción;
• acceso al Markdown maestro;
• índice general;
• acceso al roadmap;
• estado general del proyecto.

5.2 Lectura del Markdown maestro

La web debe renderizar el contenido de:

TESIS_MAESTRA_360_v0_1.md

de forma limpia y legible.

Debe respetar:

• encabezados;
• tablas;
• listas;
• citas;
• bloques de código;
• negritas;
• cursivas;
• enlaces internos.

5.3 Índice navegable

Al inicio de la página debe existir un índice que permita ir directamente a:

• Capítulo I;
• Capítulo II;
• Capítulo III;
• Capítulo IV;
• Capítulo V;
• Conclusiones;
• Referencias;
• Anexos;
• Registro de decisiones y pendientes.

Idealmente también debe mostrar subsecciones relevantes.

Los enlaces deben utilizar anclas de encabezados.

5.4 Navegación lateral opcional

Si es simple de implementar, se puede agregar una barra lateral fija con:

• índice del documento;
• sección actual;
• enlaces a capítulos.

No debe complicar el proyecto.

5.5 Búsqueda

No se requiere por ahora un motor de búsqueda propio.

El diseño debe permitir usar fácilmente:

Ctrl + F

para buscar:

• autores;
• conceptos;
• OE1;
• OE2;
• OE3;
• PENDIENTE;
• DEFINIDO;
• ground truth;
• TRC;
• nombres de referencias;
• títulos de secciones.

6. ESTADOS QUE DEBEN SER VISIBLES

El Markdown utiliza estados como:

• [DEFINIDO]
• [PROVISIONAL]
• [PENDIENTE]
• [VERIFICAR]
• [DESCARTADO]

La web puede mostrarlos tal como están escritos.

Opcionalmente, si puede hacerse sin complejidad, se pueden convertir en etiquetas visuales discretas.

No es obligatorio en la primera versión.

7. CONTEXTO ACADÉMICO DE LA TESIS

La tesis propone una metodología de documentación fotográfica 360° aplicada a construcción.

La lógica vigente es:

literatura y antecedentes
→ problemas, necesidades y requisitos — OE1
→ diseño de metodología — OE2
→ aplicación en un caso de construcción
→ generación de historial visual
→ consultas concretas realizadas por profesionales — OE3
→ respuestas verificables
→ TRC + tiempo
→ percepción complementaria
→ resultados y discusión

8. PRINCIPIO DE TRAZABILIDAD

Una idea central del proyecto es poder responder siempre:

¿De dónde salió esta decisión?

La cadena deseada es:

fuente → hallazgo → necesidad/requisito → decisión de diseño → componente metodológico → aplicación → resultado

La web debe facilitar leer esa trazabilidad, no ocultarla.

9. QUÉ NO QUEREMOS HACER TODAVÍA

En esta primera etapa NO se necesita:

• base de datos;
• autenticación;
• CMS;
• editor web;
• panel administrativo;
• buscador avanzado;
• comentarios;
• sincronización en tiempo real;
• sistema de usuarios;
• backend;
• visualización compleja;
• múltiples modos de edición;
• conversión automática a Word/PDF;
• gráficos de progreso sofisticados;
• integración con IA dentro de la web.

La prioridad es:

lectura + navegación + claridad + simplicidad

10. TECNOLOGÍA PROPUESTA

Frontend

Astro

Motivos:

• sencillo;
• rápido;
• adecuado para contenido estático;
• excelente soporte de Markdown;
• fácil despliegue;
• suficiente para este proyecto.

Fuente de contenido

Archivos .md almacenados en el repositorio.

Despliegue

Puede mantenerse el flujo actual:

GitHub
→ build
→ Astro
→ despliegue web

Si ya existe infraestructura previa del proyecto, debe reutilizarse antes de crear una nueva.

11. EXPERIENCIA DE USO ESPERADA

Al abrir la web, el usuario debería poder:

1. ver el nombre de la tesis;
2. entender en una frase qué está viendo;
3. acceder al índice;
4. hacer clic en un capítulo;
5. leer el Markdown renderizado;
6. volver al índice;
7. usar Ctrl+F;
8. distinguir contenido definido, provisional y pendiente;
9. consultar el roadmap si necesita entender la lógica metodológica.

12. ESTRUCTURA VISUAL SUGERIDA

TESIS 360°
────────────────────────────────

[Inicio] [Tesis Maestra] [Roadmap]

Título de la tesis
Estado: En desarrollo

ÍNDICE
├── Capítulo I
├── Capítulo II
├── Capítulo III
├── Capítulo IV
├── Capítulo V
├── Conclusiones
├── Referencias
└── Anexos

────────────────────────────────
Contenido de la sección
────────────────────────────────

13. CRITERIOS DE DISEÑO

La web debe ser:

• sobria;
• académica;
• legible;
• rápida;
• fácil de mantener;
• responsive;
• usable desde escritorio y móvil;
• sin dependencias innecesarias;
• sin animaciones llamativas;
• sin complejidad visual.

Priorizar:

• tipografía clara;
• ancho de lectura razonable;
• buena jerarquía de encabezados;
• tablas legibles;
• enlaces internos visibles;
• buen contraste.

14. FORMA DE TRABAJO CON CODEX

Codex deberá:

1. leer este documento;
2. leer TESIS_MAESTRA_360_v0_1.md;
3. revisar la estructura existente del repositorio;
4. reutilizar lo que ya exista;
5. implementar la solución más simple posible;
6. no modificar el contenido académico salvo que sea estrictamente necesario para renderizarlo;
7. evitar refactors grandes sin necesidad;
8. documentar qué archivos creó o modificó.

15. PRINCIPIO DE MÍNIMA COMPLEJIDAD

Toda decisión técnica debe responder:

¿Esto ayuda realmente a leer, navegar o mantener la tesis?

Si la respuesta es no, no debe incluirse en esta primera versión.

16. POSIBLES MEJORAS FUTURAS

Solo después de que la versión simple funcione correctamente, se podrá evaluar:

• buscador interno;
• filtros por estado;
• vista de pendientes;
• vista de bibliografía;
• grafo de trazabilidad;
• histórico de decisiones;
• exportación;
• separación del Markdown maestro en varios archivos;
• integración con citas;
• panel de progreso.

Nada de esto es requisito inicial.

17. RESULTADO ESPERADO DE ESTA PRIMERA ETAPA

Al finalizar, debe existir una web sencilla donde:

• el Markdown maestro sea fácil de leer;
• el índice permita navegar entre secciones;
• el roadmap sea accesible;
• la tesis pueda seguir editándose directamente en Markdown;
• cada git push actualice la web;
• el repositorio continúe siendo la fuente principal del proyecto.

18. RESUMEN EN UNA FRASE

Construir una web Astro simple que convierta los Markdown de la tesis en una interfaz de lectura y navegación clara, manteniendo GitHub como fuente de verdad y evitando complejidad innecesaria.