---
name: 自举解析路线
desc: 一条穿越 Sirno 自应用问题及其解析的叙事路线。
category:
  - narrative-zh
belongs:
  - narrative-zh
refines:
  - project-self-application-zh
---

此叙事服务于在此 Lake 中感受到递归压力的读者：
Sirno 是被解释的工具，
Sirno 也是用来解释它的方法。

对话始于一种简单的不适。
一句话可以描述任何 Sirno 管理项目应如何文档化自身。
下一句话可以描述此仓库如何使用 Sirno 来文档化 Sirno。
两者都有效，
但角色转换让读者做了隐藏的工作。

第一个答案是视角。
Lake 现在命名了四个说话立场：
`Sirno`、`a Sirno-managed project`、`this repository` 和 `this lake`。
读者可以分辨一段话是关于通用工具、
任何应用它的项目、
实现工作区，
还是 `sirno-docs/` 中的自托管 Sirno Lake。

第二个答案是词汇。
Sirno 术语在与 Sirno 一起出现时成为专有名称：
Sirno Lake 和 Sirno Frost。
否则，当它们承载 Sirno 含义时保持小写和斜体：
*lake*、*entry*、*witness*、*frost*、*ripple*、*transform*、*monograph* 和 *repository*。
普通项目词保持朴素。
这使正常文档保持可读，
同时仍然标记读者何时进入了 Sirno 的模型。

决定性的答案是 `meta`。
自举问题需要一个地方让项目可以回答：
文档在此应如何发展？
`meta` 类别赋予该问题一个地址。
`meta` 条目可以定义词汇、
术语样式、
叙事习惯、
条目拆分规则，
以及面向智能体的文档方法。

这让递归变得有生产力。
Sirno 不只是给项目文档。
它给项目一个地方来文档化文档应该如何生长。
方法可以被阅读、查询、评审、
并由使用它的相同工具修订。

穿越解析的路线是：

1. 阅读 `project-self-application` 了解递归压力。
2. 阅读 `perspective-and-terms` 了解说话立场和术语样式。
3. 阅读 `meta` 了解文档方法表面。
4. 阅读 `category` 了解类别目标是 `meta` 条目的推荐。
5. 阅读 `structural-check` 了解配置引用边界。
6. 返回 `methodology` 了解贡献者应遵循的习惯。

实现将相同的结论保留在 Lake 中，
而非字段特定代码中。
`sirno check` 验证已配置的结构引用，
而不需知道推荐的字段名称。

有意推迟的细节是局部措辞。
此叙事命名了顺序。
以上命名的条目承载了持久定义。

携带此余味：
自举表面是被 `meta` 分类的普通条目，
项目在其中文档化自己的文档方法。

[generated-footer-zh]: generated-footer-zh.md "Generated Footer"

---

> **Sirno generated links begin. Do not edit this section.**

- belongs (to):
  - [narrative-zh](narrative-zh.md)
- belongs (from): (none)

> **Sirno generated links end.**
