这份文档用于定义 TrendRadar Rust 迁移阶段不可随意改变的约束。
这里记录的不是“实现偏好”，而是影响迁移正确性、可维护性和后续审查的硬边界。
- 只有真正不应被随意打破的约束才写进来
- 不变量应尽量能被测试、lint、脚本或代码结构验证
- 新增不变量前，先确认它不是可以从代码直接推导出来的临时事实
- Rust 首版必须围绕“配置 -> 抓取 -> 归一化 -> 分析 -> 存储 -> 输出”的主链路建设
- 任何不直接服务主链路的功能，不得阻塞核心 crate 迁移
domain不依赖fetch、storage、report、appapp只做编排和入口，不承载复杂业务规则- 抓取、存储、输出不得反向污染领域模型
- 调度、过滤、聚合、排序等纯逻辑优先落地
- 外部 API、通知、MCP、AI 能力默认延后，不得抢占核心迁移优先级
- 旧系统的命令行参数、展示细节和环境分支逻辑可以有选择地丢弃
- 只有明确进入契约基线的行为才需要兼容
- 新增或调整 crate 时，必须能通过固定命令进行编译、测试或文档验证
- 没有进入验证面的代码，不应被视为迁移完成
- 新增模块优先作为现有 workspace 成员的一部分，而不是在仓库外游离实现
- 不引入绕过工作区 lint、测试和 CI 的独立构建入口
- 改动必须在 Git 工作树内完成
- 默认只修改当前仓库代码、文档、fixture 和测试
- 不直接把外部系统接入、部署脚本和敏感配置纳入 AI 自动写入范围
- 结构性变更需要同步更新
README.md、架构文档、迁移文档或开发日志 - 如果某项规则无法从仓库当前状态得到印证，应优先重写或删除文档
- 不以“整个系统一次性重写”为任务单位
- 默认按 crate、adapter、契约或测试样例推进
这些行为暂时还缺完整样例，但已经应当被视为迁移约束：
- 同一组输入 fixture 需要产生稳定、可复查的分析结果
- 配置解析必须给出可定位的错误，而不是无上下文失败
- 输出层的结构化结果必须可序列化、可比对、可快照
- 调度与评分逻辑应尽量保持纯函数或纯逻辑接口，便于做 parity 测试
目前这些不变量大多还是文档基线，后续还需要逐步落到：
- fixture
- snapshot
- crate 级测试
- 跨 crate 系统测试
- CI 验证脚本
- 每次出现“是否允许这样改”的争议时，优先检查本文件
- 如果某个不变量已经能被代码、测试或 lint 完整覆盖，应在这里补上对应验证入口
- 如果迁移策略发生变化，应先更新本文件，再放宽实现范围