> Tradução do núcleo do Manifesto de Software Humano v2.1. O original em espanhol mantém a autoridade doutrinária; havendo divergência entre os dois, prevalece o texto em espanhol.
**NÚCLEO DA ESTRUTURA DE PRODUTO E DESENVOLVIMENTO**
# Núcleo do manifesto para o desenvolvimento de software humano com inteligência artificial
Princípios, fundamento de produto, Job Stories e testes de decisão para construir produtos centrados no progresso situado das pessoas
Construímos ferramentas para ampliar a capacidade das pessoas, não para exibir a capacidade do software.
**Versão 2.1**
Setembro de 2026
## ÍNDICE OPERACIONAL PARA AGENTES · `SH-INDEX`
Esta camada de navegação permite que pessoas, agentes e adaptadores citem obrigações do núcleo de maneira estável. Os identificadores não acrescentam doutrina, prioridade, etapas, artefatos nem critérios: apenas apontam para conteúdo já aprovado. Uma referência por identificador nunca substitui a leitura do trecho citado nem modifica a autoridade do texto.
| **Família** | **Identificadores** | **Conteúdo** |
|---|---|---|
| Navegação | `SH-INDEX` | Índice operacional e regra de uso dos identificadores |
| Princípios | `P01`–`P10` | Dez compromissos que governam as decisões |
| Fundamento | `SH-FUND` | Definição de produto, autoridade, escopo e Job Stories de referência |
| Diretrizes para IA | `D01`–`D06` | Doutrina para times e agentes |
| Fluxo | `F01`–`F08` | Oito passos do fundamento até a verificação |
| Artefatos | `A01`–`A08` | Oito respostas documentais ajustadas ao contexto |
| Parada | `SH-STOP`, `STOP01`–`STOP07` | Condições que impedem avançar ou aceitar |
| Contrato do agente | `CR01`–`CR08` | Instruções reutilizáveis para desenvolver |
| Entrega do agente | `O01`–`O09` | Conteúdo esperado dos resultados em linguagem natural |
| Verificação | `V01`–`V12` | Dimensões de evidência para aceitar uma solução |
| Controles transversais | `SH-SCORE`, `SH-AP`, `SH-GOV`, `SH-DONE`, `SH-POCKET` | Decisão, antipadrões, governança, conclusão e guia breve |
Os adaptadores podem indicar quais identificadores exigem atenção em uma operação específica. Essa seleção orienta a carga e não autoriza ignorar qualquer outra disposição do núcleo que seja aplicável pelo contexto, pelo risco ou por uma contradição.
## PROPÓSITO DESTE DOCUMENTO
### O problema que este manifesto busca resolver
Como construímos software que amplifique a capacidade das pessoas de alcançar o que buscam, sem transferir a elas a complexidade da tecnologia?
O software ganha capacidade rapidamente. A inteligência artificial acelera ainda mais esse processo: hoje é barato gerar telas, opções, automações e camadas de abstração. Essa abundância não garante um produto melhor. Ela também permite transformar uma decisão fraca em muito código correto, e uma ideia desnecessária em uma funcionalidade pronta.
Este manifesto estabelece uma doutrina para decidir o que merece ser construído, como deve ser a experiência de usá-lo e que evidência deve existir antes de aceitar uma implementação. Sua unidade de medida não é a quantidade de funcionalidades entregues. É o progresso que uma pessoa consegue alcançar com clareza, confiança e controle.
A versão 2.1 preserva a concretude alcançada por meio de Jobs to Be Done e Job Stories, e amplia a capacidade da estrutura de trabalhar com definições de produto de extensão e profundidade distintas. Uma Job Story continua oferecendo uma forma especialmente útil de descrever a circunstância que ativa uma necessidade, a motivação que impulsiona a agir e o resultado buscado. No entanto, o fundamento de um desenvolvimento também pode estar expresso por épicos, capacidades, requisitos, regras, jornadas, critérios ou outras estruturas coerentes. O formato da entrada não deve obrigar a distorcer a intenção do produto.
#### A conclusão central
A função estabelece o que o software permite fazer. A experiência determina quanto dessa capacidade uma pessoa consegue de fato aproveitar.
A experiência não é uma camada estética acrescentada depois de resolver a funcionalidade. Faz parte dela. Se uma solução produz o resultado correto, mas exige que a pessoa decifre a interface, memorize regras desnecessárias ou tema errar, a solução ainda está incompleta.
#### Escopo e leitores
A estrutura se aplica a produtos em que a experiência de uso influencia diretamente o resultado: aplicações web e móveis, ferramentas internas, sistemas de aprendizagem, serviços digitais, produtos com agentes e soluções assistidas por IA. Destina-se a gestores de produto, designers, profissionais de desenvolvimento e agentes de código que participam de decisões de produto.
Não prescreve um estilo visual, uma tecnologia, uma estrutura de PRD, uma estratégia de entrega nem um framework de engenharia. Tampouco elimina a complexidade real do domínio. Define como impedir que a estrutura interna do sistema se transforme, por comodidade do time, em trabalho adicional para quem o utiliza.
Este documento contém o núcleo do manifesto. Sua tradução para métodos de desenvolvimento baseados em especificações e para frameworks específicos deve ser feita por meio de anexos ou adaptadores separados. Nenhuma implementação pode reduzir seus princípios, alterar o escopo definido por produto nem atribuir ao agente uma autoridade que o núcleo reserva às pessoas.
#### Como usar este documento
O documento oferece duas profundidades de leitura. A primeira permite compreender a postura em poucos minutos. A segunda converte essa postura em decisões verificáveis durante o desenvolvimento.
| **Rota** | **Conteúdo** | **Uso recomendado** |
|-------------|----------------------------------------------------------------------------------------|-------------------------------------------------|
| Compreender | Tese e texto canônico do manifesto | Alinhar o time antes de definir uma solução |
| Decidir | Dez princípios, fundamento de produto e Job Stories com regras e perguntas de controle | Resolver alternativas de produto e de UX |
| Construir | Doutrina específica para desenvolvimento com IA | Orientar agentes de código e revisores humanos |
| Verificar | Testes de aceitação, scorecard e antipadrões | Avaliar protótipos, implementações e entregas |
#### A arquitetura da estrutura
Cada princípio se traduz em níveis operacionais. Nenhum nível substitui outro. O fundamento de produto mantém a definição autorizada do que deve ser construído e por quê. Jobs to Be Done pode orientar o progresso geral, e a Job Story oferece a forma de referência deste manifesto para tornar esse progresso concreto, situado e verificável.
| **Nível** | **Pergunta que responde** | **Resultado** |
|--------------------------|-------------------------------------------------------------------|------------------------------------------------------|
| Princípio | O que acreditamos | Um critério estável para orientar decisões |
| Fundamento de produto | O que deve ser construído, por quê e sob que condições | Uma base autorizada, rastreável e verificável |
| Job Story de referência | Quando surge uma necessidade e que progresso a pessoa busca | Uma forma concreta para projetar e verificar |
| Regra | O que exige ao projetar ou implementar | Um comportamento observável do produto e do time |
| Teste | Como sabemos se cumprimos | Evidência que permite aceitar, revisar ou rejeitar |
#### Limite entre núcleo e implementação
O núcleo define princípios, autoridades, condições de rastreabilidade, critérios de aceitação e limites para times e agentes. Um anexo geral pode traduzir essas obrigações para um método de desenvolvimento baseado em especificações. Os adaptadores de frameworks específicos devem resolver comandos, modelos, fluxos, persistência e compatibilidade sem modificar o núcleo. Uma mudança de framework não constitui, por si só, uma nova versão do manifesto.
## TEXTO CANÔNICO
### Manifesto para o desenvolvimento de software humano
O propósito do software é ampliar o que uma pessoa pode fazer.
As pessoas não chegam aos nossos produtos para utilizar funcionalidades. Chegam porque querem compreender, decidir, criar, aprender, comunicar-se, resolver problemas ou avançar. Esse progresso é o nosso verdadeiro produto.
O progresso não acontece em abstrato. Ele é ativado quando uma circunstância cria uma necessidade, uma tensão ou uma decisão. Antes de projetar uma resposta, descrevemos essa circunstância, a motivação que ela produz e o resultado que a pessoa busca. A solução vem depois.
A definição de produto governa o que deve ser construído. Pode ser expressa por uma única história ou por um PRD extenso, composto de histórias, capacidades, regras, estados, jornadas e critérios. O desenvolvimento deve compreender essa estrutura, preservar seu significado e contemplar todo o seu escopo. Decompor, ordenar ou executar o trabalho em paralelo não autoriza omiti-lo nem redefini-lo.
Por isso a experiência faz parte da funcionalidade. Um sistema que permite concluir uma tarefa, mas obriga a interpretar a interface, memorizar convenções, atravessar estruturas desnecessárias ou perguntar-se o que acontecerá em seguida, transfere à pessoa um problema que o produto deveria resolver.
Não rejeitamos a complexidade. Muitos problemas importantes são complexos. Rejeitamos que a complexidade de construí-los tenha de se converter automaticamente em complexidade para quem usa a ferramenta.
Buscamos software simples no começo e profundo quando necessário. Software que revele capacidades em contexto, explique sem interromper, antecipe sem controlar e permita que a pessoa se recupere sem medo.
Cada elemento deve justificar a atenção que consome. Cada interação deve ajudar a compreender onde estamos, o que podemos fazer e o que acontecerá em seguida. Cada detalhe deve contribuir para uma experiência coerente, rápida e confiável.
A inteligência artificial deve absorver complexidade, não multiplicá-la. Pode propor, resumir e automatizar, mas permanece subordinada à intenção da pessoa. As regras críticas, as permissões, os compromissos e os estados que exigem certeza não dependem de uma interpretação probabilística.
Agora que construir ficou mais fácil, nossa responsabilidade aumenta. Antes de acrescentar uma capacidade, perguntamos que progresso ela habilita, que carga introduz, que risco cria e se merece existir.
Nosso objetivo é que a sofisticação permaneça por trás da experiência e que, diante dela, a pessoa conserve seu propósito, sua atenção e seu controle.
O melhor software não faz a pessoa admirar o software. Faz com que ela se surpreenda com o que agora é capaz de fazer.
## PRINCÍPIOS DE DESIGN
### Dez compromissos que governam as decisões
Os princípios não descrevem aspirações decorativas. Cada um deve ser capaz de mudar uma decisão, parar uma implementação ou exigir evidência adicional. Uma frase sem consequências práticas não cumpre função alguma dentro da estrutura.
| **N** | **Princípio** | **Consequência principal** |
|-------|----------------------------------------------------------|------------------------------------------------------------------------------------------------------------------|
| 1 | O progresso da pessoa é a unidade de design | Vincula cada decisão ao seu fundamento de produto e usa Job Stories quando expressam melhor a situação |
| 2 | A experiência também é funcionalidade | Inclui esforço, emoção e atrito na definição de qualidade |
| 3 | A complexidade pertence ao sistema | Evita transferir o modelo interno para a pessoa |
| 4 | Simples no começo e profundo quando necessário | Revela poder em contexto sem limitar a pessoa experiente |
| 5 | A interface não deve se tornar outra tarefa | Reduz aprendizado incidental e convenções próprias |
| 6 | A atenção é um recurso do produto | Justifica cada elemento e cada decisão solicitada |
| 7 | A confiança é projetada | Torna visíveis estado, consequências, controle e recuperação |
| 8 | A qualidade vive no acúmulo de detalhes | Trata microdecisões e estados extremos como parte do produto |
| 9 | O tempo e a continuidade fazem parte da interface | Integra desempenho, disponibilidade e preservação do trabalho |
| 10 | A pessoa conserva controle e propriedade | Subordina assistência e automação à intenção humana |
## PRINCÍPIO 1 · `P01`
### O progresso da pessoa é a unidade de design
Não projete o que a pessoa pode fazer. Projete o progresso que ela precisa alcançar.
#### O que significa
Uma funcionalidade só faz sentido se ajudar alguém a passar de uma situação atual para um resultado desejado. O fundamento de produto estabelece a razão autorizada do desenvolvimento. Jobs to Be Done pode definir o progresso em um nível amplo, e a Job Story o torna operacional ao descrever quando surge a necessidade, o que motiva a pessoa e que resultado ela busca, sem antecipar a solução.
#### Por que importa
Quando o trabalho se organiza em torno de funcionalidades ou perfis genéricos, o time pode entregar muito e resolver pouco. Uma Job Story obriga a explicitar a causalidade: a circunstância que ativa a necessidade, a tensão que impulsiona a agir e a situação mais favorável que permitiria reconhecer o progresso. Quando o produto utiliza outra forma, essa mesma causalidade deve ser preservada na medida em que for aplicável.
#### Regras de design
- Identificar o fundamento de produto e a fonte autorizada que estabelece o escopo antes de projetar uma resposta.
- Quando o fundamento se expressar por Job Stories, situá-las dentro do progresso ou propósito de nível superior correspondente.
- Formular cada Job Story como circunstância, motivação e resultado, sem nomear uma tela, um componente nem uma funcionalidade.
- Sustentar as decisões com comportamento observado, obstáculo ou ansiedade atual e evidência que permita aceitar o resultado.
#### Testes de decisão
- É possível apontar a fonte autorizada que justifica esta decisão e sua relação com o escopo completo?
- Quando existe uma Job Story, a circunstância é específica e observável ou apenas descreve um papel?
- A motivação e o resultado estão sustentados por evidência ou foram supostos pelo time?
- A formulação admite várias soluções possíveis? Se já prescreve uma interface sem que isso seja uma decisão de produto, precisa ser revista.
**Sinal de descumprimento.** “Como estudante, quero receber dicas para resolver derivadas” parece uma história útil, mas começa por um papel e prescreve uma função. Não explica quando surge o bloqueio, o que a pessoa precisa compreender nem como reconhecer que retomou o avanço.
## PRINCÍPIO 2 · `P02`
### A experiência também é funcionalidade
Se funciona, mas desgasta, ainda não funciona bem.
#### O que significa
O produto não se define apenas pela exatidão da sua saída. Também importa quanto esforço, incerteza e atenção ele exige para obtê-la. A sensação de fluidez ou de frustração altera a capacidade real da pessoa de concluir seu trabalho.
#### Por que importa
Dois produtos podem entregar o mesmo resultado e gerar desempenhos distintos. Uma experiência desgastante provoca abandono, erros, dependência de suporte e perda de confiança. Esse custo é funcional, ainda que não apareça na especificação técnica.
#### Regras de design
- Incluir esforço, clareza e confiança nos critérios de aceitação.
- Testar o fluxo completo, e não apenas cada tela ou endpoint de forma isolada.
- Considerar o estado emocional e cognitivo que acompanha a situação definida pelo produto e, quando existir, pela Job Story.
#### Testes de decisão
- A pessoa consegue se concentrar no seu objetivo ou precisa administrar a ferramenta?
- Que momentos provocam dúvida, tensão ou interrupção?
- Uma tarefa correta deixa a pessoa com energia para continuar?
**Sinal de descumprimento.** Um formulário tecnicamente válido que apaga os dados depois de um erro transforma a correção em castigo. A validação funciona; a experiência, não.
## PRINCÍPIO 3 · `P03`
### A complexidade pertence ao sistema
O fato de ser complexo de construir não significa que deva ser complexo de usar.
#### O que significa
O domínio pode exigir regras, integrações e exceções. O time deve absorver essa complexidade e apresentá-la como decisões compreensíveis. As tabelas, os estados e os serviços internos não deveriam ditar a linguagem nem a navegação da pessoa.
#### Por que importa
Quando a interface replica a arquitetura, a pessoa precisa aprender como o produto foi construído antes de obter valor. Essa transferência costuma parecer inevitável apenas porque é conveniente para o time.
#### Regras de design
- Traduzir conceitos internos para a linguagem e o modelo mental da pessoa.
- Resolver dependências, valores padrão e sequências quando houver contexto suficiente.
- Expor uma exceção apenas a quem realmente deve decidi-la.
#### Testes de decisão
- Este passo existe por uma necessidade da pessoa ou pela estrutura do sistema?
- Estamos mostrando uma entidade técnica que poderia ser traduzida ou inferida?
- A pessoa precisa compreender esta regra para tomar uma boa decisão?
**Sinal de descumprimento.** Pedir que a pessoa escolha primeiro um tipo de registro interno, sem que essa distinção tenha significado para ela, expõe o esquema de dados como se fosse uma necessidade humana.
## PRINCÍPIO 4 · `P04`
### Simples no começo e profundo quando necessário
Não elimine o poder. Elimine a obrigação de enfrentá-lo antes de precisar dele.
#### O que significa
A simplicidade não consiste em reduzir a capacidade do produto. Consiste em adequar o que está visível ao momento, ao nível de experiência e à decisão atual. A profundidade aparece de forma progressiva e permanece disponível.
#### Por que importa
Um produto minimalista pode ser fácil no primeiro dia e limitante no décimo. Um produto que mostra toda a sua potência desde o início pode ser inabordável. A revelação progressiva evita os dois extremos.
#### Regras de design
- Mostrar primeiro o caminho principal e revelar opções avançadas quando o contexto as tornar relevantes.
- Preservar atalhos e precisão para pessoas experientes sem impô-los a quem está começando.
- Usar bons valores padrão, sempre editáveis quando a decisão importa.
#### Testes de decisão
- O que a pessoa precisa ver exatamente neste estado?
- A simplificação elimina ruído ou elimina capacidade necessária?
- Uma pessoa experiente consegue avançar rapidamente sem que quem está começando carregue essa profundidade?
**Sinal de descumprimento.** Ocultar todas as opções pode produzir uma primeira impressão limpa e um beco sem saída quando aparece um caso menos comum.
## PRINCÍPIO 5 · `P05`
### A interface não deve se tornar outra tarefa
A pessoa veio fazer seu trabalho, não aprender o nosso.
#### O que significa
Uma interface deve se apoiar em expectativas conhecidas, hierarquia compreensível e feedback imediato. Cada convenção própria que a pessoa precisa memorizar consome capacidade que deveria ser empregada no problema real.
#### Por que importa
A carga de aprendizado se torna especialmente danosa em produtos educacionais, de saúde, financeiros ou de uso pouco frequente. A pessoa já enfrenta complexidade suficiente no conteúdo ou na decisão.
#### Regras de design
- Preferir convenções conhecidas quando resolverem bem o problema.
- Explicar em contexto, sem exigir tutoriais prévios para ações básicas.
- Tornar evidentes a ação principal, o estado atual e o próximo passo possível.
#### Testes de decisão
- A pessoa entende o que os elementos significam sem uma legenda externa?
- Ela precisa se lembrar de algo de uma tela anterior para agir corretamente?
- A interface acrescenta uma camada de aprendizado alheia à situação ou ao resultado que deve resolver?
**Sinal de descumprimento.** Uma sequência numerada sem significado visível obriga a aprender a navegação ao mesmo tempo que o conteúdo. Os números organizam para o time, mas não orientam a pessoa.
## PRINCÍPIO 6 · `P06`
### A atenção é um recurso do produto
Cada coisa que mostramos compete com aquilo que a pessoa veio fazer.
#### O que significa
A atenção é finita. Menus, alertas, animações, escolhas e textos demandam parte dela. O design deve administrar esse orçamento com a mesma disciplina que o desempenho ou o custo.
#### Por que importa
Uma interface pode não ter erros e ainda assim fracassar por saturação. A carga acumulada deteriora a compreensão, aumenta as decisões acidentais e faz tarefas simples parecerem pesadas.
#### Regras de design
- Exigir que cada elemento visível e cada decisão solicitada respondam a uma circunstância, motivação ou resultado verificável.
- Hierarquizar por relevância para o estado atual, não por atribuir o mesmo peso a todas as funcionalidades.
- Reduzir interrupções e reservar sinais intensos para assuntos que realmente exijam atenção.
#### Testes de decisão
- O que compete visual ou mentalmente com a ação principal?
- É possível eliminar um elemento sem perder informação necessária ou controle?
- A interface diferencia o urgente, o importante e o opcional?
**Sinal de descumprimento.** Apresentar cinco ações com o mesmo peso visual obriga a pessoa a estabelecer uma prioridade que o produto já deveria conhecer pelo contexto.
## PRINCÍPIO 7 · `P07`
### A confiança é projetada
Uma boa ferramenta explica o suficiente para a pessoa agir sem medo.
#### O que significa
A confiança surge quando o produto mostra seu estado, antecipa consequências, confirma resultados e oferece recuperação. Não depende de promessas gerais, e sim de um comportamento previsível.
#### Por que importa
A incerteza freia a ação. Com IA, a confiança exige ainda distinguir fatos, inferências, propostas e ações executadas. Uma resposta fluente não pode ocultar seus limites.
#### Regras de design
- Mostrar o que está acontecendo, o que vai mudar e quando uma ação será irreversível.
- Permitir que a pessoa desfaça, corrija ou volte a um estado seguro quando for razoável.
- Diferenciar com clareza recomendações, decisões automáticas e resultados confirmados.
#### Testes de decisão
- A pessoa sabe o que vai acontecer antes de confirmar?
- Ela consegue verificar o que o sistema fez e por quê?
- Existe uma rota de recuperação proporcional ao risco?
**Sinal de descumprimento.** Um agente que informa "pronto" sem mostrar o que mudou obriga a confiar no seu tom, e não na evidência.
## PRINCÍPIO 8 · `P08`
### A qualidade vive no acúmulo de detalhes
A qualidade raramente depende de uma grande decisão. Ela se reconhece em muitas decisões pequenas e coerentes entre si.
#### O que significa
Tipografia, espaçamento, textos, foco, estados vazios, erros, transições e microinterações formam uma única experiência. Nenhum detalhe compensa sozinho uma solução ruim, mas o acúmulo deles pode reforçar ou corroer a confiança.
#### Por que importa
As pessoas não separam interface, engenharia e conteúdo. Elas experimentam um produto completo. Uma inconsistência pequena pode ser tolerável; cem inconsistências transformam o uso em atrito constante.
#### Regras de design
- Projetar e verificar estados normais, vazios, de carregamento, erro, sucesso e recuperação.
- Manter linguagem, hierarquia e comportamento consistentes em todo o fluxo.
- Revisar o produto em escala real e com conteúdo realista antes de aprová-lo.
#### Testes de decisão
- Os detalhes reforçam a mesma lógica ou contradizem expectativas?
- O que acontece nos estados menos frequentes?
- O produto parece deliberadamente construído ou montado por partes?
**Sinal de descumprimento.** Um botão muda de nome entre etapas, um erro aparece longe do campo e o foco se perde depois de salvar. Cada defeito é menor; juntos, quebram a continuidade.
## PRINCÍPIO 9 · `P09`
### O tempo e a continuidade fazem parte da interface
A pessoa experimenta a espera antes de conhecer a nossa arquitetura.
#### O que significa
Latência, disponibilidade, sincronização e preservação do trabalho são propriedades da experiência. A pessoa não distingue infraestrutura de interface quando uma resposta demora, uma ação se duplica ou um avanço se perde.
#### Por que importa
A lentidão modifica comportamentos: gera cliques repetidos, dúvidas, abandono e erros. A perda de continuidade obriga a reconstruir contexto e destrói a confiança rapidamente.
#### Regras de design
- Definir orçamentos de tempo de resposta para as interações críticas.
- Mostrar progresso honesto e permitir continuar quando uma operação puder demorar.
- Salvar o trabalho, o contexto e o estado com uma frequência proporcional ao custo de perdê-los.
#### Testes de decisão
- A interface responde de imediato ainda que o processo final continue?
- O que a pessoa perde se a conexão falhar agora?
- O produto evita ações duplicadas e estados ambíguos?
**Sinal de descumprimento.** Um botão sem feedback durante três segundos convida a apertá-lo de novo. A duplicação resultante parece erro da pessoa, mas nasce do sistema.
## PRINCÍPIO 10 · `P10`
### A pessoa conserva controle e propriedade
Ajudar não significa decidir pela pessoa nem se apropriar do trabalho dela.
#### O que significa
O software pode antecipar, recomendar e automatizar. Deve fazê-lo sem ocultar decisões, sem restringir o acesso à informação e sem impedir alternativas. Em sistemas com IA, o controle inclui compreender que informação foi usada e que ação foi executada.
#### Por que importa
A automação sem agência humana pode acelerar o caminho errado. A propriedade e a portabilidade reduzem dependência, fortalecem a confiança e permitem que a pessoa combine ferramentas conforme suas necessidades.
#### Regras de design
- Pedir confirmação proporcional ao impacto, não a cada gesto nem depois de uma ação irreversível.
- Permitir revisar, editar, exportar e reverter quando o domínio permitir.
- Explicar o uso de dados e separar autorização, recomendação e execução.
#### Testes de decisão
- A pessoa pode recusar a proposta sem perder seu avanço?
- Ela entende quais dados foram utilizados e com que finalidade?
- Consegue recuperar ou levar seu conteúdo em um formato útil?
**Sinal de descumprimento.** Uma IA que reescreve e publica sem visualização prévia transforma assistência em apropriação do processo.
## FUNDAMENTO DE PRODUTO E FORMA DE REFERÊNCIA · `SH-FUND`
### Do fundamento de produto a uma solução verificável
O fundamento de produto é o conteúdo autorizado que estabelece o que deve ser construído, por que deve existir, que resultados deve produzir, que condições deve respeitar e como seu cumprimento poderá ser determinado. Não é um novo tipo de documento nem um modelo obrigatório. Pode estar em uma Job Story, em uma formulação de Jobs to Be Done, em um épico, em uma capacidade, em um requisito, em uma regra de negócio, em uma jornada, em um critério de aceitação ou em uma combinação coerente desses elementos.
#### Quando o fundamento é identificável
Um fundamento de produto é identificável quando o desenvolvimento consegue estabelecer, sem inventar decisões de produto, os elementos a seguir. Eles podem estar distribuídos em uma ou várias partes da definição recebida e não precisam usar estes nomes nem esta ordem.
| **Elemento** | **Pergunta de controle** | **Condição mínima** |
|-------------------------|----------------------------------------------------------------|----------------------------------------------------------------|
| Fonte e autoridade | De onde vem e quem pode modificá-lo? | Origem rastreável e autoridade reconhecida |
| Razão | Que situação, necessidade, problema ou oportunidade aborda? | Justificativa compreensível sem depender da solução |
| Resultado | Que mudança ou progresso deve produzir? | Resultado reconhecível para as pessoas ou para o produto |
| Condições e limites | Que regras, restrições e exclusões devem ser respeitadas? | Limites suficientes para evitar decisões silenciosas |
| Evidência | Como saberemos que foi cumprido? | Critérios, observações ou testes proporcionais ao risco |
A ausência de uma seção ou campo específico no PRD não constitui, por si só, um defeito. O método deve compreender a estrutura que o produto utiliza. Se faltar uma definição capaz de mudar materialmente a solução, o agente deve expor a lacuna e recorrer à autoridade correspondente; não deve preenchê-la por meio de uma inferência silenciosa.
#### Escopo completo e autoridade de produto
Quando uma definição de produto aprovada contém múltiplas histórias, capacidades, regras ou especificações, todas fazem parte do escopo, salvo se a própria definição ou uma decisão autorizada estabelecer o contrário. O plano de desenvolvimento deve compreender o conjunto, resolver suas relações e dependências e assegurar sua cobertura. Pode decompor, ordenar, agrupar ou executar o trabalho em paralelo; essa decomposição não modifica o escopo.
O plano organiza como o escopo é implementado. Não decide silenciosamente que parte do escopo merece existir.
- Toda omissão, modificação ou adiamento deve ser explícito, rastreável e aprovado pela autoridade de produto.
- Se as restrições de tempo, recursos ou tecnologia impedirem cobrir o escopo, o plano deve tornar visível a incompatibilidade e solicitar uma decisão.
- Uma estratégia incremental, por fases ou por releases pode ser utilizada quando o projeto a adota; não é uma obrigação do núcleo.
- A completude é determinada reconciliando a implementação e a evidência com a definição de produto completa e suas exceções aprovadas.
#### Job Stories como forma de referência
Este manifesto utiliza Job Stories como forma de referência para mostrar como um fundamento de produto pode ser transposto para o design, a implementação e a verificação. As Job Stories tornam explícitas a circunstância, a motivação e o resultado esperado, o que as torna uma representação especialmente útil para raciocinar sobre o progresso humano.
Sua utilização nas explicações, regras, exemplos e testes não obriga que toda definição de produto venha expressa por Job Stories nem autoriza transformar automaticamente um PRD nessa estrutura. Quando a definição utilizar outra forma, o método deve preservar seu significado, suas relações e sua autoridade. Uma Job Story derivada pode ser proposta como visão de trabalho quando acrescenta clareza, mas não substitui a fonte nem adquire autoridade por ter sido gerada.
#### De Jobs to Be Done a Job Stories
Jobs to Be Done e Job Stories cumprem funções distintas. Jobs to Be Done mantém a direção do produto: o progresso geral em função do qual uma pessoa adota uma solução em sua vida ou em seu trabalho. A Job Story leva esse progresso a uma situação concreta, capaz de orientar uma decisão de design, uma implementação e um teste.
Quando essa forma é utilizada, cada Job Story deve conservar uma relação explícita com o trabalho, propósito ou resultado de nível superior correspondente. Essa relação impede que uma história isolada perca a direção do produto.
#### Relação entre os níveis
| **Nível** | **Define** | **Evita** |
|--------------------------|--------------------------------------------------------------------------------------|------------------------------------------------------------|
| Jobs to Be Done | O progresso amplo que a pessoa busca conseguir | Organizar o produto em torno de funcionalidades |
| Job Story | A circunstância, a motivação e o resultado que ativam uma necessidade concreta | Projetar a partir de papéis genéricos ou pedidos literais |
| Resposta do produto | O comportamento do sistema escolhido para responder à história | Confundir o problema com a primeira solução imaginada |
| Evidência de aceitação | A observação que demonstra progresso naquela circunstância | Aceitar uma entrega porque funciona tecnicamente |
#### Forma canônica de uma Job Story
Quando ocorre uma circunstância observável, preciso avançar sem prescrever a solução, para poder alcançar um resultado reconhecível.
**Quando.** Descreve o fato, a mudança ou a tensão que ativa a necessidade. Deve poder ser observado ou reconhecido sem depender de uma persona fictícia.
**Preciso.** Expressa a motivação, a compreensão ou a decisão requerida. Não nomeia uma tela, um botão, um agente nem uma funcionalidade.
**Para poder.** Define a situação mais favorável que a pessoa busca alcançar e que depois deverá ser verificada.
#### Evidência mínima que acompanha a história
A frase guia a conversa, mas não substitui a pesquisa. Uma história pronta para orientar o desenvolvimento deve registrar apenas a evidência necessária para sustentar suas decisões.
| **Elemento** | **Pergunta** | **Conteúdo mínimo** |
|-------------------------|------------------------------------------------------------------|----------------------------------------------------------------|
| Comportamento atual | O que a pessoa faz hoje? | Passos, alternativa ou abandono observados |
| Obstáculo ou ansiedade | O que freia ou torna arriscado o avanço? | Dúvida, custo, receio, esforço ou dependência relevante |
| Evidência causal | O que sustenta a relação entre circunstância e motivação? | Observação, entrevista, dado de uso ou suposição declarada |
| Evidência de sucesso | O que demonstraria que houve progresso? | Comportamento ou resultado observável dentro da circunstância |
#### Quando o papel ainda importa
Job Stories evitam usar o papel como explicação automática. Não eliminam diferenças reais entre pessoas. Papel, experiência, idade, permissões ou uma restrição física devem ser incorporados quando mudam causalmente a circunstância, o risco ou a solução válida. Se não mudam a decisão, não devem governar a história.
#### Testes de qualidade antes de projetar
- A circunstância descreve um gatilho concreto, e não uma categoria de usuário.
- A motivação expressa progresso ou compreensão, e não uma funcionalidade solicitada.
- O resultado pode ser reconhecido sem confundi-lo com concluir o fluxo do produto.
- A história está sustentada por evidência ou identifica com clareza a suposição pendente.
- A formulação permite comparar várias respostas, inclusive a opção de não construir.
- O escopo é suficiente para mudar uma decisão, mas não tenta conter o trabalho inteiro da pessoa.
#### Cadeia de rastreabilidade
O desenvolvimento deve poder ser percorrido nas duas direções: de cada decisão implementada até o fundamento de produto que a justifica, e da definição completa do produto até a evidência que demonstra sua cobertura. Quando o fundamento se expressa por Job Stories, a rastreabilidade deve conservar a circunstância, a motivação e o resultado de cada história aplicável.
| **Origem** | **Decisão** | **Verificação** |
|-----------------------------|----------------------------------------------------------------------------------------|-----------------------------------------------------------------------------|
| Definição de produto | O que deve ser construído e sob que condições | Todo elemento obrigatório tem cobertura ou uma exceção aprovada |
| Jobs to Be Done | Que progresso geral merece atenção quando essa forma é aplicável | O resultado continua relevante para a pessoa |
| Job Story | Que circunstância concreta deve ser atendida quando a fonte utiliza essa forma | A história está validada e não prescreve uma solução não autorizada |
| Design e implementação | Que comportamento responde ao fundamento | Cada elemento tem uma razão rastreável |
| Aceitação | Que evidência autoriza declarar o desenvolvimento concluído | Resultados, regras e critérios se cumprem sob as condições definidas |
## DOUTRINA PARA DESENVOLVIMENTO COM IA
### Quando construir custa menos, a decisão importa mais
Os agentes de código reduzem o custo de transformar instruções em software. Essa vantagem muda o gargalo. O problema já não é apenas se uma capacidade pode ser construída, mas se ela merece existir, se resolve o problema certo e se preserva a compreensão da pessoa.
A IA deve absorver complexidade, não produzi-la.
Um agente pode implementar com grande velocidade uma especificação fraca, reproduzir padrões convencionais que não se encaixam no contexto e acrescentar opções plausíveis que ninguém pediu. Por isso o desenvolvimento assistido por IA precisa de uma camada explícita de intenção, limites e verificação.
#### Seis diretrizes para times e agentes
| **Diretriz** | **Exigência** | **Limite** |
|---------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------|
| `D01` Fundamento antes da implementação | Compreender a definição de produto, sua autoridade, seu escopo e a evidência que a sustenta antes de propor componentes ou código. Quando existirem Job Stories, conservar sua circunstância, motivação e resultado. | Não começar a construir se uma ambiguidade material puder alterar a solução, o escopo ou uma regra. |
| `D02` Especificação suficiente antes da geração | Definir estados, decisões, restrições e critérios de aceitação no nível necessário para o risco. | Não converter um prompt vago em uma implementação extensa e depois usar o código para descobrir o problema. |
| `D03` Simplicidade deliberada | Preferir a solução que exige da pessoa menos conceitos, decisões e esforço de memória quando ambas alcançam o mesmo resultado. | Menos código não é a medida; menos carga desnecessária, sim. |
| `D04` Determinismo onde importa | Implementar regras críticas, permissões, cálculos, estados e validações como lógica verificável. | Não delegar certeza, conformidade ou segurança ao comportamento variável de um modelo. |
| `D05` Verificação antes da aceitação | Avaliar o fluxo, os estados extremos, a acessibilidade, o desempenho e o resultado real. | Código gerado e testes unitários aprovados não equivalem a produto concluído. |
| `D06` IA subordinada à pessoa | Usar IA para propor, explicar e executar sob limites claros, mantendo revisão e reversibilidade proporcionais ao impacto. | A fluência de uma resposta nunca substitui evidência nem autorização. |
#### A segunda pergunta reitora
Agora que podemos construir quase qualquer coisa com mais facilidade, o que merece ser construído e o que devemos deixar deliberadamente de fora?
Esta pergunta introduz uma obrigação que antes podia ficar oculta pelo custo técnico. Deve ser formulada durante a definição de produto e ao avaliar alternativas, e não utilizada durante a implementação para recortar unilateralmente um escopo aprovado. Cada capacidade deve justificar sua existência em relação a uma alternativa mais simples, inclusive a alternativa de não construí-la; uma vez autorizada, qualquer exclusão exige uma decisão rastreável de produto.
#### Determinismo e geração
A escolha não é entre um produto determinista ou um produto com IA. Um sistema confiável combina ambos conforme a natureza de cada decisão.
| **Tipo de comportamento** | **Tratamento preferido** | **Exemplos** |
|------------------------------------------------------------------------|------------------------------------------------|------------------------------------------------------------------|
| Deve produzir sempre o mesmo resultado sob as mesmas condições | Regra determinista e teste automatizado | Permissões, preços, limites, cálculos, transição de estados |
| Admite várias respostas úteis e exige interpretação | IA com contexto, limites e avaliação | Explicar, resumir, propor alternativas, classificar texto |
| Pode afetar dinheiro, reputação, segurança ou direitos | A IA propõe; uma regra ou uma pessoa autoriza | Publicar, comprar, apagar, enviar, alterar acesso |
| A incerteza faz parte da saída | A IA declara suposições e nível de confiança | Recomendações, estimativas, informação incompleta |
## FLUXO DE TRABALHO
### Do propósito a uma solução verificável
O fluxo evita que a geração de código se torne o primeiro ato de design. Não pretende criar uma fase carregada de documentação nem impor uma estrutura ao PRD. Busca compreender o fundamento recebido, produzir a clareza necessária para planejar e manter cobertura até a aceitação.
| **Passo** | **Decisão** | **Trabalho** | **Evidência mínima** |
|-----------|----------------------------------------|--------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------|
| `F01` | Compreender o fundamento | Reconhecer as fontes, a autoridade, o escopo, a estrutura utilizada e os resultados esperados. | Mapa fiel da definição de produto, sem reformulá-la por conveniência técnica. |
| `F02` | Estabelecer cobertura | Inventariar histórias, capacidades, regras, estados, jornadas, critérios e relações aplicáveis. | Cobertura completa, com lacunas ou contradições visíveis. |
| `F03` | Planejar a implementação | Resolver dependências, bloqueios, ordem, paralelismo, integração e testes sem modificar o escopo. | Plano coerente que contempla toda a definição aprovada. |
| `F04` | Concretizar o progresso | Usar as Job Stories existentes ou formular uma visão derivada quando acrescentar clareza e estiver identificada como tal. | Circunstâncias, motivações e resultados preservados quando couber. |
| `F05` | Estabelecer o contrato de experiência | Descrever o que a pessoa deve compreender, decidir e sentir nos momentos críticos. | Caminho principal, estados e promessa de interação. |
| `F06` | Modelar regras e riscos | Separar lógica determinista, comportamento generativo, permissões e ações irreversíveis. | Mapa de decisões e limites. |
| `F07` | Explorar e prototipar | Comparar alternativas e testar compreensão, hierarquia e recuperação antes de otimizar código. | Razão da alternativa escolhida e evidência do percurso. |
| `F08` | Construir, integrar e verificar | Implementar o plano, manter rastreabilidade e reconciliar resultados com o escopo completo. | Código, testes e evidência de cobertura; pendências e exceções explícitas. |
#### Artefatos ajustados ao contexto
Cada artefato existe para responder a uma pergunta, não para satisfazer um modelo. Pode ser uma seção do PRD, uma visão derivada, uma tabela, um teste ou um documento separado. Se a informação já existe, deve ser referenciada e não duplicada. A profundidade depende da extensão, da complexidade, da incerteza e do risco; se um artefato não muda uma decisão nem ajuda a verificá-la, deve ser simplificado ou eliminado.
| **Artefato** | **Pergunta** | **Conteúdo mínimo** |
|---------------------------------------|-----------------------------------------------------------------|---------------------------------------------------------------------------------------------------------|
| `A01` Mapa do fundamento | O que deve ser construído, por quê e com que autoridade? | Fontes; escopo; resultados; regras; limites; evidência; não objetivos |
| `A02` Mapa de cobertura | Como todo o escopo será contemplado? | Elementos obrigatórios; relações; dependências; implementação; testes; estado; exceções |
| `A03` Ficha de Job Story quando couber | Quando surge a necessidade e que mudança a pessoa busca? | Circunstância; motivação; resultado; comportamento atual; ansiedade; evidência; suposições |
| `A04` Contrato de experiência | O que a pessoa deve compreender e conseguir fazer? | Caminho principal; linguagem; decisões; feedback; controle; recuperação |
| `A05` Modelo de estados | O que pode acontecer e que transições são válidas? | Estados; eventos; regras; erros; permissões; persistência |
| `A06` Orçamento de complexidade | Que carga estamos acrescentando? | Conceitos novos; decisões; passos; exceções; opções visíveis |
| `A07` Plano de aceitação | Que evidência autoriza declarar o desenvolvimento concluído? | Resultados; regras; Job Stories quando se aplicam; acessibilidade; desempenho; estados extremos; métricas |
| `A08` Registro de decisões | Por que escolhemos esta alternativa? | Alternativas; trade-offs; suposições; decisão; data; evidência pendente |
#### Regra de parada antes de gerar · `SH-STOP`
O agente não deveria começar uma implementação se não conseguir responder com precisão às perguntas a seguir, no nível exigido pelo risco e pela complexidade:
- Qual é a definição de produto autorizada e que escopo ela estabelece?
- Que elementos do fundamento justificam o desenvolvimento e que evidência os sustenta?
- O planejamento contempla todas as histórias, capacidades, regras, estados e critérios obrigatórios?
- Quando existem Job Stories, a circunstância, a motivação e o resultado estão separados da solução?
- Qual é o caminho principal e que estados alternativos importam?
- Que decisões a pessoa deve tomar e quais o sistema pode resolver?
- Que comportamento precisa de certeza determinista?
- O que não faz parte do escopo e quem estabeleceu essa exclusão?
- Que evidência demonstrará que o desenvolvimento está concluído?
Se faltar uma resposta capaz de mudar materialmente a solução, o escopo, uma regra ou um direito, o agente deve parar e solicitá-la. Se a incerteza for menor, reversível e estiver dentro da sua autoridade, ele pode declarar uma suposição e avançar sem reduzir silenciosamente a cobertura assumida.
## CONTRATO REUTILIZÁVEL
### Instruções para um agente de desenvolvimento
O contrato a seguir pode ser incorporado às instruções de um repositório, a um PRD ou ao prompt de um agente de código. Deve vir acompanhado do contexto específico do produto e não substitui a definição do problema.
**`CR01` Propósito.** Construa a solução mais simples que permita à pessoa alcançar o resultado definido, preservando clareza, controle e capacidade de recuperação.
**`CR02` Antes de programar.** Identifique as fontes autorizadas, explique o fundamento de produto e confirme o escopo completo. Reconheça a estrutura utilizada pela definição; quando contiver Job Stories, conserve sua circunstância, motivação e resultado. Separe evidência de suposições e identifique qualquer ambiguidade capaz de mudar materialmente a solução.
**`CR03` Ao planejar.** Contemple todos os elementos obrigatórios e estabeleça suas dependências, bloqueios, ordem, integração e testes. Não selecione, omita nem adie partes do escopo por iniciativa própria. Se as restrições impedirem cobri-lo, solicite uma decisão à autoridade de produto.
**`CR04` Ao propor.** Apresente a alternativa recomendada, uma alternativa mais simples e a opção de não construir, quando a decisão ainda pertencer a produto. Explique como cada uma responde ao fundamento, que carga introduz e que trade-offs exige.
**`CR05` Ao projetar.** Não exponha estruturas internas. Use a linguagem da pessoa, convenções conhecidas, hierarquia clara, profundidade progressiva, valores padrão editáveis e feedback imediato.
**`CR06` Ao usar IA.** Reserve as regras críticas para lógica verificável. Declare incerteza. Não execute ações de alto impacto sem autorização proporcional. Mantenha rastreabilidade, revisão e reversibilidade.
**`CR07` Ao implementar.** Respeite o escopo acordado e conserve rastreabilidade com seu fundamento. Não acrescente funcionalidades, modos, configurações nem abstrações não solicitadas. Cubra estados vazios, de carregamento, erro, sucesso e recuperação, e integre as partes relacionadas.
**`CR08` Antes de declarar o trabalho concluído.** Reconcilie a implementação com a definição completa de produto. Verifique resultados, regras, critérios e, quando couber, as Job Stories em suas circunstâncias. Verifique também acessibilidade, desempenho percebido, erros, persistência do trabalho e controle da pessoa. Apresente as evidências, as pendências e as exceções aprovadas.
#### Formato de entrega esperado do agente
1\. `O01` Fontes autorizadas e fundamento de produto que justificam o desenvolvimento.
2\. `O02` Inventário de escopo e cobertura de histórias, capacidades, regras, estados e critérios aplicáveis.
3\. `O03` Jobs to Be Done e Job Stories quando fazem parte da definição ou acrescentam uma visão derivada útil.
4\. `O04` Evidência disponível, suposições e critérios de resultado.
5\. `O05` Alternativa escolhida e razão do descarte de opções mais complexas.
6\. `O06` Arquivos ou componentes modificados e limites da mudança.
7\. `O07` Estados e casos extremos cobertos.
8\. `O08` Testes executados e evidência de resultado.
9\. `O09` Riscos, incertezas, pendências, exceções e decisões que ainda exigem julgamento humano.
#### Prompt breve para iniciar uma tarefa
Antes de escrever código, identifique a definição de produto autorizada, explique seu fundamento e confirme o escopo completo. Reconheça todas as histórias, capacidades, regras e critérios aplicáveis; quando existirem Job Stories, conserve sua circunstância, motivação e resultado. Distinga evidência de suposições. Planeje dependências e cobertura sem omitir nem adiar escopo por iniciativa própria. Implemente a solução mais simples que cumpra o aprovado e verifique resultados, integração, erros e recuperação.
## VERIFICAÇÃO
### Testes para aceitar uma solução
A aceitação deve produzir evidência. A impressão de que uma tela parece limpa ou de que o código compila não demonstra que o produto cumpre seu propósito.
| **Dimensão** | **Evidência de aceitação** |
|-----------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| `V01` Cobertura | Todos os elementos obrigatórios da definição de produto têm implementação e evidência, ou uma exceção explícita e aprovada. |
| `V02` Progresso | As pessoas alcançam os resultados definidos e conseguem reconhecê-los; quando existem Job Stories, isso é comprovado em suas circunstâncias. |
| `V03` Causalidade | A evidência relaciona a situação, a necessidade e o resultado sem depender de um pedido de funcionalidade; quando se aplica, conserva circunstância e motivação. |
| `V04` Compreensão | A pessoa consegue explicar onde está, o que pode fazer e o que acontecerá em seguida, sem ajuda externa. |
| `V05` Carga | Ela não enfrenta decisões, conceitos ou dados que o sistema poderia resolver com segurança. |
| `V06` Profundidade | Quem está começando encontra um caminho claro e a pessoa experiente conserva capacidade suficiente. |
| `V07` Confiança | O sistema antecipa consequências, confirma resultados e oferece recuperação proporcional. |
| `V08` Controle | A pessoa pode revisar, corrigir, recusar ou reverter conforme o impacto da ação. |
| `V09` Estados | Carregamento, vazio, erro, sucesso, interrupção e retorno mantêm contexto e orientação. |
| `V10` Acessibilidade | O fluxo funciona com teclado, foco visível, rótulos compreensíveis, contraste e tecnologias assistivas aplicáveis. |
| `V11` Desempenho | As ações críticas cumprem o orçamento de resposta ou mostram progresso honesto. |
| `V12` IA | As saídas variáveis declaram incerteza; as regras críticas são verificáveis; as ações sensíveis exigem autorização. |
#### Scorecard de decisão · `SH-SCORE`
Atribua 0 quando não houver evidência, 1 quando o cumprimento for parcial ou depender de uma suposição não validada, e 2 quando houver evidência suficiente. A pontuação orienta a conversa; não substitui o julgamento.
| **Critério** | **Pontuação** | **Pergunta de evidência** |
|---------------------------|---------------|---------------------------------------------------------------------------------------|
| Fundamento rastreável | 0 / 1 / 2 | Fontes, autoridade, escopo, resultados e condições são identificáveis |
| Cobertura do produto | 0 / 1 / 2 | Todo elemento obrigatório tem implementação, teste ou exceção aprovada |
| Job Stories aplicáveis | 0 / 1 / 2 | Quando existem, circunstância, motivação e resultado conservam evidência suficiente |
| Progresso da pessoa | 0 / 1 / 2 | A implementação produz os resultados definidos pelo produto |
| Carga cognitiva | 0 / 1 / 2 | Reduz ou justifica conceitos, decisões e passos |
| Clareza da interface | 0 / 1 / 2 | Estado, ação e consequência são compreendidos |
| Controle e recuperação | 0 / 1 / 2 | Existe revisão, correção ou reversibilidade proporcional |
| Profundidade progressiva | 0 / 1 / 2 | A capacidade aparece quando é apropriada |
| Confiabilidade e tempo | 0 / 1 / 2 | Desempenho, persistência e feedback cumprem o esperado |
| Uso responsável de IA | 0 / 1 / 2 | Incerteza, limites e determinismo estão resolvidos |
| Qualidade acumulativa | 0 / 1 / 2 | Estados, linguagem e microinterações são coerentes |
Critério de saída recomendado. Nenhuma dimensão crítica pode pontuar 0. Os critérios relacionados a segurança, permissões, dinheiro, dados pessoais ou ações irreversíveis devem pontuar 2 antes da liberação. Para os demais, o time deve definir seu limiar conforme o risco e o escopo.
#### Perguntas para uma revisão de produto
- Que fonte autorizada e que fundamento de produto justificam esta decisão?
- A implementação e seus testes dão conta do escopo completo?
- Quando existem Jobs to Be Done ou Job Stories, como esta decisão se relaciona com eles?
- A formulação descreve uma necessidade ou é uma funcionalidade redigida com outra fórmula?
- Que carga cognitiva ela introduz e qual elimina?
- Estamos expondo uma complexidade interna?
- É possível eliminar algum elemento sem reduzir capacidade nem controle?
- A pessoa sabe o que acontecerá antes de agir?
- Ela consegue se recuperar com facilidade se errar ou se o sistema falhar?
- A IA está propondo, decidindo ou executando? Esse nível está autorizado?
- O que nos faria rejeitar esta implementação ainda que ela funcione tecnicamente?
## ANTIPADRÕES · `SH-AP`
### Sinais de que o produto está se afastando do manifesto
| **Antipadrão** | **Como se manifesta** | **Resposta** |
|-------------------------------------------------|------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------|
| A Job Story é uma funcionalidade disfarçada | A motivação diz usar um painel, receber alertas ou apertar um botão. | Reformular o avanço de que a pessoa precisa sem antecipar a resposta. |
| A circunstância foi inventada | O time redige uma história plausível sem observar comportamento, tensão ou contexto real. | Marcá-la como hipótese e obter evidência antes de ampliar a implementação. |
| A interface replica o banco de dados | A pessoa precisa escolher tipos, estados ou relações internas. | Traduzir a estrutura para objetivos e decisões humanas. |
| Mais opções se confundem com mais valor | Cada exceção vira um controle visível. | Resolver por contexto e revelar exceções quando surgirem. |
| A IA preenche lacunas conceituais | Um prompt ambíguo produz uma implementação grande. | Parar, esclarecer suposições materiais e preservar o escopo autorizado. |
| O plano seleciona escopo | Algumas histórias ou regras são implementadas e o resto é adiado sem decisão de produto. | Restabelecer a cobertura completa ou registrar uma modificação explícita e aprovada. |
| A decomposição parece exclusão | Uma fase técnica é apresentada como se redefinisse o que o PRD exige. | Separar ordem de execução, estado de avanço e escopo assumido. |
| O tutorial compensa uma interface obscura | A tarefa básica exige explicação prévia. | Revisar linguagem, hierarquia, convenções e feedback. |
| A confirmação substitui a reversibilidade | Pergunta-se várias vezes, mas não existe desfazer. | Projetar recuperação e usar confirmações apenas conforme o risco. |
| O happy path define o produto | Erros, vazios e interrupções ficam para depois. | Modelar estados antes de implementar e aceitá-los explicitamente. |
| A resposta fluente parece verdadeira | A pessoa não distingue fato, inferência e proposta. | Mostrar fonte, incerteza, limites e rota de verificação. |
| A velocidade técnica esconde a espera | A operação demora sem feedback ou bloqueia todo o fluxo. | Responder de imediato, mostrar progresso e preservar continuidade. |
| A estética maquia o atrito | A tela parece boa, mas exige decisões desnecessárias. | Avaliar o percurso completo e o esforço real. |
| O agente acrescenta por via das dúvidas | Surgem modos, preferências e abstrações não solicitados. | Definir exclusões e exigir justificativa por capacidade. |
#### Uma advertência sobre a simplicidade
A simplicidade pode se tornar uma desculpa para ocultar informação, negar casos legítimos ou limitar a pessoa experiente. A estrutura não premia interfaces vazias. Premia a relação correta entre capacidade, momento e contexto.
A simplicidade valiosa não elimina o necessário. Ela evita exigi-lo antes da hora.
## EXEMPLO APLICADO
### Tutor de cálculo para alguém que ainda não entende
Considere um aplicativo que explica derivadas, propõe um exercício, oferece uma dica e por fim mostra a solução. O fluxo parece completo. No entanto, se a pessoa erra depois de ler a explicação e tampouco compreende a solução, ela chega a um beco sem saída. O aplicativo entregou conteúdo, mas não produziu progresso.
#### Do pedido de função à circunstância
**Formulação fraca.** Como estudante, quero receber dicas para poder resolver derivadas. O papel é genérico, a dica já prescreve a resposta e o resultado não distingue compreensão de avanço mecânico.
**Job Story principal.** *Quando li uma explicação e ainda não sei qual regra aplicar, preciso identificar o conceito anterior que não compreendo, para poder retomar o exercício sem depender de que me mostrem a solução.*
**Job Story de recuperação.** *Quando vejo a solução e continuo sem entender por que o passo seguinte foi escolhido, preciso reconstruir uma única decisão com outra representação, para poder explicar a regra com minhas próprias palavras.*
As duas histórias pertencem ao mesmo Jobs to Be Done de nível superior: desenvolver compreensão suficiente para resolver um exercício equivalente com autonomia crescente. No entanto, descrevem bloqueios distintos e podem exigir respostas diferentes.
#### Diagnóstico a partir do manifesto
| **Princípio** | **Problema observado** |
|---------------|-----------------------------------------------------------------------------------------|
| Progresso | O sistema mede etapas concluídas, não compreensão alcançada. |
| Experiência | A pessoa termina frustrada e sem uma rota de recuperação. |
| Complexidade | A explicação conserva o modelo de quem já sabe em vez de reconstruir o conceito. |
| Interface | Números ou etapas sem significado acrescentam aprendizado incidental. |
| Confiança | A solução final é apresentada como encerramento, embora a compreensão continue ausente. |
#### Evidência que completa a Job Story
| **Elemento** | **Observação** |
|---------------------------|-------------------------------------------------------------------------------------------------------|
| Comportamento atual | A pessoa pede uma dica, depois a solução, e mesmo assim não consegue decidir que regra aplicar. |
| Obstáculo e ansiedade | Não identifica o pré-requisito ausente e teme avançar sem compreender. |
| Evidência de sucesso | Consegue escolher e explicar a regra em um exercício equivalente com menos ajuda. |
#### Redesenho do percurso
1\. Detectar o tipo de bloqueio: conceito, notação, operação anterior ou interpretação do enunciado.
2\. Reformular com uma representação diferente, sem repetir a mesma explicação com mais palavras.
3\. Verificar uma micro-habilidade anterior por meio de uma pergunta breve e diagnóstica.
4\. Oferecer um exemplo resolvido passo a passo, com uma decisão por vez e na linguagem do estudante.
5\. Pedir que a pessoa explique o raciocínio ou complete um passo equivalente antes de avançar.
6\. Manter sempre uma rota para voltar, trocar de explicação ou pedir ajuda humana.
#### O que permanece determinista e o que pode usar IA
| **Camada** | **Responsabilidade** |
|-------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Determinista | Sequência de estados; validação matemática; domínio dos pré-requisitos; registro de tentativas; regras de avanço; prevenção de becos sem saída. |
| Assistida por IA | Reformular uma explicação; gerar uma analogia; classificar o bloqueio; adaptar o tom; propor um exercício equivalente dentro de limites validados. |
| Controle humano | Permitir ao estudante ou ao tutor escolher outra via, revisar o histórico e corrigir uma inferência equivocada do sistema. |
#### Critério de sucesso
O objetivo não é que o estudante chegue ao fim da sequência. É que ele consiga resolver ou explicar um exercício equivalente com menos ajuda. Essa diferença muda a interface, a lógica, a medição e o uso de IA.
## GOVERNANÇA · `SH-GOV`
### Como transformar o manifesto em prática habitual
O manifesto perde valor se ficar restrito a uma apresentação inicial. Ele deve aparecer nos momentos em que o time toma decisões: definição, design, geração, revisão e aprendizado posterior ao lançamento.
#### Responsabilidades
| **Responsável** | **Obrigação principal** |
|------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Produto | Estabelece a definição autorizada, o escopo, os resultados, as regras, os não objetivos e a evidência de sucesso; valida Jobs to Be Done e Job Stories quando são utilizados. |
| Design | Traduz o fundamento de produto em percursos coerentes com o modelo mental da pessoa e protege sua atenção; usa Job Stories quando permitem concretizar a situação. |
| Engenharia | Absorve complexidade e garante estados, desempenho, acessibilidade e recuperação. |
| Agente de IA | Planeja e implementa dentro do fundamento e do contrato; declara suposições, mantém cobertura e não reduz nem amplia escopo por iniciativa própria. |
| Revisão humana | Avalia causalidade, sentido, risco, experiência completa e evidência; não se limita a revisar código. |
#### Pontos de controle
| **Momento** | **Decisão requerida** |
|----------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------|
| Antes de projetar | Fontes, autoridade, escopo, resultados, evidência, suposições e não objetivos estão claros; as Job Stories são compreendidas quando existem. |
| Antes de gerar código | O plano cobre a definição completa e estabelece dependências, resposta escolhida, rotas, estados, regras críticas, riscos e aceitação. |
| Durante a construção | A decomposição organiza o trabalho sem alterar o escopo; bloqueios, pendências e exceções permanecem visíveis. |
| Antes de integrar | Cada mudança conserva rastreabilidade com seu fundamento, respeita o escopo, cobre estados e passa nos testes técnicos. |
| Antes de liberar | A implementação completa demonstra resultados, cobertura, compreensão, controle e qualidade de experiência. |
| Depois de liberar | Observam-se resultado, atrito, abandono e erros; revisam-se o fundamento, as histórias e suas suposições quando couber. |
#### Evolução do manifesto
Os princípios devem ser estáveis; as regras e os testes podem evoluir com novas evidências. Toda mudança deveria registrar o problema observado, a decisão modificada e a razão. A estrutura não deve crescer por acumulação: uma regra nova só é incorporada se resolver uma lacuna que as existentes não cobrem.
#### Controle de mudanças das versões 2.0 e 2.1
A versão 1.0 permanece como formulação fundacional. A versão 2.0 conserva sua tese e seus dez princípios, mas substitui referências operacionais genéricas a Jobs to Be Done por uma cadeia mais concreta e verificável.
| **Área** | **Ajuste da versão 2.0** | **Conteúdo que permanece** |
|-------------------------|--------------------------------------------------------------------------------------|---------------------------------------------------------------------------|
| Unidade de design | A Job Story concretiza o progresso no contexto de Jobs to Be Done. | O progresso da pessoa continua sendo a medida principal. |
| Arquitetura | Incorpora-se um nível entre princípio e regra. | Princípios, regras e testes conservam sua função. |
| Fluxo e artefatos | Exigem-se circunstância, motivação, resultado e evidência antes de projetar. | Mantém-se a documentação mínima que muda decisões. |
| Desenvolvimento com IA | O agente deve reformular e respeitar a Job Story. | Continuam os limites, o determinismo e a revisão humana. |
| Aceitação | O resultado é testado sob a circunstância descrita. | Acessibilidade, desempenho, estados e controle seguem obrigatórios. |
| Exemplo e governança | Acrescentam-se rastreabilidade causal e validação de histórias. | O tutor de cálculo e os pontos de controle conservam seu propósito. |
A versão 2.1 preserva a tese, os dez princípios, a doutrina para IA, as Job Stories e o exemplo aplicado. Amplia o núcleo para admitir definições de produto de forma, extensão e profundidade distintas, sem impor uma estrutura a montante nem supor uma estratégia incremental.
| **Área** | **Ajuste da versão 2.1** | **Conteúdo que permanece** |
|--------------------------|-----------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------|
| Fundamento | Define-se uma base autorizada, rastreável e verificável, que pode assumir formas distintas. | O progresso humano continua como medida principal. |
| Job Stories | Declaram-se forma de referência, e não estrutura universal obrigatória. | Conservam-se sua forma canônica, evidência, testes e exemplos. |
| Escopo | Exige-se cobertura completa e proíbem-se omissões ou adiamentos não autorizados. | Produto segue definindo escopo e não objetivos. |
| Planejamento | Separam-se decomposição, sequência e paralelismo de qualquer decisão de escopo. | Continuam a clareza prévia, as regras, os riscos e a aceitação. |
| Estratégia de entrega | A incrementalidade deixa de ser uma suposição do núcleo. | Cada projeto pode adotar fases ou releases quando couber. |
| Implementação SDD | Reserva-se para anexos e adaptadores independentes. | O núcleo conserva princípios e garantias que toda implementação deve respeitar. |
#### Definição de conclusão · `SH-DONE`
Um desenvolvimento está completo quando todos os elementos obrigatórios da definição de produto têm uma implementação e uma evidência verificável, ou uma exceção explícita e aprovada; quando as pessoas alcançam os resultados previstos sob as condições definidas; e quando o comportamento do sistema e a qualidade da experiência foram verificados com rigor proporcional ao risco.
Quando o fundamento inclui Job Stories, a verificação deve demonstrar o resultado em suas circunstâncias. A completude inclui código correto, mas não termina aí. Exige cobertura do escopo, integração entre suas partes, estados críticos confiáveis, uma experiência que não obrigue a aprender a arquitetura do produto, IA dentro de limites explícitos e clareza sobre o que deve ser observado depois do lançamento.
## GUIA DE BOLSO · `SH-POCKET`
### Catorze perguntas antes de aceitar uma decisão
1\. Qual é a fonte autorizada e que escopo ela estabelece?
2\. O planejamento contempla todos os elementos obrigatórios?
3\. Que circunstância concreta ativa a necessidade?
4\. Que motivação ou tensão impulsiona a pessoa a agir?
5\. Que resultado permitiria reconhecer o progresso?
6\. Que comportamento ou evidência demonstra que a história ocorre?
7\. Quando existe uma Job Story, ela descreve o problema sem prescrever a solução?
8\. Que complexidade o sistema absorve e qual ainda transfere à pessoa?
9\. O que a pessoa precisa ver agora e o que pode esperar?
10\. O que acontecerá se ela errar, interromper ou voltar depois?
11\. Ela conserva controle sobre a decisão, os dados e o resultado?
12\. Que parte precisa de determinismo e que parte admite geração?
13\. Qual é a alternativa mais simples que atende ao fundamento de produto?
14\. Que evidência nos permitiria dizer que está concluído?
#### Sete razões para parar uma implementação
- `STOP01` Não existe um fundamento de produto identificável ou a solução parece preceder o problema.
- `STOP02` O plano não contempla todo o escopo obrigatório definido por produto.
- `STOP03` Pretende-se omitir, modificar ou adiar uma parte sem uma decisão autorizada.
- `STOP04` Uma ambiguidade material está sendo resolvida pelo agente sem autorização.
- `STOP05` A interface expõe uma complexidade interna que o sistema poderia absorver.
- `STOP06` Uma ação sensível carece de determinismo, rastreabilidade ou recuperação.
- `STOP07` O time só consegue demonstrar que o código funciona, não que a pessoa progride.
#### Três frases que protegem o critério
Que circunstância ativa esta necessidade?
Que progresso ela habilita?
Que evidência o demonstra?
## INFLUÊNCIAS E NOTAS
### Origem da perspectiva
Esta estrutura é uma elaboração independente, inspirada em ideias públicas da Craft e nas conversas que deram origem a este documento. Não é um manifesto oficial da Craft e não atribui ao seu fundador as regras operacionais aqui propostas.
Quatro influências vêm da Craft: a união entre forma e função; o efeito que uma ferramenta produz na energia e na capacidade de quem a usa; a complexidade adaptável que aparece quando é necessária; e a abordagem human first, em contraste com sistemas que obrigam as pessoas a se acomodarem à sua estrutura.
De Jobs to Be Done conserva-se o progresso como referência superior. De Job Stories adota-se uma forma concreta de transpor esse progresso para o design, por meio de circunstâncias, motivações, resultados, comportamento atual, ansiedades e evidência causal.
A versão 2.1 integra essas influências dentro de um núcleo capaz de respeitar definições de produto heterogêneas. As Job Stories permanecem como forma de referência e exemplo aplicado; não substituem outras estruturas autorizadas nem permitem recortar seu escopo.
#### Fontes consultadas
Craft. [Sobre a Craft](https://www.craft.do/es/about). História do fundador e reflexões sobre forma, função, atrito, complexidade adaptável e atenção ao detalhe.
Balint Orosz. [Introducing Craft 3](https://www.craft.do/blog/welcome-to-craft3), 28 de novembro de 2024. Adaptação ao contexto, redução de carga cognitiva, desempenho e funcionamento offline.
Balint Orosz. [Your content is yours and that is more empowering than ever](https://www.craft.do/blog/your-content-is-yours), 27 de novembro de 2025. Controle sobre o conteúdo, portabilidade, IA e o princípio human first versus systems first.
Alan Klement. [Designing Features Using Job Stories](https://www.intercom.com/blog/using-job-stories-design-features-ui-ux/), publicado pela Intercom em 23 de dezembro de 2013. Aplicação granular de Jobs to Be Done ao design de funcionalidades, interface e experiência por meio de contexto, causalidade, motivações e ansiedades.
#### Declaração final
A tecnologia pode ser extraordinariamente sofisticada por trás da interface. Diante dela deve permanecer uma pessoa concentrada naquilo que queria alcançar.