chore(snapshot): update canonical snapshot

[github-actions]

User description

Automated update of canonical snapshot generated from Linguist. Please review and merge.

---

PR Type

Other

---

Description

• Updates canonical snapshot from Linguist

• Automated snapshot generation and synchronization

---

Diagram Walkthrough

flowchart LR
  Linguist["Linguist"] -- "generates snapshot" --> Snapshot["canonical/snapshot.json"]

Loading

File Walkthrough

	Relevant files
Configuration changes	snapshot.json Update canonical snapshot data                                                      canonical/snapshot.json Complete snapshot file update from Linguist Contains canonical language definitions and configurations Automated generation for consistency +14104/-0

---

[mikkihugo]

Reopening to trigger Bot Review Gate workflow

[qodo-code-review]

PR Compliance Guide 🔍

Below is a summary of compliance checks for this PR:

Security Compliance
🟢	No security concerns identified No security vulnerabilities detected by AI analysis. Human verification advised for critical code.
Ticket Compliance
⚪	🎫 No ticket provided Create ticket/issue
Codebase Duplication Compliance
⚪	Codebase context is not defined Follow the guide to enable codebase context checks.
Custom Compliance
⚪	Generic: Comprehensive Audit Trails Objective: To create a detailed and reliable record of critical system actions for security analysis and compliance. Status: Diff not provided: The PR adds/updates canonical/snapshot.json but its contents were not included in the diff, so we cannot verify whether any critical actions introduced by this change are appropriately audit-logged with required context. Referred Code [ { Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Meaningful Naming and Self-Documenting Code Objective: Ensure all identifiers clearly express their purpose and intent, making code self-documenting Status: Diff not provided: The PR’s only changed artifact (canonical/snapshot.json) was not provided, so identifier/key naming and self-documenting conventions cannot be assessed. Referred Code [ { Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Robust Error Handling and Edge Case Management Objective: Ensure comprehensive error handling that provides meaningful context and graceful degradation Status: Diff not provided: Because the actual snapshot content is not visible in the diff, we cannot determine whether the update affects code paths that require additional error handling or edge-case protections in snapshot generation/consumption. Referred Code [ { Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Secure Error Handling Objective: To prevent the leakage of sensitive system information through error messages while providing sufficient detail for internal debugging. Status: Diff not provided: The snapshot file contents are not available, so we cannot verify whether any user-facing error messages or embedded diagnostic details could leak internal system information. Referred Code [ { Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Secure Logging Practices Objective: To ensure logs are useful for debugging and auditing without exposing sensitive information like PII, PHI, or cardholder data. Status: Diff not provided: Since canonical/snapshot.json is not shown, we cannot verify it does not contain sensitive data (e.g., tokens, secrets, or PII) that could end up being logged or otherwise exposed. Referred Code [ { Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Security-First Input Validation and Data Handling Objective: Ensure all data inputs are validated, sanitized, and handled securely to prevent vulnerabilities Status: Snapshot content review: The snapshot JSON content is not included, so we cannot validate whether it introduces/contains unsafe or sensitive data that requires sanitization, access controls, or other secure handling measures. Referred Code [ { Learn more about managing compliance generic rules or creating your own custom rules

Compliance status legend

🟢 - Fully Compliant
🟡 - Partial Compliant
🔴 - Not Compliant
⚪ - Requires Further Human Verification
🏷️ - Compliance label

[qodo-code-review]

PR Code Suggestions ✨

Explore these optional code suggestions:

Category	Suggestion	Impact
High-level	Avoid committing large generated files Do not commit the large, auto-generated snapshot.json file. Instead, generate it dynamically during the build or deployment process to prevent repository bloat and reduce commit noise. Examples: canonical/snapshot.json [1-14104] [ { "id": "1c enterprise", "name": "1C Enterprise", "extensions": [ "bsl", "os" ], "aliases": [], "tree_sitter_language": null, ... (clipped 14094 lines) Solution Walkthrough: Before: // Git repository tracks the large generated file. // canonical/snapshot.json (14000+ lines) // CI/CD Pipeline // 1. An automated process updates snapshot.json. // 2. A PR is opened to commit the new version. // 3. The build process uses the committed file. After: // .gitignore /canonical/snapshot.json // Git repository does not track snapshot.json. // CI/CD Pipeline // 1. On build/deployment: // 2. Run script to generate canonical/snapshot.json. // 3. Use the generated file for the build. // 4. The generated file is not committed to the repository. Suggestion importance[1-10]: 9 __ Why: The suggestion addresses a critical repository management issue by advising against committing a large, auto-generated file, which is a widely accepted best practice.	High
More

[qodo-code-review]

PR Compliance Guide 🔍

Below is a summary of compliance checks for this PR:

Security Compliance
🟢	No security concerns identified No security vulnerabilities detected by AI analysis. Human verification advised for critical code.
Ticket Compliance
⚪	🎫 No ticket provided Create ticket/issue
Codebase Duplication Compliance
⚪	Codebase context is not defined Follow the guide to enable codebase context checks.
Custom Compliance
⚪	Generic: Comprehensive Audit Trails Objective: To create a detailed and reliable record of critical system actions for security analysis and compliance. Status: Diff not provided: The PR diff for canonical/snapshot.json was not included, so it cannot be verified whether any new/changed behavior introduces critical actions requiring audit logging. Referred Code [ { Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Meaningful Naming and Self-Documenting Code Objective: Ensure all identifiers clearly express their purpose and intent, making code self-documenting Status: Snapshot content unseen: The contents of canonical/snapshot.json were not provided, so it cannot be verified whether any new keys/fields use meaningful, self-documenting naming. Referred Code [ { Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Robust Error Handling and Edge Case Management Objective: Ensure comprehensive error handling that provides meaningful context and graceful degradation Status: No code context: Only canonical/snapshot.json is referenced without diff context, so it cannot be determined whether any related generation/consumption paths need additional error handling or edge-case management. Referred Code [ { Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Secure Error Handling Objective: To prevent the leakage of sensitive system information through error messages while providing sufficient detail for internal debugging. Status: No error paths shown: The PR diff does not include any application code or error-handling changes, so it cannot be confirmed that no user-facing errors leak internal details related to snapshot generation/usage. Referred Code [ { Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Secure Logging Practices Objective: To ensure logs are useful for debugging and auditing without exposing sensitive information like PII, PHI, or cardholder data. Status: Logging not visible: No logging statements or diff content were provided, so it cannot be verified whether snapshot generation/consumption logs remain structured and free of sensitive data. Referred Code [ { Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Security-First Input Validation and Data Handling Objective: Ensure all data inputs are validated, sanitized, and handled securely to prevent vulnerabilities Status: Data handling unseen: The PR references an updated canonical/snapshot.json but does not include the diff or any consumer code changes, so it cannot be verified that inputs are validated/sanitized and that no sensitive data is introduced or exposed. Referred Code [ { Learn more about managing compliance generic rules or creating your own custom rules

Compliance status legend

🟢 - Fully Compliant
🟡 - Partial Compliant
🔴 - Not Compliant
⚪ - Requires Further Human Verification
🏷️ - Compliance label

[qodo-code-review]

PR Code Suggestions ✨

Explore these optional code suggestions:

Category	Suggestion	Impact
Possible issue	Remove obsolete language entry Remove the obsolete "Cairo Zero" language entry to resolve the .cairo file extension conflict with the "Cairo" language entry. canonical/snapshot.json [1673-1688] +... +"id": "cairo", +"name": "Cairo", +"extensions": [ + "cairo" +], +... - [To ensure code accuracy, apply this suggestion manually] Suggestion importance[1-10]: 5 __ Why: The suggestion correctly identifies a file extension conflict between Cairo and the obsolete Cairo Zero, and proposes removing the obsolete entry to resolve ambiguity.	Low
	Resolve file extension conflict Remove the .re extension from the C++ language definition to resolve a conflict with the "Reason" programming language. canonical/snapshot.json [1324-1345] ... "id": "c++", "name": "C++", "extensions": [ "cpp", "c++", "cc", "cp", "cppm", "cxx", "h", "h++", "hh", "hpp", "hxx", "inc", "inl", "ino", "ipp", "ixx", - "re", "tcc", "tpp", "txx" ], ... [To ensure code accuracy, apply this suggestion manually] Suggestion importance[1-10]: 5 __ Why: The suggestion correctly identifies that the .re extension for C++ conflicts with the "Reason" language, and removing it prevents misclassification of files.	Low
	Remove ambiguous language alias Remove the ambiguous alias "adb" from "Adblock Filter List" to avoid conflict with the "Ada" language extension. canonical/snapshot.json [341-346] ... "aliases": [ "ad block filters", "ad block", - "adb", "adblock" ], ... [To ensure code accuracy, apply this suggestion manually] Suggestion importance[1-10]: 4 __ Why: The suggestion correctly identifies that the alias adb for "Adblock Filter List" conflicts with the adb extension for "Ada", and removing it improves data consistency.	Low
More

[qodo-code-review]

PR Compliance Guide 🔍

Below is a summary of compliance checks for this PR:

Security Compliance
🟢	No security concerns identified No security vulnerabilities detected by AI analysis. Human verification advised for critical code.
Ticket Compliance
⚪	🎫 No ticket provided Create ticket/issue
Codebase Duplication Compliance
⚪	Codebase context is not defined Follow the guide to enable codebase context checks.
Custom Compliance
⚪	Generic: Comprehensive Audit Trails Objective: To create a detailed and reliable record of critical system actions for security analysis and compliance. Status: Diff not provided: The PR adds canonical/snapshot.json but its contents are not included in the diff, so it cannot be verified whether any critical-action audit logging requirements are impacted. Referred Code [ { Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Meaningful Naming and Self-Documenting Code Objective: Ensure all identifiers clearly express their purpose and intent, making code self-documenting Status: Diff not provided: The added snapshot file content is not available in the provided diff, so naming/readability impacts (if any tooling code or schema fields changed) cannot be assessed. Referred Code [ { Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Robust Error Handling and Edge Case Management Objective: Ensure comprehensive error handling that provides meaningful context and graceful degradation Status: Diff not provided: Without the contents of canonical/snapshot.json, it cannot be verified whether snapshot generation/consumption changes introduce missing validation or unhandled edge cases elsewhere. Referred Code [ { Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Secure Error Handling Objective: To prevent the leakage of sensitive system information through error messages while providing sufficient detail for internal debugging. Status: Diff not provided: The snapshot file contents are not shown, so it cannot be confirmed that no sensitive internal error details are being captured/propagated through snapshot-related mechanisms. Referred Code [ { Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Secure Logging Practices Objective: To ensure logs are useful for debugging and auditing without exposing sensitive information like PII, PHI, or cardholder data. Status: Snapshot content unknown: Because canonical/snapshot.json content is not included, it cannot be validated that the snapshot does not contain sensitive data that could be logged or otherwise exposed by consumers. Referred Code [ { Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Security-First Input Validation and Data Handling Objective: Ensure all data inputs are validated, sanitized, and handled securely to prevent vulnerabilities Status: Snapshot content unknown: The PR adds a snapshot file but its contents are not available, so it cannot be verified that no unsafe/unvalidated external data or sensitive material is present or newly relied upon by downstream code. Referred Code [ { Learn more about managing compliance generic rules or creating your own custom rules

Compliance status legend

🟢 - Fully Compliant
🟡 - Partial Compliant
🔴 - Not Compliant
⚪ - Requires Further Human Verification
🏷️ - Compliance label

[qodo-code-review]

PR Code Suggestions ✨

Explore these optional code suggestions:

Category	Suggestion	Impact
General	Sort entries by ID Sort the array of language objects alphabetically by their id to ensure a deterministic order, which will simplify future diffs and manual lookups. canonical/snapshot.json [1-14104] [ { "id": "1c enterprise", "name": "1C Enterprise", - … + … }, { "id": "2-dimensional array", "name": "2-Dimensional Array", … }, { "id": "4d", "name": "4D", … }, - … + … (sorted order) ] Apply / Chat Suggestion importance[1-10]: 8 __ Why: The suggestion correctly identifies that the large list of languages is unsorted, and sorting it by id would significantly improve the file's maintainability by making future changes and reviews much easier.	Medium
	Remove null properties Remove properties with null values, such as "pattern_signatures": null, from all language objects to reduce file size and improve readability. canonical/snapshot.json [17] -"pattern_signatures": null +// (line removed) Apply / Chat Suggestion importance[1-10]: 6 __ Why: This is a valid suggestion that improves the data file's conciseness and reduces its size by removing redundant null properties, which is a good practice.	Low
High-level	Generate snapshot during the build process Instead of committing the large, auto-generated snapshot.json file to the repository, generate it during the build process and treat it as a build artifact. This will prevent repository bloat and keep the commit history cleaner. Examples: canonical/snapshot.json [1-14104] [ { "id": "1c enterprise", "name": "1C Enterprise", "extensions": [ "bsl", "os" ], "aliases": [], "tree_sitter_language": null, ... (clipped 14094 lines) Solution Walkthrough: Before: # Current Workflow (inferred) 1. A script is run to generate `snapshot.json` from an external source (Linguist). 2. The generated `snapshot.json` is added to the git repository. 3. A PR is created with the updated `snapshot.json`. 4. The file is now part of the version history. # .gitignore ... (does not include canonical/snapshot.json) After: # Proposed Workflow 1. The build/CI process includes a step to generate `snapshot.json`. 2. The generated file is used as a build artifact for subsequent steps. 3. The file is not committed to the repository. # .gitignore ... canonical/snapshot.json Suggestion importance[1-10]: 7 __ Why: The suggestion addresses a significant repository health and maintenance issue by proposing not to version a large, auto-generated file, which is a widely accepted best practice.	Medium
More