Document balance snippet format

[lL1l1]

Description of the proposed changes

Documents balance snippet format.

Checklist

- [ ] Changes are annotated, including comments where useful
- [ ] Changes are documented in a changelog snippet according to the guidelines.

• Request 2-3 reviewers from the list of reviewers and their areas of knowledge.

Summary by CodeRabbit

• Documentation
  • Added comprehensive documentation outlining the structure of balance snippet files, including file naming conventions, header formatting, parameter change entry details, and glossary-style explanations for key fields such as PR Number, Description, Formatted Unit Name, Blueprint ID, Section, Parameter Name, and before/after Values.

[coderabbitai]

📝 Walkthrough

Walkthrough

This change adds documentation for the balance snippet file structure, detailing naming conventions, header formatting, parameter change entries, and glossary definitions for key metadata fields.

Changes

Cohort / File(s)	Summary
Documentation docs/development-changelog/balance-snippet.md	Added documentation explaining balance snippet file structure, including file naming conventions, header formatting, parameter change entries, and glossary entries for metadata fields (PR Number, Description, Formatted Unit Name, Blueprint ID, Section, Parameter Name, Value).

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~3 minutes

Suggested reviewers

• Rhaelya
• BlackYps

Poem

🐰 A balance sheet takes form with care,
With snippets documented fair,
Each field and line now crystal clear,
The changelog structure appears right here! 📋✨

🚥 Pre-merge checks | ✅ 2 | ❌ 1

❌ Failed checks (1 inconclusive)

Check name	Status	Explanation	Resolution
Description check	❓ Inconclusive	The description covers the main change but is minimal; required sections like 'Testing done' and 'Additional context' are missing entirely, and the description lacks detail despite the template providing structure.	Add 'Testing done' section describing how the documentation was reviewed, and expand 'Additional context' to explain the purpose and scope of the balance snippet documentation.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title 'Document balance snippet format' directly and specifically describes the main change—adding documentation for the balance snippet format structure.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

No actionable comments were generated in the recent review. 🎉

🧹 Recent nitpick comments

docs/development-changelog/balance-snippet.md (1)

13-20: Add a language to the fenced code block.

Markdownlint MD040 flags this; specify a language like md or text for consistency.

♻️ Proposed fix

-```
+```md
 - (#<PR Number>) <Description>
 
   **<Formatted Unit Name> (<Blueprint ID>):**
   - <Section>
     - <Parameter Name>: <value before> --> <value after>
     - <Parameter Name>: <value before> --> <value after>

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[BlackYps]

I might be mistaken, but I think we do not yet link to https://faforever.github.io/fa/ anywhere. We should do that. Can you maybe find a good place in the main readme?

[Basilisk3]

Looks good. It could be beneficial to explicitly specify which database should be used for the formatted unit name. I use Spooky.

[lL1l1]

I might be mistaken, but I think we do not yet link to https://faforever.github.io/fa/ anywhere. We should do that. Can you maybe find a good place in the main readme?

I don't know where to put it because a lot of the website content overlaps with the linked markdown files in the readme.

[lL1l1]

Looks good. It could be beneficial to explicitly specify which database should be used for the formatted unit name. I use Spooky.

I explicitly wrote the format for future-proofing. Referencing spooky db feels awkward because etfreeman db is replacing it and it doesn't have that exact same format. Using spooky db just to copy paste the format while using etfreeman db for stats is awkward as well.