TeaQL Agent Kit
用可执行领域模型约束编码代理，从需求走向可验证的类型化应用。
这个 Agent 能做什么，适合哪些场景？
TeaQL Agent Kit 是一套面向智能编码工作的模型中介式开发流程。它要求先将业务意图保存为 KSML 领域模型，再通过确定性评估获取错误、警告、建议和修复指引。验证后的模型可生成 Java 或 Rust 的类型化领域库与独立、可编辑的应用工作区，业务代码在生成的契约内实现。Skill 还提供面向当前模型的辅助信息，并将编译、测试、运行时和审计结果作为完成证据。它适合愿意采用 TeaQL 建模、生成与运行时治理体系的团队，而非通用的代码补全插件。
核心 Skill 名为 build-teaql-app。它先创建并保存 KSML XML 模型，描述业务对象、字段、常量、关系、模块和存储；随后调用模型评估，依据返回的 Errors、Warnings、Suggestions 与修复指导更新模型。模型通过后，TeaQL Generation Service 生成类型化实体、关系元数据、查询、空安全表达式、图持久化能力、检查器和行为钩子、仓库注册、文档，以及 Java 或 Rust 应用工作区。开发者在生成的 API 上实现业务逻辑，例如 Rust 中通过 Q::merchants() 构造查询，调用 purpose()、comment() 和 execute_for_list(&ctx)；最后以编译、测试、运行时和策略检查结果报告交付。
- 采用领域驱动设计的 Java 团队，需要先审核领域模型，再生成可再生的类型化业务边界。
- Rust 应用团队希望用 Q 和 E 类型化 API 编写查询与关系图持久化，而非直接拼装通用 ORM 操作。
- 需要让编码代理在实施前提交可审查 KSML 模型，并在模型变更后重新评估和生成的团队。
- 处理业务数据的应用需要将 UserContext、查询 purpose 与 comment、写入审计描述纳入执行过程。
- 希望在人工异步审查模型的同时，让代理继续生成、实现、测试和修复应用的开发流程。
这个 Agent 有哪些优点和局限？
- 将 KSML 作为可保存、可检查的中间表示，使需求、模型和生成代码之间有明确的审查点。
- 模型评估会返回具体错误、警告、建议和修复指导，而非要求代理记住完整规则目录。
- Java 和 Rust 生成物把模型派生领域库与可编辑应用工作区分开，支持在模型更新后重新生成契约。
- 运行时 API 明确承载身份、查询目的与注释、写入审计和显式授予的外部能力。
- 采用流程需要学习并维护 KSML 领域模型，开发顺序不能直接从需求跳到实现。
- 完整输出依赖 TeaQL Generation Service；文档仅称开源 teaql-forge-rs 为小型实现，且不具备完整特性对等。
- 仓库本身主要发布 Skill，实际可运行应用位于独立的 Java 与 Rust 示例仓库，工具链和发布周期分别演进。
- 文档未给出模型评估或生成服务的离线、自托管部署方式，也未说明认证、定价或服务可用性保障。
如何安装或部署这个 Agent？
已提供的安装命令为：npx skills add teaql/teaql-agent-kit --skill build-teaql-app。该命令要求可用的 npx、网络访问，以及可保存模型和生成工作区的本地文件系统。文档未说明账户、API 密钥或其他凭据要求。
如何使用这个 Agent？
安装后，向所用编码代理发出类似请求：Use $build-teaql-app to first draft and save a complete KSML model, then evaluate and repair it before generating a runnable TeaQL application: [你的业务需求]。流程要求先保存完整模型，再评估并修复，然后生成应用、在生成契约内实现、执行验证并报告证据。生成服务的 /latest/ 页面提供当前演示；文档说明该端点会随服务演进。
这个 Agent 与同类方案有什么区别？
与常见的“需求 → 代理 → 代码 → 测试 → 修复”循环相比，TeaQL 在代码前加入可检查的 KSML 模型、确定性评估与生成的类型化契约；它的取舍是更强的流程约束和 TeaQL 体系依赖。