Cómo sacar los planes de especificaciones de Factory Droid de tu directorio de inicio (Guía de 2026)

La documentación de configuración de Factory tiene una sección llamada Spec mode settings. Contiene una frase de descripción y exactamente una configuración.

"Controls the persistent spec store created by Spec Mode."

La configuración es specSaveDir, y su fila en la tabla de referencia dice:

"Directory where saved specs are written. Supports ~ expansion."

Su valor por defecto es ~/.factory/specs.

Vale la pena decirlo claramente: existe un almacén de especificaciones persistente, es una característica documentada y, por defecto, se ubica en una localización por usuario. Nada está oculto y nada está roto. El valor por defecto es simplemente una configuración de herramienta personal aplicada a un artefacto de equipo.

También es un estilo de la casa consistente en lugar de un descuido. En la misma referencia de configuración, worktreeDirectory —el directorio padre para los árboles de trabajo de git creados con el flag de worktree— tiene como valor por defecto ~/.factory/worktrees. Factory coloca su propio andamiaje en tu directorio de inicio, lo cual es el instinto correcto para el andamiaje. Una especificación no es un andamiaje.

De esto se derivan dos cosas, y la segunda es la más costosa.

El plan no viaja. Spec Mode se recomienda precisamente para el trabajo donde un plan es más importante:

"Spec Mode is for research and planning before implementation. Use it for architecture changes, migrations, security-sensitive work, or any task where you want to review the plan before Droid edits files."

Todos esos son esfuerzos de varias personas y varias semanas. La persona que implementa el paso cuatro con frecuencia no es la persona que ejecutó la sesión, y el plan no está en un lugar donde pueda leerlo.

El límite que impone el modo también merece ser citado, porque explica por qué el resultado es lo suficientemente confiable como para valer la pena conservarlo:

"During Spec Mode, Droid should not edit files, change configuration, make commits, start services, or write to external systems. It can read files, search the repo, inspect linked artifacts, and ask clarifying questions."

El razonamiento no sobrevive a la tarea. Una especificación se escribe para un momento: esta base de código, esta restricción, este conjunto de opciones. Seis meses después, la implementación se fusiona y la especificación es un archivo obsoleto en un directorio de inicio que nadie abre. Las decisiones que contiene —rechazamos el enfoque basado en eventos debido al costo de reproducción, aceptamos la tabla adicional para evitar una migración— siguen siendo verdaderas y siguen sosteniendo el sistema, pero no hay ningún lugar donde se hayan registrado como decisiones en lugar de como un párrafo dentro de un plan obsoleto.

Ese segundo problema es el que la gente descubre tarde, normalmente cuando alguien se va. Tiene la misma forma que mantener el contexto de IA cuando alguien se va: el conocimiento se escribió, y se escribió en un lugar personal.

Copiar las buenas especificaciones en el repositorio a mano. Funciona, y ocurre con las dos primeras. La fricción es que el archivo está en una ruta que tienes que recordar, nombrado por una sesión en lugar de por el trabajo, por lo que el copiado se detiene.

Pegar el plan en la descripción de la pull request. Mejor, porque termina en un lugar revisable y permanente. Pero la descripción de una PR está acotada a un solo diff, y una especificación que abarca cuatro PR se fragmenta en cuatro descripciones, cada una perdiendo las partes que importaban a las demás.

Poner el plan en un ticket. El mismo dilema. El plan ahora es visible para el equipo y está acoplado a un elemento de trabajo que se cierra. Los tickets cerrados no son el lugar donde nadie busca la razón por la que existe una tabla.

Convertir la especificación en una sección de AGENTS.md. Esto confunde dos tipos de contenido. AGENTS.md contiene instrucciones permanentes que se leen en cada sesión; una especificación es un plan de una sola vez. Si los fusionas, obtienes un archivo largo que siempre se carga y que describe un trabajo que terminó en marzo.

Dejar el valor por defecto y confiar en la transcripción de la sesión. La opción más débil, porque la propia documentación de Droid describe el comportamiento de los subagentes y de la sesión como limitados a la sesión, y una transcripción es un registro en lugar de un documento. El objetivo principal de Spec Mode es que produce algo mejor que una transcripción.

Hacer commit de cada especificación, para siempre. La sobrecorrección. Apunta el almacén al repositorio sin pensar más y obtendrás docenas de archivos de planes obsoletos, cada uno proponiendo una implementación que desde entonces ha cambiado, compitiendo con tu documentación real por la atención del lector —y compitiendo con tus archivos de instrucciones reales por la de un agente.

El patrón en los seis casos es que la gente trata la especificación como un archivo de borrador personal o como un documento permanente, y no es ninguna de las dos cosas. Es un artefacto temporal que contiene algunos hechos permanentes. La solución tiene que manejar ambas mitades.

Tres pasos. El primero es un cambio de una sola línea, el segundo decide qué confirmas en git y el tercero es lo que hace que funcione a largo plazo.

Paso 1: Apuntar specSaveDir al proyecto

Configura specSaveDir en los ajustes de Factory de tu proyecto en un directorio dentro del repositorio en lugar de aceptar el valor por defecto del directorio de inicio. Factory lee la configuración de ~/.factory/settings.json a nivel de usuario y de una carpeta .factory/ en el proyecto, así que coloca esta en el archivo del proyecto —la ubicación de una especificación es una propiedad del proyecto, no de tu máquina.

Confirma que la ruta se resuelva donde esperas en la primera ejecución antes de confiar en ella. La nota documentada sobre esta configuración es que admite la expansión de ~, por lo que vale la pena verificar el comportamiento que obtienes para el estilo de ruta que elijas en lugar de asumir.

Vale la pena conocer dos configuraciones relacionadas mientras estás en este archivo. La primera es sessionDefaultSettings.interactionMode, cuyo trabajo documentado es simplemente:

"Sets whether new sessions start in Auto or Spec Mode."

Configurarlo en spec es útil en un repositorio donde deseas que la planificación sea la postura por defecto. La segunda es specModeModel, que la referencia describe como una invalidación del modelo utilizado cuando las sesiones comienzan en Spec Mode —vale la pena configurarlo, porque la planificación y la implementación benefician a diferentes modelos. Ten en cuenta también que .droid.yaml está documentado como una superficie de configuración más antigua; utiliza los archivos de .factory/.

Paso 2: Decidir qué se confirma en git y qué se ignora

Ahora que las especificaciones llegan al repositorio, decide deliberadamente, porque la respuesta por defecto de "confirmar todo" es la sobrecorrección mencionada anteriormente.

La división útil es por vida útil. Una especificación para un trabajo que está en curso debe confirmarse —es el plan compartido, y el revisor de la PR dos la necesita. Una especificación para un trabajo que ya se ha entregado ha cumplido su propósito, y mantenerla invita a alguien a leer un plan que ya no describe el sistema.

Factory te da el mecanismo para la mitad específica de la máquina. Puedes crear un settings.local.json junto a settings.json en cualquier carpeta .factory/, y el comportamiento documentado es:

"Local overrides merge on top of the corresponding settings.json at the same level and follow the same hierarchy precedence. Add settings.local.json to .gitignore if you want to keep machine-specific preferences out of version control."

Usa eso para cualquier cosa genuinamente personal y mantén el settings.json compartido con la ruta de especificaciones compartida.

Paso 3: Extraer las decisiones antes de archivar el plan

Este es el paso que cambia el resultado, y toma alrededor de dos minutos por especificación.

Cuando el trabajo de una especificación se fusione, lee el plan una última vez y extrae las frases que seguirán siendo verdaderas el próximo año. No los pasos de implementación —esos ya están en el código. Las decisiones: qué se consideró, qué se rechazó y por qué. Una especificación normalmente contiene tres o cuatro de estas, enterradas en prosa entre veinte párrafos de secuenciación.

Esas tres o cuatro frases son todo el valor duradero del documento. Regístralas en algún lugar que no sea un archivo de plan, y el archivo de plan se podrá archivar o eliminar sin perder nada. Sáltate este paso y volverás a conservar especificaciones obsoletas para siempre porque tienes miedo de lo que hay dentro —el mismo problema de acumulación que hace que la gente vuelva a explicar el contexto a la IA una y otra vez.

MemoryLake es donde van las decisiones extraídas. Se encuentra fuera del repositorio y fuera de cualquier agente individual, y responde preguntas sobre las decisiones de tu proyecto a través de MCP o la API —de modo que el razonamiento de una especificación está disponible para quien lo solicite, en cualquier herramienta, después de que el archivo del plan haya desaparecido. Tus especificaciones permanecen en el directorio del proyecto donde las escribe Factory; la capa compartida contiene las cuatro frases que vale la pena conservar.

Paso 1: Crear una clave de API

Genera una clave y realiza tu primera solicitud en unos treinta segundos. Haz esto antes del Paso 3 anterior, para tener un lugar donde colocar cada decisión a medida que lees el plan.

Paso 2: Subir tus primeras memorias

Revisa tus especificaciones existentes —incluidas las que todavía están en el directorio de inicio— y registra cada decisión real con lo que se eligió, lo que se rechazó y por qué. Los documentos y archivos de soporte van al mismo lugar; convertir los documentos del proyecto en memoria de IA cubre cómo hacer esto en masa sin tener que reescribir.

Paso 3: Conectar tu IA y agentes

Dale a Droid, Claude, Codex y a tus otros agentes acceso a través de MCP o la API. La próxima sesión de Spec Mode comenzará sabiendo ya lo que decidieron las últimas cinco, que es la diferencia entre planificar y volver a planificar.

El primer cambio es que un plan es revisable por las personas a las que afecta. Está en el repositorio, en una rama, en un diff. El implementador del paso cuatro lo lee sin pedirle un archivo a nadie.

El segundo es que Spec Mode obtiene mejores entradas. Droid investiga el repositorio antes de proponer un plan, por lo que un repositorio que contiene los últimos planes y un registro consultable de decisiones pasadas le da más elementos con los que trabajar que un repositorio que no contiene ninguno de los dos.

El tercero es que las especificaciones dejan de acumularse. Una vez que se ha extraído el contenido duradero, eliminar un plan entregado es gratis, y un directorio de planes en curso se mantiene lo suficientemente pequeño como para que la gente lo lea.

El cuarto es que el plan sobrevive a la laptop. Una ruta de directorio de inicio es por máquina, que es la misma asimetría detrás de que Claude Code olvide cosas entre máquinas —y se aplica la misma solución: coloca el elemento compartido donde lo guarde el repositorio o un servicio compartido, no donde lo haga una sola máquina.

El quinto es que los traspasos se acortan. La mitad de lo que compartir contexto entre sesiones intenta resolver es que alguien vuelva a deducir una decisión que ya se tomó cuidadosamente, una vez, en un documento que nadie más podía ver.

Configura specSaveDir en los ajustes del proyecto, no en los ajustes de usuario. El lugar donde viven las especificaciones es una propiedad del proyecto. Una configuración a nivel de usuario apunta a una ruta que puede no tener sentido en el próximo repositorio que abras.

Verifica la ruta en la primera ejecución. La nota documentada sobre esta configuración se refiere a la expansión de ~. Comprueba lo que realmente obtienes antes de depender de ello.

Confirma las especificaciones en curso, retira las entregadas. Un plan para un trabajo fusionado es una descripción de un sistema que desde entonces ha cambiado.

Extrae las decisiones antes de archivar. Tres o cuatro frases por especificación. Este es todo el trabajo, y es lo que hace que la eliminación sea segura.

Mantén las especificaciones fuera de tus archivos de instrucciones. AGENTS.md se carga en cada sesión. Un plan terminado no pertenece a cada sesión.

Usa settings.local.json para las preferencias específicas de la máquina. Se fusiona sobre el archivo compartido en el mismo nivel y está destinado a ser ignorado por git, lo que mantiene compartida la ruta de especificaciones compartida.

Considera establecer el repositorio en Spec Mode por defecto. Configurar el modo de interacción en spec hace que la planificación sea la postura por defecto en el trabajo donde eso es lo que deseas.

Migra fuera de .droid.yaml. Está documentado como una superficie de configuración más antigua, y los archivos .factory/ son los actuales.

La documentación de Factory describe un almacén de especificaciones persistente controlado por una sola configuración, specSaveDir, que por defecto es un directorio en tu carpeta de inicio. El propio Spec Mode es una planificación de solo lectura que investiga el repositorio y se detiene para obtener la aprobación humana, recomendado para cambios de arquitectura, migraciones y trabajo sensible a la seguridad. Junta esos dos hechos y la configuración por defecto escribe el documento más cuidadosamente razonado de tu equipo en el único lugar que tu equipo no puede ver.

Cambiar la ruta toma una línea. La parte que da resultados es el hábito que sigue: confirma los planes que describen el trabajo en curso, retira los que describen el trabajo ya entregado y, antes de retirar uno, extrae las tres o cuatro decisiones de su interior que seguirán importando el próximo año. Haz eso y Spec Mode se convertirá en lo que parece en el papel: una máquina para producir buenas decisiones que tu equipo conserva, en lugar de buenas decisiones que una sola laptop conserva.