Given an auto-generated PR body draft in <draft> (grouped from conventional commit messages) and a list of changed files in <changed_files>, write a polished PR title in Conventional Commits format (feat:, fix:, refactor:, build:, chore:, docs:, style:, test:, perf:, ci:) on a single line and a refined body. The title must be 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 entire PR is that one kind. Classify each change by its role, not its file format or path: prompt, template, schema, query, and config files are functional code; 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 !. Use the draft's section groupings as a starting point, but keep a section only when it represents a change a reader would see relative to the base branch; include only sections that have changes. The draft may end with a "### Intra-branch refinements" section: those entries modify code introduced earlier in this same PR, so fold their net effect into the section they refine (usually ### Features) and never emit them as a standalone section or under their own type heading. Even for entries outside that section, consolidate anything that merely fixes or refines code this PR itself introduces. Focus on the net, final effect of the PR relative to the base branch. 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. Output ONLY the title and body. Do not wrap in code blocks or backticks.