修改全栈 TypeScript Monorepo，并按语义测试其中的 LLM 功能

## 只运行与 CI 一致的包级命令和检查 在运行任何操作之前，先查明仓库中记录的开发、构建、代码检查、格式化、测试、集成测试和评估命令。使用受影响工作区对应的软件包专用命令，不要用作用于整个仓库根目录的工具代替。 - 按受支持的路径或名称筛选条件运行单个测试。 - 从仓库根目录使用 AI 软件包的专用评估命令运行 AI 评估。 - 使用与应用 CI 一致的构建或类型检查；不要运行不受支持的根目录类型检查，以免暴露单体仓库中无关的历史负担。 - 仅当工作区依赖尚未安装时，才在测试或构建前安装依赖。 - 除非任务明确要求，否则不要启动开发服务器或完整构建。 验证范围应与改动的软件包以及 CI 使用的检查相匹配。 ## 测试代码做了什么，而不是怎么写的 创建或修改测试前，先查阅仓库的测试指南。修复核心缺陷时，如条件允许，应采用红灯—绿灯—重构流程：先复现失败，再做最小修复，最后在不改变行为的前提下改进结构。 将单元测试与源文件放在一起。将集成测试、端到端测试和 AI 评估测试分别放入指定的测试目录树。除非测试专门针对日志记录器边界，否则使用真实的日志实现。 优先编写能够捕获有意义行为回归的测试。避免仅仅复述私有实现细节的低价值断言。对于提示词或模型行为的改动，除了常规代码测试外，还应提供语义评估或结构化契约测试。 ## 把依赖安装在实际使用它的工作区 将依赖安装到使用它的工作区，而不是单体仓库根目录。添加新的工作区软件包时，应先更新所有在安装依赖前复制软件包描述信息的生产和本地容器构建清单。 确保示例环境文件、运行时验证模块和单体仓库构建配置中的环境变量保持同步。向浏览器代码公开的变量必须使用仓库规定的公共变量前缀。 对于依赖特定版本或含义不明确的框架行为，修改代码前应阅读已安装依赖随附的文档。不要依赖记忆，也不要依赖针对另一个已安装版本的文档。 ## 直接从定义文件导入，并从 schema 推导类型 启用严格的 null 检查，并从验证模式推导 TypeScript 类型，不要重复定义接口。只在定义文件内部使用的类型不要导出。 - 将所有导入放在文件顶部；不要在文件中间添加动态导入。 - 直接从原始源代码导入，不要创建重复导出链或桶文件。 - 单独导入所需的实用函数，不要导入整个实用工具库。 - 应用内部导入应使用配置好的项目根目录别名。 - 将辅助函数放在文件底部。 - 每个 API 路由文件只保留一种资源。 直接明确的归属关系让依赖、摇树优化和改动影响更容易理解。 ## 只有能让代码更清楚时才抽出辅助函数 默认在逻辑的使用位置直接编写并就近放置。少量重复表达式往往比过早引入辅助函数更清晰。不要提取仅重命名并转发参数的函数。 当辅助函数能够命名一个有意义的领域概念、使周围的控制流更易读，或使对正确性敏感的行为在多个流程中保持一致时，再进行提取。如果多个副本必须保持同步才能避免缺陷，应尽早集中管理大量重复逻辑。 避免大型或嵌套的三元表达式。优先采用直观的控制流、职责明确的辅助函数或查找表。注释应说明某项决策为何存在，而不是解释不言自明的代码做了什么。 优先选择最简单且易读的改动。仅在要求明确规定时保留向后兼容性；否则应直接更新相互配合的调用点，不要叠加无人使用的迁移路径。 ## 不把个人数据写进宽泛的日志级别 不要重复调用链上游已经附加的日志上下文字段。发送者、接收者或消息主题等可识别个人身份的字段，只能记录在仓库限制最严格的跟踪级别中。 明确记录的例外可能允许在更广泛的级别记录已认证用户自己的标识符，但不要把该例外扩展到第三方数据。测试应使用真实的日志记录器，使隐私过滤、上下文传播和格式化仍能得到检验。 添加日志前，应确定其受众、保留期限、敏感程度，以及现有上下文是否已经提供该值。 ## 从数据推导 UI 状态，并使用共享组件 不要通过 effect 将已获取的 props 或服务器数据映射到本地状态。只读视图应使用派生值，用户控制的草稿应使用明确的编辑状态。 创建自定义基础组件前，先使用仓库批准的组件库。通过共享的加载与错误包装器渲染异步内容，使加载、失败和成功状态保持一致。 将特定路由的页面组件与其路由入口文件放在一起，不要添加嵌套的组件目录。跨页面共享的组件应放在应用的共享组件目录中。 ## 数据变更通过服务器操作和共享校验 schema 完成 按访问级别选择路由中间件：公共错误处理、已认证用户访问或账户范围访问。响应类型应从数据函数推导并导出，不要重复定义响应接口。 Web 变更操作应通过仓库的安全操作层使用服务器操作。POST API 路由应保留给需要稳定外部 HTTP 契约的集成，例如原生客户端。 在指定的验证模块中定义变更验证模式，并从这些模式推导输入类型。读取操作应使用既定的客户端缓存，并在变更后使受影响的键失效。使用批准的表单库和操作钩子构建表单，并通过共享的操作错误格式化程序处理失败。 常规应用逻辑应使用提供程序抽象。只有在真正的集成边界才检查具体的提供程序类型。如果仓库禁止基于回调的动态数据库事务，就应避免使用它们。 ## 按语义而不是关键词列表测试 LLM 功能 修复模型的一般性失败模式，而不是针对某个评估用例的措辞。不要仅为了捕获模型当前的表达方式，就在提示词、评估或测试中加入关键词或短语黑名单；文本检查在跨语言时尤其脆弱。 使用评审标准或结构化契约断言语义结果，例如模型是否避免了不必要的澄清或缺乏依据的状态声明。绝不能根据临时拼凑的用户文本匹配来控制上下文注入或工具行为。应使用结构化状态、描述信息或显式事件。 让每项工具说明都可独立理解，其中应包含用途、参数含义、选择指导、前置条件和该工具特有的安全约束。系统提示词中只保留跨领域的身份、确认、安全和格式策略；各工具的指导应放在对应的工具说明中。 ## 检查差异，并报告运行了哪些检查 报告完成前，先检查改动差异，并运行能够证明受影响行为的最小一组 CI 一致性检查。当契约跨越集成或评估边界时，将范围扩展到集成测试或评估测试。 确认以下事项： - 每项依赖和环境变量都归正确的工作区所有； - 测试覆盖行为，并且可以发现新增的测试文件； - 导入、由模式推导的类型、辅助函数和抽象符合仓库约定； - 日志没有扩大个人数据的暴露范围； - UI 状态、变更操作、验证、缓存失效和加载状态采用既定模式； - LLM 行为通过语义而不是脆弱的措辞进行测试； - 未经授权，没有运行不受支持的根目录全局检查、开发服务器或完整构建。 报告实际运行了哪些检查，以及哪些更广泛的检查被有意排除在范围之外。