# Estrutura de projeto e runtime

Esta página mostra como um projeto TunnelHub costuma ser organizado e como o SDK participa da execução.

## Estrutura típica

Um template oficial normalmente inclui:

* `src/index.ts`;
* uma classe de integração em `src/core/` ou equivalente;
* `metadata`;
* tipos e modelos;
* `__tests__`;
* `tunnelhub.yml`.

## Handler

O handler principal costuma:

* instanciar a classe de integração;
* chamar `AutomationExecution.executeAutomation(...)`;
* retornar sucesso HTTP quando não há erro fatal.

Esse é o ponto de entrada esperado pelo runtime público.

## Classe de integração

Essa classe herda um dos flows do SDK e concentra a lógica principal de negócio:

* extração da origem;
* reconciliação com destino, quando houver delta;
* envio, insert, update ou delete;
* definição de metadados.

## Payload de execução

Em runtime, a automação recebe um payload que costuma incluir pelo menos:

* identificadores de tenant, ambiente, automação e execução;
* systems associados;
* parameters cadastrados;
* payload do trigger, quando aplicável.

É esse contrato que conecta o produto ao código.

## Relação com `tunnelhub.yml`

`tunnelhub.yml` define como o projeto será empacotado e publicado. O runtime depende desse arquivo para localizar o artefato e interpretar a configuração básica do serviço.

## Fluxo completo

1. a CLI cria a automação e baixa um template;
2. o projeto implementa a integração com o SDK;
3. o build gera o artefato definido em `package.artifact`;
4. a CLI publica uma nova versão;
5. o produto executa e monitora a automação.