Codex 收尾官：把已寫好的改動整理成語意化 commit + 一份能過審的 PR

You are finishing a change in this git repo by producing a clean commit and a reviewable pull request. Base everything on the ACTUAL diff — never on assumptions about what I intended.

Follow any commit/PR conventions defined in AGENTS.md. If none are specified there, default to Conventional Commits.

STEP 1 — Inspect reality.
- Run `git status` and `git diff --staged` (and `git diff` for unstaged) and read the changes.
- If nothing is staged, tell me, and propose a sensible staging grouping rather than blindly `git add -A`. Do NOT stage unrelated changes (build artifacts, unrelated files, debug prints) into the same commit — flag them.
- Identify whether this is logically ONE change or several. If it should be multiple commits, tell me how you'd split it and ask before combining.

STEP 2 — Write the commit message.
Format: {{COMMIT_CONVENTION}}.
- Subject line: imperative mood, <= ~72 chars, correct type + scope (e.g. `fix(auth): ...`). The type must match what the diff actually does (a refactor is not a `feat`).
- Body (only if the change isn't trivial): explain the WHY and any non-obvious decisions, wrapped sensibly. Reference the issue/ticket {{ISSUE_REF}} if provided.
- Do not claim tests were added/passing unless the diff actually contains them or you actually ran them.
Show me the proposed message and let me approve before committing.

STEP 3 — Open the PR.
Target base branch: {{BASE_BRANCH}}.
Before writing the description, optionally run a self-review of the diff for obvious bugs, security issues, or leftovers (secrets, console logs, commented-out code) and surface them to me first.
Then draft a PR description with these sections:
- **What** — what this PR changes, in plain language.
- **Why** — the motivation / problem being solved (link {{ISSUE_REF}} if any).
- **How** — key implementation decisions and anything a reviewer should look at closely.
- **Testing** — exactly how it was verified (commands run + result). If you did not run them, say "not yet verified" — do not fabricate green checks.
- **Risk / rollback** — what could break and how to revert.
- **Out of scope** — explicitly what this PR does NOT do.
Keep it scannable: short paragraphs and bullets, no filler.

STEP 4 — Create it.
If the GitHub CLI (`gh`) is available, create the PR against {{BASE_BRANCH}} using the message and description above and return the PR URL. If `gh` is not available or not authenticated, instead output the final commit command and a ready-to-paste PR title + body so I can open it manually. Confirm before pushing to any remote.

Guardrails: never force-push, never push to {{BASE_BRANCH}} directly, and never invent ticket numbers, reviewers, or test results.

You are finishing a change in this git repo by producing a clean commit and a reviewable pull request. Base everything on the ACTUAL diff — never on assumptions about what I intended.

Follow any commit/PR conventions defined in AGENTS.md. If none are specified there, default to Conventional Commits.

STEP 1 — Inspect reality.
- Run `git status` and `git diff --staged` (and `git diff` for unstaged) and read the changes.
- If nothing is staged, tell me, and propose a sensible staging grouping rather than blindly `git add -A`. Do NOT stage unrelated changes (build artifacts, unrelated files, debug prints) into the same commit — flag them.
- Identify whether this is logically ONE change or several. If it should be multiple commits, tell me how you'd split it and ask before combining.

STEP 2 — Write the commit message.
Format: {{COMMIT_CONVENTION}}.
- Subject line: imperative mood, <= ~72 chars, correct type + scope (e.g. `fix(auth): ...`). The type must match what the diff actually does (a refactor is not a `feat`).
- Body (only if the change isn't trivial): explain the WHY and any non-obvious decisions, wrapped sensibly. Reference the issue/ticket {{ISSUE_REF}} if provided.
- Do not claim tests were added/passing unless the diff actually contains them or you actually ran them.
Show me the proposed message and let me approve before committing.

STEP 3 — Open the PR.
Target base branch: {{BASE_BRANCH}}.
Before writing the description, optionally run a self-review of the diff for obvious bugs, security issues, or leftovers (secrets, console logs, commented-out code) and surface them to me first.
Then draft a PR description with these sections:
- **What** — what this PR changes, in plain language.
- **Why** — the motivation / problem being solved (link {{ISSUE_REF}} if any).
- **How** — key implementation decisions and anything a reviewer should look at closely.
- **Testing** — exactly how it was verified (commands run + result). If you did not run them, say "not yet verified" — do not fabricate green checks.
- **Risk / rollback** — what could break and how to revert.
- **Out of scope** — explicitly what this PR does NOT do.
Keep it scannable: short paragraphs and bullets, no filler.

STEP 4 — Create it.
If the GitHub CLI (`gh`) is available, create the PR against {{BASE_BRANCH}} using the message and description above and return the PR URL. If `gh` is not available or not authenticated, instead output the final commit command and a ready-to-paste PR title + body so I can open it manually. Confirm before pushing to any remote.

Guardrails: never force-push, never push to {{BASE_BRANCH}} directly, and never invent ticket numbers, reviewers, or test results.