Repository navigation
核定 lmm-api/cortexfs 退役范围、依赖与保留数据 #220
Description
当前范围 · 2026-10-03
保持开放。2026-10-03 的只读盘点仍确认 lmm-api 与 cortexfs 的包已安装，两个服务正在运行；MSG 的路径隔离实现没有退役这些项目。
剩余工作是按当前用途核对准确对象、共享依赖和数据保留范围，再执行并复查对应退役。当前没有停服、卸包、卸载挂载或删除，因此不能写成已清理，也没有足够证据把需求直接判为过时。
剩余完成条件
- 确认目前仍计划退役的 lmm-api/cortexfs 专属对象、共享依赖与数据保留范围。
- 在准确范围确定后执行退役，复查包、服务/激活、挂载、代理和专属数据；保持 MSG 与共享服务可用。
本轮依据当前主线 105c2cf716c1179d49bc79224f10f44a3b031163、已完成 CI 和只读部署盘点更新范围。没有执行新的生产迁移、删除、Root/CA 变更或资金操作。旧的全章/全客户端人工矩阵不再作为本项永久门槛。
历史需求与旧验收记录（保留供查阅；当前待办以上述范围为准）
2026-10-01 状态确认
旧 lmm-api / cortexfs 的包、服务、挂载、配置与数据清理仍未执行和验收；路径设计 PR #222 与这些项目退役属于不同事项。保持开放，后续按准确目标清理，并保护共享 PostgreSQL/Valkey/Nginx 及当前 MSG/Root 材料。
原始报告（保留历史；当前状态以上述更新为准）
用户要求清理 lmm-api / cortexfs 遗留痕迹。只读盘点实际发现相关软件包、服务、挂载和部署目录仍存在，其中服务还在运行。后续用户又明确指出 MSG 的路径设计问题，不能把路径重构当成删除 MSG Root 材料的授权。
目前未执行删除。需记录准确退役目标，处理服务/包/挂载/配置/数据/过期归档与反向代理引用，避免只删 /var/lib 目录或破坏共享 PostgreSQL、Valkey、Nginx及当前MSG。
验收：确认退役目标后执行；包/服务/挂载/遗留路径检查无残留；保留当前MSG和非目标项目；不将运行状态伪装成已清理。
Activity
LIghtJUNction commentedon Sep 30, 2026
2026-10-01 状态确认
旧 lmm-api / cortexfs 的包、服务、挂载、配置与数据清理仍未执行和验收；路径设计 PR #222 与这些项目退役属于不同事项。保持开放，后续按准确目标清理，并保护共享 PostgreSQL/Valkey/Nginx 及当前 MSG/Root 材料。
LIghtJUNction commentedon Oct 3, 2026
保持开放。2026-10-03 的只读盘点仍确认 lmm-api 与 cortexfs 的包已安装，两个服务正在运行；MSG 的路径隔离实现没有退役这些项目。
剩余工作是按当前用途核对准确对象、共享依赖和数据保留范围，再执行并复查对应退役。当前没有停服、卸包、卸载挂载或删除，因此不能写成已清理，也没有足够证据把需求直接判为过时。
[-]服务器退役项目清理需有准确范围与验收，避免误解路径要求[/-][+]核定 lmm-api/cortexfs 退役范围、依赖与保留数据[/+]