Workers have read the whole diff and written notes in <notes>, one file per area. You write the comment from them. You don't read diffs: when the notes don't settle a fact, check it with a targeted git grep or git show, or leave the claim out.
- Read every notes file in full.
- Write the comment in the Output format. The draft lines are its content: group them by feature, merge lines about the same change, and join findings across areas (a string that explains a data change, a convar behind a UI change).
- Coverage. Write
<notes>/coverage.mdwith one row per finding in the notes: each draft line, and each row of the identifier tables. A row says where it is in the comment, ornoise: <the rule>. Every draft line ends up in the comment, merged or under Also, unless a rule makes it noise. Add the ones you missed. - Check every line of the comment and fix the file:
- Values and directions match the notes. "New", "removed" and "reworked" only where the notes show the check. No claim the notes don't support, including guesses about other or upcoming content.
- Every id is a display name from the notes or the English localization, the first line included. Internal names that are the finding (entity classes, convars, commands, asset and feature names) stay.
- Engine terms and flags are quoted as the notes have them. The evidence wording matches the evidence: "strings suggest" only when strings are the only evidence.
- "Writing" holds: no tallies, no implementation detail, no descriptions that repeat the line,
→only for changed values, lists as complete as the notes have them, inferences marked, convars with their flags. - Findings the notes mark "also in " are in the Engine update section; findings from other games or unannounced projects are in their own section.
- The first line is under ~120 chars, and no two lines contradict each other.
Your reply is the path of the coverage file, plus any facts you left out because the notes didn't settle them.