quality-maintenance

name	quality-maintenance
description	长期、间歇性的代码质量维护与异味检测工作流。与主线开发（code-workflow）互补：主线是主要意图（高密度冲刺），质量维护是低强度、周期性、可持续的背景过程。按"分层节奏"排布（随主线顺带 / 定期窗口 / 专项审计），平衡覆盖率与维护效率，只修低风险项、全量零回归；决定"维持现状"的项归入无目的审视清单。Triggers on "长期质量维护", "异味检测", "质量巡检", "smell 定期", "quality maintenance", "代码体检", "质量排布".

长期质量维护工作流（Quality Maintenance）

规范长期、间歇性的代码质量/异味检测与维护。核心立场：质量检测是长期存在的背景工作，但不时刻与主线开发同强度。需要一套兼顾覆盖率与效率、维护成本可控的节奏方案，合理分配长期维护与主线开发，降低开发风险、提高总体效率。

一、分层节奏（长期维护 vs 主线开发的排布）

质量维护不抢占主线，而按三层节奏错峰运行：

层	触发时机	强度	工作内容
Tier A · 随主线顺带	主线任一次代码改动中	每次	只对本次改动范围做 code-quality/code-odor 自检（已有 code-workflow Phase 4 + code-quality §九）；不扩大范围
Tier B · 定期窗口	每 N 个主线里程碑 / 每 M 天（建议在主线阶段边界）	低强度、批量	跑 code-quality 健康诊断十查 + code-odor 特征码扫描 + smell 清单复核；只分类 + 只修低风险、无契约影响项；其余入记录
Tier C · 专项审计	主线停滞 / 用户指定 / 重大技术债专项	独立分支	PT-SMELL 类独立审计（见 tasks_docs/PENDING_TASKS.md §六），可含架构重构，独立分支执行、不混主线

分配原则：

• 主线（Tier A）永远是主要意图；质量维护（Tier B/C）只在阶段边界或用户指定时介入，不打断主线冲刺。
• 任何时候同一时刻只主推一个 P0 阶段（含质量维护专项），不并行多线。
• 质量维护的产出以"分类定案 + 低风险修复 + 记录"为主，不把架构重构塞进例行维护。

二、Tier B 定期窗口执行流程

1. 扫描：code-quality 十查 + code-odor 特征码 grep 全仓；重跑既有 smell 清单（历史结论见 tasks_docs/WORKLOG.md）。
2. 分类：按 code-quality 判定基准（A 合法保留 / B 修复根因 / 死代码删除 / 双通道收敛 / 需讨论）。
3. 只修低风险项：机械性清理、死代码、可提升 import、测试补齐、明确根因修复（无契约/架构影响）。架构/契约级改动一律不在此窗口做，转 Tier C 或上报。
4. 记录：维持现状 的项（含"能跑但看着别扭"）→ 记入 tasks_docs/WORKLOG.md；待决断 的项 → 记入 tasks_docs/PENDING_TASKS.md。
5. 验证：每批 python -m pytest tests/ 全量零回归；收尾回写审计文档。

三、Tier C 专项审计执行流程

1. 独立 git 分支执行，不混主线文件。
2. 按审计文档的核验流程（证据驱动、禁静态推演、禁单一反射关键字作检索信号）。
3. 优先级：已知吞错面 → 异常当控制流 → 巨型分派链 → 宽 except → 防御探测 → 循环依赖。
4. 每批全量 pytest 零回归；收尾回写清单、合并或保留分支。

四、与无目的审视的关系

• 质量维护（本 skill）产出确定性的分类/修复。
• 无目的审视（aimless-review）产出非目的性的潜在参考（含本 skill 的"维持现状"项）。
• 两者的"维持现状 / 待参考"项都汇入 tasks_docs/WORKLOG.md，由 aimless-review 负责周期性事实回顾与演进。

五、配套 skill

• code-quality：判定与处置基准（红线/十查/分类速查）。
• code-odor：特征信号扫描与工作过程自查。
• code-review：缺陷复核/分类/实施后核验。
• self-grill：交付前自我质询。
• aimless-review：非目的性审视（长期潜在参考的沉淀与演进）。