ProjectOS: validar los flujos antes de depender del sistema

Estado: En curso. R2 recibió la aceptación acotada del Arquitecto y del Product Owner. R3 sigue en revisión; este registro describe una validación con datos sintéticos, no una instalación ni un lanzamiento.

El reto es mantener coherente el trabajo

ProjectOS está pensado para una persona que coordina proyectos personales y profesionales. Su función es convertir un resultado deseado en un proyecto acotado, hitos y tareas concretas; mostrar los prerrequisitos y el trabajo simultáneo; y conservar un registro inspeccionable a medida que cambian los planes. La motivación de fondo es cotidiana: compiten las prioridades, se expanden tareas tangenciales y se vuelve difícil saber qué sigue o qué es seguro comenzar.

Esos son objetivos de diseño, no resultados medidos de productividad. Antes de depender del sistema para trabajo real, la revisión planteó una pregunta más básica: ¿el proyecto, sus tareas y relaciones, sus fechas y su historial siguen contando la misma historia durante el uso habitual, las ediciones y la recuperación?

ProjectOS conserva sus registros canónicos en Markdown legible por personas, para un flujo de trabajo con bóveda local. SQLite es una proyección de consultas reconstruible: ayuda a recuperar y mostrar registros, mientras Markdown sigue siendo la autoridad. Los controles de revisión protegen las ediciones cuando el estado ya cambió en otro lugar. Por eso, la recuperación y la integridad de los registros forman parte de la experiencia, además de la implementación interna.

1. Flujos diarios coherentesR28 de octubre de 2026 · aceptación acotada
2. Fiabilidad bajo evaluaciónR3En curso · criterios de aceptación pendientes

R2 hizo más coherente el flujo de trabajo diario

R2 abordó las partes que una persona encuentra al planificar y completar tareas: formularios tipados de Task y Subtask, controles de finalización, visibilidad del trabajo en curso, actualización de las vistas afectadas, presentación de comentarios, exportación de fechas sin hora y recuperación cuando la respuesta de guardado es incierta. El candidato recibió aceptación acotada del Arquitecto y del Product Owner el 8 de octubre de 2026. Esa aceptación cubrió recorridos profesionales y personales revisados y la recuperación del estado descartable; el comportamiento de interfaz con otra zona horaria del navegador y parte de la evidencia de CI quedaron fuera del alcance demostrado.

La aceptación de R2 estableció una base útil para la siguiente pregunta. ¿Seguirían siendo confiables los registros y las relaciones si el repositorio cambiaba bajo carga, hubiera que reconstruir una vista derivada o el paquete de escritorio tuviera que recuperarse?

R3 prueba el sistema alrededor de esos flujos

R3 se centra en el rendimiento, la contención y actualidad de las escrituras, la recuperación, el comportamiento existente de Habit y el ciclo de vida y empaquetado de Windows. Una optimización aceptada del repositorio redujo el trabajo repetido sobre rutas del sistema de archivos, conservando las verificaciones de enlaces, la resolución estricta de rutas y los controles de contención. También se ajustó la caché para mantener aislados los datos mutables de las entidades entre quienes los consultan. Otros cambios revisados hacen más explícitos el orden de observación de la proyección, el comportamiento alternativo cuando falla una consulta y el estado del observador, sin quitarle a Markdown la autoridad sobre los datos.

El Arquitecto ejecutó de manera independiente 47 pruebas de integración de lectura y escritura del repositorio. Cubrieron el rechazo de uniones de directorios, el recorrido fuera de la ruta permitida, las discrepancias entre la ruta observada y la esperada, el aislamiento de la caché, las revisiones y la preparación de escrituras. Pasaron las 47 en esa versión revisada. Esto respalda el cambio específico de seguridad del repositorio, no la aceptación del producto completo.

El paquete se probó con recorridos sintéticos completos

En una bóveda sintética aislada, el candidato portátil completó un recorrido de proyecto profesional y otro personal, incluidas sus acciones explícitas de cierre. El recorrido personal ejercitó ambas formas admitidas de elemento hijo: una Subtask real y una Task histórica con relación a su elemento superior. Una inspección independiente corroboró los proyectos completados, los comprobantes de creación y las relaciones guardadas. El selector de Task también llegó a las filas 251–300, guardó una Task relacionada y mostró el vínculo al volver a leerla. La interfaz existente de Habits guardó una finalización numérica y un Skip. La revisión ejercitó estas capacidades; esta continuación no introdujo un nuevo Habit Tracker ni demostró que todos los flujos estén completos.

Los campos de fecha del asistente necesitaron recibir la entrada con el teclado y el foco en el control para que los valores llegaran al estado de la aplicación. Después de corregir el método de prueba, ambos recorridos de proyecto se completaron; el intento de automatización descartado no confirmó un defecto del producto.

Una comparación con el estado inicial de esa misma bóveda sintética aislada encontró 1,243 registros Markdown sin cambios, ningún registro cambiado o eliminado y 16 incorporaciones previstas; desapareció un bloqueo efímero del escritor. El resultado describe solo ese escenario. No demuestra la preservación universal de datos ni describe una bóveda activa.

El resultado de rendimiento fija la siguiente restricción

Con 1,212 entidades sintéticas iniciales, el Worker midió 100 creaciones y 100 actualizaciones con el observador desactivado. El p95 del servicio/servidor fue de 4.602 segundos para crear y 6.493 segundos para actualizar, frente al objetivo de 2 segundos para escrituras habituales. La medición cubre la ruta del servicio/servidor, no el recorrido completo hasta que el cambio aparece en la interfaz; ambos resultados siguen fuera del objetivo declarado.

Creación

4.602 sObjetivo: 2 s · excedido

Actualización

6.493 sObjetivo: 2 s · excedido

El Arquitecto aceptó el cambio de código como una optimización acotada, pero el criterio de rendimiento sigue abierto y no se eximió su objetivo. Las muestras anteriores utilizaron condiciones de corpus distintas, por lo que no demuestran una mejora de velocidad controlada atribuible al cambio. Se aplazó una alternativa que confirmaría el guardado antes de completar todo el procesamiento: la latencia estimada aún excedía el objetivo y la recuperación y confirmación serían más complejas.

La medición hace visible la disyuntiva: conservar una confirmación veraz del guardado y mejorar la ruta medida, en vez de cambiar el significado de una escritura exitosa sin una vía creíble para alcanzar el objetivo.

Lo que falta antes de confiarle trabajo real

La continuación deja abiertas varias preguntas de aceptación:

• No se completó una prueba exploratoria de capacidad con 5,000 entidades ni una prueba de resistencia de 60 minutos.
• La corrección y anulación de evidencia de Habit para una fecha anterior, el cambio controlado de día y el comportamiento ante la pérdida de la proyección en el paquete exacto siguen pendientes. Los resultados del arnés temporal y las pruebas de interfaz del paquete son evidencias distintas.
• Se verificó de forma independiente que el backend sintético seguía activo y listo según su comprobación de salud. La bandeja nativa, el singleton, el reinicio, los recordatorios, la medición de memoria y la aceptación del instalador aislado siguen pendientes; una comprobación de cierre ordenado mediante evento con nombre cubre solo ese caso del backend.
• Se corrigió una prueba intermitente del observador para esperar una observación nativa real antes de editar; se mantuvo su comprobación de actualidad. Otra prueba verifica la recuperación automática mediante un nuevo escaneo. Esto valida escenarios acotados, no una garantía universal de actualización.
• Las latencias de creación y actualización siguen por encima del objetivo de 2 segundos.

El trabajo pendiente consiste en cerrar la brecha de rendimiento medida y completar las verificaciones de capacidad, recuperación, Habit, ciclo de vida nativo e instalación aislada. Estos criterios importan porque este sistema está pensado para conservar tanto los planes como la evidencia de lo ocurrido.

Por qué esta revisión resulta útil

La revisión utilizó registros sintéticos y un paquete portátil aislado. No utilizó una bóveda activa, la aplicación instalada actual ni un entorno de instalación. El Arquitecto aceptó la optimización acotada del repositorio, mientras WO-STAB-03 seguía incompleto en el candidato revisado. No se establece una aceptación final de R3, una exención de rendimiento, una instalación en producción, una migración ni un lanzamiento.

Para quienes evalúan el criterio técnico, el valor aquí es ver cómo se construye la fiabilidad: modelar las reglas del flujo de trabajo, mantener inspeccionables los registros fuente, probar recorridos completos, medir la ruta de la que dependen las personas y dejar visibles los criterios pendientes. El trabajo demuestra ese método y varios escenarios acotados. Cualquier mejora de productividad sigue siendo un objetivo, no un resultado medido.