@gabrihhh/jarvis 2.2.2 → 2.3.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/.claude/skills/MEMORY_ARCHITECTURE.md +172 -0
- package/.claude/skills/configure-memory/SKILL.md +184 -0
- package/.claude/skills/create-memory/SKILL.md +125 -0
- package/.claude/skills/setup-memory/SKILL.md +1 -1
- package/.claude/skills/update-memory/SKILL.md +151 -0
- package/README.md +16 -3
- package/bin/jarvis.js +8 -2
- package/package.json +1 -1
- package/src/memory/mcp-server.js +2 -2
- package/.claude/skills/memory-index/SKILL.md +0 -168
|
@@ -0,0 +1,172 @@
|
|
|
1
|
+
# Memory Architecture — Contrato do Grafo de Memória Semântica
|
|
2
|
+
|
|
3
|
+
Este documento é a fonte de verdade para as skills `/create-memory` e `/update-memory`.
|
|
4
|
+
Toda decisão de indexação deve seguir as regras aqui definidas.
|
|
5
|
+
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
## 1. Schema do Grafo
|
|
9
|
+
|
|
10
|
+
### Nodes
|
|
11
|
+
|
|
12
|
+
| Node | Propriedades | Unicidade |
|
|
13
|
+
|---|---|---|
|
|
14
|
+
| `Project` | name, path, description, language, branch, createdAt | (name, branch) |
|
|
15
|
+
| `Module` | name, path, domain, projectName, branch | (path, projectName, branch) |
|
|
16
|
+
| `File` | path, name, extension, purpose, projectName, branch | (path, projectName, branch) |
|
|
17
|
+
| `Concept` | name, projectName | (name, projectName) |
|
|
18
|
+
| `Pattern` | name, description | name — **global, compartilhado entre projetos** |
|
|
19
|
+
| `Dependency` | name, version, type, projectName, branch | (name, projectName, branch) |
|
|
20
|
+
|
|
21
|
+
### Relationships
|
|
22
|
+
|
|
23
|
+
```
|
|
24
|
+
Project -[:HAS_MODULE]-> Module
|
|
25
|
+
Module -[:CONTAINS]-> File
|
|
26
|
+
Module -[:HANDLES]-> Concept
|
|
27
|
+
Module -[:IMPLEMENTS]-> Pattern
|
|
28
|
+
Module -[:DEPENDS_ON]-> Module
|
|
29
|
+
Project -[:USES_PATTERN]-> Pattern
|
|
30
|
+
```
|
|
31
|
+
|
|
32
|
+
### Notas do schema
|
|
33
|
+
|
|
34
|
+
- `Pattern` é o único nó global — o mesmo padrão pode ser compartilhado entre projetos
|
|
35
|
+
- `Concept` é sempre vinculado ao projeto — "pedido" no projeto A ≠ "pedido" no projeto B
|
|
36
|
+
- `Dependency` registra apenas dependências diretas (package.json, go.mod, etc.), nunca transitivas
|
|
37
|
+
|
|
38
|
+
---
|
|
39
|
+
|
|
40
|
+
## 2. Regras de Indexação
|
|
41
|
+
|
|
42
|
+
### O que É um módulo
|
|
43
|
+
|
|
44
|
+
- Um diretório com **responsabilidade coesa e identificável**
|
|
45
|
+
- Exemplos: `src/auth`, `src/memory`, `.claude/skills`, `bin`
|
|
46
|
+
- Profundidade máxima: 2 níveis a partir da raiz do projeto (ex: `src/memory` é válido, `src/memory/adapters/neo4j` não)
|
|
47
|
+
- Diretórios "standalone" com um único arquivo importante podem ser tratados como módulo
|
|
48
|
+
|
|
49
|
+
### O que NÃO é um módulo
|
|
50
|
+
|
|
51
|
+
- `node_modules/`, `.git/`, `dist/`, `build/`, `.next/`, `__pycache__/`
|
|
52
|
+
- Diretórios de configuração trivial (`.husky/`, `.vscode/`)
|
|
53
|
+
- Diretórios gerados automaticamente
|
|
54
|
+
|
|
55
|
+
### O que É um arquivo indexável
|
|
56
|
+
|
|
57
|
+
- Arquivos com lógica de negócio: `.js`, `.ts`, `.py`, `.go`, `.php`, `.java`, `.rb`, `.rs`
|
|
58
|
+
- Entry points, services, controllers, handlers, routers, models
|
|
59
|
+
- Arquivos de skill/automação (`.md` de skills)
|
|
60
|
+
|
|
61
|
+
### O que NÃO indexar como arquivo
|
|
62
|
+
|
|
63
|
+
- Lock files (`package-lock.json`, `yarn.lock`, `*.lock`)
|
|
64
|
+
- Arquivos minificados ou gerados
|
|
65
|
+
- Arquivos de configuração sem lógica (`tsconfig.json`, `.eslintrc`)
|
|
66
|
+
- Binários
|
|
67
|
+
|
|
68
|
+
### Conceitos: domínio, não técnica
|
|
69
|
+
|
|
70
|
+
- **Certo:** `autenticação`, `sessão`, `pedido`, `faturamento`, `status bar`, `injeção de contexto`
|
|
71
|
+
- **Errado:** `string`, `array`, `request`, `handler`, `utils`
|
|
72
|
+
- Conceitos em português quando o domínio é brasileiro, inglês quando o projeto é internacional
|
|
73
|
+
|
|
74
|
+
### Padrões: nomes canônicos
|
|
75
|
+
|
|
76
|
+
- Usar nomes reconhecíveis: `Repository Pattern`, `MCP Protocol`, `Command Pattern`, `Pipeline`, `Single Responsibility`, `Observer`, `Factory`, `Middleware`
|
|
77
|
+
- Nunca inventar nomes de padrões
|
|
78
|
+
|
|
79
|
+
### Granularidade do domain (Module.domain)
|
|
80
|
+
|
|
81
|
+
- Frase curta e descritiva: `"Autenticação de usuários"`, `"Grafo de memória semântica"`, `"Dashboard de uso do terminal"`
|
|
82
|
+
- Nunca genérico: `"Utilitários"`, `"Helpers"`, `"Misc"`
|
|
83
|
+
|
|
84
|
+
---
|
|
85
|
+
|
|
86
|
+
## 3. Fluxo de Criação (`/create-memory`)
|
|
87
|
+
|
|
88
|
+
Usado quando o projeto **não existe** no grafo ou se deseja reindexar do zero.
|
|
89
|
+
|
|
90
|
+
```
|
|
91
|
+
Passo 0 → Selecionar branch (main ou qa)
|
|
92
|
+
Passo 1 → Descoberta inicial (manifesto, estrutura, dependências)
|
|
93
|
+
Passo 2 → Análise profunda por módulo (arquivos, padrões, conceitos, deps)
|
|
94
|
+
Passo 3 → Montagem do mapa completo (sem salvar ainda)
|
|
95
|
+
Passo 4 → Apresentação ao usuário para aprovação e correção
|
|
96
|
+
Passo 5 → Gravação via save-project após "pode salvar"
|
|
97
|
+
```
|
|
98
|
+
|
|
99
|
+
**Regra:** nunca salvar sem aprovação explícita.
|
|
100
|
+
|
|
101
|
+
---
|
|
102
|
+
|
|
103
|
+
## 4. Fluxo de Atualização (`/update-memory`)
|
|
104
|
+
|
|
105
|
+
Usado quando o projeto **já existe** no grafo e houve mudanças no repositório.
|
|
106
|
+
|
|
107
|
+
```
|
|
108
|
+
Passo 0 → Consultar grafo atual (query-project)
|
|
109
|
+
Passo 1 → Detectar mudanças via git (git log + git diff)
|
|
110
|
+
Passo 2 → Calcular delta (novo, modificado, removido)
|
|
111
|
+
Passo 3 → Re-analisar apenas módulos afetados
|
|
112
|
+
Passo 4 → Apresentar delta ao usuário (antes vs. depois)
|
|
113
|
+
Passo 5 → Aplicar merge via save-project após aprovação
|
|
114
|
+
```
|
|
115
|
+
|
|
116
|
+
**Comportamento do save-project:** usa `MERGE` — adiciona e atualiza, nunca deleta.
|
|
117
|
+
**Limitação v1:** módulos removidos do código permanecem como nós órfãos no grafo.
|
|
118
|
+
Módulos removidos devem ser sinalizados ao usuário no Passo 4 com um aviso explícito.
|
|
119
|
+
|
|
120
|
+
---
|
|
121
|
+
|
|
122
|
+
## 5. Critérios de Qualidade
|
|
123
|
+
|
|
124
|
+
### Grafo saudável
|
|
125
|
+
|
|
126
|
+
- Cada módulo tem `domain` específico e não genérico
|
|
127
|
+
- Conceitos refletem o vocabulário do produto/negócio
|
|
128
|
+
- Relações `DEPENDS_ON` são reais e verificadas no código
|
|
129
|
+
- Patterns são nomes canônicos da literatura
|
|
130
|
+
|
|
131
|
+
### Sinais de grafo poluído
|
|
132
|
+
|
|
133
|
+
- Módulos com `domain: "utilitários"` ou `"misc"`
|
|
134
|
+
- Conceitos técnicos: `"json"`, `"http"`, `"string"`
|
|
135
|
+
- Arquivos de config indexados como arquivos relevantes
|
|
136
|
+
- Mais de 15 arquivos por módulo sem subdivisão
|
|
137
|
+
- Módulos sem nenhum conceito associado
|
|
138
|
+
|
|
139
|
+
---
|
|
140
|
+
|
|
141
|
+
## 6. Objeto canônico para save-project
|
|
142
|
+
|
|
143
|
+
```json
|
|
144
|
+
{
|
|
145
|
+
"project": {
|
|
146
|
+
"name": "<nome do repositório>",
|
|
147
|
+
"path": "<path absoluto>",
|
|
148
|
+
"description": "<uma linha descrevendo o que o projeto faz>",
|
|
149
|
+
"language": "<linguagem principal>",
|
|
150
|
+
"branch": "main | qa"
|
|
151
|
+
},
|
|
152
|
+
"modules": [
|
|
153
|
+
{
|
|
154
|
+
"name": "<nome do diretório ou nome semântico>",
|
|
155
|
+
"path": "<path relativo ao root>",
|
|
156
|
+
"domain": "<responsabilidade em frase curta>",
|
|
157
|
+
"files": [
|
|
158
|
+
{ "path": "<path relativo>", "purpose": "<o que este arquivo faz>" }
|
|
159
|
+
],
|
|
160
|
+
"patterns": ["Repository Pattern", "MCP Protocol"],
|
|
161
|
+
"concepts": ["autenticação", "sessão"],
|
|
162
|
+
"dependsOn": ["<nome de outro módulo deste projeto>"]
|
|
163
|
+
}
|
|
164
|
+
],
|
|
165
|
+
"dependencies": [
|
|
166
|
+
{ "name": "<pacote>", "version": "<versão>", "type": "external | internal" }
|
|
167
|
+
],
|
|
168
|
+
"patterns": [
|
|
169
|
+
{ "name": "<nome canônico>", "description": "<descrição do padrão>" }
|
|
170
|
+
]
|
|
171
|
+
}
|
|
172
|
+
```
|
|
@@ -0,0 +1,184 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: configure-memory
|
|
3
|
+
description: Configurar a arquitetura do grafo de memória semântica — personaliza o schema, regras e fluxos usados pelo /create-memory e /update-memory
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# /configure-memory — Configurar Arquitetura de Memória
|
|
7
|
+
|
|
8
|
+
Você vai guiar o usuário para criar ou modificar a arquitetura do grafo de memória semântica.
|
|
9
|
+
O resultado será salvo em `~/.claude/skills/MEMORY_ARCHITECTURE.md`, substituindo o padrão e sendo usado pelo `/create-memory` e `/update-memory`.
|
|
10
|
+
|
|
11
|
+
## REGRA GLOBAL
|
|
12
|
+
|
|
13
|
+
- Nunca salvar sem aprovação explícita do usuário
|
|
14
|
+
- Se qualquer intenção do usuário for ambígua, pergunte antes de continuar
|
|
15
|
+
- Ao final, sempre mostrar o arquivo completo gerado antes de salvar
|
|
16
|
+
|
|
17
|
+
---
|
|
18
|
+
|
|
19
|
+
## Passo 0 — Ler arquitetura atual
|
|
20
|
+
|
|
21
|
+
Leia o arquivo `~/.claude/skills/MEMORY_ARCHITECTURE.md`.
|
|
22
|
+
|
|
23
|
+
Se não existir, informe: "Nenhuma arquitetura customizada encontrada. Usarei a arquitetura padrão como base."
|
|
24
|
+
Nesse caso, use o conteúdo padrão definido internamente (schema básico com Project, Module, File, Concept, Pattern, Dependency).
|
|
25
|
+
|
|
26
|
+
---
|
|
27
|
+
|
|
28
|
+
## Passo 1 — Entender a intenção
|
|
29
|
+
|
|
30
|
+
Apresente as duas opções ao usuário:
|
|
31
|
+
|
|
32
|
+
```
|
|
33
|
+
Como deseja proceder?
|
|
34
|
+
|
|
35
|
+
1. Modificar a arquitetura atual (ajustar regras, schema ou convenções)
|
|
36
|
+
2. Criar uma arquitetura do zero (descreva o que precisa)
|
|
37
|
+
```
|
|
38
|
+
|
|
39
|
+
Aguarde a resposta antes de continuar.
|
|
40
|
+
|
|
41
|
+
---
|
|
42
|
+
|
|
43
|
+
## Passo 2a — Se escolher "Modificar"
|
|
44
|
+
|
|
45
|
+
Mostre um resumo da arquitetura atual (schema e regras principais) e pergunte:
|
|
46
|
+
|
|
47
|
+
```
|
|
48
|
+
O que deseja modificar? Exemplos:
|
|
49
|
+
• Adicionar/remover tipos de nó
|
|
50
|
+
• Mudar regras de granularidade de módulo
|
|
51
|
+
• Alterar convenções de naming (português/inglês, etc.)
|
|
52
|
+
• Adicionar/remover tipos de relacionamento
|
|
53
|
+
• Mudar critérios de qualidade
|
|
54
|
+
• Ajustar regras de o que indexar/ignorar
|
|
55
|
+
```
|
|
56
|
+
|
|
57
|
+
Conduza a conversa até ter clareza completa sobre cada alteração desejada.
|
|
58
|
+
Se o usuário der uma instrução vaga ("quero algo mais simples"), faça perguntas de refinamento:
|
|
59
|
+
- "Simples em qual sentido? Menos tipos de nó? Menos regras?"
|
|
60
|
+
- "Pode me dar um exemplo do que ficaria fora?"
|
|
61
|
+
|
|
62
|
+
---
|
|
63
|
+
|
|
64
|
+
## Passo 2b — Se escolher "Do zero"
|
|
65
|
+
|
|
66
|
+
Conduza uma conversa estruturada com estas perguntas (adapte conforme as respostas):
|
|
67
|
+
|
|
68
|
+
**Sobre o domínio:**
|
|
69
|
+
- "Que tipo de projetos você vai indexar? (frontend, backend, monorepo, scripts, etc.)"
|
|
70
|
+
- "Qual linguagem/stack predominante?"
|
|
71
|
+
- "Qual o vocabulário do seu domínio? (ex: pedidos, clientes, eventos, pipelines)"
|
|
72
|
+
|
|
73
|
+
**Sobre o schema:**
|
|
74
|
+
- "Além de módulos e arquivos, quer rastrear algo mais? (ex: serviços externos, tabelas de banco, endpoints de API)"
|
|
75
|
+
- "Quer rastrear relacionamentos entre projetos diferentes?"
|
|
76
|
+
- "Padrões de design são relevantes para o seu contexto?"
|
|
77
|
+
|
|
78
|
+
**Sobre as regras:**
|
|
79
|
+
- "Qual é a granularidade ideal de módulo para você? (diretório? feature? domínio de negócio?)"
|
|
80
|
+
- "Há diretórios/arquivos específicos que sempre devem ser ignorados no seu contexto?"
|
|
81
|
+
- "Prefere conceitos em português, inglês ou misto?"
|
|
82
|
+
|
|
83
|
+
**Sobre os fluxos:**
|
|
84
|
+
- "Quer manter o fluxo de aprovação antes de salvar, ou prefere algo mais direto?"
|
|
85
|
+
- "O /update-memory deve sempre mostrar o delta ou pode salvar direto se as mudanças forem pequenas?"
|
|
86
|
+
|
|
87
|
+
Continue perguntando até ter uma visão clara e completa da arquitetura desejada.
|
|
88
|
+
|
|
89
|
+
---
|
|
90
|
+
|
|
91
|
+
## Passo 3 — Gerar a arquitetura
|
|
92
|
+
|
|
93
|
+
Com base na conversa, gere o arquivo completo `MEMORY_ARCHITECTURE.md` seguindo esta estrutura:
|
|
94
|
+
|
|
95
|
+
```markdown
|
|
96
|
+
# Memory Architecture — [título que reflita o contexto do usuário]
|
|
97
|
+
|
|
98
|
+
[descrição breve do propósito desta configuração]
|
|
99
|
+
|
|
100
|
+
---
|
|
101
|
+
|
|
102
|
+
## 1. Schema do Grafo
|
|
103
|
+
|
|
104
|
+
### Nodes
|
|
105
|
+
[tabela com nodes, propriedades e unicidade]
|
|
106
|
+
|
|
107
|
+
### Relationships
|
|
108
|
+
[diagrama em texto]
|
|
109
|
+
|
|
110
|
+
### Notas do schema
|
|
111
|
+
[decisões e justificativas]
|
|
112
|
+
|
|
113
|
+
---
|
|
114
|
+
|
|
115
|
+
## 2. Regras de Indexação
|
|
116
|
+
|
|
117
|
+
### O que É um módulo
|
|
118
|
+
[definição específica para o contexto do usuário]
|
|
119
|
+
|
|
120
|
+
### O que NÃO é um módulo
|
|
121
|
+
[exclusões]
|
|
122
|
+
|
|
123
|
+
### O que É um arquivo indexável
|
|
124
|
+
[critérios]
|
|
125
|
+
|
|
126
|
+
### O que NÃO indexar
|
|
127
|
+
[exclusões]
|
|
128
|
+
|
|
129
|
+
### Convenções de naming
|
|
130
|
+
[padrões de escrita para domain, concepts, patterns]
|
|
131
|
+
|
|
132
|
+
---
|
|
133
|
+
|
|
134
|
+
## 3. Fluxo de Criação (/create-memory)
|
|
135
|
+
[resumo do fluxo, com qualquer customização]
|
|
136
|
+
|
|
137
|
+
---
|
|
138
|
+
|
|
139
|
+
## 4. Fluxo de Atualização (/update-memory)
|
|
140
|
+
[resumo do fluxo, com qualquer customização]
|
|
141
|
+
|
|
142
|
+
---
|
|
143
|
+
|
|
144
|
+
## 5. Critérios de Qualidade
|
|
145
|
+
|
|
146
|
+
### Grafo saudável
|
|
147
|
+
[sinais positivos]
|
|
148
|
+
|
|
149
|
+
### Sinais de grafo poluído
|
|
150
|
+
[antipadrões a evitar]
|
|
151
|
+
|
|
152
|
+
---
|
|
153
|
+
|
|
154
|
+
## 6. Objeto canônico para save-project
|
|
155
|
+
[exemplo JSON com os campos relevantes para este contexto]
|
|
156
|
+
```
|
|
157
|
+
|
|
158
|
+
---
|
|
159
|
+
|
|
160
|
+
## Passo 4 — Apresentar para aprovação
|
|
161
|
+
|
|
162
|
+
Mostre o arquivo **completo** gerado ao usuário.
|
|
163
|
+
|
|
164
|
+
Diga: **"Esta é a arquitetura que vou salvar em `~/.claude/skills/MEMORY_ARCHITECTURE.md`. Revise, corrija o que quiser, e me diga 'pode salvar' quando estiver pronto."**
|
|
165
|
+
|
|
166
|
+
Se o usuário pedir ajustes:
|
|
167
|
+
- Aplique, mostre o trecho alterado
|
|
168
|
+
- Confirme: "Ajustei X. Mais alguma coisa antes de salvar?"
|
|
169
|
+
- Repita até aprovação
|
|
170
|
+
|
|
171
|
+
---
|
|
172
|
+
|
|
173
|
+
## Passo 5 — Salvar
|
|
174
|
+
|
|
175
|
+
Após aprovação explícita, salve o conteúdo gerado em:
|
|
176
|
+
|
|
177
|
+
```
|
|
178
|
+
~/.claude/skills/MEMORY_ARCHITECTURE.md
|
|
179
|
+
```
|
|
180
|
+
|
|
181
|
+
Informe ao usuário:
|
|
182
|
+
**"Arquitetura salva. O `/create-memory` e o `/update-memory` já vão usar essa configuração a partir de agora."**
|
|
183
|
+
|
|
184
|
+
Se quiser restaurar o padrão no futuro: **"Rode `jarvis --setup` novamente para reinstalar a arquitetura padrão."**
|
|
@@ -0,0 +1,125 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: create-memory
|
|
3
|
+
description: Indexar repositório atual no grafo de memória semântica (Neo4j) do zero
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# /create-memory — Criar Índice de Memória do Repositório
|
|
7
|
+
|
|
8
|
+
Você vai analisar o repositório atual de forma exaustiva e indexar seu entendimento no Neo4j.
|
|
9
|
+
|
|
10
|
+
**Antes de iniciar:** leia `.claude/skills/MEMORY_ARCHITECTURE.md` — ele define o schema do grafo, as regras de indexação e os critérios de qualidade que você deve seguir durante toda a execução desta skill.
|
|
11
|
+
|
|
12
|
+
## REGRA GLOBAL
|
|
13
|
+
|
|
14
|
+
- Se travar em qualquer ponto — dúvida técnica, conceitual, arquivo ilegível, ambiguidade de qualquer natureza — **pare e pergunte ao usuário** antes de continuar
|
|
15
|
+
- Não há limite de perguntas. Prefira perguntar a gravar algo errado
|
|
16
|
+
- Só chame a MCP tool `save-project` após o usuário dizer explicitamente "pode salvar" ou equivalente
|
|
17
|
+
|
|
18
|
+
---
|
|
19
|
+
|
|
20
|
+
## Passo 0 — Seleção de Branch
|
|
21
|
+
|
|
22
|
+
Pergunte ao usuário: **"Deseja indexar o branch `main` ou `qa`?"**
|
|
23
|
+
|
|
24
|
+
Após a resposta, execute:
|
|
25
|
+
```bash
|
|
26
|
+
git checkout <branch-escolhido>
|
|
27
|
+
git pull origin <branch-escolhido>
|
|
28
|
+
git branch --show-current
|
|
29
|
+
```
|
|
30
|
+
|
|
31
|
+
Se qualquer comando falhar (branch inexistente, conflitos, sem remote), pergunte ao usuário o que fazer antes de continuar.
|
|
32
|
+
|
|
33
|
+
---
|
|
34
|
+
|
|
35
|
+
## Passo 1 — Descoberta Inicial
|
|
36
|
+
|
|
37
|
+
```bash
|
|
38
|
+
# Manifesto principal do projeto
|
|
39
|
+
cat package.json 2>/dev/null || cat composer.json 2>/dev/null || cat pyproject.toml 2>/dev/null || cat go.mod 2>/dev/null || echo "Nenhum manifesto padrão encontrado"
|
|
40
|
+
|
|
41
|
+
# Estrutura de diretórios (sem ruído)
|
|
42
|
+
find . -maxdepth 3 -type d \
|
|
43
|
+
! -path "*/node_modules/*" ! -path "*/.git/*" \
|
|
44
|
+
! -path "*/dist/*" ! -path "*/build/*" ! -path "*/.next/*"
|
|
45
|
+
|
|
46
|
+
# Arquivos de configuração relevantes
|
|
47
|
+
find . -maxdepth 2 -type f \( -name "*.json" -o -name "*.toml" -o -name "*.yaml" -o -name "*.yml" \) \
|
|
48
|
+
! -path "*/node_modules/*" ! -path "*/.git/*"
|
|
49
|
+
```
|
|
50
|
+
|
|
51
|
+
Identifique com base no output:
|
|
52
|
+
- Linguagem principal e framework
|
|
53
|
+
- Candidatos a módulos (diretórios com responsabilidade identificável)
|
|
54
|
+
- Dependências do manifesto
|
|
55
|
+
|
|
56
|
+
Consulte `MEMORY_ARCHITECTURE.md §2` para decidir o que é ou não um módulo.
|
|
57
|
+
|
|
58
|
+
---
|
|
59
|
+
|
|
60
|
+
## Passo 2 — Análise Profunda
|
|
61
|
+
|
|
62
|
+
Para cada módulo candidato:
|
|
63
|
+
|
|
64
|
+
**1. Liste os arquivos:**
|
|
65
|
+
```bash
|
|
66
|
+
find <diretório> -type f \
|
|
67
|
+
! -path "*/node_modules/*" ! -path "*/.git/*" \
|
|
68
|
+
! -name "*.lock" ! -name "package-lock.json"
|
|
69
|
+
```
|
|
70
|
+
|
|
71
|
+
**2. Leia os arquivos relevantes** (entry points, services, controllers, handlers, routers, models).
|
|
72
|
+
|
|
73
|
+
**3. Para cada arquivo, determine:**
|
|
74
|
+
- **Responsabilidade:** o que este arquivo faz?
|
|
75
|
+
- **Imports/Exports:** quais módulos ele usa ou expõe?
|
|
76
|
+
- **Padrões:** nomes canônicos conforme `MEMORY_ARCHITECTURE.md §2`
|
|
77
|
+
- **Conceitos de negócio:** conforme regra de domínio em `MEMORY_ARCHITECTURE.md §2`
|
|
78
|
+
|
|
79
|
+
**A qualquer momento de incerteza → pergunte ao usuário.**
|
|
80
|
+
|
|
81
|
+
---
|
|
82
|
+
|
|
83
|
+
## Passo 3 — Montagem do Mapa
|
|
84
|
+
|
|
85
|
+
Consolide o mapa completo (sem salvar ainda):
|
|
86
|
+
|
|
87
|
+
```
|
|
88
|
+
Projeto: <nome> [<branch>]
|
|
89
|
+
Linguagem: <linguagem>
|
|
90
|
+
Descrição: <descrição curta>
|
|
91
|
+
|
|
92
|
+
Módulos:
|
|
93
|
+
- <nome> | Domínio: <domain> | Path: <path>
|
|
94
|
+
Arquivos: [lista com purpose de cada um]
|
|
95
|
+
Padrões: [padrões identificados]
|
|
96
|
+
Conceitos: [conceitos de negócio]
|
|
97
|
+
Depende de: [outros módulos do projeto]
|
|
98
|
+
|
|
99
|
+
Padrões globais do projeto: [lista]
|
|
100
|
+
Dependências externas relevantes: [nome, versão, tipo]
|
|
101
|
+
```
|
|
102
|
+
|
|
103
|
+
Valide o mapa contra os critérios de qualidade em `MEMORY_ARCHITECTURE.md §5` antes de apresentar.
|
|
104
|
+
|
|
105
|
+
---
|
|
106
|
+
|
|
107
|
+
## Passo 4 — Apresentação para Aprovação
|
|
108
|
+
|
|
109
|
+
Apresente o mapa completo ao usuário de forma clara e legível.
|
|
110
|
+
|
|
111
|
+
Diga ao final: **"Este é meu entendimento completo do projeto. Revise, corrija o que estiver errado, e quando estiver tudo certo me diga 'pode salvar'."**
|
|
112
|
+
|
|
113
|
+
Se o usuário corrigir algo:
|
|
114
|
+
- Atualize o mapa
|
|
115
|
+
- Confirme: "Entendido. Corrigi X para Y. Mais alguma correção?"
|
|
116
|
+
- Repita até aprovação explícita
|
|
117
|
+
|
|
118
|
+
---
|
|
119
|
+
|
|
120
|
+
## Passo 5 — Gravação
|
|
121
|
+
|
|
122
|
+
Após aprovação explícita, chame `save-project` com o objeto canônico definido em `MEMORY_ARCHITECTURE.md §6`.
|
|
123
|
+
|
|
124
|
+
Após sucesso:
|
|
125
|
+
**"Projeto `<nome>` [<branch>] indexado com sucesso no grafo de memória."**
|
|
@@ -110,4 +110,4 @@ Informe ao usuário:
|
|
|
110
110
|
- "Neo4j rodando em http://localhost:7474 (interface web) e bolt://localhost:7687"
|
|
111
111
|
- "MCP server `jarvis-memory` registrado em ~/.claude/settings.json"
|
|
112
112
|
- "**Reinicie o Claude Code** para que o MCP server seja ativado"
|
|
113
|
-
- "Após reiniciar, use `/memory
|
|
113
|
+
- "Após reiniciar, use `/create-memory` para indexar seu primeiro repositório"
|
|
@@ -0,0 +1,151 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: update-memory
|
|
3
|
+
description: Atualizar o índice de memória semântica (Neo4j) de um repositório já indexado com base nas mudanças recentes
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# /update-memory — Atualizar Memória do Repositório
|
|
7
|
+
|
|
8
|
+
Você vai identificar o que mudou no repositório desde a última indexação e aplicar as atualizações no grafo de memória.
|
|
9
|
+
|
|
10
|
+
**Antes de iniciar:** leia `.claude/skills/MEMORY_ARCHITECTURE.md` — ele define o schema, as regras de indexação e os critérios de qualidade que guiam esta skill.
|
|
11
|
+
|
|
12
|
+
## REGRA GLOBAL
|
|
13
|
+
|
|
14
|
+
- Se travar em qualquer ponto — dúvida técnica, ambiguidade, mudança que não entende — **pare e pergunte ao usuário**
|
|
15
|
+
- Só chame `save-project` após aprovação explícita do usuário
|
|
16
|
+
- **Nunca re-indexar o projeto inteiro** — se detectar que a mudança é muito grande, sugira usar `/create-memory` no lugar
|
|
17
|
+
|
|
18
|
+
---
|
|
19
|
+
|
|
20
|
+
## Passo 0 — Consultar Estado Atual do Grafo
|
|
21
|
+
|
|
22
|
+
Chame a MCP tool `query-project` para obter o estado atual indexado:
|
|
23
|
+
|
|
24
|
+
```
|
|
25
|
+
query-project(name: "<nome do projeto>", branch: "<branch>")
|
|
26
|
+
```
|
|
27
|
+
|
|
28
|
+
Se o projeto não estiver indexado, interrompa e informe:
|
|
29
|
+
**"Este projeto não está indexado ainda. Use `/create-memory` para criar o índice inicial."**
|
|
30
|
+
|
|
31
|
+
Anote o estado atual: módulos existentes, conceitos, padrões.
|
|
32
|
+
|
|
33
|
+
---
|
|
34
|
+
|
|
35
|
+
## Passo 1 — Detectar Mudanças no Repositório
|
|
36
|
+
|
|
37
|
+
Execute os comandos abaixo para entender o que mudou:
|
|
38
|
+
|
|
39
|
+
```bash
|
|
40
|
+
# Commits recentes (para ter contexto das mudanças)
|
|
41
|
+
git log --oneline -20
|
|
42
|
+
|
|
43
|
+
# Arquivos modificados nos últimos commits (ajuste N conforme necessário)
|
|
44
|
+
git diff HEAD~5..HEAD --name-status
|
|
45
|
+
|
|
46
|
+
# Arquivos modificados e não commitados (trabalho em andamento)
|
|
47
|
+
git status --short
|
|
48
|
+
|
|
49
|
+
# Resumo de quais diretórios foram afetados
|
|
50
|
+
git diff HEAD~5..HEAD --name-only | sed 's|/[^/]*$||' | sort -u
|
|
51
|
+
```
|
|
52
|
+
|
|
53
|
+
Se o projeto não tiver histórico git ou a última indexação for muito antiga, pergunte ao usuário qual período considerar.
|
|
54
|
+
|
|
55
|
+
---
|
|
56
|
+
|
|
57
|
+
## Passo 2 — Calcular o Delta
|
|
58
|
+
|
|
59
|
+
Com base nos arquivos modificados, classifique cada mudança:
|
|
60
|
+
|
|
61
|
+
### Módulos novos
|
|
62
|
+
Diretórios que apareceram e não existem no grafo atual.
|
|
63
|
+
|
|
64
|
+
### Módulos modificados
|
|
65
|
+
Diretórios cujos arquivos foram alterados (novos arquivos, arquivos removidos, lógica modificada).
|
|
66
|
+
|
|
67
|
+
### Módulos removidos
|
|
68
|
+
Diretórios que existiam no grafo mas não existem mais no código.
|
|
69
|
+
> ⚠️ **Limitação v1:** `save-project` não deleta nós — módulos removidos serão sinalizados ao usuário mas não removidos automaticamente do grafo.
|
|
70
|
+
|
|
71
|
+
### Novos conceitos / padrões
|
|
72
|
+
Identificados na análise dos módulos modificados que não constam no grafo atual.
|
|
73
|
+
|
|
74
|
+
Apresente o delta inicial ao usuário antes de continuar a análise profunda:
|
|
75
|
+
|
|
76
|
+
```
|
|
77
|
+
Delta detectado:
|
|
78
|
+
✅ Módulos novos: [lista]
|
|
79
|
+
🔄 Módulos modificados: [lista]
|
|
80
|
+
⚠️ Módulos removidos (ficam no grafo — não são deletados automaticamente): [lista]
|
|
81
|
+
```
|
|
82
|
+
|
|
83
|
+
Pergunte: **"Este delta está correto? Posso prosseguir com a análise?"**
|
|
84
|
+
|
|
85
|
+
---
|
|
86
|
+
|
|
87
|
+
## Passo 3 — Re-analisar Módulos Afetados
|
|
88
|
+
|
|
89
|
+
Para cada módulo **novo** ou **modificado** (apenas esses):
|
|
90
|
+
|
|
91
|
+
**1. Liste os arquivos atuais:**
|
|
92
|
+
```bash
|
|
93
|
+
find <diretório> -type f \
|
|
94
|
+
! -path "*/node_modules/*" ! -path "*/.git/*" \
|
|
95
|
+
! -name "*.lock"
|
|
96
|
+
```
|
|
97
|
+
|
|
98
|
+
**2. Leia os arquivos relevantes.**
|
|
99
|
+
|
|
100
|
+
**3. Determine para cada arquivo:**
|
|
101
|
+
- Responsabilidade
|
|
102
|
+
- Padrões (nomes canônicos conforme `MEMORY_ARCHITECTURE.md §2`)
|
|
103
|
+
- Conceitos de negócio (domínio, não termos técnicos)
|
|
104
|
+
- Dependências de outros módulos
|
|
105
|
+
|
|
106
|
+
**A qualquer incerteza → pergunte ao usuário.**
|
|
107
|
+
|
|
108
|
+
---
|
|
109
|
+
|
|
110
|
+
## Passo 4 — Apresentar Delta Completo
|
|
111
|
+
|
|
112
|
+
Apresente o mapa atualizado apenas com o que vai mudar:
|
|
113
|
+
|
|
114
|
+
```
|
|
115
|
+
## Atualização proposta para <nome do projeto> [<branch>]
|
|
116
|
+
|
|
117
|
+
### Módulos novos
|
|
118
|
+
- <nome> | Domínio: <domain> | Path: <path>
|
|
119
|
+
Arquivos: [lista]
|
|
120
|
+
Padrões: [lista]
|
|
121
|
+
Conceitos: [lista]
|
|
122
|
+
Depende de: [lista]
|
|
123
|
+
|
|
124
|
+
### Módulos atualizados
|
|
125
|
+
- <nome> | Antes: <domain antigo> → Depois: <domain novo>
|
|
126
|
+
Arquivos adicionados: [lista]
|
|
127
|
+
Arquivos removidos: [lista]
|
|
128
|
+
Novos conceitos: [lista]
|
|
129
|
+
Novos padrões: [lista]
|
|
130
|
+
|
|
131
|
+
### ⚠️ Módulos removidos do código (permanecem no grafo nesta versão)
|
|
132
|
+
- <nome> — ainda presente no grafo, mas não encontrado no código
|
|
133
|
+
```
|
|
134
|
+
|
|
135
|
+
Diga ao final: **"Este é o delta que vou aplicar. Corrija o que estiver errado e me diga 'pode salvar' quando estiver pronto."**
|
|
136
|
+
|
|
137
|
+
---
|
|
138
|
+
|
|
139
|
+
## Passo 5 — Aplicar Merge no Grafo
|
|
140
|
+
|
|
141
|
+
Após aprovação explícita, monte o objeto completo do projeto (estado atual do grafo + mudanças do delta) e chame `save-project`.
|
|
142
|
+
|
|
143
|
+
O `save-project` usa `MERGE` — atualiza e adiciona, nunca deleta. O resultado será um merge seguro.
|
|
144
|
+
|
|
145
|
+
Use o objeto canônico definido em `MEMORY_ARCHITECTURE.md §6`.
|
|
146
|
+
|
|
147
|
+
Após sucesso:
|
|
148
|
+
**"Memória de `<nome>` [<branch>] atualizada. <N> módulos processados."**
|
|
149
|
+
|
|
150
|
+
Se houver módulos removidos não tratados:
|
|
151
|
+
**"⚠️ Os módulos `<lista>` foram removidos do código mas ainda existem no grafo. Para removê-los, será necessário um tool de limpeza (previsto para v2)."**
|
package/README.md
CHANGED
|
@@ -17,17 +17,30 @@ Reinicie o Claude Code após o setup.
|
|
|
17
17
|
|
|
18
18
|
## Comandos
|
|
19
19
|
|
|
20
|
+
**CLI:**
|
|
21
|
+
|
|
20
22
|
| Comando | Descrição |
|
|
21
23
|
|---|---|
|
|
22
24
|
| `jarvis` | Mostra a versão |
|
|
23
25
|
| `jarvis --usage` | Dashboard completo de uso (tokens, custo, contexto) |
|
|
24
26
|
| `jarvis --watch` | Dashboard com auto-refresh a cada 30s |
|
|
25
|
-
| `jarvis --setup` | Configura status bar
|
|
27
|
+
| `jarvis --setup` | Configura status bar, instala slash commands e define trigger padrão |
|
|
26
28
|
| `jarvis --graph` | Abre o Neo4j Browser em localhost:7474 |
|
|
29
|
+
| `jarvis --trigger` | Mostra o modo de trigger atual |
|
|
30
|
+
| `jarvis --trigger session` | Hook de memória roda uma vez por sessão *(padrão)* |
|
|
31
|
+
| `jarvis --trigger prompt` | Hook de memória roda a cada prompt |
|
|
32
|
+
| `jarvis --trigger off` | Desativa o carregamento automático de memória |
|
|
27
33
|
| `jarvis --line` | Saída de uma linha usada internamente pela status bar |
|
|
28
34
|
| `jarvis --help` | Lista todos os comandos |
|
|
29
|
-
|
|
30
|
-
|
|
35
|
+
|
|
36
|
+
**Slash commands** *(dentro do Claude Code)*:
|
|
37
|
+
|
|
38
|
+
| Comando | Descrição |
|
|
39
|
+
|---|---|
|
|
40
|
+
| `/setup-memory` | Sobe Neo4j via Docker e registra o MCP server |
|
|
41
|
+
| `/create-memory` | Indexa um repositório no grafo de memória (primeira vez) |
|
|
42
|
+
| `/update-memory` | Atualiza o grafo com as mudanças recentes do repositório |
|
|
43
|
+
| `/configure-memory` | Personaliza o schema, regras e fluxos da arquitetura de memória |
|
|
31
44
|
|
|
32
45
|
---
|
|
33
46
|
|
package/bin/jarvis.js
CHANGED
|
@@ -55,7 +55,9 @@ if (args.includes('--help') || args.includes('-h')) {
|
|
|
55
55
|
|
|
56
56
|
Slash commands (inside Claude Code):
|
|
57
57
|
/setup-memory Setup Docker + Neo4j + register MCP server
|
|
58
|
-
/memory
|
|
58
|
+
/create-memory Index a repository into the memory graph (first time)
|
|
59
|
+
/update-memory Update an existing memory graph with recent changes
|
|
60
|
+
/configure-memory Customize the memory graph architecture (schema, rules, flows)
|
|
59
61
|
|
|
60
62
|
Data source: ~/.claude/projects/
|
|
61
63
|
`);
|
|
@@ -88,13 +90,17 @@ if (args.includes('--graph')) {
|
|
|
88
90
|
// Slash commands → ~/.claude/skills/<name>/SKILL.md
|
|
89
91
|
const skillsDir = join(homedir(), '.claude', 'skills');
|
|
90
92
|
const srcSkills = join(__dir, '../.claude/skills');
|
|
91
|
-
for (const skill of ['setup-memory', 'memory-
|
|
93
|
+
for (const skill of ['setup-memory', 'create-memory', 'update-memory', 'configure-memory']) {
|
|
92
94
|
const destDir = join(skillsDir, skill);
|
|
93
95
|
mkdirSync(destDir, { recursive: true });
|
|
94
96
|
copyFileSync(join(srcSkills, skill, 'SKILL.md'), join(destDir, 'SKILL.md'));
|
|
95
97
|
console.log(` ✓ Slash command /${skill} installed`);
|
|
96
98
|
}
|
|
97
99
|
|
|
100
|
+
// Arquitetura de memória (referenciada pelas skills)
|
|
101
|
+
copyFileSync(join(srcSkills, 'MEMORY_ARCHITECTURE.md'), join(skillsDir, 'MEMORY_ARCHITECTURE.md'));
|
|
102
|
+
console.log(' ✓ MEMORY_ARCHITECTURE.md installed');
|
|
103
|
+
|
|
98
104
|
// Trigger padrão: session
|
|
99
105
|
const memoryCfg = loadMemoryConfig();
|
|
100
106
|
if (!memoryCfg.trigger) {
|
package/package.json
CHANGED
package/src/memory/mcp-server.js
CHANGED
|
@@ -65,7 +65,7 @@ const TOOLS = [
|
|
|
65
65
|
},
|
|
66
66
|
{
|
|
67
67
|
name: 'save-project',
|
|
68
|
-
description: 'Salva o entendimento completo de um projeto no grafo. Use após aprovação do usuário no /memory-
|
|
68
|
+
description: 'Salva o entendimento completo de um projeto no grafo. Use após aprovação do usuário no /create-memory ou /update-memory.',
|
|
69
69
|
inputSchema: {
|
|
70
70
|
type: 'object',
|
|
71
71
|
properties: {
|
|
@@ -138,7 +138,7 @@ async function handleListProjects() {
|
|
|
138
138
|
language: r.get('language'),
|
|
139
139
|
}));
|
|
140
140
|
if (!projects.length) {
|
|
141
|
-
return 'Nenhum projeto indexado ainda. Use /memory
|
|
141
|
+
return 'Nenhum projeto indexado ainda. Use /create-memory para indexar um repositório.';
|
|
142
142
|
}
|
|
143
143
|
return `Projetos indexados:\n${projects.map(p =>
|
|
144
144
|
`• ${p.name} [${p.branch}] — ${p.language}${p.description ? ': ' + p.description : ''}`
|
|
@@ -1,168 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: memory-index
|
|
3
|
-
description: Indexar repositório atual no grafo de memória semantica (Neo4j)
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
# Memory Index — Indexar Repositório no Grafo de Memória
|
|
7
|
-
|
|
8
|
-
Você vai analisar o repositório atual de forma exaustiva e indexar seu entendimento no Neo4j. **Não grave nada sem aprovação explícita do usuário.**
|
|
9
|
-
|
|
10
|
-
## REGRA GLOBAL
|
|
11
|
-
- Se travar em qualquer ponto — dúvida técnica, conceitual, arquivo ilegível, ambiguidade de qualquer natureza — **pare e pergunte ao usuário** antes de continuar
|
|
12
|
-
- Não há limite de perguntas. Prefira perguntar a gravar algo errado
|
|
13
|
-
- Só chame a MCP tool `save-project` após o usuário dizer explicitamente "pode salvar" ou equivalente
|
|
14
|
-
|
|
15
|
-
---
|
|
16
|
-
|
|
17
|
-
## Passo 0 — Seleção de Branch
|
|
18
|
-
|
|
19
|
-
Pergunte ao usuário: **"Deseja indexar o branch `main` ou `qa`?"**
|
|
20
|
-
|
|
21
|
-
Após a resposta, execute:
|
|
22
|
-
```bash
|
|
23
|
-
git checkout <branch-escolhido>
|
|
24
|
-
git pull origin <branch-escolhido>
|
|
25
|
-
```
|
|
26
|
-
|
|
27
|
-
Se algum comando falhar (branch inexistente, conflitos, sem remote), pergunte ao usuário o que fazer antes de continuar.
|
|
28
|
-
|
|
29
|
-
Confirme com:
|
|
30
|
-
```bash
|
|
31
|
-
git branch --show-current
|
|
32
|
-
```
|
|
33
|
-
|
|
34
|
-
O output deve mostrar o branch escolhido. Se não, pergunte ao usuário.
|
|
35
|
-
|
|
36
|
-
---
|
|
37
|
-
|
|
38
|
-
## Passo 1 — Descoberta Inicial
|
|
39
|
-
|
|
40
|
-
Execute para entender a estrutura geral:
|
|
41
|
-
|
|
42
|
-
```bash
|
|
43
|
-
# Manifesto principal do projeto
|
|
44
|
-
cat package.json 2>/dev/null || cat composer.json 2>/dev/null || cat pyproject.toml 2>/dev/null || cat go.mod 2>/dev/null || echo "Nenhum manifesto padrão encontrado"
|
|
45
|
-
|
|
46
|
-
# Estrutura de diretórios (sem node_modules, .git, dist, build)
|
|
47
|
-
find . -maxdepth 3 -type d \
|
|
48
|
-
! -path "*/node_modules/*" ! -path "*/.git/*" \
|
|
49
|
-
! -path "*/dist/*" ! -path "*/build/*" ! -path "*/.next/*"
|
|
50
|
-
|
|
51
|
-
# Arquivos de configuração relevantes
|
|
52
|
-
find . -maxdepth 2 -type f \( -name "*.json" -o -name "*.toml" -o -name "*.yaml" -o -name "*.yml" -o -name "*.env.example" \) \
|
|
53
|
-
! -path "*/node_modules/*" ! -path "*/.git/*"
|
|
54
|
-
```
|
|
55
|
-
|
|
56
|
-
Com base no output, identifique:
|
|
57
|
-
- Linguagem principal e framework
|
|
58
|
-
- Diretórios de primeiro e segundo nível como candidatos a módulos
|
|
59
|
-
- Dependências listadas no manifesto
|
|
60
|
-
|
|
61
|
-
Se qualquer coisa não for óbvia, pergunte ao usuário antes de prosseguir.
|
|
62
|
-
|
|
63
|
-
---
|
|
64
|
-
|
|
65
|
-
## Passo 2 — Análise Profunda
|
|
66
|
-
|
|
67
|
-
Para cada diretório candidato a módulo identificado:
|
|
68
|
-
|
|
69
|
-
**1. Liste os arquivos:**
|
|
70
|
-
```bash
|
|
71
|
-
find <diretório> -type f \
|
|
72
|
-
! -path "*/node_modules/*" ! -path "*/.git/*" \
|
|
73
|
-
! -name "*.lock" ! -name "package-lock.json"
|
|
74
|
-
```
|
|
75
|
-
|
|
76
|
-
**2. Leia os arquivos mais relevantes** (entry points, services, controllers, models, routers, handlers):
|
|
77
|
-
- Priorize: `.js`, `.ts`, `.py`, `.php`, `.go`, `.java`, `.rb`
|
|
78
|
-
- Ignore: binários, lock files, arquivos gerados, arquivos minificados
|
|
79
|
-
|
|
80
|
-
**3. Para cada arquivo lido, determine com certeza:**
|
|
81
|
-
- **Responsabilidade:** o que este arquivo faz?
|
|
82
|
-
- **Imports/Exports:** quais módulos ele usa ou expõe?
|
|
83
|
-
- **Padrões:** Repository, Service Layer, MVC, Factory, Middleware, etc.?
|
|
84
|
-
- **Domínio de negócio:** a qual área pertence (autenticação, pedidos, faturamento, etc.)?
|
|
85
|
-
|
|
86
|
-
**A qualquer momento que não tiver 100% de certeza → pergunte ao usuário.**
|
|
87
|
-
|
|
88
|
-
Exemplos de perguntas válidas:
|
|
89
|
-
- "A pasta `src/oms/` é o módulo de gestão de pedidos?"
|
|
90
|
-
- "O arquivo `auth.service.js` usa JWT ou sessões?"
|
|
91
|
-
- "Qual é o domínio de negócio de `src/billing/`?"
|
|
92
|
-
- "Este diretório `src/shared/` contém utilitários compartilhados?"
|
|
93
|
-
- "Esse padrão aqui é Repository ou Service Layer?"
|
|
94
|
-
|
|
95
|
-
---
|
|
96
|
-
|
|
97
|
-
## Passo 3 — Montagem do Mapa
|
|
98
|
-
|
|
99
|
-
Ao concluir a análise, consolide mentalmente (sem gravar ainda) o mapa completo:
|
|
100
|
-
|
|
101
|
-
```
|
|
102
|
-
Projeto: <nome> [<branch>]
|
|
103
|
-
Linguagem: <linguagem>
|
|
104
|
-
Descrição: <descrição curta do que o projeto faz>
|
|
105
|
-
|
|
106
|
-
Módulos:
|
|
107
|
-
- <nome> | Domínio: <domínio> | Path: <path>
|
|
108
|
-
Arquivos: [lista com propósito de cada um]
|
|
109
|
-
Padrões: [padrões de código identificados]
|
|
110
|
-
Conceitos: [conceitos de negócio]
|
|
111
|
-
Depende de: [outros módulos do projeto]
|
|
112
|
-
|
|
113
|
-
Padrões globais do projeto: [lista]
|
|
114
|
-
Dependências externas relevantes: [nome, versão, tipo]
|
|
115
|
-
```
|
|
116
|
-
|
|
117
|
-
---
|
|
118
|
-
|
|
119
|
-
## Passo 4 — Apresentação para Aprovação
|
|
120
|
-
|
|
121
|
-
Apresente o mapa completo ao usuário de forma clara e legível.
|
|
122
|
-
|
|
123
|
-
Diga ao final: **"Este é meu entendimento completo do projeto. Revise, corrija o que estiver errado, e quando estiver tudo certo me diga 'pode salvar'."**
|
|
124
|
-
|
|
125
|
-
Aguarde a resposta. Se o usuário corrigir algo:
|
|
126
|
-
- Atualize o mapa
|
|
127
|
-
- Confirme as correções: "Entendido. Corrigi X para Y. Mais alguma correção?"
|
|
128
|
-
- Repita até aprovação explícita
|
|
129
|
-
|
|
130
|
-
---
|
|
131
|
-
|
|
132
|
-
## Passo 5 — Gravação
|
|
133
|
-
|
|
134
|
-
Após aprovação explícita do usuário, chame a MCP tool `save-project` com o objeto completo:
|
|
135
|
-
|
|
136
|
-
```json
|
|
137
|
-
{
|
|
138
|
-
"project": {
|
|
139
|
-
"name": "<nome do projeto>",
|
|
140
|
-
"path": "<path absoluto do repositório>",
|
|
141
|
-
"description": "<descrição>",
|
|
142
|
-
"language": "<linguagem principal>",
|
|
143
|
-
"branch": "<branch escolhido>"
|
|
144
|
-
},
|
|
145
|
-
"modules": [
|
|
146
|
-
{
|
|
147
|
-
"name": "<nome do módulo>",
|
|
148
|
-
"path": "<path relativo>",
|
|
149
|
-
"domain": "<domínio de negócio>",
|
|
150
|
-
"files": [
|
|
151
|
-
{ "path": "<path do arquivo>", "purpose": "<responsabilidade>" }
|
|
152
|
-
],
|
|
153
|
-
"patterns": ["<padrão identificado>"],
|
|
154
|
-
"concepts": ["<conceito de negócio>"],
|
|
155
|
-
"dependsOn": ["<nome de outro módulo do projeto>"]
|
|
156
|
-
}
|
|
157
|
-
],
|
|
158
|
-
"dependencies": [
|
|
159
|
-
{ "name": "<nome>", "version": "<versão>", "type": "external" }
|
|
160
|
-
],
|
|
161
|
-
"patterns": [
|
|
162
|
-
{ "name": "<nome>", "description": "<descrição do padrão>" }
|
|
163
|
-
]
|
|
164
|
-
}
|
|
165
|
-
```
|
|
166
|
-
|
|
167
|
-
Após a tool retornar sucesso, informe ao usuário:
|
|
168
|
-
**"Projeto `<nome>` [<branch>] indexado com sucesso no grafo de memória."**
|