Comparto mi instalación de openclaw.

# Sistema de memoria OpenClaw — esquema completo > Pásale este documento a tu molty. Lo lee y sabe exactamente qué construir. > Sustituye `<NOMBRE>`, `<AGENTE>` y las rutas por los valores reales del usuario. --- ## ARRANQUE — se lee al inicio de cada sesión Archivo Para qué sirve `SOUL.md` Quién soy yo: tono, comportamiento, verdades fundamentales, respuesta adaptativa `USER.md` Quién eres tú: perfil, salud, familia, entorno, anclas, preferencias de trato `IDENTITY.md` Nombre del agente, rol, criatura, límites `AGENTS.md` Reglas operativas: checklist de arranque, escritura proactiva, recall, cierre `MEMORY.md` Índice de hechos y preferencias durables (lo que no debe olvidarse nunca) `<NOMBRE>.md` Histórico crudo acumulativo del usuario (no se resume, solo crece) --- ## ESTADO — la verdad ahora, no el histórico Archivo Para qué sirve `memory/state/integrated.md` Foto del momento presente por dominios: focus, reality now, next move `memory/open-loops.md` Pendientes vivos con next step — NOW / NEXT / WAITING / BLOCKED `memory/decisions.md` Decisiones durables tomadas (para no rediscutir lo mismo) `memory/session-handoff.md` Relevo entre sesiones — se reescribe en cada cierre `memory/self.md` Errores y aprendizajes del propio agente --- ## TIEMPO — capturas cronológicas Archivo Para qué sirve `memory/YYYY-MM-DD.md` Diaria: lo que pasó cada día, hechos confirmados, cierre `memory/weekly/YYYY-Www.md` Semanal: consolidación de 7 días, patrones, promociones a memoria durable Plantillas en `memory/templates/`: `daily.md`, `weekly.md`, `open-loops.md`, `decisions.md`, `state-domain.md`, `entity.md` --- ## SEMÁNTICA — largo plazo y mantenimiento Archivo Para qué sirve `memory/backbone-log.md` Log del watchdog diario `memory/audits/backbone-lint.md` Lint semanal del backbone (contradicciones, huérfanos, stale) `memory/entities/` Dossiers persistentes sobre personas o proyectos clave --- ## BÚSQUEDA **QMD** indexa todos los `.md` del workspace. `memory_search` busca semánticamente sobre ese índice. Configurar en `openclaw.json`: ```json "memory": { "backend": "qmd", "qmd": { "paths": [{ "path": "<WS>", "mask": "**/*.md" }] } } ``` Regla: cuando se cree una carpeta fuera de las rutas indexadas, actualizar `memory.qmd.paths` y reiniciar el gateway. --- ## ÁRBOL COMPLETO DEL WORKSPACE Así debe quedar el workspace principal una vez montado: ``` ~/.openclaw/workspace/ ── ARRANQUE ── SOUL.md quién es el agente IDENTITY.md nombre, rol, criatura USER.md quién es el usuario AGENTS.md reglas operativas y protocolos WORKSPACE_RULES.md higiene, trazabilidad, prioridad normativa MEMORY.md hechos y preferencias durables TOOLS.md setup del entorno (modelo, QMD, buscador) <NOMBRE>.md histórico crudo acumulativo del usuario INDEX.md índice de la raíz WORKSPACE_INDEX.md mapa de navegación del workspace memory/ ── ESTADO ── state/ integrated.md foto del presente por dominios domains/<dominio>.md estado detallado por frente (opcional) open-loops.md pendientes vivos con next step decisions.md decisiones durables session-handoff.md relevo entre sesiones self.md errores y aprendizajes del agente ── TIEMPO ── YYYY-MM-DD.md diaria weekly/YYYY-Www.md consolidación semanal ── SEMÁNTICA / MANTENIMIENTO ── MEMORY (en raíz) durable entities/ dossiers de personas/proyectos backbone-log.md log del watchdog diario audits/backbone-lint.md lint semanal ── REGLAS DEL SISTEMA ── RULES.md arquitectura por capas PROCESS.md ritmo de mantenimiento ARCHITECTURE.md diseño del segundo cerebro (opcional) ── PLANTILLAS ── templates/daily.md templates/weekly.md templates/open-loops.md templates/decisions.md templates/state-domain.md templates/entity.md tools/ update-workspace-index.sh generador de índices bin/qmd-openclaw-shim shim de QMD (si hace falta) ``` --- ## AGENTES DE DOMINIO — ×N (uno por frente con contexto propio) Cada agente tiene su propio workspace espejo con la misma estructura reducida: ``` ~/.openclaw/workspace-<AGENTE>/ AGENTS.md ← contrato reducido del agente de dominio USER.md ← contexto del usuario relevante para ese dominio MEMORY.md ← memoria durable del dominio memory/ YYYY-MM-DD.md open-loops.md state/integrated.md weekly/YYYY-Www.md templates/daily.md templates/weekly.md ``` Regla de los agentes de dominio: cada uno cierra su propio frente y **anuncia su cierre a Telegram**. El principal, además, integra todos los dominios y anuncia el cierre maestro. Añadir cada agente en `openclaw.json` → `agents.list[]` y su ruta en `memory.qmd.paths`. --- ## CRONS — automatizan la escritura Schedule Job Agente Delivery `15 16 * * *` `workspace-index-refresh` main none `35 11 * * *` `qmd-healthcheck-daily` main announce si falla `0..30 23 * * *` `<AGENTE>-daily-close` (escalonado) cada dominio announce `32 23 * * *` `memory-daily-close` main announce `40 23 * * *` `memory-backbone-keeper` (watchdog de coherencia) main announce si descuadra `45..54 23 * * 0` `<AGENTE>-weekly` (escalonado, domingo) cada dominio announce `59 23 * * 0` `memory-weekly-consolidation` main announce > Cada dominio anuncia su propio cierre a Telegram; el principal anuncia además el cierre maestro integrado. El refresco de índices no anuncia. El healthcheck QMD y el backbone-keeper solo anuncian si algo falla o descuadra. --- ## `memory/BACKBONE.md` — mapa corto del sistema Versión corta y operativa del sistema de memoria (el mapa de una ojeada). `RULES.md`/`PROCESS.md`/`ARCHITECTURE.md` son la versión larga; `BACKBONE.md` es el resumen que se lee rápido al arrancar. --- ## ORDEN DE AUTORIDAD Cuando dos capas se contradicen: Evidencia viva y archivos canónicos del frente Memoria operativa (`state/`, `open-loops`, `decisions`, `session-handoff`) Memoria durable (`MEMORY.md`, `entities/`) Vistas derivadas (índices, backbone-log, audits) Inferencias o material experimental --- ## PARA EL MOLTY — prompts de inicialización Pegar en orden en el chat del agente principal. Sustituir placeholders antes de pegar. ### PROMPT A — Identidad del usuario ``` Hazme entre 8 y 12 preguntas, de una en una, para construir USER.md: nombre, zona horaria, ubicación, frentes activos, cómo trabajo y cómo fallo, tono preferido, qué me frustra, salud relevante, anclas. Escribe <WS>/USER.md con secciones: Perfil rápido, Entorno, Anclas, Salud, Preferencias. No inventes nada. Confirma qué guardaste. ``` ### PROMPT B — Persona del agente ``` Pregúntame: qué nombre quiero darte, qué tono (directo/cálido/afilado/neutro), qué NUNCA debes hacer, y cómo adaptarte cuando tenga poca energía. Escribe <WS>/SOUL.md (identidad, tono, verdades fundamentales, respuesta adaptativa) y <WS>/IDENTITY.md (nombre, qué eres, dónde no entras). En primera persona. Confirma qué guardaste. ``` ### PROMPT C — Archivos del sistema ``` Crea estos archivos en <WS>/ usando el contenido EXACTO del apéndice "PLANTILLAS DEL SISTEMA" de este documento, adaptando <NOMBRE> y los dominios reales: - AGENTS.md - WORKSPACE_RULES.md - memory/RULES.md - memory/PROCESS.md - memory/ARCHITECTURE.md - memory/BACKBONE.md No resumas ni reinterpretes: copia el contenido y adapta solo los placeholders. Confirma el árbol creado. ``` ### PROMPT D — Esqueleto de archivos vivos ``` Crea con contenido inicial mínimo (no vacíos): - memory/<HOY>.md desde plantilla daily - memory/state/integrated.md con secciones por dominio - memory/open-loops.md con secciones NOW/NEXT/WAITING/BLOCKED/RECENTLY CLOSED - memory/decisions.md con cabecera de tabla - memory/session-handoff.md con secciones estándar - memory/self.md con cabecera y formato de entradas - MEMORY.md con cabecera - TOOLS.md con setup del entorno (modelo, QMD, buscador) - <NOMBRE>.md — histórico crudo acumulativo del usuario. Cabecera explicando que es el archivo de biografía/contexto profundo que solo crece y no se resume; arrancar con lo esencial que ya sepamos de USER.md y dejarlo listo para ir acumulando. Y plantillas en memory/templates/: daily.md, weekly.md, open-loops.md, decisions.md, state-domain.md, entity.md Confirma el árbol. ``` ### PROMPT E — Índices y QMD ``` Crea tools/update-workspace-index.sh con ROOT="<WS>": por cada carpeta conserva frontmatter y bloque <!-- MANUAL:START/END -->, escribe título+fecha, lista subcarpetas y archivos. Al final regenera WORKSPACE_INDEX.md como mapa que enlaza a los INDEX.md clave. Hazlo ejecutable, ejecútalo y confirma que generó INDEX.md y WORKSPACE_INDEX.md sin rutas ajenas. Después ejecuta: openclaw memory index --agent main --verbose Confirma documents > 0 y content_vectors > 0. ``` ### PROMPT F — Crons ``` Crea los crons de mantenimiento con la herramienta cron de OpenClaw. Zona horaria: <TZ>. Timeout de todos: 600s. Chat de Telegram: <CHAT\_ID>. workspace-index-refresh — "15 16 * * *" — main — delivery none Cuerpo: "Ejecuta <WS>/tools/update-workspace-index.sh y luego openclaw memory index --agent main --verbose." qmd-healthcheck-daily — "35 11 * * *" — main — announce a <CHAT\_ID> SOLO si falla Cuerpo: "Healthcheck ligero de QMD. Para main y cada agente de dominio revisa el índice en ~/.openclaw/agents/<agent>/qmd/xdg-cache/qmd/index.sqlite y verifica: 1) la base existe; 2) documents > 0; 3) content_vectors > 0. Para main, además, smoke test real de búsqueda: 'qmd search <colección-main> \"<término que exista>\" -n 1' (usar search, no query). Una DB con vectores puede no responder; el smoke lo caza. Si todo está bien: no envíes nada. Si algo falla o sale a cero: avisa en una línea empezando por '⚠️ QMD healthcheck' diciendo qué agente falló y si es ausencia de DB, documents=0, vectors=0 o smoke fallido. No hagas auditoría amplia ni regeneres índices: esto solo detecta rotura." memory-daily-close — "32 23 * * *" — main — announce a <CHAT\_ID> Cuerpo: "PRECHECK: si memory/<HOY>.md no existe, créala desde memory/templates/daily.md (fecha local de hoy en <TZ>). OBJETIVO: la diaria debe leerse como el diario del usuario, no como informe técnico. Primero un relato humano del día (qué pasó, qué tono tuvo, qué ocupó la cabeza, qué se resolvió, qué pesó, qué quedó abierto). Esqueleto: Qué pasó / Qué cambió / Qué queda pendiente. Después añade la parte operativa: timeline, estado por dominios, cambios, decisiones, pendientes, gaps. Primero captura completa, después curación: 'signal > inventory' aplica a state/, open-loops, decisions y MEMORY.md, NO a recortar la diaria. PASO 1 — Reconstruye el día real: - Lee memory/<HOY>.md y la de ayer; las diarias de hoy de los agentes de dominio; memory/state/integrated.md, memory/open-loops.md, memory/decisions.md y memory/RULES.md. - OBLIGATORIO: usa sessions_list (agentId main) para leer tus propias sesiones del día de hoy. Sin esto el relato del día queda incompleto. No inventes lo que no esté en sesiones o archivos. PASO 2 — Propaga: actualiza state/ si cambió la verdad, open-loops.md si abriste o cerraste algo, decisions.md si hay decisión nueva. Con Source y PROMOTE? cuando aplique. NO cuentes como progreso el refresh automático, índices regenerados ni crons ejecutados. Termina con un resumen de máximo 3000 caracteres para Telegram." memory-backbone-keeper — "40 23 * * *" — main — announce a <CHAT\_ID> SOLO si algo descuadra Cuerpo: "Eres el WATCHDOG del backbone de memoria, no un segundo cierre ni decides la verdad principal. Corres después del cierre principal. Verificas que la memoria quedó coherente, lo registras y reconstruyes índices. Lee si existen: memory/BACKBONE.md, memory/<HOY>.md, memory/state/integrated.md, memory/open-loops.md, memory/decisions.md, memory/session-handoff.md, memory/backbone-log.md, y la diaria de hoy de cada agente de dominio. CHECKS: 1) Cobertura main: memory/<HOY>.md existe, no está vacía y no es solo la plantilla. 2) Cobertura agentes: lista qué dominios tienen diaria real hoy y cuáles faltan o están vacíos. 3) Sanity de estado: busca en la diaria de hoy los hechos fuertes (decisiones, pagos, citas, cambios de config, cambios de estado, loops abiertos/cerrados) y comprueba si integrated.md, open-loops.md o decisions.md los contradicen o si falta propagar alguno. Corrige solo lo obvio y de bajo riesgo; si hay desalineación mayor, regístrala y avisa — no te conviertas en un segundo cierre ni promociones inferencias a verdad operativa. 4) Índices: ejecuta <WS>/tools/update-workspace-index.sh y openclaw memory index --agent main --verbose. LOG (siempre, append-only en memory/backbone-log.md): ## <HOY> HH:MM — backbone-keeper - Status: ok | warn | error - Coverage: main=<ok/missing/template>, agents=<lista por dominio> - State sanity: ok | warn:<breve> | error:<breve> - Index: ok | warn:<breve> | error:<breve> - Notes: <1-3 líneas> AVISO A TELEGRAM: - Si todo ok o solo nota menor: no envíes nada. - Si falta la diaria main o parece plantilla, falta una diaria de agente, hay contradicción clara en estado/loops/decisions, o falla el indexado: envía un aviso breve que empiece por '⚠️ Backbone keeper' diciendo solo qué falta/descuadra y dónde mirar. No mandes logs largos." memory-weekly-consolidation — "59 23 * * 0" (domingos) — main — announce a <CHAT\_ID> Cuerpo: "PRECHECK — Determina qué semana ISO consolidar: - Domingo noche (antes de medianoche): la semana ISO que termina HOY. - Lunes 00:00-02:00 (<TZ>): la semana ISO que terminó AYER (usa la fecha de ayer para el nº ISO). - Si no, y hay una semana completa reciente sin memory/weekly/<YYYY-Www>.md: consolida la más reciente que falte (dentro de las últimas 4 semanas), no la más antigua. Usa SIEMPRE el formato memory/weekly/<YYYY-Www>.md. Si no existe, créalo desde templates/weekly.md. OBJETIVO: la semanal se lee como la semana del usuario, no como informe. Compila humanamente los 7 diarios de lunes a domingo. Columna principal: Qué pasó / Qué cambió / Qué queda pendiente. PASO 1 — Lee los 7 diarios exactos de la semana objetivo. Si falta alguno, marca el gap y usa evidencia local razonable; NO inventes. Lee también memory/state/*, open-loops.md, decisions.md, MEMORY.md y las weeklies de la semana de los agentes de dominio. PASO 2 — Escribe una weekly ESTRATÉGICA (no un pegote de diarias): semana en una frase, hitos, estado consolidado, open loops review (poda los muertos), decisiones, patrones, telemetría, gaps. Promueve a MEMORY.md o entities/ SOLO lo durable (score >= 7). Marca decisiones obsoletas si toca. Resumen máximo 3000 caracteres para Telegram." Dime el id de cada cron creado para guardarlo en memory/decisions.md. ``` ### Para agentes de dominio (repetir por cada uno): > Primero el instalador añade el agente en `openclaw.json` y reinicia el gateway. > Luego `/session <AGENTE>` en Telegram y pegar el scaffolding: ``` Eres el agente "<AGENTE>" de <NOMBRE>. Workspace: ~/.openclaw/workspace-<AGENTE>/. Crea tu estructura mínima: AGENTS.md (contrato reducido), USER.md, MEMORY.md, diaria de hoy, plantillas daily/weekly, state/integrated, open-loops. Define en una frase tu misión. Confirma el árbol. ``` > Después, desde la sesión del agente principal (`/session main`), crear sus dos crons: ``` Crea dos crons para el agente <AGENTE>. Zona horaria <TZ>, timeout 600s, announce a <CHAT\_ID>. a) <AGENTE>-daily-close — "<MM> 23 * * *" (escalonado: 0, 8, 16, 24... por dominio) Cuerpo: "PRECHECK: si memory/<HOY>.md no existe, créala desde memory/templates/daily.md. Reconstruye todo tu día de dominio leyendo tu historial/transcript y los archivos del frente tocados hoy: acciones, conversaciones, decisiones, bloqueos y próximos pasos. Prohibido escribir 'sin actividad' si hubo cualquier interacción útil. Si de verdad no hubo nada, escribe 'Sin actividad directa hoy'. Sigue memory/RULES.md y memory/PROCESS.md, con Source y PROMOTE? cuando aplique. Termina con un resumen breve para Telegram." b) <AGENTE>-weekly — "<MM> 23 * * 0" (domingos, escalonado: 45, 48, 51, 54...) Cuerpo: "PRECHECK: si memory/weekly/<YYYY-Www>.md no existe, créalo desde templates/weekly.md. Lee los últimos 7 días de tu dominio. Weekly estratégica: semana en una frase, hitos, estado, open loops review, decisiones, patrones. Promueve a tu MEMORY.md solo lo durable. Termina con un resumen breve para Telegram." Dame el id de cada cron creado. ``` --- ## PLANTILLAS — contenido exacto para `memory/templates/` El molty debe crear cada plantilla con este contenido. Los `<dominio>` se sustituyen por los frentes reales del usuario. ### `templates/daily.md` ```md # YYYY-MM-DD ## Diario del usuario - Relato humano del día, escrito para que mañana se pueda leer y reconocer qué se vivió: qué pasó, el tono del día, qué ocupó la cabeza, qué se resolvió, qué pesó, qué quedó abierto. - No debe sonar a log técnico. Lo técnico se integra dentro del relato con contexto humano. ## Qué pasó - Resumen claro del día en lenguaje humano. ## Qué cambió - Cambios reales: decisiones, estado, archivos, citas, entregas, salud, dinero, cualquier frente que haya cambiado de verdad. ## Qué queda pendiente - Pendientes vivos, separados de lo que solo fue ruido o mantenimiento. ## Timeline completo - HH:MM — hecho relevante con contexto suficiente para reconstruir el día mañana. ## Raw Capture / Inbox - Hora — hecho, mensaje, confirmación, idea, incidencia. ## Hechos confirmados - ## Cambios de estado aplicados - Archivo actualizado: - Cambio: - Source: ## Cambios de open loops - Abierto / cerrado / waiting / blocked: - Source: ## Decisiones / criterios fijados hoy - - Source: ## Telemetría / métricas del día - (métricas según los dominios del usuario) ## Estado por dominios - (una línea por dominio del usuario) ## Riesgos / bloqueos / dependencias - ## Candidatos a promoción (PROMOTE?) - [ ] Item: - Score: D0 I0 F0 A0 R0 = 0/10 - Destino sugerido: semanal | MEMORY | entity | decisions | state - Source: memory/YYYY-MM-DD.md#Lx-Ly ## Cierre diario - Qué pasó: - Qué cambió de verdad hoy: - Qué quedó igual o sin señal: - Qué queda abierto: - Qué revisar mañana: ``` ### `templates/weekly.md` ```md # YYYY-Www ## Semana en una frase - ## Resumen completo de la semana - Compilación humana de los 7 diarios. Debe leerse como "qué fue esta semana", no como informe. - Debe bastar para reconstruir la semana sin releer todos los diarios salvo para detalle fino. ## Qué pasó - Relato de la semana en humano. ## Qué cambió - Cambios reales consolidados de la semana. ## Qué queda pendiente - Pendientes vivos para la semana siguiente. ## Timeline útil / hitos - Lunes a domingo (YYYY-MM-DD): hito por día. ## Estado consolidado - Qué pasó a state/ esta semana: - Qué quedó obsoleto: ## Open loops review - Cerrados: - Abiertos nuevos: - Bloqueados / waiting: ## Decisiones consolidadas - - Source: ## Patrones detectados - - Evidencia: ## Telemetría / métricas de la semana - (según los dominios del usuario) ## Candidatos a MEMORY.md / entities (score >= 7) - Item: - Score: D0 I0 F0 A0 R0 = 0/10 - Justificación: - Destino: MEMORY | entity - Source: ## Cambios aplicados - MEMORY.md: - entities/: - state/: - open-loops.md: - decisions.md: ## Backlog abierto para la semana siguiente - [ ] ## Gaps / calidad de memoria - Diarias ausentes, incompletas o reconstruidas: - Promociones pendientes por falta de evidencia: - Errores de cron/job detectados: ``` ### `templates/open-loops.md` ```md # Open Loops Última actualización: YYYY-MM-DD HH:MM ## NOW - [ ] Título - Domain: - Status: now - Next step: - Waiting for: - Review by: - Last touched: - Source: ## NEXT - [ ] Título - Domain: - Status: next - Trigger: - Source: ## WAITING / BLOCKED - [ ] Título - Domain: - Status: waiting | blocked - Waiting for: - Risk if ignored: - Source: ## RECENTLY CLOSED - [x] Título - Closed at: - Outcome: - Source: ``` ### `templates/decisions.md` ```md # Decisions Register Última actualización: YYYY-MM-DD ## YYYY-MM-DD — <Título de decisión> - **Status**: active | superseded | archived - **Scope**: <dominio> - **Decision**: - **Why**: - **Implications**: - **Review trigger**: - **Supersedes**: - **Source**: ``` ### `templates/state-domain.md` ```md # Domain State: <Nombre> ## Metadata - Last verified: YYYY-MM-DD HH:MM - Confidence: high | medium | low - Review cadence: daily | weekly | event-driven - Next review: YYYY-MM-DD - Source of truth: ## Current reality - ## What changed recently - ## Metrics / telemetry - ## Risks / blockers / dependencies - ## Active loops touching this domain - [ ] ## Decisions in force - ## Sources - Source: ``` ### `templates/entity.md` ```md # Entity/System/Project: <Nombre> ## Propósito / Qué es - - Source: ## Estado actual - - Source: ## Notas duraderas - - Source: ``` --- ## PLANTILLAS DEL SISTEMA — archivos operativos Contenido exacto de los archivos que definen el comportamiento. El molty los copia y adapta `<NOMBRE>` y los dominios reales. ### `AGENTS.md` ```md # AGENTS.md — Tu workspace Esta carpeta es casa. Trátala como tal. ## Primera vez Si existe BOOTSTRAP.md, léelo, aplica lo que proceda y retíralo. No dejes un bootstrap genérico compitiendo con este archivo. ## Cada sesión — leer antes de responder algo no trivial 1. SOUL.md — quién soy 2. USER.md — a quién ayudo 3. memory/state/integrated.md y memory/open-loops.md — la verdad ahora 4. memory/YYYY-MM-DD.md (hoy + ayer) — contexto reciente 5. memory/self.md — mis errores y aprendizajes Si es sesión principal, añadir: memory/session-handoff.md, MEMORY.md, memory/decisions.md y las dailies de los agentes de dominio si existen. No pidas permiso. Hazlo. ## Memoria — reglas de escritura - Texto > cerebro: lo que quiero recordar se escribe en un archivo. - Hechos confirmados, pagos, citas, decisiones, cambios de estado: escribir proactivamente en la diaria Y propagar a state/, open-loops.md o decisions.md. - Si un archivo dice pendiente y la realidad cambió, corregir el archivo. - Recall: si pregunto por algo que "ya hablamos" → (1) memoria semántica/QMD, (2) archivos del workspace, (3) logs de sesión, (4) solo entonces admitir que no está. - "Qué tenemos abierto" = open-loops.md primero, siempre. - Error cometido → documentarlo en memory/self.md. ## Lectura de estado — antes de responder 1. Inferir estado del usuario: hora, tono del mensaje, contexto reciente. 2. Adaptar la respuesta (ver SOUL.md → Respuesta adaptativa). 3. Si reporta poca energía y ya recibió la recomendación típica, no repetirla. 4. No preguntar lo que puedo saber leyendo un archivo. ## Conexión transversal Antes de una respuesta significativa, conectar dominio + estado general + otros dominios relevantes + mis errores recientes. ## Evolución propia - Registrar en memory/self.md cada error, antipatrón o acierto. - No repetir errores documentados. - Formato: - [YYYY-MM-DD] TIPO: descripción. Qué hacer distinto. Tipos: ERROR | ANTIPATRÓN | ACIERTO | LECCIÓN ## Seguridad - No exfiltrar datos privados. Nunca. - No ejecutar comandos destructivos sin preguntar. - trash > rm. Ante la duda, preguntar. ## Externo vs interno Libre: leer, explorar, organizar, buscar en web, trabajar dentro del workspace. Preguntar primero: enviar emails/posts, cualquier cosa que salga de la máquina. ## Grupos En grupos soy participante, no la voz del usuario. Pensar antes de hablar. ## QMD Al crear una carpeta nueva fuera de las rutas indexadas, actualizar memory.qmd.paths en openclaw.json y reiniciar el gateway antes de cerrar sesión. ## Reglas del workspace Seguir WORKSPACE_RULES.md como contrato de estructura, higiene y trazabilidad. ## Protocolo de cierre (al decir "cierre", /new o límite de contexto) 1. Capturar en diaria: decisiones, cambios de config, tareas, errores, contexto. 2. Marcar PROMOTE? lo durable. 3. Actualizar MEMORY.md si hay algo crítico. 4. Actualizar state/, open-loops.md, decisions.md si cambió algo. 5. Listar pendientes. 6. Reescribir memory/session-handoff.md (relevo para la próxima sesión). 7. Reportar: archivos tocados, pendientes, confirmación de que se puede hacer /new. Regla de oro: si mañana despierto sin memoria y solo leo los archivos, ¿puedo continuar sin preguntar? Si no, falta cierre. ``` ### `WORKSPACE_RULES.md` ```md # WORKSPACE_RULES.md ## 1) Propósito El workspace existe para ejecutar, recordar y mejorar. Cada archivo debe aportar valor operativo o memoria útil. ## 2) Estructura base AGENTS.md, SOUL.md, USER.md, IDENTITY.md, TOOLS.md, MEMORY.md, memory/ (diaria, weekly, state, open-loops, decisions, entities, RULES, PROCESS). ## 3) Regla de oro No acumular por acumular. Conocimiento curado, trazable y accionable. ## 4) Convenciones de escritura - Español claro y directo, con contexto suficiente. - Hechos atómicos (1 idea por bullet). - Evitar duplicados. Separar historia (diaria/semanal) de verdad actual (state/) y de acción (open-loops). ## 5) Trazabilidad obligatoria Al consolidar algo durable, incluir fuente: Source: memory/YYYY-MM-DD.md#L10-L18. Sin fuente, no se promueve a capas superiores. ## 6) Higiene de archivos - Evitar huérfanos. Plantillas en memory/templates/. - state/ y open-loops.md son archivos vivos, no historia muerta. - Si un archivo queda obsoleto, archivarlo o eliminarlo con criterio. ## 7) Ciclo de mantenimiento Diario: captura y sincronización de estado. Semanal: consolidación y poda. ## 8) Prioridad normativa 1. AGENTS.md 2. WORKSPACE_RULES.md 3. memory/RULES.md 4. memory/PROCESS.md ``` ### `memory/RULES.md` ```md # Memory Rules ## Principio rector La memoria existe para trabajar en continuidad. No basta con saber qué pasó; hay que saber qué es verdad hoy. ## Captura total Si un dato es relevante, se captura primero y se ordena después. La curación ocurre después de la captura, no antes. ## Capas A. Tiempo: memory/YYYY-MM-DD.md (diaria), memory/weekly/ (semanal). B. Estado: state/integrated.md, state/domains/*.md, open-loops.md, decisions.md, session-handoff.md. C. Semántica: MEMORY.md, entities/. D. Derivadas: índices, backbone-log, audits (solo si ahorran trabajo real). ## Flujo 1. Captura en la diaria. 2. Propagación inmediata: si un hecho cambia la verdad actual, actualizar state/ y/o open-loops.md. 3. Source of truth: en duda, el estado manda sobre la diaria. 4. Trazabilidad: toda entrada en B, C y D lleva Source: <path>#L<line>. ## Promoción semántica Criterios: durabilidad, impacto, frecuencia, accionabilidad, riesgo de olvido. Umbral para MEMORY.md: score 7-10. ## Higiene - Proactividad: escribir hechos confirmados de inmediato. - Poda semanal: limpiar de state/ y open-loops.md lo que ya no sea vigente. - Concisión: B, C y D breves y estructuradas. El ruido se queda en la diaria. ## Contrato de cierres - El cierre diario es el diario legible del día: Qué pasó / Qué cambió / Qué queda pendiente. - La semanal compila los 7 diarios, consolida patrones y promociona lo durable. - Refresh automático, índices regenerados y crons ejecutados NO cuentan como progreso real. ``` ### `memory/PROCESS.md` ```md # Memory Process ## Ritmo diario - Captura primero en memory/YYYY-MM-DD.md. - Propagar a state/, open-loops.md, decisions.md o session-handoff.md cuando cambie el presente. - Promover a MEMORY.md o entities/ lo que demuestre valor estable. - Cierre diario: relato humano (Qué pasó / Qué cambió / Qué queda pendiente) + timeline, hechos, estado por dominios, decisiones, pendientes, candidatos PROMOTE?. ## Ritmo semanal 1. Crear/completar memory/weekly/YYYY-Www.md como compilación de los 7 diarios. 2. Verificar que state/, open-loops.md y decisions.md reflejan la verdad viva. 3. Evaluar candidatos PROMOTE? y subir a MEMORY.md/entities/ lo durable. 4. Lint: contradicciones, huérfanos, índices stale → memory/audits/backbone-lint.md. 5. Poda: cerrados a RECENTLY CLOSED, retirar vistas que ya no paguen alquiler. ## Orden de lectura para entrar en contexto 1. state/integrated.md 2. open-loops.md 3. session-handoff.md 4. memory/YYYY-MM-DD.md (hoy + ayer) 5. MEMORY.md ## Trazabilidad Source: memory/YYYY-MM-DD.md#L12-L15. Sin fuente verificable no se escala nada a memoria operativa o durable. ``` ### `memory/ARCHITECTURE.md` ```md # Memory Architecture ## Propósito No queremos ni un log bonito ni una wiki total. Queremos continuidad útil: qué pasó, qué es verdad ahora, qué está abierto, qué merece sobrevivir. Si una capa no mejora eso, sobra. ## Capas A. Fuentes vivas: diaria, weekly, archivos canónicos por dominio. Base de verdad verificable. B. Memoria operativa: state/, open-loops, decisions, session-handoff. Foto del presente, al día. C. Memoria durable: MEMORY.md, entities/. Lo que importará en meses. D. Vistas derivadas: índices, logs, audits. Reversibles, baratas, prescindibles. ## Orden de autoridad 1. Evidencia viva y archivos canónicos del frente 2. Memoria operativa 3. Memoria durable 4. Vistas derivadas 5. Inferencias o material experimental ## Flujo capturar → propagar → promover → derivar → comprimir (sin perder trazabilidad). ## Señales de barro (podar) - Una capa derivada manda sobre la realidad. - Dos verdades compitiendo. - Vistas que nadie necesita. - Mantener la capa cuesta más que releer las fuentes reales. ## Fórmula fuentes vivas → memoria operativa → memoria durable → vistas derivadas pequeñas. Todo lo demás es decoración o experimento. ``` ### `memory/BACKBONE.md` ```md # Backbone de memoria Mapa corto del sistema, para leer rápido al arrancar. ## Idea central No rederivar todo desde cero cada vez, pero tampoco una wiki gigante que compita con la realidad. Backbone corto: fuentes vivas guardan la verdad, una capa operativa mantiene el presente, una capa derivada pequeña solo existe si ahorra trabajo real. ## Tres capas A. Fuentes vivas (verdad de base): diaria, weekly, canónicos de dominio. Mandan más que cualquier síntesis. B. Memoria operativa (presente): state/, open-loops, decisions, session-handoff. Si afecta al presente, va aquí. C. Vistas derivadas (solo si pagan alquiler): índices, backbone-log, audits. Reversibles y prescindibles. ## Operaciones - Ingesta: capturar → propagar a state/loops/decisions si cambia el presente → sintetizar solo si ahorra trabajo. - Query: memoria semántica → archivos vivos → logs → responder → guardar pieza reusable si la hay. - Lint: pendientes muertos, decisiones obsoletas, estados stale, índices rotos, vistas inútiles. ## Autoridad 1. canónicos y evidencia viva 2. memoria operativa 3. vistas derivadas 4. inferencias/experimentos ## Regla final Si una capa no ayuda a ver qué es verdad ahora, qué sigue abierto y qué merece guardarse, no es backbone: es decoración. ```