[fm1randa]

O que mudou

Itens de prioridade média do dogfooding de 2026-10-16 ("Lançamentos e séries", aprovados pelo Filipe às 10:08 BRT) sobre entries create e entries update:

1. entries create -T transfer --to-account <conta>: antes a transferência saía com transferencia: false fixo e sem conta de destino (create.ts:155,212). Agora vai como no web: um lançamento só, do lado da origem (valor negativo), com contaOrigem/contaDestino (sem conta), transferencia: true e valorT/valorPrevistoT/valorEfetivoT espelhando o valor. Sem -c, usa a categoria de sistema de transferência (tipoL 15), como o web. Recusa a mesma conta nos dois lados, --to-account em despesa/receita, transferência de/para cartão (pagamento de fatura tem datas e plastico que a CLI ainda não modela) e entre moedas diferentes.
2. Série parcelada: --installments <n> (ou -i) gera agenda.repeticao: "p" com parcelas ({valor, data}) calculadas como a opção padrão do web: total ÷ n arredondado ao centavo, e a 1ª parcela fica com a diferença (100 em 3 = 33,34 + 33,33 + 33,33). --per-installment faz --value ser o valor de cada parcela; --repeat/--frequency definem o espaçamento (padrão mensal, a cada 1); --first-installment vai em agenda.inicial. Meses e anos fazem clamp do dia (31/jan → 28/fev), como o moment.add do web. --frequency + --times deixaram de ser mutuamente exclusivos na série fixa.
3. Agendado: entries create --scheduled (-S) e entries update --scheduled mandam status: {confirmado: false, conciliado: false}, conciliado: false, dataEfetiva: null e valorEfetivo: null (no update de transferência também valorEfetivoT: null), que é o que o formulário do web envia com Confirmado e Conciliado desligados. Combinações conflitantes (--scheduled + --pending/--reconciled, --scheduled em cartão) são recusadas antes de chamar a API.

Refactor para caber no max-lines: resolveCardDueDate → entries/card-invoice.ts; parse de repetição/parcelas → entries/schedule.ts; validação da transferência → entries/create-transfer.ts; payload de transferência do update → entries/update-transfer.ts. addInterval novo em lib/dates.ts.

De onde vieram os formatos

Do bundle público https://cdn.meudinheiroweb.com.br/js/md.js (mesmo método do #69), sem nenhuma chamada à conta real:

• save do formulário de lançamento (nt/st): transferência → delete conta, transferencia = true, contaOrigem/contaDestino; valor negativo para tudo que não é receita;
• ut() + St(): cálculo das parcelas (resíduo na 1ª), valor/valorPrevisto = total, valorEfetivo = 1ª parcela quando confirmado;
• $(): não confirmado → dataEfetiva = null, valorEfetivo = null, conciliado = false;
• W(): categoria padrão da transferência = tipoL == 15.

Precisa de confirmação do Filipe (numa conta/lançamento de teste)

• Transferência: o web só preenche valorT pelo template (que não é público); a CLI manda valorT = |valor|, coerente com o PUT de transferência que já funciona (entries update falha (400) em transferências (tipo t) #15/test(entries): cobertura de update de transferência e installment #53). Confirmar que as duas metades aparecem com o valor certo.
• --first-installment: o web manda agenda.inicial e continua mandando quantidade parcelas; não dá para saber pelo bundle se o servidor cria todas ou só a partir da inicial. O padrão (1) é igual ao web; a flag é opt-in.
• Série fixa com --times (comportamento antigo, não mudou): o web manda quantidade: -1 + quantidadeFixa: N para "fixa com quantidade definida"; a CLI continua mandando quantidade: N. Vale confirmar se o servidor respeita.
• Semanal: o código w já era usado pela CLI; o web tem um rótulo para s ("semanas"). Não mudou aqui.

Como foi verificado

• Testes novos que assertam o payload enviado ao mock e a saída: test/entries-create-series.test.ts (transferência, parcelada, fixa com --frequency + --times, agendado e recusas sem chamar a API), test/entries-update-scheduled.test.ts (update --scheduled em despesa e transferência) e addInterval em test/dates.test.ts com datas literais.
• scripts/mock-api.ts: rota GET /v1/cadastros/categorias, conta poupança 1004, e o POST /v1/lancamentos passa a recusar com 400 transferência sem contaOrigem/contaDestino (ou com conta), parcelada cuja soma das parcelas não bate com valor, e agendado com dataEfetiva/valorEfetivo.
• scripts/verify.sh: 7 passos E2E novos (transferência, transferência sem destino, parcelada JSON/texto, fixa --frequency + --times, create e update agendado).
• scripts/verify.sh local → VERIFICAÇÃO OK (162 testes pass / 0 fail).

Refs: dogfooding 2026-10-16 — Lançamentos e séries (itens entries create -T transfer, série parcelada e agendado).