docs(copilot): add Conventional Commits standards and scope guidance

- Document Conventional Commits 1.0.0 specification from Context7

- Add required types (feat, fix) and recommended types

- Define scopes as functional/logical areas, not physical projects

- Include common scopes: core, ui, logging, config, build, ci, tests, etc.

- Provide examples and guidance on when to use/omit scopes

- Document breaking change notation and footer conventions

- Cross-reference with Serena memory for consistency

Author: TimGels

.github/copilot-instructions.md

@@ -259,6 +259,149 @@ dotnet test --filter "FullyQualifiedName~BatchConfigurationTests"
 - **External tools**: mkvpropedit is executed with controlled arguments; validate user input before passing to command line
 - **File operations**: All file modifications require explicit user action (no automatic writes on scan)
 
+## Commit Message Standards
+
+**Copilot MUST follow [Conventional Commits 1.0.0](https://www.conventionalcommits.org/en/v1.0.0/) specification when generating commit messages.**
+
+### Format
+```
+<type>[optional scope]: <description>
+
+[optional body]
+
+[optional footer(s)]
+```
+
+### Required Types
+- `feat:` - A new feature (correlates with MINOR in SemVer)
+- `fix:` - A bug fix (correlates with PATCH in SemVer)
+
+### Recommended Types
+Additional types from @commitlint/config-conventional (Angular convention):
+- `build:` - Changes to build system or dependencies
+- `chore:` - Maintenance tasks
+- `ci:` - CI/CD configuration changes
+- `docs:` - Documentation changes
+- `style:` - Code style/formatting changes (no functional changes)
+- `refactor:` - Code refactoring without behavior change
+- `perf:` - Performance improvements
+- `test:` - Adding or updating tests
+- `revert:` - Reverting a previous commit
+
+### Scope (Optional)
+Scopes represent **what the change is about** (functional/logical areas), not just physical project locations.
+
+**Common scopes used in this codebase:**
+
+*Project layers:*
+- `core` - Core library logic (MatroskaBatchFlow.Core)
+- `ui` - Views, XAML, and presentation components
+- `vm` - ViewModels and MVVM patterns
+
+*Domain-specific:*
+- `validation` - Validation system (rules, engine, strictness modes)
+- `processing` - File processing pipeline and batch operations
+- `tracks` - Track configuration and track-level logic
+- `mkvtools` - mkvpropedit/MediaInfo integration
+
+*Infrastructure:*
+- `config` - Configuration and settings
+- `logging` - Logging system
+- `di` - Dependency injection and service registration
+- `nav` - Navigation system
+
+*Tooling:*
+- `deps` - Package dependencies
+- `dev` - Development tooling
+
+*Documentation:*
+- `instructions` - AI assistant instructions (copilot-instructions.md, Serena memories)
+
+*Release:*
+- `version` - Version management
+- `release` - Release and publishing
+
+> **Note:** `build`, `ci`, `docs`, and `test` are commit **types**, not scopes. Use them as types (e.g., `build: update project files`, `test: add validation tests`).
+
+**When to use a scope:**
+- Changes focus on a specific functional area or component
+- Examples: `feat(logging): add structured logging`, `fix(config): handle invalid JSON`, `refactor(ui): simplify navigation`
+
+**When to omit the scope:**
+- Changes are truly repository-wide or don't fit a single category
+- Examples: `chore: update all dependencies`, `docs: update README`
+
+**Multiple scopes:**
+- Use comma-separated scopes when changes span multiple areas: `refactor(core,ui): redesign batch processing`
+
+**Expanding scopes:**
+- The scopes above are common examples, not an exhaustive list
+- Create new scopes when needed for clarity (e.g., `feat(dialogs): add confirmation dialog`)
+
+### Breaking Changes
+- **Option 1**: Add `!` after type/scope: `feat(core)!: redesign batch processing API`
+- **Option 2**: Use footer: `BREAKING CHANGE: description` (MUST be uppercase)
+- Breaking changes correlate with MAJOR in SemVer
+
+### Body (Optional)
+- Provide additional context after a blank line
+- Free-form text, may contain multiple paragraphs
+- **Project preference**: Use bullet points for clarity
+
+### Footer(s) (Optional)
+Footers follow git trailer format (token: value or token #value):
+- `BREAKING CHANGE: <description>` - Breaking change details
+- `Refs: #123` - Reference issues
+- `Closes: #123` or `Fixes: #123` or `Resolves: #123` - Close issues
+- `Reviewed-by:`, `Acked-by:`, `See-also:` - Other standard git trailers
+
+### Examples
+
+**Simple feature:**
+```
+feat(core): add subtitle track reordering support
+```
+
+**Bug fix with body and footer:**
+```
+fix(ui): prevent UI freeze during large batch operations
+
+- Move batch processing to background thread
+- Add progress reporting with cancellation support
+- Update MainViewModel to marshal UI updates
+
+Closes: #89
+```
+
+**Breaking change with scope:**
+```
+feat(core)!: redesign track configuration API
+
+- Replace TrackConfiguration with immutable TrackInfo
+- Update all track ViewModels to use new API
+- Migration guide added to docs/migration.md
+
+BREAKING CHANGE: TrackConfiguration class removed, use TrackInfo instead
+Refs: #125
+```
+
+**Documentation update:**
+```
+docs: update README with mkvpropedit installation guide
+
+Refs: #42
+```
+
+### Important Rules
+- Type and description are REQUIRED
+- Description MUST immediately follow the colon and space
+- Scope MUST be a noun in parentheses if provided
+- BREAKING CHANGE footer MUST be uppercase
+- Breaking changes can use `!` in prefix OR footer (or both)
+- Tokens other than BREAKING CHANGE are case-insensitive
+
+> **Cross-reference**: Detailed Conventional Commits standards are also in Serena's memory (`.serena/memories/task_completion_checklist.md`). Keep both locations synchronized.
+
 ## **CRITICAL: Always Use Serena First (#serena MCP server)**
 
 **Serena is a semantic code analysis toolkit that provides IDE-like capabilities to AI assistants. It's designed for:**
@@ -361,7 +504,7 @@ dotnet test --filter "FullyQualifiedName~BatchConfigurationTests"
 2. Update relevant sections in this file
 3. Update Serena memories to match
 4. Update "Last Updated" date at the top
-5. Commit both code changes and instruction updates together
+5. Commit both code changes and instruction updates together using Conventional Commits format
 
 **Review cadence:**
 - Minor updates: As needed when patterns change

.serena/memories/task_completion_checklist.md

@@ -138,109 +138,14 @@ git commit -m @"
 ```
 
 ### Commit Message Format
-Follow the **[Conventional Commits 1.0.0](https://www.conventionalcommits.org/)** specification.
 
-**Structure:**
-```
-<type>[optional scope]: <description>
-
-[optional body]
-
-[optional footer(s)]
-```
-
-**Required Elements:**
-- **type**: Noun describing the change (e.g., `feat`, `fix`, `docs`, `style`, `refactor`, `perf`, `test`, `build`, `ci`, `chore`, `revert`)
-  - `feat`: New feature (correlates with MINOR in SemVer)
-  - `fix`: Bug fix (correlates with PATCH in SemVer)
-- **description**: Short summary immediately following `: ` (imperative mood, e.g., "add feature" not "adds feature")
-
-**Optional Elements:**
-- **scope**: Section of codebase in parentheses (e.g., `core`, `uno`, `cli`, `tests`)
-- **!**: Appended after type/scope to indicate breaking change
-- **body**: Additional context, begins one blank line after description, free-form
-  - *Project preference:* Use bullet points when listing multiple changes (not required, but preferred for clarity)
-- **footer(s)**: Metadata following git trailer format
-  - `Refs: #123` - References issue(s) without closing it
-  - `Closes: #123` (or `Fixes:`, `Resolves:`) - References and automatically closes issue(s) on GitHub
-  - Other footers: `See-also: #456`
-
-**Breaking Changes:**
-MUST be indicated by either (or both):
-- Appending `!` immediately before `:` (e.g., `feat!:` or `feat(api)!:`)
-- Footer with `BREAKING CHANGE: <description>` (MUST be uppercase)
-
-Breaking changes correlate with MAJOR in SemVer and can be part of any commit type.
-
-**Examples:**
-
-Commit with description only:
-```
-docs: correct spelling of CHANGELOG
-```
-
-Commit with scope:
-```
-feat(lang): add Polish language
-```
-
-Commit with body:
-```
-fix: prevent racing of requests
-
-Introduce a request id and a reference to latest request. Dismiss
-incoming responses other than from latest request.
-```
-
-Commit with bulleted body (project preference):
-```
-feat(cli): add recursive folder processing
+Follow **[Conventional Commits 1.0.0](https://www.conventionalcommits.org/)** specification.
 
-- Process nested folders in batch jobs
-- Preserve original file timestamps
-- Skip hidden/system files automatically
-```
-
-Breaking change with `!`:
-```
-feat(api)!: send an email to the customer when a product is shipped
-```
-
-Breaking change with footer:
-```
-feat: allow provided config object to extend other configs
-
-BREAKING CHANGE: `extends` key in config file is now used for extending other config files
-```
-
-Multiple footers:
-```
-fix: prevent racing of requests
-
-Introduce a request id and a reference to latest request. Dismiss
-incoming responses other than from latest request.
-
-Refs: #123
-```
-
-Closing an issue:
-```
-fix(core): handle empty MKV metadata gracefully
-
-- Return default values for missing track info
-- Log warning instead of throwing exception
-- Add unit tests for edge cases
-
-Refs: #38
-Closes: #42
-```
-
-Revert commit:
-```
-revert: let us never again speak of the noodle incident
-
-Refs: 676104e, a215868
-```
+See `.github/copilot-instructions.md` → **Commit Message Standards** section for:
+- Required and recommended types
+- Codebase-specific scopes
+- Breaking change conventions
+- Examples
 
 ## 8. Clean Up