Feedback direto no terminal
Um binário Go, sem fallback Bash/Python, para scaffold, assessment, validação, release e manutenção.
pose validate --strict --report
OPEN SOURCE · APACHE-2.0 · LOCAL-FIRST
SDD que vai da intenção à evidência.
POSE é um framework open source de Spec-Driven Development para engenharia agêntica governada. Specs, políticas, execução, evidências, follow-ups e conhecimento permanecem versionados e verificáveis junto do código.
Governança que agentes conseguem executar.
Linux · macOS
curl -fsSL https://github.com/oseiaspereira88/pose/releases/latest/download/install.sh | bash
binário Go nativo
offline por design
CLI + MCP + CI
Sigstore · SBOM · SLSA
delivery.contract
EXEMPLO
-
01
Intentversioned
.pose/specs/AAAA-MM-DD-feature.md -
02
Policyresolved
pose suggest feature -
03
Executionbounded
module-aware checks -
04
Evidencepassed
pose validate --strict
loop fechado
pose usage --since-days 30
58ferramentas POSE no catálogo MCP congelado por fixture
3reporters opcionais para runs externos no Conductor
5métricas DORA atuais, com ambiente de produção explícito
0contadores manuais exigidos dos agentes para usage analytics
Por que POSE
Seu processo de engenharia não deveria depender da memória do agente
Agentes escrevem, alteram e revisam cada vez mais código. Mas requisitos, regras, decisões, critérios de pronto e trabalho residual ainda costumam viver em prompts, conversas e context windows.
Quando a sessão termina — ou o modelo muda, ou a IDE muda — parte do contrato desaparece. Sem erro, sem aviso, sem nada quebrar visivelmente. O agente continua produzindo código; o que se perdeu foi a capacidade de dizer se aquele código estava pronto para começar e se está pronto para fechar.
Quanto do seu processo de engenharia depende de o agente lembrar do que estava no prompt?
POSE move a autoridade para o repositório. Modelos mudam. Agentes mudam. O contrato de engenharia continua com o código.
# onde o contrato vive hoje prompt · sessão · context window └─ temporário, some com a sessão # onde POSE coloca o contrato .pose/ ├── specs/ requisitos com ID estável ├── rules/ o que se aplica a este módulo ├── workflows/ a trilha do tipo de trabalho ├── reports/ evidência versionada └── knowledge/ o que precisa sobreviver └─ versionado, revisável, com o código
A categoria
A spec é o começo, não o fim
Spec-Driven Development criou uma base melhor para agentes: intenção e requisitos deixaram de depender só do prompt. POSE leva essa ideia até o resto da entrega.
O mesmo contrato que define o trabalho também determina quando ele está pronto para começar, quais regras se aplicam, quais checks precisam passar, qual evidência comprova a entrega, como o trabalho residual é tratado e qual conhecimento deve sobreviver para o próximo ciclo.
Uma spec não teve sucesso só porque código foi gerado. POSE aplica gate de readiness antes da execução e de closeout depois dela, com checks nativos do repositório e evidência versionada.
SDD como lifecycle de entrega, não apenas como etapa de planejamento.
SDD tradicional intent → spec → plan → tasks → implementação → ? POSE discover → specify → route → execute → prove → close → learn └──────► próximo ciclo
Como funciona
Um loop que deixa rastros úteis
O agente não precisa lembrar o processo inteiro no prompt. O repositório declara a trilha, o engine aplica os gates e cada passagem produz contexto para a próxima.
-
01
Descobrir
pose state --attentione assessments mostram arquitetura, dívida, prontidão por fase e evidência antes da mudança. -
02
Especificar
Specs dão IDs estáveis a requisitos, premissas e decisões (R/A/D), dependências, riscos e definição de pronto.
-
03
Roteirizar
pose suggestresolve workflow, skill, regras cumulativas e checks pelo tipo e pelo módulo. -
04
Executar
pose startverifica a prontidão e registra a base aprovada antes de o agente implementar dentro dos limites do repositório. -
05
Provar
Test, lint, typecheck, build e segurança viram resultado estruturado em texto, JSON, JUnit ou SARIF — cada check declara a classe de evidência que produz.
-
06
Fechar e aprender
pose closeexecuta o plano de closeout estruturado e recuperável; trace, follow-ups e knowledge preservam o que foi aceito.
Mesmo engine, três interfaces
O contrato acompanha humanos, agentes e CI
Não há uma versão “para o agente” e outra para o pipeline. Todos leem o mesmo estado local e os mesmos gates determinísticos.
Contexto tipado para agentes
58 ferramentas POSE project-scoped (61 com reporters), catálogo congelado, resolução cross-project e obrigações tipadas.
pose_project_state → pose_check
O mesmo gate na entrega
GitHub Action, pre-commit e matrix por módulo transformam política local em condição de promoção reproduzível.
pose check --strict
O diferencial
POSE não é outro coding agent
Agentes escrevem código. Ferramentas de planning ajudam a escrever planos. POSE governa o sistema inteiro em que ambos trabalham.
coding agent
propõe e executa mudanças
execução
SDD / planning
estrutura intenção e requisitos
planejamento
POSE
liga intenção, regras, execução, prova, fechamento e aprendizado
governançaentrada + saída
Lifecycle governado
Definition of Ready, início com base aprovada, amendments imutáveis e closeout recuperável com todo follow-up disposto.
prova composta
Delivery integrity
artifact-check, surface-check, causalidade estrutural com requisitos, premissas e decisões (R/A/D), e gates de roadmap federados. Contratos opcionais dependem da adoção da instância.
humano auditável
Ações assinadas
Respostas a action requests podem ser assinadas por uma chave registrada ou provadas por um emissor confiável, vinculadas à decisão; onde a garantia verified é exigida, só essas valem. No modo declared, a resposta é registrada e rotulada como declarada, sem prova criptográfica. A garantia depende da proteção das chaves e da configuração de confiança.
revisão convergente
Review & auto-attest
Bundles imutáveis separam evidência de julgamento. brief e dispatch levam o contexto selado a um segundo agente; executar a revisão não registra aprovação. Entenda o fluxo de review ↗.
supply chain
Release verificável
Checksums, assinatura keyless Sigstore, SBOM CycloneDX, provenance SLSA e rebuild independente por artefato.
adoção incremental
Entra sem apagar o passado
pose setup, catálogo de capabilities (pose adopt), onboarding automático, importadores para Spec Kit e OpenSpec.
Operação diária
Saiba o que está valendo. E o que precisa de você.
A política que o engine suporta, a que o projeto adotou e a que se aplica à tarefa são informações diferentes. O POSE torna cada uma consultável.
configurar
Adoção com decisão explícita
pose setup orienta identidade, chaves, hook e capacidades. pose adopt --list mostra o que está ativo, recusado, adiado ou precisa de configuração. Atualizar o binário não ativa todas as políticas opcionais.
priorizar
Pendências por ator e fase
pose state --attention mostra quem deve agir e o que restringe início, execução, review, fechamento ou release. Cobertura incompleta aparece no resultado. Uma pergunta só de release pode aguardar sem interromper a implementação.
coordenar
Autoridade entre projetos
Referências qualificadas resolvem a spec canônica. Roadmaps podem consumir entregas revisadas de outro projeto mantendo seus próprios gates. Transferências exigem preview, contexto atual e autorização dos projetos afetados.
Entender múltiplos projetos ↗Evolução do POSE · revisão em 20/10/2026
O que você instala hoje. O que vem depois.
Base publicada: release publicada em 10/10/2026. O changelog pendente e os planos têm espaço próprio, sem antecipar disponibilidade.
publicado
Decisões e reviews com prova
A linha 7.x reúne configuração guiada, atenção por fase e respostas assinadas. Emissores locais e o ledger de legado permitem adotar assinatura preservando o histórico. A revisão delegada parte do bundle selado e mantém execução separada de aprovação.
Usar as capacidades publicadas ↗changelog pendente · sem release
Mais integridade e recuperação
O branch de desenvolvimento registra melhorias de verificação de provas, cobertura de fontes, publicação concorrente, gerações coerentes de índices e recuperação de journals e checkpoints. O reforço de snapshots Git e dispatch segue em andamento. Essas mudanças aguardam publicação em uma próxima release.
Ver o que está pendente ↗planejamento
Consolidação com limites claros
Novas specs e roadmaps organizam consistência, experiência, eficiência e um possível runtime compartilhado. Fragmentos que formalizam planos documentam intenção; não comprovam entrega de runtime, IPC, caches ou pilotos.
Consultar os roadmaps ↗Confira a evolução por versão e os critérios de disponibilidade ↗. A instalação via latest acompanha a release publicada, sem incluir automaticamente o conteúdo de unreleased.
Migração
Já começou com outro SDD? Traga o trabalho com você
POSE é um framework SDD completo. Quando adotado, ele passa a ser a autoridade do lifecycle de specs e entrega naquele repositório.
Em vez de manter dois frameworks disputando quem é dono de IDs de requisito, status, dependências e definição de pronto, POSE oferece importação para trazer o trabalho existente e continuar sob um único lifecycle.
Interoperabilidade na migração. Uma autoridade durante a execução.
Os guias documentam o que transfere e — igualmente importante — o que não transfere: IDs de requisito são renumerados, status e dependências não vêm junto, e a validação fica como placeholder porque POSE roda os checks do seu repositório, não os que ele inventou.
# inspecione antes de escrever — nada é gravado $ pose import spec-kit .specify/specs --dry-run import.spec slug=customer-export requirements=2 artifacts=3 action=dry-run import.curation warning="unmapped source section \"Out Of Scope\"" import.summary specs=1 warnings=1 written=0 dry_run=true $ pose import openspec openspec/changes/add-2fa --dry-run
Primeiro valor
Do binário à primeira evidência
Comece em uma linha no Linux ou macOS. Para ambientes controlados, fixe a versão e verifique checksum, assinatura e provenance pelo guia completo.
terminal · POSE
guia completo ↗
# execute na raiz do seu repositório $ curl -fsSL https://github.com/oseiaspereira88/pose/releases/latest/download/install.sh | bash # o instalador valida a estrutura; revise o resultado antes de continuar $ pose setup $ pose new-spec minha-primeira-feature $ pose suggest feature --path meu-modulo $ pose start spec:minha-primeira-feature # após preencher a spec e revisar o preview, use o digest retornado $ pose start spec:minha-primeira-feature --apply --digest <start.digest> # implemente a mudança e execute os checks declarados pelo módulo $ pose validate --strict --report # commit com o trailer da spec; depois fechar pelo plano estruturado $ git commit -m "feat: primeira feature" -m "POSE-Spec: minha-primeira-feature" $ pose close spec:minha-primeira-feature --plan $ pose close spec:minha-primeira-feature --apply --reviewer agent:revisor # atenção e usage observados; nenhum contador manual $ pose state --attention $ pose usage --since-days 30
Este roteiro exige preencher a spec, implementar a mudança e preparar os arquivos para commit. Adote a capability de início atômico quando necessário. O fechamento pode parar para julgamentos do revisor; responda às pendências antes de retomar com pose close spec:minha-primeira-feature --resume --reviewer agent:revisor. O one-liner acompanha a release latest e prioriza adoção rápida. Para pinning e verificação offline, use os checksums e bundles Sigstore publicados em Verified install ↗.
Analytics sem ficção
Uso, adoção e entrega são sinais diferentes
POSE mede cada plano na fonte apropriada e não transforma atividade do agente em causalidade de negócio.
01 · produtoautomático
POSE usage
Quais ferramentas CLI/MCP são usadas, seus outcomes, latência e quantos findings estruturados foram observados, resolvidos ou reabertos.
- zero
count++manual por agente - execução separada de resultado semântico
- filtros por tool, surface e janela
pose usage --since-days 30
02 · adoçãoderivado
Valor no workflow
Ativação, tempo até o primeiro gate, retenção e sucesso de tasks vêm dos artefatos que o POSE já governa.
- mede chegada ao primeiro valor
- não exige instrumentação individual
- não ranqueia pessoas ou agentes
pose adoption-metrics --json
03 · entregaexplícito
DORA, sem adivinhação
Deploy frequency, lead time, change failure, recovery e rework por aplicação e ambiente — a partir de eventos de deploy/incidente.
- produção é o escopo padrão explícito
- recovery só quando causado por deploy
- legado desconhecido aparece indisponível, não zero
pose dora-metrics --environment production
Fronteira honesta
Open source no repositório. Plataforma quando a operação escala.
Apache-2.0
POSE core
CLI, engine, templates, MCP server e gates rodam localmente, sem cadastro, telemetria obrigatória ou dependência da Harne8 Platform.
camada opcional
Harne8 Platform
Orquestração durável multi-time, operação visual e distribuição central de política compõem o POSE sem retirar sua autonomia local. Veja a plataforma.
Telemetria de ativação é uma terceira coisa, separada de usage local e DORA: opt-in, inspecionável com pose telemetry status e sem conteúdo do repositório.
O contrato mora com o código