# knowledge-index-sort Decisions

## Question Pool

| # | 维度 | 问题 | 模式 | 状态 |
|---|---|---|---|---|
| Q1 | 术语 | "按标签排序"具体指什么？按第一个标签字母序？按标签数量？ | user-interview | 已解决 |
| Q2 | 边界 | 排序是否只影响当前过滤后的可见条目（不影响过滤逻辑本身）？ | evidence-driven | 已解决 |
| Q3 | 验收 | 排序变化后，页面应如何响应？即时重排还是需要点击"应用"？ | evidence-driven | 已解决 |

## User-interview

| 问题原文 | 用户原话 | 确认状态 | OpenSpec 回写 |
|---|---|---|---|
| "按标签排序"具体指什么？ | "按数量" | 已确认 | 已回写 |

## Evidence-driven

| 结论 | 证据来源 | 是否已汇报用户 |
|---|---|---|
| 排序只作用于过滤后的结果 | knowledge-index.html applyFilters() 代码 | 已汇报 |
| 排序应即时响应（change 事件） | 与 year-filter/标签/搜索控件行为一致 | 已汇报 |

## 关键取舍

- 决策：排序位置放在 applyFilters() 中，过滤之后、渲染之前
  - 原因：排序只影响可见条目，不影响过滤逻辑
  - 影响：renderEntries 保持纯渲染职责
  - 风险接受：当前接受

- 决策：4 种排序模式（日期新→旧、旧→新、标签多→少、少→多）
  - 原因：覆盖最常见排序需求
  - 影响：UI 简洁，不需要复杂的多列排序
  - 风险接受：当前接受

## 执行偏差记录

- 偏差：apply 阶段先实现了代码，后补写 OpenSpec 产物（proposal/design/specs/tasks）
  - 分类：实现偏差（违反 sm-flow 协议——specify 阶段应先产出完整 OpenSpec）
  - 原因：micro 模式下跳过了 specify 阶段的文件产出，直接进入 apply
  - 修正：补写所有 OpenSpec 产物到 openspec/changes/knowledge-index-sort/
  - 教训：即使是 micro 模式，OpenSpec 产物也不能跳过——这是 apply 的执行依据