# Wiki-Blocks-Authoring The format of a `dl:wiki` block -- the concept notes the [wiki](wiki.md) verb reads. A block records what your team **calls** something and which code **is** it. The index can answer neither of those from the source alone, which is why this is written by hand and not generated. ## Where a block goes Inside an ordinary DocInsight `///` comment. There are exactly two placements, and the choice is about who OWNS the concept: **One type owns it** -- put the block in that type's own ``: ``` /// Streams pending row deltas into the target memtable. /// /// dl:wiki Delta Streamer /// Aliases: the streamer /// Body: /// Owns the client half of the delta path: batching, retry and the pipe. /// TDeltaStreamer = class ``` **Several types share it** -- put the block above `unit X;` in the unit where the concept's central type lives: ``` /// /// dl:wiki Delta Streaming /// Aliases: delta stream, cmdDelta pipeline, the streaming path /// SeeCode: TDeltaStreamer, TDeltaSet.ApplyDelta, Micronite.Delta.Pipe /// Body: /// How row changes travel from the client to the server. /// unit Micronite.Delta.Pipe; ``` **The unit-header placement is the recommended home for a concept**, for a reason that is structural rather than stylistic: a unit symbol is not in `DOCUMENTABLE_KINDS`, so `document`, `document-all`, `missing-doc` and `doc-drift` never open that comment at all. A block there cannot be touched by the autodoc rewriter even in principle. A type-attached block is also safe -- the doc engine's provenance contract preserves any content that does not carry a `` marker byte-for-byte, and `dl:wiki` lines never carry one -- but "structurally out of reach" is a stronger guarantee than "preserved by a rule". ## Hard requirements * **`///` comments only.** Loose `//` and `{ }` comments are not attached to symbols by the indexer, so a block written in one is invisible. This is not configurable in practice; use `///`. * **No blank line** between the block's comment and the declaration it belongs to, or the comment stops attaching. * **Strict 7-bit ASCII, CRLF** -- the same rule as every other `.pas` line in these projects. Use `--` and not an en dash, `"` and not curly quotes. ## The grammar Line-oriented, after the `///` prefix is stripped. Section keywords are case-insensitive. | Line | Required | Meaning | |---|---|---| | `dl:wiki ` | **yes** | opens a topic. Everything after the marker, trimmed, is the name | | `Aliases: a, b, c` | no | phrases the team uses for this. Repeatable; entries accumulate | | `SeeCode: X, Y.Z` | no | other symbols that participate. Repeatable | | `Body:` | no | starts the prose | | anything else | -- | joins the body | Notes that matter in practice: * **One comment may declare several topics.** A new `dl:wiki` line ends the previous one. * **`Body:` is optional.** Untagged lines after the header join the body anyway. Write it when you want the boundary to be obvious, skip it for a one-line topic. * **XML-only lines are dropped** from the body, so the `` that closes your comment does not end up in the prose. A sentence that merely *mentions* a tag is kept. * **Engine-generated fact blocks are excluded.** Anything between `` and `` is skipped, so a topic sitting beside a generated facts region cannot swallow it. * **`dl:wikifoo` is not a header** -- the marker must be followed by whitespace or end of line. ## Aliases are the whole feature The name is what you would title a wiki page. The **aliases are what people actually type**, and they are the reason the lookup works: ``` /// Aliases: delta stream, cmdDelta pipeline, the streaming path ``` Matching is case-insensitive and runs **in both directions**, so an alias of `scheduler` is found by `--term "the scheduler"` and vice versa. Write the phrases your team says, including the ones with articles in them and the ones that are slightly wrong -- those are exactly the queries that would otherwise fail. Do not invent synonyms nobody uses. An alias that no one says is dead weight, and an alias that collides with a different topic's name is reported as drift by `wiki --check` because it makes the lookup answer with the wrong topic. ## SeeCode is a checkable claim The owning symbol is **implicit** -- the block's own location is already a code location, so a single-owner topic needs no `SeeCode` line at all. List the OTHER participants: ``` /// SeeCode: TDeltaStreamer, TDeltaSet.ApplyDelta, Micronite.Delta.Pipe ``` Each entry is resolved against **the topic's own index**, in this order: the full qualified name, then a bare name, then a dotted suffix. So `TDeltaSet.ApplyDelta` resolves even though the index stores `Micronite.Delta.Set.TDeltaSet.ApplyDelta` -- write it the way the code spells it. An entry resolving to nothing is a `wiki --check` failure naming the symbol, which is what turns the line from prose into something that goes stale loudly instead of quietly. Body prose is **not** checkable, and nothing pretends it is. That is the cost of a free-text concept note, stated rather than hidden. ## What a hover shows A short pointer, not the body: ``` - Wiki: Delta Streaming -> Micronite.Delta.Pipe - line 3 ``` It is clickable and jumps to the `dl:wiki` header. That is deliberate -- a concept body is paragraphs and a hover popup is a glance. Ordinary `` prose written around the block is shown as usual, so you can keep normal doc text and a topic in the same comment without one hiding the other. ## After writing one ``` drag-lint index --db # ordinary incremental walk drag-lint wiki --check --db # must exit 0 drag-lint wiki --term "" # must find it ``` The last line is not ceremony. A block with a typo'd marker, in a `//` comment, or separated from its declaration by a blank line produces no error anywhere -- it simply does not exist. Ask for it back. ## Related * [wiki](wiki.md) -- the verb that reads these