v1.4 — 两张「四层一图」+ type 字段无消费者的如实记录

v1.4 — 2026-08-03

纯文档发布,无代码行为变化。 两页各补一张全景信息图,
顺带把一条不太好看的查证结论摆到明面上。

新增:两张「四层一图」

《系统如何运作》 —— 按数据流画(与该页第 1 节的权责视图互补,不重复):

层	内容
来源层	raw/*,只读,唯一真相
加工层	两条路:① sage-wiki compile 引擎批量 ② LLM 对话式 ingest 人在环
知识层	引擎领地(LLM 只读)与 LLM 领地,各自的门禁标在写入点上
调用层	索引 / 浏览站 / 本地检索 / 引擎查询,含一条回流箭头

图里说清了三件文字不容易讲明白的事:加工是两条路而非一条(只有 raw/todo
走人工深度处理,clippings、flomo/delta、pdfs 三者都在 config.yaml 的
sources 里由引擎自动编译);门禁挂在写入点上而不是挂在嘴上;调用层那条
回流才是"知识复利"的实现——没有它,这就只是个搜索引擎。

《OKF 合规》 —— 按流水线环节画:来源层 → 引擎层 → 合规层
(① okf.py --fix → ② build-index.py → ③ okf.py --check,标注顺序约束与自愈回环)
→ 消费层(各字段分别被谁读取)。

两张图共用同一套视觉语汇(单张内联 SVG、左侧层轨、CSS class 上色而非写死 fill),
并排看时不用重新学一套符号;浅/深主题自动跟随,窄屏时图容器自身横向滚动、不压缩图形。

一条如实的查证结论:type 目前没有消费者

v1.3 补齐了 OKF 要求的 type 字段。事后把整个代码库翻了一遍,结果是:

读 entity_type 的：build-index.py:71   build-wiki-site.py:107
读 「类别」 的：   build-wiki-site.py:230
读 frontmatter type 的：  只有 okf.py 自己

indexlib / searchlib 一次没碰。也就是说,这个字段今天的实际产出是零 ——
真正划算的是顺带做成的 okf.py --check(编译引擎领地此前零校验)与
stale_after 链路,而那两件都不需要 OKF。留着 type 的理由只有一条:
成本≈0 的互操作期权,等 OKF 生态工具出现时才兑现。

这条结论已画进信息图的末层(四条实线通向真实消费者,type 一条虚线指向空框),
不是藏在正文里。若你 fork 了本项目,可据此自行决定要不要保留这一步。

门禁

文档站的「两份载体」检查改成完全表驱动:章节数与主题词都写在 PAIRS 表里,
加新页或改章节结构会被门禁挡下,不会出现"改了一边忘另一边"。