Codex x Código Claude: Qual agente de codificação se adapta melhor ao seu fluxo de trabalho?

Codex x Claude: o que importa não é tanto encontrar um vencedor universal, mas sim escolher o estilo de trabalho no qual você pode confiar no dia a dia. Ambos os produtos são capazes de inspecionar um repositório, editar vários arquivos, executar comandos, realizar testes e explicar um patch. As diferenças significativas residem na forma como você delega o trabalho, na frequência com que orienta o agente, na quantidade de informações que você pode analisar e na forma como cada ferramenta se adapta ao seu ambiente de desenvolvimento atual.

Em nosso teste controlado com quatro tarefas no repositório, o Codex obteve 98/100 e o Claude Code, 99/100. Ambos concluíram o trabalho principal. O Claude Code apresentou uma análise mais abrangente e maior cobertura de casos extremos, enquanto o Codex frequentemente alcançou o resultado exigido com um escopo menor e produziu evidências mais sólidas no nível de execução em nossa configuração. Uma diferença de um ponto em um pequeno teste de Python não é motivo para declarar um vencedor global.

Os desenvolvedores que não desejam que o restante de seu fluxo de trabalho fique restrito a um único agente de codificação podem adicionar o GlobalGPT como uma camada multimodelo e multimodal independente. O GlobalGPT integra mais de 100 modelos de ponta, como o GPT 5.6, o Claude Opus 5 e o GPT Image 2, em um único painel. Além disso, o GlobalGPT CLI, as rotas MCP e Skill podem ser utilizadas a partir do Codex ou do Claude Code para obter segundas opiniões, planejamento, documentação ou outros modelos compatíveis, enquanto o ambiente de codificação nativo mantém o controle das edições no repositório e dos testes.

Experimente mais de 100 modelos de ponta no GlobalGPT

A comparação combina informações oficiais dos planos, trabalho prático com repositórios, resultados completos e expansíveis e experiências da comunidade claramente descritas. O objetivo é ajudar um desenvolvedor independente a escolher uma plataforma de programação principal sem se confundir com acessos por assinatura, créditos extras e cobrança por API.

Codex vs. Claude: uma visão geral

A tabela descreve uma decisão de compra, não uma classificação de modelos. Uma configuração diferente do modelo, do repositório, das permissões ou da tarefa pode alterar o resultado. Se você já utiliza um produto, a melhor comparação é uma tarefa delimitada a partir de sua própria base de código, com o mesmo comando de sucesso e sem repetições de qualidade.

O que são, na verdade, o Codex e o código Claude

Codex e Claude Code são produtos de agentes, não apenas nomes de modelos. O subjacente Modelo de IA para codificação Isso é importante, mas a estrutura circundante também determina quais arquivos o agente pode visualizar, quais comandos ele pode executar, como funcionam as aprovações, como o contexto é mantido e quais evidências permanecem após a conclusão da tarefa. Comparar apenas a reputação do modelo ignora grande parte da experiência que um desenvolvedor está adquirindo.

O Codex abrange fluxos de trabalho na linha de comando, em IDE, em desktop e orientados para a nuvem. Essa variedade o torna adequado tanto para a colaboração local direta quanto para uma delegação mais restrita. O Claude Code é centrado em um fluxo de trabalho conversacional no terminal, com integrações compatíveis e amplas possibilidades de personalização; isso guia para o uso do Claude na codificação oferece uma introdução mais abrangente a esse fluxo de trabalho. Para alguns desenvolvedores, observar um agente em ação no terminal é tranquilizador. Para outros, o que importa são o diff final, os testes e o histórico de auditoria, e não uma conversa contínua.

Essa distinção também explica por que dois testes que utilizam modelos nominalmente robustos podem apresentar comportamentos diferentes. O host decide como as instruções são apresentadas, como as ferramentas são acionadas e quando um ser humano deve aprovar uma ação. Comparações entre comunidades que ignoram o ambiente de teste podem confundir um comportamento no nível do produto com uma verdade no nível do modelo.

• O modelo oferece capacidade de raciocínio e geração.
• O conjunto de cabos do agente controla arquivos, comandos, contexto, aprovações e recuperação.
• O contrato de tarefa do usuário determina o escopo, as verificações de sucesso e quando o agente deve parar.

Fluxo de trabalho e controle: delegação ou orientação contínua?

A pergunta mais útil sobre o Codex versus o Código Claude geralmente não é “Qual deles produz um código melhor?”, mas sim “Como eu quero trabalhar com ele?” Uma tarefa clara e bem delimitada pode ser delegada com um objetivo exato, um escopo permitido e uma instrução de verificação. Uma refatoração ambígua se beneficia de discussão, inspeção intermediária e da oportunidade de redirecionar o agente antes que ele faça alterações excessivas.

A orientação contínua é valiosa quando os requisitos estão em evolução ou quando as decisões arquitetônicas ainda estão sendo discutidas. Ela se torna um custo quando o agente solicita repetidamente decisões que poderiam ter sido resolvidas com base nas instruções do repositório. A execução autônoma é valiosa quando o contrato da tarefa é estável. Ela se torna arriscada quando o agente faz suposições sem verificação ou amplia o escopo sem um caminho claro para reverter as ações.

Um relatório detalhado do Reddit, datado de 13 de abril de 2026, descreveu cerca de 100 horas de trabalho com o Claude Code e 20 horas com o Codex em um projeto de Python e TypeScript com aproximadamente 80.000 linhas de código e cerca de 2.800 testes. O autor caracterizou o Claude como mais rápido e mais interativo, mas exigindo mais atenção, e o Codex como mais lento e mais metódico. Esse relatório é excepcionalmente útil porque inclui o contexto do projeto e da experiência, mas ainda assim representa o fluxo de trabalho de um único desenvolvedor.

Nossos próprios testes de tempo não apontaram um vencedor claro. O Claude concluiu as duas primeiras tarefas mais rapidamente, enquanto o Codex concluiu as duas últimas mais rapidamente. O Claude também utilizou um subagente de contingência depois que sua rota de autenticação via CLI ficou indisponível; portanto, as rotas de execução não foram equivalentes às do laboratório. A conclusão responsável é que a velocidade depende da tarefa, do modelo selecionado, da configuração de esforço, do contexto e do host — e não que um dos produtos seja sempre mais rápido.

Compreensão do repositório e gestão do contexto

Compreender o repositório vai além de apenas nomear pastas. Um agente útil deve rastrear como os dados circulam entre os arquivos, identificar contratos que restringem uma alteração, localizar testes, distinguir um sintoma de sua provável origem e explicar o risco de editar a camada errada. Um mapa exaustivo pode revelar inconsistências ocultas; um mapa conciso pode levar um desenvolvedor a uma decisão segura de implementação mais rapidamente.

Em nossa tarefa T1 de leitura exclusiva, ambos os agentes obtiveram nota 20/20 e fundamentaram suas respostas no repositório. O código Claude foi mais exaustivo e revelou inconsistências adicionais no contrato. O Codex foi mais conciso, mas ainda assim identificou os arquivos relevantes, os riscos e o plano de implementação. Nenhum dos dois estilos é automaticamente superior. A exaustividade ajuda em migrações e auditorias em que não se está familiarizado com o ambiente; a concisão ajuda quando o desenvolvedor já conhece a arquitetura e deseja um plano de mudança focado.

Arquitetura: modelo, repositório, serviço e um utilitário de tempo sem conexão.

Principais riscos: semântica de prioridade indefinida, compatibilidade, ordenação, validação e incompatibilidade de escopo.

Três camadas mais um módulo isolado. Sem ciclos; injeção de dependências mínima.

Também revelou problemas relacionados à alocação de identificadores, contratos de erro assimétricos e cobertura de teste insuficiente.

Arquitetura ##

Este é um pequeno pacote Python que utiliza apenas a biblioteca padrão e possui quatro camadas funcionais:

- **Modelo de dados:** [`Job`]() é uma classe de dados imutável que contém `identifier`, `name` e `owner`. `Job.to_dict()` a serializa por meio de `dataclasses.asdict()`.
- **Repositório:** [`JobRepository`]() armazena tarefas em um dicionário na memória, indexado por `identifier`. Não há banco de dados nem persistência duradoura.
- **Serviço:** [`SchedulerService`]() é responsável pela alocação de identificadores, normalização de entradas, criação, listagem e exclusão.
- **Utilitário de tempo:** [`next_daily_run()`]() calcula a hora da próxima execução, mas nada o importa ou o conecta a `Job`, `SchedulerService` ou `JobRepository`.
- **API pública:** [`scheduler.__init__`]() exporta apenas `SchedulerService`.

Apesar do nome do repositório, os trabalhos atualmente não contêm informações de agendamento, e não há fila de execução. A prioridade pode, portanto, afetar os metadados armazenados e a ordem de listagem, mas não pode afetar a execução real do trabalho sem ampliar consideravelmente o sistema.

## Fluxo de dados de criação e listagem

Criação por meio de `SchedulerService.create_job(name, owner)`:

1. [`create_job()`]() rejeita um nome composto apenas por espaços em branco.
2. Ele remove os espaços em branco de `name` e `owner` e, em seguida, constrói um objeto `Job` imutável usando o `_next_identifier` do serviço.
3. [`JobRepository.save()`]() grava o objeto em `_jobs[job.identifier]`.
4. O serviço incrementa `_next_identifier` e retorna o mesmo `Job`.

Listagem por meio de `SchedulerService.list_jobs()`:

1. [`list_jobs()`]() delega diretamente para `repository.all()`.
2. [`JobRepository.all()`]() ordena as chaves do dicionário numericamente.
3. Os trabalhos são, portanto, retornados em ordem crescente de identificador/criação, e não por ordem de agendamento ou prioridade.

## Arquivos provavelmente afetados pelas prioridades das tarefas

Obrigatório:

- [`scheduler/models.py`](): adicione o campo de prioridade e qualquer valor padrão. `to_dict()` o incluirá automaticamente, pois utiliza `asdict()`.
- [`scheduler/service.py`](): aceitar, validar e passar a prioridade para `Job`.
- [`tests/test_scheduler.py`](): testar o comportamento dos valores padrão, explícitos, inválidos, serializados e de ordenação.

Condicional:

- [`scheduler/repository.py`](): altere `all()` somente se as prioridades tiverem como objetivo controlar a ordem da lista. Uma chave secundária determinística, como `identifier`, deve lidar com empates.
- [`scheduler/__init__.py`](): atualize somente se a prioridade se tornar uma enumeração pública ou um objeto de valor.
- [`README.md`](): documente os valores aceitos, o padrão e a semântica de ordenação.

Provavelmente não afetado:

- `scheduler/time_rules.py`, pois seu único símbolo opera sobre uma data e hora fornecidas e não tem relação com tarefas ou listagem.

## Principais riscos

- **Semântica indefinida:** O código não fornece nenhum precedente para determinar se valores maiores ou menores significam maior prioridade, quais valores são válidos ou se a prioridade afeta de alguma forma a listagem.
- **Compatibilidade:** Adicionar um argumento obrigatório a `Job` ou `create_job()` quebraria chamadas existentes, como `create_job("Relatório diário", "Alex")` no teste atual. Um valor padrão preserva essa chamada.
- **Quebra na construção posicional:** `Job` é atualmente construído posicionalmente em `SchedulerService.create_job()`. O posicionamento dos campos e futuras chamadas posicionais poderiam atribuir valores errados sem aviso prévio; a construção por palavra-chave seria mais segura.
- **Alteração na ordem:** Substituir a ordem dos identificadores em `JobRepository.all()` altera o comportamento estabelecido. Prioridades iguais precisam de um critério de desempate estável.
- **Ambiguidade na validação:** Um valor Python sem restrições poderia permitir strings, booleanos ou inteiros arbitrários que são difíceis de comparar de forma consistente.
- **Incompatibilidade de escopo de execução:** Não há despachante nem fila de execução. A alegação de que a prioridade altera qual tarefa é executada primeiro não seria suportada por nenhum símbolo atual.
- **Limitações na memória:** A prioridade, assim como qualquer outro campo da tarefa, desaparece quando o processo termina, pois `_jobs` é apenas um dicionário de instância.

## Plano de implementação e validação

1. Definir primeiro o contrato: representação, valores permitidos, padrão, direção da prioridade, desempate e se ela altera a ordem de listagem.
2. Adicione `priority` a `Job`, de preferência com um valor padrão compatível com versões anteriores.
3. Estenda `SchedulerService.create_job()` com um parâmetro de prioridade predefinido, valide-o e construa `Job` com argumentos-chave.
4. Se a listagem levar em conta a prioridade, altere `JobRepository.all()` para classificar primeiro por prioridade e, em segundo lugar, por identificador. Caso contrário, mantenha a ordem do repositório inalterada.
5. Adicione testes para:
   - Criação existente com dois argumentos.
   - Preservação explícita da prioridade.
   - Prioridade padrão.
   - Tipo inválido e valores fora do intervalo.
   - Saída de `Job.to_dict()`.
   - Ordem de listagem com prioridades múltiplas.
   - Ordenação estável para prioridades iguais.
   - Comportamento existente para nomes em branco.
6. Atualize o README com o contrato público exato.
7. Executar o conjunto completo de testes offline com `python3 -m unittest discover -s tests -v`.

## Verificação realizada

- Conjunto de testes de referência: **2 testes aprovados**.
- A pesquisa de símbolos em todo o repositório confirmou que `next_daily_run()` está desconectado e que não há símbolos de prioridade existentes.
- Arquivos alterados: **nenhum**.
- Implementação do recurso: **não realizada**, conforme exigido.

> **Conclusão + decisão**
>
> A alteração é pequena se a prioridade for apenas metadados ou ordem de listagem: principalmente `models.py`, `service.py`, `repository.py` e testes. Antes da implementação, a decisão necessária é se a prioridade descreve apenas uma tarefa ou altera a ordem de `list_jobs()`, além da escala de valores, padrão, direção e regra de desempate.

Registro de execução do # T1 — Compreensão de repositório desconhecido

Parâmetros de execução do ##

| Campo | Valor |
| --- | --- |
| Tarefa | `T1` |
| Prompt congelado | `01-prompts/T1.md` |
| SHA-256 do prompt congelado | `a571ff15c2502ec29b172ae2e77dd9ab0caca2869b91f9468d47571434d16c17` |
| Unidade de execução | subagente Claude isolado, `uso geral`, contexto novo |
| Método de isolamento | **recurso alternativo do subagente** (regressão documentada — consulte `results/isolation-decision.md`) |
| Cópia limpa atribuída | `runtime/workspaces/T1` |
| Versão do código Claude | `2.1.220` |
| Configuração do modelo | `claude-opus-5` |
| start_utc | `2026-07-28T10:27:31Z` |
| end_utc | `2026-07-28T10:28:32Z` |
| Duração | 61 s (simultânea com T2–T4; não é uma medição de latência precisa) |
| Número da tentativa | 1 |
| Status | `válido` |
| Intervenção humana | nenhuma |

## Resumo da ferramenta segura

`date`, `find`, `ls`, `wc`, `stat`, `grep`, `Read` em 7 arquivos da área de trabalho, `python3 -V`,
`python3 -m unittest discover -s tests -v`. Todas as leituras restritas à área de trabalho designada.
Sem rede, sem instalações, sem gravações.

## Resultado da verificação offline

`python3 -m unittest discover -s tests -v` → 2 testes, OK (saída 0). Revisado pelo
coordenador de fora do espaço de trabalho: consulte `results/checks/T1-public.txt`.

## Patch

Nenhum. `results/T1/patch.diff` está vazio, e `diff -ru 02-fixture runtime/workspaces/T1`
não retorna diferenças. A tarefa exigia inspeção sem alteração de arquivos; isso foi
confirmado, e não apenas declarado.

## Erros corrigidos

Um erro recuperável do shell: um `grep` inicial usou padrões `--include=*.py` sem aspas, que
o shell tentou expandir; a execução foi repetida com padrões entre aspas e foi bem-sucedida. Sem efeito nos resultados.

## Saída visível (textual)

### 1. O que é este repositório

Um fixture autônomo da biblioteca padrão do Python chamado `local-scheduler-1.0.0` (`fixture-manifest.json`), licenciado sob a licença MIT, sem dependências de rede ou de produção (`README.md`, `"network_required": false`). É muito pequeno: 8 arquivos de código-fonte/documentação mais o manifesto, totalizando 103 linhas. O interpretador utilizado é o **Python 3.9.6**. Não há `pyproject.toml`, `setup.py`, configuração de CI, linter ou configuração de verificador de tipos — o único fluxo de trabalho declarado é `python3 -m unittest discover -s tests -v` (`README.md`).

### 2. Arquitetura

Três camadas mais um módulo órfão, todos sob `scheduler/`:

| Camada | Arquivo | Símbolo | Responsabilidade |
|---|---|---|---|
| Fachada do pacote | `scheduler/__init__.py` | `__all__ = ["SchedulerService"]` | Reexporta apenas `SchedulerService`; `Job`, `JobRepository` e `time_rules` não fazem parte da interface pública |
| Modelo de domínio | `scheduler/models.py` | `Job` (`@dataclass(frozen=True)`) | Objeto de valor imutável com os campos `identifier: int`, `name: str`, `owner: str`, além de `to_dict()` implementado como `asdict(self)` |
| Persistência | `scheduler/repository.py` | `JobRepository` | `dict` na memória com chave `identifier`; `save`, `get`, `all`, `delete` |
| Serviço de aplicação | `scheduler/service.py` | `SchedulerService` | Validação, alocação de identificadores, orquestração: `create_job`, `list_jobs`, `delete_job` |
| Órfão | `scheduler/time_rules.py` | `next_daily_run` | Cálculo de recorrência — **não importado por nenhum outro arquivo** |

A direção das dependências é clara e unidirecional: `service.py` importa de `.models` e `.repository`; `repository.py` importa de `.models`; `models.py` importa apenas `dataclasses`. Sem ciclos. A injeção de dependências está presente, mas é mínima — `SchedulerService.__init__(self, repository=None)` faz `self.repository = repository or JobRepository()`, de modo que um repositório fictício pode ser substituído nos testes.

Observe que `scheduler/time_rules.py` é código morto atualmente. Eu pesquisei toda a árvore por `time_rules` e `next_daily_run`; os únicos resultados são sua própria definição e sua listagem em `expected_files` do `fixture-manifest.json`. Ele está incluído, mas não está conectado.

### 3. Fluxo de dados

**Criação de um trabalho** — `SchedulerService.create_job(name, owner)`:
1. Verificação: `if not name.strip(): raise ValueError('name is required")`. Essa é a *única* validação no sistema — `owner` nunca é verificado, portanto, um proprietário em branco é aceito.
2. Construção: `Job(self._next_identifier, name.strip(), owner.strip())` — construção posicional, e ambas as strings são normalizadas por meio da remoção de espaços.
3. Persistência: `self.repository.save(job)`, que executa `self._jobs[job.identifier] = job` e retorna o trabalho.
4. Avançar o contador: `self._next_identifier += 1` — *após* o salvamento, de modo que uma exceção levantada deixa o contador não consumido.
5. Retornar a instância `Job` (o serviço retorna seu próprio `job` local, não o valor de retorno do repositório).

A alocação de identificadores ocorre no **serviço**, não no repositório (`self._next_identifier = 1` em `SchedulerService.__init__`). Esse é um ponto de integração importante: injetar um repositório que já contenha tarefas irá sobrescrevê-las silenciosamente, pois o novo serviço reinicia a numeração em 1.

**Listando tarefas** — `SchedulerService.list_jobs()` é um simples repasse para `JobRepository.all()`, que retorna `[self._jobs[key] for key in sorted(self._jobs)]`. A ordenação é, portanto, **ascendente por identificador inteiro**, o que atualmente coincide com a ordem de inserção. Uma nova lista é construída a cada chamada, mas os objetos `Job` são referências compartilhadas — seguras apenas porque `Job` é congelado.

**Exclusão** — `SchedulerService.delete_job(identifier)` delega para `JobRepository.delete`, que é `self._jobs.pop(identifier)` sem valor padrão; portanto, gera um `KeyError` caso o identificador esteja ausente. Isso é inconsistente com `JobRepository.get`, que retorna `None` para a mesma condição.

**Cobertura de teste desses caminhos** — `tests/test_scheduler.py` possui exatamente dois casos: `test_create_and_list_jobs` (verifica se `job.identifier == 1` e `[job] == service.list_jobs()`) e `test_blank_name_is_rejected`. Ambos são aprovados na árvore atual.

### 4. Arquivos provavelmente afetados pela adição de prioridades de tarefas

Em ordem decrescente de certeza:

1. **`scheduler/models.py`** — certo. `Job` precisa de um campo `priority`. Como a classe de dados tem `frozen=True` e os campos são posicionais, um novo campo deve ter um valor padrão (por exemplo, `priority: int = 0`) ou deve ser colocado após os três já existentes; caso contrário, toda a construção posicional existente será prejudicada. `to_dict()` não precisa de alteração — `asdict(self)` reconhece o campo automaticamente, o que é uma mudança silenciosa no contrato de serialização, e não uma alteração no código.
2. **`scheduler/service.py`** — com certeza. `create_job` precisa de um parâmetro `priority` e deve passá-lo para o construtor posicional `Job(...)` na linha 13. Se a prioridade for validada (intervalo, pertencimento a enumeração), a condição de verificação deve ser colocada ao lado da verificação existente `name.strip()`. Se a lista precisar ser ordenada por prioridade, `list_jobs` é onde uma política de ordenação seria definida, caso você queira que o repositório continue sendo um armazenamento simples.
3. **`scheduler/repository.py`** — provável. O `sorted(self._jobs)` de `JobRepository.all()` ordena as *chaves* do dicionário, ou seja, os identificadores. Uma listagem ordenada por prioridade requer alterar isso para classificar os valores por uma chave como `(-job.priority, job.identifier)`, ou adicionar um acessador ordenado separado. Não deixe o desempate implícito: a ordem de inserção no dicionário não é um contrato estável no qual se possa confiar.
4. **`tests/test_scheduler.py`** — certo. Novos casos para prioridade padrão, prioridade explícita, ordenação e rejeição de prioridade inválida. Observe que o `assertEqual([job], service.list_jobs())` existente compara o *mesmo* objeto, portanto, ele sobrevive à adição de um campo; ele não sobreviveria se comparasse um literal `Job` recém-construído.
5. **`README.md`** — provavelmente, se a semântica de prioridade (qual extremidade do intervalo prevalece, valor padrão) precisar ser declarada em algum lugar.
6. **`scheduler/__init__.py`** — somente se uma enumeração de prioridade ou constantes precisarem ser exportadas junto com `SchedulerService`.
7. **`fixture-manifest.json`** — somente se você adicionar um novo arquivo de módulo; sua matriz `expected_files` é um inventário explícito e ficaria desatualizada.
8. **`scheduler/time_rules.py`** — *não* deve ser alterado. A prioridade é ortogonal à recorrência, e este módulo não está conectado.

### 5. Principais riscos

- **A semântica de ordenação representa uma mudança silenciosa de comportamento.** Atualmente, `JobRepository.all()` garante a ordenação por identificador crescente, e `list_jobs` herda essa propriedade. Qualquer consumidor que dependa dessa garantia será afetado negativamente pela reordenação. Decida explicitamente: `list_jobs()` muda de significado, ou surge um novo `list_jobs_by_priority()` ao lado dele? A primeira opção é a de maior risco, e o teste existente `test_create_and_list_jobs` é fraco demais para detectar uma regressão (lista com um único elemento).
- **A direção da ordenação é genuinamente ambígua.** "Prioridade 1' significa convencionalmente *a mais alta* em alguns sistemas e *a mais baixa* em outros. Não há nada neste repositório — nenhum comentário, nenhuma string de documentação, nenhuma linha no README — que defina isso. Escolha uma convenção, documente-a em `models.py` e incorpore-a em um teste com pelo menos três prioridades distintas para que a direção fique definida.
- **Empates instáveis na ordenação.** Se dois trabalhos compartilharem a mesma prioridade, o resultado ainda deve ser determinístico. A função `sorted` do Python é estável, mas a estabilidade só é útil se a ordem de entrada estiver definida. Sempre inclua `identifier` como uma chave secundária explícita.
- **Ordenação de campos em `dataclass` congelada.** `Job` é `@dataclass(frozen=True)` com três campos posicionais, e `service.py:13` o constrói posicionalmente. Inserir `priority` em qualquer lugar que não seja o último, ou sem um valor padrão, é uma alteração compatibilidade que os dois testes existentes podem não detectar claramente.
- **Ampliação do contrato de `to_dict()`.** `asdict(self)` reflete todos os campos. Adicionar `priority` altera todas as cargas serializadas sem nenhuma modificação visível no corpo do método em `models.py`. Qualquer coisa que verifique a forma exata do dicionário deixa de funcionar.
- **Restrições do Python 3.9.6.** Sem `@dataclass(slots=True)` (3.10+), sem `kw_only=True` (3.10+) e as anotações PEP 604 `int | None` falham em tempo de execução sem `from __future__ import annotations`. Se a prioridade for modelada como uma enumeração, `enum.StrEnum` é 3.11+ e não está disponível. Qualquer uma dessas situações faria com que o fixture falhasse neste interpretador.
- **A alocação de identificadores está na camada errada.** `SchedulerService._next_identifier` significa que o serviço é responsável pela geração de IDs, enquanto o repositório é responsável pelo armazenamento. Se o trabalho com prioridades motivar uma segunda implementação de repositório ou fixtures pré-carregados, essa divisão produzirá colisões de IDs e tarefas sobrescritas.
- **Contratos de erro assimétricos.** `JobRepository.get` retorna `None` em caso de falha, enquanto `JobRepository.delete` lança `KeyError`. Qualquer nova consulta relacionada à prioridade deve adotar deliberadamente uma convenção, em vez de herdar a inconsistência acidentalmente.
- **Precedente de lacuna na validação.** `create_job` valida `name`, mas não `owner`. Não copie essa negligência para `priority` — uma prioridade não validada se propaga para a chave de classificação e pode gerar `TypeError` bem no interior de `sorted` (por exemplo, comparando `int` com `None`), em vez de no local da chamada.
- **Armadilha de código morto.** `scheduler/time_rules.py` parece uma lógica de agendamento e atrairá edições. Ele não é importado por nenhum outro arquivo, e sua própria string de documentação admite o bug: ele adiciona 24 horas decorridas em UTC e "ajusta a hora local do relógio de parede nas transições do horário de verão". Alterá-lo não produz nenhum efeito observável no sistema testado; portanto, o esforço gasto nisso é desperdiçado e qualquer teste escrito com base nele não valida nada do que é lançado.
- **Rede de segurança frágil.** Dois testes, sem CI, sem linter, sem verificação de tipos. Não há nada para detectar uma regressão, exceto o que você mesmo escrever. Trate o conjunto de testes existente como uma cobertura básica insuficiente, não como um filtro.

### 6. Plano de implementação (não executado)

1. **Defina primeiro a semântica, por escrito.** Tipo de prioridade (`int` vs. enum), intervalo válido, valor padrão para tarefas existentes/não especificadas e direção de classificação. Registre isso como uma string de documentação em `Job`, no arquivo `scheduler/models.py` — esse é o único local do qual todas as camadas já dependem.
2. **Estenda o modelo.** Adicione `priority: int = 0` como o *último* campo de `Job` em `scheduler/models.py`, preservando a compatibilidade posicional com `service.py:13` e deixando `to_dict()` inalterado.
3. **Incorpore isso ao serviço.** Adicione um parâmetro `priority` com valor padrão a `SchedulerService.create_job`, valide-o junto com a condição de verificação `name.strip()` já existente (lance um `ValueError`, correspondendo ao tipo de erro estabelecido) e passe-o para o construtor `Job`.
4. **Defina explicitamente o contrato de listagem.** Opção preferida de baixo risco: mantenha `JobRepository.all()` como a primitiva ordenada por identificador e adicione um acessador separado ordenado por prioridade. Se, em vez disso, `list_jobs()` precisar mudar de significado, altere a compreensão de `JobRepository.all()` para classificar os valores por uma chave composta explícita, incluindo `identifier` como critério de desempate, e anote a alteração no `README.md`.
5. **Mantenha `scheduler/__init__.py` em sincronia** apenas se uma enumeração ou constante pública tiver sido introduzida.
6. **Não altere `scheduler/time_rules.py`** e não adicione arquivos, a menos que `expected_files` em `fixture-manifest.json` seja atualizado na mesma alteração.

### 7. Plano de validação

- **Primeiro, a linha de base.** Execute `python3 -m unittest discover -s tests -v` antes de qualquer edição e confirme que os dois testes foram aprovados. Eu já fiz isso — os testes foram aprovados sem falhas.
- **Controle de regressão.** Ambos os testes existentes devem continuar sendo aprovados sem modificações. Se `test_create_and_list_jobs` precisar ser editado, isso é um sinal de que a alteração está causando falhas, não um motivo para editar o teste.
- **Novos casos em `tests/test_scheduler.py`:**
  - Prioridade padrão quando `create_job` é chamado com a assinatura antiga de dois argumentos (comprova a compatibilidade com versões anteriores).
  - Ciclos explícitos de prioridade passando por `create_job` → `list_jobs`.
  - Ordenação com **três ou mais** prioridades distintas, verificando a lista completa — é isso que determina a direção da ordenação.
  - Desempate: dois trabalhos com prioridade igual são retornados em ordem crescente de identificador.
  - Prioridade inválida gera `ValueError`, espelhando o caso de nome em branco.
  - `to_dict()` inclui `priority` com o valor esperado.
  - Caminho do repositório injetado: `SchedulerService(repository=fake)` ainda atribui a prioridade corretamente, testando a integração `repository ou JobRepository()`.
- **Verificação de compatibilidade.** Confirme se tudo funciona especificamente no Python 3.9.6 — sem `slots=`, sem `kw_only=`, sem uniões PEP 604 simples, sem `StrEnum`.
- **Verificação de inventário.** Releia o `fixture-manifest.json` e confirme se o conjunto de arquivos no disco ainda corresponde a `expected_files`.
- **Determinismo.** Execute o conjunto de testes duas ou três vezes; bugs de ordenação envolvendo a ordem de iteração do dicionário podem ocorrer de forma intermitente.
- **Limpeza.** Execute com `PYTHONDONTWRITEBYTECODE=1` para que os diretórios `__pycache__` não apareçam como desvios não rastreados em relação ao manifesto.

Esse resultado não reflete o desempenho em um monorepo de grande porte ou em uma sessão autônoma de uma semana. O ambiente de teste foi deliberadamente pequeno e controlado. Para uma avaliação real, comece com um prompt somente para leitura: peça a cada ferramenta para mapear o caminho de chamadas, indicar os arquivos que seriam alterados, identificar os testes e listar as suposições não resolvidas antes de permitir edições.

Estilo de implementação, escopo do patch e correção de bugs

Trabalho com vários arquivos

O mesmo comportamento de aprovação pode resultar de diferentes escolhas de engenharia. No T2, ambos os produtos obtiveram 30/30 e foram aprovados no validador oculto congelado. O código Claude colocou a validação em mais de um limite e adicionou testes mais abrangentes de modelo direto e de limiar. O Codex utilizou uma implementação menor, centrada em serviços, que também atendeu ao contrato.

Para um desenvolvedor independente, essa é uma verdadeira escolha. Uma validação mais abrangente pode proteger as invariantes quando os objetos são criados por meio de múltiplos caminhos. Um patch menor pode reduzir a superfície de regressão e o tempo de revisão quando um único serviço é o ponto de entrada pretendido. A resposta correta depende das regras de propriedade do repositório, e não da contagem isolada de linhas alteradas ou de testes.

Adicionamos prioridade ao modelo imutável, validamos esse modelo no limite do serviço e mantivemos a ordem no repositório.

Todos os sete testes públicos e o validador oculto congelado foram aprovados.

Validei a prioridade tanto no limite do serviço quanto no modelo imutável, preservei a filtragem do repositório e adicionei a cobertura de limite.

Quatorze testes públicos e o validador oculto foram aprovados.

Implementamos o recurso de prioridade para tarefas agendadas.

Arquivos alterados:

- [scheduler/models.py](./scheduler/models.py:5) — adicionamos o parâmetro `priority` serializado, com valor padrão `0`.
- [scheduler/service.py](./scheduler/service.py:11) — adicionou validação, armazenamento e filtragem `list_jobs(min_priority=0)`, preservando a ordem dos identificadores.
- [tests/test_scheduler.py](./tests/test_scheduler.py:16) — adicionada cobertura para valores padrão, serialização, armazenamento, limites, valores inválidos e filtragem.

Testes executados:

```text
python3 -m unittest discover -s tests -v
Executados 7 testes — OK
```

**Conclusão:** A tarefa congelada está concluída e verificada.  
**Decisão necessária:** Nenhuma.

Registro de execução do # T2 — Recurso de prioridade de múltiplos arquivos

Parâmetros de execução do #

| Campo | Valor |
| --- | --- |
| Tarefa | `T2` |
| Prompt congelado | `01-prompts/T2.md` |
| SHA-256 do prompt congelado | `8476a56034c4e719b97ee4081b32b4c73efd45feafe1bda9d477c83cb8fdb698` |
| Unidade de execução | subagente Claude isolado, `uso geral`, contexto novo |
| Método de isolamento | **recurso alternativo do subagente** (regresso documentado — consulte `results/isolation-decision.md`) |
| Cópia limpa atribuída | `runtime/workspaces/T2` |
| Versão do código Claude | `2.1.220` |
| Configuração do modelo | `claude-opus-5` |
| start_utc | `2026-07-28T10:27:52Z` |
| end_utc | `2026-07-28T10:29:33Z` |
| Duração | 101 s (simultânea com T1, T3, T4; não é uma medição de latência precisa) |
| Número da tentativa | 1 |
| Status | `válido` |
| Intervenção humana | nenhuma |

## Resumo da ferramenta segura

`date`, `Leitura`/`Edição`/`Gravação` apenas dentro do espaço de trabalho atribuído, `grep`,
`python3 -m unittest discover`, `python3 -m compileall`, verificações de funcionamento `python3 -c` embutidas.
Sem rede, sem instalações, apenas biblioteca padrão.

## Arquivos alterados

`scheduler/models.py`, `scheduler/repository.py`, `scheduler/service.py`,
`tests/test_scheduler.py`. Nenhum arquivo foi adicionado ou removido, portanto o `fixture-manifest.json` permanece
preciso. Patch completo: `results/T2/patch.diff`.

## Resultados da verificação offline

Relatado pelo executor de tarefas:

| Verificação | Resultado |
| --- | --- |
| `python3 -m unittest discover -s tests -v` (linha de base, pré-alteração) | 2 aprovados, 0 reprovados |
| `python3 -m compileall -q scheduler tests` | sem erros |
| verificações de fumaça inline (construção legada de 3 argumentos, limite de palavra-chave/posicional, `to_dict`) | aprovado |
| `python3 -m unittest discover -s tests -v` (final) | **14 aprovados, 0 reprovados** |

Revisado de forma independente pelo coordenador de fora do espaço de trabalho:

| Verificação | Saída | Resultado |
| --- | --- | --- |
| conjunto público (`results/checks/T2-public.txt`) | 0 | 14 testes, OK |
| validador oculto `03-checks/test_t2_hidden.py` (`results/checks/T2-hidden.txt`) | 0 | 2 testes, OK |

O validador oculto falha (saída 1) ao ser executado em uma cópia inalterada do fixture, confirmando que a aprovação é
significativa. Consulte `results/checks/validator-controls.md`.

## Cobertura de comportamento do mapa de referência

Todos os cinco comportamentos exigidos em `03-checks/gold-map.json` foram atendidos:

| Comportamento exigido | Evidência |
| --- | --- |
| prioridade padrão 0 | `Job.priority: int = MIN_PRIORITY`; `create_job(..., priority=MIN_PRIORITY)`; `test_priority_defaults_to_zero` |
| intervalo de inteiros de 0 a 9 | `validate_priority` rejeita valores não inteiros e fora do intervalo; `test_out_of_range_priority_is_rejected`, `test_non_integer_priority_is_rejected` |
| prioridade serializada | `to_dict()` via `asdict`; `test_priority_appears_in_serialized_output` verifica se o dicionário exato está presente |
| filtragem por prioridade mínima | `list_jobs(min_priority=0)` → `JobRepository.all(min_priority)`; `test_filter_is_inclusive_of_the_threshold` |
| ordenação de identificadores | filtro aplicado dentro da compreensão existente `sorted(self._jobs)`; `test_filter_preserves_ascending_identifier_order` |

## Erros corrigidos

Nenhum. Os artefatos `__pycache__` das execuções de teste foram removidos pelo executor de tarefas; uma varredura do coordenador
confirmou que o espaço de trabalho está limpo.

## Saída visível (textual)

Adicionado um campo inteiro `priority` aos trabalhos agendados nas camadas de modelo, repositório e serviço do fixture do agendador local, além da listagem filtrada.

**`scheduler/models.py`** — Adicionadas as constantes do módulo `MIN_PRIORITY = 0` / `MAX_PRIORITY = 9` e uma função reutilizável `validate_priority(priority)` que gera um `ValueError` para valores que não sejam inteiros e para valores fora do intervalo de 0 a 9, inclusive. `bool` é explicitamente rejeitado, apesar de ser uma subclasse de `int`, de modo que `True` não pode ser interpretado como prioridade 1. A classe de dados `Job`, que é congelada, ganha `priority: int = MIN_PRIORITY` como um campo final com valor padrão, o que mantém a construção existente com três argumentos funcionando, e um `__post_init__` que chama o validador para que prioridades inválidas não possam ser construídas por nenhum caminho. `to_dict()` foi mantido como `asdict(self)`, de modo que a prioridade aparece na saída serializada automaticamente e na ordem dos campos.

**`scheduler/repository.py`** — `JobRepository.all()` aceita um `min_priority` opcional e filtra dentro da compreensão existente `sorted(self._jobs)`, de modo que a ordem ascendente dos identificadores é garantida pelo mesmo caminho de código único que já a fornecia, em vez de ser restabelecida após a filtragem. O argumento padrão preserva o comportamento anterior sem argumentos para chamadores existentes. O armazenamento em si não precisou de alterações: o repositório armazena instâncias `Job` completas, de modo que a prioridade persiste e é transmitida nas operações `save`/`get`/`all`.

**`scheduler/service.py`** — `create_job` aceita um argumento opcional `priority` no final (padrão 0) e o valida antes de construir o `Job`, de modo que a falha é levantada no limite do serviço com o mesmo contrato `ValueError` que a verificação existente de nome em branco. `list_jobs(min_priority=0)` delega ao repositório. A ordenação e a filtragem ficam em um único local, em vez de serem duplicadas.

**Nota de projeto sobre a validação de `min_priority`:** ela é verificada quanto ao tipo como um inteiro, mas deliberadamente *não* é restrita ao intervalo de 0 a 9. A regra 0–9 restringe o que um trabalho pode armazenar; um limite é um parâmetro de consulta, e rejeitar, por exemplo, `min_priority=10` transformaria uma consulta legítima do tipo "não encontrar nada" em um erro. O fato de `list_jobs(min_priority=9)` retornar `[]` quando nenhum trabalho tem prioridade 9 é coberto por um teste.

O arquivo `scheduler/time_rules.py` foi lido, mas não sofreu alterações — a mudança relacionada ao horário de verão documentada nele é um comportamento pré-definido já existente, fora do escopo desta tarefa, e alterá-la teria sido uma mudança de comportamento não relacionada. Nenhum arquivo foi adicionado ou removido, portanto `fixture-manifest.json` permanece correto (verificado programaticamente).

### Cobertura de teste adicionada

Padrão 0; ida e volta no armazenamento via `JobRepository`; prioridade na saída de `to_dict()`; valores limite 0 e 9 aceitos; valores fora do intervalo −1/10/100 rejeitados; valores não inteiros `"3"`/`3.5`/`None`/`True` rejeitados; validação direta no nível do modelo; ordem de listagem não filtrada; listagem filtrada preservando a ordem ascendente dos identificadores; limite inclusivo; resultado vazio; `min_priority` não inteiro rejeitado.

Correção de bugs em casos extremos

O T3 testou uma falha na programação relacionada ao horário de verão. Ambos os agentes obtiveram 30/30 e foram aprovados nas mesmas verificações ocultas da primavera e do outono. O código Claude adicionou cobertura explícita para horários locais ambíguos e ignorados, entradas simplistas e rolagens de vários dias. O Codex fez uma alteração mais restrita no dia do calendário e foi aprovado no contrato congelado.

Testes mais abrangentes de casos extremos geram confiança quando a biblioteca é amplamente reutilizada ou quando o custo de um erro de agendamento é alto. Uma alteração restrita é atraente quando o defeito está bem isolado e a equipe deseja minimizar as mudanças de comportamento. A questão prática da revisão não é “Qual deles escreveu mais?”, mas sim se o patch corrige a causa raiz identificada, preserva os contratos relacionados e comprova os limites de risco.

Causa principal: a implementação adicionou 24 horas UTC decorridas.

Correção: avançar um dia do calendário local. As verificações congeladas da primavera e do outono foram aprovadas.

Foram abordados: primavera e outono, horários locais omitidos e ambíguos, entradas simplificadas e rolagens de vários dias.

Ambas as verificações ocultas congeladas foram aprovadas após uma cobertura mais ampla de regressão.

Implementada a correção do horário de verão.

Arquivos alterados:

- [scheduler/time_rules.py](./scheduler/time_rules.py)
- [tests/test_time_rules.py](./tests/test_time_rules.py)

Alterações:

- Avança um dia do calendário local em vez de 24 horas UTC.
- Adicionados testes de regressão para o avanço e recuo do horário de verão em Nova York.
- Verificado que os intervalos UTC decorridos são de 23 e 25 horas, respectivamente.

Verificações:

- Testes unitários: 4 aprovados.
- Verificação de sintaxe na memória: 7 arquivos Python foram aprovados.
- A compilação do bytecode foi bloqueada porque o Python redireciona seu cache para fora do espaço de trabalho designado; nenhum arquivo externo foi gravado.

**Conclusão:** `next_daily_run` agora preserva a hora do relógio de parede solicitada durante as transições do horário de verão. Não é necessária nenhuma decisão.

Registro de execução do # T3 — Correção de bug no DST

Parâmetros de execução do #

| Campo | Valor |
| --- | --- |
| Tarefa | `T3` |
| Prompt congelado | `01-prompts/T3.md` |
| SHA-256 do prompt congelado | `3fee50d0230f27f8d6dd7f12e050fa3f0b7f5fb77d9559361fee96e5f1a47307` |
| Unidade de execução | subagente Claude isolado, `uso geral`, contexto novo |
| Método de isolamento | **recurso alternativo do subagente** (reversão documentada — consulte `results/isolation-decision.md`) |
| Cópia limpa atribuída | `runtime/workspaces/T3` |
| Versão do código Claude | `2.1.220` |
| Configuração do modelo | `claude-opus-5` |
| start_utc | `2026-07-28T10:28:05Z` |
| end_utc | `2026-07-28T10:30:03Z` |
| Duração | 118 s (simultânea com T1, T2, T4; não é uma medição de latência precisa) |
| Número da tentativa | 1 |
| Status | `válido` |
| Intervenção humana | nenhuma |

## Resumo da ferramenta segura

`date`, `Leitura`/`Edição` apenas dentro do espaço de trabalho designado, `python3 -m unittest discover`,
`python3 -m compileall`, uma execução de controle negativo na memória, uma verificação de integridade do manifesto.
Apenas biblioteca padrão (`datetime`, `zoneinfo`, `unittest`). Sem rede, sem instalações.

## Arquivos alterados

`scheduler/time_rules.py` (a correção — apenas o corpo e a string de documentação de `next_daily_run`),
`tests/test_scheduler.py` (adicionado `NextDailyRunTests`, 8 testes, além de um auxiliar `_elapsed`;
testes existentes inalterados). Nenhum outro módulo foi alterado, nenhum arquivo foi adicionado. Patch completo:
`results/T3/patch.diff`.

## Resultados da verificação offline

Relatado pelo executor de tarefas:

| Verificação | Resultado |
| --- | --- |
| `python3 -m unittest discover -s tests -v` | **10 aprovados, 0 reprovados** (2 pré-existentes + 8 novos) |
| `python3 -m compileall -q scheduler tests` | sem erros |
| integridade do manifesto em relação a `fixture-manifest.json` | 0 ausentes, 0 inesperados |
| controle negativo: implementação inicializada corrigida na memória, apenas `NextDailyRunTests` | 8 executados, **5 falharam conforme esperado**, incluindo ambos os testes de horário de verão |

Reverificado de forma independente pelo coordenador de fora do espaço de trabalho:

| Verificação | Saída | Resultado |
| --- | --- | --- |
| conjunto de testes público (`results/checks/T3-public.txt`) | 0 | 10 testes, OK |
| validador oculto `03-checks/test_t3_hidden.py` (`results/checks/T3-hidden.txt`) | 0 | 2 testes, OK |

O validador oculto falha (saída 1) ao ser executado em uma cópia inalterada do fixture. Consulte
`results/checks/validator-controls.md`.

## Cobertura de comportamento do mapa de referência

Todos os quatro comportamentos exigidos em `03-checks/gold-map.json` foram atendidos:

| Comportamento exigido | Evidência |
| --- | --- |
| hora do relógio de parede preservada | incremento aplicado ao relógio de parede local simples, fuso horário reatribuído; verificado em todos os testes de horário de verão |
| Transição de primavera coberta | `test_spring_forward_keeps_requested_hour` — hora 09:30 mantida, deslocamento `-04:00`, tempo decorrido 23 h |
| Transição de outono coberta | `test_fall_back_keeps_requested_hour` — hora 09:30 mantida, deslocamento `-05:00`, tempo decorrido de 25 h |
| Fuso horário da IANA utilizado | `ZoneInfo("America/New_York")` da biblioteca padrão |

Além do conjunto exigido, o executor também cobriu os dois casos extremos da PEP 495 — um tempo real
ignorado pelo avanço da hora no verão e um tempo real ambíguo durante o recuo da hora no outono — além de rolagens de sete dias
que abrangem cada transição e o comportamento de entrada ingênua.

## Erros corrigidos

Duas falhas de asserção de teste autoinfligidas: `following - previous` em duas datas e horários que compartilham um
`tzinfo` subtrai relógios de parede ingênuos, de modo que as asserções de tempo decorrido indicavam 1 dia e falharam.
A implementação estava correta e as asserções estavam erradas; corrigido com um auxiliar `_elapsed`
que converte ambos os operandos para UTC primeiro. Sem erros de ferramentas, importação ou ambiente.
Os artefatos `__pycache__` foram removidos após a execução.

## Saída visível (textual)

**Reprodução**

`scheduler/time_rules.py::next_daily_run` foi chamado com uma data e hora `America/New_York` em cada lado de uma transição para o horário de verão de 2024:

```
2024-03-09T09:30:00-05:00 -> 2024-03-10T10:30:00-04:00   # a hora sofreu um desvio de +1
2024-11-02T09:30:00-04:00 -> 2024-11-03T08:30:00-05:00   #: a hora sofreu um desvio de -1
```

Um trabalho solicitado para as 09:30 locais foi executado às 10:30 após o avanço do relógio no verão e às 08:30 após o atraso no outono.

**Causa raiz**

A implementação inicial tratava "diário" como uma duração absoluta fixa:

```python
elapsed = previous_run.astimezone(timezone.utc) + timedelta(hours=24)
return elapsed.astimezone(previous_run.tzinfo)
```

A conversão para UTC primeiro faz com que `timedelta(hours=24)` resulte exatamente em 24 horas decorridas. Mas um dia do calendário local em um fuso horário da IANA tem 23 horas no dia do adiantamento do relógio e 25 horas no dia do atraso, portanto, um deslocamento constante de 24 horas necessariamente resulta em um desvio de uma hora em relação à hora do relógio de parede solicitada.

**A correção** (`scheduler/time_rules.py`)

A recorrência diária é uma regra de calendário; portanto, o incremento agora é aplicado ao relógio local simples, com o fuso horário reatribuído posteriormente:

```python
tzinfo = previous_run.tzinfo
naive_next = previous_run.replace(tzinfo=None) + timedelta(days=1)
if tzinfo is None:
    return naive_next
candidate = naive_next.replace(tzinfo=tzinfo, fold=0)
return candidate.astimezone(timezone.utc).astimezone(tzinfo)
```

Por que está correto:
- A aritmética do relógio de parede sobre o valor “naive” é independente do deslocamento, portanto a hora e os minutos solicitados são preservados por definição; `zoneinfo`, então, fornece o deslocamento UTC em vigor na nova data (verificado: `-04:00` após o avanço do relógio na primavera, `-05:00` após o atraso no outono, com tempo real decorrido de 23 h e 25 h, respectivamente).
- `fold=0`, somado ao ciclo de ida e volta do UTC, lida com os dois casos extremos que a aritmética pura do relógio de parede deixa mal definidos. De acordo com a PEP 495, uma hora de relógio de parede *pulada* (02:30 em 10/03/2024) tem o deslocamento pré-transição em `fold=0`; assim, a viagem de ida e volta o normaliza para o instante real 03:30 EDT, em vez de retornar uma data e hora que não especifica nenhum instante. Um tempo real *ambíguo* (01:30 em 03/11/2024) é resolvido de forma determinística para sua primeira ocorrência (EDT), em vez de ser arbitrário.
- A entrada simples mantém seu significado anterior (apenas +1 dia do calendário) — nenhum novo requisito do `tzinfo` é imposto aos chamadores.

O escopo foi mantido restrito: apenas o corpo/docstring de `next_daily_run` foi alterado. `service.py`, `models.py`, `repository.py` e `__init__.py` permaneceram inalterados, nenhum novo arquivo foi adicionado e o manifesto de fixtures ainda corresponde exatamente (sem arquivos ausentes ou inesperados). Apenas biblioteca padrão (`datetime`, `zoneinfo`, `unittest`).

**Testes de regressão** (`tests/test_scheduler.py`, novo `NextDailyRunTests`, 8 testes) abrangem: estabilidade em dias normais, mudança para o horário de verão + deslocamento + 23 h decorridas, mudança para o horário de inverno + deslocamento + 25 h decorridas, ciclos de sete dias abrangendo cada transição, tempo real pulado, tempo real ambíguo e entrada ingênua.

Duas observações que vale a pena registrar. Primeiro, minhas asserções iniciais de tempo decorrido usavam `seguinte - anterior`; o Python ignora um `tzinfo` compartilhado e subtrai relógios de parede ingênuos, de modo que ambas retornaram 1 dia e falharam. A implementação estava correta e as asserções estavam erradas — corrigido com um auxiliar `_elapsed` que converte ambos os operandos para UTC. Segundo, verifiquei se os testes realmente detectavam o defeito original, executando novamente `NextDailyRunTests` em uma cópia na memória da implementação inicializada: 5 de 8 falharam, incluindo os dois testes de horário de verão. Os três que passam na versão com bug (dia comum, ignorado, ambíguo) servem para documentar o comportamento, e não para detectar regressão — os casos ignorados/ambíguos coincidem porque um deslocamento absoluto de +24 h acaba caindo no mesmo instante normalizado.

Qualidade da revisão de código e verificação humana

As tarefas de revisão de código exigem habilidades diferentes das necessárias para a implementação de funcionalidades. Um revisor competente deve identificar problemas reproduzíveis, classificar seu impacto, indicar o caminho exato do código e distinguir um defeito real de um aviso especulativo. A correção de um problema acrescenta mais um teste: o patch não deve introduzir uma nova regressão.

O código Claude apresentou a vantagem mais clara no T4. Ele relatou cinco resultados reproduzíveis de forma independente, incluindo os dois alvos de revisão pré-definidos, e obteve 19/20. O Codex relatou e corrigiu dois defeitos válidos de gravidade mais elevada, mas não mencionou o par pré-definido, obtendo 18/20. Os resultados do Codex não foram falsos positivos; a diferença observada foi de abrangência, e não de correção básica.

1. Alto — Os trabalhos existentes poderiam ser sobrescritos sem aviso prévio.

2. Médio — As execuções diárias sofreram desvios durante as transições para o horário de verão.

Verificação: quatro testes aprovados, zero falhas.

D1 Desvio do horário de verão (DST) · Alto
D2 Aquisição simplista do fuso horário · Médio
D3 Colisão de identificadores · Alto
D4 A tentativa de exclusão de um item ausente gera um KeyError · Médio
D5 Proprietário não validado · Baixo

## Conclusões que requerem ação

1. **Alto — Os trabalhos existentes podem ser sobrescritos sem aviso**

   - Evidência: inicialização do identificador em [service.py](./scheduler/service.py:8), combinada com a substituição do dicionário em [repository.py](./scheduler/repository.py:9).
   - Impacto: a criação de um serviço com um repositório existente poderia reutilizar o identificador `1`, substituindo a tarefa armazenada e causando perda de dados.
   - Reprodução mínima: salve `Job(1, ...)`, construa `SchedulerService(repository)` e, em seguida, crie outra tarefa. Antes da correção, apenas a nova tarefa permanecia.
   - Correção: inicializar o próximo identificador a partir do maior identificador existente no repositório.
   - Teste de regressão: [test_scheduler.py](./tests/test_scheduler.py:22).

2. **Médio — Execuções diárias sofriam desvios nas transições para o horário de verão**

   - Evidência: cálculo corrigido em [time_rules.py](./scheduler/time_rules.py:4).
   - Impacto: uma tarefa diária agendada para as 09:00 foi executada às 10:00 após a transição para o horário de verão na primavera.
   - Reprodução mínima: calcule a próxima execução após `2026-03-07 09:00 America/New_York`. Antes da correção, o resultado era `2026-03-08 10:00`.
   - Correção: adicionar um dia do calendário local em vez de 24 horas UTC decorridas.
   - Teste de regressão: [test_scheduler.py](./tests/test_scheduler.py:33).

## Arquivos alterados

- [scheduler/service.py](./scheduler/service.py)
- [scheduler/time_rules.py](./scheduler/time_rules.py)
- [tests/test_scheduler.py](./tests/test_scheduler.py)

## Verificação

- Observou-se que ambos os testes de regressão falharam antes de suas correções.
- Cada um foi aprovado após a correção correspondente.
- `PYTHONDONTWRITEBYTECODE=1 python3 -m unittest discover -s tests -v`
- Resultado: **4 testes aprovados, 0 falhas**.
- Não restam artefatos de cache de Python gerados.

## Conclusão e decisão

- **Conclusão:** Ambos os defeitos confirmados foram corrigidos e estão cobertos por testes de regressão específicos.
- **Decisão necessária:** Nenhuma.

Registro de execução do # T4 — Teste e revisão de código

Parâmetros de execução do ##

| Campo | Valor |
| --- | --- |
| Tarefa | `T4` |
| Prompt congelado | `01-prompts/T4.md` |
| SHA-256 do prompt congelado | `5e69546007ea776f40b3d334ddb75671ff684c151c77551bad27de3b0fdce640` |
| Unidade de execução | subagente isolado Claude, `uso geral`, contexto novo |
| Método de isolamento | **recurso alternativo do subagente** (reversão documentada — consulte `results/isolation-decision.md`) |
| Cópia limpa atribuída | `runtime/workspaces/T4` |
| Versão do código Claude | `2.1.220` |
| Configuração do modelo | `claude-opus-5` |
| start_utc | `2026-07-28T10:28:22Z` |
| end_utc | `2026-07-28T10:32:17Z` |
| Duração | 235 s (simultânea com T1–T3; não é uma medição de latência pura) |
| Número da tentativa | 1 |
| Status | `válido` |
| Intervenção humana | nenhuma |

A condição no prompt congelado — "corrija-os se a configuração de execução congelada permitir
correções" — foi resolvida pelo coordenador a partir de `00-control/run-config.json` e
`00-control/safety-policy.json`, que permitem a gravação de cópias isoladas de fixtures. O executor foi
informado de que as correções são permitidas. Nenhum arquivo de controle foi exibido a ele.

## Resumo da ferramenta segura

`date`, `Read`/`Edit`/`Write` apenas dentro do espaço de trabalho atribuído, `grep`,
`python3 -m unittest discover`, `python3 -m compileall`, uma execução de vacuidade com cópia temporária, uma
verificação de presença do manifesto. Sem rede, sem instalações, apenas biblioteca padrão.

## Arquivos alterados

`scheduler/time_rules.py` (modificado), `scheduler/service.py` (modificado),
`tests/test_scheduler.py` (modificado, +2 testes), `tests/test_time_rules.py` (adicionado, 5 testes).
Patch completo: `results/T4/patch.diff`.

## Resultados da verificação offline

Relatados pelo executador de tarefas:

| Verificação | Resultado |
| --- | --- |
| `python3 -m unittest discover -s tests -v` | **9 aprovados, 0 reprovados, 0 ignorados** (linha de base 2) |
| `python3 -m compileall -q scheduler tests` | aprovado |
| verificação da presença do manifesto em relação a `expected_files` | todos os 8 presentes |
| execução do vacuity contra as implementações originais restauradas | 5 falhas, 4 aprovados, conforme esperado |

Verificado novamente de forma independente pelo coordenador de fora do espaço de trabalho:

| Verificação | Saída | Resultado |
| --- | --- | --- |
| conjunto de testes público (`results/checks/T4-public.txt`) | 0 | 9 testes, OK |

Verificação cruzada informativa, sem pontuação: o validador oculto T3 também é aprovado neste
espaço de trabalho (saída 0), pois o T4 corrigiu de forma independente o mesmo defeito `next_daily_run`. Consulte
`results/checks/validator-controls.md`.

## Cobertura de defeitos no mapa de referência

O arquivo `03-checks/gold-map.json` insere dois defeitos para pontuação do T4. Ambos foram encontrados:

| Defeito inserido | Encontrado | Relatado como |
| --- | --- | --- |
| proprietário em branco aceito | sim | **D5**, `scheduler/service.py:11,13`, gravidade Baixa, relatado e deliberadamente não corrigido |
| a exclusão de um identificador ausente gera `KeyError` | sim | **D4**, `scheduler/repository.py:19` → `service.py:22`, gravidade Média, relatado e deliberadamente não corrigido |

Três descobertas adicionais foram relatadas além do conjunto inserido. Nenhuma delas é um falso positivo:

- **D1** — Desvio do horário de verão (DST) em `next_daily_run`. Este é o terceiro defeito listado em
  `03-checks/seeded-defects.md` (ele está classificado como T3, não como T4, mas é um bug plantado genuíno).
- **D2** — uma entrada ingênua em `next_daily_run` obtém silenciosamente o fuso horário do host e retorna uma
  data e hora com essa informação. Real e dependente do host; verificado pelo coordenador em relação ao código-fonte do fixture.
- **D3** — colisão de identificadores entre um serviço e um repositório injetado ou compartilhado, causando
  sobrescrita silenciosa. Real: `SchedulerService._next_identifier` sempre começa em 1, enquanto
  `JobRepository.save` é uma atribuição de dicionário desprotegida. O T1 identificou independentemente a mesma
  falha a partir do fixture original.

Contagem de falsos positivos: **0**. O executor também relatou corretamente que não havia achados de segurança, observando
que o fixture não apresenta vulnerabilidades relacionadas a rede, E/S, desserialização, subprocessos ou credenciais.

## Desvio digno de registro

O prompt congelado solicitou testes e correções para "os dois defeitos com maior confiança". O
executor selecionou D1/D2 (uma correção, mesma função) e D3, em vez dos dois defeitos plantados no mapa de referência
D4 e D5. A razão apresentada é defensável: D4 e D5 dependem de um contrato de API
não especificado, portanto, corrigi-los seria um palpite. O crédito pela detecção não foi afetado — ambos os defeitos predefinidos
foram encontrados, com arquivo, linha, gravidade, impacto e reprodução. As correções aplicadas foram em defeitos reais
e são respaldadas por uma verificação de vacuidade.

## Erros corrigidos

Duas falhas de teste autoinfligidas decorrentes da subtração entre tempo real e tempo absoluto em datas e horários
que compartilham um `tzinfo`; corrigidas e verificadas novamente. Sem erros de ferramentas ou ambiente. Artefatos `__pycache__`
foram removidos após a execução.

## Saída visível (textual)

### Relatório de defeito

**D1 — `scheduler/time_rules.py:10-11` — A programação diária apresenta desvio de uma hora devido ao horário de verão — Gravidade: Alta**

`next_daily_run` adiciona 24 horas *decorridas* por meio de uma ida e volta no UTC, em vez de avançar o dia do calendário. Uma tarefa diária é definida pela hora do relógio, portanto, todas as tarefas em uma zona que adota o horário de verão são executadas silenciosamente uma hora mais cedo ou mais tarde a partir do dia da transição, e o erro persiste (cada execução é reiniciada a partir da hora deslocada). A própria string de documentação admitia esse comportamento.

```
prev = datetime(2024, 3, 9, 9, 0, tzinfo=ZoneInfo("America/New_York"))
next_daily_run(prev)   # -> 2024-03-10 10:00:00-04:00, esperado 09:00-04:00
prev = datetime(2024, 11, 2, 9, 0, tzinfo=ZoneInfo("America/New_York"))
next_daily_run(prev)   # -> 03/11/2024 08:00:00-05:00, esperado 09:00-05:00
```

**D2 — `scheduler/time_rules.py:10-11` — Uma entrada ingênua adquire silenciosamente o fuso horário local da máquina — Gravidade: Média**

As mesmas duas linhas. `.astimezone(timezone.utc)` em um datetime ingênuo assume a hora local do sistema, e `.astimezone(None)` retorna um datetime consciente. Uma chamada com entrada ingênua retorna uma saída consciente, portanto o resultado não é comparável com os outros valores ingênuos do chamador (`TypeError` na comparação) e a resposta depende do `TZ` do host.

```
next_daily_run(datetime(2024, 1, 1, 9, 0))
# -> datetime(2024, 1, 2, 9, 0, tzinfo=timezone(timedelta(hours=8), 'CST'))  # dependente do host
```

**D3 — `scheduler/service.py:8,13,15` (prefixo) — Colisão de identificadores destrói silenciosamente tarefas armazenadas — Gravidade: Alta**

O contador de IDs era específico para cada `SchedulerService` e sempre começava em 1, ignorando o conteúdo do repositório injetado. Qualquer segundo serviço em um repositório compartilhado, ou qualquer serviço em um repositório pré-preenchido, reemitia o ID 1; `JobRepository.save` é uma atribuição a um dicionário, portanto, a tarefa existente era sobrescrita sem gerar erro. Perda de dados.

```
repo = JobRepository()
SchedulerService(repo).create_job("Backup noturno", "Alex")    # id 1
SchedulerService(repo).create_job("Exportação da folha de pagamento", "Blake")   # id 1 novamente
repo.all()   # -> [Job(1, 'Exportação da folha de pagamento', 'Blake')]  — A tarefa do Alex sumiu
```

**D4 — `scheduler/repository.py:19` → `scheduler/service.py:22` — `delete_job` gera um `KeyError` para um id desconhecido — Gravidade: Média**

`delete` usa `dict.pop` sem um valor padrão, enquanto o método irmão `get` (linha 13) retorna `None` caso não encontre o item. Essa inconsistência gera um `KeyError` não tratado por meio de `SchedulerService.delete_job`, que provavelmente não será interceptado pelos chamadores. Reprodução: `SchedulerService().delete_job(999)` → `KeyError: 999`. A correção seria `pop(identifier, None)` ou uma exceção de domínio explícita — deixada deliberadamente sem correção, já que o contrato correto (operação nula silenciosa vs. erro tipado) é uma decisão de API a cargo do proprietário.

**D5 — `scheduler/service.py:11,13` — O campo `owner` não é validado — Gravidade: Baixa**

O campo `name` é verificado quanto a valores em branco, mas o `owner` não: `create_job("ok", "   ")` armazena `owner=''`. Ambos os parâmetros também chamam `.strip()` sem proteção, de modo que `None` é exibido como `AttributeError: 'NoneType' object has no attribute 'strip'`, em vez do `ValueError` que a API normalmente usa para entradas inválidas. Deixado sem correção — o contrato pretendido para `owner` não está declarado em nenhum lugar do fixture.

**Segurança:** nenhuma falha encontrada. O fixture não apresenta vulnerabilidades relacionadas a rede, E/S, desserialização, subprocessos ou credenciais; o armazenamento é um dicionário interno ao processo.

**Lacuna de cobertura:** `scheduler/time_rules.py` e `scheduler/repository.py` tinham cobertura de teste igual a zero antes desta execução; os dois testes iniciais exerceram apenas o caminho normal do serviço.

### Testes e correções aplicadas

Os dois defeitos com maior grau de confiança foram **D1/D2** (mesma função, uma correção) e **D3**.

**Correção 1 — `scheduler/time_rules.py`:** substituiu a ida e volta ao UTC por `previous_run + timedelta(days=1)`. O Python realiza cálculos com tempo real em datetimes conscientes, e o `zoneinfo` resolve novamente o deslocamento UTC de forma preguiçosa a partir do novo tempo real — assim, 09:00 permanece 09:00 enquanto o deslocamento se altera corretamente de `-05:00 → -04:00`. Isso corrige D1 e D2 juntos: entradas ingênuas agora permanecem ingênuas e o fuso horário local nunca é inferido. O caso de hora de transição entre “inacessível” e “ambíguo” está documentado como estando sujeito às regras de resolução do `tzinfo`.

**Correção 2 — `scheduler/service.py`:** removido o contador `_next_identifier` por instância; os identificadores agora são alocados a partir do estado do repositório como `max(IDs existentes, padrão=0) + 1` no momento da criação. Isso está correto tanto para repositórios compartilhados quanto para os pré-preenchidos. Compromisso: O(n) por criação em vez de O(1), aceitável para um armazenamento em memória baseado em dicionário, e correção em relação a um contador que não tem acesso ao armazenamento no qual grava.

**Testes — `tests/test_time_rules.py` (novo, 5 testes):** preservação do relógio de parede durante o avanço e o recuo do horário, tempo decorrido absoluto de 23h/25h nessas transições, redefinição do deslocamento UTC, “naive-stays-naive” e um simples avanço de um dia no UTC. Ignora corretamente se não houver banco de dados da IANA disponível.

**Testes — `tests/test_scheduler.py` (ampliado, +2 testes):** dois serviços que compartilham um repositório devem emitir IDs distintos e manter ambas as tarefas; um serviço em um repositório pré-preenchido com os IDs 1 e 7 deve emitir o 8 e deixar as tarefas existentes intactas.

**Verificação de vacuidade:** restaurei ambas as implementações originais em uma cópia temporária e executei novamente o conjunto de testes — todos os 5 novos testes falharam (`FAILED (failures=5)`), e todos foram aprovados com o código corrigido. Os testes realmente identificam os defeitos.

Uma correção durante a execução: meu primeiro rascunho verificava o tempo decorrido no horário de verão (DST) como `resultado - anterior`, o que o Python avalia como aritmética de relógio de parede quando ambos os operandos compartilham um tzinfo; por isso, ele interpretou como `24h` e os testes falharam. As verificações agora convertem para UTC antes da subtração. A falha estava no meu teste, não na correção.

### Notas para o responsável

O `fixture-manifest.json` não foi alterado, portanto, o `tests/test_time_rules.py` é um novo arquivo válido que não consta na lista `expected_files` — atualize o manifesto se uma verificação exigir um conjunto exato de arquivos. E os D4/D5 foram relatados, mas deliberadamente não corrigidos: ambos dependem de uma decisão de contrato de API (semântica de “miss-on-delete”, regras de validação do proprietário) que não está especificada em nenhuma parte do fixture; portanto, escolher uma opção teria sido um palpite, e não uma correção.

Nenhuma dessas pontuações dispensa a necessidade de revisão humana. Depois que qualquer um dos agentes concluir um reparo, inspecione as interfaces alteradas, o escopo inesperado dos arquivos, a ausência de testes negativos, o histórico de permissões ou comandos e o caminho de reversão. Uma explicação convincente não substitui um teste reproduzível.

Permissões, sandboxing e segurança operacional

Um agente de codificação pode ler código privado, executar comandos do shell, modificar diversos arquivos e chamar ferramentas externas. Isso faz com que o projeto das permissões seja parte integrante da qualidade do produto. As questões relevantes são: quais operações exigem aprovação, a que o agente tem acesso por padrão, com que clareza ele alerta sobre ações de risco e se um desenvolvedor pode inspecionar as alterações resultantes.

Não considere que um número menor de solicitações de aprovação seja automaticamente melhor. A redução do atrito é útil em um ambiente isolado, sem credenciais ou conexões de produção. O mesmo comportamento pode ser perigoso em um repositório conectado a scripts de implantação, dados reais de clientes ou permissões amplas na nuvem. Por outro lado, um número excessivo de aprovações pode tornar a automação segura impraticável e incentivar os usuários a aprovar solicitações sem lê-las.

Nosso teste utilizou cópias locais recentes, sem sistemas de produção, sem implantação e sem intervenção humana em execução válida. Portanto, ele avalia a conclusão das tarefas em condições seguras, e não a segurança relativa dos dois produtos. Antes de usar qualquer uma das ferramentas em trabalhos importantes, comece com acesso somente leitura, defina os diretórios e comandos permitidos, analise as diferenças e execute verificações objetivas em um ambiente recuperável.

• Comece com uma arquitetura somente leitura ou opte pela abordagem de risco.
• Aprove apenas comandos cujo escopo e consequências você compreenda.
• Mantenha as credenciais, os dados de produção e o acesso à implantação fora do ambiente de teste.
• Exija um diff, testes e um caminho claro para reversão antes de aceitar o resultado.

MCP, competências, instruções do projeto e personalização

Ambos os ecossistemas podem ser ampliados, mas os termos de extensão não devem ser tratados como sinônimos. As instruções do projeto orientam um agente sobre como se comportar em um repositório. As habilidades reutilizáveis agrupam um fluxo de trabalho repetível ou um conjunto de conhecimentos especializados. O MCP conecta um host a ferramentas ou dados externos. Os ganchos e comandos podem automatizar momentos específicos em um ciclo de desenvolvimento. Um produto pode ser forte em uma camada sem necessariamente corresponder a um recurso de outra camada ponto a ponto.

A questão para a compra não é se existe um logotipo de integração. É se a conexão pode ser instalada, autenticada, aprovada e utilizada no host que você realmente usa. Também é necessário que haja um modo de falha compreensível. Um servidor MCP que funciona de forma interativa, mas aguarda aprovação em uma sessão autônoma, ainda é útil, mas não deve ser descrito como automação sem atritos.

As instruções reutilizáveis apresentam uma ressalva semelhante. Arquivos de instruções extensos não garantem o cumprimento das regras, e um conjunto de regras excessivamente complicado pode obscurecer o contexto ou gerar contradições. Mantenha as orientações do repositório concisas, testáveis e próximas ao código. Especifique os comandos de verificação obrigatórios, as áreas protegidas, as regras de estilo e os momentos em que o agente deve interromper a execução para solicitar orientação.

• Instruções do projeto: regras específicas do repositório e comandos de verificação.
• Competências: procedimentos reutilizáveis ou pacotes de conhecimentos especializados.
• MCP: conexões com ferramentas e dados externos.
• Ganchos e comandos: automação em torno de eventos definidos no fluxo de trabalho.

Codex vs. Claude: preços e limites de uso

A comparação de planos básicos começa em $20 por mês. O acesso ao Codex está incluído no plano $20 ChatGPT correspondente, enquanto o Claude Pro custa $20 por mês nos Estados Unidos e inclui o Claude Code. Ambos oferecem planos para consumidores com uso mais intenso, de $100 e $200. Preços de tabela semelhantes não significam capacidade idêntica.

O plano Claude Max 5x custa $100 por mês e o plano Max 20x custa $200 por mês. Os nomes “5x” e “20x” descrevem o uso por sessão em relação ao plano Pro, e não um número garantido de tarefas de codificação. Os planos Claude e Claude Code compartilham os limites de sessão e semanais. O comprimento do contexto, os arquivos anexados, a escolha do modelo e o uso de recursos podem alterar a rapidez com que a cota é consumida.

Os créditos de uso opcionais do Claude podem dar continuidade ao trabalho elegível após o uso incluído, quando ativados, e esses créditos são cobrados separadamente de acordo com as tarifas padrão da API. A autenticação por chave de API é outra modalidade de cobrança separada. Chamar qualquer uma dessas modalidades de “ilimitada” ocultaria o custo marginal real.

O Codex também distingue entre o uso incluído no plano do consumidor, os créditos adquiridos elegíveis e o faturamento da API. As mensagens locais e os chats na nuvem compartilham um intervalo de cinco horas, e também podem ser aplicados limites semanais. Um campo de token em um log da CLI não pode ser convertido diretamente em uma porcentagem de cinco horas, no valor do crédito da assinatura ou na fatura da API.

Para trabalhos ocasionais de programação individual, o nível $20 em qualquer um dos lados é o ponto de partida mais sensato. O trabalho diário com repositórios em contextos extensos pode justificar um nível de uso mais alto, mas somente após observar reinicializações reais e o consumo de tarefas. Trabalhos paralelos intensivos exigem ainda mais cuidado: pagar por um nível maior não elimina a necessidade de controlar o contexto, dividir tarefas e reservar recursos de raciocínio mais onerosos para trabalhos que exijam alto grau de julgamento.

O que nosso teste comparativo entre o Codex e o Código Claude revelou

Congelamos quatro prompts em inglês, um recurso público do Python, verificações objetivas, uma tabela de avaliação e uma regra de “primeiro resultado válido” antes de qualquer um dos agentes ser executado. As tarefas abrangeram a compreensão de repositórios desconhecidos, um recurso com vários arquivos, a correção de um bug no DST e a revisão de código com correções. Resultados válidos não receberam intervenção humana, e saídas fracas, mas válidas, não puderam ser executadas novamente para obter uma pontuação melhor.

O Codex foi executado em processos CLI isolados, com JSONL bruto e campos de tokens emitidos pela CLI mantidos. A sessão OAuth da CLI do Claude do colega havia expirado; por isso, o Claude Code utilizou um coordenador com contextos de subagentes atualizados. Reconstruímos os patches do Claude em cópias de auditoria limpas e reexecutamos as verificações públicas e ocultas. Isso produziu evidências práticas confiáveis, mas não isolamentos idênticos nem superfícies de controle de modelo idênticas.

O teste é pequeno demais para avaliar o desempenho em grandes repositórios, em todas as linguagens, em todas as camadas de modelos ou em longas sessões autônomas. A diferença total de um ponto deve ser interpretada como “ambos tiveram sucesso, com uma diferença na amplitude da revisão”, e não como uma classificação universal.

O que os usuários reais relatam — e até que ponto podemos confiar nisso

O feedback da comunidade é valioso quando inclui um projeto, uma tarefa, um modelo, o contexto da iniciativa e o prazo previsto. Ele perde valor quando uma postagem se limita a afirmar que um determinado produto “parece mais inteligente” ou “é muito mais rápido”. Usuários diferentes comparam repositórios, planos de assinatura, prompts, extensões e níveis de supervisão distintos.

O exemplo contextual do Reddit acima sugere um equilíbrio entre interação e velocidade: uma abordagem rápida e coloquial pode exigir mais atenção, enquanto uma execução deliberada pode parecer mais lenta, mas requerer menos correções. Nosso teste controlado se sobrepõe apenas parcialmente a essa conta. Ele constatou velocidades variadas e nenhuma intervenção humana nas execuções válidas; portanto, não pode validar a alegação de “babysitting”. É exatamente por isso que as evidências da comunidade e as evidências controladas devem ser apresentadas juntas, sem que sejam mescladas.

O comentário sobre o “X harness” levanta um segundo ponto importante: o resultado da codificação pertence ao sistema como um todo, e não apenas ao rótulo do modelo. Nenhuma das postagens, individualmente, deve ser tratada como dados de pesquisa. Use-as para identificar questões para seu próprio teste — número de intervenções, magnitude da diferença, qualidade do teste e recuperação a partir de uma suposição incorreta.

Ampliação do Codex e do código Claude com GlobalGPT

GlobalGPT é um espaço de trabalho multimodelo e multimodal, não substitui os agentes nativos do repositório. Sua função prática é ampliar as capacidades de um host existente: utilizar outro modelo de agente disponível para uma segunda opinião, revisão de planos, verificação da documentação ou geração de resultados especializados, enquanto o Codex ou o Claude Code continuam responsáveis pelo acesso ao repositório, comandos de shell, testes e aprovações.

A GlobalGPT publica guias oficiais da CLI para Códice e Código Claude, bem como o Cursor. Em nosso teste de integração seguro do T5, a CLI concluiu a mesma tarefa congelada em ambos os ambientes comparados. No Codex, também verificamos uma chamada de lista de modelos do MCP somente para leitura e instalamos, carregamos e utilizamos a Skill GlobalGPT.

Resumo do teste de integração # GlobalGPT

Escopo do # #

O T5 avalia a integração do GlobalGPT e está excluído da pontuação de codificação nativa do Codex. O Yukie não foi utilizado.

## Bloqueio e prontidão do modelo

- Modelo A: `gpt-5.6-sol`
- Modelo B: `gpt-5.6-luna`
- Ambos os modelos apareceram na lista de modelos ativos.
- Ambos os testes de prontidão leves retornaram texto válido e analisável.
- Os modelos foram bloqueados antes das chamadas formais de saída T5A e T5B.

## Resultados formais da CLI

| Tarefa | Modelo | Status | Duração | Tokens do prompt | Tokens de conclusão | Títulos obrigatórios |
|---|---|---|---:|---:|---:|---:|
| T5A | gpt-5.6-sol | Válido | 27 s | 2.116 | 1.207 | 6/6 |
| T5B | gpt-5.6-luna | Válido | 14 s | 2.116 | 1.441 | 6/6 |

Ambas as chamadas formais utilizaram a mesma tarefa congelada de planejamento de produto em inglês por meio do `glbgpt exec`, retornaram resultados visíveis apenas em inglês e não expuseram credenciais. Não ocorreu nenhuma repetição de qualidade.

## Resultado do MCP

- O comando `codex mcp list` mostrou que o `globalgpt` estava habilitado.
- Uma sessão não interativa do Codex detectou e tentou executar `mcp__globalgpt__glbgpt_list_models`, mas a chamada foi cancelada porque a aprovação automática do MCP não estava disponível. Nenhuma configuração de segurança foi flexibilizada.
- A sessão interativa ativa do Codex chamou com sucesso a mesma ferramenta MCP GlobalGPT somente para leitura e recebeu nove modelos de chat.
- Resultado: acesso interativo ao MCP verificado; a execução não interativa e autônoma do MCP mantém uma restrição de aprovação.

Resultado da habilidade ##

- As habilidades de codificação GlobalGPT e GlobalGPT estão instaladas no diretório de habilidades do Codex por meio de links para o pacote de habilidades CLI incluído.
- A habilidade GlobalGPT foi carregada e executada para verificação da sessão configurada, seleção de modelo ativo, prontidão, opções seguras de crédito e tratamento de falhas.
- Resultado: instalada e testada no fluxo de trabalho ativo do Codex.

## Conclusão limitada

Esta execução verifica o funcionamento das chamadas CLI do GlobalGPT, uma chamada interativa de somente leitura do MCP do GlobalGPT a partir do Codex e um caminho da habilidade GlobalGPT instalado/utilizado. Ela não comprova que todos os modelos, ferramentas de mídia, hosts, contas ou configurações MCP não supervisionadas funcionem. Ela não testa o Yukie nem corrobora a alegação de que o GlobalGPT substitui o Codex ou o Claude Code.

O limite é importante. A execução do Claude pelo colega verificou o caminho do CLI, e não o MCP do lado do Claude. A Skill estava instalada lá, mas não foi utilizada para as chamadas congeladas. Uma tentativa autônoma do Codex MCP ainda precisava de aprovação manual. A disponibilidade dos modelos e os créditos também dependem do plano atual do GlobalGPT; portanto, os desenvolvedores devem verificar a lista ativa, em vez de presumir que todos os modelos estão incluídos.

O GlobalGPT também abrange imagens, vídeos, áudio e fluxos de trabalho guiados para Agentes. As entradas “Slides”, “Document” e “Image” do Yukie pertencem a uma categoria diferente: elas oferecem modelos explícitos e orientação passo a passo no navegador para tarefas que não envolvem código. Isso pode ser mais fácil do que abrir uma CLI de programação para criar uma apresentação ou um documento estruturado, mas não substitui a leitura do repositório, a execução de testes ou a revisão de código.

Qual linguagem de programação um desenvolvedor independente deve escolher?

• Escolha o Codex quando a execução compacta e limitada, a combinação de superfícies disponíveis ou as evidências de execução disponíveis na sua configuração se adequarem à sua forma de trabalhar.
• Escolha o código Claude quando o ciclo de um terminal conversacional, os recursos de personalização que você verificou ou um comportamento de revisão mais amplo, como o observado em nosso fixture, se tornam mais importantes.
• Use qualquer uma das opções para um repositório desconhecido somente após a aprovação da arquitetura de leitura exclusiva e da avaliação de riscos. Ambas as ferramentas realizaram bem essa tarefa.
• Use os dois de forma seletiva quando uma revisão por um segundo agente justifica o custo adicional de assinatura e coordenação. Peça à segunda ferramenta que questione uma diferença ou um plano, em vez de repetir a tarefa cegamente.
• Adicione GlobalGPT quando o roteamento multimodelo ou o trabalho multimodal é a camada que está faltando. Mantenha as operações nativas do repositório no host de codificação.

Um período de teste de sete dias é mais informativo do que uma tabela de classificação. Escolha um recurso real, mas que não esteja em produção, um bug e faça uma revisão. Congele o prompt e o comando de sucesso. Registre o primeiro diff válido, os testes aprovados, o tempo decorrido, as intervenções humanas, o escopo inesperado e como o trabalho afetou seu uso disponível. O melhor produto é aquele cujos erros você consegue detectar e cujo fluxo de trabalho você consegue manter.

Perguntas frequentes sobre o Codex vs. o código Claude

O Codex é melhor do que o código Claude?

Não de maneira geral. Ambos concluíram as quatro tarefas previstas em nosso plano. O Claude Code liderou em abrangência da revisão, enquanto o Codex se mostrou mais compacto em alguns aspectos da implementação e da correção de bugs.

O que é melhor para repositórios grandes?

Nosso pequeno programa não pode responder a isso. Avalie ambos em uma tarefa de arquitetura somente leitura a partir do seu próprio repositório antes de permitir alterações.

Qual agente de codificação requer menos supervisão?

Isso depende da clareza da tarefa, das configurações do modelo, das instruções do repositório e do estilo de interação desejado. Um usuário do Reddit relatou diferentes padrões de supervisão, mas essa experiência individual não constitui uma regra válida para todo o produto.

Qual é mais barato?

Os principais níveis de consumo correspondem a $20, $100 e $200 por mês, mas a capacidade incluída e as regras de limite variam. Os créditos opcionais e o faturamento por API são tratados separadamente.

Os planos Claude e Claude compartilham os limites de uso?

Sim. O Claude e o Claude Code utilizam limites compartilhados de sessão e semanais nos planos Pro ou Max associados.

As tarefas locais e na nuvem do Codex compartilham os mesmos limites?

As mensagens locais e os chats na nuvem têm um intervalo de cinco horas, e também podem ser aplicados limites semanais.

O GlobalGPT pode substituir o Codex ou o Claude Code?

Não. Ele pode ampliar qualquer um dos fluxos de trabalho com modelos adicionais, CLI, MCP, Skills e ferramentas multimodais, mas o acesso ao repositório e o comportamento do agente de programação permanecem no host.

Posso usar o GlobalGPT dos dois produtos?

O GlobalGPT oferece tutoriais oficiais sobre a CLI para ambos. Verificamos o uso da CLI nos dois ambientes e o uso do MCP e do Skill no Codex, com uma restrição de aprovação para o MCP em modo autônomo.

Os preços, as regras dos planos, as integrações e as fontes de referência foram verificados em julho de 2026. Os detalhes do produto estão sujeitos a alterações.

Abrir GlobalGPT se você quiser incorporar uma camada multimodelo e multimodal ao seu fluxo de trabalho de codificação atual.