ProjectOS

I — El concepto central

ProjectOS parte de una premisa local-first: el estado del proyecto debe permanecer cerca del operador, ser legible fuera de la aplicación y resultar útil sin convertir un servicio remoto en el centro de la arquitectura. La interacción pensada primero para escritorio le da al sistema una presencia operativa persistente, en lugar de reducirlo a otra pestaña del navegador.

El proyecto se modela como un dominio, no como un conjunto disperso de pantallas. Las interfaces actúan mediante contratos de aplicación; los contratos operan sobre conceptos estructurados del proyecto; los artefactos persistentes conservan el estado en una forma legible por personas. Esta separación evita que la experiencia de escritorio, la superficie de API y las futuras herramientas de ejecución se conviertan por sí mismas en el modelo de dominio.

1. 01Interfaces humanasEspacio de escritorio · bandeja del sistema
2. 02Contratos de aplicaciónComandos y consultas explícitos
3. 03Dominio del proyectoEntidades y relaciones estructuradas
4. 04Estado local del proyectoArtefactos persistentes y legibles por personas

Esta disposición también permite una experiencia fluida en Windows, mientras el trabajo de ejecución puede cruzar hacia un entorno Linux local mediante una frontera explícita. La frontera es arquitectónica: cada interfaz recibe un contrato definido, en lugar de autoridad directa sobre el estado del proyecto.

II — Interfaz e interacción

ProjectOS trata el escritorio como un entorno operativo para el proyecto. El espacio de trabajo principal puede ocupar toda la ventana, conservar contexto entre vistas y permanecer accesible desde la bandeja del sistema. El objetivo no es imitar un dashboard web, sino reducir la distancia entre observar el estado del proyecto y actuar sobre él.

El modelo de interacción combina:

• carriles Kanban dinámicos con medidas visibles de trabajo en curso;
• un calendario integrado con vistas de Día, Semana, dos semanas, Mes y Trimestre;
• paneles contextuales que mantienen a la vista la entidad seleccionada y sus relaciones;
• arrastrar y soltar únicamente para entidades cuyo movimiento tiene un significado definido dentro del dominio;
• acceso desde la bandeja del sistema para una presencia de escritorio persistente y de baja fricción.

Kanban y Calendario son dos proyecciones del mismo modelo de proyecto. Un cambio en una vista no es una reorganización decorativa; es una transición del estado del proyecto gobernada por la capa de aplicación. Esa diferencia mantiene la conveniencia de la interfaz subordinada a la integridad del trabajo.

Evidencia actual de interfaz

Estas capturas directas muestran la GUI de escritorio actual sobre el espacio sintético de demostración de ProjectOS. Son evidencia del producto, no maquetas conceptuales.

III — Plantillas de proyecto en la práctica

ProjectOS no está diseñado alrededor de ISO 27001. Su modelo central es general: los proyectos contienen entidades estructuradas, relaciones, artefactos, responsabilidades, vistas y rutas de ejecución. Las plantillas configuran ese modelo para un tipo de trabajo repetible sin redefinir la plataforma que existe debajo.

Se utiliza una plantilla de proyecto ISO 27001 / SGSI como ejemplo exigente porque permite mostrar muchas capacidades de ProjectOS al mismo tiempo. La plantilla puede expresar requisitos, controles, actividades de implementación, responsables, evidencia, revisiones y remediación como registros conectados del proyecto, no como documentos aislados.

1. 01Requisito
2. 02Control
3. 03Actividad
4. 04Responsable
5. 05Evidencia
6. 06Revisión
7. 07Remediación

Dentro de esta plantilla, los controles pueden permanecer conectados con las actividades de implementación; la evidencia puede conservar su vínculo con la decisión que respalda; la remediación puede regresar al mismo estado del proyecto, en lugar de desaparecer dentro de un registro separado. Una plantilla distinta podría utilizar los mismos elementos de ProjectOS para otro dominio y otro modelo de relaciones.

Una plantilla debe configurar el modelo del proyecto; no debe convertirse en la arquitectura del producto.

ISO 27001 es, por tanto, evidencia de la expresividad de las plantillas, no parte de la identidad de diseño de ProjectOS. El ejemplo tampoco afirma que ProjectOS ni ninguna organización que utilice la plantilla posean una certificación.

IV — Agent Fabric

Agent Fabric es el subsistema de ejecución situado entre el estado autoritativo del proyecto y la actividad de los agentes. No es un único agente ni es el dominio del proyecto. Recibe trabajo estructurado desde ProjectOS, establece la frontera de ejecución autorizada por una persona, coordina agentes especializados y rutas de modelos, ejecuta el trabajo aprobado dentro del entorno local, observa lo que ocurre y devuelve resultados con evidencia.

1. InterfazEscritorio de ProjectOS
2. Autoridad del proyectoContratos de aplicación / API
3. Ingreso al tejido autorizado por una personaTarea estructurada + contexto del proyecto
4. OrquestaciónFirstmate · especialización + enrutamiento de modelos
5. Entorno localPi · entorno de ejecución Linux
6. EjecuciónHerramientas + destinos

Las responsabilidades dentro del tejido

01Recepción del contrato

Recibir una tarea estructurada y el contexto relevante del proyecto a través de la frontera de aplicación de ProjectOS.

02Autorización

Preservar el alcance aprobado por la persona, incluidos el agente, las herramientas y los destinos de ejecución permitidos.

03Especialización

Asignar el trabajo a un agente cuyo rol e instrucciones operativas correspondan con la tarea solicitada.

04Enrutamiento de modelos

Seleccionar la ruta de modelo adecuada como una decisión de ejecución dentro del tejido, en lugar de incrustar un modelo en la arquitectura del proyecto.

05Ejecución local

Utilizar Pi como el entorno Linux local mediante el cual el plan aprobado alcanza herramientas y destinos de ejecución.

06Retorno de evidencia

Devolver resultados, artefactos y evidencia observable de ejecución a ProjectOS para revisión humana y una actualización deliberada del estado del proyecto.

Firstmate coordina la ejecución: ocupa el punto donde el trabajo estructurado se convierte en asignación de agente, ruta de modelo y plan de ejecución. Pi proporciona el entorno Linux local desde el que ese plan puede invocar las herramientas permitidas. Herdr es ortogonal a la secuencia; observa la ejecución a través de la orquestación y la operación, en lugar de actuar como otra etapa de la cadena.

La frontera que el tejido no cruza

Agent Fabric no es propietario de la intención de negocio, el estado autoritativo del proyecto ni la aprobación final. ProjectOS sigue siendo el sistema de registro del proyecto; el operador humano conserva la responsabilidad de autorizar trabajo con consecuencias y de aceptar o rechazar el resultado devuelto. El tejido es responsable de coordinar la ejecución y conservar su trazabilidad entre esas dos fronteras.

1. 01Intención humanaDefinir el resultado deseado para el proyecto.
2. 02Tarea estructuradaExpresar el trabajo mediante el contrato de ProjectOS.
3. 03Asignación de agenteVincular la tarea con un rol especializado.
4. 04Ruta de modeloElegir la ruta de ejecución dentro del tejido.
5. 05Plan de ejecuciónHacer inspeccionables los pasos previstos.
6. 06Llamadas a herramientasEjecutar únicamente sobre los destinos permitidos.
7. 07Resultado + evidenciaDevolver el resultado con su registro de ejecución.
8. 08Revisión humanaAceptar, rechazar o refinar el trabajo devuelto.
9. 09Actualización del estadoIncorporar el resultado revisado al estado autoritativo.

La auditabilidad es, por tanto, una propiedad del tejido, no un informe generado después de los hechos. La asignación, la ruta del modelo, el plan, la actividad de herramientas, el resultado y la evidencia permanecen diferenciados; la revisión humana es una transición explícita antes de que la salida de un agente modifique el estado autoritativo del proyecto. Esto aplica la misma frontera de revisión examinada en Juicio humano en operaciones mediadas por IA (en inglés) y el método de flujo acotado documentado en Operaciones técnicas asistidas por IA (en inglés).

V — Modelo operativo

Un proyecto no es únicamente una lista de tareas. Es una red de decisiones y dependencias que acumula memoria organizacional a medida que avanza el trabajo. ProjectOS mantiene esas relaciones dentro de un solo grafo para que la documentación, las plantillas, la ejecución y la revisión puedan referirse al mismo estado.

Centro persistenteGrafo del proyectoMemoria organizacional expresada como relaciones inspeccionables.

• Decisiones
• Responsabilidades
• Tareas
• Reuniones
• Documentos
• Controles
• Evidencia
• Riesgos
• Dependencias
• Acciones
• Agentes

Ese grafo sigue el método Avantlord a escala de sistema: Observar → Descomponer → Modelar → Construir → Probar → Refinar. La observación crea registros; la descomposición nombra las partes; el modelado conserva sus relaciones; la construcción y las pruebas generan evidencia; el refinamiento actualiza el estado sin borrar el razonamiento que lo produjo.

VI — Tesis de cierre

El objetivo no es la autonomía como espectáculo. Es un entorno operativo más sereno, donde el estado del proyecto sea legible, las plantillas permitan reutilizar trabajo complejo, la automatización sea observable y la autoridad humana permanezca explícita.