Referência

Esta secção descreve, campo a campo, a configuração JSON de tudo o que se pode construir no OutDo: os componentes de uma coluna, as vistas, os passos e os gatilhos das automações, e as entidades de estrutura. É pública e não precisa de credenciais.

As páginas de cada tipo nascem do código: um gerador lê as declarações de campo do outdo_library e escreve-as durante o build do site. Cada página diz no fim de que versão das declarações nasceu. Não se editam à mão: a edição desaparece no build seguinte.

Como ler uma página

Cada página tem uma tabela com seis colunas:

Coluna	O que diz
Chave	O nome exato da chave no JSON. Distingue maiúsculas.
Tipo	string, integer, number, boolean, enumeration, uuid, expression, list, map ou json. Uma lista diz também de que são os elementos.
Obrigatório	sim quando a config é inválida sem a chave.
Omissão	O valor que a plataforma usa quando a chave não vem. - significa que não há omissão declarada.
Descrição	Para que serve. Marca Opaco quando o caminho transporta dados do utilizador e nenhum resolvedor lhe toca, e Descontinuado quando sai numa versão futura.
Referência	Se o valor aponta para outra coisa: a que tipo aponta e em que forma.

Os campos compostos (um mapa dentro de outro, ou uma lista de objetos) têm sub-tabela própria, com o caminho no título: options[] são os elementos da lista options.

O bloco Exemplo JSON de cada página é sintetizado, não copiado de uma organização real: leva os campos obrigatórios e os que têm omissão declarada, e mais nada. É o mínimo que funciona, não um inventário.

Envelopes: quando a config é uma lista de um

Duas configs da plataforma não são um objeto, são uma lista com um único elemento, e ler config em vez de config[0] é o erro mais comum a quem escreve um template à mão:

• View.config é [ { ... } ].
• Rail.config é [ { ... } ].

As páginas dessas keys levam um aviso em cima. Todas as outras configs (Featurecolumn.config, trigger_config, graph_config) são um mapa.

Nomes contra uuids

A plataforma identifica as coisas por uuid, e a maior parte das configs guarda uuids. Num template isso não serve: o uuid de uma tabela da organização de origem não existe no destino. Por isso a coluna Referência diz sempre a forma:

• uuid: só aceita um identificador.
• nome: só aceita o nome técnico (por exemplo o name de uma coluna).
• uuid ou nome: aceita os dois, e o resolvedor tenta o uuid primeiro.

Quando a referência é a uma coluna, a forma vem acompanhada de a que tabela pertence: coluna de `linkedFeatureId` (uuid) quer dizer que a coluna é da tabela indicada na chave linkedFeatureId da mesma config.

A gramática das referências simbólicas

Num pacote de template, as referências viajam como strings simbólicas. Só estas são referências, e tudo o mais que comece por $ é texto normal:

^\$(workspace|currentUser|organization|[fcvrmw]_[a-z0-9_]+)$

Os prefixos das letras: f_ tabela (feature), c_ coluna, v_ vista, r_ rail, m_ módulo, w_ workflow. Mais três nomes fixos: $workspace, $currentUser e $organization. Um valor de linha como "$100" não é referência, e é por isso que a gramática é fechada e não "tudo o que começa por dólar".

Idioma e locales

A referência é gerada só em português de Portugal. O site tem uma versão inglesa, e /en/reference/** serve exatamente estas mesmas páginas, sem tradução. É deliberado: a alternativa, traduzir centenas de páginas geradas a cada mudança de campo, produziria uma tradução sempre atrasada face ao código.

Para agentes

• /llms.txt: índice curto, com URLs absolutos e uma linha por página.
• /llms-full.txt: todas as páginas desta secção, concatenadas em Markdown.
• API REST e MCP: como autenticar e onde bater.