Workspace Intelligence

Workspace Intelligence responde a una sola pregunta: ¿cómo funciona este proyecto?

No se trata de lo que contienen los archivos. Eso un agente puede leerlo, y lo lee bien. Lo que no puede leer es el conocimiento práctico que un repositorio va acumulando alrededor de su código, que es justamente el que decide si un cambio es correcto o solo parece razonable.

Qué modela

• Decisiones de arquitectura, y el razonamiento que las originó.
• Restricciones ocultas que no se ven en ninguna parte del código.
• Requisitos de verificación: qué hay que comprobar antes de dar algo por terminado.
• Correcciones anteriores: qué funcionó realmente la última vez que apareció este problema concreto.
• Convenciones que un equipo sigue sin ponerlas por escrito.
• Procedimientos: el orden en que se hace aquí una tarea recurrente.
• Hechos de contexto que cambian el enfoque correcto, como que una base de datos sea una réplica de solo lectura.
• Justificación técnica, que es lo que impide que un agente, con la mejor intención, deshaga una decisión deliberada.
• Implementaciones preferidas entre varias que funcionarían igual.
• Decisiones reemplazadas, para que una decisión antigua deje de tratarse como vigente.

Todo esto vive en tres tipos de contenido que tu equipo puede leer y editar: memorias, reglas y skills.

Alcance

Workspace Intelligence está vinculada a un repositorio y, dentro de él, a rutas.

Este es el mecanismo que evita que una capa de conocimiento se convierta en el problema que debía resolver. No todo lo que es cierto sobre un monorepo es relevante para un cambio en un paquete, y entregarlo todo hace que las tres frases que importan compitan con doscientas que no importan. El conocimiento se asocia a la ruta que rige, y una tarea en esa ruta recibe lo que la rige.

La vinculación a rutas es también lo que permite que un espacio de trabajo siga creciendo sin que cada turno se vuelva más pesado. Consulta cómo funciona la recuperación.

Autoridad

Workspace Intelligence es la capa que puede contener requisitos obligatorios.

Los requisitos viven en las reglas. Una regla indica lo que debe o no debe ocurrir en un ámbito, tiene una prioridad y llega en su propia sección, separada de los consejos. Una regla también puede incluir una restricción ejecutable, es decir, un patrón que un cambio no debe contener. Una restricción que propone un agente se guarda como propuesta y no se aplica; una vez que una persona la aprueba, el hook previo a la herramienta puede bloquear una edición que coincida en los clientes cuyos hooks lo admiten. Consulta las reglas como barreras de protección.

Estas son propiedades del proyecto. No se descartan porque una preferencia personal resulte más cómoda, y User Intelligence no puede prevalecer sobre ellas. Todo lo demás que contiene Workspace Intelligence es orientativo y se entrega como consejo, así que una corrección anterior nunca se presenta como si tuviera más peso que una regla.

Fuentes

Hay cuatro tipos, y importa distinguir cuál es cuál.

Escritas. Memorias, reglas y skills que una persona escribió a propósito, o que un agente escribió con las herramientas de Pathrule, normalmente después de proponértelas. Son las que un equipo puede señalar y discutir, y forman la columna vertebral.

Hallazgos a partir del código. Conclusiones a las que llegó un agente al leer tu código, guardadas junto con los archivos en los que se basan y entregadas como consejo solo mientras esos archivos no cambien. Consulta aprendizaje del proyecto.

Evidencia del trabajo real. Lo que las sesiones de los agentes informaron sobre sí mismas: qué conocimiento se entregó, cuál se consultó de verdad, qué archivos cambiaron juntos, dónde un agente se atascaba una y otra vez. Consulta qué calcula Pathrule.

Sembradas desde tu copia local, en un espacio de trabajo de Cloud. La primera vez que un agente le pide a Pathrule contexto profundo en un espacio de trabajo de Cloud, el entorno de ejecución local lee las rutas de archivo del historial reciente de git para saber qué archivos han cambiado juntos, y lista los nombres de archivo de los primeros niveles del árbol de carpetas para reconocer las tecnologías en uso, como una configuración de TypeScript, Docker o GitHub Actions. Los pares de rutas se guardan en el espacio de trabajo como punto de partida de los archivos que cambian juntos, de modo que la señal resulta útil antes de que tu equipo haya registrado mucho trabajo. Cada tecnología que reconoce se convierte en una memoria breve en la raíz del espacio de trabajo, como "TypeScript project", escrita sin preguntar; es una memoria normal que puedes editar o eliminar. Un espacio de trabajo local omite este paso y aprende qué archivos cambian juntos solo a partir del trabajo registrado.

Lo que no es una fuente: tu código fuente. Pathrule no sube tu código automáticamente, y la siembra anterior lee nombres de archivo y rutas, no el contenido de los archivos, los diffs ni los mensajes de commit. En un espacio de trabajo de Cloud, pathrule snapshot, cuando tú o tu agente lo ejecutan, sube el árbol de archivos, los manifiestos, muestras breves de documentación y metadatos recientes de git para que Pathrule pueda describir el proyecto. En qué calcula Pathrule se detalla qué se lee y qué se conserva.

Team Intelligence

En Pathrule Cloud, Team Intelligence revisa la evidencia que produce el trabajo de un equipo y propone patrones: convenciones, correcciones y decisiones que se repiten. Está disponible en los planes Team y Enterprise, y los propietarios y administradores de la organización lo gestionan en la consola web, en la configuración Team guidance de la organización.

Un patrón pasa de borrador a sugerido, y una persona lo verifica o lo rechaza; una sugerencia que nadie atiende caduca. Solo los patrones verificados llegan a los agentes. Nada de lo que infiere Team Intelligence se considera confiable por sí solo.

Ciclo de vida

1. Escrito o propuesto. Una persona lo escribe con la CLI, la extensión de VS Code o su agente. Un agente que descubrió algo que vale la pena conservar lo guarda con las herramientas de escritura de Pathrule, normalmente después de proponértelo, y cada escritura queda atribuida, versionada y es reversible. Si le pides a tu agente "Set up Pathrule for this project", se ejecuta un análisis guiado en el que el agente propone memorias, reglas y skills y escribe las que apruebes. En un espacio de trabajo de Cloud, Pathrule también agrega las memorias breves de tecnología descritas arriba.
2. Aprobado, cuando algo se infirió. El conocimiento inferido espera a una persona: la restricción ejecutable de una regla solo se aplica después de su aprobación, y un patrón de Team Intelligence llega a los agentes solo una vez verificado. Los hallazgos de los agentes son la única excepción, y siguen siendo orientativos. Consulta Proposed Knowledge.
3. Entregado. La parte relevante para una tarea llega al agente mediante el mecanismo que admite su cliente. Consulta Agent IR.
4. Medido. Se registra la entrega y lo que el agente hizo con ella, de modo que la posición de cada entrada refleja lo que ocurrió y no quién la escribió.
5. Actualizado, reemplazado o retirado. El conocimiento que parece desactualizado puede marcarse como tarea de actualización, y una persona o un agente se encarga de ella. Una decisión que otra posterior reemplazó deja de tratarse como vigente. Consulta sugerencias y autoauditoría.

Qué cambia cuando cambias de proyecto

Todo. Workspace Intelligence pertenece al repositorio, y abrir otro significa trabajar con otro conjunto de conocimiento del proyecto, compartido con quienes también trabajan en él.

Lo que te acompaña es User Intelligence, que te pertenece a ti: las preferencias que le enseñaste a Pathrule y que elegiste aplicar en todas partes.