fix: stronger style rules for filenames

Author: verytactical

.github/scripts/build_review_instructions.py

@@ -49,6 +49,7 @@ def main() -> None:
   • Findings may target `docs.json` when the issue is there (e.g., broken/duplicate slug, incorrect path, wrong ordering/grouping).
   • You may also use `docs.json` to verify that changed frontmatter `slug`/title or links in `.md`/`.mdx` remain valid.
   • Cite `docs.json` lines when it is the source of the problem; otherwise cite the offending `.md`/`.mdx` lines.
+  • If an issue relates to both `docs.json` and `.md`/`.mdx`, report it only on `docs.json`.
 - Do not speculate about Mintlify runtime behavior or external systems; rely solely on repository content.
 
 Severity policy:

contribute/style-guide-extended.mdx

@@ -766,6 +766,8 @@ Rationale: Clear, inclusive writing and accessible assets improve comprehension
 
 ## 16. File, navigation, and frontmatter conventions
 
+Content of this section mostly describes contents of `docs.json` and `[...](...)` markdown links in `.mdx` files.
+
 ### 16.1 Sidebar groups and ordering
 
 Objective. Keep navigation predictable and reduce decision points. (Why: consistent ordering helps readers find the right kind of page without scanning the whole section.)
@@ -779,11 +781,13 @@ Rules (binding).
 
 Objective. Keep repository structure and UI labels consistent. (Why: predictable structure speeds editing, improves search/TOC behavior, and reduces merge and build issues.)
 
-### 16.1 Files and titles
+### 16.2 Files and titles
 
-- Filenames **MUST** use kebab‑case.md or kebab‑case.mdx (e.g., `validator-setup.mdx`). (Why: kebab‑case avoids case‑sensitivity bugs, reads well in URLs, and is easy to grep.)
+- Filenames **MUST** use kebab‑case.md or kebab‑case.mdx (e.g., `validator-setup.mdx`). (Why: kebab‑case avoids case‑sensitivity bugs, reads well in URLs, and is easy to grep.) \[HIGH]
+- Filenames **MUST NOT** have uppercase characters, i.e. `foo-bAR.mdx`. \[HIGH]
+- Filenames **MUST NOT** have cyrillic characters, i.e. `сhoice.mdx`. \[HIGH]
 
-### 16.2 Navigation labels
+### 16.3 Navigation labels
 
 - Sidebar and nav labels **SHOULD** be short (2–4 words), unique, and mirror in‑page headings. (Why: short, unique labels prevent truncation and speed scanning.)
 
@@ -826,13 +830,13 @@ Objective. Keep repository structure and UI labels consistent. (Why: predictable
   ---
   ```
 
-### 16.3 Links and anchors
+### 16.4 Links and anchors
 
 - Internal links **MUST** be root‑absolute (start with `/`) and **MUST NOT** include `./` or `../`; ensure anchors are stable. (Why: root‑absolute links survive file moves and changes to the information architecture; relative segments break during reorganizations.) \[HIGH]
 - Trailing slashes: Follow a single repo‑wide policy set by the site generator, and apply it consistently across all internal links. (Why: consistency prevents duplicate routes, cache misses, and SEO issues.)
 - Cross‑section links **SHOULD** target specific anchors rather than page tops. (Why: deep links land readers directly on the needed detail.)
 
-### 16.4 Status labels
+### 16.5 Status labels
 
 - Pages and features **MAY** declare a status in content at the top of the page using an `<Aside>` with a clear title (e.g., `title="Deprecated"` or `title="Experimental"`). Do not introduce custom frontmatter keys for status. (Why: status is visible to readers and does not require unsupported metadata.)
 - If deprecated, the page **MUST** include the replacement (link to successor) and the removal timeline (date or version) in the callout. You **MAY** set `noindex: true` in frontmatter to exclude the page from search when appropriate. (Why: clear migration guidance reduces breakage; de‑indexing avoids surfacing outdated pages.)