IBM Bob

En un banco, IBM Bob compite con Copilot, no con kbspec. kbspec gobierna el trabajo de Bob igual que el de Copilot y Claude Code: el mismo ciclo, las mismas skills, el mismo juez antes de cada herramienta y el consumo en el expediente.

kb init-repo --ia bob

Qué deja en el repositorio

Archivo	Para qué
`.bob/skills/`	Las mismas skills de kbspec. Bob las activa solo, por la descripción.
`.bob/commands/`	`/kb` (la sesión) y los comandos de sesión: `/kb-iniciar`, `/kb-abrir`, `/kb-estado`, `/kb-cerrar`… No va `/kb-modelo`: en Bob el modelo lo enruta Bob.
`.bob/rules/00-kbspec.md`	Una regla corta que Bob carga en cada conversación y que sobrevive a su `/init`.
`.bob/mcp.json`	El servidor MCP de kbspec, el mismo que `.mcp.json`.
`.bob/settings.json`	Los ganchos: la compuerta (`PreToolUse`, sin matcher), el contexto al arrancar (`SessionStart`) y el cierre de fase (`Stop`).
`.bob/politica-kbspec/`	La compuerta como política de TI (`EnforcedHooks`), lista para repartir.
`AGENTS.md`	Las reglas del proceso. Bob lo carga solo.

Nada de eso se commitea: queda en .git/info/exclude, como el resto de lo que genera kbspec. Si el equipo ya tiene un .bob/settings.json con sus propios ganchos, se fusiona: los del equipo quedan intactos, los de kbspec se reemplazan y no se duplican, y un archivo que no es JSON válido no se toca —se dice qué agregar a mano—.

Con --ia todos, Bob se prepara solo donde se usa: si el repositorio ya tiene .bob/ o la máquina tiene ~/.bob/ (KB_BOB=1 o KB_BOB=0 manda). kb update mantiene todo al día y kb check lo revisa.

La compuerta

Es el mismo juez que en Copilot y Claude Code (kb hook pretool). Frena los comandos que corre una persona (kb ciclo aprobar, kb pr aprobado…), los secretos antes de que el archivo exista, las rutas vedadas, el código en una fase cuyo producto es el expediente y el código en la rama equivocada. Las herramientas de Bob que escriben —write_file, apply_diff, insert_content, search_and_replace— cuentan como escritura, y execute_command como terminal.

Lo que cambia es el protocolo: Bob no lee la respuesta del gancho. Ignora su salida, y lo único que frena la herramienta es salir con código 2. Con Bob, kbspec niega así, con el motivo por stderr —que va al registro de Bob— y en .kb/ultimo-bloqueo.txt, porque el modelo no ve ese registro: la regla de .bob/rules/ le dice que lo lea.

El juez reconoce a Bob por la forma de lo que recibe (event, tool, input); el --agente bob del comando lo confirma. No es una bandera nueva a propósito: con una versión anterior de kb en la máquina, una bandera desconocida haría salir con código 2 —que para Bob es bloquear— y frenaría todas las herramientas.

Para TI: la compuerta que nadie puede apagar

En .bob/settings.json el desarrollador puede apagar los ganchos. Con la política EnforcedHooks los impone TI: corren antes que los del usuario y nadie los puede apagar. Y en bob run, donde todas las herramientas están preaprobadas, el gancho es la única compuerta.

.bob/politica-kbspec/ trae todo lo necesario:

Archivo	Para qué
`EnforcedHooks.txt`	El valor: un texto con JSON adentro, en una línea.
`policy.json`	Para Linux: `/etc/bob/policy.json` (dueño root, permisos 644).
`EnforcedHooks.reg`	Para probar en una máquina Windows: `Software\Policies\IBM\Bob`.
`LEEME.md`	Cómo repartirlo por MDM (`com.ibm.bob`), GPO o `/etc/bob/policy.json`.

Impone la compuerta y el cierre de fase. El contexto al arrancar queda en el repositorio: impuesto, le llegaría dos veces al modelo.

Bob ignora en silencio un valor que no sea JSON válido: la política queda puesta y la compuerta, apagada. Por eso el valor lo genera kbspec; no se escribe a mano.

Lo que hay que saber:

kb tiene que estar en el PATH de cada máquina. Si falta, el gancho falla y Bob lo toma como un error que no bloquea.
Según la documentación de IBM, las políticas rigen en Bob IDE. En Bob Shell (bob run, pipelines), los ganchos que siempre corren son los globales (~/.bob/settings/settings.json); los del repositorio, solo en una carpeta de confianza: bob run --trust.
Con la política y el repositorio preparado, la compuerta corre dos veces por herramienta. kbspec la cuenta una sola vez.

El consumo

Bob no deja una base que kbspec pueda leer por su cuenta: el costo de una corrida lo dice su propia salida.

bob run --format json "Implementá la T-02" | kb tokens --bob -
kb tokens --bob salida.json

Se leen --format json y --format stream-json, de un archivo o de stdin. Entran al consumo del expediente los tokens de entrada, salida y caché, session_costs en Bobcoins —la unidad en que Bob mide y cobra—, la tarea (task_id), las herramientas y la fase. El modelo queda «enrutado por IBM Bob»: en Bob SaaS lo elige Bob y no viene en la salida, así que kbspec no inventa uno. La misma corrida registrada dos veces no se cuenta dos veces, y la respuesta de Bob nunca se guarda.

kb tokens muestra los Bobcoins aparte. Sus tokens están en las tablas, pero no se costean por tarifa: no hay tarifa de un modelo que no se conoce.

Ojo con el `/init` de Bob

El /init de Bob reescribe AGENTS.md, y como está fuera de versión, git no lo muestra. El agente pierde las reglas del proceso sin que nadie se entere. kb check lo detecta («IBM Bob gobernado por kbspec»). Desde 3.186.1, kb init-repo --ia bob —o kb update— ya no pisa el AGENTS.md nuevo: lo trata como del equipo y deja las reglas de kbspec en .claude/rules/00-kbspec.md. Mientras tanto, la regla de .bob/rules/ le dice al modelo qué pasó y dónde leerlas.