catalog-project

catalog-project

Objetivo: criar ou atualizar .project-memory/manifest.yaml no repo consumidor com stack, capacidades, integrações e narrativa de produto rastreáveis a evidência.

Fluxo:

• rodar dentro do repo consumidor (raiz do produto, não do kit)
• se docs/repo-audit/current.md não existir ou estiver desatualizado → disparar Repo Auditor primeiro
• se _detective_sdd/00-overview.md não existir → disparar Detective Spec primeiro (ou usar o que já existir)
• procurar conteúdo de produto no repo consumidor de forma exaustiva, não superficial — o objetivo é que quem ler a seção product do manifest tenha tudo que precisa pra escrever um post/anúncio externo sem re-perguntar a uma IA "o que esse sistema faz": README.md inteiro (não só o primeiro parágrafo), docs/pricing*, docs/landing*, páginas de marketing/landing dentro de app//src/ (seção hero, FAQ, tabela de planos), CHANGELOG.md para funcionalidades recentes, e também _detective_sdd/00-overview.md/02-business-rules/ já gerados neste mesmo fluxo — usar o que existir, nunca inventar
  • product.summary: o que o produto É (1-2 frases)
  • product.problemSolved: que dor/problema ele resolve pro usuário — distinto do summary, foca na motivação de uso, não na descrição funcional
  • product.features: lista EXAUSTIVA de funcionalidades voltadas a usuário (não técnicas) — varrer README completo + CHANGELOG + _detective_sdd/00-overview.md, não parar nas primeiras 3-4 óbvias
  • product.monetization: como o produto ganha dinheiro em linguagem simples — ex. "freemium com upgrade pago", "100% gratuito, sem monetização", "paga por uso via créditos consumíveis". Derivar da presença/ausência real de billing (docs/repo-audit/current.md, capabilities de billing) cruzado com o que o README/pricing diz
  • product.plans: TODOS os planos encontrados, com preço e a lista completa de limites/features de cada um — não resumir "vários planos", listar cada um
• procurar histórico de sessões em docs/context/session-*.md do repo consumidor (formato gerado por 31-session-summary) — se existirem, sintetizar cada arquivo numa entrada de sessions: (ver schema abaixo); se não existir nenhum, omitir a seção inteira (nunca inventar sessão)
• procurar dados operacionais no repo consumidor: .env, .env.example, .env.production (para envVars), docker-compose.yml/vercel.json/README.md/DEPLOY.md (para addresses de produção — domínio, URL da API, dashboard), e qualquer doc com métricas já coletadas (ex. docs/metrics.md, seção de analytics no README) — sintetizar em operations: (ver schema abaixo)
  • AVISO DE SEGURANÇA — decisão explícita do usuário, não default do kit: operations.envVars[].value grava o VALOR REAL de cada variável, incluindo secrets (API keys, senhas de banco, tokens), lido diretamente do .env do repo consumidor. Isso deixa credenciais em texto puro dentro de manifest.yaml, versionado no git do repo consumidor, e visível a qualquer agente de IA que consultar o project-brain (UI ou MCP). Só prossiga com valores reais se o usuário já confirmou esse tradeoff nesta conversa — se não tiver certeza, pare e confirme antes de ler qualquer .env. Se o usuário preferir a opção segura, grave só name (sem value) por variável, extraído de .env.example
  • antes de gravar qualquer valor real de env var: rodar git remote -v no repo consumidor. Se houver QUALQUER remote configurado (GitHub, GitLab, servidor próprio, não importa se privado ou público) — avisar o usuário explicitamente ("este repo tem remote configurado: <url>; secrets gravados no manifest vão junto no próximo push, mesmo que o repo seja privado hoje") e aguardar confirmação antes de prosseguir com valores reais. Sem remote (git remote -v vazio) → repo é só local, pode prosseguir sem essa pausa adicional (mas o aviso do item acima ainda vale)
• procurar instrumentação de tracking/analytics no repo consumidor: docs/tracking*, TRACKING_PLAN.md, arquivos de eventos (ex. lib/analytics/*, */events.ts), e chamadas reais no código (gtag(...), window.gtag, SDK do GA4/Google Ads/Meta Pixel, analytics.track(...)) — sintetizar em analytics: (ver schema abaixo). Cada evento listado precisa apontar pra onde foi encontrado (source: <file:line ou doc>); nunca inventar nome de evento ou funil que não esteja no código/doc. Se o repo não tem nenhuma chamada de tracking nem doc de plano, omitir a seção inteira
• sintetizar tudo em .project-memory/manifest.yaml seguindo o schema: