zhuyongxin
63994b6440
- Rewrite hard constraint #1: apply must read Committed OpenSpec files as the execution source of truth - Promote sub-skill invocation to hard constraint #6; remove fallbacks.md and all degradation paths - Add file existence verification at commit and archive exit gates - Require grill question pool, evidence-driven conclusions, and user-interview confirmations to be written to decisions.md - Record v4.0 validation retrospective in workflow.md: propose overreach, sub-skill pseudo-calling, spec omitting user behavior - Archive knowledge-index-sort OpenSpec and devflow entries from prior run
1.9 KiB
1.9 KiB
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 的执行依据