When generating database entries from ddccontrol scannings, always read this:

Using the ddccontrol output from this GitHub issue, generate a conservative and minimally-assumptive monitor XML profile for ddccontrol-db.

Requirements:

* Create a new monitor XML file using the monitor PNP ID from the issue.
* Add a comment header at the top referencing the GitHub issue URL.
* Keep the XML style consistent with existing monitor definitions in the repository.
* Include `<include file="VESA"/>`.

Very important rules:

* Only treat controls with explicit non-`???` names in the ddccontrol output as known controls.
* Do NOT invent semantic mappings for controls marked as `???`.
* Do NOT infer monitor-specific enum values (such as input source mappings) unless they are explicitly confirmed by the issue itself.
* If values are borrowed from similar Dell monitor profiles, clearly label them as unverified candidate mappings.
* Unknown controls from the issue should remain present in the XML file, but commented out for future investigation.
* Prefer a conservative database entry over an aggressive one.
* Do not expose potentially destructive controls such as factory reset as active controls unless already standardized in existing ddccontrol-db Dell profiles.

Git workflow requirements:

* Create a new branch for the issue.
* Commit the generated XML file.
* Use a commit message containing:
  Fixes #<issue-number>
* Open a PR with a description explaining that:

  * the profile is intentionally conservative,
  * candidate mappings are commented out,
  * and hardware verification is requested from the issue author before enabling additional controls.

The goal is to create a safe initial profile suitable for distribution in packages without risking incorrect monitor-specific mappings.

## Preservation of existing functionality

The conservative-profile rules apply primarily to new controls and new semantic mappings. They must not be used as justification for removing, disabling, or commenting out functionality that is already present in an existing monitor profile.

Existing functionality may have been hardware-tested even when that verification is not documented in the repository. Therefore, do not assume that an existing mapping is untested or incorrect merely because supporting evidence cannot be found.

Preserve existing active controls and mappings unless there is concrete evidence that they are incorrect, unsafe, or causing a regression. If an existing mapping is uncertain, document the uncertainty and request hardware verification without removing the functionality.

## Git and PR hygiene

Do not include AI/vendor/tool branding in any Git metadata.

Forbidden examples:
- "[claude]"
- "[codex]"
- "claude/"
- "codex/"
- "generated-by-claude"
- "generated-by-codex"
- "co-authored-by: Claude"
- "co-authored-by: Codex"

This applies to:
- branch names
- commit messages
- PR titles
- PR descriptions
- changelog entries

Use normal human project conventions only.

Branch names should describe the work, for example:
- feature/add-minnye-support
- fix/handle-empty-config
- chore/update-ci-validation

Commit messages should follow Conventional Commits where applicable:
- feat: add minnye support
- fix: handle empty config
- test: cover invalid manifests
