Apéndice A — Glosario

Propósito

Este apéndice es el glosario canónico. Cada término usado en la documentación del lab está definido aquí. Las definiciones son precisas; cuando un término se usa de una forma específica en una página específica, esa página es la referencia autoritativa.

El glosario es alfabético. Las definiciones de los placeholders están al final.

A

Adapter. Un módulo que traduce entre una interfaz genérica y un formato específico del provider. Los adaptadores aparecen en el research framework y en el tooling de media. Ver External Providers → Adapter contract.

ADR (Architecture Decision Record). Un documento corto que captura una decisión significativa, el contexto en el que se tomó y las consecuencias. El lab tiene 13 ADRs. Ver Decisiones de arquitectura.

Agent. Un rol especializado con sus propias herramientas y su propio lifecycle. El lab tiene 5 agentes: Coordinator, Coding Assistant, Research Worker, Media Agent, Web Agent. Ver Agents and Roles.

API key. Una credencial usada para autenticarse con un provider externo. El lab almacena las API keys en ficheros de configuración con permisos solo del owner.

Artifact. Un fichero tipado producido por el research framework. Los artefactos los validan esquemas Pydantic. Ver Artifacts.

Audit. Una revisión sistemática del estado del lab. La salida es un report. Las auditorías se realizan semanal, mensual, trimestral y ad-hoc. Ver Modelo de auditoría.

Audit trail. El registro completo de la actividad del lab. El trail se compone del request journal, los mission states, los audit reports y los cambios de configuración.

B

Backend. Un target de reproducción para el Media Agent. El lab soporta tres backends: Chromecast, VLC y direct. Ver Media Playback.

Backup. Una copia de los datos del lab para disaster recovery. Los backups se hacen diarios. El destino es elección del usuario.

Browser automation. La capacidad de manejar un browser a través de la herramienta browser de OpenClaw. La capacidad se expone a través del Web Agent.

C

Candidate. Un match potencial para una research query. Los candidatos los produce la fase F1 del research framework. Ver Mission DAG → F1.

Cast protocol. El protocolo de Google para controlar dispositivos Chromecast. El lab usa el protocolo a través de la herramienta chromecast.

CDP (Chrome DevTools Protocol). El protocolo usado para controlar Chromium. El lab usa el protocolo en el puerto 18800. Ver Web Agent.

Checkpoint. Un registro de estado persistente de una misión. Los checkpoints se escriben tras cada fase y tras cada paso de herramienta de dominio. Ver Mission Lifecycle → Checkpointing.

Chromecast. Un display Cast-capable en la LAN. El Media Agent puede descubrir y controlar dispositivos Chromecast.

Coding Assistant. El brazo de implementación del lab. El Assistant delega la escritura de código a un sub-agent sandboxed. Ver Coding Assistant.

Coding sub-agent. La herramienta CLI externa (Codex, en el caso del lab) a la que delega el Coding Assistant. El sub-agent está sandboxed.

Configuration. Los settings que controlan el comportamiento del lab. La configuración está en ficheros, no en código. Ver System Architecture → Configuration files.

Context. La información disponible para un agente en un momento dado. El context incluye el session state, la memoria y las instrucciones del skill.

Coordinator. El main control agent. El punto de contacto primario del usuario. Ver Coordinator.

Coverage. La fracción del código que ejercitan los tests. El target del lab es 70% mínimo por proyecto.

CWD (current working directory). El directorio en el que está actualmente un proceso. El CWD del Coordinator es típicamente el workspace root.

D

DAG (Directed Acyclic Graph). Una estructura de datos que representa las dependencias entre tareas. Las fases del research framework se organizan en un DAG. Ver Mission DAG.

Daily log. Un fichero markdown (memory/YYYY-MM-DD.md) que registra la actividad del día. Los daily logs son append-only. Ver Memory and Context.

Direct player. El backend de reproducción más simple del Media Agent. Lanza el reproductor de media por defecto del sistema. Se usa raramente.

Dispatch. El acto de rutear una request a un agente. El Coordinator es el único dispatcher.

Domain tool. Una herramienta del research framework que realiza una task de dominio específica (hotel research, review research, etc.). El lab tiene 8 domain tools.

E

End-to-end test. Un test que ejercita el flow completo de input a output. El research framework del lab tiene end-to-end tests para cada domain tool.

Environment variable. Un valor de configuración pasado a un proceso a través del OS. El lab usa environment variables para configuración sensible (secretos, rutas).

Executor. El componente que corre una fase o una herramienta. El executor del orquestador es el PhaseRunner.

External provider. Un servicio fuera del lab con el que habla el lab (provider de modelo, provider de search, servicio de streaming).

F

F0, F1, F2, F4, F6. Fases del research framework. F0 inicializa la misión, F1 junta candidatos, F2 agrega reseñas, F4 calcula precios, F6 escribe el informe.

Failure catalog. La lista de modos de fallo conocidos y sus procedimientos de recuperación. Ver Failure Catalog.

Framework. Un orquestador de dominio específico. El lab tiene dos: el Research Framework y el Coding Sub-agent. Ver Framework.

G

Gateway. Un proceso de larga duración que acepta requests y las dispatcha a los agentes. El lab tiene dos gateways: el Coordinator (puerto 18789) y el Scout (puerto 18790).

Git. El sistema de control de versiones. El Coding Assistant usa Git a través del shell del usuario, pero nunca hace commit, push ni pull.

H

Health check. Una verificación de que un componente está funcionando correctamente. Los health checks se dividen en tres categorías: liveness, correctness, performance. Ver Health Checks.

Heartbeat. Un probe periódico que verifica que los gateways y las misiones en curso están healthy. El intervalo por defecto es 30 minutos.

HTTP API. La interfaz expuesta por los gateways. La API del Coordinator está en el puerto 18789; la del Scout en el 18790.

I

Incident. Un evento inesperado que requiere intervención. Los incidentes se registran en documentos post-mortem bajo security/incidents/.

Intent. El objetivo del usuario, según lo resuelve el Coordinator a partir de la request en lenguaje natural. El intent se mapea a uno o más agentes.

Invocation. Una única llamada a una herramienta o un sub-agent. Las invocaciones del Coding Assistant se trackean en la telemetry.

J

Journal. El log append-only de llamadas externas. El journal es la base del audit trail del lab para uso de APIs externas. Ver Request Journal.

K

Keyword. Una palabra o frase que el Coordinator usa para resolver el intent del usuario. Los keywords se configuran por agente.

L

LaunchAgent (macOS) / systemd unit (Linux). El supervisor que mantiene un proceso corriendo. El Coordinator y el Scout están supervisados por launchd (macOS) o systemd (Linux).

Layer. Un nivel en la arquitectura de 8 capas del lab. Cada layer tiene una única responsabilidad. Ver Framework.

Lifespan. La duración que corre un componente. Los gateways son long-running; los procesos de herramientas son per-call; el sub-agent es per-invocation.

Liveness probe. Un check simple que verifica que un componente está up. El lab tiene liveness probes para cada componente.

Logger. El componente que escribe mensajes de log. El lab usa logging estructurado (JSON Lines) para los logs de runtime.

M

Main session. La sesión primaria del usuario. El fichero MEMORY.md se carga solo en la main session. Ver Memory and Context.

Media Agent. El especialista en entretenimiento del lab. El agent maneja búsqueda y reproducción de media. Ver Media Agent.

Media Lab Server. El servidor HTTP local que expone generación de imágenes y música. El server corre en 127.0.0.1:8765. Ver Media Lab Server.

Memory. El conocimiento persistente del lab. La memoria se organiza en tres capas: long-term (MEMORY.md), daily logs y session state. Ver Memory and Context.

Mission. Una task de research. Una misión se identifica por un mission_id y se trackea en phase.json. Ver Mission Lifecycle.

Mission DAG. El directed acyclic graph de fases. El DAG define las dependencias y los parallel groups. Ver Mission DAG.

M3. El modelo actual. Reemplazó a M2.7 en junio 2026. El lab usa M3 como default y M2.7-highspeed como variante rápida.

N

NL (natural language). El idioma de input del usuario. El Coordinator parsea lenguaje natural y rutea a los agentes.

Non-goal. Una declaración explícita de lo que un agente NO hace. Los non-goals son los boundaries que evitan que un agente derive fuera de su rol. Ver Agents and Roles.

O

Orchestrator. El componente que conduce un phase DAG. El orquestador del research framework está en scout/orchestrator/.

Output directory. El directorio donde el Media Lab Server escribe sus outputs. Ubicación por defecto: ~/.openclaw/media/outbound/.

P

P3. La fase opcional del research framework que usa el adaptador Perplexity para síntesis. P3 es opt-in porque cuesta créditos de API.

Parallel group. Un conjunto de fases que pueden correr concurrentemente. F2, F4 y Y1 están en el parallel group 1.

ParsedQuery. La representación estructurada de una research query. Producido por F0. Ver Artifacts → task.json.

Phase. Un único paso en una misión de research. El lab tiene 8 fases: F0, F1, F2, F4, P3, Y1, Y2, F6.

Phase status. El status de lifecycle de una fase. El lab tiene 9 phase statuses. Ver Mission DAG → Failure Status.

Playwright. La librería que maneja el browser. El lab usa Playwright a través de la herramienta browser de OpenClaw.

Pool. El token pool para APIs de pago. El pool se configura en token_pool_config.json y escribe su estado a token_pool_state.json. Ver External Providers → Token pool.

Post-mortem. Un documento que registra un incidente. El post-mortem se almacena bajo security/incidents/.

Progressive prompt. La técnica de dividir una task grande en prompts más pequeños. El Coding Assistant usa progressive prompts para evitar que el OS mate al sub-agent.

Q

Quorum. El número mínimo de adaptadores que deben succeed para que una fase se considere succeeded_partial. El default es "al menos uno".

Quota. El rate limit que impone un provider externo. El lab trackea la quota y espera al reset cuando se agota.

R

Rate limit. El número máximo de requests que permite un provider por unidad de tiempo. El lab respeta los rate limits a través del cap por minuto del adaptador.

Report. La salida final de una misión de research. El report es un fichero markdown que agrega todos los artefactos.

Request journal. El log append-only de llamadas externas. Ver Request Journal.

Research Framework. El orquestador de research del lab. Ver Research Framework.

Research Worker. El especialista en research del lab. Ver Research Worker.

Resume. El acto de continuar una misión pausada. El orquestador carga el estado desde phase.json y retoma donde lo dejó.

Retry policy. Las reglas para reintentar una operación fallida. El default del lab es 3 intentos con exponential backoff.

Root cause. La causa subyacente de un incidente. El post-mortem identifica la root cause.

Router. El componente del Coordinator que dispatcha las requests a los agentes.

S

Sandbox. Un entorno restringido que limita lo que puede hacer un proceso. El coding sub-agent corre en un sandbox. El sandbox tiene tres niveles: read-only, workspace-write, full.

Scout. El proceso gateway que aloja al Research Worker y al Media Agent. Corre en el puerto 18790.

Session. Una conversación continua entre el usuario y el Coordinator. Las sesiones tienen un timeout y se almacenan en el session store.

Skill. Un fichero markdown (SKILL.md) que describe una capacidad. El Coordinator activa un skill cuando la request matchea las frases disparadoras del skill.

SKILL.md. El fichero que define un skill. Ver Tool Spec.

SLA (Service Level Agreement). Un compromiso sobre la performance del sistema. Los SLAs del lab están documentados en Health Checks.

Snapshot. El accessibility tree de una página web. El Web Agent usa snapshots para acciones.

Source. Una referencia a una URL con metadatos. Las sources las producen los adaptadores y se agregan en artefactos.

State. Los datos que persiste el lab. El state incluye la long-term memory, los daily logs, el session state, los artefactos de skills, los artefactos de research y el audit trail.

State machine. Un modelo del lifecycle de un componente. La misión tiene una state machine; las fases tienen una state machine.

Strategy. El algoritmo que usa el token pool para seleccionar un token. El lab soporta round-robin, weighted-round-robin, least-used y failover.

Sub-agent. El CLI externo de coding al que delega el Coding Assistant. El sub-agent está sandboxed.

Systemd unit. El supervisor de Linux que mantiene un proceso corriendo. El lab usa systemd en Linux y launchd en macOS.

T

Task. El input de una misión de research. Un Task es un modelo Pydantic con un mission_id, un raw_query y una estructura parsed.

Telemetry. Las métricas, logs y traces que produce el lab. Ver Telemetry.

Template. Una estructura de proyecto preconfigurada desde la que se puede copiar un proyecto nuevo. El lab tiene 4 templates: Next.js, CLI Python, research framework, agent skill. Ver Project Templates.

Token. Una credencial para una API de pago. El lab usa un token pool para APIs de pago.

Token pool. El mecanismo que gestiona múltiples API tokens. Ver Token pool.

Tool. Una capacidad tipada y determinista. El lab tiene docenas de herramientas, organizadas por categoría.

Tooling Layer. La capa que envuelve capacidades deterministas. Ver Tooling Layer.

TOOL.md. El fichero que define la especificación de una herramienta. Ver Tool Spec.

Trust boundary. La línea entre código de confianza y código no confiable. El lab tiene múltiples trust boundaries. Ver Principios de seguridad → Trust boundaries.

Trust level. El nivel de sandbox para el coding sub-agent. El default del lab es workspace-write.

TTL (Time to Live). La duración durante la que un valor es válido. El lab usa TTLs para cachés y ficheros rotados.

Typed artifact. Un fichero que valida un esquema. El research framework escribe artefactos tipados.

U

Unit test. Un test que ejercita una única función o módulo. Los proyectos del lab tienen unit tests para cada módulo.

User authorization. La aprobación explícita del usuario para una operación de alto riesgo. El Coordinator surface la request de autorización y espera la respuesta.

V

Validation. El acto de comprobar un valor contra un esquema. El lab valida cada artefacto tipado en lectura y en escritura.

VLC. Un media player que el lab usa como backend de reproducción. VLC se controla a través de su interfaz RC (TCP) o HTTP. Ver Media Playback → VLC.

W

Web Agent. La capacidad de browser automation del lab. El agent maneja un browser basado en Chromium a través de la herramienta browser de OpenClaw. Ver Web Agent.

Workspace. El directorio raíz del lab. El workspace contiene el estado de los agentes, los directorios de proyecto y la configuración.

Y

Y1, Y2. Fases del research framework que manejan YouTube. Y1 busca vídeos; Y2 extrae transcripciones.

Placeholders

La documentación usa placeholders para anonimizar valores reales. Los placeholders son:

Los placeholders se usan en comandos, rutas y configuración. Se reemplazan con valores reales cuando el operator aplica la documentación a su entorno.

Ver también

• Todas las demás páginas de la documentación.