Devolutions/IronRDP

Commit and PR conventions

Treat the PR title and initial body as the exact commit message that squash-and-merge will land.

Commit message

• Read repository instructions first. Derive scopes with the repository-local commit-scope skill. If unavailable, use explicit repository rules or omit the scope rather than inventing one.
• Follow Conventional Commits: <type>[optional scope][!]: <description>.
• Target 50 characters and describe the resulting behavior. Do not drop repository-required scopes to meet that target; when they make it impossible, keep the remaining description as concise as practical.
• Separate subject, body, and footers with blank lines.
• For standalone commits, wrap body lines at 72 characters. Explain why the change was needed, how it solves it, and material side effects.
• Put an existing ticket key or link in a footer, not the subject: Issue: PROJECT-123. Follow repository-specific footer format when an issue exists. When none exists, omit the footer rather than fabricating Issue: N/A.
• Add applicable Conventional Commit footers and Co-authored-by: Name <email> trailers for collaborators.
• Choose the type by the affected surface, not by whether the change fixes a defect.
• Use ci for CI, workflow, and automation changes, including fixes to that automation.
• Use fix for product or runtime bugs and non-feature changes to externally consumed public API boundaries.
• Use feat for features, build for build or dependencies, chore for non-product tools or configuration, docs for documentation only, style for non-semantic edits, refactor for internal restructuring, test for tests, and perf for performance.
• Mark breaking changes with ! or a BREAKING CHANGE footer without changing an otherwise accurate type.
• Keep every non-squashed development commit coherent and conventional.

fix(storage): preserve collated indexes

Normalize server-expanded collations before comparing index definitions.

Issue: PROJECT-123

Pull request

• Set the title to the intended squash commit subject exactly.
• Set the initial body to the intended squash commit body and footers exactly. Exclude PR-only preambles, checklists, and implementation journals.
• Do not manually wrap the PR body; GitHub handles display wrapping.
• Keep permanent history concise: record motivation, material behavior, and side effects.
• Put experiments, alternatives, extensive validation, and implementation chronology in follow-up comments.
• Post a follow-up comment with the lines changed, split at least into production code, tests, and other files, so a reviewer sees where the change's weight lies before reading it; how to count and present them is yours, and refresh it when the diff changes materially.
• Update the title and initial body as the implementation evolves.
• Before opening, updating, or merging, read title + blank line + body as one commit message and correct any mismatch.