ÍNDICE Rental / Reserve mapa da operação Pilar Reservas SOL · SDR

[reserve] Form Página Dados

6JjzvJQqtlTxS1vX · FINALIZADO · ativo · 11 nós

Identidade

campo	valor
nome	[reserve] Form Página Dados
id	`6JjzvJQqtlTxS1vX`
estado no n8n	ativo
empresa	reserve-temporada
pilar	Reservas
boss	Boss Reservas
workplace	FINALIZADO
IA	NÃO
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
nós · conexões	11 · 10
tags	audit:revisado · workplace verificado · boss:reservas · empresa:reserve · pilar:reservas
abrir no n8n	https://n8n.rbrtecnologia.com.br/workflow/6JjzvJQqtlTxS1vX

Papel

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.

começa quando

Quando o Worker chama um dos três endpoints /api/… em nome do navegador do hóspede.

termina quando

Ao responder o webhook. A telemetria roda DEPOIS do Respond, para não atrasar a página.

o que NÃO faz

Não renderiza HTML — quem desenha a página é o Worker.
Não decide autenticação: hoje devolve sempre auth_method=publico.
Não grava os dados do formulário no Notion — isso é o Voucher I.
Não movimenta status da reserva.
Não redireciona pós-checkout (é do Worker) — mas RECUSA a escrita.

posição na jornada

Entre o Worker (interface) e o Voucher I (gravação). É a terceira das quatro peças da jornada da página.

Mapa nó a nó — ordem real de execução

#	nó	tipo	recebe	regra / condição	lê	escreve / efeito	saída	próximo	em falha
1	WH Info	webhook	GET /form/reserva-info?rid=	sempre	query.rid	—	query	Code Info	HTTP 500
2	Code Info	code	query do webhook	rid tem que casar ^[A-Z0-9]{4,12}$; senão devolve rid_invalido	Notion data_source Hóspedes: todos os cards com aquela Reserva Stays · página do imóvel (Tipo de Resort, Dormitório)	NADA no Notion — só lê	{ok, rid, page_id, status, etapa, canal, resort, segmentos, dividida, capacidade, cap_confiavel, cap_motivo, capacidade_max, qtd_contratada, qtd_informada, vagas_livres, pode_incluir, pos_checkout, auth_method, prefill, titular (PII zerada), acompanhantes (sem CPF)}	Respond Info	exceção na leitura do imóvel cai em cap_motivo='excecao:…' e a capacidade degrada para 5
3	Respond Info	respondToWebhook	saída do Code Info	sempre	—	responde o hóspede	JSON para o Worker	Code · Telemetria	—
4	WH Submit	webhook	POST /form/reserva-submit	sempre	body	—	body	Code Submit	HTTP 500
5	Code Submit	code	body do formulário	1) rid e nome do titular obrigatórios; 2) se não conseguiu LER os cards → recusa; 3) se o maior checkout já passou → recusa; 4) se informados > capacidade → recusa	Notion: cards da reserva (capacidade, Check-out) · página do imóvel	POST no webhook do Voucher I com o payload em formato LABELS · PATCH Hospede N_CPF em TODOS os cards da reserva	{ok, voucher1_status, cpf_patch, capacidade, informados, cap_confiavel} ou {ok:false, error}	Respond Submit	falha do Notion vira recusa validacao_indisponivel — não grava às cegas
6	Respond Submit	respondToWebhook	saída do Code Submit	sempre	—	responde o hóspede	JSON	Code · Telemetria	—
7	WH Estender	webhook	POST /form/estender	sempre	body.rid	—	body	Code Estender	HTTP 500
8	Code Estender	code	body com rid	rid válido e reserva existente	Notion: cards da reserva (nome, telefone, datas, canal, Hospede 2–8)	WhatsApp ao Rafael pela sessão WAHA Reserve	{ok, rid, msg_id}	Respond Estender	ok=false se o WAHA não devolver id
9	Respond Estender	respondToWebhook	saída do Code Estender	sempre	—	responde o hóspede	JSON	Code · Telemetria	—
10	Code · Telemetria	code	qualquer um dos três Respond	try/catch em toda leitura upstream: nó que não rodou lança em n8n	saída do ramo que executou	—	{rota, rid, sucesso, resultado}	HTTP · Execution Log	nunca derruba — é o motivo do try/catch
11	HTTP · Execution Log	httpRequest	saída da Telemetria	sempre	—	RPC cockpit_execution_log no Supabase Workplace	confirmação com boss, pilar e uses_ai resolvidos pelo control plane	fim	onError=continueRegularOutput — telemetria não derruba operação

Ramos

WH Info ──→ Code Info ──→ Respond Info ─────┐
WH Submit ─→ Code Submit ─→ Respond Submit ─┼─→ Code · Telemetria ─→ HTTP · Execution Log
WH Estender → Code Estender → Respond Estender ┘

Os três ramos são INDEPENDENTES: exatamente um roda por execução.

Dentro do Code Submit, as recusas em ordem:
├─ rid ou nome ausente → dados_incompletos
├─ não consegui LER os cards → validacao_indisponivel (fail-closed, 18/08)
├─ maior checkout já passou → pos_checkout (zero writes, 18/08)
├─ informados > capacidade → acima_capacidade (rejeita, não trunca)
└─ tudo ok → Voucher I + PATCH dos CPFs

Dados e autoridade

campo	autoridade	quem escreve	quando	quem NÃO sobrescreve
nome · CPF · RG · nascimento · e-mail · telefone · endereço	página / Voucher I	Voucher I, a partir do que este workflow repassa	no submit do formulário	o Stays no reservation.modified NÃO sobrescreve
Hospede N_CPF	este workflow	Code Submit, PATCH direto	no submit — o Voucher I não carrega esses campos	—
capacidade	matriz canônica por resort+tipologia	ninguém escreve — é derivada do imóvel	calculada a cada chamada	o cliente não pode informar: o backend recalcula do zero
qtd_contratada	Stays, via gqo5d5 no created	gqo5d5	na criação do card	este workflow só lê
check-in · check-out · canal · imóvel · valor	Stays	gqo5d5	created/modified	o formulário NÃO altera — são campos estruturais da reserva

Status

aspecto	detalhe
status lidos	Status Autorização de Reserva de todos os cards da reserva
status escritos	NENHUM — este workflow não movimenta a esteira
mapeamento de etapa	Reserva/Dados Recebidos → dados · Envio ao Proprietario/Pendente Assinatura/Enviado ao Resort/Problemas Disponibilidade → aguardando · Voucher Enviado Hospede/Aguardando Transferência/Repasse Autorizado/Concluido → pronto · Cancelado → cancelado
reserva dividida	a etapa é o MÍNIMO entre as pernas vivas — a reserva só está pronta quando TODAS estão
status desconhecido	fail-closed desde 18/08: vira aguardando, NUNCA dados. A reserva não retrocede.
pós-checkout	pos_checkout=true no Info; recusa de escrita no Submit

Comunicações

público	identidade	canal	nó	condição	dedup	texto validado	conteúdo	materialidade
Rafael	Reserve (sessão do hóspede)	WhatsApp	Code Estender	hóspede tocou em 'quero ficar mais dias'	nenhuma — cada toque manda	NÃO	reserva, hóspede, estadia atual, nº de hóspedes, canal e wa.me do hóspede	material — é oportunidade comercial

Integrações

sistema	papel exato
Notion	leitura dos cards e do imóvel; PATCH apenas dos CPFs de acompanhante
Voucher I	POST no webhook /voucher-parte1-dados-hospede com o payload em formato LABELS
Workplace	RPC cockpit_execution_log — telemetria, credencial Supabase Workplace service_role
WAHA Reserve	envio ao Rafael no ramo Estender
Cloudflare Worker	consumidor dos três endpoints; faz proxy same-origin e mascara. É a peça EM ANÁLISE
Supabase Rental	NÃO SE APLICA
Telegram	NÃO SE APLICA
Kuma	NÃO SE APLICA
sub-workflows	nenhum

Reserva dividida

SIM, e em três lugares: o Info devolve o período GLOBAL (min check-in → max check-out) e a lista de segmentos; a etapa é o mínimo entre as pernas; e o Submit patcheia os CPFs de acompanhante em TODOS os cards da reserva, não só no da URL.

Idempotência e deduplicação

Info é leitura pura: repetir não muda nada.
Submit é idempotente no Notion (PATCH do mesmo valor), mas cada envio dispara o Voucher I de novo — a idempotência real mora lá.
Estender não deduplica: cada toque manda um WhatsApp ao Rafael.

Tratamento de falhas

Notion ilegível no Submit → recusa validacao_indisponivel, zero escrita (18/08).
Notion ilegível no Info → capacidade degrada para 5 com cap_motivo, nunca inventa vaga.
Execution Log com onError=continueRegularOutput: telemetria não derruba a resposta ao hóspede.
Sem errorWorkflow configurado.

Alterações feitas na auditoria

data	defeito anterior	consequência	correção	evidência	tocou negócio?
17/08	o webhook /form/reserva-info é público e sem auth e devolvia CPF, RG, nascimento, e-mail, telefone e endereço do titular	o mascaramento do Worker era contornável: bastava chamar o n8n direto. rid enumerável, ~830 hóspedes com CPF e RG	chaves preservadas, valores zerados + auth_method e prefill explícitos	testado nos dois caminhos: PII preenchida = NENHUMA	sim — mas o navegador já recebia vazio, então o hóspede não perdeu nada
17/08	o Code Submit não repassava o sinal de remoção de acompanhante	o Voucher I sabia tratar remove_hospede_N desde 14/08 e nunca recebia	repassa remover_hospedes[] e remove_hospede_N	cadeia completa do webhook ao Notion	sim
17/08	sem telemetria	execução não registrada no Workplace	Code · Telemetria → HTTP · Execution Log, depois dos Respond	execução 882121 · log id=502 · boss=Boss Reservas	não
18/08	'Enviado ao Resort' e 'Problemas Disponibilidade' não estavam no mapa de etapa	caíam em 'dados': a página mandava o hóspede preencher tudo de novo numa reserva já no resort. Em reserva dividida, UMA perna desconhecida puxava a reserva inteira	mapeados + default fail-closed (só status iniciais valem 'dados')	OI01J: dados → aguardando; NM03J e MJ06J seguem pronto; OQ11J segue dados	sim
18/08	a API não expunha qtd_contratada	a página não tinha como separar contratada de informada de capacidade — daí 'Ocupação: 2 de 5'	expostos qtd_contratada, qtd_informada, capacidade_max, vagas_livres, pode_incluir	NR02J: 5/1/5, vagas 0, pode_incluir false	sim
18/08	submit gravava mesmo pós-checkout; e falha do Notion era engolida	reserva encerrada aceitava alteração; e uma queda do Notion pularia o próprio guard	recusa pos_checkout e validacao_indisponivel, com a data vinda do CARD	offline com o JS do PROD: NG01J recusa, NR02J segue, Notion fora recusa — zero escrita	sim

Prova

EXECUÇÃO REAL

item	valor
execução	882121 · 18/08
rota	info · rid=MJ06J
resultado registrado	etapa=pronto cap=6 cap_confiavel=true dividida=false auth=publico
efeito verificado	cockpit_execution_log id=502 · boss='Boss Reservas' · pilar='Reservas' · uses_ai=false
ownership	não afirmado por mim — veio da resposta do Workplace
testes ao vivo depois dos fixes	NR02J 5/1/5 pode_incluir=false · OI01J 4/4/5 pode_incluir=true · NG01J pos_checkout=true

Limites — o que NÃO é defeito deste workflow

item	camada	estado
admin abrir sem CPF	Worker	não implementado — o Worker não repassa o IP do cliente
exibir os três números	Worker	backend pronto desde 18/08; falta consumir
redirect pós-checkout	Worker	não implementado — GET /NG01J devolve 200 e renderiza
botão 'Remover acompanhante'	Worker	backend pronto; front não emite o sinal
reconciliar worker.js repo ↔ deploy	Worker	BLOQUEIO EXTERNO — sem credencial Cloudflare
3 tokens do Notion + 1 chave WAHA literais	hardening transversal	PENDENTE

Veredito

FINALIZADO — O backend faz o que promete e os P0/P1 encontrados foram fechados e testados; o que falta é tudo da borda Worker, que é peça própria e está EM ANÁLISE.

Fonte: estrutura-workflows.json (definição viva do n8n PROD, sanitizada) + fichas-detalhe.json · gerado por scripts/gerar-fichas.py. Nenhum token, senha ou PII nesta página.