O protocolo v1

Um worker é uma imagem que lê um arquivo e escreve outro. Não há SDK obrigatório, linguagem preferida nem API a implementar.

/oren/
├── input.json     # somente leitura — inputs validados
├── context.json   # somente leitura — metadados da execução
└── output.json    # o worker escreve aqui

Os caminhos também chegam por variável de ambiente:

Variável	Valor
OREN_INPUT_PATH	/oren/input.json
OREN_OUTPUT_PATH	/oren/output.json
OREN_CONTEXT_PATH	/oren/context.json

Um worker completo

#!/bin/sh
INPUT=$(cat "$OREN_INPUT_PATH")
echo "processando"                          # log livre
echo '{"change":"minor"}' > "$OREN_OUTPUT_PATH"

Por que não argv

A versão anterior passava JSON em argv e lia a saída de stdout delimitada por marcadores. Isso trouxe três problemas:

• Escaping. JSON em argv atravessa o shell do entrypoint; $, aspas e quebras de linha exigem escaping que nenhum lado fazia direito.
• Colisão com log. stdout era canal de log e de dados ao mesmo tempo.
• Vazamento. Tokens em argv aparecem em ps e em qualquer eco do comando.

Ganho não previsto: o protocolo ficou agnóstico de plataforma. O mesmo worker roda pela CLI ou por um job de CI sem saber a diferença.

Sinalização

Código de saída	Significado
0	sucesso — output.json é lido e validado
1–125	falha da task
126+	falha de infraestrutura

Saída fora do contrato falha o step mesmo com código zero. Contrato que não é verificado não é contrato.

Dependências

Cada uma é entregue conforme a forma do seu tipo. O worker nunca sabe qual tipo semântico foi declarado — só onde o recurso está, o que ele descobre pelo context.json:

{
  "dependencies": {
    "source": { "type": "git-repository", "path": "/source" }
  }
}

A CLI concede exatamente o que foi declarado. Uma implementação que use o socket do Docker sem declarar engine/docker falha ao executar — é o que impede sub-declaração de virar vantagem no catálogo.