Referência da CLI

orvienm validate <file> [--json]

Verifica uma especificação sem tocar no sistema de arquivos.

O argumento de arquivo é obrigatório. Todos os outros comandos validam antes de fazer qualquer coisa, então uma falha aqui bloqueia o resto do ciclo.

saída: 0 válido · 1 erro de validação · 4 arquivo ausente ou ilegível

orvienm plan [file]

Mostra a diferença entre a estrutura declarada e o que existe.

Imprime uma linha por diretório — create, keep ou undeclared — seguida de um resumo. Um caminho declarado é comparado junto com os diretórios que ele implica, de modo que uma entrada aninhada converge após o apply. Undeclared significa presente em disco mas ausente da especificação; o apply não o cria nem o remove.

saída: 0

orvienm apply [file] [--dry-run] [--json]

Cria a estrutura declarada.

Aditivo e conservador. Se a raiz não existe, cria a raiz e todos os diretórios declarados dentro dela, incluindo os intermediários implicados por entradas aninhadas. Se a raiz já existe, cria os diretórios declarados que estão faltando e deixa o resto intacto. Diretórios e arquivos não declarados nunca são removidos nem sobrescritos. Recusa-se a rodar quando a especificação divergiu de .orv.lock, a menos que --dry-run seja passado. Uma execução bem-sucedida registra a especificação em .orv.lock. Se um arquivo ocupa um caminho declarado como diretório, o apply o identifica, não cria nada e deixa o arquivo intacto.

saída: 0 criado, ampliado ou já conforme · 2 erro de sistema de arquivos ou um arquivo onde um diretório é declarado · 3 desvio detectado

orvienm verify <file>

Verifica se todos os diretórios declarados existem.

Imprime Status: VALID ou Status: INVALID, conferindo cada caminho declarado junto com os diretórios que ele implica. Não olha o lock file, o fingerprint nem os diretórios não declarados — use status ou doctor para isso.

saída: 0 completo · 2 um diretório declarado está faltando

orvienm status <file> [--json]

Resume raiz, estrutura, lock file e fingerprint em uma única visão.

Reporta FOUND/NOT FOUND para a raiz e para o lock file, COMPLIANT/INVALID para os diretórios declarados e MATCH/DRIFT_DETECTED para o fingerprint. O resultado geral só é CLEAN quando os quatro estão bons.

saída: 0 limpo · 2 qualquer outro caso

orvienm doctor <file> [--json] [--strict]

Diagnóstico completo, incluindo diretórios não declarados.

O único comando que reporta diretórios órfãos — presentes em disco mas ausentes da especificação — junto com diretórios faltantes e o estado do fingerprint. O diagnóstico é HEALTHY ou CRITICAL; qualquer diretório faltante, qualquer órfão ou um fingerprint divergente torna o diagnóstico CRITICAL. Por padrão apenas reporta: é o --strict que transforma um diagnóstico CRITICAL em falha. A detecção é idêntica nos dois casos, e a saída --json também.

saída: 0 · 2 com --strict quando o diagnóstico não é HEALTHY

orvienm fingerprint <file> [--json]

Imprime o fingerprint SHA-256 da especificação.

Calcula o hash de um manifesto canônico construído a partir de version, style, structure.name e da lista ordenada de diretórios. Reordenar diretórios não o altera; mudar style altera.

saída: 0

orvienm policy [file] [--strict]

Verifica as regras de policy declaradas contra a estrutura declarada.

Lê policy.forbid da especificação e reporta qualquer nome proibido encontrado dentro da estrutura declarada, em qualquer profundidade. Por padrão apenas reporta, de modo que adicionar um bloco policy não pode, por si só, tornar vermelho um pipeline que estava verde; é o --strict que faz uma violação quebrar o build. A varredura cobre a raiz da estrutura declarada, não o diretório de trabalho, então um nome proibido ao lado dessa raiz passa mesmo com --strict.

saída: 0 · 2 com --strict quando uma violação é encontrada

orvienm new <name>

Cria um projeto de exemplo em um novo diretório.

Cria name/, escreve name/.orvienm.yaml e cria core, governance e products dentro dele. Rode os comandos de ciclo de vida a partir do diretório que contém name/, e não de dentro dele — structure.name é resolvido em relação ao diretório de trabalho, então aplicar de dentro criaria uma segunda raiz aninhada.

saída: 0 · 4 se o diretório já existir

orvienm init <name>

Declara uma estrutura no diretório atual.

Escreve .orvienm.yaml no diretório atual declarando name como a raiz gerenciada, com core, governance e products dentro dela. Não cria diretório algum — quem faz isso é o apply, como em todo o resto — então um plan logo após o init mostra a estrutura inteira como pendente. O name é obrigatório e é a raiz sendo declarada: rode o init no diretório sob o qual você quer que a estrutura viva. Ele não sobrescreve uma especificação existente.

saída: 0 · 2 erro de uso se nenhum nome for informado