Agendar contra o mundo real

O problema

Marcar horário parece trivial até o mundo real chegar: falta, convênio que muda o que aquele horário significa, profissional com habilidade e agenda próprias, buffer entre um atendimento e outro, e uma agenda que ainda precisa dar lucro. E tem a parte que ninguém espera: conta de data não dá pra confiar no modelo. Pergunta que dia cai a próxima terça perto da virada do mês e ele erra com toda a confiança.

As restrições

• 01Quem é dono da agenda é o servidor. Dia da semana e data se resolvem em código; o agente diz a intenção e o servidor transforma isso num horário real.
• 02Perguntar as restrições antes de marcar. Convênio, profissional, duração. Horário marcado em cima de suposição errada é falta esperando pra acontecer.
• 03Respeitar buffer e duração por oferta. Um buffer de 15 minutos que ninguém vê na tela continua tendo que ser real no motor.
• 04Manter lucrativo. Horário não é tudo igual: a agenda precisa poder reservar, limitar e priorizar por valor, e não só por "está livre".

A arquitetura

O bug do "horário errado" era uma cadeia de quatro, e pra matar ele eu tive que matar a ideia de que o agente devia raciocinar sobre data. Ele não escolhe número de opção, não soma dia, não nomeia dia da semana. Ele diz que o cliente quer terça de tarde, e o servidor resolve isso contra a agenda real, buffer incluído.

A parte difícil

Os relatos de "marcou no horário errado" eram de enlouquecer, porque eram quatro bugs diferentes com um sintoma só. O agente falava um dia da semana que não batia com a data. Oferecia horário ignorando o buffer. Uma remarcação largava, em silêncio, o profissional a que o agendamento estava amarrado. E ele se apoiava num atalho frágil de "escolha a opção 2", que quebrava assim que a lista mudava.

Quem desembaraçou isso foi o trace: cada relato apontava pra um turno diferente fazendo uma coisa errada diferente. A correção que atravessa os quatro foi tirar raciocínio de data do modelo por completo. Toda tentativa de ser esperto com "a próxima terça" dentro do prompt era um gerador de bug. Com o servidor resolvendo a data e o agente só dizendo a intenção, três dos quatro deixaram de ser possíveis.

Trade-offs

• Mover a lógica de data pro servidor deixa o agente menos mágico, porque ele não pode improvisar uma marcação esperta. É esse o objetivo: improvisar foi o que produziu os horários errados.
• Modelar buffer, recurso e lucratividade é muita restrição pra uma coisa que o usuário vê como "uma agenda". A complexidade é real porque o negócio é assim; esconder ela dentro do motor é o melhor que eu consigo fazer.
• Regra de lucratividade dá poder e dá um jeito novo de configurar errado. Vale por uma agenda que precisa render, mas está pedindo uma tela que explique o piso, não só que deixe mexer nele.

O que eu faria diferente

Eu modelaria as restrições da agenda como dado desde o começo, em vez de ir descobrindo elas como bug. Falta, convênio, buffer e lucratividade chegaram um por um, cada um como correção de alguma coisa que quebrou. Se desde o início "o que faz um horário ser válido e valer a pena" fosse um conjunto de regras configurável, tudo isso teria entrado como configuração em vez de quatro incidentes separados.