¿Qué pasó ayer?

Open-source MCP server and AI skill for technical debt, recurring issues, project knowledge graphs, cross-project dependencies, real-time agent handoffs, change context, and collaborative software engineering.

¿Qué pasó ayer? busca que un equipo pueda responder rápidamente:

• ¿Qué cambió y quién lo cambió?

• ¿Por qué esta función tiene esta regla o límite?

• ¿Qué servicio o proyecto impone esa restricción?

• ¿Qué puede romperse si la modificamos?

• ¿Hay otra persona o agente trabajando en lo mismo?

• ¿Qué quedó aplicado, verificado, pendiente o bloqueado?

El sistema organiza el conocimiento como un mapa causal multidimensional: proyectos, servicios, conexiones entre proyectos, dependencias técnicas, reglas, decisiones, modificaciones, incidentes, evidencia, usuarios, agentes y sesiones.

Estado

El proyecto está en MVP local. El repositorio contiene:

• un CLI instalable con un instalador seguro de la skill;

• un servidor MCP local por stdio con persistencia durable por proyecto;

• carga y extracción multidimensional con relaciones causales;

• revisión optimista, idempotencia, aislamiento entre proyectos y rechazo básico de secretos;

• una skill que obliga a comprobar la asociación antes de compartir contexto;

• la arquitectura conceptual y el roadmap del MVP.

Todavía no incluye el servicio remoto multiusuario, Streamable HTTP, OAuth, PostgreSQL ni configuración automática de dominio. El almacén actual es local y no debe presentarse como servidor colaborativo terminado.

Inicio rápido

Requiere Node.js 20 o superior.

npx que-paso-ayer@latest init
npx que-paso-ayer@latest doctor
npx que-paso-ayer@latest mcp --stdio

El primer comando instala tanto la skill como la configuración MCP del proyecto. Reinicia Codex o inicia una conversación nueva después de ejecutarlo.

init busca la raíz Git e instala dos piezas con alcance de proyecto:

<proyecto>/.agents/skills/coordinate-project-relay
<proyecto>/.codex/config.toml

La segunda contiene un bloque administrado que inicia el MCP con npx y fija los datos en <proyecto>/.qpa/knowledge.json. Esto limita la skill y el servidor al proyecto; Codex solo carga configuraciones MCP de proyectos confiables, según su documentación oficial. init no registra ni activa el proyecto dentro del MCP: la asociación se realiza después, con aprobación explícita del usuario.

La instalación es idempotente, admite --dry-run, preserva el resto de config.toml y nunca reemplaza una skill modificada o ajena sin --force; en ese caso conserva una copia de seguridad. Tampoco pisa una tabla MCP del mismo nombre que no haya sido creada por el instalador.

También puede instalarse globalmente:

npm install --global que-paso-ayer
qpa init
qpa doctor
qpa mcp --stdio

Compatibilidad prevista:

pnpm dlx que-paso-ayer doctor
yarn dlx que-paso-ayer doctor
bunx que-paso-ayer doctor

La instalación como plugin Codex incluye el MCP y la skill en el mismo paquete. Al instalar mediante npm, qpa init copia explícitamente la skill incluida. Las skills nuevas se descubren al iniciar una sesión nueva del agente.

Instalar el plugin en Codex

Agrega el marketplace público del repositorio e instala el plugin:

codex plugin marketplace add franmelx/que-paso-ayer --ref main
codex plugin add que-paso-ayer@que-paso-ayer

Después inicia una sesión nueva. El marketplace instala la versión compatible desde npm sin ejecutar scripts de ciclo de vida. También puedes consultar las fuentes configuradas con codex plugin marketplace list.

La versión 0.4.0 se distribuye por npm y mediante GitHub Releases.

Datos locales del MVP

Por defecto, el MCP guarda el conocimiento en .qpa/knowledge.json del directorio de ejecución. Para pruebas o aislamiento se puede definir QPA_DATA_FILE con una ruta explícita. Las herramientas disponibles son:

• project_register: registra un proyecto solo con approvedByUser: true;

• project_association_check: comprueba asociación sin escribir;

• participant_register: registra usuarios y agentes por proyecto, con especialidades, modelo y capacidades;

• knowledge_record: carga conocimiento con revisión e idempotencia;

• knowledge_query: extrae por proyecto, términos, tipo, certeza, dimensiones y revisión.

• knowledge_transition: registra transiciones de estado por registro de conocimiento con rastro auditable.

• activity_report: resume cambios por proyecto desde una revisión o timestamp.

• session_start: inicia una sesión de trabajo colaborativo para un actor;

• session_heartbeat: actualiza el estado de la sesión y devuelve cambios desde el cursor;

• checkpoint_publish: guarda un checkpoint duradero de contexto y progreso;

• session_finish: cierra sesión y consolida checkpoints publicados;

• active_sessions: lista sesiones activas por proyecto;

• impact_analyze: estima impacto en otras áreas/proyectos desde un disparador de conocimiento.

Este archivo local es adecuado para el MVP y sus pruebas de contrato. La operación realmente multiusuario requerirá el backend PostgreSQL y la autenticación planificados.

Principios

1. Detectar no significa registrar.

2. Registrar no significa confirmar.

3. Confirmar no significa activar.

4. Un proyecto no asociado no envía ni consulta información.

5. Las hipótesis nunca se presentan como causas confirmadas.

6. applied, verified, partial, blocked y reverted son estados diferentes.

7. No se almacenan secretos, razonamiento interno ni código fuente completo por defecto.

Arquitectura

La visión inicial se encuentra en docs/architecture/overview.md. El alcance del primer producto verificable está en docs/roadmap/mvp.md.

Comunidad

Consulta CONTRIBUTING.md, CODE_OF_CONDUCT.md, SECURITY.md y GOVERNANCE.md antes de colaborar.

Los cambios publicados se documentan en CHANGELOG.md. Consulta también PRIVACY.md y TERMS.md.

Licencia

Apache License 2.0. Consulta LICENSE.