Generate a pull request title and body from the commit log in <commit_log>, changed files in <changed_files>, and full diff in <diff>. The title MUST use Conventional Commits format (feat:, fix:, refactor:, build:, chore:, docs:, style:, test:, perf:, ci:) on a single line, concise (under 70 characters): name the single most significant outcome the PR delivers, phrased from the reader's perspective — what users or developers gain — rather than listing internal changes or implementation details. Choose the title type by the most significant change in the PR, using the precedence feat > fix > perf > refactor > test > build > ci > docs > style > chore; only use test, build, ci, docs, style, or chore when the PR contains no feat, fix, perf, or refactor change. First frame the repo's user POV — who consumes what this repo produces and what they perceive as its output — and judge each change by its impact on that audience; "user-facing" is defined by that POV, so the same change can take different types in different repos, and a <repo_guidance> block stating the POV is authoritative. Classify each change by its role, not its file format or path: prompt, template, schema, query, and config files are functional code, but that applies to config that defines behavior, not to the values it pins — bumping a version, model id, dependency, or other pinned value without changing the behavior surface is chore, never feat; a script or helper that only runs inside the build, CI, or release pipeline is build or ci, never feat; documentation or generated files touched alongside real code or tests never make the PR docs or chore. Use ! (e.g. feat!:) when this PR would require a semver MAJOR version bump — i.e., it removes or incompatibly changes behavior that users of the current release rely on. Examples: removed command or flag, renamed required argument, changed output format that consumers parse. When in doubt, omit !. If the changed interface was introduced after the last tag (never shipped to consumers), it is not breaking — omit !. Follow with a blank line, then the PR body: group changes by conventional commit type using markdown headers (e.g. ### Features, ### Bug Fixes, ### Refactors, ### Docs) and list each change as a concise bullet under the relevant section. Only include sections that have changes. Phrase each bullet as a practical outcome from the reader's perspective — describe what users or developers can now do, what no longer happens, or what improved — rather than listing implementation steps or internal file changes. Keep each bullet to one concise sentence; avoid internal terminology (function names, file paths, rule names) unless they are the user-facing thing that changed. After the change sections, add a ### Test Plan section with a short bullet list of manual steps a reviewer can follow to verify the changes work. A <repo_guidance> block may precede the other context with repo-specific conventions — commit scopes this repo uses and overrides to the type-classification rules above; treat it as authoritative and apply its scopes and overrides when it conflicts with the rules above. Output ONLY the title and body, wrapped in exact line markers: a line containing exactly ===TITLE===, then the title on its own line, then a line containing exactly ===BODY===, then the body on the following lines. Write nothing before the ===TITLE=== marker and nothing outside these markers — no commentary, reasoning, character counts, or notes. Do not wrap anything in code blocks or backticks.