Pilar Reservas baseline 13/08/2026última revisão técnica 19/08/2026

+ 1 workflow próprio ARQUIVADO, fora da contagem de ativos · +2 relacionados sem dono

Boss Reservas · 16 workflows próprios ATIVOS = 10 esteira + 3 proteção + 3 gestão · tópico 41

Por que 18 e 17 aparecem juntos: O pilar tinha 18 fluxos classificados em cockpit.flows e 17 com dono. Em 18/08 a Conferência — Régua Única foi ARQUIVADA (zero chamadores), então os PRÓPRIOS ATIVOS passaram a ser 16 (10 esteira + 3 proteção + 3 gestão). O 18º é a Média Semanal, ambígua e sem dono. Lembretes está classificado em Concierge, não aqui.

Reservas = processo de AUTORIZAÇÃO da reserva. Não confundir com Concierge, que é venda de ingressos e upsell. O prefixo [reserve] nos nomes é legado do produto, não indica o pilar.

A jornada

Stays (webhook) → Reservas (Stays webhook) → Notion → mensagem ao hóspede
   ↓
Form Página Dados ← hóspede preenche titular + acompanhantes
   ↓
Voucher I → Dados Recebidos
   ↓
Conferência de Dados → confere cardinalidade e valida contra o Stays
   ├─ falta dado → Dados Incompletos → mensagem Corrigir → volta ao formulário
   └─ dados completos → mensagem Confirmar / Corrigir ao hóspede
   ↓
o hóspede clica Confirmar — sem clique, a reserva fica aguardando
   ↓
Transição Confirmação Hóspede → gate de cardinalidade
   ↓
Voucher II → gate interno → PDF → proprietário assina
   ↓
Intake WA→TG → Callback → Voucher III → hóspede

REGRA OFICIAL — CONFIRMAÇÃO DO HÓSPEDE É OBRIGATÓRIA PARA AVANÇO.
Sem clique em Confirmar, a reserva não avança: fica aguardando. Não existe fast-forward automático. O pior caso passa a ser atraso operacional, nunca autorização emitida sem confirmação.
19/08/2026 — hgZCsm2EFg2aWbvY Auto-Continuidade foi desativada e arquivada. Ela media o timeout por last_edited_time, e relógio não prova que a confirmação foi enviada: card cuja mensagem nunca saiu avançava do mesmo jeito. Redesenho fica para a migração Supabase, com confirmation_sent_at.

Esteira — movimentam a reserva

workflow	id	posição / papel
Reservas (Stays webhook)	`gqo5d5DfH242Q5hd`	porta de entrada — nova reserva
Form Página Dados	`6JjzvJQqtlTxS1vX`	coleta titular + acompanhantes
Voucher I	`me2kReWzbjo30YAv`	recebe form → Dados Recebidos
Conferência de Dados	`lweuc1GnINcdFxl4`	valida contra o Stays, escala
Transição Confirmação Hóspede	`tTekTbVcufKEDh21`	confirma/corrige → dispara Voucher II
Voucher II	`yPsoGuuHV1loA3Cb`	gera PDF → proprietário
Voucher Intake · WA→TG	`sv6OpQyMJptu0rJC`	recebe PDF assinado
Voucher Intake · Callback	`NrdKR2f9FdQjFXp1`	botão TG → dispara III
Voucher III	`BpzDzZg9R7Lf7mC1`	entrega ao hóspede
Sync Reservas	`fBJ653L6xjvTya3x`	inativo · tag arquivado-2026-08-08

Proteção — vigiam, não movimentam

workflow	id	posição / papel
Sentinela Reservas Stays	`riIM7yPFr8FAC4hO`	divergência Stays ↔ Notion, 30min
Auto-Continuidade Dados Recebidos	`hgZCsm2EFg2aWbvY`	destrava paradas em Dados Recebidos
Guardião Fluxo Hóspede	`ohifEOZP6BQcFd2h`	sonda /r/confirmar

Gestão — resumem para o Boss

workflow	id	posição / papel
Boss · Brief Diário	`hOrJZYeFbMXfoC9s`	cron 9h BRT seg-sex
Brief Diário Pin Reservas	`tf03cwdDXPV6HkJ1`	8h plano + 19h resumo, com pin
Mesa de Reservas · Digest	`nXzBBwL6JYgGcWbP`	30min, 8h–21h

Arquivados — saíram da jornada ativa

workflow	id	posição / papel
Conferência — Régua Única	`hLQdB0pEX33hMOU0`	ARQUIVADO 18/08 · zero chamadores · régua canônica passou a ser a inline da Conferência de Dados

Histórico preservado: ficha e snapshot continuam no Git. Abrir ficha completa →

Relacionados / ambíguos — fora da contagem

workflow	id	posição / papel
Lembretes	`7ughJgkYr9ap7mYc`	classificado no Pilar Concierge (control plane) · fora dos 17 proprios · religado em 13/08
Boss Reservas · Média Semanal	`fahZeQNIVWpSAnxd`	segunda 8h · sem Boss no control plane (owner_agent nulo)

Sem ownership até a função ser lida. Não entram na contagem do pilar.

Já revisados — clique para abrir a ficha completa

[reserve] Reservas (Stays webhook) FINALIZADO revisado 2026-08-17

O dono da RESERVA. Recebe o evento do Stays e mantém o card do hóspede, a disponibilidade do imóvel e os avisos de nascimento e cancelamento. É quem cria o card; todo o resto da esteira trabalha em cima do que ele criou.

trigger: Webhook do Stays (POST) — reservation.created / modified / canceled / deleted · frequência: a cada evento de reserva no Stays
última prova: EXECUÇÃO REAL — 881346 · 17/08 16:17
IA: NÃO · Boss: Boss Reservas

ABRIR FICHA COMPLETA — NÓ A NÓ (12 nós documentados) →

[reserve] Voucher I FINALIZADO revisado 2026-08-17

Recebe o formulário preenchido pelo hóspede e GRAVA no card do Notion. É a autoridade sobre os dados do hóspede a partir do momento em que ele preenche: o Stays só semeia no created, daqui em diante manda o que veio da página.

trigger: Webhook POST /voucher-parte1-dados-hospede — chamado pelo Form Página Dados · frequência: sob demanda — a cada envio de formulário
última prova: EXECUÇÃO REAL — 876841 · 16/08 20:22 · rota A
IA: NÃO · Boss: Boss Reservas

ABRIR FICHA COMPLETA — NÓ A NÓ (33 nós documentados) →

[reserve] Form Página Dados FINALIZADO revisado 2026-08-19

O BACKEND da página de reserva. Serve o estado da reserva para a página montar a tela, valida o formulário quando o hóspede envia, e recebe o toque no botão 'quero ficar mais dias'. É consumido pelo Worker do Cloudflare, que faz proxy same-origin para o n8n não ficar exposto.

trigger: 3 webhooks independentes: /form/reserva-info · /form/reserva-submit · /form/estender · frequência: sob demanda — sempre que um hóspede abre ou envia a página
última prova: EXECUÇÃO REAL — 882121 · 18/08
IA: NÃO · Boss: Boss Reservas

ABRIR FICHA COMPLETA — NÓ A NÓ (11 nós documentados) →

[reserve] Conferência de Dados FINALIZADO revisado 2026-08-18

A RÉGUA DE COBRANÇA. Todo dia útil varre os cards que ainda devem dados, confere cada um contra a régua canônica, cobra o hóspede pelo WhatsApp em até 3 tentativas e transforma silêncio prolongado em pendência vermelha na Mesa.

trigger: Cron 0 9 * * 1-5 (America/Sao_Paulo) + execução manual + webhook de teste · frequência: uma vez por dia útil, 9h BRT
última prova: EXECUÇÃO REAL — 886124 · 18/08 12:00Z (09:00 BRT) · sucesso em 15s
IA: NÃO · Boss: Boss Reservas

ABRIR FICHA COMPLETA — NÓ A NÓ (33 nós documentados) →

[reserve] Conferência — Régua Única FINALIZADO / ARQUIVADO revisado 2026-08-18

Função pura de conferência: recebe uma reserva e devolve a lista de problemas nos dados, sem escrever nada em lugar nenhum. É a implementação literal da seção 1 do ESTEIRA_RESERVAS_RULEBOOK — a régua que decide se um card pode avançar para o proprietário.

trigger: Execute Workflow Trigger (sub-workflow) + webhook de teste /webhook/regua-unica-test · frequência: sob demanda — e desde 18/08, nunca: zero chamadores
última prova: PROVA ESTÁTICA — o workflow está arquivado; a última execução é de 14/08 e foi manual
IA: NÃO · Boss: Boss Reservas

ABRIR FICHA COMPLETA — NÓ A NÓ (3 nós documentados) →

Alertas conhecidos — revalidar workflow a workflow

AUDITORIA DA ESTEIRA (13/08 15h BRT) INCORPORADA — cópia em evidencias/auditoria-esteira-reserve-2026-08-13.html
Voucher I: a alteração das 18:41 UTC = 15:41 BRT foi um P0 CORRIGIDO pela própria auditoria — parou de devolver erro falso (HTTP 500) ao hóspede.
Form Página Dados: erro falso ao hóspede — segundo P0, corrigido 15:47 BRT.
Lembretes é a ÚNICA peça de cobrança recorrente da esteira, e foi desligado na varredura de 08/08 junto com campanhas descartáveis. Ficou 5 dias sem cobrar hóspede nem proprietário. Religado em 13/08.
Pendente Assinatura: cobrança PAUSADA em 13/08 — a régua não distinguia quem não assinou de quem já mandou ao resort, e cobrava os dois.
Enviado ao Resort: status CRIADO em 13/08 para separar a dívida do proprietário da dívida do resort. Por isso não constava nas listas anteriores.
Dados Incompletos: dono é a Conferência de Dados. Cobrança NENHUMA — o status está fora da consulta do Lembretes. Card aqui não recebe mensagem.
288 erros/dia afogando o canal de alerta — 7 achados abertos na auditoria.
Reservas (Stays webhook): IMOVEL_NAO_ENCONTRADO NAO era erro de dado, como se dizia aqui. Provado em 17/08 (OU06J): o reservation.canceled chega SEM childs, o _idlisting raiz e o PAI/FAKE que por desenho nao existe em Imoveis, e o codigo o lia como single-unit. CORRIGIDO em 17/08 — no cancelamento o imovel vem dos CARDS, nao do payload.
Voucher I ramo A: 'Boss Reservas · msg (Dados Recebidos)' e ORFAO DE PROPOSITO. Dados Recebidos normal nao e material (Silent by Default); o hospede recebe WhatsApp e o Boss corretamente nao recebe nada. Em 17/08 ligou-se ao Concierge um evento NOVO e material: upsell de hospedes adicionais.
status_autorizacao tem SEIS escritores — risco POTENCIAL, não conflito provado.
Tags normalizadas em 17-18/08: os 67 ativos do escopo tem empresa/pilar/boss/workplace. Media Semanal segue SEM BOSS no control plane (cockpit.flows.owner_agent nulo) — a tag nao substitui o cadastro. Lembretes esta em Concierge no control plane e marcado morto, mas segue ATIVO no n8n: divergencia a resolver.
CANCELAMENTO — IMPLEMENTAÇÃO: reserva cancelada leva a disponibilidade de volta para Disponível. DEFINIDO E PROVADO; desde 17/08 o imóvel vem dos CARDS, então reserva dividida também libera.
Kuma: sem acesso admin. SEMÂNTICA DEFINIDA — Kuma mede SAÚDE TÉCNICA, não atividade comercial: ausência de reserva é NEUTRA, nunca DOWN. Nada de timeout de venda.
CANCELAMENTO — POLÍTICA: a mensagem automática ao hóspede NÃO é regra canônica. Em 13/08 foi restaurado um Template 4 que já existia e nunca disparava. Manter ou não é decisão do Rafael, ainda não tomada.
CANCELAMENTO — PROPRIETÁRIO: avisar que a cota/período voltou a ficar disponível continua PENDENTE.
RESOLVIDO 19/08: Auto-Continuidade Dados Recebidos foi desativada e arquivada. Ela movia Dados Recebidos → Envio ao Proprietário medindo timeout por last_edited_time, sem prova de que a confirmação tinha sido enviada. Saiu da jornada; a confirmação do hóspede passa a ser obrigatória.

Próximo na esteira: hgZCsm2EFg2aWbvY — Auto-Continuidade Dados Recebidos.

Fonte única: dados-rental-reserve.json · gerado por scripts/gerar-rental-reserve.py.
CORTE 13/08/2026 · última atualização técnica 2026-08-19 14:45 UTC. Corte ≠ runtime ao vivo.