[barbatdev]

Docs only.

• Built-in Pi MCP reads ~/.gentle-shell/agent/mcp.json; pi-mcp-adapter is retired by Gentle AI and must not be installed. Applied on Mac, agent-dev and agent-gentle; brains connected on all three.
• agent-gentle workshop deploy evidence (backup, skills, wrapper, first real gs sync, legacy Pi retired, old-worktree Pi fallback) and what is kept on purpose.
• Open item: gs sync dotfiles step uses a different clone than gs.

[barbatdev]

Fleet review (deepseek)

Lens: evidence + test design. PR solo de documentación (docs/gentle-official-migration.md +34, odd/tasks/agent-gentle-official-home.md +2/-1). Contrasté las afirmaciones contra el código disponible en el host: el lanzador gentle-shell usa join(home.dir, "mcp.json") y advierte cuando settings.json deshabilita el MCP incorporado, así que la ruta ~/.gentle-shell/agent/mcp.json y el mecanismo de MCP incorporado son correctos; la forma gentle-shell --isolated remove <source> coincide con la remediación que emite el propio lanzador; bin/gs:344 define CORTEX_DOTFILES_DIR con default ~/dev/barbatdev/cortex/cortex-dotfiles y saltea el clon con cambios locales (350-358), lo que respalda el ítem "Pendiente" de dotfiles; el anchor #agent-gentle-workshop resuelve desde la heading "## agent-gentle (workshop)" y el link relativo ../odd/tasks/... apunta al archivo real; y ~/.agents/skills sí se lee con cualquier home (el bundle de Pi resuelve userAgentsSkillsDir = getHomeDir()/.agents/skills, con getHomeDir() = HOME || homedir()). Límite de evidencia: en este host Pi es 1.3.0, así que la afirmación "Pi 1.4.0 trae MCP incorporado" quedó correlacionada con el lanzador, no verificada contra Pi 1.4.0. El hallazgo bloqueante es el cp -p del bloque MCP: reemplaza un mcp.json existente aunque el comentario diga lo contrario.

Blocking (1)

• cp -p sobrescribe un mcp.json existente, aunque el comentario afirme lo contrario (docs/gentle-official-migration.md:331): El bloque presenta cp -p ~/.config/mcp/mcp.json ~/.gentle-shell/agent/mcp.json con el comentario "no pisar uno existente", pero cp sin -n reemplaza el destino. Lo verifiqué con un cp -p sobre un archivo existente en un directorio descartable: el contenido del destino quedó reemplazado. La sección no incluye backup previo del archivo de destino, y el home aislado se re-provisiona en cada gs sync (misma doc, línea 268), así que el archivo puede existir antes de ejecutar el procedimiento. Además, L3 del task file registra que el home aislado de agent-gentle ya tenía brains configurados, por lo que la corrida aplicada muy probablemente reemplazó un archivo existente.
  • Failure scenario: En un host cuyo ~/.gentle-shell/agent/mcp.json ya declara work-brain, life-brain y second-brain, se pega el bloque tal cual: cp -p ~/.config/mcp/mcp.json ~/.gentle-shell/agent/mcp.json reemplaza ese archivo por el contenido de ~/.config/mcp/mcp.json. Si la fuente usa otro conjunto o naming de servidores, el host pierde la configuración que funcionaba, no hay backup en la sección, y gentle-shell --isolated mcp list pasa a mostrar el conjunto nuevo o vacío sin que quede rastro de lo anterior.

Suggestion (3)

• El bloque asume que ~/.gentle-shell/agent ya existe (docs/gentle-official-migration.md:331): El procedimiento no indica la precondición de que el home aislado ya esté provisionado. En un host nuevo, cp hacia ~/.gentle-shell/agent/mcp.json falla con "No such file or directory" y el resto del bloque (chmod, mcp list) queda sin sentido. Agregar la precondición (gentle-shell setup o mkdir -p ~/.gentle-shell/agent antes del cp) hace el procedimiento reproducible desde cero.
• Falta el chequeo del filtro -builtin:mcp que deshabilita el MCP incorporado (docs/gentle-official-migration.md:334): La sección promete que, retirado pi-mcp-adapter, los servidores de mcp.json cargan. El lanzador gentle-shell (warnDisabledMCP, líneas 1304-1326 del script instalado) detecta el estado en que settings.json del home aislado incluye -builtin:mcp en extensions y entonces advierte que los servidores de mcp.json no cargan. Es un estado que el propio lanzador considera probable: la nota de verificación debería incluir revisar que extensions no contenga -builtin:mcp (o citar el WARNING del lanzador), porque mcp list con nombres y estado no distingue "servidor configurado pero no cargado" de "servidor ausente".
• T2 figura Done aunque el pull de dotfiles de S7 se salteó (odd/tasks/agent-gentle-official-home.md:21): S7 incluye "pull dotfiles" y el propio PR documenta en "Pendiente" (línea 356 de la doc) que el paso de dotfiles de gs sync se saltea porque el clon en CORTEX_DOTFILES_DIR tiene cambios locales, comportamiento que confirma bin/gs en las líneas 350-358. Marcar T2 como Done 2026-10-31 sin ese caveat hace que el ledger lea un deploy completo cuando una de las acciones nombradas por el criterio no se ejecutó. Conviene anotarlo en la misma línea (por ejemplo Done with open item: dotfiles pull skipped, see Pendiente) para que el estado sea consistente con la evidencia del mismo commit.

Question (2)

• ¿Se confirmó la causa del codegraph en failed en agent-dev? (docs/gentle-official-migration.md:337): El texto dice "pendiente de revisar (probable PATH)": es una hipótesis, no evidencia. Para que la nota sirva como evidencia conviene registrar el output que la confirma (por ejemplo el comando del server resuelto con command -v dentro del entorno del home aislado, o el mensaje exacto de mcp list), o marcarlo explícitamente como causa no verificada.
• El backup de retiro está en $HOME y S7 pide mktemp -d (docs/gentle-official-migration.md:350): S7 del task file (odd/tasks/agent-gentle-official-home.md:15) dice "move retired legacy pieces to a mktemp -d backup (never delete)"; mktemp -d devuelve un path en $TMPDIR, no bajo $HOME. La fila documenta ~/gentle-workshop-retirement.ufAbAo. ¿Se creó con mktemp -d -t gentle-workshop-retirement con TMPDIR apuntando al home, o directamente bajo $HOME? Si fue lo segundo, la fila y S7 deberían alinearse sobre dónde queda el material retirado (y desde cuándo ese path se puede considerar temporal).

Verdict: not ready

[barbatdev]

Fleet review (glmflash)

Lens: adversarial. Docs-only PR extending docs/gentle-official-migration.md with the built-in Pi MCP procedure and the agent-gentle workshop deploy log, plus the T2 status flip in odd/tasks/agent-gentle-official-home.md. The documentation is coherent and honestly records open items (codegraph failed on agent-dev, gs sync dotfiles clone mismatch). One blocking defect: the documented copy command contradicts its own inline comment and is destructive if a target file already exists. Two non-blocking observations: unconfirmed exposure of the cortex-maintainer-delivery skill required by L4 before legacy retirement, and a wording inconsistency between the PR body ("brains connected on all three") and the doc itself (agent-dev codegraph failed).

Blocking (1)

• Documented cp -p overwrites an existing mcp.json, contradicting its own comment (docs/gentle-official-migration.md:331): The procedure documents cp -p ~/.config/mcp/mcp.json ~/.gentle-shell/agent/mcp.json # no pisar uno existente, but plain cp unconditionally replaces the destination when it exists. The inline comment states the opposite intent ("do not clobber an existing one"). Since this doc is the reference procedure applied on multiple machines (Mac, agent-dev, agent-gentle) and may be re-run on hosts where ~/.gentle-shell/agent/mcp.json already exists with a customized or partially applied configuration, following it verbatim silently destroys the existing file (no backup, chmod 600 afterwards hides the loss from a later permission check).
  • Failure scenario: Operator runs the documented four-line procedure on a host where ~/.gentle-shell/agent/mcp.json already exists (for example a re-run of this same procedure, or a host where a brain had its own curated server list). cp -p replaces the existing file with the contents of ~/.config/mcp/mcp.json; the previously configured MCP servers are lost with no warning, while the comment and intent said the existing file must not be clobbered.

Suggestion (1)

• Guard and wording details in the MCP procedure and summary (docs/gentle-official-migration.md:333): Two minor points: (1) line 333 documents gentle-shell --isolated remove npm:pi-mcp-adapter # solo si estaba instalado without a guard or a note on what happens when the package is not installed; if remove errors on a missing package, operators following the procedure verbatim on a clean host hit a failure at that step. A one-line note would prevent that. (2) The PR body states "brains connected on all three", while line ~336 of the doc itself reports agent-dev's codegraph server as failed (pending PATH fix); aligning the body wording or pointing to the doc's caveat would keep the headline claim consistent with the recorded evidence.

Question (1)

• Was cortex-maintainer-delivery exposed to the isolated home before retiring legacy Pi? (docs/gentle-official-migration.md:347): The task log entry L4 in odd/tasks/agent-gentle-official-home.md records that the skill cortex-maintainer-delivery exists only in ~/.pi/agent/skills on agent-gentle and that T2 must expose it to the isolated home BEFORE retiring legacy. The new table documents 12 cortex-* skills copied to ~/.agents/skills and, in the 'Pi legacy' row, the legacy pi binary and symlink moved to the retirement directory. The doc does not state whether cortex-maptainer-delivery is among the 12 copied skills; if it is not, the L4 precondition was violated by the deploy. Please confirm the skill was included (or correct the record).

Verdict: not ready

[barbatdev]

Fleet review (mimo)

Lens: requirements. PR solo de documentación (2 archivos markdown, confirmado con --json files); sin issue enlazado, así que los criterios son los 4 claims del body más los del task file (S7, L4). Los 4 claims del body quedan cubiertos por las secciones nuevas y verifiqué las referencias: el anchor #agent-gentle-workshop resuelve desde la heading '## agent-gentle (workshop)', el link relativo ../odd/tasks/agent-gentle-official-home.md apunta al archivo real, y los PR #101/#102 citados existen, están mergeados y sus títulos coinciden con lo que la tabla afirma. Un criterio explícito del propio procedimiento no se cumple: su comentario declara 'no pisar uno existente' y el comando documentado sobrescribe sin backup (hallazgo bloqueante). Además quedan sin cerrar: T2 marcado Done pese a que S7 incluye 'pull dotfiles' que este mismo PR registra como salteado; la precondición de L4 (exponer cortex-maintainer-delivery antes de retirar legacy) no es verificable con la evidencia de la fila Skills; y la causa del codegraph failed queda como hipótesis sin verificar pese a la evidencia PATH que el mismo documento ya registra. Nota de proceso: el head reportado por pending (cd8989c) se movió a 1dc792b y el PR fue mergeado durante esta revisión; el review se hizo contra el head mergeado 1dc792b (el diff de context ya incluía la fila Theme RefactorIA agregada por ese commit).

Blocking (1)

• El cp -p documentado sobrescribe un mcp.json existente, contradiciendo su propio comentario (docs/gentle-official-migration.md:331): El bloque declara cp -p ~/.config/mcp/mcp.json ~/.gentle-shell/agent/mcp.json # no pisar uno existente, pero cp sin -n reemplaza el destino de forma incondicional: el comentario expresa un criterio del procedimiento que el propio comando incumple y no hace verificable. El procedimiento se presenta como repiteable ('Procedimiento aplicado el 2026-10-31 en la Mac, agent-dev y agent-gentle') y este mismo PR documenta que el destino puede existir antes de correrlo: L3 del task file registra que el home aislado de agent-gentle ya tenía brains en ~/.gentle-shell/agent/mcp.json. La sección además dice que se aplicó 'sin abrir el archivo' y no incluye chequeo de existencia ni backup del destino, así que la precondición queda solo como comentario sin mecanismo que la respete.
  • Failure scenario: En un host cuyo ~/.gentle-shell/agent/mcp.json ya declara work-brain, life-brain y second-brain (estado previo documentado en L3 de este mismo PR), un operador re-ejecuta el bloque tal cual: cp -p reemplaza ese archivo por el contenido de ~/.config/mcp/mcp.json sin previo aviso ni backup. Si las dos versiones difieren (el host tenía un servidor curado, o la fuente quedó desactualizada respecto del home aislado), el host pierde la configuración que funcionaba, y los pasos siguientes (chmod 600 y gentle-shell --isolated mcp list) no muestran rastro de lo perdido.

Suggestion (1)

• El headline del PR ('brains connected on all three') no refleja el caveat de codegraph failed del propio PR (docs/gentle-official-migration.md:337): El body afirma 'brains connected on all three' y la sección agregada dice que en agent-dev un servidor codegraph figura failed. La afirmación es estrictamente cierta si 'brains' son solo work-brain, life-brain y second-brain, pero un lector que no haga esa distinción ve dos claims aparentemente contradictorios entre el resumen del PR y la evidencia del mismo PR.

Question (3)

• T2 figura Done aunque S7 incluye 'pull dotfiles' que este PR registra como salteado (odd/tasks/agent-gentle-official-home.md:21): S7 define el deploy como 'confirm last NAS backup succeeded; then pull dotfiles, run gs sync, replace the wrapper...' y la nueva línea 21 marca T2 como 'Done 2026-10-31'. El mismo PR agrega en docs/gentle-official-migration.md:357 un Pendiente que dice que el paso de dotfiles de gs sync 'lo saltea porque tiene cambios locales'. No queda documentado si el 'pull dotfiles' de S7 corrió por otro camino o quedó sin cubrir; como está, el ledger no distingue un deploy completo de uno con una acción nombrada por S7 pendiente.
• No se puede verificar que cortex-maintainer-delivery esté entre las 12 skills copiadas (docs/gentle-official-migration.md:347): L4 del task file (odd/tasks/agent-gentle-official-home.md:28) establece la precondición 'T2 must expose it to the isolated home before retiring legacy' para la skill cortex-maintainer-delivery, y la fila Skills solo dice '12 skills cortex-* copiados de ~/.pi/agent/skills a ~/.agents/skills' sin nombrarlas, mientras la fila Pi legacy documenta que el legacy ya fue retirado. El nombre coincide con el patrón cortex-*, pero sin el listado no se puede comprobar que la precondición de L4 se cumplió antes del retiro.
• La causa 'probable PATH' del codegraph failed es una hipótesis sin verificar pese a la evidencia que el mismo documento ya registra (docs/gentle-official-migration.md:337): La nota dice 'figura failed; pendiente de revisar (probable PATH)': es una hipótesis, no evidencia, por lo que el registro no es verificable como está escrito. El mismo documento, en 'Setup de Claude Code: incidencia de CodeGraph' (línea 238), ya registra un fallo de codegraph por PATH (zsh no encontraba el comando; npm prefix -g = /home/jbarbat/npm-global) junto con su remediación. Falta establecer si el failed de agent-dev es esa misma incidencia o una distinta.

Verdict: not ready