Referência da linha de comando¶

Depois de instalado, flower é um único executável, 4 subcomandos, 23 flags. Esta página lista todas elas: o tipo de cada flag, o valor padrão, a semântica exata, mais como falar com a run no meio do caminho, o que ele pergunta na primeira execução, quais são os códigos de saída e quais arquivos ele coloca no seu diretório. Depois de ler esta página você não precisa abrir o código-fonte.

Código-fonte: flower/cli.py.

Total de 23 flags = 5 globais + 11 próprias do go + 6 próprias do once + -h/--help. run e setup não têm flags próprias.

Formas de invocação¶

Todo o argv do flower passa primeiro por _with_default_cmd(), que completa o subcomando padrão, e só depois vai para o argparse (cli.py:1437-1439). É por isso que flower "帮我做一个 X" funciona — ele é reescrito como flower go "帮我做一个 X".

As regras para completar o subcomando padrão (cli.py:940-976):

1. O conjunto de flags globais é derivado do próprio parser principal, não é uma lista fixa no código. As que têm nargs == 0 contam como flags puras; as demais contam como flags com valor.
2. Varre da esquerda para a direita, pulando as flags globais. As que levam valor são puladas junto com o valor, e a forma com =, tipo --workspace=/tmp, também é reconhecida.
3. Para no primeiro token que não é uma flag global. Se ele for go, run ou once, é entregue ao argparse como está; caso contrário, insere um go antes dele, e ele vira o corpo do pedido do go.
4. Se a varredura terminar sem encontrar argumento posicional (argv vazio, ou só com flags globais) → acrescenta go no final e entra na entrada interativa.
5. Exceção: se o argv contiver -h ou --help, é devolvido como está, para o argparse imprimir a ajuda.

A constante usada nessa decisão é _CMDS = ("go", "run", "once") (cli.py:937) — setup não está lá dentro, veja as consequências em setup.

O que a reescrita realmente produz¶

As palavras run e once não podem ser usadas diretamente como corpo do pedido; essa ambiguidade foi deixada de propósito (cli.py:949-950). Para usá-las como pedido, escreva flower go run.

As seis formas que funcionam¶

flower                                    # 1. Sem nada: pergunta "要做什么?" ou "接着上次?"
flower "帮我做一个 X"                       # 2. Pedido como argumento posicional
echo "帮我做一个 X" | flower --timeout 0    # 3. Alimenta o stdin por pipe
flower once "读一眼这个仓库"                 # 4. Agent único
flower run flows.py:main                  # 5. Executa um workflow próprio
flower go setup                           # 6. go explícito, com setup como corpo do pedido

A forma de módulo python -m flower.cli é equivalente a flower (cli.py:1451-1452). Os parâmetros do wrapper de container docker/flowerbox são exatamente iguais aos do flower.

Alimentar o stdin por pipe¶

Quando sys.stdin.isatty() é falso, ask_for_prompt() não imprime o cabeçalho do prompt e lê uma linha direto com input("> ") (cli.py:993-1001). Por isso echo "..." | flower funciona.

Mas logo em seguida ele imprime um aviso, e a thread de stdin encontra EOF imediatamente e sai:

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

Rodar por pipe deve vir com --timeout 0: as perguntas deixam de fingir que esperam 30 minutos, falham na hora, e o agent decide sozinho e escreve as suposições na seção "未知与假设" do brief.

Subcomandos¶

go¶

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

Argumento posicional ask, com nargs="?" — se não for dado, entra na entrada interativa. É a porta de entrada mais usada; flower "做 X" passa por aqui.

O que ele faz (cli.py:1190-1221):

1. ensure_credentials() — verifica as credenciais e realmente dispara uma sonda à API, veja Fluxo de configuração na primeira execução.
2. Sondagem de wake: apenas dá uma olhada de leitura para ver se este diretório já foi usado, sem gravar um único byte.
3. Se ask não foi dado, mostra o prompt e pergunta; digitar /new equivale a --new, e então pergunta o pedido de novo.
4. Se for continuity, imprime uma linha de banner de wake.
5. Monta o workflow de três steps: 确认需求 → 设定目标 → 干活, com um 干活·判定#N depois de cada rodada de trabalho. --clarify-only deixa só o primeiro step.
6. Começa a rodar.

O banner de wake é assim (o diretório home no caminho é trocado por ~):

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

需求已确认 aparece sempre; 目标 N 条 só aparece quando existe lista de verdict; 干活上下文 X exige que o contexto da última rodada daquela session possa ser consultado em sessions.db — se não for encontrado, não é exibido.

As 11 flags do go¶

Cantos dos valores, todos silenciosos, sem erro e sem aviso:

• --rounds 0 e --rounds 1 são equivalentes — internamente é retries = max(0, rounds - 1), ambos rodam 1 rodada.
• Qualquer negativo em --asks significa sem limite, não só -1.
• Qualquer negativo em --timeout equivale a 0, ou seja, totalmente automático.
• --window 0 é silenciosamente ignorado (0 é falsy, nem chega a ser repassado) e volta ao valor padrão inferido pelo nome do modelo. Negativos são repassados e depois presos em 10000.
• --clarify-only é uma operação vazia num diretório já esclarecido — o step 确认需求 vê um 需求.md completo e pula, e como esse é o único step do workflow, nada acontece (fora o contador de wake +1). Para reesclarecer, combine com --new.
• O --help do go termina com "全局开关(-v/-w/-r/-T)见 flower --help"; essa linha esqueceu o -W.

run¶

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

Argumento posicional target, escrito como módulo:atributo. As duas formas são suportadas (cli.py:1010-1031):

flower run mypkg.flows:build     # import pelo nome do módulo
flower run flows.py:build        # caminho de arquivo; coloca o diretório pai no sys.path e importa pelo nome do arquivo

Se o atributo obtido for chamável, ele é chamado uma vez e o retorno vira o workflow; se já for um objeto de workflow, é usado direto.

run não tem nenhuma flag própria, só as 5 globais. Então --window, --no-handoff e afins ficam sempre no padrão nesse caminho (o código usa getattr como fallback, cli.py:1041-1043). Para ajustá-los, escreva os parâmetros dentro do seu próprio workflow.

once¶

Texto de ajuda: 跑一次单 agent (cli.py:1314-1324). O argumento posicional prompt é obrigatório.

Ele monta um AgentSpec(name="ad-hoc", …) e executa direto, sem passar pelo _drive. Por isso o once não tem:

• Ctrl-C para interromper e falar (apertar gera um KeyboardInterrupt comum)
• Thread de resposta no stdin, nem o prompt de entrada fixo na parte de baixo
• Perguntas ao oracle
• Gravação de emergência da contabilidade em SIGHUP / SIGTERM
• A linha final 总花费 … · 清单 …
• Guia de reconfiguração automática depois de falha de credencial

No run manifest, o nome deste step é sempre ad-hoc.

setup¶

Texto de ajuda: 配置凭证(API key / 网关 / 模型),写到 ~/.config/flower/.env (cli.py:1326-1328). Sem nenhuma flag.

O que ele faz: lê o .env → decide se já foi configurado → inicia o fluxo interativo de configuração, com reason sendo 重新配置。 ou 还没配过凭证。. O conteúdo da tela está em Fluxo de configuração na primeira execução.

Flags globais¶

As 5 flags globais ficam penduradas ao mesmo tempo no parser principal e em cada subcomando (cli.py:1250-1266). A cópia dos subcomandos usa argparse.SUPPRESS: se não for passada, não escreve o atributo, então tanto faz escrevê-las antes ou depois do subcomando, uma não sobrescreve a outra. O efeito colateral é que elas não aparecem no --help dos subcomandos — para vê-las, rode flower --help.

O detalhe de -r/--run-dir ser relativo ao CWD morde: flower -w /other/proj "做 X" cria runs/ no diretório onde você digitou o comando, enquanto .flower/ é criado dentro de /other/proj/ — os dois estados se separam. Para mantê-los juntos, passe explicitamente -r /other/proj/runs.

A ajuda do -v diz "显示思考与工具结果", mas o pensamento da main thread já é exibido por padrão. O que o -v realmente liga a mais é:

• O corpo do texto dos subagents (não exibido por padrão, só as chamadas de ferramenta deles)
• Resultados normais de ferramenta (por padrão só os que deram erro)
• Eventos prompt
• Antes de iniciar, imprime uma vez a configuração de credenciais em vigor, com o token mascarado deixando só os 4 primeiros caracteres

Esta última passa por um print() cru, sem sanitização de saída, sem quebra de linha e sem a proteção do lock de escrita do terminal; ao rodar vários flower em paralelo, essas linhas podem sair rasgadas.

Como falar com ele durante a run¶

Depois que a run começa, o terminal está o tempo todo lendo o que você digita. Não é preciso esperar uma pergunta nem apertar nada para entrar em modo de entrada — a última linha é sempre a linha onde você pode digitar.

O prompt de entrada fixo embaixo¶

Há uma thread daemon flower-stdin lendo o stdin o tempo todo (cli.py:764-934), usando select com polling a cada 0.2 segundos, não leitura bloqueante (assim o sinal de parada consegue acordá-la; em streams que não suportam select, como no Windows, ela degrada para leitura bloqueante).

Ela lê o tempo todo, não só quando há uma pergunta. A razão é: se só lesse durante as perguntas, o que você digitou nas horas de trabalho ficaria no buffer do terminal e seria engolido como resposta na pergunta seguinte — você seria respondido antes mesmo de ver a pergunta.

Na exibição, _say() é a única saída; antes de cada escrita ele apaga o prompt e redesenha depois (cli.py:309-315), então o prompt nunca é empurrado para cima pela saída de eventos. No redesenho, os caracteres que você digitou pela metade e ainda não deu Enter voltam junto — eles ficam em _PROMPT["buf"] (cli.py:183-192). Sem isso, o conteúdo na verdade não se perde (ainda está no buffer de linha do terminal, e o Enter o envia normalmente), mas você não o vê, fica inseguro e redigita.

O prompt tem dois textos, alternando conforme haja ou não pergunta pendente:

Modo de entrada caractere a caractere e teclas¶

Para redesenhar "os caracteres digitados pela metade", o flower precisa assumir a entrada. Quando o stdin é um terminal e é possível import termios, o terminal é colocado em cbreak antes de iniciar a thread flower-stdin (cli.py:793-807) — usa cbreak e não raw para que Ctrl+C continue gerando SIGINT, mantendo todo o comportamento de Ctrl-C. Tem que ser antes de iniciar a thread: colocar isso dentro da thread cria uma corrida real, e os caracteres digitados no instante em que a thread ainda não pegou CPU são engolidos pelo modo de linha, aparecendo como "a entrada sumiu" (reproduzido de forma estável uma vez a cada três testes, cli.py:928-934).

Se não der para configurar, volta ao readline() de linha inteira (não é terminal, termios indisponível, tcgetattr falhou). Os dois caminhos funcionam, só que no modo de linha as teclas abaixo não existem (cli.py:883-899).

A lógica de edição está em LineEditor (cli.py:320-414), uma máquina de estados pura que não toca no terminal:

O Enter entrega o buffer e o esvazia, além de pular uma linha na tela — o que você disse fica ali em cima (cli.py:811-827).

Para onde vai o que você digita¶

Ao entrar na caixa de entrada, ele imprime um recibo:

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

Quando não há brief onde fazer o spill, a segunda metade vira 没有确认书可落盘 —— 它可能活不过下一个步骤. A caixa de entrada não interrompe o worker que está trabalhando; ele só pega da próxima vez que consultar a caixa por iniciativa própria. A mesma frase também é anexada a notes/需求.md; sem spill, ela não sobrevive à fronteira do step — o próximo step é uma session nova, que só lê os artefatos congelados.

Começar com ? = pergunta ao oracle¶

Uma linha que começa com ? não é enviada ao agent em execução, e sim ao oracle:

? 现在到哪一步了

Ele sobe um Runtime independente, com run_dir em <run_dir>/aside/, então o custo e a lineage de sessions dele não se misturam ao manifest.json principal. O papel é somente-leitura, as ferramentas são apenas Read, Glob, Grep, no máximo 12 rodadas, com teto de custo de $0.5. O contexto que ele vê são os 60 eventos mais recentes (eventos thinking e prompt não entram nessa janela), cada um truncado em 200 caracteres, mais a descrição do caminho do workbench.

Ele roda concorrentemente; a run em andamento não espera um segundo. A resposta é assim:

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

Em caso de falha, imprime uma linha em vermelho # 旁路问答失败:<类型>: <消息>, sem afetar o fluxo principal. Na saída, espera no máximo 120 segundos pelo encerramento do oracle, e antes de esperar imprime uma linha (等 N 条旁路问答收尾…).

O que ele diz não entra no contexto daquela run — perguntar não afeta a run, e a resposta é descartada depois.

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

O que aparece na tela¶

Os ícones são sempre ASCII, não emoji (cli.py:51-69). A razão está no comentário do código: emoji junto com caracteres de moldura, geométricos e setas dispara fallback de glifos no terminal, o que já causou dois travamentos de terminal.

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

Os cinco estados de uma pergunta, na tela, são:

Quando --asks está sem limite (o padrão), a última linha "还能问 N 次" não é exibida.

Quando o handoff termina de escrever o handoff document, sai um bloco inteiro:

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

Quando o handoff document é degradado, entra uma linha vermelha extra 交接没写成,用了降级版本 —— 接手的人会自己去现场看.

A saída também faz duas coisas que você não vê: todas as linhas passam por uma sanitização que só deixa passar os códigos SGR de cor do próprio flower, engolindo por inteiro sequências de limpar tela e mover cursor cuspidas pelo modelo ou pelas ferramentas; e a largura é max(40, min(colunas do terminal, 110)), então em terminais largos o texto não ocupa a linha inteira — isso é intencional.

O prompt na largada¶

Rodando flower puro (sem pedido), ele pergunta antes. Dois textos:

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

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

O segundo só aparece quando este diretório já foi usado e as quatro seções de 需求.md estão completas.

Esse prompt lê via input(), sem passar pelo parsing do shell. Aspas chinesas, espaços e pontos de exclamação podem ser digitados direto — essa é toda a razão de ele existir. O zsh, ao encontrar a aspa direita chinesa, entra em dquote> esperando continuação, o que parece travamento, mas na verdade nada chegou a iniciar.

• Entrada vazia + primeira vez → sai, imprimindo 诉求是空的。直接 `flower` 然后按提示输入,或者 flower "帮我做一个 X"。
• Entrada vazia + wake → é válido, significa "continuar"
• Digitar /new → equivale a --new, arquiva o trecho anterior e pergunta o pedido de novo
• Ctrl-C / Ctrl-D → sai, imprimindo 已取消

Timeout¶

--timeout é float, em segundos, padrão 1800.0. Três faixas de valor:

--timeout 0 e --timeout -1 são completamente equivalentes. Rodar por pipe, em CI ou sem supervisão usa exatamente isso.

Quando a pergunta não obtém resposta, o resultado de ferramenta devolvido ao modelo é um texto fixo, em quatro variantes:

Ctrl-C¶

A semântica do Ctrl-C nos dois lugares é completamente diferente.

Apertado no prompt de largada > — sai do programa direto, imprimindo 已取消.

Apertado no meio da run — interrompe a rodada atual e te dá uma chance de falar:

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

Dar Enter direto aqui significa apenas interromper sem dizer nada e seguir. Se houver perguntas pendentes no momento, sai uma linha a mais: (有 N 个提问还等着,打断不影响它们).

Apertar Ctrl+C outra vez é sair de verdade, e é um KeyboardInterrupt não capturado — vai aparecer um traceback de Python na tela, não é uma saída limpa.

A interrupção é cooperativa: corta de forma limpa na fronteira de mensagem, sem cancelar tarefas à força. Ela não conta como tentativa falha e não consome retentativas. Ao continuar, é anexada uma explicação dizendo ao modelo que "chamadas de ferramenta em voo retornando interrupted é um efeito colateral normal da interrupção, não uma falha de ambiente".

Esse Ctrl-C customizado só é instalado quando sys.stdin.isatty() (cli.py:1097). Rodando por pipe, mantém o comportamento padrão do Python, ou seja, sai já na primeira vez. O caminho do once não passa por aqui, então o Ctrl-C no once também sai já na primeira vez.

SIGHUP / SIGTERM¶

Os caminhos go e run instalam tratamento para SIGHUP e SIGTERM: primeiro gravam também o step em voo no manifest.json, marcado como killed-by-signal, depois restauram a ação padrão e realmente saem.

A origem disso é que, quando o terminal trava, o kernel manda SIGHUP, cuja ação padrão encerra o processo direto: o finally não roda, o manifest não é gravado — e a contabilidade daquela run se perde. Em threads que não são a principal do sistema operacional, ou em plataformas sem suporte, isso é pulado silenciosamente.

Fluxo de configuração na primeira execução¶

As três portas de entrada go, run e once chamam ensure_credentials() logo no começo (cli.py:1392-1428), com duas barreiras.

Primeira barreira: existe credencial?¶

Procura credenciais por ordem de prioridade. Se não achar ANTHROPIC_API_KEY nem ANTHROPIC_AUTH_TOKEN, inicia a configuração interativa; em modo não interativo (stdin não é terminal), não bloqueia, imprime este bloco e sai:

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

Este texto tem dois pontos que não batem com a implementação: o flower setup da segunda linha hoje é inalcançável (veja setup); e a quarta linha contradiz o código — o flower de fato usa o bloco env de ~/.claude/settings.json e settings.local.json como último nível de fallback, pegando emprestado apenas 9 chaves de credencial dali, sem assumir nenhuma outra configuração. O lugar que imprime essa linha é env.py:192 (a função check_credentials() está definida em env.py:184), enquanto quem realmente lê esses dois arquivos é env.py:56-75 e :109-111; registrado na issue #13. Vale o código: ele lê. A ordem completa de busca e as 9 chaves estão na referência de configuração.

O que a configuração interativa pergunta¶

== 配置 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

• A pergunta 1 é obrigatória. Deixar em branco imprime em vermelho 没给 token,取消。 e a configuração é abandonada.
• As perguntas 2 e 3 podem ficar em branco.
• Quando o stdin não é terminal, todo o fluxo é pulado, sem bloquear.

As chaves que ele grava¶

O caminho do arquivo é ${XDG_CONFIG_HOME:-~/.config}/flower/.env, e o diretório pai é criado automaticamente. A escrita é sobrescrita integral, chaves com valor vazio são puladas, e ao terminar faz chmod 0600 e carrega na hora — não precisa reabrir o shell. A primeira linha é sempre um comentário lembrando de não versionar o arquivo.

Segunda barreira: a credencial funciona?¶

Com a configuração completa, imprime uma linha - 验一下凭证… e então dispara uma chamada real à API.

Detalhes da sonda: POST {BASE_URL}/v1/messages, max_tokens=16, timeout padrão de 20 segundos, via urllib da stdlib, sem trazer dependências. O modelo é escolhido na ordem ANTHROPIC_DEFAULT_HAIKU_MODEL → ANTHROPIC_MODEL → claude-3-5-haiku-20241022. Havendo ANTHROPIC_API_KEY, usa o header x-api-key; caso contrário, authorization: Bearer <ANTHROPIC_AUTH_TOKEN>.

max_tokens é 16 de propósito, e não 1: em testes, modelos com cadeia de pensamento forçada não cabem nem o pensamento, e o servidor demora até 30 segundos para responder; com 16, leva só 3.6 segundos.

A conclusão da sonda é tratada em três classes, e a diferença importa:

O critério de config foi apertado: em JSONs de erro no estilo da Anthropic, a palavra model aparece quase sempre, e usá-la como "nome de modelo errado" transformaria um 400 transitório em erro de configuração e forçaria uma reconfiguração — só vale quando a resposta diz explicitamente "não encontrado / não existe" (env.py:176-182).

O net é intencional: uma oscilação de rede não deve forçar você a redigitar o token, e o próprio flower tem mecanismo de suspender e reconectar em queda de rede. Ao ver "探针没打通", ignore e siga.

A chance de reconfiguração é dada no máximo uma vez. Se falhar de novo na segunda, sai.

A sonda só é disparada em terminal interativo. ensure_credentials() retorna direto, sem essa chamada à API, se qualquer uma destas condições valer (cli.py:1413): quem chamou passou probe=False, FLOWER_NO_PROBE está setado, ou o stdin não é terminal (pipe / CI / testes offline). O motivo é que, sem interatividade, descobrir o problema não permite consertá-lo, e o único efeito seria "falhar mais cedo" — e falhar mais cedo, em caso de falso positivo, é pior do que não sondar. Se a credencial for realmente ruim, a run vai explodir sozinha, e esse caminho é capturado pela reconfiguração automática depois de uma falha.

Reconfiguração automática depois de uma falha¶

Quando o workflow falha, o flower pega a mensagem de erro do step que falhou e a compara com uma regex (401, invalid api key, authentication, unauthorized, 无效…key/token/密钥). Se casar e o stdin for um terminal, ele imprime na hora ! 看起来是凭证不对:<前 120 字> e inicia a configuração interativa; ao terminar, imprime:

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

E depois sai com código de saída 1 de qualquer forma. O caminho do once não tem essa parte.

Códigos de saída¶

Todas as mensagens do código de saída 1:

Ao terminar (caminhos go / run), imprime uma última linha:

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

Esse valor conta apenas o gasto deste processo, sem incluir a run anterior — ainda que o próprio arquivo de manifest acumule entre processos.

O que ele cria no projeto¶

Duas árvores: <run_dir>/ (padrão ./runs/, relativo ao CWD) guarda a contabilidade e as sessions; <workspace>/.flower/ guarda o workbench.

runs/¶

Campos de cada registro do 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 é a marca deste processo, no formato YYYYmmdd-HHMMSS-<6 dígitos hex>. A política de gravação é anexar sem sobrescrever: antes de cada escrita, relê o arquivo e deduplica por run — as linhas deste processo são substituídas pelas mais recentes, e as linhas de outros processos ficam como estão.

Os nomes de step têm quatro formatos:

Quando morre por sinal, o step em voo também é gravado, com o campo error valendo killed-by-signal.

Vários flower em paralelo no mesmo diretório: o manifest.json é seguro (relê e mescla por run), mas o lineage.json é sobrescrito por inteiro, e dois processos vão apagar a lineage um do outro para steps de mesmo nome. Para rodar em paralelo, use -r diferentes.

O lineage.json guarda o caminho absoluto do workspace. Se não bater, é tratado como inexistente e o sistema volta silenciosamente para uma session nova, sem erro — depois que o diretório é copiado para outro lugar, o session_id antigo não seria encontrado mesmo.

.flower/¶

O caminho do go gera sempre estes arquivos sob notes/:

Com --isolate, o workbench é movido para fora do repositório: <workspace>.parent/.flower-<nome do workspace>/. O worktree é a cópia privada de cada agent, e o workbench é a camada compartilhada entre agents; o que é compartilhado não pode ficar dentro de uma cerca privada. Nesse caso, o caminho do workbench passado ao modelo é absoluto.