[Clear Room][CR-08] 统一聊天记忆契约与存储适配的包层级 #34

设计约束：以收益决定变更，破坏性变更需逐项论证

用户明确：技术独立是目标，改动幅度和破坏性不是目标。合理的现有概念、API、模块和实现可以保留；不能因为来自上游就要求删除、重命名或重写。新 API 包装旧引擎若只是表面换名不能证明技术独立，但也不以“零旧代码”作为验收指标。

每项破坏性变更在实施前必须完成以下决策记录：

• 具体问题：现状如何影响职责、正确性、扩展性、依赖隔离或使用体验，附代码/用例/测试证据。
• 方案比较：至少比较保留现状或兼容演进与破坏性调整，说明为何较小改动不足以解决问题。
• 收益与成本：列出预期收益、受影响 API/消费者/配置/数据/观测、迁移工作量及回归风险；只有收益足以覆盖成本才采用破坏性方案。
• 迁移与验证：明确目标版本、旧→新映射、升级步骤、必要的兼容期限或不兼容理由、回滚条件及有意义的行为验收。
• 评审结论：记录采用、保留或推迟及理由；未形成结论前不实施对应破坏性调整。

不为追求与上游形式不同而修改成熟设计，不机械加前缀、迁包、拆模块或替换行业通用术语。技术独立通过自主架构决策、清晰契约、可控依赖和独立演进能力评估；重写仅用于解决已证实且值得付出迁移成本的问题。

本节是后续明确的约束；若下文历史规划含有无条件重写、删除旧路径或仅因上游来源而替换的表述，按本节执行并在设计阶段修订。

目标升级

本任务纳入 ARGI 独立架构与实现重设计：agentic-ai-java/argi#186 。原有名称与路径仅为现状证据，不要求沿用旧模块或 API。实施前等待目标架构评审，按新的职责与行为契约重新确定范围；必要时重写该能力并移除旧路径。仅改名或包装旧实现不足以证明设计问题已解决；是否替换由问题证据和成本收益决定。本文已有局部回归项仍需覆盖，若与新架构冲突，应更新验收标准并说明取舍。

总览：#30

证据：memory-repository 下存在 ...memory.redis，对应自动配置使用 ...model.chat.memory.redis.autoconfigure。路径不一致是评估输入，不直接构成必须迁包的结论。

交付与验收：

• 盘点各 memory/repository 实现与自动配置，按聊天记忆契约、存储适配、装配职责给出统一层级决策。
• 逐项记录公共 API、配置键、缓存键和持久化类型影响；明确无需变更项。
• 实施获批迁移并同步 starter、imports、元数据与测试；避免为路径一致改动存储协议。
• 如影响数据格式，遵守 CR-02；以旧格式 fixture 验证消息角色、工具调用关联及读取结果。
• 对改动实现验证装配和读写行为，外部存储测试列明已执行及未执行项。

不改变 TTL、索引、租户隔离等既有业务策略。

依赖与执行边界

• [Clear Room][CR-01] 确认两仓迁移基点、领域术语与命名决策清单 argi#181
• [Design][CR-02/OPT-05] 明确 checkpoint 协议、类型解耦与历史数据迁移契约 argi#182

本系列的 Clear Room 指从当前职责和行为契约出发设计。目标名称以评审结论为准；允许有证据地保留现状。