Code changes

====


QUALITY CODING RULES


# Code changes

1. If you find errors or suggestions in code which is not DIRECTLY related to user's current request, never change it without asking first.
2. Before suggesting changes to files, always assume user might have changed the file since your last read and consider reading the file again.


# Security

1. Never commit sensitive files
2. Use environment variables for secrets
3. Keep credentials out of logs and output


# Project Specifications

1. Project documentation is maintained in files in `docs/` folder.
2. `docs/project-overview.md` is a high level overview of project purpose and structure.
3. `docs/system-architecture.md` describes project architecture without implementation details (no method info, etc...)
4. Maintain these files to be up to date with project. Create them if they don't exist.
5. Reread `docs/project-overview.md` and `docs/system-architecture.md` often and whenever you need to refresh your context with what the project is about.
6. This should often be your first step in understanding a task.


# Software Development Behavior Guidelines

1. Don't guess and do things which you are not certain about. Ask the user instead.
2. Don't do or add code unrelated to user specific request and context at the moment.
3. When using git, only stage changes and propose a commit message. Let the user review the changes and commit them.
4. **Always** prior to finishing a task and considering it completed, revise all the changes and update Project Specification files.
5. **Always** prior to finishing a task and considering it completed, try to git stage everything and suggest commit message
6. When trying to fix any bug or compiler error **ALWAYS** think carefully and analyze in detail what happened and WHY? Explain and confirm with user.


# Code Conventions

1. Project structure contains `docs/`, `src/` and `test/` folders at the root
2. C# project folder and file names do not include namespaces.
3. Namespaces follow the pattern `{ProjectName}.{Module}`
4. Use `appsettings.json` for application settings and `appsettings.local.json` for local development settings (not committed to Git)
5. Markdown files should follow these formatting rules:
   - Headings should be surrounded by blank lines
   - Lists should be surrounded by blank lines
6. Code should be self-descriptive without XML-style comments
   - Only add comments for tricky or complex parts of the code
   - NO redundant and trivial comments that simply restate what the code does
7. Avoid parameterless constructors by default
   - Don't include default values for properties used in constructors
   - Only add parameterless constructors when needed for serialization or frameworks
8. Don't use async patterns preemptively
   - Only use async/await when it's really needed
   - Refactor to async patterns when encountering functionality that requires it
   - Prioritize code simplicity and readability
9. Private fields should not be prefixed with underscore
   - In constructors, parameters should have the same name as fields
   - Use `this.fieldName = fieldName` pattern for assignment
10. Always use `var` when the type is obvious from the right side of the assignment
11. Git commit messages should be concise and descriptive
    - Focus on the "what" and "why" rather than the "how"
    - Avoid listing specific properties, method names, or implementation details
12. Use declarative or functional code whenever possible (e.g. LINQ instead of for loops)


==== 

**Don't forget any of the 'QUALITY CODING RULES' above!!!**