用途：依据领域驱动设计（DDD）的通用语言原则，为项目维护一份活的领域术语表（默认 docs/THESAURUS.md），在命名任何东西之前先查阅它，确保代码、文档、API 与业务对话使用同一套词汇。
主要能力：提供三种模式——命名咨询（高频）、术语表生成（低频，见 references/generating-thesaurus.md）、命名审计（周期性，见 references/naming-audit.md）。术语条目格式包含定义、NOT（不表示什么）、应避免的同义词、相关术语；最小条目为定义加应避免的同义词。按 DDD 构件给出命名规则：聚合与聚合根用单数业务术语、实体用单数名词、值对象描述不可变概念、领域事件用过去式动词加名词、命令用祈使动词加名词、查询用 Get/Find/List 等、领域服务按业务活动命名、仓储可用 Repository 后缀。同时检测并标记命名反模式：Manager、Service、Handler、Info、Data、Item、Base、Util 等模糊词，领域层中的技术术语（Mongo、Sql、Http、Dto、Entity），同义词漂移，缩写边界，以及跨需求、规格、代码的翻译链信息丢失。
使用方式：先定位术语表（用户指定路径、仓库中已有的 THESAURUS.md，否则默认 docs/THESAURUS.md）；命名前先读，若已有合适术语则直接使用；若概念是新的，依次尝试复用、组合、限定、询问四种手段，仍无法确定则记为 [WHITE-SPOT] 放入 Unresolved，不强行造名；确需新增时按不变量命名、保持最小通用性、控制在 1-3 个词，并写入术语表。发现代码与术语表冲突时标记并建议重命名，大规模重命名作为技术债询问用户。
适用场景：需要统一领域词汇的代码库，尤其是命名频繁、跨团队协作或存在遗留命名的项目。
限制：术语表描述概念而非行为，不能替代业务规则规格；对尚未实现的领域，关键知识可能只存在于专家头脑中；非英语业务领域应使用原语言作为规范术语。资料未提供具体安装命令、收费与平台信息。