An existing PR title and body are provided in <existing_pr>, along with a commit log in <commit_log>, changed files in <changed_files>, and a diff in <diff>. Update the PR title and body to reflect new commits. <commit_log>, <changed_files>, and <diff> cover only the commits added since <existing_pr> was written — they are a slice of the branch, not its current state. The rest of the branch is still present but is not shown to you, so <existing_pr> is the only record of it: never delete, narrow, or rewrite existing content on the grounds that those three do not mention it. Carry all of it forward and extend it with the new commits. PRESERVATION RULES. Treat <existing_pr> as authoritative for all content it covers. Copy it verbatim — same wording, punctuation, capitalization, bullet order, section order, and section headers. Stylistic rewording is forbidden; factual correction from new commits is required. Title — rewrite ONLY if new commits change the Conventional Commits type or scope, OR if the title's claim is now inaccurate (e.g. the feature was renamed, narrowed, or reverted in new commits). Otherwise leave byte-identical. Existing prose and bullets — rewrite ONLY if a new commit invalidates the claim (e.g. a later commit changes the described behavior). Remove ONLY if the change was fully reverted. Otherwise leave byte-identical — do NOT adjust phrasing, tense, punctuation (periods, dashes, em-dashes, commas), or capitalization. Section headers and section order — never change; in particular, do not restructure an existing body to match the section scheme described below, and do not add headings to an existing body that has none. Adding new content — extend the existing section that covers the same concern, appending to the end of it. Do not interleave with or reorder existing content. Add a new section only if new commits introduce a concern no existing section covers. Intra-branch churn — if a new commit is a fix/refactor of code introduced earlier in this same branch, prefer correcting the existing description in place (if its claim is now wrong) over adding new content. Do not describe the churn itself. If uncertain whether a change is warranted, prefer no change. 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. When you do change the type, choose it 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. Keep the existing body's shape — its sections, their order, and whether it has headings at all. The structure, voice, and verification rules that follow govern only content you add; they never license restructuring or restyling what <existing_pr> already covers. Structure the body by purpose, never by conventional commit type: do not group changes under type headings such as "### Features", "### Bug Fixes", "### Refactors", or "### Docs". Length. The body orients a reviewer before they read the diff; it does not replace the diff. Scale it to the number of distinct concerns a reviewer must hold in their head, not to the size of the diff — a large but mechanical change still gets a short body. Aim for 200 words outside "## Verification" and treat 400 as a hard ceiling. Give each concern one paragraph at most, and give a secondary concern a single sentence rather than a paragraph or a section of its own. Name the mechanism and the reason for it, then stop: do not walk through every case, branch, fallback, or deleted helper the implementation handles, and do not explain why a rejected alternative was rejected more than once — the diff carries that detail for the reader who wants it. If a sentence is true but would not change what the reviewer does, cut it. Sections. Scale the structure the same way. A PR with a single concern and a small diff gets two or three sentences of prose and no headings at all — do not pad it into sections. A PR with one substantial concern gets "## Overview" (or "## Problem", when the PR fixes something that was broken) followed by "## Change" (or "## Fix"). A PR spanning several distinct concerns gets the full set in this order: "## Overview" or "## Problem", then "## Change" or "## Fix", then "## How it works" only when the mechanism is non-obvious and the diff shows why, and then in a single paragraph, then "## Deployment" only when the diff shows that merging alone does not ship the change (deployment manifests, pinned image tags, infrastructure config, release assets), then "## Sequencing" only when the commit log or existing PR context shows this branch depends on or blocks another. Never add a catch-all section for whatever the other sections did not cover. Omit every section you have nothing concrete to put in; an empty or restated section is worse than no section. Inside a section, use bullets only for genuinely parallel items and prefer prose for anything with cause and effect. Voice. Lead with the cause, not a restatement of the diff: open by naming what was broken, missing, or needed and why, then what the PR does about it. Name code directly — files, functions, classes, flags, and config keys in backticks — wherever naming it explains the change better than a paraphrase would; never include line numbers, and never name a file, symbol, or call site that the provided diff and commit log do not evidence. Be concrete: counts, versions, dates, and durations that the context actually shows are worth stating, but never invent a number, a measurement, a production impact, or an observed behavior you cannot derive from the context you were given. State what the PR deliberately does not change when a reader would otherwise assume it does. When the diff or commit messages show an alternative was tried and rejected, say what it was and why it failed in a single sentence. When the change makes a trade-off, name it plainly instead of hiding it. Write flatly: no marketing adjectives, no "seamlessly", "robust", "comprehensive", "significantly improved", or "greatly enhances", and no closing sentence that just restates the section above it. Verification. Close the body with a "## Verification" section giving the concrete steps a reviewer can run to confirm the change works: real commands for this repo — its test runner, linters, build commands, or CLI invocations — using the actual paths, flags, and file names the diff shows, in a fenced bash code block when they are commands and a short numbered list when they are manual or UI steps. Keep it to the smallest set of steps that actually proves the change, and say what a passing result looks like. When this PR adds tests, point the reviewer at them by name in the same breath rather than describing what each one covers. When a step creates disposable or billable resources, include the cleanup command. Never claim you ran anything, that tests pass, or that any check is currently green — you have executed nothing; write only what the reviewer should do and what they should expect to see. If the context gives you nothing specific enough to be worth running, omit the section entirely rather than padding it with generic advice. On a PR small enough to carry no headings, fold the check into a closing sentence instead of a section. 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. These two markers are the only ones that exist: the body simply ends the response, so never emit a closing marker such as ===END===. Do not wrap the response as a whole, or the title line, in a code block or backticks — fenced code blocks inside the body are content and are expected wherever you give the reader commands to run.