Front Office

Sistema de registro de diseño-ops para proyectos construidos en conversación con IA: registros de decisiones, preguntas abiertas y documentos como vistas generadas — para que cada sesión (humana o IA, hoy o dentro de meses, paralela o secuencial) trabaje desde el mismo cerebro en lugar del scrollback del chat.

Nacido de un problema real: diseñar un juego a lo largo de largas sesiones de IA produjo 46 decisiones registradas, y "¿eso se aprobó realmente?" seguía requiriendo una auditoría. Front Office convierte el rastro de auditoría en el artefacto principal.

Ideas centrales

• El registro de decisiones es un registro de eventos. Cada decisión lleva cuándo / quién / por qué, una etiqueta de procedencia — [A] decisión humana explícita · [A→C] dirección humana, especificación de IA · [C→A] propuesta de IA, ratificada por humano · [C] asumido por IA, vigente pero vetable — y un estado (✅ decidido · 🕐 pendiente de documento · 💬 propuesto). Las correcciones son nuevas entradas que referencian a las anteriores, nunca ediciones.

• Las preguntas abiertas son registros, no scrollback. Los elementos sin responder viven en un archivo rastreado hasta que se resuelven — con una entrada en el registro.

• Los documentos son compilaciones. Los paquetes de contexto y las vistas de estado se generan a partir de los registros; el markdown es el almacenamiento y el formato de intercambio, por lo que no hay bloqueo — los archivos son útiles sin ninguna herramienta.

• La salvaguarda del jinete. Una propuesta adjunta a una decisión aprobada nunca hereda esa aprobación. Los borradores escritos por IA son siempre 💬.

Related MCP server: kb

Uso

npm ci
npm run fo -- status                 # counts, unratified [C] list, pending rulings
npm run fo -- decisions --provenance C --status decided
npm run fo -- open --section A
npm run fo -- show 12
npm run fo -- pack                   # writes projects/<p>/context-pack.md
npm run fo -- validate               # CI-able: exit 1 on invariant violations

Los datos del proyecto viven en projects/<name>/ que contiene *decision-log.md y *open-items.md (consulta test/fixtures/ para el formato). projects/ está en gitignore — los datos del inquilino son tuyos y permanecen privados. Apunta a otro lugar con --project <dir> o FO_PROJECT_DIR.

Interfaz web

npm run fo -- pack   # optional: regenerate views first
npm run web          # http://localhost:4747 (FO_PORT / FO_PROJECT_DIR to override)

Panel en vivo sobre los mismos archivos: feed de decisiones con chips de procedencia/estado y filtros, franja de atención (decisiones pendientes, [C] no ratificados), elementos abiertos por sección, estadísticas — y un formulario de borrador (los borradores son siempre 💬). Separación 100% UI/lógica: el cliente no contiene lógica de negocio; cada valor derivado llega precalculado desde /api/state, el navegador solo renderiza y envía comandos.

Servidor MCP (la conexión de cerebros)

Expone los registros a cualquier sesión de Claude Code:

claude mcp add front-office --scope user -- npx tsx <repo>/src/mcp/server.ts

Herramientas: get_context_pack · list_decisions · list_open_items · draft_decision (siempre 💬) · get_stats. Configura FO_PROJECT_DIR en el entorno del servidor para seleccionar el proyecto.

Arquitectura

Según la propia doctrina del proyecto (sí, sus decisiones de diseño se rastrean en un registro de Front Office):

• src/core, src/adapters, src/views — puros (perfil ESLint funcional estricto: sin let/bucles/clases/mutación, los relojes y la aleatoriedad deben inyectarse).

• src/shell, src/mcp — el borde de efectos (perfil moderado).

• Los analizadores mantienen las celdas crudas verbatim → la serialización hace round-trip exacto (parse(serialize(parse(x))) ≡ parse(x), probado por propiedades).

npm run typecheck && npm run lint && npm test

MIT.