一个智能 MCP（模型上下文协议）服务器，使用混合搜索（语义 + 关键词 + 图增强）提供设计模式推荐。通过自然语言界面访问 710 种设计模式，涵盖 90 多个类别，采用先进的混合 RAG 架构。
# Clone and setup
git clone https://github.com/apolosan/design_patterns_mcp.git
cd design_patterns_mcp
# Install dependencies and build (using bun)
bun install
bun run db:setup
# Or using npm (if bun is not installed)
npm install --ignore-scripts
npx tsc
node dist/cli/migrate.js
node dist/cli/seed.js
node dist/cli/generate-embeddings.js
node dist/cli/setup-relationships.js在您的 MCP 客户端（Claude Desktop、Cursor 等）中进行配置，即可通过自然语言查询开始发现模式。
Related MCP server: Acemcp
使用 Bun 作为本仓库的规范包管理器（仅 bun install）。锁文件为 bun.lock。
切勿将 .git 目录复制到 dist/data 中（或将其打包进 dist/）。该路径必须保持为纯数据目录，以避免产生数 GB 级的镜像和元数据泄漏。
功能 | 描述 |
混合搜索引擎 | 结合语义、关键词（BM25）和图增强的混合 RAG 检索 |
710 种模式 | 涵盖 90 多个类别的综合模式目录，包括功能开关 / 功能切换，用于渐进式交付和实验 |
MCP 集成 | 与 Claude、Cursor 及其他 MCP 客户端无缝集成 |
多级缓存 | L1 内存缓存 + L3 SQLite 缓存，命中率 95% 以上 |
事件总线系统 | 通过发布/订阅实现解耦的服务通信 |
遥测与健康检查 | 实时性能指标与系统监控 |
SOLID 架构 | 遵循最佳实践的干净、可维护代码库 |
生产就绪 | 77 个测试文件中的 654 个测试用例，100% 通过率（0 失败，0 跳过） |
类别 | 数量 | 示例 |
经典 GoF 模式 | 34 | 工厂、建造者、观察者、策略、命令 |
架构模式 | 56 | MVC、整洁架构、六边形架构、DDD、功能开关 |
微服务与云 | 39 | 断路器、Saga 事务、服务网格 |
数据工程 | 54 | 仓库模式、CQRS、事件溯源 |
AI/ML 与 MLOps | 46 | RAG、微调、模型压缩 |
React 模式 | 27 | Hooks、服务端组件、性能优化 |
区块链与 Web3 | 115 | DeFi、NFT、智能合约、MEV |
并发与响应式 | 45 | 生产者-消费者、Actor 模型 |
安全 | 21 | OAuth、RBAC、零信任 |
函数式编程 | 26 | 单子、函子、高阶函数 |
src/
├── adapters/ # External service adapters (LLM, embeddings)
├── cli/ # CLI commands (migrate, seed, embeddings, setup-relationships)
├── core/ # DI Container, configuration builder
├── db/ # Database migrations
├── events/ # Event bus system
├── handlers/ # MCP request handlers (hybrid search, recommendations)
├── health/ # Health check services
├── repositories/ # Data access layer
├── search/ # Hybrid search engine
├── services/ # Business services (cache, telemetry, pattern service)
├── strategies/ # Strategy pattern implementations
├── types/ # TypeScript type definitions
└── mcp-server.ts # MCP server entry point
data/
├── patterns/ # 710 JSON pattern definitions (see `feature-flag.json`)
└── design-patterns.db # SQLite database with 710 patterns and embeddings通过您的 MCP 客户端使用自然语言提问：
"I need to create complex objects with many optional configurations"
→ Builder, Abstract Factory, Factory Method
"How to handle service failures gracefully in distributed systems?"
→ Circuit Breaker, Bulkhead, Retry, Fallback
"What pattern helps with state-dependent behavior in React?"
→ State Machine, Observer, useReducer
"How to implement secure authentication and authorization?"
→ OAuth 2.0, RBAC, JWT, Zero Trust工具 | 描述 |
| 使用问题描述进行混合搜索查找模式 |
| 带过滤条件的关键词或语义搜索 |
| 获取包含代码示例的完整模式信息 |
| 可用模式的统计信息 |
| 系统健康与服务状态 |
Node.js >= 18.0.0
Bun >= 1.0.0（推荐）或 npm >= 8.0.0
bun install
bun run build
bun run db:setuppackage.json 中的 prepare 脚本需要 bun。如果您未安装 bun，请使用 --ignore-scripts 跳过该脚本并手动构建：
npm install --ignore-scripts
npx tsc
# Setup database
node dist/cli/migrate.js
node dist/cli/seed.js
node dist/cli/generate-embeddings.js
node dist/cli/setup-relationships.js在您的 MCP 客户端配置中添加（Claude Desktop、Cursor 等）：
{
"mcpServers": {
"design-patterns": {
"command": "node",
"args": ["/absolute/path/to/design-patterns-mcp/dist/mcp-server.js"],
"env": {
"LOG_LEVEL": "info",
"DATABASE_PATH": "/absolute/path/to/design-patterns-mcp/data/design-patterns.db",
"ENABLE_HYBRID_SEARCH": "true",
"ENABLE_GRAPH_AUGMENTATION": "true",
"EMBEDDING_COMPRESSION": "true",
"ENABLE_FUZZY_LOGIC": "true",
"ENABLE_TELEMETRY": "true",
"ENABLE_MULTI_LEVEL_CACHE": "true"
}
}
}
}重要提示： 请为
args和DATABASE_PATH使用绝对路径。像 Cursor 这样的 MCP 客户端不能可靠地支持cwd字段，因此相对路径会相对于用户的主目录解析，而不是项目目录。有关客户端特定的配置示例，请参阅项目快速入门指南。
变量 | 默认值 | 描述 |
|
| 日志级别（debug、info、warn、error） |
|
| SQLite 数据库路径 |
|
| 启用混合 RAG 搜索 |
|
| 启用模式关系图遍历增强 |
|
| 启用维度缩减 |
|
| 启用模糊逻辑结果优化 |
|
| 启用性能指标收集 |
|
| 启用 L1 + L3 多级缓存 |
|
| 最大并发请求数 |
|
| 缓存大小上限 |
|
| 缓存生存时间（毫秒） |
|
| 传输模式（stdio/http） |
|
| HTTP 端口（HTTP 模式） |
|
| MCP 端点路径 |
|
| 健康检查路径 |
|
| 跳过数据库初始化 |
# Build
docker build -t design-patterns-mcp .
# Run HTTP mode
docker run -p 3000:3000 -e TRANSPORT_MODE=http design-patterns-mcp
# Run stdio mode (default)
docker run design-patterns-mcpdocker compose up --build -d变量 | 默认值 | 描述 |
|
| 传输模式（stdio/http） |
|
| HTTP 端口（HTTP 模式） |
|
| MCP 端点路径 |
|
| 健康检查路径 |
|
| SQLite 数据库路径 |
|
| 日志级别 |
|
| 跳过数据库初始化 |
GET /health — 健康检查
POST /mcp — MCP JSON-RPC 端点
# Development
bun run build # Compile TypeScript
bun run dev # Development with hot reload
bun run start # Build and start production server
# Database
bun run db:setup # Complete database setup
bun run migrate # Run migrations
bun run seed # Seed pattern data
bun run generate-embeddings # Generate semantic embeddings
bun run setup-relationships # Setup pattern relationships
# Quality
bun run test # Run all tests
bun run lint # Check code quality
bun run lint:fix # Auto-fix linting issues
bun run typecheck # TypeScript type checking项目包含 77 个测试文件中的 654 个测试用例，100% 通过率（0 失败，0 跳过）：
契约测试：MCP 协议合规性验证
集成测试：针对实时 SQLite 数据库和嵌入向量的组件交互测试
性能测试：搜索和向量化基准测试
单元测试：单个组件测试
# Run all tests
bun run test
# Run specific test suites
bun run test:unit -- --grep "PatternService"
bun run test:integration -- --grep "database"
bun run test:performance -- --timeout 30000本项目实现了其自身所记录的模式：
模式 | 实现位置 |
仓库模式 |
|
服务层 |
|
对象池 |
|
依赖注入 |
|
策略模式 |
|
事件总线 |
|
多级缓存 |
|
建造者模式 |
|
服务器使用 sql.js（SQLite WASM）配合内存余弦相似度对存储的嵌入向量进行计算。原生 sqlite-vec（vec0 虚拟表）在此运行时中不可用。语义搜索适用于当前目录规模（约 710 种模式），但不使用索引化的原生向量表。
仅在您拥有真实提供商集成时才启用 LLM 增强功能——内置的 LLM 桥接提供商在未扩展的情况下返回占位符。
欢迎贡献！请参阅贡献指南。
Fork 本仓库
创建功能分支
遵循 SOLID 原则进行修改
运行测试和代码检查
提交拉取请求
规范版本号从 0.7.1 → 0.7.2 更新，涉及所有活跃的源文件和文档文件。
更新的文件：package.json、src/mcp-server.ts（服务器注册 + 运行时信息）、AGENTS.md、CLAUDE.md（规范标识头）、README.md（徽章、发布说明章节、版本页脚）、CHANGELOG.md（新条目）。docs/IMPROVEMENTS_03.md 和 QUICKSTART.md 中的审计证据引用按状态 #45 保持不变。
修正了过时的版本引用：AGENTS.md 和 CLAUDE.md 头部 (version 0.6.0) → (version 0.7.2)（落后于实际 package.json 7 个次要版本）。
运行时自报告现在通过 Server 构造函数和 /info 端点向 MCP 客户端通告 0.7.2。
无代码级行为变更：纯发布/版本规范化补丁。
测试：完整测试套件保留（未修改任何测试文件），类型检查通过。
测试套件已全面验证：654/654 通过，0 跳过，0 待办（此前为 651/654，存在 3 个预先存在的偶发失败）。
解决了 db:setup 流水线引入的 data/.git 泄漏问题（data-hygiene 测试）。
将两个过时的测试与 BUG-007 契约 对齐：snake_case 的 search_type 会被 validateSearchPatternsArgs 静默忽略，并应用规范的默认 hybrid 策略。
tests/unit/input-validation.test.ts
tests/unit/mcp-server-search.test.ts
已修正 README.md 版本漂移：尾部块现在反映规范的 0.7.0 → 0.7.1 基线，徽章 + Production Ready + Testing 部分与当前 654 个测试套件保持一致。
Lint 基线已恢复：0 个问题，退出码 0（此前为 2 个错误 + 6 个警告）。
移除了 src/mcp/http-transport.ts 中未使用的 HealthStatus 导入。
在 src/health/embedding-coverage-health-check.ts 的同步 check() 上为 require-await 添加了针对性的 eslint-disable（保留了接口一致性）。
重构了 src/handlers/keyword-search-handler.ts 中的 ensureBM25()，使其返回 BM25Scorer，消除了调用点的 4 个非空断言。
将 tests/unit/bm25-scorer.test.ts 中 results.find() 的 2 个非空断言替换为显式的 toBeDefined 守卫。
bun run typecheck 通过。
从 docs/01_Agentic_Design_Patterns.md 和 docs/02_Data_Engineering_Design_Patterns.md 添加了 24 个新设计模式：
3 个 Agentic AI：多智能体协作、目标设定与监控、异常处理与恢复。
21 个数据工程：Aligned Fan-In、Unaligned Fan-In、Bin Pack Orderer、Exclusive Choice、FIFO Orderer、Fine-Grained Accessor for Resources、Fine-Grained Accessor for Tables、Fine-Grained Tracker、In-Place Overwriter、Isolated Sequencer、Metadata Decorator、Metadata Enhancer、Offline Observer、Schema Compatibility Enforcer、Schema Migrator、Secretless Connector、Secrets Pointer、Single Runner、Skew Detector、SLA Misses Detector、Vertical Partitioner。
目录从 686 个模式增长到 710 个模式（Agentic AI：3→6，数据工程：4→25）。
完整性检查通过：710 个模式，151 个有效关系。
654/654 个测试通过（100% 通过，0 跳过，0 待办）。
MIT 许可证 - 详情请参阅 LICENSE。
向量搜索说明（sql.js 与 sqlite-vec）— 请参阅贡献指南
MCP 工具接口参考
文档索引
版本：0.7.2 最后更新：2026 年 8 月 模式：710 个 JSON 定义（亮点：Feature Flag / Feature Toggle） 测试：654 个测试用例 | 100% 通过率（0 失败，0 跳过）
另请参阅： 最新的对抗性质量保证报告（16 个发现：1 个严重，9 个高优先级，6 个次要）。发现涵盖搜索流水线正确性、配置漂移、传输安全性和文档同步。
Get the total number of design patterns in the database
| Name | Required | Description | Default |
|---|---|---|---|
| includeDetails | No | Include breakdown by category |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool 'Get[s] the total number', implying a read-only operation, but doesn't mention any behavioral traits such as performance considerations, error handling, or whether it's a simple count versus an aggregated query. For a tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any unnecessary words. It is appropriately sized and front-loaded, making it easy for an agent to parse quickly. Every part of the sentence earns its place by conveying essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one optional parameter) and high schema coverage, the description is adequate but has clear gaps. It lacks output schema information, usage guidelines, and behavioral context, which could help an agent use it correctly. However, for a simple counting tool, it meets the minimum viable threshold without being fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the parameter 'includeDetails' clearly documented in the schema. The description adds no additional meaning beyond what the schema provides, as it doesn't mention parameters at all. According to the rules, when schema_description_coverage is high (>80%), the baseline score is 3, which is appropriate here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Get') and resource ('total number of design patterns in the database'), making it easy to understand what it does. However, it doesn't explicitly differentiate from sibling tools like 'find_patterns' or 'search_patterns', which might also retrieve pattern information, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'find_patterns', 'get_pattern_details', or 'search_patterns'. It lacks any context about use cases, prerequisites, or exclusions, leaving the agent to infer usage based on the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find design patterns matching a problem description using semantic search
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Natural language description of the problem or requirements | |
| categories | No | Optional: Pattern categories to search in | |
| maxResults | No | Maximum number of recommendations to return | |
| programmingLanguage | No | Target programming language for implementation examples |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'semantic search' but doesn't explain what this entails—e.g., how results are ranked, whether it's a read-only operation, or any limitations like rate limits or authentication needs. For a tool with no annotation coverage, this leaves critical behavioral traits unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It is front-loaded with the core purpose ('Find design patterns...'), making it easy to understand at a glance. Every part of the sentence earns its place by conveying essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (semantic search with 4 parameters) and the absence of both annotations and an output schema, the description is insufficient. It doesn't cover behavioral aspects like result format, error handling, or how semantic search works, nor does it explain the relationship between parameters and outcomes. This leaves significant gaps for an AI agent to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, meaning all parameters are documented in the schema itself. The description adds no additional meaning beyond the schema, such as explaining the 'semantic search' process in relation to the 'query' parameter or how 'categories' affect results. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, but no extra value is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Find design patterns matching a problem description using semantic search.' It specifies the verb ('Find'), resource ('design patterns'), and method ('semantic search'), making the intent unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'search_patterns' or 'count_patterns,' which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'search_patterns' and 'count_patterns' available, it fails to indicate scenarios where this tool is preferred, such as for semantic versus keyword-based searches, or how it differs from 'get_pattern_details.' This lack of comparative context leaves the agent without clear usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific pattern
| Name | Required | Description | Default |
|---|---|---|---|
| patternId | Yes | Pattern ID to get details for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states it 'gets' information, implying a read-only operation, but doesn't disclose any behavioral traits such as error handling, permissions needed, rate limits, or what 'detailed information' includes. This is a significant gap for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any wasted words. It is appropriately sized and front-loaded, making it easy to understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'detailed information' entails, potential return values, or any behavioral context. For a tool with no structured data beyond the input schema, this leaves significant gaps in understanding its full functionality.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the parameter 'patternId' clearly documented. The description adds no additional meaning beyond what the schema provides, such as format examples or constraints. With high schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'detailed information about a specific pattern', which is specific and understandable. However, it doesn't differentiate from sibling tools like 'find_patterns' or 'search_patterns' that might also retrieve pattern information, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'find_patterns' or 'search_patterns'. It lacks context about whether this is for retrieving details of a known pattern ID versus searching for patterns, leaving usage unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search patterns by keyword or semantic similarity
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query | |
| searchType | No | hybrid | |
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions search functionality but fails to describe critical behaviors such as pagination, rate limits, authentication needs, or what happens on no matches. For a search tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at one sentence with zero waste, front-loading the core functionality. Every word earns its place, making it easy for an agent to parse quickly without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity as a search function with 3 parameters, no annotations, and no output schema, the description is incomplete. It lacks information on return values, error handling, and behavioral traits, leaving the agent with insufficient context to use the tool effectively beyond basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low at 33%, with only the 'query' parameter documented. The description adds value by explaining that searches can be by keyword or semantic similarity, which helps interpret the 'searchType' enum, but it doesn't clarify the 'limit' parameter or provide details beyond what the schema implies. This partial compensation justifies a baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as searching patterns using keyword or semantic similarity, which is specific and actionable. However, it doesn't explicitly distinguish this from sibling tools like 'find_patterns' or 'count_patterns', leaving some ambiguity about when to choose one over another.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'find_patterns' or 'count_patterns'. It mentions search methods but doesn't specify scenarios, prerequisites, or exclusions, leaving the agent to guess based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
count_patternsfind_patternsget_pattern_detailssearch_patternsScored across 4 tools
Multiple tools have overlapping purposes that could cause confusion. 'find_patterns' and 'search_patterns' both appear to search for patterns, with descriptions that are nearly identical ('semantic search' vs 'keyword or semantic similarity'), making them difficult to distinguish. 'count_patterns' and 'get_pattern_details' are clearer, but the overlap between the two search tools significantly reduces disambiguation.
All tool names follow a consistent verb_noun pattern with snake_case, such as 'count_patterns', 'find_patterns', 'get_pattern_details', and 'search_patterns'. This uniformity makes the tool set predictable and easy to understand, with no deviations in naming conventions.
With only 4 tools, the set feels thin for a server focused on design patterns, which typically involve operations like creating, updating, or categorizing patterns. While basic retrieval functions are covered, the low count may limit functionality for more complex agent tasks, placing it in the borderline range for appropriateness.
The tool set is severely incomplete for a design patterns domain, as it only supports read operations (counting, searching, and getting details) with no ability to create, update, delete, or manage patterns. This lack of CRUD coverage creates significant gaps that will likely cause agent failures when trying to perform full lifecycle tasks.
Code intelligence for coding agents: semantic, AST, graph, and full-text search. 279+ languages.
Code intelligence platform for AI agents. 20 tools for architecture, security & impact analysis.
AI Agent with Architectural Memory. Impact analysis (free), tests and code from the graph (pro).
295k+ bug-fix patterns with MCP Hub proxy, PII filtering, and code search
