bug PR验证

You are operating inside a Daytona sandbox with a freshly-cloned checkout of {{repo}} at the current working directory. Dependencies are already installed using {{packageManager}} (use {{packageManager}} test, {{packageManager}} run <script>, etc. throughout; never substitute another tool).

The repo you're working in ({{repo}}) is the fork that will receive your branch + PR. The issue lives on {{issueRepo}} (typically the upstream parent of {{repo}}, since GitHub disables issues on forks by default). Treat them as two separate concerns: read the issue from {{issueRepo}}, push and PR against {{repo}}.

Your task: fix issue #{{issueNumber}} end-to-end. Issue payload:

{{issueData}}

Follow these phases in order. Do not skip phases. Do not combine phases.

Work directly in this session. Do NOT call the task tool to delegate this skill (or any of its phases) to a sub-agent. You have full access to read, write, edit, bash, grep, and glob tools here, plus the entire repository checkout in the current working directory. Delegating wastes round-trips and quickly hits Flue's task-depth limit.

Phase 1: Understand

1. Read the issue body carefully. Identify the expected behavior, the actual behavior, and any reproduction steps the reporter mentioned.
2. Inspect the project layout: read package.json, README.md, and AGENTS.md if present. Identify the test framework (vitest, jest, node:test, tsx test runner, etc.) and the test command.
3. Locate the source file(s) most likely involved in the bug. Read them fully — do not skim.
4. Read at least one existing test file to learn the project's testing conventions (file naming, import style, assertion library).

Phase 2: Reproduce

1. Create a new git branch named flue/fix-issue-{{issueNumber}}.
2. Write a single, focused test that asserts the expected behavior described in the issue. The test must currently fail because of the bug.
3. Run the test command. The test must fail. If it passes, you have not reproduced the bug — re-read the issue and try again.
4. Save the failing test output. You will reference it in the PR body.

Phase 3: Fix

1. Make the minimal code change required to make the failing test pass.
2. Do not refactor unrelated code. Do not reformat untouched files. Do not edit lockfiles.
3. Run the full test suite. All tests must pass, including pre-existing ones.

Phase 4: Pull Request

1. Stage and commit the changes with a clear conventional-style message: fix: <one-line summary> (#{{issueNumber}})

2. Push the branch to the fork ({{repo}}): git push origin flue/fix-issue-{{issueNumber}}.

3. Open a pull request against the fork's own default branch (not upstream). Pin both --repo and --base explicitly so gh doesn't accidentally target {{issueRepo}}:

   gh pr create --repo {{repo}} \
     --base $(gh repo view {{repo}} --json defaultBranchRef --jq '.defaultBranchRef.name') \
     --head flue/fix-issue-{{issueNumber}} \
     --title "fix: <summary>" \
     --body "..."
   

   Use this PR body structure:

   Closes {{issueRepo}}#{{issueNumber}}
   
   ## Reproduction
   <paste the failing test output captured in Phase 2>
   
   ## Fix
   <one paragraph explaining the root cause and the change>
   
   ## Verification
   <paste the passing test output from Phase 3>
   
   ---
   Generated by a Flue + Daytona bug-fix agent.
   

   The cross-repo Closes {{issueRepo}}#{{issueNumber}} reference is required because the PR lives on the fork ({{repo}}) but the issue lives on the upstream ({{issueRepo}}). A bare Closes #{{issueNumber}} would point at the fork's own issue tracker, which is empty by default.

Output

Return a structured result with these fields:

• branch: the branch name you created
• prUrl: the URL of the pull request you opened
• testFile: the path of the test file you added or modified
• filesChanged: the array of file paths you changed (relative to repo root)
• summary: one sentence describing the root cause and your fix

Hard rules

• Do NOT use the task tool. Work directly in this session.
• The failing test MUST fail before the fix and MUST pass after the fix. No exceptions.
• The fix must be minimal. If you find yourself touching more than two source files, stop and reconsider.
• Never disable, skip, or delete pre-existing tests.
• Never use --force on git push. Push to a fresh branch.
• If the issue is ambiguous or you cannot reproduce it after one honest attempt, return early with { branch: "", prUrl: "", testFile: "", filesChanged: [], summary: "<what context is missing>" }. Do not fabricate.