@orkastery/cli 0.2.0 → 0.4.1

package/adapters/openclaw/src/tipos-openclaw.d.ts

@@ -0,0 +1,58 @@
+/**
+ * Tipos minimos do SDK de plugins do OpenClaw usados por este adapter.
+ *
+ * O modulo real e resolvido em runtime pelo proprio loader do OpenClaw (alias
+ * `openclaw/plugin-sdk/*`); esta declaracao existe so para o tsc compilar sem
+ * depender do pacote openclaw no repositorio. As formas espelham
+ * `docs/plugins/tool-plugins.md` do OpenClaw 2026.7.1.
+ */
+declare module 'openclaw/plugin-sdk/tool-plugin' {
+  /** Schema JSON literal: objeto simples, sem dependencia de typebox (decisao D1). */
+  export type SchemaJson = Record<string, unknown>;
+
+  export interface ContextoDaTool {
+    signal?: AbortSignal;
+    toolCallId?: string;
+    onUpdate?: (atualizacao: unknown) => void;
+    api?: unknown;
+  }
+
+  // Inspeção do SDK instalado, hook-types-DQ9eTy2x.d.ts: campos de inbound_claim.
+  // Opcionais no SDK; ingresso nativo exige presença e igualdade com o binding.
+  export interface IdentidadeInboundClaim {
+    sessionKey?: string;
+    commandAuthorized?: boolean;
+    senderIsOwner?: boolean;
+    accountId?: string;
+    senderId?: string;
+    conversationId?: string;
+    messageId?: string;
+  }
+
+  export interface DefinicaoDeTool {
+    name: string;
+    label?: string;
+    description: string;
+    parameters?: SchemaJson;
+    optional?: boolean;
+    execute?: (
+      params: Record<string, unknown>,
+      config: Record<string, unknown>,
+      contexto: ContextoDaTool
+    ) => unknown | Promise<unknown>;
+    factory?: (contexto: { api: unknown; config: unknown; toolContext: unknown }) => unknown;
+  }
+
+  export type FabricaDeTool = (definicao: DefinicaoDeTool) => DefinicaoDeTool;
+
+  export interface DefinicaoDoPlugin {
+    id: string;
+    name: string;
+    description: string;
+    configSchema?: SchemaJson;
+    activation?: { onStartup?: boolean };
+    tools: (tool: FabricaDeTool) => DefinicaoDeTool[];
+  }
+
+  export function defineToolPlugin(definicao: DefinicaoDoPlugin): unknown;
+}

package/adapters/openclaw/tsconfig.json

@@ -0,0 +1,15 @@
+{
+  "compilerOptions": {
+    "target": "ES2022",
+    "module": "NodeNext",
+    "moduleResolution": "NodeNext",
+    "outDir": "dist",
+    "rootDir": "src",
+    "strict": true,
+    "declaration": false,
+    "skipLibCheck": true,
+    "types": ["node"],
+    "typeRoots": ["../../core/node_modules/@types"]
+  },
+  "include": ["src"]
+}

package/assets/docs/markdownlint-cli2.jsonc

@@ -0,0 +1,22 @@
+// Padronizacao de Markdown da documentacao de produto e do roadmap (Orkastery, I-44).
+// Divisao de trabalho: este linter cobre a FORMA do Markdown; `ork docs verificar` cobre
+// frontmatter, leitura (TDAH), paridade com o codigo e com o git.
+{
+  "globs": [
+    "docs/produto/**/*.md",
+    "docs/roadmap/**/*.md",
+    "docs/padroes/**/*.md",
+    "README.md"
+  ],
+  "config": {
+    "default": true,
+    // Prosa em portugues nao quebra linha em 80 colunas: um paragrafo e uma linha.
+    "MD013": false,
+    // "Historico" e "Comportamento" repetem entre paginas, nunca entre irmaos do mesmo titulo.
+    "MD024": { "siblings_only": true },
+    // O modelo usa a mesma forma de lista ordenada que o padrao do dono.
+    "MD029": { "style": "one_or_ordered" },
+    // HTML so para imagem, selo e dobra de detalhe; layout em HTML esconde a resposta da primeira linha.
+    "MD033": { "allowed_elements": ["img", "picture", "source", "br", "sub", "sup", "kbd", "details", "summary"] }
+  }
+}

package/assets/docs/padroes/documentacao-de-produto.md

@@ -0,0 +1,133 @@
+# Padrão de documentação de produto de software
+
+> Versão 1.1 · Aplicação: plataformas, sistemas, módulos e funcionalidades · Documento complementar: [Padrão de roadmap de produto](roadmap-de-produto.md)
+>
+> A versão 1.1 mantém a 1.0 e acrescenta a seção 6 (três leitores e fatos de SDLC) e o frontmatter do modelo, que o `ork docs verificar` confere.
+
+## 1. Objetivo e unidade documental
+
+Este padrão descreve **o produto e seu comportamento verificável**, do contexto da plataforma aos contratos técnicos. Crie uma página por entidade relevante; uma funcionalidade (`Feature`) é a unidade recomendada para especificar comportamento. Detalhes volumosos, como contratos OpenAPI e esquemas de dados, podem ficar em arquivos próprios, ligados por identificadores estáveis.
+
+Use a hierarquia `Plataforma → Sistema/Serviço → Módulo → Submódulo/Domínio → Feature`. Um caso de uso pertence a uma feature; uma operação representa uma ação dessa feature. Entidades e campos descrevem dados; APIs, endpoints, eventos, gatilhos e jobs descrevem interfaces e execução. Um mesmo serviço ou contrato pode atender várias features: mantenha uma fonte canônica e faça referências, sem copiar definições divergentes.
+
+O **roadmap** registra problemas, hipóteses, escolhas, prioridades e andamento das mudanças. Esta documentação registra o comportamento vigente e, quando necessário, a especificação futura explicitamente identificada. Relacione ambos por IDs e links; não trate proposta como funcionalidade já entregue.
+
+## 2. Convenções obrigatórias
+
+| Regra | Aplicação |
+| --- | --- |
+| Identidade | Atribua IDs estáveis, por exemplo `PLAT-01`, `SYS-01`, `MOD-01`, `FEAT-042`, `UC-042-01`, `BR-042-01`, `API-01`, `EVT-01`, `JOB-01` e `RM-042`. Renomear não muda o ID. |
+| Escopo e estado | Informe se a página descreve `vigente`, `em desenvolvimento`, `proposto` ou `descontinuado`, com ambiente, versão e data de verificação. |
+| Rastreabilidade | Ligue feature ↔ item de roadmap ↔ casos de uso/regras ↔ contratos/esquemas ↔ código/PR ↔ testes/evidências ↔ release. Use `Não aplicável — motivo` quando uma seção não fizer sentido. |
+| Fonte | Diferencie `confirmado` (código, contrato, teste ou decisão aprovada), `planejado` (item de roadmap) e `a validar`. Nunca complete uma lacuna por inferência silenciosa. |
+| Forma | Use português claro; preserve nomes exatos de código, endpoints, flags e eventos em crases. Datas em ISO 8601 com fuso; unidades explícitas. |
+| Responsabilidade | Registre owner humano da página, aprovador técnico quando aplicável e última revisão. Um agente de IA pode propor alterações, com fonte e revisão humana definidas pelo time. |
+| Histórico | Mudanças de comportamento exigem atualização da página e ligação ao item de roadmap/release; decisões técnicas relevantes apontam para um ADR. |
+
+## 3. Categorias de documentação
+
+Preencha os campos aplicáveis. Para entidades reutilizáveis, crie páginas próprias e ligue seus IDs à página da feature.
+
+### 3.1 Contexto e arquitetura
+
+| Campo | O que registrar |
+| --- | --- |
+| Plataforma; sistema/serviço; módulo; submódulo | IDs, nomes e links para os respectivos pais. |
+| Objetivo; limites | Problema atendido, responsabilidade do componente e o que não lhe pertence. |
+| Dependências | Serviços internos/externos e impacto em caso de falha. |
+| Repositório; localização do código | URL, diretórios e versão/commit de referência. |
+| Implantação; ambientes | Modelo de deploy, ambientes e regiões efetivamente usados. |
+| Isolamento; configuração | Modelo de tenancy e parâmetros de sistema; cite nomes, efeito, padrão e ambiente, nunca valores secretos. |
+| Retenção | Tipos de dado, prazo, descarte e política/decisão aprovada. |
+
+### 3.2 Funcionalidades e comportamento
+
+| Campo | O que registrar |
+| --- | --- |
+| Feature; atores/personas | ID, finalidade, usuários e sistemas participantes. |
+| Casos de uso; operações | IDs e nomes; operações CRUD e ações de negócio separadas. |
+| Pré-condições; gatilho | Estado necessário e ação/evento que inicia o fluxo. |
+| Fluxo principal; alternativas | Passos observáveis e caminhos de erro, cancelamento, timeout e recuperação. |
+| Pós-condições | Alterações persistidas, mensagens emitidas e efeitos externos. |
+| Regras de negócio | Regra atômica com ID, condição, resultado e exceções. |
+| Critérios de aceite | Cenários testáveis, preferencialmente Dado/Quando/Então, ligados às regras. |
+| Interface | Telas, componentes, estados, acessibilidade e referência ao protótipo aprovado. |
+
+### 3.3 Dados e campos
+
+Defina cada entidade uma vez. Para cada campo, registre `nome técnico`, `rótulo`, `tipo`, `unidade`, `obrigatoriedade`, `nulidade`, `limites`, `validação`, `formato/máscara`, `valor padrão`, `classificação de sensibilidade`, `retenção` e `origem/destino`. Explique diferenças entre representação de UI, API e banco; por exemplo, `refund_amount_cents` é inteiro em centavos e aparece como moeda na interface. Relacione tabela/migration/schema e a versão do contrato. Não use uma regex de formato como prova de validade semântica de um documento.
+
+### 3.4 APIs e integrações
+
+Registre `API/integração`, `protocolo e versão`, `provedor/consumidor`, `método e endpoint`, `path/query/header params`, `autenticação`, `autorização`, `request`, `response de sucesso`, `erros`, `paginação`, `limites de uso`, `timeout`, `idempotência`, `compatibilidade` e link para OpenAPI ou contrato canônico. Inclua exemplos sanitizados e sem credenciais; explicite o comportamento diante de falhas e versões anteriores.
+
+### 3.5 Eventos, gatilhos e tarefas agendadas
+
+Registre `ID/nome/versão do evento`, `produtor`, `gatilho`, `payload/schema`, `broker/tópico`, `consumidores`, `entrega/ordenação`, `retry/backoff`, `DLQ`, `idempotência`, `observabilidade` e `retenção`. Para jobs, inclua `ID`, `dono`, `expressão de agendamento`, `fuso horário`, `timeout`, `concorrência`, `efeitos`, `retentativa` e procedimento de reprocessamento. Um cron em UTC precisa de descrição legível e referência de fuso.
+
+### 3.6 Observabilidade e operação
+
+Registre `correlation_id/trace_id`, logs e campos permitidos, métricas técnicas e de negócio, SLI/SLO com janela de medição, alertas e limiares, dashboards, rastreamento de erros, health checks, runbook, eventos de auditoria e impacto esperado em custo/capacidade. Diferencie meta de serviço (SLO) de compromisso contratual (SLA).
+
+### 3.7 Segurança, governança e conformidade
+
+Registre risco, perfis e matriz de permissões (RBAC/ABAC), autenticação/sessão, criptografia e gestão de segredos, tratamento de dados pessoais, mascaramento em logs, validação de entrada, políticas de origem quando houver navegador, requisitos regulatórios aplicáveis, janela de manutenção e procedimento de reversão. Cite políticas internas e decisões aprovadas em vez de presumir que toda norma citada se aplica.
+
+## 4. Modelo de página de feature
+
+Copie [o modelo](../produto/_modelo-feature.md) para cada feature; substitua colchetes por valores ou por `Não aplicável — motivo`. O frontmatter é a camada que agentes e o verificador leem; o corpo é a camada que pessoas leem. Acrescente tabelas de campos e contratos quando houver vários elementos.
+
+Chaves do frontmatter de uma feature:
+
+| Chave | Conteúdo | Conferido por `ork docs verificar` |
+| --- | --- | --- |
+| `id`, `tipo`, `titulo` | `FEAT-000`, `feature`, nome | formato do ID, nome do arquivo, unicidade |
+| `estado` | `vigente`, `em desenvolvimento`, `proposto` ou `descontinuado` | valor do padrão |
+| `pai` | `MOD-00` | existe e é do nível acima |
+| `roadmap` | lista de `RM-000` | existe, e o item cita a feature de volta |
+| `owner`, `aprovador` | pessoas | presença |
+| `verificado_em`, `versao` | ISO 8601 com fuso; branch@commit | formato |
+| `fontes.codigo`, `fontes.testes`, `fontes.docs` | caminhos relativos à raiz | **existem no repositório** |
+| `fontes.simbolos` | `arquivo#nome` | **o nome aparece no arquivo** |
+| `fontes.contratos` | IDs de contrato (`ork.hitl/v2`) | **aparecem em `fontes.codigo`** |
+| `fontes.comandos` | comandos do CLI do produto | **o CLI declara o comando** |
+
+## 5. Revisão e sincronização
+
+Antes de aprovar uma mudança, confira IDs e links, comportamento e exceções, nomes e tipos contra código/migrations, contratos de API/evento, permissões, testes e ambiente real. Atualize a documentação junto à mudança de implementação; marque diferenças como `a validar` com responsável e prazo. Automação ou agente pode comparar fontes e preparar um diff, mas deve registrar o commit/contrato consultado e não converter suposição em fato. O status de execução e as decisões de prioridade ficam no [padrão de roadmap](roadmap-de-produto.md).
+
+No Orkastery essa comparação tem dono e comando:
+
+- `ork docs verificar` — roda no CI em todo PR; reprova página cujas `fontes` não existem mais, link quebrado, ID repetido ou campo de modelo esquecido.
+- `ork docs sincronizar` — roda na máquina do projeto; lê o ledger das threads e o git e atualiza **só fatos** (merge, fase), nunca status por passagem de tempo. Sem `--escrever`, só mostra o que mudaria.
+- `ork docs init` — cria esta estrutura em qualquer produto conduzido pelo Orkastery.
+
+## 6. Três leitores e fatos de SDLC (adaptação Orkastery)
+
+Cada página é lida ao mesmo tempo por três leitores. Se um deles fica para trás, a página falhou.
+
+### 6.1 Pessoa com TDAH
+
+- **Resposta primeiro.** Logo abaixo do título, uma linha `> **Em uma frase:**` com até 240 caracteres.
+- **Estado de relance.** Estado, data de verificação e versão aparecem antes de qualquer explicação.
+- **Uma ideia por linha.** Tópicos em vez de parágrafos; parágrafo com mais de 600 caracteres gera aviso.
+- **Seções sempre com o mesmo nome.** Quem já leu uma página sabe onde está cada coisa na próxima.
+- **Nada vazio em silêncio.** Seção sem conteúdo diz `Não aplicável — motivo` ou `A definir — responsável, prazo`.
+
+### 6.2 Verificador de paridade
+
+- A página afirma coisas conferíveis: caminhos, símbolos, contratos, comandos, commits.
+- Divergência entre página e repositório é **erro de lint**, não questão de opinião.
+- O verificador nunca completa lacuna nem infere estado; ele só aponta.
+
+### 6.3 Modelos e agentes de IA
+
+- Frontmatter YAML com chaves e valores fixos (seção 4); IDs estáveis no nome do arquivo e no título.
+- `ork docs verificar --json` devolve os achados com regra tipada (`docs.paridade.fonte`, `docs.leitura.resumo`...).
+- Um agente pode propor a mudança; a revisão e a decisão ficam com pessoas (seção 2, Responsabilidade).
+
+### 6.4 Fatos de SDLC do método Orkastery
+
+- Entram na documentação **fatos do produto**: a feature está `vigente`, em qual versão, verificada quando, contra quais fontes.
+- O andamento da entrega (thread, fase, CHECK, merge) é registrado no [roadmap](roadmap-de-produto.md), na seção `sdlc` do item.
+- **Micro-decisões de condução não entram**: qual claim foi recadastrada, qual GO-FIX corrigiu um teste, qual sessão caiu. Isso vive no ledger da thread.

package/assets/docs/padroes/roadmap-de-produto.md

@@ -0,0 +1,98 @@
+# Padrão de roadmap de produto de software
+
+> Versão 1.1 · Aplicação: iniciativas, épicos, funcionalidades e mudanças · Documento complementar: [Padrão de documentação de produto](documentacao-de-produto.md)
+>
+> A versão 1.1 mantém a 1.0 e acrescenta a seção 6 (três leitores e fatos de SDLC) e o frontmatter do modelo, que o `ork docs verificar` confere.
+
+## 1. Objetivo e unidade de acompanhamento
+
+Este padrão registra **por que mudar, o que se pretende entregar, como validar e qual o estado real da execução**. Use um item por decisão de investimento/entrega rastreável. Iniciativas podem conter épicos, e épicos podem conter features; cada item tem ID próprio e aponta para o item pai. Uma feature implementada aponta para sua especificação `FEAT-ID`. Não replique campos técnicos extensos do produto no roadmap: mantenha links para a documentação canônica.
+
+O roadmap é uma visão de planejamento sujeita a revisão. Datas, prioridades e escopo são compromissos somente quando explicitamente aprovados e identificados como tal. Marque estimativas e hipóteses como tais.
+
+## 2. Regras comuns
+
+| Regra | Aplicação |
+| --- | --- |
+| ID e vínculo | Use `RM-001` estável; indique pai, features afetadas e links para especificações, ADRs, issue, PR, testes e release. |
+| Resultado | Explicite problema, público, objetivo, hipótese mensurável, linha de base, meta, janela e fonte da métrica. |
+| Priorização | Registre método, critérios, pontuação e data; prioridade é distinta de urgência e não substitui justificativa. |
+| Escopo | Separe incluído, excluído, dependências e premissas. Mudanças de escopo pedem registro de decisão. |
+| Datas | Distinga alvo, previsão e data efetiva; use ISO 8601, fuso e nível de confiança. Nunca infira progresso pela data. |
+| Evidência | Informe fonte e data de cada status. PR mesclado, deploy e disponibilidade para usuários são fatos distintos. |
+| Responsabilidade | Nomeie owner humano por decisão, execução e validação. Agentes de IA podem elaborar, verificar ou executar dentro de autonomia registrada; atribua revisão e decisão final a pessoas. |
+| Lacunas | Use `A definir` com responsável e prazo; para seção irrelevante, `Não aplicável — motivo`. Não invente status ou métricas. |
+
+## 3. Categorias do item de roadmap
+
+### 3.1 Identificação e posicionamento
+
+Registre `ID`, `título orientado ao resultado`, `tipo` (iniciativa/épico/feature/melhoria), `item pai`, `plataforma`, `sistema`, `módulo`, `features afetadas`, `público`, `área solicitante`, `links canônicos` e `versão da página`. Hierarquia arquitetural descreve onde a mudança ocorre; hierarquia de roadmap descreve como ela é planejada.
+
+### 3.2 Problema, objetivo e hipótese
+
+Registre `problema/oportunidade`, `evidências`, `objetivo/OKR`, `hipótese no formato Se... então... porque...`, `métrica principal`, `métricas de proteção`, `linha de base`, `meta`, `janela de observação`, `segmento de análise` e `fonte dos dados`. Sem linha de base conhecida, defina como será medida antes de declarar sucesso.
+
+### 3.3 Escopo, entregáveis e validação
+
+Registre `escopo incluído`, `fora de escopo`, `entregáveis`, `casos de uso afetados`, `critérios de aceite`, `experimento/piloto`, `plano de medição`, `critérios para expandir/interromper`, `habilitação operacional` e `documentação necessária`. Aponte para IDs de regras, contratos e testes na documentação de produto.
+
+### 3.4 Priorização e planejamento
+
+Registre `prioridade`, `método/pontuação` (por exemplo RICE, com fatores explícitos), `justificativa`, `urgência`, `horizonte` (Agora/Próximo/Depois ou trimestre), `alvo`, `previsão`, `confiança`, `marcos`, `capacidade/custo estimado` e `trade-offs`. Uma pontuação sem critérios e data não é reproduzível.
+
+### 3.5 Dependências, riscos e decisões
+
+Registre `dependências com IDs e owners`, `bloqueios`, `premissas ainda não validadas`, `riscos com probabilidade/impacto`, `mitigação/contingência`, `decisões de produto`, `ADR técnico`, `alternativas descartadas`, `data/decisor` e `gatilho para revisão`. ADR é um registro de decisão que pode ser substituído por outro; preserve o histórico, sem apagar decisões anteriores.
+
+### 3.6 Ciclo de vida e estados independentes
+
+Não use um único campo para ocultar diferenças entre plano, código e entrega. Atualize cada dimensão separadamente:
+
+| Dimensão | Valores recomendados | Evidência mínima |
+| --- | --- | --- |
+| Ciclo do item | `Discovery` → `Backlog` → `Refinamento` → `Pronto para desenvolvimento` → `Em desenvolvimento` → `Em validação` → `Piloto` → `Disponível` → `Concluído`; estados laterais: `Bloqueado`, `Cancelado`, `Descontinuado` | Decisão, marco ou entrega com data e owner. |
+| Documentação | `Rascunho`, `Em revisão`, `Aprovada`, `Desatualizada` | Link, versão e revisor. |
+| Código | `Não iniciado`, `Branch criada`, `PR aberto`, `Mesclado` | Repositório, branch/PR e commit. |
+| Testes | `Não iniciados`, `Em execução`, `Aprovados`, `Falhando` | Execução e data; cobertura, se relevante. |
+| Deploy | `Não implantado`, `Dev`, `Staging`, `Produção` | Pipeline, release e data efetiva. |
+| Exposição | `Flag desligada`, `Piloto/Canary`, `Parcial`, `Geral` | Configuração por ambiente/coorte e verificação. |
+| Habilitação | `Pendente`, `Em andamento`, `Concluída` | Comunicação, treinamento ou material publicado. |
+
+`Bloqueado` exige motivo, dependência, responsável e próxima revisão. `Concluído` exige critérios de aceite cumpridos, evidência de disponibilidade e registro de medição inicial ou plano de avaliação pós-lançamento. O status não deve ser atualizado por mera passagem do tempo.
+
+### 3.7 Owners e colaboração entre pessoas e agentes
+
+Registre `PM/PO accountable`, `responsável técnico`, `engenheiro executor`, `QA/validador`, `sponsor`, `consultados`, `informados`, `canal`, `agente de planejamento`, `agente de execução`, `agente de validação`, `autonomia permitida`, `revisor humano` e `RACI`. Separe contribuição de agente da pessoa que aprova; documente ações realizadas e evidências, sem atribuir decisões a um agente por omissão.
+
+## 4. Modelo de item de roadmap
+
+Copie [o modelo](../roadmap/_modelo-item.md) para cada item. O frontmatter guarda as sete dimensões da seção 3.6 com os valores exatos do padrão, e o verificador cobra coerência entre elas:
+
+| Regra de coerência | Por quê |
+| --- | --- |
+| `ciclo: Concluído` exige `codigo: Mesclado` e `testes: Aprovados` | concluído sem código na base é promessa |
+| `deploy: Produção` exige `codigo: Mesclado` | não se implanta o que não foi mesclado |
+| `codigo: Mesclado` exige `evidencias.codigo.commit` **na branch base** | merge se prova pelo git, não por declaração |
+| `ciclo: Bloqueado` exige o mapa `bloqueio` (motivo, dependência, responsável, próxima revisão) | bloqueio sem dono não destrava |
+
+## 5. Cadência e consistência
+
+Revisite itens ativos na cadência do time e sempre após decisão, PR relevante, teste, deploy, alteração de flag ou medição de resultado. A cada revisão, compare roadmap, documentação da feature, código, contratos e evidências de produção; anote divergências com owner e prazo. Agentes podem sugerir atualização de status a partir de eventos do repositório, mas um PR mesclado atualiza somente a dimensão **código** até que deploy e exposição sejam comprovados. Registre a data de atualização e mantenha histórico das decisões e mudanças de escopo.
+
+No Orkastery, `ork docs sincronizar` é esse agente: ele atualiza `estado.codigo` e `evidencias.codigo.commit` a partir do ledger (`ship_done`) e do git, e a seção `sdlc` a partir da thread. **Ele nunca mexe em ciclo, documentação, deploy, exposição ou habilitação** — essas dimensões são decisão de pessoa, e o verificador só cobra que estejam coerentes com o código.
+
+## 6. Três leitores e fatos de SDLC (adaptação Orkastery)
+
+As regras de leitura do [padrão de documentação](documentacao-de-produto.md#6-três-leitores-e-fatos-de-sdlc-adaptação-orkastery) valem aqui: resposta primeiro, estado de relance, uma ideia por linha, seções com nome fixo, frontmatter para agentes.
+
+O que muda no roadmap é o bloco `sdlc`, que liga o item ao método Orkastery **só com fatos do produto**:
+
+| Chave | Conteúdo | Quem preenche |
+| --- | --- | --- |
+| `sdlc.thread` | ID da thread que entrega o item | pessoa, ao abrir a thread |
+| `sdlc.modo` | `#Classic`, `#Maestro` ou `#Auto` | pessoa |
+| `sdlc.fase`, `sdlc.status` | fase atual e status da thread | `ork docs sincronizar` |
+| `sdlc.check` | último veredito do CHECK independente | pessoa, a partir do parecer |
+
+Micro-decisões de condução (claims recadastradas, GO-FIX de teste, sessão que caiu) **não entram no item**: vivem no ledger da thread, que é o registro de auditoria do método.

package/assets/docs/produto/README.md

@@ -0,0 +1,14 @@
+# Documentação de produto
+
+> **Em uma frase:** o que o produto é e faz hoje, uma página por entidade, conferida contra o código a cada PR.
+
+- **Padrão:** [documentação de produto](../padroes/documentacao-de-produto.md) · **Complemento:** [roadmap](../roadmap/README.md)
+- **Hierarquia:** plataforma (`PLAT`) → sistema (`SYS`) → módulo (`MOD`) → feature (`FEAT`)
+- **Nova página:** copie [o modelo](_modelo-feature.md) e rode `ork docs verificar`
+
+## Índice
+
+Gerado por `ork docs sincronizar` a partir do frontmatter de cada página.
+
+<!-- ork-docs:indice:inicio -->
+<!-- ork-docs:indice:fim -->

package/assets/docs/produto/_modelo-feature.md

@@ -0,0 +1,59 @@
+---
+id: FEAT-000
+tipo: feature
+titulo: <Nome da feature>
+estado: proposto
+pai: MOD-00
+roadmap: [RM-000]
+owner: <nome>
+aprovador: <nome>
+verificado_em: 2026-01-01T00:00:00-03:00
+versao: main@0000000
+fontes:
+  codigo: []
+  testes: []
+  simbolos: []
+  contratos: []
+  comandos: []
+---
+
+# FEAT-000 — Nome da feature
+
+> **Em uma frase:** [o que esta feature faz, para quem, em até 240 caracteres]
+
+- **Estado:** proposto · **Verificado em:** [AAAA-MM-DD] · **Versão:** [branch@commit]
+- **Onde fica:** [PLAT-00 > SYS-00 > MOD-00, com links]
+- **Roadmap:** [RM-000, com link]
+- **Dono da página / aprovador:** [nomes]
+
+## Comportamento
+
+- **Casos de uso e operações:** [UC-ID, ação, ator]
+- **Pré-condições e gatilho:** [o que precisa existir e o que dispara]
+- **Fluxo principal:**
+  1. [passo observável]
+- **Alternativas, erros e recuperação:** [erro, cancelamento, timeout, retomada]
+- **Pós-condições:** [o que fica gravado, emitido ou mudado fora]
+- **Regras de negócio:** [BR-ID: condição → resultado; exceção]
+- **Critérios de aceite e testes:** [Dado/Quando/Então, com o teste que prova]
+- **Interface e acessibilidade:** [telas, estados, protótipo — ou Não aplicável — motivo]
+
+## Dados e contratos
+
+- **Entidades e campos:** [links, tipos, validações, sensibilidade]
+- **APIs e endpoints:** [IDs, métodos, contratos, erros, versionamento]
+- **Eventos e jobs:** [IDs, schemas, gatilhos, retries, fuso]
+
+## Operação e controle
+
+- **Configuração e ambientes:** [parâmetros, sem segredos]
+- **Observabilidade:** [métricas, SLO, logs, alertas, runbook]
+- **Acesso, privacidade e conformidade:** [controles aplicáveis]
+- **Dependências e rollback:** [o que ela usa e como voltar atrás]
+- **Código, PR, testes e release:** [links identificáveis]
+
+## Histórico
+
+| Data | Mudança | Autor/revisor | Evidência ou decisão |
+| --- | --- | --- | --- |
+| [AAAA-MM-DD] | [descrição] | [nomes] | [link] |

package/assets/docs/roadmap/README.md

@@ -0,0 +1,14 @@
+# Roadmap
+
+> **Em uma frase:** por que mudar, o que entregar e em que pé está cada item — com o estado provado pelo git, não declarado.
+
+- **Padrão:** [roadmap de produto](../padroes/roadmap-de-produto.md) · **Complemento:** [documentação de produto](../produto/README.md)
+- **Um arquivo por item:** `RM-000-assunto.md`, com o estado no frontmatter
+- **Novo item:** copie [o modelo](_modelo-item.md) e rode `ork docs verificar`
+
+## Itens
+
+Gerado por `ork docs sincronizar` a partir do frontmatter de cada item.
+
+<!-- ork-docs:indice:inicio -->
+<!-- ork-docs:indice:fim -->

package/assets/docs/roadmap/_modelo-item.md

@@ -0,0 +1,73 @@
+---
+id: RM-000
+tipo: roadmap
+titulo: <Resultado pretendido>
+categoria: iniciativa
+pai: null
+features: []
+owner: <nome>
+atualizado_em: 2026-01-01T00:00:00-03:00
+estado:
+  ciclo: Discovery
+  documentacao: Rascunho
+  codigo: Não iniciado
+  testes: Não iniciados
+  deploy: Não implantado
+  exposicao: Flag desligada
+  habilitacao: Pendente
+evidencias:
+  codigo:
+    commit: null
+    pr: null
+sdlc:
+  thread: null
+  modo: null
+---
+
+# RM-000 — Resultado pretendido
+
+> **Em uma frase:** [o resultado que este item entrega, para quem, em até 240 caracteres]
+
+<!-- ork-docs:relance:inicio -->
+<!-- ork-docs:relance:fim -->
+
+## Problema e resultado
+
+- **Público e problema/oportunidade:** [quem sofre o quê]
+- **Evidências e fonte:** [dado, conversa, incidente — com link]
+- **Objetivo/OKR:** [o que muda para quem]
+- **Hipótese:** Se [mudança], então [efeito mensurável], porque [mecanismo].
+- **Métrica principal / linha de base / meta / janela / fonte:** [valores e origem]
+- **Métricas de proteção:** [o que não pode piorar]
+
+## Escopo e validação
+
+- **Incluído:** [o que entra]
+- **Fora de escopo:** [o que não entra]
+- **Entregáveis e critérios de aceite:** [entregável → como se prova]
+- **Piloto, medição e critérios de expansão/interrupção:** [como e quando decidir]
+
+## Plano e decisões
+
+- **Prioridade / método / pontuação / justificativa / data:** [valores]
+- **Horizonte / alvo / previsão / confiança / marcos:** [valores]
+- **Dependências e bloqueios (ID, owner, próxima revisão):** [lista]
+- **Premissas / riscos / mitigação:** [lista]
+- **Decisões, alternativas e ADRs (ID, decisor, data, link):** [lista]
+
+## Estado com evidências
+
+O estado se edita no frontmatter; esta tabela é gerada por `ork docs sincronizar`.
+
+<!-- ork-docs:estado:inicio -->
+<!-- ork-docs:estado:fim -->
+
+## Responsabilidades e histórico
+
+- **RACI (R / A / C / I):** [nomes]
+- **Agentes envolvidos, atuação, autonomia e revisor humano:** [quem fez o quê, e quem aprovou]
+- **Próxima ação, responsável e prazo:** [uma linha]
+
+| Data | Mudança de plano, escopo ou status | Motivo e evidência | Decisor |
+| --- | --- | --- | --- |
+| [AAAA-MM-DD] | [descrição] | [link] | [nome] |

package/assets/orkmind-native-schema.json

@@ -0,0 +1,32 @@
+{
+  "schema": "ork.native-entry-fields/v1",
+  "fields": [
+    "author_id",
+    "collection",
+    "conflict",
+    "content",
+    "content_hash",
+    "created_at",
+    "embedding",
+    "encrypted",
+    "encryption_meta",
+    "essence",
+    "expires_at",
+    "id",
+    "injection_risk",
+    "layer_generated_at",
+    "mandatory",
+    "metadata",
+    "parent_id",
+    "priority",
+    "protected",
+    "scope",
+    "source",
+    "structure",
+    "tags",
+    "updated_at",
+    "url",
+    "version",
+    "visibility"
+  ]
+}