---
desc: A narrative route through Sirno's self-application problem and its resolution.
lifecycle: Active
name: Bootstrap Resolution Route
structural:
  category:
  - narrative
  belongs:
  - narrative
  refines:
  - project-self-application
---

This narrative serves readers who feel the recursive pressure in this *lake*:
Sirno is the tool being explained,
and Sirno is also the method used to explain it.

The conversation began with a simple discomfort.
A sentence could describe how any Sirno-managed project should document itself.
The next sentence could describe how this repository uses Sirno to document Sirno.
Both were valid,
but the role shift made the reader do hidden work.

The first answer was perspective.
The *lake* now names four speaking positions:
`Sirno`, `a Sirno-managed project`, `this repository`, and `this lake`.
A reader can tell whether a passage is about the general tool,
any project that applies it,
the implementation workspace,
or the self-hosted Sirno Lake in `sirno-docs/`.

The second answer was vocabulary.
Sirno terms become proper names when they appear with Sirno:
Sirno Lake and Sirno Frost.
Otherwise they stay lowercase and italic when they carry Sirno meaning:
*lake*, *entry*, *witness*, *frost*, *ripple*, *transform*, and *repository*.
Ordinary project words remain plain.
This keeps normal documentation readable
while still marking when the reader has entered Sirno's model.

The decisive answer was `meta`.
The bootstrap problem needed a place where the project could answer:
how should documentation develop here?
The `meta` category gives that question an address.
A `meta` *entry* can define vocabulary,
term styling,
narrative habits,
*entry* splitting rules,
and agent-facing documentation method.

That made the recursion productive.
Sirno does not just give the project documentation.
It gives the project a place to document how documentation should grow.
The method can be read,
queried,
reviewed,
and revised by the same tools that use it.

The route through the resolution is:

1. Read `project-self-application` for the recursive pressure.
2. Read `perspective-and-terms` for the speaking positions and term styling.
3. Read `meta` for the documentation-method surface.
4. Read `category` for the recommendation that category targets are categorized by `category`.
5. Read `structural-check` for the configured-reference boundary.
6. Return to `methodology` for the habit contributors should follow.

The implementation keeps the same conclusion in the *lake*,
not in field-specific code.
`sirno check` validates configured structural references
without knowing the recommended field names.

The detail intentionally deferred is local wording.
This narrative names the sequence.
The *entries* named above carry the durable definitions.

Carry this aftertaste:
the bootstrap surface is ordinary *entries* categorized by `meta`,
where the project documents its own documentation method.
