@ds9-solutions/mcp 0.2.0 → 0.4.0

package/content/skills/mysql/SKILL.md

@@ -1,94 +0,0 @@
----
-name: mysql
-description: Diretrizes de modelagem, indexação, migrations, performance e segurança para bancos MySQL/MariaDB usados pelos projetos DS9. Use ao criar/alterar tabelas, escrever migrations, definir índices, revisar queries lentas, ou quando o usuário pedir "schema MySQL", "migration", "índice" ou "otimizar query".
----
-
-# MySQL — Diretrizes DS9
-
-Convenções obrigatórias para schema, queries e migrations em MySQL (compatível com MariaDB), usadas com a camada de persistência do projeto.
-
-## Engine e charset
-
-- Engine padrão: `InnoDB` (suporta transações e FKs). Nunca usar `MyISAM` para tabelas transacionais.
-- Charset/collation padrão: `utf8mb4` / `utf8mb4_unicode_ci` (ou `utf8mb4_0900_ai_ci` em MySQL 8+). Nunca `utf8` puro (não suporta 4 bytes/emojis).
-
-## Convenções de nomenclatura
-
-- Tabelas: `snake_case`, plural (`orders`, `order_items`).
-- Colunas: `snake_case` (`created_at`, `customer_id`).
-- Chave primária: `id` (`BIGINT UNSIGNED AUTO_INCREMENT` ou `CHAR(36)`/`BINARY(16)` para UUID — definir por projeto e manter consistente).
-- Chave estrangeira: `<tabela_singular>_id` (`customer_id` referenciando `customers.id`).
-- Índices: `idx_<tabela>_<colunas>`; únicos: `uq_<tabela>_<colunas>`; FKs: `fk_<tabela>_<tabela_referenciada>`.
-
-## Colunas obrigatórias
-
-Toda tabela transacional deve ter:
-
-```sql
-created_at DATETIME(3) NOT NULL DEFAULT CURRENT_TIMESTAMP(3),
-updated_at DATETIME(3) NOT NULL DEFAULT CURRENT_TIMESTAMP(3) ON UPDATE CURRENT_TIMESTAMP(3),
-deleted_at DATETIME(3) NULL          -- se o domínio usa soft delete
-```
-
-- Use `DATETIME` (não `TIMESTAMP`) para evitar o limite de ano 2038 e problemas de fuso; grave sempre em UTC na aplicação.
-- Nunca armazene datas/horas como `VARCHAR`.
-
-## Tipos de dados
-
-- Dinheiro/valores monetários: `DECIMAL(19,4)` (nunca `FLOAT`/`DOUBLE`).
-- Texto curto com tamanho conhecido: `VARCHAR(n)` com `n` justificado pelo domínio (evitar `VARCHAR(255)` por padrão sem pensar).
-- Texto longo: `TEXT`/`LONGTEXT` apenas quando necessário (impacta performance de index/row size).
-- Enums de domínio fixo e pequeno: `VARCHAR` + `CHECK` constraint (MySQL 8.0.16+) ou tabela de referência; evite `ENUM` nativo do MySQL (dificulta `ALTER` e não é portável).
-- Booleanos: `TINYINT(1)` (convenção do MySQL; mapeie como `boolean` na aplicação).
-- JSON: tipo nativo `JSON` apenas para dados verdadeiramente semiestruturados, nunca para modelar relações que deveriam ser colunas/tabelas.
-
-## Índices
-
-- Toda FK **precisa** de índice (MySQL não cria automaticamente para colunas de FK em alguns casos — sempre declare explicitamente).
-- Índices compostos: ordem das colunas segue o padrão de consulta (coluna de igualdade antes de coluna de range/order).
-- Evite índices redundantes (um índice composto `(a, b)` já cobre buscas por `a` sozinho).
-- Toda query de produção recorrente deve ter `EXPLAIN` validado antes do merge — sem `type: ALL` (full table scan) em tabelas grandes.
-- Use índice único (`UNIQUE KEY`) para garantir invariantes de negócio no banco (ex.: `email` único), nunca confie só em validação da aplicação.
-
-## Migrations
-
-- Toda alteração de schema é uma migration versionada (via o mecanismo de migrations do projeto), nunca alteração manual direto no banco de produção.
-- Migrations são **imutáveis** após merge/deploy: para corrigir, crie uma nova migration (nunca edite uma já aplicada em outro ambiente).
-- Toda migration precisa de `up` e `down` reversível. Se o `down` não for possível com segurança (ex.: `DROP COLUMN`), documente explicitamente no corpo da migration.
-- Alterações em tabelas grandes (`ADD COLUMN`, `ADD INDEX`) em produção devem considerar lock de tabela: preferir `ALGORITHM=INPLACE, LOCK=NONE` quando suportado, e avaliar janela de manutenção para tabelas muito grandes.
-- Nunca faça `DROP TABLE`/`DROP COLUMN` na mesma migration que ainda está em uso por código em produção (deploy em etapas: parar de usar → migration de remoção).
-
-## Transações
-
-- Operações que alteram múltiplas tabelas com invariantes relacionadas (ex.: criar pedido + baixar estoque) **devem** rodar em uma transação explícita.
-- Nível de isolamento padrão do InnoDB é `REPEATABLE READ`; use `SELECT ... FOR UPDATE` quando precisar de lock pessimista para evitar race conditions em concorrência (ex.: controle de estoque, saldo).
-- Mantenha transações curtas: nunca faça chamadas de rede (HTTP, fila) dentro de uma transação de banco aberta.
-
-## Queries
-
-- Nunca concatene valores de usuário diretamente em SQL — sempre use *prepared statements*/query builder parametrizado (via a biblioteca de acesso a dados do projeto). Isso é mandatório contra SQL Injection.
-- Evite `SELECT *`; liste as colunas necessárias, especialmente em tabelas largas.
-- Pagine toda listagem (`LIMIT`/`OFFSET` ou keyset pagination para datasets grandes); nunca retorne uma tabela inteira sem limite.
-- Prefira keyset pagination (`WHERE id > :lastId ORDER BY id LIMIT :n`) a `OFFSET` alto em tabelas grandes (OFFSET grande é O(n)).
-
-## Segurança e acesso
-
-- Usuário da aplicação nunca deve ter privilégio `SUPER`, `GRANT OPTION` ou DDL (`CREATE`/`DROP`/`ALTER`) em produção — apenas `SELECT`, `INSERT`, `UPDATE`, `DELETE` nas tabelas do próprio schema. Migrations rodam com usuário/privilégio separado (pipeline de deploy).
-- Nunca commitar credenciais de conexão; usar variáveis de ambiente/secret manager (ver README do MCP).
-- Dados sensíveis (PII, senha, token) nunca em texto plano: hash (ex.: `bcrypt`/`argon2`) para senha, criptografia em nível de aplicação para PII quando exigido por compliance.
-
-## Checklist ao revisar schema/migration/query
-
-1. Engine `InnoDB`, charset `utf8mb4`?
-2. Nomenclatura `snake_case` consistente e FKs com índice?
-3. Tipos corretos (`DECIMAL` para dinheiro, sem `ENUM` nativo, sem `VARCHAR` para datas)?
-4. Migration tem `up`/`down`, é aditiva/segura para produção?
-5. Query usa parâmetros (sem concatenação), tem `LIMIT`, e passou por `EXPLAIN`?
-6. Alterações concorrentes têm transação e/ou lock explícito quando necessário?
-
-## Não fazer
-
-- Não usar `SELECT *` em código de produção.
-- Não usar `FLOAT`/`DOUBLE` para valores monetários.
-- Não rodar DDL manual direto em produção fora de migration versionada.
-- Não deixar queries sem paginação em endpoints de listagem.

package/content/skills/typescript/SKILL.md

@@ -1,75 +0,0 @@
----
-name: typescript
-description: Convenções de TypeScript da DS9 — tipagem estrita, modelagem de domínio, tratamento de erros, imports e estilo de código. Use ao escrever ou revisar qualquer código TypeScript (independente de framework), definir tipos/interfaces, ou quando o usuário pedir "tipagem", "strict mode" ou "boas práticas TypeScript".
----
-
-# TypeScript — Diretrizes DS9
-
-Convenções de código TypeScript aplicáveis a qualquer projeto da empresa, incluindo os que seguem arquitetura hexagonal em geral.
-
-## Configuração do compilador
-
-- `strict: true` obrigatório no `tsconfig.json` (ativa `strictNullChecks`, `noImplicitAny`, etc.). Não desative flags de strict mode isoladamente sem justificativa documentada.
-- `noUnusedLocals` e `noUnusedParameters` ativados — código morto não compila.
-- `noImplicitReturns` e `noFallthroughCasesInSwitch` ativados para evitar bugs de controle de fluxo.
-
-## Tipagem
-
-- Proibido `any` explícito em código novo. Quando o tipo é genuinamente desconhecido (ex.: payload externo não tipado), use `unknown` e faça *narrowing* explícito antes de usar.
-- Prefira `interface` para formas de objeto/contratos públicos (ports, DTOs) e `type` para unions, intersections e tipos utilitários.
-- Nunca use type assertion (`as Tipo`) para "calar" o compilador sem validação real; prefira type guards (`function isOrder(x: unknown): x is Order`).
-- Habilite e respeite `readonly` em propriedades que não devem mudar após criação (especialmente em entidades de domínio e DTOs).
-
-```typescript
-// Evitar
-function handle(payload: any) { return payload.items.map((i: any) => i.id); }
-
-// Preferir
-interface OrderPayload { items: Array<{ id: string }>; }
-function handle(payload: OrderPayload) { return payload.items.map((i) => i.id); }
-```
-
-## Modelagem de domínio
-
-- Use *value objects* para conceitos com regras próprias (ex.: `Email`, `Money`), em vez de `string`/`number` soltos, quando o projeto já segue esse padrão.
-- Invariantes de negócio são validadas no construtor/factory da entidade (`Order.create(...)`), lançando erro de domínio em vez de permitir estado inválido existir.
-- Prefira classes/funções imutáveis (métodos retornam uma nova instância) para entidades de domínio sensíveis a concorrência, salvo quando o projeto adota mutação controlada por padrão.
-
-## Tratamento de erros
-
-- Erros de domínio são classes que estendem `Error`, com nome específico (`class OrderNotFoundError extends Error`), nunca `throw` de string ou objeto genérico (`throw 'erro'` é proibido).
-- Nunca capture um erro (`catch`) só para logar e relançar sem adicionar contexto; se não for tratar, deixe propagar.
-- Funções assíncronas que podem falhar previsivelmente (ex.: "não encontrado") devem deixar isso explícito no tipo de retorno (`Promise<Order | null>`) quando fizer sentido, em vez de forçar o chamador a sempre usar `try/catch`.
-
-## Imports e organização de módulos
-
-- Imports absolutos/com alias (`@app/domain/...`) para cruzar camadas, imports relativos (`./`, `../`) dentro do mesmo módulo/camada — configurar via `paths` no `tsconfig.json`.
-- Nunca import circular entre módulos; se ocorrer, é sinal de fronteira de módulo mal definida (revisar a organização dos módulos).
-- Um export principal por arquivo quando possível (facilita navegação e testes); evite arquivos "barril" (`index.ts`) gigantes que reexportam dezenas de símbolos sem necessidade.
-
-## Nulidade e valores opcionais
-
-- Prefira `T | null` para "ausência de valor conhecida" e `T | undefined`/parâmetro opcional (`param?: T`) para "valor não fornecido". Seja consistente dentro do mesmo módulo.
-- Nunca use `!` (non-null assertion) para contornar `strictNullChecks` sem uma garantia real logo acima no código (ex.: dentro de um `if` que já checou).
-
-## Nomenclatura
-
-- Classes/interfaces/tipos: `PascalCase`. Variáveis/funções: `camelCase`. Constantes verdadeiramente globais/imutáveis: `UPPER_SNAKE_CASE`.
-- Nomes de função descrevem a ação (`calculateTotal`, não `total` ou `doIt`); booleanos começam com `is`/`has`/`should` (`isValid`, `hasDiscount`).
-- Evite abreviações não óbvias (`qty` ok se for convenção do domínio; `tmp`, `data2` não).
-- Nome de **arquivo**: `kebab-case`, com sufixo que indica o papel do arquivo quando aplicável (`order-repository.port.ts`, `create-order.use-case.ts`, `order.repository.ts`, `order.entity.ts`, `order.controller.ts`, `order.module.ts`). Arquivo de teste usa o mesmo nome base + `.spec.ts`/`.e2e-spec.ts` (seguindo a convenção de testes do projeto).
-
-## Checklist ao escrever/revisar código TypeScript
-
-1. Existe algum `any` que poderia ser `unknown` + narrowing, ou um tipo concreto?
-2. Erros são classes nomeadas, não strings/objetos genéricos?
-3. Nenhum `as Tipo`/`!` sem uma garantia lógica imediatamente visível?
-4. Nomes de variáveis/funções comunicam intenção sem precisar ler a implementação?
-5. O `tsconfig.json` do projeto mantém `strict: true` e nenhuma flag de strict foi desabilitada pontualmente?
-
-## Não fazer
-
-- Não usar `any` em código novo.
-- Não usar `// @ts-ignore` para silenciar erro de tipo sem comentário explicando o motivo e um plano de correção.
-- Não lançar (`throw`) valores que não sejam instância de `Error`.
-- Não criar imports circulares entre módulos/camadas.