Feature Spec Builder

Transforme "meia dúzia de palavras" em "especificações de recurso em nível de engenharia".

O núcleo não é escrever documentos, mas sistematicamente extrair e completar o que não foi dito em uma frase. Uma frase "preciso da funcionalidade XX" geralmente omite 80% das informações necessárias para o desenvolvimento: papéis, cenários, limites, atribuições de capacidade, interfaces, dependências e critérios de aceitação. Esta skill usa uma abordagem de "varredura por dimensões fixas + esclarecimento interativo pergunta por pergunta" para preencher essas lacunas, resultando em uma especificação de recurso que passa pela revisão de engenharia.

O resultado desta skill termina na especificação do recurso — incluindo rascunhos de contratos de interface e critérios de aceitação, mas não faz divisão de tarefas ou planos de implementação, que ficam a cargo do time de engenharia.

Área de Configuração (preencha antes do primeiro uso)

Esta skill depende de um sistema de coordenadas de produto próprio e convenções de equipe para classificação e colaboração. Substitua os placeholders pelas definições reais da sua equipe; agrupados por tema, grupos não utilizados podem permanecer como padrão.

A. Sistema de Coordenadas de Capacidade

L1 = <ex: Capacidade Atômica / Interface Subjacente de Movimento e Percepção>
L2 = <ex: Capacidade Combinada / Pacote de Desenvolvimento em Nível de Aplicação>
L3 = <ex: Solução Completa / Entrega de Cenário>
Cinco Domínios: Domínio1=<…> Domínio2=<…> Domínio3=<…> Domínio4=<…> Domínio5=<…>

B. Convenções de Interface

Orçamento de API = <ex: limite de 300 métodos>    Convenção de Linguagem/ Binding = <ex: C++ core + pybind11>

C. Integradores e Formatos

Níveis de Integrador = <ex: Associado / Profissional / Especialista>    Formato = <Simulação / Robô Real / Ambos>
Diretório de Saída = <padrão feature-specs/; saída em <este diretório>/<nome do recurso>/<nome do recurso>.md>

D. Princípios de Produto (régua para o gate de auto-verificação antes da saída)

Usar princípios padrão internos: Sim / Não (padrão=Sim, texto completo em references/product-principles.md)
Princípios personalizados/complementares da equipe: <pode ficar vazio; se preenchido, mescla com os padrões internos, conflitos resolvidos pela equipe>
Prioridade de conflitos: <Duas restrições rígidas não podem ser substituídas: segurança padrão e compatibilidade com versões anteriores são linhas vermelhas; se ambas colidirem, deve ser escalado para decisão humana; para os demais princípios, preencha a ordem de prioridade relativa aqui; se vazio, conflitos são sempre devolvidos ao usuário para decisão, sem ordenação automática>
Autoridade para alterações disruptivas: <quem precisa assinar quando uma alteração é considerada break, ex: Arquiteto de Plataforma>

E. Mapeamento Camada de Implementação × Departamento (usado no passo 4 para decomposição entre camadas e atribuição de owners; ortogonal ao L-Tier — L-Tier define quão alto é a abstração externa, enquanto a camada de implementação define quais pilhas técnicas internas e departamentos são envolvidos)

Camada de Implementação → Departamento/Responsável Owner → Signatário entre Camadas
  Camada de Runtime:
    Camada SDK de segunda ordem   → <preencher, ex: SDK/Grupo de Plataforma>   → <signatário>
    Software Subjacente (firmware/middleware)  → <preencher, ex: Grupo Embarcado/Firmware> → <signatário>
    Serviços de Algoritmo (percepção/algoritmo)  → <preencher, ex: Grupo de Algoritmos>       → <signatário>
    Hardware (mecânico/eletrônico)        → <preencher, ex: Grupo de Hardware/Eletrônica>   → <signatário>
  Camada de Não-Runtime (características ecológicas/integração/documentação caem aqui, não force para grupos de firmware/algoritmo/hardware):
    Camada de Portal de Documentação      → <preencher, ex: DevRel/Documentação/Frontend do Site> → <signatário>
    Camada de Infraestrutura de Build/Distribuição        → <preencher, ex: Build SDK/DevOps>      → <signatário>
  Caminho de Escalação entre Departamentos = <ex: Owner da Camada → Responsável do Departamento → Reunião de Revisão de Arquitetura entre Departamentos → CTO>

Se a área de configuração não for preenchida: Pelo menos complete o grupo A (níveis de capacidade + cinco domínios), pois estes dois determinam diretamente a precisão da classificação. Para os demais grupos, tratamento rebaixado:

A/B/C não preenchidos: Na classificação (passo de classificação automática), declare explicitamente "os seguintes níveis L/domínios/orçamento de API/binding são minha inferência" e forneça a justificativa; em todos os campos do corpo que usam este sistema de coordenadas (nível, domínio de capacidade, orçamento de API, convenção de binding, distribuídos nas seções "/Posicionamento da Capacidade", "/Avaliação de Impacto·Compatibilidade·Estratégia de Lançamento", "/Rascunho do Contrato de Interface"), marque com [Pendente de Confirmação], nunca escreva valores inferidos como confirmados; coloque "Valores reais da área de configuração a serem preenchidos" na seção "/Itens Pendentes de Confirmação".

D não preenchido: Aplicar por padrão as 10 regras padrão internas de references/product-principles.md e anotar na seção "/Auto-Verificação de Princípios de Produto" que "Esta especificação utiliza os princípios de produto padrão internos". O gate de auto-verificação de princípios de produto deve ser executado em qualquer circunstância, nunca deve ser pulado mesmo que a área de configuração esteja vazia.

E não preenchido: No passo 4 de decomposição entre camadas, todos os owners/departamentos/signatários devem ser marcados com [Pendente de Confirmação·Necessita Atribuição], indicando ao usuário para preencher, nunca invente nomes de departamentos — atribuir erroneamente responsabilidades de departamento inferidas ao time errado é o fracasso mais perigoso.

F. Organização e Processos (configuração privada local, para colaboração em nível de empresa)

O que cada empresa faz, quais gates de processo existem e como as versões são organizadas são diferentes e privados, não são escritos nesta skill. Para colaboração em nível de empresa, copie o template de references/org-process-config.md para um org-process.local.md local (ou execute scripts/init-org-config.sh para gerar) e preencha com o mapa de papéis da sua empresa / gates de entrega / ritmo de versão e capacidade do pipeline. Privado localmente, não comitar (já está em .gitignore).

Com esta configuração: Na saída, mapeie os owners para pessoas reais de acordo com o mapa de papéis, liste os gates obrigatórios e artefatos de entrega em "/Avaliação de Impacto·Compatibilidade·Estratégia de Lançamento", marque a versão alvo e o esforço (dias-homem) vs. capacidade do pipeline, e sinalize mudanças após o bloqueio do requisito para seguir o CCB (detalhes em references/org-process-config.md).

Sem esta configuração: Use placeholders de papéis genéricos (ex: [Gerente de Produto·A Atribuir]) e sugira ao usuário que pode gerar uma configuração local. Em nenhuma circunstância escreva nomes reais de pessoas/processos internos na skill ou produza em documentos que circularão publicamente.

Fluxo de Trabalho

Após receber um fragmento de requisito, siga rigorosamente esta cadeia principal:

Receber Fragmento → Dividir Demanda (identificar múltiplos recursos implícitos) → Classificação Automática → Decomposição entre Camadas e Roteamento (identificar mudanças por camada·owner·ordem de dependência) → Primeiro Esclarecimento (Posicionamento·Grosso) → Segundo Esclarecimento (Detalhes Funcionais·Fino) → Gerar Documento (passar pelo gate de auto-verificação de princípios)

Passo 1: Receber e Reafirmar

Leia o fragmento dado pelo usuário. Primeiro, reafirme seu entendimento em uma frase ("Entendo que você quer..., correto?") para que o usuário confirme ou corrija. Isso evita desvios desde o início.

Passo 2: Dividir Demanda (Identificar se há múltiplos recursos implícitos)

Uma solicitação vaga muitas vezes contém mais de um requisito — especialmente fragmentos colados de bate-papos/e-mails originais, onde a solicitação principal é a mais óbvia, mas há outras solicitações espalhadas, perguntas desviadas pela conversa, ou capacidades implícitas inferidas pelo objetivo final. Não mergulhe na solicitação mais óbvia e comece a fazer, faça primeiro uma varredura de divisão:

Leia o fragmento por completo e liste cada solicitação que pode ser independente (uma ação / uma capacidade = um recurso candidato). Preste atenção especial a quatro tipos frequentemente esquecidos: ① a "pergunta original" desviada por perguntas de acompanhamento; ② solicitações independentes não relacionadas à solicitação principal, apenas mencionadas na mesma conversa; ③ pontos onde a engenharia já respondeu "não suportado por enquanto / implemente você mesmo" (muitas vezes são requisitos ocultos enterrados); ④ capacidades combinadas inferidas a partir do objetivo final do cliente, mas não explicitamente declaradas atualmente.
Heurística de artefatos heterogêneos: Quando uma frase de solicitação contém simultaneamente diferentes formas de artefatos de entrega (código executável / contrato de interface / conteúdo de documentação / estrutura do site / pacote de distribuição), suspeite primeiro de múltiplos recursos — diferentes formas de artefatos geralmente correspondem a diferentes owners, diferentes formas de aceitação e diferentes ciclos de manutenção. Misturar pode fazer com que os objetos de revisão e os critérios de aceitação entrem em conflito em um único md (ex: "dar um exemplo ROS + adicionar uma seção no site oficial" = recurso de código + recurso de documentação, com owners e aceitação completamente diferentes).
Cluster de recursos relacionados com fonte de verdade compartilhada: Se vários recursos extraídos compartilham uma única fonte de verdade (ex: tutorial de documentação = código do repositório de exemplo = projeção externa do contrato do recurso principal), ainda assim documente cada um de forma independente, mas em cada "/Dependências e Pré-requisitos" / recurso relacionado, fixe explicitamente a atribuição da fonte de verdade (qual documento/repositório possui o direito de definição, os demais são projeções/referências) e forneça um gráfico de dependências dentro do cluster — reutilizando o paradigma de "atribuição do direito de definição" do "/Contrato de Transferência entre Camadas" para evitar que vários documentos escrevam versões diferentes e não correspondam.
Se realmente houver apenas uma solicitação, anote "Recurso único confirmado" e vá diretamente para a classificação.
Se houver várias, desenhe uma tabela de divisão de demanda (Recurso Candidato | Fala Original | Natureza | Status Atual | Relação/Dependência com a Solicitação Principal) e então peça ao usuário para decidir quais refinar nesta rodada — isso é escopo de escolha, nunca decida por ele. Para os não selecionados, deixe um "placeholder de recurso relacionado" na seção "/Itens Pendentes de Confirmação" para facilitar a criação posterior de um novo item.
Ao fazer vários recursos juntos, cada recurso produz um documento de especificação de recurso independente, nunca misture vários requisitos no mesmo documento — percorra os passos subsequentes um por um, apenas referenciando-se mutuamente com "recursos relacionados" e marcando as dependências (ex: D depende de A+B). (Nota: Mesmo que um recurso abranja camadas, produza apenas um md com seções divididas por leitor-alvo internamente, não divida em vários arquivos; isso é "subcamadas dentro do mesmo recurso / divisão por leitor-alvo", o que não entra em conflito com "vários recursos com documentos independentes".)

Este passo é o mais fácil de pular em toda a cadeia, mas o que mais afeta a correção da entrega: pular pode fazer com que a engenharia receba apenas uma parte da solicitação do cliente, ou junte vários recursos que deveriam ser independentes em um só.

Passo 3: Classificação Automática

Fixe o requisito no sistema de coordenadas: em qual nível L1/L2/L3 ele se encaixa, a qual dos cinco domínios pertence e se é entre domínios. A classificação em si já expõe o primeiro lote de problemas implícitos — se você não consegue classificar de forma limpa, significa que o fragmento carece de informações em alguma dimensão, que é exatamente a lacuna a ser esclarecida posteriormente. Anote as incertezas da classificação.

Nota: A classificação fixa o nível de abstração externo (L-Tier) e o domínio de capacidade, não responde "quais camadas de implementação internas isso afeta, a qual departamento pertence" — isso é assunto do próximo Passo 4. Uma interface L1 pode afetar apenas a camada SDK de segunda ordem, ou pode afetar todo o caminho até firmware/algoritmos/hardware.

Saída N/A do L-Tier para características de não-runtime: Se a característica é essencialmente uma forma de entrega/distribuição/instalação/documentação de capacidade existente (não uma nova capacidade de runtime, não expõe API, não consome orçamento de API, como pacotes de instalação offline/repositórios de exemplo/seções do site oficial — protótipos H/I), o L-Tier deve ser explicitamente marcado como N/A (não é uma característica de capacidade, apenas no eixo da camada de implementação), os cinco domínios podem ser N/A, não force um valor L. Sinal de decisão: o artefato de entrega é "pacote de distribuição/documentação/estrutura do site" em vez de "API/comportamento de runtime"; seu foco muda para a camada de infraestrutura de build/distribuição ou camada de portal de documentação + eixo de dependência externa (Passo 4).

Passo 4: Decomposição entre Camadas e Roteamento (Obrigatório para características entre camadas)

A classificação responde apenas "em qual L, qual domínio"; este passo responde a "quais camadas de implementação este requisito afeta, a quem cada camada pertence, qual a ordem de precedência, e se pode ser entregue de forma independente apenas com SDK de segunda ordem". Muitos requisitos de cliente parecem estar na camada SDK de segunda ordem, mas dependem fortemente de camadas inferiores — firmware/middleware, serviços de algoritmo, ou até hardware — e essas camadas geralmente pertencem a departamentos diferentes.

Siga as cinco ações em references/cross-layer-routing.md:

Avaliar camada por camada se precisa ser modificada: Para as quatro camadas de runtime — Camada SDK de segunda ordem / Software Subjacente (firmware/middleware) / Camada de Serviços de Algoritmo / Camada de Hardware — pergunte camada por camada "o que precisa ser mudado nesta camada". Além disso, pergunte obrigatoriamente sobre dois tipos de camadas de não-runtime (características de ecossistema/integração/documentação frequentemente têm seu centro aqui): Camada de Portal de Documentação (seções do site oficial, repositórios de exemplo, IA de documentação — owner é DevRel/Documentação/Site, não engenharia) e Camada de Infraestrutura de Build/Distribuição (empacotamento, CI multi-ambiente, ABI/pré-compilação — owner é Build SDK/DevOps). ⚠ Quando o artefato de entrega é exemplo/empacotamento/instalação/distribuição/documentação (protótipos H/I), mesmo que o toque técnico seja puramente SDK de segunda ordem, não atribua por padrão ao grupo SDK de segunda ordem — roteie de acordo com o grupo E da área de configuração para o owner correspondente (forçar para grupos de firmware/algoritmo/hardware, ou atribuir por padrão ao grupo SDK de segunda ordem, são atribuições erradas de alto risco). Se puder responder claramente "afeta apenas a camada SDK de segunda ordem, sem mudanças no portal/infraestrutura", anote "Característica de camada única (SDK de segunda ordem)" e vá diretamente para o Passo 5.
Determinar a camada de modificação mais baixa (gate rígido) + Falsificação de viabilidade: Encontre a camada mais baixa que precisa ser modificada. Assim que uma camada responder "não suporta/incerto", desça camada por camada na ordem SDK → Firmware → Algoritmos → Hardware até atingir o fundo (encontrar a camada que suporta ou determinar fisicamente inviável). Dê a conclusão de toque no fundo da camada (três opções): A Puramente SDK de segunda ordem pode entregar / B Pode entregar entre camadas / C A camada atual não pode entregar (camada inferior não agendada ou limitação física). Se a camada de modificação mais baixa não for a camada SDK de segunda ordem, esta característica não pode ser entregue de forma independente pela camada SDK de segunda ordem — marque em local visível no documento: ⚠ Não pode ser entregue de forma independente pela camada SDK de segunda ordem: a modificação mais baixa desta característica está em <camada>, precisa que o <departamento owner> entregue <capacidade> primeiro, para que a camada SDK de segunda ordem possa encapsular e escreva na seção "/Posicionamento da Capacidade" e no DoR. Ao atingir limitações de hardware/físicas, pare imediatamente de refinar as assinaturas de interface na camada SDK de segunda ordem — continuar escrevendo um rascunho de contrato impossível de implementar é uma causa frequente de rejeição na revisão.
Desenhar tabela de decomposição entre camadas + Ordenar dependências + Contrato de transferência entre camadas: Liste o que precisa ser mudado em cada camada, departamento owner, se bloqueia a camada superior; organize a cadeia de dependências de baixo para cima; para cada dependência entre camadas, fixe um contrato de transferência de "o que a camada inferior expõe para a camada superior" (incluindo a atribuição do direito de definição — para evitar que dois departamentos escrevam versões diferentes e não correspondam).
Identificar owner e itens pendentes entre departamentos (cada item deve vir com uma tríade de atribuição): Quais camadas "precisa ou não ser modificado / pode ou não suportar" são questões que você não pode julgar e precisa confirmar com o departamento correspondente (ex: "o firmware realmente suporta beamforming?"), liste como itens pendentes entre departamentos. O usuário desta skill (geralmente o lado do produto/SDK) não pode obter respostas reais das camadas inferiores na sessão, então não basta marcar [Pendente de Confirmação] e colocar em uma lista — cada item deve vir com uma tríade: owner de verificação (quem entra em contato com esse departamento) | até qual ponto de revisão precisa de resposta | suposição padrão/plano de contingência se não responder a tempo (mesmo paradigma de [Pendente de Confirmação] do tipo limite com "responsável + método + prazo"). Eles são frequentemente os pontos de bloqueio do caminho crítico de todo o requisito.
Conclusão B/C é obrigatória: Reescrever a narrativa principal com o artefato real entregável (para evitar o "falso pronto"): Assim que a conclusão de toque no fundo da camada for B ou C, deve-se reescrever a "/Definição em Uma Frase" e a história P1 para que descrevam apenas o artefato real entregável desta rodada (ex: "esta rodada entrega stub SDK + assinatura, a capacidade real de beamforming depende do firmware no Q4"), nunca escreva o P1 com a capacidade completa da solicitação original do cliente — caso contrário, o documento de pronto que a engenharia/cliente lê não corresponderá ao que realmente pode ser entregue, que é o falso pronto mais perigoso. Se a camada inferior "não suporta e não está agendada", forneça um plano de contingência/faseamento na seção "/Implementação entre Camadas e Cooperação entre Departamentos" (stub mock / nível limitado / simulação primeiro), não apenas deixe como pendente de confirmação.

Ponto de parada antecipada para conclusão C quando a camada SDK de segunda ordem não tem nenhum artefato entregável independente nesta rodada (incluindo stubs): Se a falsificação confirmar que esta característica é atualmente uma mudança de camada inferior/hardware, e o lado SDK de segunda ordem não tem nem sentido ter stubs, não continue com os Passos 5 e 6 de esclarecimento por dimensão (isso só produzirá um documento vazio cheio de [Pendente de Confirmação], desperdiçando orçamento de interação e violando a própria disciplina de escopo). Produza diretamente uma "Conclusão de Roteamento entre Camadas" simplificada: Conclusão de toque no fundo da camada + Tabela de decomposição entre camadas + Bloqueios entre camadas e caminho de escalação + Mensagem para o cliente, e marque explicitamente "Este requisito atualmente não é uma tarefa da camada SDK de segunda ordem, sugere-se transferir para para criar um item".

Forma de saída: Um recurso = um md (dividido por leitor-alvo). Independentemente de ser de camada única ou entre camadas, um recurso produz apenas um documento de especificação de recurso; o conteúdo entre camadas/departamentos não é dividido em vários arquivos, mas sim dentro deste mesmo md em seções por leitor-alvo (Produto/Revisão, SDK de segunda ordem, Firmware, Algoritmos, Hardware) e coloca no topo do documento um "/Guia de Leitura" listando "Leitor-alvo → Quais seções ler → Pelo que cada um é responsável", para facilitar o rastreamento em um único documento de especificação. O template de seções por leitor-alvo e o template do guia de leitura estão em references/cross-layer-routing.md "Nove".

Preencha a saída na seção do template de saída "/Implementação entre Camadas e Cooperação entre Departamentos".

A conclusão deste passo reescreverá a lista de perguntas a serem feitas nos Passos 5 e 6: Por exemplo, se o cliente quer uma interface de beamforming set_microphone_beam_angle, e este passo verificar que o firmware ainda não suporta beamforming, o Passo 5 deve primeiro esclarecer "você aceita cascatear para algoritmos/hardware, e o escopo desta rodada é apenas fazer um placeholder do SDK?" em vez de ir diretamente perguntar sobre a assinatura da interface.

Por que um passo separado, e colocado antes do posicionamento: Um requisito que "na verdade precisa modificar o firmware" se for tratado como uma característica comum de SDK de segunda ordem, produzirá um documento que "parece que a engenharia pode pegar, mas na verdade a camada inferior não tem essa capacidade" — este é o modo de falha mais perigoso. Colocar este passo antes é bloquear a "pseudo-característica de SDK de segunda ordem" antes do DoR.

Ainda segue as "/Regras de Esclarecimento Interativo": Na tabela de decomposição entre camadas, tudo que for owner, se uma camada precisa ser modificada, ou se a camada inferior já suporta, que forem inferidos, marque com [Pendente de Confirmação] e use como perguntas de esclarecimento para devolver ao usuário uma de cada vez (uma pergunta por vez, com candidatos), nunca coloque departamentos/owners/dependências inferidos como confirmados na tabela — este passo naturalmente induz a preencher a tabela de owners de uma vez, o que equivale a decidir pelo usuário "quem é o owner, qual camada precisa ser modificada".

Passo 5: Primeiro Esclarecimento — Posicionamento (Granularidade Grossa)

Use a "/Primeira Camada · Dimensões de Posicionamento" como lista de verificação, compare com o fragmento item por item, liste as dimensões não respondidas e pergunte uma a uma de acordo com as "/Regras de Esclarecimento Interativo". Esta camada determina a forma do recurso: o que é, a qual camada e domínio pertence, quais são os limites, qual o formato. Faça apenas uma pergunta de cada vez.

Divida as lacunas em dois tipos:

Lacunas Bloqueadoras: Sem preencher, não é possível continuar a classificação ou definir os limites (ex: qual é o papel atendido, qual é o comportamento principal).
Lacunas Não Bloqueadoras: Afetam a completude, mas não o tronco principal (ex: um código de erro periférico, a forma da documentação).

Passo 6: Segundo Esclarecimento — Detalhes Funcionais (Granularidade Fina)

Após o posicionamento claro, a forma do recurso é conhecida, mas a engenharia ainda não pode começar a implementar — porque ainda não sabe "como funciona exatamente". Esta camada usa a "/Segunda Camada · Dimensões de Detalhes Funcionais" para aprofundar as especificações de comportamento: como o fluxo normal funciona, quais estados existem, como lidar com exceções, o que fazer em cenários de borda, quais são os valores dos parâmetros.

As perguntas da segunda camada devem variar de acordo com o tipo de recurso: Recursos de navegação devem perguntar sobre o caminho e a lógica de chegada; recursos de percepção devem perguntar sobre falsos positivos e confiança; recursos de dados devem perguntar sobre schema e magnitude. A biblioteca de perguntas específicas por tipo está em references/detail-probes.md — primeiro determine a qual protótipo este recurso pertence e depois chame a lista de sondas correspondente.

Passo 7: Gerar Documento de Especificação do Recurso (incluindo gate de auto-verificação de princípios de produto)

Após preencher as lacunas bloqueadoras, passe primeiro pelo gate de auto-verificação de princípios de produto, depois produza de acordo com o "/Template de Saída".

Seleção do Template: Características pequenas de camada única puramente SDK de segunda ordem com poucas lacunas usam o Template Simplificado (ex: Definição em Uma Frase, Fonte e Contexto, Posicionamento da Capacidade, Limites do Escopo, História+MVP, Especificação de Comportamento, Contrato de Interface, Dependências, Avaliação de Impacto, Auto-Verificação de Princípios de Produto (conclusão em uma linha), Registro de Decisões, Itens Pendentes, pulando a seção de Implementação entre Camadas e Cooperação entre Departamentos e a maioria dos NFRs sob demanda); características que abrangem camadas de implementação ou são importantes usam o Template Completo. Ambos compartilham o mesmo conjunto de itens obrigatórios e DoR.

Obrigatório antes da saída: Gate de auto-verificação de princípios de produto. Pegue a seção D da configuração "/Princípios de Produto" (se não preenchido, use os 10 padrão internos de references/product-principles.md) e, para cada princípio, dê uma conclusão de três estados: ✓ Conforme / ⚠ Violado-com concessão / — Não se aplica. Regras de julgamento de três estados, lista comum de bandeiras vermelhas, prioridade de conflitos em references/product-principles.md. Qualquer ⚠ deve ter a concessão escrita claramente na seção "/Auto-Verificação de Princípios de Produto" e uma linha na seção "/Registro de Decisões-Chave" (fonte marcada como "Conflito com princípios de produto - concessão", indicando qual princípio); características leves com tudo ✓/— podem comprimir a auto-verificação em uma linha de conclusão, sem necessidade de preencher tabela vazia.

O gate não é a skill marcar como aprovado, mas sim transformar itens não conformes em perguntas de esclarecimento ou [Pendente de Confirmação] para o usuário. Qualquer coisa envolvendo concessão (sacrificar uma capacidade pela compatibilidade, cortar algo quando o orçamento estourar, adicionar uma porta de permissão para ações perigosas) deve seguir as "/Regras de Esclarecimento Interativo" — uma pergunta por vez, com candidatos, devolvendo ao usuário para decidir.

Requisitos Rígidos do DoR:

Qualquer princípio marcado como ⚠ sem a explicação de concessão correspondente + registro de decisão no documento → Não passa no DoR, não pode ser marcado como "Engenharia pode pegar / Aguardando Revisão".
Se a conclusão de toque no fundo da camada do Passo 4 for B/C, e a "/Definição em Uma Frase" ou P1 ainda prometer a capacidade completa não disponível na camada inferior → Não passa no DoR (deve primeiro reescrever como artefato real entregável conforme o subponto 5 do Passo 4).

Após passar pelo gate, gere o documento de acordo com o template selecionado, escrevendo no diretório de saída padrão feature-specs/<nome do recurso>/<nome do recurso>.md (não apenas colado na conversa; a localização está no "/Template de Saída"); lacunas não bloqueadoras ainda não resolvidas coloque na seção "/Itens Pendentes de Confirmação", marcando os campos afetados no corpo com [Pendente de Confirmação], nunca invente.

Por que duas camadas em dois passes: Fazer muitas perguntas em uma única sessão cansa (veja o limite total nas regras de esclarecimento). Sugere-se que após terminar a primeira camada (Passo 5), produza um rascunho de "posicionamento definido, comportamento a ser preenchido" e a segunda camada (Passo 6) como um passe de aprofundamento subsequente para completar a especificação de comportamento e atualizar para v1.0 em nível de engenharia. Cada camada respeita seu próprio limite total, sem competir entre si. Se o requisito for pequeno e com poucas lacunas, as duas camadas podem ser concluídas de uma vez.

Primeira Camada · Dimensões de Posicionamento (Granularidade Grossa)

Determine a "forma" do recurso. Compare com o fragmento item por item; o que faltar é o que precisa ser esclarecido. Dividido em dois grupos.

Grupo A · Natureza do Requisito (O quê / Por quê / Limites)

Papéis e Cenários: Quem usa? Em qual cenário é acionado? (Usuário final / Desenvolvedor integrador / Operações…)
Comportamento Principal: O que esta funcionalidade faz exatamente? Qual é a entrada e qual é o resultado?
Limites do Escopo: O que está incluído, o que está explicitamente excluído (este é o mais fácil de ignorar e o que mais previne a engenharia de extrapolar o escopo por conta própria).
Critério de Sucesso: Como saber se "está certo"? Quais métricas observáveis podem ser medidas?

Grupo B · Posicionamento de Engenharia do SDK

Nível de Capacidade: Em qual nível L1 / L2 / L3 se encaixa?
Posicionamento nos Cinco Domínios: A qual domínio de capacidade pertence? É entre domínios? Se for, quem será afetado?
Superfície de Impacto da Interface: Quais interfaces precisam ser adicionadas/modificadas? Impacta o limite do orçamento de API?
Dependências Subjacentes: Quais capacidades existentes são necessárias? Quais ainda não existem e precisam ser construídas primeiro?
Formato Aplicável: Simulação, robô real, ou ambos? Os critérios de aceitação podem ser diferentes para cada um.
Disponibilidade para Integradores: Qual nível de integrador é o alvo? A complexidade do encapsulamento/documentação varia conforme o nível.
Compatibilidade com Versões Anteriores: Isso quebrará os contratos de interface existentes? Precisa de versionamento ou caminho de migração? Se for considerado break, pergunte também sobre a faixa de integradores/versões afetados e o ciclo de depreciação aceitável, não apenas anote "se é break".
Impacto em Documentação e Certificação: Precisa de nova documentação para desenvolvedores? Entra no escopo da certificação do integrador?
Segurança e Permissões (incluindo modificações físicas): Para qual nível de integrador/papel esta capacidade é aberta? Envolve ações perigosas ou de alto privilégio? Existem dois tipos de risco de segurança, ambos devem ser perguntados obrigatoriamente uma vez, nunca liberados por padrão:
- Chamadas de Software Perigosas: Desbloquear limites de velocidade/torque, desativar parada de emergência, controle direto de chassis/articulações, ultrapassar barreiras de segurança → Perguntar "quem tem permissão para chamar, precisa de confirmação secundária/auditoria/porta de permissão?".
- Modificações Físicas Perigosas (características de hardware final/modificações, protótipo J): O cliente conecta hardware caseiro a um robô que se move e pode ferir → Perguntar sobre limites de carga/torque/alimentação e consequências de excedê-los, área proibida de modificação (quais interfaces, se alteradas, desativam parada de emergência/mecanismos de segurança), necessidade de recalibração de carga após modificação do final, nível de autorização/qualificação para modificação, garantia e limites de responsabilidade, isenção de responsabilidade e declaração de conformidade, escopo de divulgação de materiais (por nível de papel/portão). Dar um número errado de limite físico = segurança pessoal + responsabilidade legal.

Segunda Camada · Dimensões de Detalhes Funcionais (Granularidade Fina)

Determine "como funciona exatamente". Este é o ponto chave para tornar o requisito realmente em nível de engenharia — se cada um dos itens abaixo não for definido com precisão, a engenharia terá que decidir por conta própria ao implementar. Estas são dimensões gerais; consulte o tipo de recurso em references/detail-probes.md para perguntas específicas de cada tipo.

Fluxo Normal Passo a Passo: Divida o comportamento principal em etapas ordenadas, com entrada, saída e pré-condições de cada etapa.
Estados e Ciclo de Vida: Quais estados existem? Como a máquina de estados transita? Semântica de start / pause / resume / stop / cancel e quais operações são permitidas em cada estado.
Acionamento e Pré-condições: Sob quais condições pode ser iniciado? Pré-requisitos de sistema/recursos? Como lidar com acionamentos repetidos ou concorrentes?
Tratamento de Exceções e Falhas: Liste os possíveis pontos de falha em cada etapa e defina a ação de recuperação para cada um — repetir / degradar / abortar / reportar, e quem faz o tratamento e como o estado é finalizado.
Cenários de Borda e Extremos: Comportamento com entrada vazia, valores extremos, interrupção no meio, recursos insuficientes (bateria/poder computacional), mudanças súbitas nas condições externas.
Detalhes dos Parâmetros: Unidade, faixa de valores, valor padrão, validação de valor inválido para cada item configurável.
Restrições de Tempo e Desempenho: Tempo de resposta, limite de tempo limite (timeout), throughput, requisitos de tempo real.
Concorrência e Reentrância: Pode executar múltiplas instâncias em paralelo? O que acontece se o chamador chamar a mesma interface várias vezes?
Observabilidade: Quais consultas de estado, eventos/callbacks, logs ou métricas o chamador precisa para perceber o estado de funcionamento do recurso. A observabilidade tem duas camadas, ambas devem ser perguntadas — Orientada ao chamador (consulta de estado / callback de evento / log localizável, para servir o integrador na percepção do estado de funcionamento) e Orientada à operação da plataforma (quais métricas/eventos são usados para julgar a saúde, taxa de adoção, distribuição de falhas deste recurso após o lançamento, servindo para depuração e tomada de decisão), esta última é frequentemente esquecida.

Não é necessário perguntar todas as 9 até o fim. Julgue quais são críticas para este recurso (tratamento de exceção é quase sempre crítico para tarefas longas, detalhes de parâmetros podem ser leves para consultas puras), pergunte as críticas e deixe o resto com valor padrão razoável ou marque como [Pendente de Confirmação].

Três eixos ortogonais, use em combinação: As nove dimensões acima + os "protótipos de recurso A~J" de detail-probes são um eixo que corta por tipo de recurso (H = Integração de ecossistema/implementação de referência/documentação; I = Empacotamento/distribuição/instalação offline/implantação; J = Especificações de interface física de hardware final e materiais de modificação, o contrato externo são interfaces físicas mecânicas/elétricas); se um recurso precisa de decomposição entre camadas de implementação (afeta camadas além da SDK de segunda ordem, incluindo as duas camadas de não-runtime "Camada de Portal de Documentação / Camada de Infraestrutura de Build·Distribuição", bem como o eixo de dependência externa/fim de vida (EOL)) é o segundo eixo, veja Passo 4 e references/cross-layer-routing.md; quais Requisitos Não Funcionais (NFR) e Princípios de Produto precisam ser verificados são o terceiro eixo, veja references/product-principles.md. Eles não se substituem mutuamente; se aplicável, são combinados.

Regras de Esclarecimento Interativo

Este é o motor para transformar "simples" em "completo", siga estritamente:

Uma pergunta de cada vez. Após fazer uma, pare, aguarde a resposta do usuário, depois faça a próxima. Não despeje uma série de perguntas de uma vez.
Prioridade bloqueadora. Primeiro pergunte sobre lacunas bloqueadoras (papéis, comportamento principal, limites do escopo, atribuição de capacidade), depois sobre as não bloqueadoras.
Cada pergunta deve vir com "por que está sendo perguntada" e respostas candidatas. No formato: "Esta funcionalidade atende principalmente a qual tipo de papel? (Isso determina em qual camada deve ser encapsulada) A. Usuário final usando diretamente B. Desenvolvedor integrador usando para desenvolvimento secundário C. Teste interno". Dar respostas candidatas reduz significativamente o custo da resposta; o usuário também pode optar por "nenhuma das anteriores" e complementar.
Controle o total para evitar fadiga. Cada camada, em uma única sessão, tente não exceder 7~8 perguntas (cada uma das duas camadas conta separadamente, sem competir entre si). Se houver muitas lacunas, preencha primeiro as bloqueadoras e marque o restante como [Pendente de Confirmação], informando ao usuário "o restante vou marcar, você pode preencher depois". As perguntas de detalhes da segunda camada são particularmente propensas a exceder; escolha as críticas para este recurso para perguntar.
Após resposta, reafirme para confirmação. Após o usuário responder, reafirme seu entendimento em uma frase antes de continuar, para garantir que não houve desentendimento.
Nunca decida pelo usuário. Perguntas envolvendo concessão (fazer ou não um certo limite, qual formato usar, quem é o owner, qual camada precisa ser modificada) devem ser perguntadas, nunca assumidas por padrão. Marque explicitamente o que "ainda não foi confirmado" como [Pendente de Confirmação], em vez de preencher silenciosamente com um valor que parece razoável.

Escrita e Legibilidade (A saída deve cumprir)

Documentos de requisito são lidos por pessoas e precisam passar por revisão, não são apenas um acúmulo de pontos pensados. Antes da saída, verifique estes três pontos:

Fale a língua do povo, com lógica coerente. Frases fluidas, parágrafos com linha mestre, não acumule fragmentos "pensou e escreveu". Para o primeiro termo/abreviação que aparecer, ou explique em uma frase no local, ou coloque no "/Glossário" — não deixe o leitor preso em palavras desconhecidas. Melhor uma explicação extra em linguagem simples do que jargão.
Contexto geral + seções por papel + glossário, estrutura em três partes. Um documento = ① Contexto Geral (todos leem primeiro: o que é, por quê, para quem, o que entrega = "/Definição em Uma Frase" + "/Fonte e Contexto" + "/Glossário") + ② Seções por Papel ("/Guia de Leitura" divide as seções subsequentes por leitor-alvo, cada papel lê apenas sua parte, não deixe uma equipe se afogar em detalhes irrelevantes) + ③ "/Glossário" (termos explicados separadamente, para quem não entende).
Limite a forma de entrega externa, libere detalhes técnicos internos. O requisito fixa "o que é entregue externamente" — assinatura da interface, forma do produto, forma do artefato, plataforma/ambiente suportado, critério de aceitação; mas não especifique excessivamente "como implementar internamente" — qual biblioteca, qual arquitetura, qual ferramenta de empacotamento/compilação, deixe para a engenharia. Ao escrever cada linha, pergunte-se: "Isso é um contrato externo ou uma implementação interna?" Se for implementação interna, mude para "definido pela engenharia" ou rebaixe para "sugestão (não obrigatório)", não escreva o requisito como uma solução de design.
Linguagem simples é para facilitar o entendimento, não para ser vaga — o contrato externo deve ser rigoroso. Use linguagem simples no texto, mas tudo que envolve padrões de saída externa — definição de interface (assinatura/parâmetros/retorno/erro), formato de mensagens e dados, matriz de plataformas suportadas deve ser listada completamente célula por célula, forma do artefato, critério de aceitação — deve ser preciso, inequívoco e passível de verificação, dê a assinatura quando necessário, liste a matriz completamente quando necessário. Simples não significa frouxo no contrato. Ao dividir por papéis, concentre esses contratos rigorosos nas seções do tipo "contrato externo" para que a engenharia/testes possam implementar e verificar.

Template de Saída

Após preencher as lacunas bloqueadoras (e passar pelo gate de auto-verificação de princípios de produto do Passo 7), produza estritamente de acordo com este template. O template incorpora uma Definition of Ready (DoR) — apenas quando cada seção estiver preenchida (ou explicitamente marcada como [Pendente de Confirmação]), este requisito será considerado "engenharia pode pegar".

Convenções:

As seções não são mais numeradas rigidamente, referencie uniformemente pelo nome da seção, para evitar desalinhamento de numeração ao inserir seções.
Template Simplificado = o mesmo conjunto de seções, mas removendo "/Implementação entre Camadas e Cooperação entre Departamentos" e as dimensões de NFR sob demanda, para características pequenas de camada única puramente SDK de segunda ordem; Template Completo para características entre camadas ou importantes.
Nomes de interface/parâmetros seguem uniformemente: tudo em minúsculo com underscore (snake_case), palavras completas e precisas, proibir abreviações (ex: mic→microphone, cfg→config, num→count) e consistentes com interfaces existentes no mesmo domínio.
Um documento carrega apenas um recurso, e um recurso produz apenas um md; múltiplos recursos são documentados de forma independente (nunca misturados), mas um recurso, mesmo que entre camadas, não é dividido em vários arquivos — o conteúdo entre camadas/departamentos é dividido em seções por leitor-alvo dentro do mesmo md.
Localização da saída (diretório de saída padrão, deve ser seguido): A saída é escrita em arquivo (não apenas colada na conversa) — no diretório de saída feature-specs/<nome do recurso>/<nome do recurso>.md (relativo ao diretório de trabalho atual/raiz do repositório; raiz padrão é feature-specs/, a equipe pode alterar na área de configuração). Um recurso = um subdiretório (para facilitar a colocação de figuras/subprodutos desse recurso), nome do arquivo = nome do recurso. Vários recursos têm seus próprios subdiretórios independentes; recursos relacionados referenciam-se mutuamente com links relativos.
Características entre camadas (conclusão B/C): Adicione um "/Guia de Leitura (Por Leitor-Alvo)" no topo deste template e, na seção "/Implementação entre Camadas e Cooperação entre Departamentos", coloque o conteúdo de cada camada em seções com o cabeçalho 【Leitor-Alvo: Grupo X】 (template em references/cross-layer-routing.md "Nove") — tudo dentro deste mesmo md, sem dividir em arquivos.

# Especificação do Recurso: [Nome do Recurso]

> Status: Rascunho / Aguardando Revisão / Confirmado ｜ Solicitante: [Cliente/Parceiro] ｜ Data: AAAA-MM-DD ｜ Template: Completo / Simplificado

## Guia de Leitura (Por Leitor-Alvo)
> **Como ler:** Primeiro leia o **Contexto Geral** ("/Definição em Uma Frase", "/Fonte e Contexto", "/Glossário", todos leem); as demais seções siga a tabela abaixo **cada um lê a sua parte**, sem necessidade de ler o documento inteiro. Características entre camadas/departamentos devem preencher esta tabela; para características pequenas de camada única, a tabela pode ser simplificada, mas o contexto geral e o "/Glossário" ainda são necessários.
| Leitor-Alvo | Quais seções ler prioritariamente | Pelo que você é responsável |
| --- | --- | --- |
| Produto / Revisão | Definição em uma frase, Fonte e contexto, Posicionamento da capacidade, Limites do escopo, História+verificação, Avaliação de impacto, Auto-verificação de princípios de produto, Registro de decisões, Itens pendentes | Confirmar escopo/prioridade/concessões |
| Grupo SDK de segunda ordem | Contrato de interface, Especificação de comportamento, "/Implementação entre Camadas e Cooperação entre Departamentos" · Seção SDK de segunda ordem | Encapsulamento externo e contrato de interface |
| Grupo Firmware | "/Implementação entre Camadas e Cooperação entre Departamentos" · Seção Firmware, Contrato de transferência entre camadas | Confirmar/disponibilizar interface de capacidade da camada inferior |
| Grupo Algoritmo | "/Implementação entre Camadas e Cooperação entre Departamentos" · Seção Algoritmo | Disponibilidade/adaptação da capacidade de algoritmo |
| Grupo Hardware | "/Implementação entre Camadas e Cooperação entre Departamentos" · Seção Hardware | Forma de hardware/limites físicos |
| Teste / QA | Critérios de aceitação, Contratos externos (interface/mensagem/matriz de plataformas), Itens pendentes | Projetar testes de acordo com os critérios de aceitação e contratos, cobrir toda a matriz de plataformas |
(Papeis **selecionados conforme o tipo de recurso**: Runtime = cada camada de implementação; Entrega/Integração/Instalação = Empacotamento·DevOps / Documentação / Testes, etc. **Teste/QA sempre incluído como um papel** — ele se preocupa com como o teste é feito, quais plataformas cobrir, se os contratos externos são testáveis. Linhas de papeis não envolvidos podem ser removidas. **O corpo do documento deve, sempre que possível, ser dividido por papel**, para que cada papel possa ler sua parte de forma contínua.)

## Definição em Uma Frase
[O quê — o que este recurso faz, em uma frase clara. ⚠ Se a conclusão de toque no fundo da camada do Passo 4 for B/C, escreva aqui apenas o artefato real entregável desta rodada, não a capacidade completa não disponível na camada inferior]

## Fonte e Contexto (Por quê)
- Solicitação Original: [A frase original do cliente/parceiro, mantendo o sentido original]
- Cenário de Negócio: [Quem, em qual cenário, quer resolver qual problema]
- Valor: [Por que vale a pena fazer]

## Glossário (Termos)
> Termos/abreviações que aparecerão no documento e que leitores não familiarizados com o domínio podem não entender, explique cada um em uma frase simples (para diferentes papeis, não presuma que todos entendem); se não houver termos, escreva "Nenhum".
| Termo | Explicação em uma frase |
| --- | --- |
| … | … |

## Posicionamento da Capacidade
- Nível: L1 / L2 / L3　[Se o grupo A da configuração não estiver preenchido, marque [Pendente de Confirmação]; **se for uma característica de não-runtime do tipo entrega/distribuição/instalação/documentação, marque `N/A (não é uma característica de capacidade, apenas no eixo da camada de implementação)`**]
- Domínio de Capacidade: [Um dos cinco domínios, ou "Entre Domínios: X + Y", ou N/A]
- Impacto entre Domínios: [Quais outros domínios/equipes serão afetados]
- Conclusão entre Camadas (Passo 4): Característica de camada única (SDK de segunda ordem) / ⚠ Não pode ser entregue de forma independente pela camada SDK de segunda ordem: a modificação mais baixa está em <camada>, precisa que <departamento> entregue <capacidade> primeiro, para que a camada SDK de segunda ordem possa encapsular

## Limites do Escopo
- Incluído (In Scope):
  - …
- Explicitamente Não Incluído (Out of Scope):   ← Obrigatório, para evitar que a engenharia extrapole o escopo
  - …
- Placeholder de Recurso Relacionado (da divisão de demanda, não feito nesta rodada):
  - …

## Implementação entre Camadas e Cooperação entre Departamentos
> Obrigatório apenas quando o Passo 4 determinar que esta característica abrange camadas de implementação (afeta camadas além da camada SDK de segunda ordem); para características de camada única puramente SDK de segunda ordem, escreva "Característica de camada única (SDK de segunda ordem), sem cooperação entre camadas" e pule esta seção (o template simplificado não contém esta seção).
> **Forma de saída:** Um recurso produz apenas um md; esta seção contém o conteúdo de cada camada, dividido em seções com o cabeçalho `【Leitor-Alvo: X】`.

【Leitor-Alvo: Todos】
**Conclusão de Toque no Fundo da Camada:** [A / B / C]
**Dependências:** [Relação de dependência entre camadas, ex: A camada de firmware deve ser concluída antes da camada SDK de segunda ordem]
**Contrato de Transferência:**
| Camada Fornecedora | Camada Receptora | Interface/Capacidade Fornecida | Direito de Definição |
| --- | --- | --- | --- |
| <camada inferior> | <camada superior> | <o que é exposto> | <qual documento/repositório possui a definição> |

【Leitor-Alvo: Grupo SDK de segunda ordem】
[Mudanças necessárias nesta camada, assinaturas de interface, etc.]

【Leitor-Alvo: Grupo Firmware】
[Mudanças necessárias nesta camada, interfaces de capacidade, etc.]

【Leitor-Alvo: Grupo Algoritmo】
[Mudanças necessárias nesta camada, etc.]

【Leitor-Alvo: Grupo Hardware】
[Mudanças necessárias nesta camada, limites físicos, etc.]

【Leitor-Alvo: Teste / QA】
[Considerações de teste para esta camada, pontos de verificação específicos, etc.]

## Especificação de Comportamento
### Fluxo Normal Passo a Passo
1. … (Entrada: …, Pré-condição: …, Resultado: …)
2. …

### Estados e Ciclo de Vida
[Diagrama de estados ou descrição da máquina de estados; semântica de iniciar/pausar/retomar/parar/cancelar]

### Acionamento e Pré-condições
[Condições para iniciar, pré-requisitos, tratamento de repetição/concorrência]

### Tratamento de Exceções e Falhas
| Ponto de Falha | Ação de Recuperação | Quem Trata | Estado Final |
| --- | --- | --- | --- |
| … | … | … | … |

### Cenários de Borda e Extremos
- …

### Detalhes dos Parâmetros
| Parâmetro | Unidade | Faixa | Padrão | Validação de Inválido |
| --- | --- | --- | --- | --- |
| … | … | … | … | … |

### Restrições de Tempo e Desempenho
- …

### Concorrência e Reentrância
- …

### Observabilidade
- **Orientada ao Chamador (Integrador):** [Eventos/callbacks/consultas de estado/logs]
- **Orientada à Operação da Plataforma:** [Métricas/eventos para monitoramento pós-lançamento]

## Contrato de Interface
### Interfaces Novas

<ex: bool set_beam_angle(int32_t angle_ms); …>

### Interfaces Modificadas

…

### Formato de Mensagens / Dados (se aplicável)
- [Definição de estruturas de dados, formatos de serialização, etc.]

## Dependências
- [Capacidades existentes necessárias]
- [Capacidades que precisam ser construídas primeiro]

## Avaliação de Impacto, Compatibilidade e Estratégia de Lançamento
- **Compatibilidade com Versões Anteriores:** [Sim/Não e ações necessárias]
- **Impacto em Documentação:** [Novos documentos necessários]
- **Impacto em Certificação:** [Afeta a certificação do integrador?]
- **Segurança e Permissões:** [Nível de acesso necessário, riscos de segurança]
- **Matriz de Plataformas Suportadas:** [Listar todas as plataformas e se há diferenças]
- **Gates de Entrega (se aplicável, com config org-process):** [Quais revisões/aprovações são necessárias]
- **Estimativa de Esforço (se aplicável):** [Dias-homem, capacidade do pipeline]

## Auto-Verificação de Princípios de Produto
> Conclusão do gate: ✓ Conforme / ⚠ Violado-com concessão / — Não se aplica. Se ⚠, explique a concessão e referencie a decisão no registro.
| Princípio | Conclusão | Concessão (se aplicável) |
| --- | --- | --- |
| … | … | … |

## Registro de Decisões-Chave
| Decisão | Data | Alternativas Consideradas | Raciocínio | Fonte |
| --- | --- | --- | --- | --- |
| … | … | … | … | … |

## Itens Pendentes de Confirmação
| Item | Tipo | Owner de Verificação | Prazo | Suposição Padrão / Plano de Contingência |
| --- | --- | --- | --- | --- |
| … | … | … | … | … |

Apêndice: Referências

Esta skill depende dos seguintes arquivos de referência, que devem existir no mesmo diretório:

references/cross-layer-routing.md — guia de decomposição entre camadas, tabela de julgamento, template de contrato de transferência
references/detail-probes.md — biblioteca de perguntas de detalhe por protótipo de recurso (A~J)
references/product-principles.md — princípios de produto padrão internos (10 itens), regras de julgamento de três estados do gate, lista de bandeiras vermelhas comuns, prioridade de conflitos
references/org-process-config.md — template de configuração para colaboração em nível de empresa (mapa de papéis, gates de entrega, ritmo de versão, etc.)
scripts/init-org-config.sh — script para gerar configuração local org-process.local.md

Auromix/feature-spec-builder

O que é feature-spec-builder?

Perguntar na sua IA favorita

Documentação