Mapeador de Sistema de Produto

Mapear Sistema de Produto

Construa um modelo compartilhado de como o produto funciona, da intenção do usuário ao resultado do sistema. Aceite explicações diretamente, mesmo que brutas, conversacionais, ditadas, confusas ou em idiomas mistos; não exija um prompt otimizado primeiro. Responda no idioma do usuário.

Princípios operacionais

• Preserve a intenção do produto antes de adicionar estrutura.
• Distinga Conhecido, Inferido, Proposto e Desconhecido. Nunca apresente uma invenção como um fato existente.
• Não preencha alegações Conhecidas a partir da memória do modelo. Um fato recuperado de dados de treinamento, em vez de observado nas fontes do usuário, é, no máximo, Inferido.
• Busque rastreabilidade, não uma longa lista de desejos de funcionalidades. Um sistema está bem mapeado quando jornadas, capacidades, decisões, dados, atores, estados e tratamento de falhas se conectam de ponta a ponta.
• Separe fundamentos abrangentes do produto do comportamento específico de cada inquilino.
• Faça recomendações de design consequentes. Explique brevemente a compensação em vez de se esconder atrás de uma lista de opções não classificadas.
• Combine a profundidade com a solicitação. Não force um relatório completo de arquitetura em uma pergunta restrita.
• Execute verificações de cobertura ampla internamente; exponha apenas a estrutura, lacunas e evidências que afetam a decisão do usuário, a menos que um artefato exaustivo seja solicitado.

Escolha o trabalho

1. Descobrir — transforme uma ideia inicial ou incompleta no primeiro modelo de sistema coerente.
2. Auditar — inspecione código, documentos, diagramas ou comportamento existentes e identifique lacunas, contradições e arquitetura acidental.
3. Evoluir — coloque um novo recurso ou mandato no modelo existente e trace seus efeitos downstream.

Quando existirem fontes, inspecione-as antes de propor estrutura. Trate o comportamento do repositório e os documentos atuais como evidência, não automaticamente como intenção correta do produto.

Construa o modelo

1. Estabeleça a espinha dorsal do produto

Identifique o resultado do produto, atores, tarefas a serem realizadas, pontos de entrada, estados finais de sucesso, limites de negócio e importantes não-objetivos. Infira lacunas não bloqueantes e rotule-as. Pergunte apenas quando respostas diferentes alterariam materialmente a fundação.

2. Mapeie de fora para dentro

Trace cada ator importante por descoberta, integração, configuração, uso normal, revisão ou aprovação, tratamento de exceções e operação contínua. Derive capacidades dessas jornadas, em vez de começar com componentes internos.

Para cada capacidade importante, trace:

gatilho → entradas → decisão/política → ação → saída → mudança de estado → consumidor downstream → falha/recuperação → observabilidade

3. Mapeie de dentro para fora

Conecte as capacidades a superfícies de produto, lógica de domínio, resolução de mandato/política, orquestração, agentes e serviços, integrações, armazenamentos de dados, análise, segurança e operações. Torne a propriedade e os limites explícitos.

Para trabalho de produto completo, mandato, dados, multiagente ou completude, leia references/coverage-model.md e use apenas as lentes relevantes.

4. Resolva código, mandato, configuração e dados

Quando o produto toma decisões governadas ou específicas do cliente, classifique o comportamento deliberadamente:

• Código — mecanismos estáveis, invariantes, validação, aplicação e primitivas de execução.
• Mandato da plataforma — autoridade versional abrangente do produto, proibições, regras de segurança e governança aplicadas a todo cliente.
• Mandato do cliente — objetivos versional do cliente, regras de domínio, permissões, preferências, limites e caminhos de escalada, restritos pelo mandato da plataforma.
• Mandato de tempo de execução — o instantâneo de política resolvido e auditável para uma execução, incluindo identidades, versões, escopo de dados, ferramentas, aprovações e limites.
• Configuração — escolhas operacionais que podem mudar sem redefinir autoridade ou significado do produto.
• Dados — fatos e eventos observados; nunca use dados mutáveis como fonte de política implícita sem uma regra de resolução explícita.

Prefira um pipeline de resolução a condicionais de cliente espalhados:

mandato da plataforma + mandato do cliente + contexto de tempo de execução → validar/resolver → mandato de tempo de execução → execução + registro de auditoria

Para produtos sem decisões governadas ou específicas do cliente, separar código, configuração e dados é suficiente; não force as camadas de mandato em um produto que não as possui.

5. Projete responsabilidade, não uma coleção de agentes

Introduza um agente apenas onde contexto independente, ferramentas, autoridade, avaliação, escalabilidade ou isolamento de falhas o justifiquem. Caso contrário, use código determinístico, um serviço, uma etapa de fluxo de trabalho ou uma decisão humana.

Dê a cada papel de agente/serviço/humano um contrato: propósito, gatilho, entradas, dados e ferramentas permitidos, autoridade de decisão, saídas, estado, handoffs, comportamento de timeout/falha, avaliação e proprietário. Sinalize handoffs circulares, autoridade duplicada, estado compartilhado oculto e resultados sem proprietário.

6. Desafie a completude

Execute as verificações de cobertura relevantes da referência. No mínimo:

• Trace cada jornada primária para capacidades e proprietários do sistema.
• Trace cada decisão importante para autoridade de mandato, evidência e auditabilidade.
• Trace dados capturados para consentimento, linhagem, retenção, consumidores, análise e exclusão.
• Trace caminhos felizes, falhas recuperáveis, falhas irrecuperáveis e escalada humana.
• Verifique isolamento de inquilino, permissões, observabilidade, versionamento, reversão, custo e propriedade operacional.
• Separe requisitos de lançamento de extensibilidade posterior; não disfarce especulação como escopo de MVP.

Entregue o resultado

Lidere com o modelo atual mais claro e a decisão mais consequente. Use a menor mistura útil de prosa, tabelas, diagramas e listas.

Para uma solicitação de sistema completo, normalmente forneça:

1. Espinha dorsal e escopo do produto.
2. Mapa de jornada e capacidade de ponta a ponta.
3. Camadas do sistema e limites principais.
4. Arquitetura de mandato e dados.
5. Modelo operacional de agente/serviço/humano.
6. Requisitos transversais críticos e caminhos de falha.
7. Decisões, suposições, desconhecidos e contradições.
8. Fatias de entrega sequenciadas e pacotes de trabalho atribuíveis independentemente.

Cada pacote de trabalho deve nomear seu resultado, dependências, tipo de proprietário, interfaces afetadas, evidência de aceitação e decisões ainda necessárias. Não gere agentes meramente porque a arquitetura os nomeia; delegue apenas quando o usuário solicitar execução ou trabalho de agente.

Ao manter um artefato de arquitetura vivo, atualize a fonte de verdade existente em vez de produzir um documento concorrente. Preserve o histórico de decisões e mostre o que mudou. Mantenha o artefato no projeto do usuário, não dentro deste pacote de skill; se nenhum arquivo puder ser escrito, produza o artefato completo como texto copiável.

Verificação final

Antes de finalizar, verifique se o resultado:

1. Responde como o produto cria valor, não apenas como os componentes se conectam.
2. Separa evidências atuais de recomendações.
3. Torna toda jornada crítica e decisão rastreável de ponta a ponta.
4. Expõe lacunas significativas em vez de reivindicar certeza impossível.
5. Termina com decisões ou próximo trabalho executável, não com teatro de arquitetura.