aimless-review

name	aimless-review
description	非目的性的代码审视与设计沉思。不带特定架构指标/缺陷目标，纯粹分析"某段代码为何这样设计、带来什么、未来可能有什么问题"，以及"能运行但看着别扭/微妙不合理"之处。低密度、低强度，作为潜在参考而非强制处置；分析策略自我演进；记录清单周期性事实回顾与更新，避免过期/偏颇干扰主线。是长期质量维护的"无目的"侧。Triggers on "无目的分析", "非目的审视", "设计沉思", "aimless", "审视", "为什么这样设计".

非目的性审视（Aimless Review）

低密度、低强度的纯粹无目的分析。目的不是修 bug、不是满足某条架构指标，而是积累对设计选择与潜在风险的潜在参考。它不高频、不干预主线，只在你观察时沉淀，并定期做事实回顾防止过期。

一、定位与纪律

• 性质：无目的——不预设要达成某个架构原则/指标，不承诺处置。分析是"潜在参考"，不是待办清单。
• 密度：低密度、低强度。很多这类分析只是潜在参考，且容易过期、容易偏颇——所以必须克制，不因"发现了"就扩散。
• 演进：审视"审视策略"本身——分析关注点、扫描模式、分类框架都需被周期性自我演进，避免僵化。
• 不打扰主线：产出只入记录清单，不打断主线开发；除非某条观察上升为明确缺陷（此时转 code-review/code-quality 处置）。

二、观察什么（无目的的四个追问）

1. 为什么这样设计：这段代码的取舍/形态从哪来？可能对应什么历史决策？
2. 带来什么：这个设计当下提供了什么收益/能力？
3. 未来可能有什么问题：它可能在什么条件下演变成问题（性能、正确性、扩展、维护）？
4. 能跑但别扭：运行正确但看着不舒服、微妙不合理、命名/结构/粒度不自然之处。

注意：仅记录，不立即判定"要修"。判定与处置是 code-quality/code-review/quality-maintenance 的职责。

三、记录（living list）

• 每条观察写入 tasks_docs/WORKLOG.md，含：位置、观察、潜在风险、记录日期、来源（无目的审视 / 质量维护·维持现状）。
• 来源标记：smell 维持现状 项（来自 quality-maintenance 或 code-quality 判定为"合法保留"的）必须纳入此清单，作为潜在参考。

四、周期性事实回顾与更新

• 周期（建议随 Tier B 质量维护窗口，或每里程碑边界）对清单做事实复审：
  1. 逐条核对"该观察在当前代码是否仍成立"（读代码/跑测试，禁凭记忆）。
  2. 已过期 / 已偏颇 / 已被重构消除 → 删除或标注"已失效"。
  3. 已上升为明确缺陷 → 转出到 code-review/PENDING_TASKS 处置。
• 目的：防止清单里过期/偏颇的记录，在未来主线开发时被误当作依据，反而干扰主线。

五、策略自我演进

• 定期（周期同上）审视"审视策略"本身：当前关注点是否仍有效？是否漏了某类模式？是否引入了新的偏见？
• 调整本 skill 的观察问法、扫描模式、记录粒度，并回写到本 skill 或 WORKLOG.md 记录段落。

六、配套

• quality-maintenance：长期质量维护的"有目的"侧（确定性分类/修复）。
• code-quality / code-odor / code-review / self-grill：判定与处置基准。
• 本 skill 只沉淀"潜在参考"，不产出强制处置。