背景
仓库在长期迭代和专项适配过程中逐渐积累了死代码、不可达分支、只写不读的配置、重复实现、单调用者转发层、失效样式以及格式不一致等问题。
这些问题未必直接形成单一功能缺陷，但会持续扩大维护面，增加代码审查、问题定位和后续修改的成本，也会让真正承担运行职责的逻辑更难辨认。
本 Issue 作为整仓清理工作的总追踪项。
目标
- 系统审查后端、前端、配置模型、生成代码和测试代码中的无效或重复实现。
- 在保持现有用户行为和兼容边界不变的前提下，优先删除无运行职责的代码。
- 优先复用仓库已有组件、模型、通知通道和工具函数，避免同类能力重复维护。
- 修正能够由项目规范或工具稳定判定的格式问题。
- 将清理拆分为按模块可独立验证、可独立回滚的变更，避免一次性混入无关重构。
清理边界
以下内容不会为了追求行数而简化：
- 信任边界上的输入验证。
- 防止数据丢失的错误处理、快照与恢复机制。
- 安全措施和必要的兼容逻辑。
- 前端可访问性基础。
- 已有明确多实现、多调用者或独立生命周期职责的模块边界。
- 仅凭“看起来复杂”但尚未完成调用链核验的代码。
推进方式
每个模块单独审查并在本 Issue 下追加评论，评论持续记录：
- 审查范围和真实调用链。
- 已确认的死代码、重复实现与格式问题。
- 可直接复用的现有能力或最小替代方案。
- 排除的疑点及保留理由。
- 预计净删减量、实际实现结果和验证情况。
- 审查结论在实现过程中发生变化时的原因。
清理实现将按模块分别提交，逻辑清理与大范围纯格式调整尽量分开，确保差异可审查。
当前进度
背景
仓库在长期迭代和专项适配过程中逐渐积累了死代码、不可达分支、只写不读的配置、重复实现、单调用者转发层、失效样式以及格式不一致等问题。
这些问题未必直接形成单一功能缺陷，但会持续扩大维护面，增加代码审查、问题定位和后续修改的成本，也会让真正承担运行职责的逻辑更难辨认。
本 Issue 作为整仓清理工作的总追踪项。
目标
清理边界
以下内容不会为了追求行数而简化：
推进方式
每个模块单独审查并在本 Issue 下追加评论，评论持续记录：
清理实现将按模块分别提交，逻辑清理与大范围纯格式调整尽量分开，确保差异可审查。
当前进度