diegoschagas.SmartDependencies 0.1.8

DSC.Tech.SmartDependencies

DSC.Tech.SmartDependencies é um gerador de backend .NET orientado a modelo e exposto através do Model Context Protocol (MCP).

O projeto utiliza um arquivo definitions.txt como fonte de verdade do domínio e, a partir dessa definição, gera automaticamente uma solução backend estruturada com Clean Architecture, CQRS, Repository Pattern, Entity Framework Core, API REST e OpenAPI.

O objetivo é reduzir código repetitivo, manter consistência arquitetural entre projetos e permitir que ferramentas e agentes compatíveis com MCP gerem backends completos a partir de uma DSL declarativa.

---

Principais recursos

A partir do definitions.txt, o gerador pode produzir:

• Domain
• Application
• Infrastructure
• API REST
• Entities
• Commands e Command Handlers
• Queries e Query Handlers
• DTOs
• Validators
• Repository Interfaces
• Repositories
• Entity Framework Core
• DbContext
• Persistence
• Dependency Injection
• Controllers
• Testes
• OpenAPI
• suporte a autenticação externa Bearer
• suporte a FEATURE AI
• relacionamentos locais e referências externas

O gerador foi desenhado para permanecer genérico: particularidades de cada sistema pertencem ao definitions.txt, não ao código do MCP.

---

Arquitetura

O fluxo principal é:

definitions.txt
       │
       ▼
DefinitionParser
       │
       ▼
ProjectDefinition
       │
       ├── Persistence
       ├── Features
       ├── Authentication
       ├── AI
       ├── Entities
       ├── Fields
       ├── Relationships
       ├── External References
       └── Metadata
       │
       ▼
Generation Pipeline
       │
       ├── Domain
       ├── Application
       ├── Infrastructure
       ├── API
       ├── Tests
       └── OpenAPI

O definitions.txt funciona como uma DSL (Domain Definition Language). O DefinitionParser interpreta a DSL uma única vez e produz um modelo canônico. Os templates e geradores consomem esse modelo; eles não devem reinterpretar o texto de forma independente.

---

Pré-requisitos

Para uso local:

• .NET 10 SDK
• PowerShell 7 recomendado para scripts auxiliares
• Visual Studio Code ou Visual Studio
• GitHub Copilot / cliente MCP opcional
• PostgreSQL, MongoDB ou outro serviço necessário ao projeto gerado, conforme a persistência declarada

Para uso via MCP/NuGet:

• dnx
• um cliente compatível com MCP

---

Como rodar

O uso recomendado do pacote publicado no NuGet é através de um cliente compatível com MCP, como o GitHub Copilot Agent no VS Code.

1. Criar uma pasta para o projeto

Exemplo:

mkdir E:\Projects\MeuProjeto; cd E:\Projects\MeuProjeto

Crie nessa pasta o arquivo:

definitions.txt

Exemplo mínimo:

DSC.Sample;

PERSISTENCE RELATIONAL;

FEATURE API;

"Customer"
Id UUID PRIMARY KEY
Name VARCHAR(150) NOT NULL
Email VARCHAR(200) NOT NULL UNIQUE
CreatedAt TIMESTAMP NOT NULL DEFAULT NOW()
UpdatedAt TIMESTAMP NULL
;

O nome da primeira linha define o nome lógico do projeto gerado.

---

2. Configurar o MCP no VS Code

Crie o arquivo:

.vscode/mcp.json

Conteúdo:

{
  "servers": {
    "dsc-smartdependencies": {
      "type": "stdio",
      "command": "dnx",
      "args": [
        "diegoschagas.SmartDependencies@<VERSAO>",
        "--yes"
      ]
    }
  }
}

Substitua <VERSAO> pela versão publicada no NuGet.

Exemplo de estrutura:

MeuProjeto/
├── .vscode/
│   └── mcp.json
├── definitions.txt
└── ...

O pacote é executado via dnx; não é necessário adicionar referência NuGet ao projeto que será gerado.

---

3. Confirmar que o servidor MCP está disponível

No VS Code:

Ctrl + Shift + P

Execute:

MCP: List Servers

O servidor deve aparecer como:

dsc-smartdependencies

Se necessário, inicie ou reinicie o servidor MCP pelo próprio VS Code.

---

4. Gerar o backend

No Copilot Agent, use por exemplo:

Use o MCP dsc-smartdependencies para gerar o backend completo
usando o definitions.txt deste projeto.

Ou informe explicitamente a ferramenta e os caminhos:

Use a ferramenta generate_full_project do MCP dsc-smartdependencies.

root:
E:\Projects\MeuProjeto

definitionsFile:
E:\Projects\MeuProjeto\definitions.txt

Fluxo:

Copilot Agent
    │
    ▼
MCP
    │
    ▼
DSC.Tech.SmartDependencies
    │
    ▼
generate_full_project
    │
    ▼
definitions.txt
    │
    ▼
ProjectDefinition
    │
    ▼
Backend .NET

---

5. Compilar o projeto gerado

Na raiz da solução gerada:

dotnet build

---

6. Criar e aplicar migrations

Para projetos com PERSISTENCE RELATIONAL:

dotnet ef migrations add InitialCreate --project .\src\Project.Infrastructure --startup-project .\src\Project.Api --output-dir Migrations

Depois:

dotnet ef database update --project .\src\Project.Infrastructure --startup-project .\src\Project.Api

Substitua Project pelo nome real do projeto gerado quando necessário.

A connection string deve ser configurada de acordo com o ambiente antes de aplicar a migration.

---

7. Executar a API

dotnet run --project .\src\Project.Api\Project.Api.csproj

A porta utilizada é definida pelo projeto/ambiente gerado e não é fixa no MCP.

Depois de iniciar a API, utilize o endpoint OpenAPI/Swagger exposto pela aplicação para validar o contrato gerado.

---

Exemplo com Authentication externa e AI

Quando o projeto utiliza Authentication externa e AI, essas configurações devem estar declaradas no definitions.txt.

Exemplo:

DSC.Sample;

PERSISTENCE RELATIONAL;

FEATURE API;
FEATURE AI;

AUTHENTICATION EXTERNAL
PROVIDER OPENAPI
SCHEME BEARER
ISSUER "DSC.API.Authentication"
AUDIENCE "sample-api"
;

AI EXTERNAL
PROVIDER OPENROUTER
BASEURL "https://openrouter.ai/api/v1"
MODEL "openrouter/free"
MODE TOOLS
;

Secrets não devem ser colocados no definitions.txt.

Para Authentication baseada em chave simétrica, configure a chave fora do código, por exemplo:

dotnet user-secrets set "Authentication:Key" "<KEY>" --project .\src\Project.Api\Project.Api.csproj

Para providers de AI que exigem chave, utilize o mecanismo de configuração segura adotado pela aplicação/ambiente.

---

Relacionamentos locais e externos

Relacionamento local:

HouseholdId UUID NOT NULL REFERENCES Household(Id)

Referência externa:

UserId UUID NOT NULL REFERENCES EXTERNAL Authentication.User(Id)

A diferença é importante:

LOCAL
→ pertence ao mesmo domínio
→ pode gerar FK e navigation property no Entity Framework

EXTERNAL
→ pertence a outro sistema/provider
→ mantém somente o identificador escalar
→ não gera FK local
→ não gera navigation property local

O OpenAPI gerado publica metadados x-dsc-relationship para que outros geradores possam distinguir relações locais e externas.

---

Uso programático

Também é possível chamar o gerador diretamente em C#:

using DSC.Tech.SmartDependencies.Tools;

var root = @"E:\Projects\MeuProjeto";
var definitionsFile = Path.Combine(root, "definitions.txt");

var result =
    await new FullProjectGeneratorTools()
        .GenerateFullProject(
            root,
            definitionsFile);

Console.WriteLine(result);

Esse modo é útil principalmente para desenvolvimento do próprio MCP, testes de regressão e automações internas.

---

Estrutura geral do definitions.txt

Um arquivo pode combinar:

ProjectName;

PERSISTENCE ...

FEATURE ...

AUTHENTICATION ...

AI ...

"Entity"
...
;

Exemplo mais completo:

DSC.Oikos;

PERSISTENCE RELATIONAL;

FEATURE API;
FEATURE AI;

AUTHENTICATION EXTERNAL
PROVIDER OPENAPI
SCHEME BEARER
ISSUER "DSC.API.Authentication"
AUDIENCE "sample-api"
;

@project title="Oikos"
@project tagline="Gestão financeira para o seu lar."
@dashboard enabled=true defaultPeriod="CURRENT_MONTH"

"Household"
Id UUID PRIMARY KEY
Name VARCHAR(150) NOT NULL
Description VARCHAR(500)
Currency VARCHAR(10) NOT NULL DEFAULT 'BRL'
IsActive BOOLEAN NOT NULL DEFAULT TRUE
CreatedAt TIMESTAMP NOT NULL DEFAULT NOW()
UpdatedAt TIMESTAMP NULL
;

---

Persistência

Relacional

PERSISTENCE RELATIONAL;

Gera infraestrutura relacional baseada em Entity Framework Core.

MongoDB

PERSISTENCE MONGODB;

A escolha de persistência pertence ao modelo declarativo. Ela não deve ser inferida pelo nome do projeto.

---

Features

API

FEATURE API;

Gera a API REST e os artefatos associados.

AI

FEATURE AI;

Habilita a infraestrutura de AI prevista pelo gerador.

A configuração operacional do provider pode ser declarada na DSL e propagada para a aplicação gerada.

Exemplo:

AI EXTERNAL
PROVIDER OPENROUTER
BASEURL "https://openrouter.ai/api/v1"
MODEL "openrouter/free"
MODE TOOLS
;

Secrets continuam fora do definitions.txt e do código gerado.

A implementação gerada deve continuar genérica. O MCP não deve ser acoplado a um único sistema ou provider.

---

Authentication externa

Uma API de domínio pode utilizar uma API de autenticação separada.

DSL:

AUTHENTICATION EXTERNAL
PROVIDER OPENAPI
SCHEME BEARER
ISSUER "DSC.API.Authentication"
AUDIENCE "sample-api"
;

Isso significa:

Authentication API
      │
      │ emite JWT
      ▼
Bearer Token
      │
      ▼
API de domínio

Nesse modo, a API de domínio:

• valida o token;
• utiliza AddAuthentication;
• utiliza Bearer/JWT;
• utiliza AddAuthorization;
• pode proteger controllers com [Authorize];
• publica segurança Bearer no OpenAPI.

Ela não deve gerar:

• login;
• refresh token;
• password hashing;
• armazenamento de senha;
• endpoints internos da API de Authentication;
• bootstrap de usuários do servidor de identidade.

FEATURE AUTHENTICATION e AUTHENTICATION EXTERNAL possuem significados diferentes.

---

Relacionamentos locais

Relacionamentos entre entidades do mesmo domínio são declarados com:

HouseholdId UUID NOT NULL REFERENCES Household(Id)

O modelo canônico representa esse relacionamento como uma relação local.

Uma relação local pode gerar:

• propriedade FK;
• navigation property;
• configuração EF;
• display de relacionamento em DTOs;
• metadados de relacionamento no OpenAPI.

Exemplo:

"Account"
Id UUID PRIMARY KEY
HouseholdId UUID NOT NULL REFERENCES Household(Id)
Name VARCHAR(150) NOT NULL
;

---

Referências externas

Quando o identificador aponta para uma entidade pertencente a outro sistema, utilize:

REFERENCES EXTERNAL Provider.Entity(Property)

Exemplo:

UserId UUID NOT NULL REFERENCES EXTERNAL Authentication.User(Id)

Outro exemplo:

CustomerId UUID NULL REFERENCES EXTERNAL CRM.Customer(Id)

Conceitualmente:

LOCAL
HouseholdId
    │
    ▼
Household
    └── entidade do mesmo ProjectDefinition

EXTERNAL
UserId
    │
    ▼
Authentication.User
    └── entidade pertencente a outro sistema

Uma referência externa:

• mantém a propriedade escalar, por exemplo UserId;
• não gera FK local no Entity Framework;
• não gera navigation property local;
• não executa Include() para a entidade externa;
• não tenta resolver a entidade externa dentro do ProjectDefinition local;
• não deve obrigar a API gerada a conhecer o modelo interno do provider externo.

Exemplo:

"HouseholdMember"
Id UUID PRIMARY KEY
HouseholdId UUID NOT NULL REFERENCES Household(Id)
UserId UUID NOT NULL REFERENCES EXTERNAL Authentication.User(Id)
Role VARCHAR(50) NOT NULL DEFAULT 'MEMBER'
UNIQUE (HouseholdId, UserId)
;

Nesse exemplo:

HouseholdId -> relacionamento local
UserId      -> referência externa

---

Entidades e campos

A DSL suporta, entre outros:

PRIMARY KEY
NOT NULL
NULL
UNIQUE
DEFAULT
REFERENCES
REFERENCES EXTERNAL
VARCHAR(length)
NUMERIC(precision, scale)
UUID
TIMESTAMP
BOOLEAN
INT
TEXT

Exemplo:

"Transaction"
Id UUID PRIMARY KEY
Amount NUMERIC(15,2) NOT NULL
Description VARCHAR(255) NOT NULL
TransactionDate TIMESTAMP NOT NULL
IsRecurring BOOLEAN NOT NULL DEFAULT FALSE
Notes TEXT
;

---

Constraints

Constraint composta:

UNIQUE (HouseholdId, UserId)

Outro exemplo:

UNIQUE (HouseholdId, Year, Month)

Esses metadados pertencem ao modelo do domínio e devem ser propagados pelo gerador.

---

Metadados de apresentação

O definitions.txt também pode carregar metadados utilizados por outros geradores.

Exemplo de i18n:

Name VARCHAR(150) NOT NULL
@i18n en-US label="Name"
@i18n pt-BR label="Nome"
@i18n es-ES label="Nombre"

Entidade:

"Category"
@i18n en-US singular="Category" plural="Categories"
@i18n pt-BR singular="Categoria" plural="Categorias"
@i18n es-ES singular="Categoría" plural="Categorías"

---

Metadados de filtros e analytics

Exemplos:

TransactionDate TIMESTAMP NOT NULL
@filter kind="date-range" default="CURRENT_MONTH"
@analytics role="time"
@dashboard primaryDate=true

Amount NUMERIC(15,2) NOT NULL
@analytics role="measure" aggregate="sum"

CategoryId UUID NULL REFERENCES Category(Id)
@filter kind="relation"
@analytics role="dimension"

O backend continua genérico: esses dados são metadados declarativos.

---

CQRS

Escrita:

HTTP POST
    │
    ▼
CreateEntityCommand
    │
    ▼
CreateEntityCommandHandler
    │
    ▼
Repository
    │
    ▼
Persistence

Consulta:

HTTP GET
    │
    ▼
GetEntityByIdQuery
    │
    ▼
GetEntityByIdQueryHandler
    │
    ▼
Repository
    │
    ▼
DTO

---

OpenAPI

O OpenAPI é derivado do backend gerado:

definitions.txt
       │
       ▼
ProjectDefinition
       │
       ▼
.NET Backend
       │
       ▼
OpenAPI

Quando existe Authentication externa, o OpenAPI da API de domínio pode publicar o esquema Bearer correspondente.

Em um fluxo full-stack:

definitions.txt
       │
       ▼
Backend MCP
       │
       ▼
Domain OpenAPI
       │
       ├──────────────┐
       │              │
Authentication OpenAPI
                      │
                      ▼
              Frontend Generator
                      │
                      ▼
                    React

---

Estrutura da solução gerada

Exemplo:

src/
├── Project.Domain/
│   ├── Entities/
│   ├── ValueObjects/
│   └── Shared/
│
├── Project.Application/
│   ├── Common/
│   └── Features/
│       └── Entity/
│           ├── Commands/
│           ├── Queries/
│           ├── Dtos/
│           ├── Validators/
│           └── Mappers/
│
├── Project.Infrastructure/
│   ├── Persistence/
│   ├── Repositories/
│   └── DependencyInjection/
│
└── Project.Api/
    ├── Controllers/
    ├── Configuration/
    └── OpenApi/

tests/
└── ...

---

Configuração depois da geração

Alguns valores pertencem ao ambiente e não devem ser hardcoded no MCP.

Banco relacional

Exemplo:

{
  "ConnectionStrings": {
    "DefaultConnection": "Host=localhost;Port=5432;Database=SampleDb;Username=sample_app;Password=..."
  }
}

Authentication externa

Exemplo:

{
  "Authentication": {
    "Mode": "External",
    "Provider": "OPENAPI",
    "Scheme": "BEARER",
    "Issuer": "DSC.API.Authentication",
    "Audience": "sample-api"
  }
}

A chave de assinatura deve ser fornecida por mecanismo seguro, por exemplo:

dotnet user-secrets set "Authentication:Key" "<valor>"

Nunca versione secrets reais no appsettings.json.

---

Configurando JWT com Authentication externa

Quando o projeto utiliza:

AUTHENTICATION EXTERNAL
PROVIDER OPENAPI
SCHEME BEARER
ISSUER "DSC.API.Authentication"
AUDIENCE "sample-api"
;

a API de domínio valida tokens emitidos pelo servidor externo de Authentication.

Para validação com JWT/HMAC, três valores precisam estar alinhados entre quem emite e quem valida o token:

Issuer
Audience
Key

Conceitualmente:

Authentication API
    Issuer   = DSC.API.Authentication
    Audience = dsc-oikos-api
    Key      = K

              JWT
               │
               ▼

API de domínio
    Issuer   = DSC.API.Authentication
    Audience = dsc-oikos-api
    Key      = K

Issuer

Issuer identifica quem emitiu o token.

Exemplo:

{
  "Authentication": {
    "Issuer": "DSC.API.Authentication"
  }
}

O valor configurado na API de domínio deve ser compatível com o iss emitido no JWT.

Audience

Audience identifica para qual API o token foi emitido.

Exemplo para Oikos:

{
  "Authentication": {
    "Audience": "dsc-oikos-api"
  }
}

O valor precisa corresponder ao aud do token.

Projetos diferentes podem utilizar audiences diferentes.

Gerando uma Key

Para HS256, gere uma chave aleatória suficientemente forte.

Exemplo em PowerShell:

$keyBytes = New-Object byte[] 32
[System.Security.Cryptography.RandomNumberGenerator]::Fill($keyBytes)
$key = [Convert]::ToBase64String($keyBytes)

$key

O comando imprime uma chave que pode ser armazenada de forma segura.

Não versione a chave real no Git e não coloque secrets reais no definitions.txt.

Configurando a Key com user-secrets

Entre no projeto .Api gerado:

cd .\src\Project.Api

Inicialize user-secrets, caso o projeto ainda não tenha um UserSecretsId:

dotnet user-secrets init

Configure a chave:

dotnet user-secrets set "Authentication:Key" "<KEY>"

Confira:

dotnet user-secrets list

O .csproj deverá possuir um UserSecretsId depois da inicialização.

Exemplo:

<PropertyGroup>
  <UserSecretsId>...</UserSecretsId>
</PropertyGroup>

Configuração completa da API de domínio

Exemplo:

{
  "Authentication": {
    "Mode": "External",
    "Provider": "OPENAPI",
    "Scheme": "BEARER",
    "Issuer": "DSC.API.Authentication",
    "Audience": "dsc-oikos-api"
  }
}

A Key fica fora do arquivo:

dotnet user-secrets set "Authentication:Key" "<KEY>"

Em produção, utilize um mecanismo apropriado de secrets/environment variables em vez de user-secrets.

Regra importante sobre a Key

A API que emite o JWT e a API que valida o JWT precisam utilizar a mesma convenção de chave.

Na implementação atual baseada em HS256, a string configurada em Authentication:Key é utilizada como bytes UTF-8 para construir a SymmetricSecurityKey.

Portanto, se a chave foi gerada como uma string Base64:

abc123...=

a implementação atual utiliza os bytes UTF-8 dessa própria string.

Não faça Convert.FromBase64String() apenas no lado emissor ou apenas no lado consumidor. Isso produziria chaves criptográficas diferentes.

O contrato deve permanecer simétrico:

Authentication
Encoding.UTF8.GetBytes(Key)
          │
          ▼
       assinatura

       mesmo Key

          │
          ▼
API de domínio
Encoding.UTF8.GetBytes(Key)
          │
          ▼
       validação

Se futuramente o projeto adotar outra representação de chave, a mudança deve ser feita simultaneamente no emissor e no consumidor.

Configuração do Authentication

O servidor de Authentication também precisa utilizar valores compatíveis:

Issuer   = mesmo Issuer esperado pela API
Audience = audience da API de destino
Key      = mesma chave usada para validação

Para múltiplas APIs:

Authentication
      │
      ├── audience: dsc-oikos-api
      │       └── Oikos
      │
      ├── audience: dsc-crm-api
      │       └── CRM
      │
      └── audience: dsc-other-api
              └── Outra API

A arquitetura não deve hardcodar dsc-oikos-api no MCP. O valor é configuração do projeto/ambiente.

Diagnóstico de 401 Unauthorized

Quando uma API protegida responder 401 Unauthorized, confira nesta ordem:

1. Authorization: Bearer <token>
2. token ainda está válido
3. Issuer da API == iss do JWT
4. Audience da API == aud do JWT
5. Key do emissor == Key do consumidor
6. mesma convenção de encoding da Key
7. Authentication está registrado antes de Authorization
8. middleware UseAuthentication está ativo
9. endpoint/controller realmente utiliza o esquema esperado

Ao utilizar arquivos .http, não coloque aspas em volta do token.

Correto:

@accessToken = eyJ...

GET http://localhost:5000/api/v1/example
Authorization: Bearer {{accessToken}}

Evite:

@accessToken = "eyJ..."

As aspas passam a fazer parte do valor e podem invalidar o token.

Erro Authentication:Issuer nao configurado

Confirme que a configuração possui:

"Authentication": {
  "Issuer": "..."
}

e que o ambiente carregado pela aplicação é o esperado.

Erro Authentication:Audience nao configurado

Configure:

"Authentication": {
  "Audience": "..."
}

O valor precisa ser compatível com o token emitido.

Erro Authentication:Key nao configurada

Para desenvolvimento:

dotnet user-secrets set "Authentication:Key" "<KEY>"

Se aparecer:

Could not find the global property 'UserSecretsId'

execute no diretório do projeto .Api:

dotnet user-secrets init

e depois configure novamente a chave.

Checklist rápido

Antes de testar uma API gerada com Authentication externa:

[ ] Authentication API está executando
[ ] usuário consegue fazer login
[ ] JWT possui iss correto
[ ] JWT possui aud correto
[ ] API de domínio possui Issuer configurado
[ ] API de domínio possui Audience configurado
[ ] Authentication:Key está disponível via secret/environment
[ ] emissor e consumidor usam a mesma Key
[ ] API de domínio compila e inicia
[ ] endpoint protegido recebe Authorization: Bearer

---

Build do projeto gerado

Após a geração:

cd <pasta-do-projeto-gerado>
dotnet build

Depois, se aplicável:

dotnet run --project .\src\Project.Api\Project.Api.csproj

Para EF Core:

dotnet ef migrations add InitialCreate --project .\src\Project.Infrastructure --startup-project .\src\Project.Api --output-dir Migrations

e:

dotnet ef database update --project .\src\Project.Infrastructure --startup-project .\src\Project.Api

---

Fluxo recomendado de desenvolvimento

Para alterar uma característica estrutural de projetos gerados:

1. NÃO corrigir manualmente apenas o projeto gerado
2. identificar a limitação no MCP
3. evoluir Definitions / Parser / Canonical Model
4. evoluir os templates
5. compilar o MCP
6. gerar um projeto do zero
7. compilar o projeto gerado
8. validar OpenAPI
9. validar runtime

A regra principal é:

corrigir o gerador, não o resultado gerado.

---

Projeto Debug

Durante o desenvolvimento do MCP, um executável de Debug pode chamar o gerador diretamente.

Exemplo:

var backend =
    new McpBackEnd();

var result =
    await backend.GenerateAsync(
        backendRoot,
        definitionsFile);

Console.WriteLine(result);

Isso permite validar rapidamente:

• parser;
• geração completa;
• regressões;
• templates;
• build de projetos gerados.

---

Idempotência e atualização incremental

O MCP atualmente deve ser tratado principalmente como gerador orientado ao modelo.

A evolução planejada é permitir que ele também funcione como um updater/migrator inteligente, capaz de:

projeto existente
      +
definitions.txt atualizado
      │
      ▼
detecção de diferenças
      │
      ▼
mudanças incrementais
      │
      ├── preservar customizações
      ├── adicionar novos artefatos
      ├── atualizar artefatos gerenciados
      └── evitar regeneração destrutiva

Até que esse mecanismo esteja implementado e validado, não assuma que uma regeneração sobre um projeto customizado preservará alterações manuais.

---

Princípios do projeto

Uma única fonte de verdade

definitions.txt

é a fonte declarativa principal do domínio.

Geração determinística

A mesma definição deve produzir estruturalmente o mesmo backend.

Separação de responsabilidades

Parsing
   ↓
Canonical Model
   ↓
Generation

Contratos explícitos

Relacionamentos, nullability, defaults, constraints, referências externas e metadados devem existir como dados estruturados.

Independência dos geradores

Os geradores consomem o modelo canônico e não reinterpretam a DSL por conta própria.

Sem hardcode de domínio

O MCP não deve conter regras específicas para Oikos, Household, User, Authentication ou qualquer outro domínio concreto.

Exemplos concretos podem existir em documentação e testes, mas não devem determinar o comportamento do gerador.

---

Objetivo

O objetivo do DSC.Tech.SmartDependencies é permitir que uma definição relativamente pequena:

definitions.txt

seja suficiente para produzir uma base consistente e reproduzível para uma aplicação .NET completa:

Domain
+
Application
+
Infrastructure
+
REST API
+
Persistence
+
Tests
+
OpenAPI

com suporte a evolução arquitetural sem perder o princípio central:

o comportamento do sistema deve ser dirigido pelo modelo, e não por código específico de um projeto.

Como ele vai ser publicado como NuGet MCP, o fluxo que fechamos é este:

Na pasta do projeto que você quer gerar, crie .vscode/mcp.json: { "servers": { "dsc-smartdependencies": { "type": "stdio", "command": "dnx", "args": [ "diegoschagas.SmartDependencies@<VERSAO>", "--yes" ] } } }

Troque <VERSAO> pela versão que você publicou, por exemplo 0.1.4.

Na mesma raiz, tenha o definitions.txt. Abra essa pasta no VS Code e pressione: Ctrl + Shift + P

Procure:

MCP: List Servers

Deve aparecer:

dsc-smartdependencies Depois, no Copilot Agent, pode simplesmente pedir: Use o MCP dsc-smartdependencies para gerar o backend completo usando o definitions.txt deste projeto.

Ele deverá chamar a ferramenta generate_full_project.