Referência
Catálogo de prompts
Todo prompt que a toolchain envia, o que ele pede e como cada um degrada quando a resposta é inutilizável.
Todo ponto de contato com LLM na toolchain. Todas as chamadas que produzem JSON rodam a
temperatura 0 (descartada automaticamente para modelos de raciocínio). A narração em chinês
(--narrate-lang zh) mantém em inglês as chaves JSON, os valores de enum, os ids e os
caminhos de arquivo; só os valores em prosa mudam.
| # | Prompt (módulo) | Fase | Propósito | Contrato de saída |
|---|---|---|---|---|
| 1 | regras de ficha brief (pipeline/cards.ts) | 2a | propósito em linguagem simples de 1–2 frases + enum de role + dica de lifecycle por arquivo do lote | {"purposes":[{file,purpose,role,lifecycle}]} |
| 2 | regras de ficha deep (pipeline/cards.ts) | 2a | passo a passo do arquivo inteiro (120–300 palavras) + purpose / data_flow / relations por função, chaveados pelo qualname exato; fatos do grafo declarados como autoritativos | adiciona description, functions[] |
| 3 | fallback por bloco (pipeline/cards.ts) | 2a | as mesmas regras do modo deep sobre um bloco de função de um arquivo grande demais | uma entrada purposes cobrindo o bloco |
| 4 | síntese do esqueleto (pipeline/skeleton.ts) | 2b | espinha narrativa ordenada a partir dos agregados por diretório + pontos de entrada; ordem de ciclo de vida obrigatória; transversais depois do fluxo principal | {"metadata":{archetype},"stages":[{id,title,description,parent,crosscut}]} |
| 5 | atribuição de arquivos (pipeline/assign.ts) | 2b | uma etapa primária por arquivo, a partir de um menu fixo; also 0–2; escape unassigned para código vendorizado/morto | {"assignments":[{file,stage,also}]} |
| 6 | ator do doctor (pipeline/doctor.ts) | 2b | ≤3 mudanças estruturais (add_stage / remove_stage / merge_stages / split_stage), priorizadas: sem atribuição → sobrecarga → escassez → morto | {"changes":[…],"rationale"} |
| 7 | papéis do crítico (llm/critic.ts) | 2b | revisão em papéis (engenheiro / arquiteto / leitor / editor) de uma proposta contra evidências de referência; APPROVE com generosidade, REJECT apenas quando não há conserto | {"decision","concerns","suggested_revision","rationale"} |
| 8 | prompt de revisão (llm/critic.ts) | 2b | revisão do ator respondendo aos itens [role] concern agregados | o mesmo schema da proposta original |
| 9 | organização da etapa (pipeline/organize.ts) | 2c | 2–8 subgrupos ordenados por etapa; cada arquivo exatamente uma vez; ordem narrativa respeitando as dicas de chamada | {"groups":[{title,summary,files}]} |
| 10 | classificação de membros (pipeline/member.ts) | 2b (member) | atribui funções/métodos individuais às etapas escritas pelo usuário | {"assignments":[{member,stage}]} |
| 11 | agregação da etapa (pipeline/narrate.ts) | 3 | visão geral da etapa para não especialistas, de 100–200 palavras, a partir das visões gerais filhas + resumos de uma linha dos arquivos | apenas prosa simples (sem JSON, sem cabeçalhos) |
| 12 | agregação do sistema (pipeline/narrate.ts) | 3 | visão geral do sistema de 200–350 palavras costurando as etapas de nível superior | apenas prosa simples |
| 13 | extração de registradores (pipeline/narrate.ts) | 3 rodada 1 | registradores de estado entre etapas (id + semântica de uma linha + etapas tocadas) a partir das visões gerais das etapas + fichas data_model | {"registers":[{id,semantics,stages}]} |
| 14 | passada de lacunas de registradores (pipeline/narrate.ts) | 3 rodadas 2+ | APENAS os registradores faltantes, dada a lista dos já encontrados; array vazio quando não há nada (o laço para após 2 rodadas vazias) | o mesmo schema, apenas entradas novas |
| 15 | prompt de sistema do planner (planner/prompt.ts) | plan | roteia com o handbook → lê o código-fonte real → emite blocos EDIT byte-exatos + JSON de declarações; regras de o-executor-confia-cegamente (unicidade, sem sobreposição, menor extensão) | plano em markdown terminando em um bloco {"will_modify","will_add","will_remove"} |
| 16 | protocolo de ferramentas do planner (planner/prompt.ts) | plan | uma ação JSON por turno: list_dir / read_file / grep / finish | bloco de ação {"tool": …} |
| 17 | rótulo de evolução do resync (studio/server.ts) | studio resync | uma frase de ≤40 caracteres nomeando QUAIS capacidades/módulos uma mudança tocou, a partir dos propósitos dos arquivos tocados; adivinhar a intenção é proibido (o resync do studio não tem diff); degrada para uma lista determinística de arquivos sem um cliente | prosa simples, uma linha (renderizada esmaecida + marcada com auto) |
Regras de projeto que os prompts compartilham
- Os fatos são injetados, nunca solicitados. Inventários de funções, faixas de linhas e relações de chamada vêm do grafo e são marcados como verdade de referência; o modelo escreve prosa em torno deles e é instruído a não relistá-los.
- Os menus são fechados. Os prompts de atribuição e de classificação enumeram os ids de
etapa válidos e instruem "nunca invente"; qualquer coisa fora do menu é coagida para
unassignedno parse, de modo que a deriva do prompt não pode corromper artefatos. - Todo contrato JSON tem um validador mecânico do lado consumidor (zod ou verificações escritas à mão); entradas descartadas ou malformadas são preenchidas deterministicamente e contabilizadas nos artefatos de cobertura, em vez de remendadas em silêncio.
- Finais só-JSON / só-prosa mantêm o parse sem ambiguidade; o extrator de JSON tolera blocos cercados e varreduras por chaves balanceadas, mas os prompts ainda pedem um único bloco cercado.
- Os prompts de crítico resistem à aprovação automática nos dois sentidos: aprovam propostas corretas o bastante (nada de REVISE vazio — esses são normalizados para APPROVE), mas uma chamada de crítico quebrada conta como REJECT, para que falhas de infraestrutura nunca aprovem mudanças.