Harden dev-flow: pre-authorization marker, alternatives log, check script
- Record rejected answers in decision.md at the moment they are rejected - Allow explicit pre-authorized Build via a pre-authorized marker line - Land scripts/check-dev-flow.sh and derive devflow/index.md from archives - Add dev-flow process artifacts (decisions, prd) for open changes
This commit is contained in:
@@ -0,0 +1,70 @@
|
||||
# Decision: 年份筛选采用纯前端派生,不新增数据字段
|
||||
|
||||
## Problem
|
||||
|
||||
知识索引只能按关键词和标签过滤。当条目跨越多个月份和年份时,列表只会越来越长,而用户缺少一个**粗粒度**的收敛手段——想回看某一年沉淀了什么,只能靠肉眼扫或者记住关键词。
|
||||
|
||||
而"年份"这个维度其实**已经躺在数据里**了:每个条目的 `date` 字段(格式 `YYYYMMDD`)是渲染日期时的唯一来源。也就是说这不是一个需要新增信息的需求,而是一个**已经存在的信息没有暴露给用户**的问题。
|
||||
|
||||
## Decision
|
||||
|
||||
年份从 `ENTRIES[].date.slice(0,4)` 派生,**不新增数据字段**。
|
||||
|
||||
- 控件用原生 `<select id="year-filter">`,位置在搜索框下方、标签云上方,与搜索、标签同属一组合并过滤。
|
||||
- 选项从条目里**实际出现的**年份去重生成、倒序排列;只接受能匹配 `/^\d{4}$/` 的值。默认"全部年份"。
|
||||
- 过滤并入现有 `applyFilters()` 作为**单一过滤入口**,顺序为 `年份 → 标签 → 搜索`。
|
||||
- 修改在 `scripts/update-knowledge-index.sh` 的 HTML 模板里完成,再重建 `knowledge-index.html`。
|
||||
|
||||
## Alternatives considered
|
||||
|
||||
**新增 `year` 字段到条目数据。** 冗余——`date` 已是唯一来源,派生成本为零,多一个字段就多一处可能不一致的地方。而且条目是 `knowledge_*/` 下的手写 markdown,新增字段意味着所有历史条目都要回填。
|
||||
|
||||
**引入第三方筛选组件(Select2 等)。** 为 4 行原生 `<select>` 代码引入依赖,与仓库"单文件静态 HTML、零依赖"的约束直接冲突。
|
||||
|
||||
**只修改生成后的 `knowledge-index.html`,不改生成脚本。** 更快,但 `knowledge-index.html` 是**生成产物**——下一次重建即丢功能,生成脚本才是真理源。这条在实现过程中确实被识别为"主要风险"(见 `design.md` 的架构审计一节),但**当时没有被记成一条备选**。它是一个真实的、有诱惑力的错误选项,所以补录在这里。
|
||||
|
||||
## Consequences
|
||||
|
||||
**得到**
|
||||
|
||||
- 零依赖、无数据迁移,没有新字段需要维护一致性。
|
||||
- 与既有搜索、标签过滤自然组合,因为三者走同一个 `applyFilters()` 入口。
|
||||
- 年份选项只列**实际存在**的年份,不会出现空年份。
|
||||
- 重建索引不会丢功能——修改落在生成脚本的模板里。
|
||||
|
||||
**代价**
|
||||
|
||||
- **只有年粒度**:不支持月份、日期范围、时间线视图或自定义排序。
|
||||
- `<select>` 选项数量随年份**线性增长**。以当前条目量完全可接受;多年后可能需要改成可搜索的下拉。
|
||||
- 过滤在前端全量进行。条目数量级显著变大时需要改为服务端或预建索引方案。
|
||||
|
||||
**已知限制**
|
||||
|
||||
- `date` 为空或不匹配 `YYYYMMDD` 的条目:不进入年份选项,在"全部年份"下仍显示,选中具体年份时隐藏。
|
||||
- 年份比较基于**字符串前四位**,不做真实日期解析——因此 `20260230` 这类非法日期会被当作 2026 年处理。这是有意的取舍:真实解析会引入日期库依赖,而收益只覆盖一个不会出现的输入。
|
||||
|
||||
## Verification
|
||||
|
||||
以下命令均在仓库根目录执行,路径为相对路径。
|
||||
|
||||
**只读(可直接跑,已在本次收尾时实测)**
|
||||
|
||||
- 控件同时存在于生成产物与模板两处
|
||||
`grep -c 'id="year-filter"' knowledge-index.html scripts/update-knowledge-index.sh`
|
||||
→ `knowledge-index.html: 1`,`scripts/update-knowledge-index.sh: 1`
|
||||
|
||||
- 年份过滤确实并入唯一入口 `applyFilters()`(函数体起始于第 217 行)
|
||||
`grep -n 'selectedYear' knowledge-index.html`
|
||||
→ `219`(读取控件值)、`228`(判断)、`229`(执行过滤)——三处都在函数体内
|
||||
|
||||
- 生成脚本语法完整(只做语法检查,不执行)
|
||||
`bash -n scripts/update-knowledge-index.sh` → `exit=0`
|
||||
|
||||
**有副作用(会重写 `knowledge-index.html`,故未在收尾时运行)**
|
||||
|
||||
- 重建后功能仍在
|
||||
`bash scripts/update-knowledge-index.sh`,然后复跑上面两条 `grep`
|
||||
|
||||
**人工**
|
||||
|
||||
选择 `2026` → 只显示 `date` 以 `2026` 开头的条目;再激活一个标签 → 两者取交集;选"全部年份" → 年份过滤解除,而标签仍然生效。
|
||||
Reference in New Issue
Block a user