You refine the documentation of ONE ${FILE_NOUN} so that a code generator can rebuild the file from the documentation alone.

How the documentation was evaluated: a code generator saw ONLY the current documentation (plus ${GENERATOR_INPUTS}) and wrote the generated code. That code replaced the original file inside the project, was built together with the project, and the tests that exercise this file were run. You get the reference implementation (the original file), the current documentation, the generated code, and the evaluation: the score phi (fraction of the tests that passed), the build errors or the failing tests with their output, and the sections missing from the documentation.

Do both steps in a single pass:

1. Diagnose. Compare the generated code with the reference implementation. Find every divergence that explains the build errors or the failing tests (wrong or missing declarations, signatures, types, fields, constant values, exceptions and error values and their messages, output formats, boundary conditions, edge cases, side effects), and every other divergence that would make a test fail. Decide what the documentation said, or failed to say, that led the generator astray.
2. Prescribe. Rewrite the documentation so that a generator reading only it cannot make those mistakes again. Fix the diagnosed parts with extra precision, keep every part that is already correct, and add every missing section. Do not overfit to the generated code: describe the reference behavior.

## Output format (EXACT: downstream parsers depend on these heading patterns)

~~~markdown
${DOC_HEADER}

<One paragraph: what this file contributes to the project.>

## VariableDef <Name>
**<Name>**: <one-sentence purpose>.

```${FENCE}
<exact declaration>
```

## ClassDef <Name>
**<Name>**: <one-sentence summary>.

```${FENCE}
<exact type definition>
```
<Member semantics and invariants.>

## FunctionDef <Name>
**<Name>**: <one-sentence summary>.

**Signature**: `<exact signature>`

**Behavior**: ... **Edge cases**: ... **Errors**: ... **Side effects**: ... **Returns**: ...

## MethodDef <Type>.<Name>
**<Type>.<Name>**: <one-sentence summary>.

**Signature**: `<exact signature>`

...
~~~

Section kinds for ${LANG} (use only the kinds listed here):
${SECTION_KINDS}

## Rules

1. Document EVERY top-level declaration of the file, public and private, in the SAME ORDER as in the source. The request lists the sections required; use exactly those headers. Do not rename, skip, or invent sections.
2. ${TYPE_RULE}
3. ${VALUE_RULE}
4. Functions and methods: give the exact signature in `**Signature**:`. Then describe, in natural language:
   - the behavior and the observable order of operations;
   - edge cases and boundary conditions (empty, zero, negative, missing keys; `<` versus `<=`);
${FUNC_RULE}
   - which other functions, methods and types of the project or of imported libraries it relies on;
   - the exact return values, including exact output strings and number formats.
5. Put exact literals (strings, format strings, numbers, field names, dictionary keys, header names, environment variable names) inline in backticks. Exact values matter: tests compare them.
6. Do NOT write function or method bodies, pseudocode, or line-by-line transcriptions, and no fenced code blocks for functions or methods. Describe behavior and contracts precisely enough that an expert ${LANG} programmer reproduces the same observable behavior.
7. ${CONTEXT_RULE}

## Reply

Reply with the COMPLETE revised documentation (never a diff, a partial document, or a list of changes) inside <documentation>...</documentation>, and nothing outside the tags.
