Referencia de línea de comandos¶

Una vez instalado, flower es un único ejecutable: 4 subcomandos y 23 opciones. Esta página las lista todas: el tipo de cada opción, su valor por defecto, su semántica exacta, además de cómo intervenir mientras corre, qué te pregunta la primera vez, cuáles son los códigos de salida y qué ficheros deja en tu directorio. Después de leer esta página no hace falta abrir el código fuente.

Código fuente: flower/cli.py.

Total de 23 opciones = 5 globales + 11 propias de go + 6 propias de once + -h/--help. run y setup no tienen opciones propias.

Formas de invocación¶

Todos los argv de flower pasan primero por _with_default_cmd(), que completa el subcomando predeterminado, y luego se entregan a argparse (cli.py:1437-1439). Por eso funciona flower "帮我做一个 X": se reescribe a flower go "帮我做一个 X".

Reglas para completar el subcomando predeterminado (cli.py:940-976):

1. El conjunto de opciones globales se deriva del propio parser principal, no es una lista codificada a mano. Las de nargs == 0 cuentan como flags puros; el resto, como opciones con valor.
2. Se recorre de izquierda a derecha saltando las opciones globales. Las que llevan valor se saltan junto con su valor, y también se reconoce la forma con =, tipo --workspace=/tmp.
3. Se para en el primer token que no sea una opción global. Si es go, run u once, se pasa tal cual a argparse; en caso contrario se inserta un go delante, con lo que ese token pasa a ser el cuerpo de la petición de go.
4. Si se recorre todo sin encontrar un argumento posicional (argv vacío, o solo opciones globales) → se añade go al final y se entra en la entrada interactiva.
5. Excepción: si argv contiene -h o --help, se devuelve tal cual y argparse imprime la ayuda.

La constante que se usa para decidir es _CMDS = ("go", "run", "once") (cli.py:937): setup no está ahí dentro, con las consecuencias que se ven en setup.

El resultado real de la reescritura¶

Las palabras run y once no pueden usarse directamente como cuerpo de la petición: es una ambigüedad reservada a propósito (cli.py:949-950). Para usarlas como petición, escribe flower go run.

Seis formas válidas de escribirlo¶

flower                                    # 1. En seco: pregunta “要做什么?” o “接着上次?”
flower "帮我做一个 X"                       # 2. La petición como argumento posicional
echo "帮我做一个 X" | flower --timeout 0    # 3. stdin por tubería
flower once "读一眼这个仓库"                 # 4. Un solo agente
flower run flows.py:main                  # 5. Ejecuta un workflow propio
flower go setup                           # 6. go explícito, con setup como cuerpo de la petición

La forma de módulo python -m flower.cli es equivalente a flower (cli.py:1451-1452). El wrapper de contenedor docker/flowerbox acepta exactamente los mismos argumentos que flower.

stdin por tubería¶

Cuando sys.stdin.isatty() es falso, ask_for_prompt() no imprime la cabecera del prompt y lee una línea directamente con input("> ") (cli.py:993-1001). Por eso funciona echo "..." | flower.

Pero justo después imprime un aviso, y el hilo de stdin llega inmediatamente a EOF y termina:

! 标准输入不是终端,没人能回答提问。想让它自己判断就加 --timeout 0

Ejecutar por tubería pide --timeout 0: las preguntas dejan de fingir que esperan 30 minutos, quedan sin respuesta al instante, el agente decide por su cuenta y escribe sus supuestos en el apartado «未知与假设» del brief.

Subcomandos¶

go¶

Texto de ayuda: 一键跑:问清需求 → 派人干活(不写子命令时的默认) (cli.py:1275-1307).

Argumento posicional ask, con nargs="?": si no lo das, entra en la entrada interactiva. Es la puerta de entrada más usada; flower "做 X" pasa por aquí.

Lo que hace (cli.py:1190-1221):

1. ensure_credentials(): comprueba las credenciales y lanza de verdad una sonda contra la API; ver el flujo de configuración de la primera ejecución.
2. Sondeo de despertar: solo mira si este directorio se ha usado antes, sin escribir un solo byte.
3. Si no diste ask, imprime el prompt y pregunta; escribir /new equivale a --new, y entonces vuelve a preguntar la petición.
4. Si es una continuidad, imprime una línea de banner de despertar.
5. Construye un workflow de tres pasos: 确认需求 → 设定目标 → 干活, con un 干活·判定#N detrás de cada ronda de trabajo. Con --clarify-only solo queda el primer paso.
6. Arranca.

El banner de despertar tiene esta pinta (el directorio home dentro de las rutas se sustituye por ~):

<- 在 ~/proj 接上上次  需求已确认 · 目标 7 条 · 干活上下文 71.4K · 第 3 次唤醒

需求已确认 aparece siempre; 目标 N 条 solo si hay lista de veredicto; 干活上下文 X requiere poder consultar en sessions.db el contexto de la última vuelta de esa sesión, y si no se encuentra no se muestra.

Las 11 opciones de go¶

Casos límite en los valores; ninguno da error ni avisa:

• --rounds 0 y --rounds 1 son equivalentes: internamente es retries = max(0, rounds - 1), ambos ejecutan 1 ronda.
• Cualquier valor negativo de --asks significa sin límite, no solo -1.
• Cualquier valor negativo de --timeout equivale a 0, es decir, totalmente automático.
• --window 0 se ignora en silencio (0 es falsy y ni siquiera se propaga) y se vuelve al valor por defecto deducido del nombre del modelo. Los negativos sí se propagan y luego se elevan a 10000.
• --clarify-only es una operación vacía en un directorio ya clarificado: el paso 确认需求 ve un 需求.md completo y lo salta, y como en el workflow solo está ese paso, no ocurre nada (salvo que el contador de despertares sube en 1). Para volver a clarificar hay que combinarlo con --new.
• El --help de go termina diciendo «全局开关(-v/-w/-r/-T)见 flower --help», y esa línea se deja -W.

run¶

Texto de ayuda: 运行一个 workflow (cli.py:1309-1312).

Argumento posicional target, escrito como módulo:atributo. Se admiten ambas formas (cli.py:1010-1031):

flower run mypkg.flows:build     # import por nombre de módulo
flower run flows.py:build        # ruta de fichero; mete el directorio padre en sys.path e importa por nombre de fichero

Si el atributo obtenido es invocable se llama una vez y su valor de retorno se toma como workflow; si ya es un objeto workflow, se usa directamente.

run no tiene ninguna opción propia, solo las 5 globales. Por tanto --window, --no-handoff y demás toman siempre su valor por defecto en esta ruta (el código usa getattr como respaldo, cli.py:1041-1043). Para ajustarlas, escríbelas dentro de tu propio workflow.

once¶

Texto de ayuda: 跑一次单 agent (cli.py:1314-1324). El argumento posicional prompt es obligatorio.

Construye un AgentSpec(name="ad-hoc", …) y lo ejecuta directamente, sin pasar por _drive. Por eso en once no hay:

• Interrupción con Ctrl-C acompañada de un mensaje (pulsarlo es un KeyboardInterrupt normal)
• Hilo de respuesta por stdin ni prompt de entrada fijo al pie
• Preguntas al oráculo
• Rescate contable ante SIGHUP / SIGTERM
• La línea final 总花费 … · 清单 …
• La guía de reconfiguración automática tras un fallo de credenciales

En el manifiesto de ejecución, el nombre de este paso es siempre ad-hoc.

setup¶

Texto de ayuda: 配置凭证(API key / 网关 / 模型),写到 ~/.config/flower/.env (cli.py:1326-1328). No tiene ninguna opción.

Lo que hace: lee el .env → decide si ya está configurado → lanza el flujo de configuración interactivo, con reason igual a 重新配置。 o 还没配过凭证。. El contenido de la pantalla está en el flujo de configuración de la primera ejecución.

Opciones globales¶

Las 5 opciones globales están registradas a la vez en el parser principal y en cada subcomando (cli.py:1250-1266). La copia del subcomando usa argparse.SUPPRESS, así que si no se da no escribe el atributo: por eso da igual escribirlas antes o después del subcomando, no se pisan entre sí. El efecto secundario es que no aparecen en el --help del subcomando; para verlas hay que ejecutar flower --help.

Lo de que -r/--run-dir sea relativo al CWD muerde: flower -w /other/proj "做 X" crea runs/ en el directorio desde el que lanzaste el comando, mientras que .flower/ se crea bajo /other/proj/: los dos estados quedan separados. Para tenerlos juntos, da explícitamente -r /other/proj/runs.

La ayuda de -v dice «显示思考与工具结果», pero el pensamiento del hilo principal se muestra por defecto. Lo que -v activa de verdad además es:

• El cuerpo del subagent (por defecto no se muestra, solo sus llamadas a herramientas)
• Los resultados normales de herramientas (por defecto solo se muestran los que dan error)
• El evento prompt
• Un volcado, antes de arrancar, de la configuración de credenciales vigente, con el token enmascarado dejando solo los 4 primeros caracteres

Esto último sale por un print() pelado, sin pasar por la desinfección de salida, sin ajuste de ancho y sin la protección del cerrojo de escritura del terminal: al ejecutar varios flower en paralelo, esas líneas pueden salir mezcladas.

Cómo hablarle mientras corre¶

Una vez arrancada la ejecución, el terminal está leyendo tu entrada todo el tiempo. No hace falta esperar a que pregunte ni pulsar nada para entrar en modo entrada: la última línea es siempre la línea en la que puedes escribir.

El prompt de entrada fijo al pie¶

Hay un hilo daemon flower-stdin que lee stdin de principio a fin (cli.py:764-934), con select sondeando cada 0.2 segundos en lugar de lectura bloqueante (así la señal de parada puede despertarlo; en flujos que no soportan select, como en Windows, degrada a lectura bloqueante).

Lee siempre, no solo cuando hay una pregunta pendiente. El motivo: si solo leyera al preguntar, lo que teclees durante las horas de trabajo quedaría en el búfer del terminal y, en la siguiente pregunta, se tomaría como respuesta; la pregunta quedaría contestada antes de que la vieras.

En cuanto a la pantalla, _say() es la única salida: antes de imprimir borra el prompt y después lo vuelve a dibujar (cli.py:309-315), de modo que el prompt no acaba empujado hacia arriba por la salida de eventos. Al redibujarlo también repinta los caracteres que habías tecleado a medias sin pulsar intro: viven en _PROMPT["buf"] (cli.py:183-192). Sin eso el contenido no se perdería de verdad (sigue en el búfer de línea del terminal y el intro lo enviaría igual), pero no lo verías, dudarías y lo volverías a escribir.

El prompt tiene dos textos, según haya o no una pregunta pendiente de respuesta:

Modo de entrada carácter a carácter y teclas¶

Para poder repintar «los caracteres a medias», flower tiene que tomar el control de la entrada. Cuando stdin es un terminal y se puede import termios, pone el terminal en cbreak antes de arrancar el hilo flower-stdin (cli.py:793-807): se usa cbreak y no raw para que Ctrl+C siga generando SIGINT y todo lo de Ctrl-C siga funcionando. Tiene que ser antes de arrancar el hilo: meterlo dentro del hilo abre una carrera real, y los caracteres tecleados en el instante en que el hilo aún no ha conseguido CPU se los come el modo de línea, lo que se manifiesta como «se ha perdido la entrada» (reproducido de forma estable una de cada tres veces en pruebas, cli.py:928-934).

Si no se puede configurar, se vuelve al readline() de línea completa de siempre (stdin no es terminal, termios no disponible, o tcgetattr falla). Ambos caminos funcionan; simplemente, en modo línea no existen las teclas de abajo (cli.py:883-899).

La lógica de edición vive en LineEditor (cli.py:320-414), pura máquina de estados que no toca el terminal:

El intro entrega el búfer y lo vacía, y a la vez salta de línea en pantalla: lo que dijiste queda arriba (cli.py:811-827).

Adónde va lo que tecleas¶

Al entrar en la bandeja de entrada se imprime un acuse:

+ 收到 (它下次查收件箱时会看到;已追加进确认书)

Cuando no hay brief donde volcarlo, la segunda mitad pasa a ser 没有确认书可落盘 —— 它可能活不过下一个步骤. La bandeja de entrada no interrumpe al ejecutor que está trabajando: solo se lo lleva cuando consulta la bandeja por iniciativa propia. La misma frase se añade además a notes/需求.md; sin volcarla a disco no sobrevive al límite del paso, porque el siguiente paso es una sesión nueva que solo lee el documento congelado.

Empezar por ? = consulta al oráculo¶

Una línea que empieza por ? no se envía al agente que está corriendo, sino al oráculo:

? 现在到哪一步了

Arranca un Runtime independiente, con run_dir en <run_dir>/aside/, de modo que su coste y su linaje de sesiones no se mezclan con el manifest.json principal. El rol es de solo lectura, con las herramientas Read, Glob y Grep, un máximo de 12 vueltas y un tope de coste de $0.5. El contexto que ve son los últimos 60 eventos (los eventos thinking y prompt no entran en esa ventana), cada uno truncado a 200 caracteres, más la descripción de las rutas del banco de trabajo.

Corre en paralelo: la ejecución en curso no espera ni un segundo. La respuesta se ve así:

# 旁路
  <回答正文>
  ($0.0123,没有打扰正在跑的运行)

Si falla, imprime una línea en rojo # 旁路问答失败:<类型>: <消息>, sin afectar al flujo principal. Al salir espera como mucho 120 segundos a que terminen las consultas al oráculo, y antes de esperar imprime una línea (等 N 条旁路问答收尾…).

Lo que dice no entra en el contexto de esa ejecución: preguntar no la altera, y la respuesta se descarta al terminar.

if raw.startswith("?") or raw.startswith("?"):

Qué se ve en pantalla¶

Los iconos son todos ASCII, no emoji (cli.py:51-69). La razón está escrita en un comentario del código: los emoji y los caracteres de marco, geométricos y de flecha disparan el fallback de glifos del terminal, y eso ya provocó dos cuelgues del terminal.

  ? 这个工具要做成 CLI 还是库?
     1) CLI
     2) 库
     (还能问 5 次)
<- 在 ~/proj 接上上次  需求已确认 · 目标 7 条 · 第 3 次唤醒

Los cinco estados de una pregunta se ven así en pantalla:

Cuando --asks es sin límite (el valor por defecto), esa última línea de «还能问 N 次» no se muestra.

Cuando el relevo termina de escribir el documento de relevo, sale un bloque entero:

# 上下文 950.0K/1000K —— 写交接准备换代
  - 现在在做    …
  - 已定的事    …
  - 走不通的    …
  - 下一步      …
<- 交接写在 ~/proj/.flower/notes/交接-干活.md
<- 新会话接手,上下文从 950.0K 重新开始

Si el documento de relevo se degrada, se inserta una línea más en rojo: 交接没写成,用了降级版本 —— 接手的人会自己去现场看.

La salida hace además dos cosas que no ves: todas las líneas pasan por una desinfección que solo deja pasar los códigos de color SGR del propio flower, de modo que las secuencias de borrado de pantalla o movimiento de cursor que escupan el modelo o las herramientas se tragan enteras; y el ancho se toma como max(40, min(columnas del terminal, 110)), así que en terminales anchos no se ocupa toda la línea, y es a propósito.

El prompt del arranque¶

Al ejecutar flower en seco (sin petición), primero pregunta. Hay dos textos:

要做什么? 一句话就够,回车开始(Ctrl-C 退出)
> 

接着上次? 直接回车 = 接着做;也可以说点新的;/new = 重开一件事(Ctrl-C 退出)
> 

El segundo solo aparece si en ese directorio ya se ha ejecutado antes y 需求.md tiene los cuatro apartados completos.

Este prompt lee con input(), sin pasar por la interpretación del shell. Las comillas chinas, los espacios y los signos de exclamación se pueden escribir tal cual: esa es toda la razón de que exista. zsh, al encontrarse una comilla derecha china, entra en continuación dquote> y parece colgado, cuando en realidad no ha arrancado ni una vez.

• Entrada vacía + primera vez → sale, imprimiendo 诉求是空的。直接 `flower` 然后按提示输入,或者 flower "帮我做一个 X"。
• Entrada vacía + despertar → es válido, significa «sigue con lo de antes»
• Escribir /new → equivale a --new: archiva el tramo anterior y vuelve a preguntar la petición
• Ctrl-C / Ctrl-D → sale, imprimiendo 已取消

Timeout¶

--timeout es un float en segundos, por defecto 1800.0. Tres tipos de valor:

--timeout 0 y --timeout -1 son exactamente equivalentes. Por tubería, en CI o desatendido, se usa siempre esto.

Cuando una pregunta no obtiene respuesta, el resultado de herramienta que se devuelve al modelo es un texto fijo, de cuatro tipos:

Ctrl-C¶

La semántica de Ctrl-C es completamente distinta en dos sitios.

Pulsado en el prompt de arranque >: sale del programa directamente, imprimiendo 已取消.

Pulsado durante la ejecución: interrumpe la ronda actual y te da una oportunidad de hablar:

! 已打断这一轮。正在跑的 subagent 会丢掉半成品。
  要说什么?(直接回车 = 什么都不说,接着跑;再按一次 Ctrl+C = 退出)
> 

Pulsar intro aquí significa interrumpir sin decir nada y seguir. Si en ese momento hay preguntas pendientes, se imprime una línea más: (有 N 个提问还等着,打断不影响它们).

Pulsar Ctrl+C otra vez sí sale de verdad, y como KeyboardInterrupt no capturado: en pantalla queda un traceback de Python, no es una salida limpia.

La interrupción es cooperativa: corta limpiamente en un límite de mensaje, sin cancelar tareas a la fuerza. No cuenta como un intento fallido y no consume reintentos. Al continuar se adjunta una nota que le dice al modelo que «una llamada a herramienta en vuelo que devuelve interrupted es un efecto normal de la interrupción, no un fallo del entorno».

Este Ctrl-C personalizado solo se instala cuando sys.stdin.isatty() (cli.py:1097). Ejecutando por tubería se mantiene el comportamiento por defecto de Python, es decir, salir a la primera. La ruta once no pasa por aquí, así que allí Ctrl-C también sale a la primera.

SIGHUP / SIGTERM¶

Las rutas go y run instalan manejadores para SIGHUP y SIGTERM: primero escriben también en manifest.json el paso que estaba en vuelo marcándolo como killed-by-signal, y después restauran la acción por defecto y se van de verdad.

El origen: cuando el terminal se cae, el kernel envía SIGHUP, cuya acción por defecto termina el proceso directamente, el finally no corre y el manifiesto no se escribe, y se pierde la contabilidad de una ejecución entera. Si no es el hilo principal del sistema operativo o la plataforma no lo soporta, se salta en silencio.

El flujo de configuración de la primera ejecución¶

Las tres puertas de entrada go, run y once llaman al principio a ensure_credentials() (cli.py:1392-1428), con dos filtros.

Primer filtro: ¿hay credenciales?¶

Busca las credenciales por orden de prioridad. Si no encuentra ANTHROPIC_API_KEY ni ANTHROPIC_AUTH_TOKEN, lanza la configuración interactiva; en modo no interactivo (stdin no es terminal) no bloquea: imprime esto y sale:

缺少凭证:需要 ANTHROPIC_API_KEY 或 ANTHROPIC_AUTH_TOKEN。
最省事:跑一次 `flower setup`,把 token 存到 /Users/you/.config/flower/.env(装一次,处处生效)。
或者:在当前目录建 `.env`,或 export 进进程环境。
flower 不读 ~/.claude/settings.json —— 那是可移植性的代价。

Este texto no cuadra con la implementación en dos puntos: el flower setup de la segunda línea hoy no se alcanza (ver setup); y la cuarta línea dice lo contrario que el código: flower sí toma el bloque env de ~/.claude/settings.json y de settings.local.json como último nivel de respaldo, tomando prestadas de ahí 9 claves de credenciales y sin apropiarse de ningún otro ajuste. El sitio que imprime esa línea es env.py:192 (la función check_credentials() está definida en env.py:184), mientras que lo que lee de verdad esos dos ficheros está en env.py:56-75 y :109-111; anotado en issue #13. Manda el código: sí los lee. La prioridad de búsqueda completa y esas 9 claves están en la referencia de configuración.

Qué pregunta la configuración interactiva¶

== 配置 flower ========================================
<为什么要配这一行>
凭证会存到 /Users/you/.config/flower/.env(只你可读)。装一次,处处生效。

1. 你的 API key 或网关 token (Anthropic 官方的 sk-ant-… 或第三方网关签发的)
   > 

2. 网关地址 (直接回车 = Anthropic 官方;第三方网关填它的 BASE_URL)
   > 

3. 模型名 (直接回车 = 默认;网关有自己的模型名就填,如 claude-opus-5[1m])
   > 

+ 存好了:/Users/you/.config/flower/.env

• La pregunta 1 es obligatoria. Si la dejas vacía, imprime en rojo 没给 token,取消。 y abandona la configuración.
• Las preguntas 2 y 3 pueden dejarse vacías.
• Si stdin no es un terminal, todo el flujo se salta sin bloquear.

Las claves que escribe¶

La ruta del fichero es ${XDG_CONFIG_HOME:-~/.config}/flower/.env, y el directorio padre se crea automáticamente. La escritura es sobrescritura completa, saltando las claves con valor vacío; al terminar hace chmod 0600 y carga los valores de inmediato: no hace falta reabrir la shell. La primera línea es siempre un comentario que recuerda no subirlo al control de versiones.

Segundo filtro: ¿funcionan las credenciales?¶

Una vez completada la configuración, imprime una línea - 验一下凭证… y lanza de verdad una llamada a la API.

Detalles de la sonda: POST {BASE_URL}/v1/messages, max_tokens=16, timeout por defecto de 20 segundos, usando urllib de la stdlib, sin dependencias. El modelo se toma en el orden ANTHROPIC_DEFAULT_HAIKU_MODEL → ANTHROPIC_MODEL → claude-3-5-haiku-20241022. Si hay ANTHROPIC_API_KEY usa la cabecera x-api-key; si no, authorization: Bearer <ANTHROPIC_AUTH_TOKEN>.

max_tokens está puesto a 16 y no a 1 a propósito: en pruebas, los modelos con cadena de pensamiento forzada ni siquiera caben con el pensamiento y el servidor tarda hasta 30 segundos en responder; con 16 bastan 3.6 segundos.

El resultado de la sonda se trata en tres categorías, y la diferencia importa:

El criterio de config está apretado a propósito: en el JSON de error de estilo Anthropic aparece casi con seguridad la palabra model, y tomarla como «el nombre del modelo está mal» convertiría un 400 transitorio en un error de configuración y forzaría a reconfigurar; tiene que decir explícitamente «no se encuentra / no existe» para contar (env.py:176-182).

Lo de net es deliberado: un bache de red no debe obligarte a reintroducir el token, y además flower tiene su propio mecanismo de suspensión y reconexión ante caída de red. Si ves «探针没打通», ignóralo y sigue.

La oportunidad de reconfigurar se da como mucho una vez. Si la segunda también falla, sale.

La sonda solo se lanza en un terminal interactivo. ensure_credentials() retorna directamente sin hacer esa llamada a la API si se cumple cualquiera de estas condiciones (cli.py:1413): quien llama pasó probe=False, está puesta FLOWER_NO_PROBE, o stdin no es un terminal (tubería / CI / pruebas offline). El motivo es que en no interactivo, aunque la sonda detecte un problema, no se puede arreglar: el único efecto sería «fallar antes», y fallar antes por un falso positivo es peor que no sondear. Si las credenciales son malas de verdad, la ejecución reventará sola, y ese camino lo recoge la reconfiguración automática tras un fallo.

Reconfiguración automática tras un fallo¶

Cuando el workflow falla, flower toma el mensaje de error del paso que falló y lo compara con una expresión regular (401, invalid api key, authentication, unauthorized, 无效…key/token/密钥). Si hay coincidencia y stdin es un terminal, imprime en el acto ! 看起来是凭证不对:<前 120 字> y lanza la configuración interactiva; una vez configurado, imprime:

配好了。再跑一次刚才的命令 —— 同一目录会接着上次。

Y después sale con código 1 en cualquier caso. La ruta once no tiene esta parte.

Códigos de salida¶

Todos los mensajes del código de salida 1:

Al terminar (rutas go / run) se imprime una última línea:

总花费 $1.2345 · 清单 /abs/path/runs/manifest.json

Ese importe cuenta solo el gasto de este proceso, sin incluir la ejecución anterior, aunque el propio fichero de manifiesto sí acumula entre procesos.

Qué crea en el proyecto¶

Dos árboles: <run_dir>/ (por defecto ./runs/, relativo al CWD) guarda la contabilidad y las sesiones; <workspace>/.flower/ guarda el banco de trabajo.

runs/¶

Campos de cada registro de manifest.json:

step  session_id  ok  cost_usd  num_turns  text  error  started_at  ended_at
attempts  errors[]  resumed  retired[]  context  duration_s  run

run es la marca de este proceso, con formato YYYYmmdd-HHMMSS-<6 位 hex>. La política de volcado es añadir sin sobrescribir: antes de cada escritura se relee el fichero y se deduplica por run; las filas de este proceso se sustituyen por las más recientes y las de otros procesos se dejan tal cual.

El nombre del paso tiene cuatro formas:

Cuando lo mata una señal, el paso en vuelo también se escribe, con el campo error a killed-by-signal.

Varios flower en paralelo sobre el mismo directorio: manifest.json es seguro (relectura + fusión por run), pero lineage.json se sobrescribe entero, y dos procesos se pisarán mutuamente el linaje de los pasos con el mismo nombre. Para ir en paralelo, usa un -r distinto.

lineage.json guarda la ruta absoluta del workspace. Si no cuadra, se hace como si no existiera y se vuelve en silencio a una sesión nueva, sin error: después de copiar el directorio a otro sitio, el viejo session_id tampoco se podría consultar.

.flower/¶

La ruta go genera siempre estos ficheros bajo notes/:

Con --isolate, el banco de trabajo se traslada fuera del repositorio: <workspace>.parent/.flower-<nombre del workspace>/. El worktree es la copia privada de cada agente y el banco de trabajo es la capa compartida entre agentes; lo compartido no puede vivir dentro de una valla privada. En ese caso, la ruta del banco de trabajo que se le da al modelo es absoluta.