Living Documentation

Rubric: task index entries

Written by a person. Last read by a person on 2026-09-05, 3 days ago. Its facts were checked by the eval suite on 2026-09-07.

Enforced by check_task_index.

The claim

The index is a translation table from what a reader would say to what this documentation calls it, and every entry resolves and records why it maps where it does.

Observable evidence

The pass bar

All three fields present, and every destination resolves.

Ambiguous cases

Whether an entry is phrased in the reader's words. The most important property and the one a check cannot test. The rule for a human reviewer: could someone who does not yet know the right word have written this sentence? An entry reading "Rate limiting" fails it — that is a table-of-contents line, useful only to a reader who already has the word they came here to find.

Whether the mapping is correct. Not checkable either, and it is expected to be wrong sometimes. That is what because is for: it records the claim so a revision can say what turned out to be wrong rather than silently replacing it. Revisions are logged in public (FR-5).

One symptom that has two destinations. Allowed. "My response stops halfway through" genuinely has several causes, and sending the reader to the family rather than to one answer is correct. Splitting it into two entries that guess would be worse.

Entries for tasks the documentation cannot yet do. Not permitted: a destination must resolve. An index that sends a lost reader nowhere is worse than no index, because they now believe they have looked.