Manual — Formulário de Atualização YAML

Baliza TV 3.0 · Como entender e preencher o formulário de proposta

O que é este formulário

O formulário de atualização YAML é uma ferramenta para que cada equipe de serviço possa revisar o contrato planejado da API TV 3.0 e indicar, rota por rota, o que deve ser mantido, removido ou corrigido no arquivo api-gateway-tv30.yaml.

O formulário é gerado automaticamente pelo Baliza a partir do último ciclo de comparação entre o YAML planejado e os swaggers implementados. Todas as rotas já estão pré-carregadas — a equipe só precisa marcar a ação proposta para cada uma e exportar o resultado.

Importante O formulário funciona 100% offline, diretamente no navegador. Não é necessário servidor ou login. O preenchimento é salvo automaticamente no navegador (localStorage) e persiste entre sessões.

Fluxo de trabalho

📂
Receber
Arquivo .html
🔍
Filtrar
Seu serviço
✏️
Preencher
Ação por rota
⬇️
Exportar
JSON ou CSV
📤
Enviar
WhatsApp / Mattermost
  1. Abra o arquivo baliza-form-run7.html no navegador (duplo clique).
  2. Use a aba do seu serviço (topo da página) para ver apenas suas rotas.
  3. Para cada rota, selecione a ação proposta e preencha a justificativa.
  4. Clique em ↓ JSON ou ↓ CSV para baixar o arquivo de resposta.
  5. Envie o arquivo baixado para o arquiteto de API (Carlos Eduardo) via WhatsApp ou Mattermost.
Dica Não precisa preencher todas as rotas de uma vez. O formulário salva automaticamente — feche e reabra quando quiser; o preenchimento estará lá. Exporte apenas quando terminar.

Abas de serviço

No topo do formulário há abas, uma por serviço. Clique na aba do seu serviço para ver apenas as rotas que lhe dizem respeito. A aba Todas exibe o conjunto completo (241 rotas únicas).

AbaServiço / Módulo
Meta 4 · CHATChat API e Chat CMS
Meta 4 · DEBDebates CMS
Meta 4 · PERGQuestions (Perguntas)
Meta 4 · ENQEnquetes (Polls API + Votes)
Meta 9 · CMS-MAMVOD / CMS-MAM
Meta 4 · NOTIFNotificações
Meta 3 · PUUsuários
Meta 10 · RECRecomendações
Nota Você pode preencher rotas de outras abas se tiver visibilidade sobre elas, mas cada equipe é responsável pelo seu serviço. Itens não preenchidos aparecem como (pendente) no arquivo exportado — não bloqueiam o envio.

Filtros e busca

Filtros por categoria

Ao lado das abas há botões de filtro rápido:

FiltroO que exibe
Todas Todas as rotas do serviço selecionado
Só planejado Rotas que existem no YAML mas não foram encontradas nos swaggers implementados — as mais importantes para revisar
Divergente Rotas presentes em ambos os lados mas com diferenças (schema, parâmetros, etc.)
Só impl. Rotas implementadas que não estão no YAML planejado
Igual Rotas sem divergência — YAML e implementação coincidem
Cosmético Diferenças de documentação (descrições, exemplos) sem impacto funcional
Prioridade sugerida Comece pelos filtros Só planejado e Divergente — são as rotas que mais precisam de decisão. "Igual" e "Cosmético" normalmente podem ficar com ação Manter sem necessidade de justificativa.

Campo de busca

O campo Filtrar por path... filtra as rotas visíveis por texto no método ou no caminho. Exemplos: digitar rooms mostra só rotas com /rooms; digitar delete mostra só rotas DELETE.

Categorias de rota

Cada rota exibe um badge colorido indicando sua situação atual no Baliza:

igual
Igual
A rota existe no YAML e na implementação sem divergências relevantes. Ação sugerida: Manter.
divergente
Divergente
A rota existe em ambos os lados mas tem diferenças (parâmetros, schemas, tipos de resposta). Requer decisão: o YAML deve ser atualizado para refletir a implementação, ou vice-versa.
só planejado
Só planejado
A rota está no YAML mas não foi encontrada nos swaggers do serviço. Pode ser: (a) ainda não implementada, (b) implementada em caminho diferente, ou (c) descartada pela equipe.
só impl.
Só implementado
A rota existe na implementação mas não está no YAML. Pode ser: (a) nova rota a adicionar ao contrato, ou (b) rota interna que não deve ser exposta no YAML.
cosmético
Cosmético
Diferença apenas em campos descritivos (description, example, summary) que o Baliza ignora por padrão. Sem impacto funcional.
breaking
Breaking
Divergência que implica quebra de contrato para clientes existentes (remoção de campo obrigatório, mudança de tipo, etc.). Requer atenção prioritária.

Campos por rota

Cada linha da tabela representa uma rota e tem quatro campos editáveis:

Método GET — não editável, informativo
Path /api/v1/polls/{id} — não editável, informativo
Categoria divergente — não editável, informativo
Ação proposta ↪ Outra rota editável (dropdown)
Rota equivalente PATCH /api/v1/polls/{id}/status — editável quando ação = "Outra rota"
Justificativa Ciclo de vida via PATCH, não PUT editável
Prioridade Alta editável (dropdown)

Campo "Rota equivalente"

Só é habilitado quando a ação é "↪ Implementado em outra rota". Use o formato MÉTODO /caminho/completo, por exemplo: PATCH /cms/v1/debates/sessions/{sessionId}/status. Quando a ação for outra, o campo fica desabilitado e cinza — ignore-o.

Campo "Justificativa"

Texto livre. Explique brevemente o motivo da decisão. Uma frase é suficiente. Exemplos:

  • "Moderação é assíncrona via Kafka; endpoint HTTP quebraria separação de responsabilidades."
  • "GET já retornado no detalhe do canal; rota separada é redundante."
  • "Rota nova ainda não implementada — schema em definição."

Ações disponíveis

Selecione a ação que melhor descreve o que deve acontecer com cada rota no YAML:

(pendente)
Estado inicial — rota ainda não avaliada. Itens pendentes aparecem no JSON exportado mas sinalizados como vazios. Não deixe as rotas do seu serviço em pendente.
Manter no YAML
A rota está correta no contrato como está ou com pequenos ajustes já conhecidos. Nenhuma mudança estrutural necessária.
Remover do YAML
A rota não será implementada e deve sair do contrato planejado. Use quando a abordagem arquitetural mudou (ex: lógica migrou para Kafka, WebSocket, etc.) ou quando o caso de uso foi descartado.
Implementado em outra rota
A funcionalidade existe, mas sob um método ou caminho diferente do YAML atual. Preencha o campo Rota equivalente com o caminho real. Exemplos:
  • GET /cms/v1/cms/channels/{id} já cobre o dado desta rota
  • PATCH /cms/v1/cms/channels/{id}/status substitui PUT nesta URL
Necessita schema
A rota vai ser implementada (ou já está), mas o YAML não tem o schema correto (body de request, campos de response, tipos). Sinaliza que a equipe precisa fornecer a definição OpenAPI antes da atualização do contrato.
🏗
Decisão arquitetural
A rota não será implementada por razão arquitetural explícita (ex: a funcionalidade é assíncrona, opera por outro protocolo, ou a responsabilidade foi realocada para outro sistema). Use a justificativa para explicar o motivo.

Barra de progresso

No canto superior direito há um contador X / Y avaliados com uma barra de progresso. Conta quantas rotas já têm uma ação selecionada (qualquer opção diferente de pendente). A barra considera todas as rotas, não apenas as do filtro ativo.

Meta por equipe Avalie pelo menos as rotas da sua aba de serviço. Itens de outros serviços podem ficar pendentes — o arquiteto de API consolida as respostas de todas as equipes.

Exportar JSON / CSV

No canto superior direito há dois botões de exportação. Ambos geram um arquivo com todas as rotas (incluindo pendentes), independente do filtro ativo.

Botão ↓ JSON (recomendado)

Gera baliza-yaml-proposals-run7.json com a estrutura:

{
  "meta": {
    "run_id": 7,
    "total": 241
  },
  "proposals": [
    {
      "service": "Meta 4 · CHAT",
      "method": "DELETE",
      "path": "/rooms/{roomId}/moderation/queue",
      "category": "so_planejado",
      "breaking": false,
      "action": "decisao_arquitetural",
      "equivalent_route": "",
      "justification": "Moderação assíncrona via Kafka",
      "priority": "alta"
    },
    ...
  ]
}

Botão ↓ CSV

Gera baliza-yaml-proposals-run7.csv com as mesmas colunas, compatível com Excel e Google Sheets. Útil para revisão offline em planilha.

Quando exportar Exporte quando terminar de preencher as rotas do seu serviço. Não é necessário preencher 100% das rotas — exporte com o que tiver e sinalise no envio quais rotas ainda estão pendentes de decisão.

Importar resposta anterior

O botão ↑ Importar permite carregar um JSON exportado anteriormente (por você ou por outra pessoa) para continuar o preenchimento ou consolidar respostas.

Ao importar, os campos preenchidos no JSON são aplicados às rotas correspondentes. Rotas já preenchidas no navegador são sobrescritas pelos valores do JSON importado. Rotas sem correspondência no arquivo são ignoradas.

Uso para consolidação Se você recebeu JSONs de múltiplas pessoas da equipe, abra o formulário, importe o primeiro JSON, depois importe o segundo — os campos de cada equipe se acumulam (o segundo import sobrescreve apenas as rotas que ele contém).

Como enviar

1
Exporte o JSON
Clique em ↓ JSON. O arquivo é baixado automaticamente na pasta de Downloads.
2
Renomeie (opcional)
Sugestão: baliza-proposals-<seu-serviço>.json para facilitar a identificação. Ex: baliza-proposals-chat.json.
3
Envie o arquivo
Encaminhe o arquivo JSON por WhatsApp ou Mattermost para Carlos Eduardo (arquiteto de API). Junto com o arquivo, informe brevemente:
  • Quantas rotas foram avaliadas
  • Se há alguma rota ainda pendente e qual o motivo
  • Se há alguma rota que requer discussão antes da atualização do YAML
Dúvidas sobre uma rota específica? Use o campo Justificativa para sinalizar a dúvida com prefixo [DÚVIDA] — ex: "[DÚVIDA] Não sei se esta rota foi descartada ou migrada." O arquiteto vai consolidar e responder antes de aplicar as mudanças no YAML.

O que acontece depois

Após receber os JSONs de todas as equipes, o arquiteto de API irá:

  1. Consolidar todas as respostas em um único arquivo
  2. Aplicar as mudanças no api-gateway-tv30.yaml em MRs separados por grupo de mudança
  3. Solicitar schemas das rotas marcadas como Necessita schema
  4. Abrir discussão para itens marcados como [DÚVIDA] antes de agir
Prazo e escopo Não há prazo fixo nesta primeira rodada. O objetivo é capturar as decisões já tomadas pelas equipes — rotas confirmadas como não-implementadas e rotas migradas para outros caminhos. Novos endpoints (que requerem schema) têm um segundo ciclo de atualização.