dd-harness

Política e briefing carregados do serviço; memória consultada por MCP ou CLI. A fonte dos artefatos continua no serviço. O cliente mantém configuração, ponteiros para skills e estado descartável fora do repositório.

Requer Node >=20.3.0. CLI sem dependências de runtime.

Instalação e configuração

npm install -g dd-harness@latest
npx -y dd-harness-mcp@latest --help
dd-harness start --host todos

Para um projeto já criado no serviço:

dd-harness init --tenant meu-espaco --projeto meu-projeto
dd-harness login --token <token>
dd-harness integrar --host claude,codex,antigravity
dd-harness diagnostico --mcp

start usa Claude por padrão. --host aceita claude, codex, antigravity, uma lista separada por vírgulas ou todos. integrar instala nos três por padrão e preserva configurações alheias. O token nasce em /tokens e fica em ~/.dd-harness/credentials.json, por origem de API. Para serviço local, use init --api http://localhost:3000 antes do login.

Hosts

| Host | MCP | Boot e guarda | Skills | |---|---|---|---| | Claude Code | .mcp.json | .claude/settings.json | .claude/skills | | Codex | .codex/config.toml | .codex/hooks.json | .agents/skills | | Antigravity | .agents/mcp_config.json | .agents/hooks.json | .agents/skills |

Codex exige revisão/confiança dos hooks em /hooks. Instalação não comprova ativação. Antigravity usa PreInvocation e mensagem efêmera: política e briefing são consultados antes de cada inferência. Sua guarda usa ask para respeitar concessões já existentes; ela pode acrescentar confirmações. Não amplia permissões automaticamente.

Sem boot válido, a guarda recusa ferramentas cobertas, inclusive shell. Leitura conhecida e onboarding controlado continuam possíveis. Os hooks precisam estar ativos: não são sandbox nem controlam ferramentas que o aplicativo não encaminha a eles. Após boot válido, shell não tem análise de diff antecipada; avisos por âncora cobrem edições estruturadas, patches, remoções e renomeações.

Configurações MCP novas levam DD_HARNESS_ROOT explícito. Ao copiar/mover um checkout, confira essa raiz com diagnostico. O MCP recusa divergência entre a raiz explícita e o projeto identificado no diretório de execução. Corrija a configuração e reinicie o host.

Uso diário

dd-harness politica
dd-harness buscar "contrato de integração"
dd-harness ler regras/contrato
dd-harness gravar memoria.md
dd-harness editar memoria.md
dd-harness arquivar regras/contrato --motivo obsoleta
dd-harness status
dd-harness skills
dd-harness roadmap
dd-harness changelog
dd-harness --help

check mede e grava observações de deriva; status só consulta. O antigo comando sync não faz parte do CLI atual. politica --hook e cinto permanecem como compatibilidade legada; use integrar para instalar sessao e guarda.

Estado e conflitos

• Política/briefing não são materializados. Âncoras/resumos, sessão e manifestos ficam em ~/.dd-harness/repos, isolados por caminho/projeto/credencial quando aplicável.
• DD_HARNESS_HOME permite isolamento explícito em testes. Nunca aponte testes ao estado pessoal.
• Uma sessão validada expira em quatro horas. Boot, retomada e compactação revalidam. Alterações locais de política/briefing via MCP invalidam a sessão; reabra depois de editar. Alterações remotas feitas por outro cliente são percebidas no próximo boot/revalidação.
• Curadoria invalida as âncoras do checkout atual. A próxima edição as consulta novamente.
• Só ponteiros registrados e intactos são atualizados/removidos. Skills manuais, editadas ou redirecionadas por links são preservadas e aparecem como conflitos.
• Skills marcadas só por comando não são instaladas para descoberta automática em .agents; use listar_skills/ler_skill após pedido explícito. Metadados próprios do Claude não são prometidos como portáveis.
• Se há fila e worker local configurado, o boot solicita um lote. O log fica em ~/.dd-harness/worker.log; solicitar não significa que a indexação concluiu.

Escritas e commits

Só GET/HEAD têm retry automático (até três tentativas, timeout por tentativa). POST/PATCH/PUT/DELETE não são repetidos. Falha de conexão, 5xx ou resposta incompleta em escrita exige consultar o estado antes de tentar novamente.

A política entregue exige [IDENTIFICAÇÃO] - tipo: descrição nos commits de agentes: [CODEX] - feat: ..., [CLAUDE] - fix: ..., [GEMINI] - docs: .... Identifique quem realmente commitou, inclusive ao usar outro editor. A regra não altera Git author nem concede autorização de commit/push. É regra de trabalho do agente, não inferência automática de identidade nem hook que renomeia commits humanos.