fix: include verified upgrade files in pull requests

[JAIVIGNESH2002]

Summary

• Include verified repair file edits when TrueForge returns an incomplete changed-file payload.
• Support verified unified-diff repairs in changed-file enrichment.
• Reject manifest-only npm/pnpm upgrade PRs when the expected lockfile is missing.
• Support creating new files during GitHub PR file writes by omitting sha for missing paths.
• Preserve package manager on upgrade run snapshots for PR safety checks.

Agent changes

• src/lib/trueforge.ts: enriches verified repair results with all repaired files, including text replacements, full-file replacements, and unified diffs; fails the repair handoff instead of persisting partial verified evidence when enrichment cannot safely recover a touched file.
• src/lib/upgrade-run-store.ts: carries package-manager metadata through upgrade run snapshots so PR safety checks know which lockfile is required.
• src/app/api/repositories/upgrade-runs/pull-request/route.ts: blocks unsafe manifest-only dependency PRs and generates PR descriptions with agent changes, verification evidence, and remaining risk.
• src/lib/github.ts: supports both updating existing files and creating new files in generated upgrade PRs.
• Test files: add regression coverage for multi-file PR payloads, unified-diff repair enrichment, enrichment failure handling, and GitHub create-vs-update behavior.

Verification

• npm test -- src/lib/trueforge.test.ts src/lib/upgrade-run-store.test.ts src/app/api/repositories/upgrade-runs/pull-request/route.test.ts --runInBand
• npm test -- src/lib/trueforge.test.ts src/lib/github.test.ts --runInBand
• npm run typecheck
• npm run lint
• npm test
• npm run build
• git diff --check

Remaining risk

• No known remaining risk after the focused regression coverage and local quality gates above.
• This PR does not change the patched TrueForge server workflow itself; it hardens UpgradePilot against incomplete changedFiles payloads returned by that integration.
• Human review is still required before merge.

[qodo-code-review]

PR Summary by Qodo

Include verified repair files in dependency upgrade PRs

🐞 Bug fix 🧪 Tests 🕐 20-40 Minutes

AI Description

• Include verified repair edits omitted from TrueForge changed-file payloads.
• Reject npm and pnpm manifest-only upgrade PRs missing their lockfiles.
• Preserve package-manager metadata for pull-request safety validation.

Diagram

graph TD
  TF["TrueForge repair"] --> Verify["Repair verification"] --> Enrich["File enrichment"] --> Store["Upgrade snapshot"] --> Guard["Lockfile guard"] --> PR["GitHub PR"]
  Repo["GitHub source"] --> Enrich

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Require complete TrueForge changed-file results

• ➕ Makes the verifier the single authoritative source of repaired file contents.
• ➕ Avoids default-branch GitHub reads and local text-replacement reconstruction.
• ➖ Requires an upstream TrueForge contract and deployment change.
• ➖ Does not protect callers from older or temporarily incomplete verifier payloads.

Recommendation: The current compatibility-layer approach is appropriate for an immediate safety fix: it preserves complete verifier output, fills only omitted repair paths, and blocks unsafe manifest-only PRs. A stricter TrueForge changed-files contract would be a useful follow-up, but should not replace the defensive validation added here.

Files changed (6) +206 / -11

Bug fix (3) +130 / -7

route.tsBlock unsafe manifest-only npm and pnpm upgrade PRs +22/-0

Block unsafe manifest-only npm and pnpm upgrade PRs

• Derives the expected lockfile from the recorded package manager and rejects PR creation when that file is absent. Existing verified files continue to be passed together to GitHub.

src/app/api/repositories/upgrade-runs/pull-request/route.ts

trueforge.tsEnrich verified results with omitted structured repair files +100/-7

Enrich verified results with omitted structured repair files

• Merges missing full-file replacements into verified changed files and reconstructs omitted text replacements from default-branch GitHub content. Deduplicates paths, applies only unambiguous text matches, and preserves available verifier results when source retrieval fails.

src/lib/trueforge.ts

upgrade-run-store.tsPreserve package manager in every upgrade-run snapshot +8/-0

Preserve package manager in every upgrade-run snapshot

• Adds package-manager metadata to upgrade snapshots across running, blocked, interrupted, completed, and sanitized records. This enables downstream PR validation to select the correct lockfile requirement.

src/lib/upgrade-run-store.ts

Tests (3) +76 / -4

route.test.tsCover complete changed-file forwarding and missing-lockfile rejection +46/-3

Cover complete changed-file forwarding and missing-lockfile rejection

• Expands PR creation coverage to assert that manifest, lockfile, and repaired source files are all forwarded. Adds a regression test ensuring verified npm runs without package-lock.json return 409 and never call GitHub.

src/app/api/repositories/upgrade-runs/pull-request/route.test.ts

workspace.test.tsxAdd package-manager metadata to workspace upgrade fixtures +1/-0

Add package-manager metadata to workspace upgrade fixtures

• Updates the workspace upgrade-run fixture to match the expanded snapshot contract by identifying npm as its package manager.

src/app/workspace.test.tsx

trueforge.test.tsVerify omitted text-repair files are reconstructed +29/-1

Verify omitted text-repair files are reconstructed

• Mocks GitHub repository metadata and source retrieval for a repaired file omitted by verification results. Confirms the successful handoff returns the fully repaired content in changedFiles.

src/lib/trueforge.test.ts

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📜 Skill insights (0)

1. Unified-diff repairs stay omitted ✓ Resolved 🐞 Bug ≡ Correctness

Description

includeVerifiedRepairFiles augments missing files only from structured file/text replacements and
never uses the supported repairPatch.unifiedDiff. When TrueForge's changed-file payload is
incomplete for a unified-diff repair, the verified source edits remain absent from the pull request.

Code

src/lib/trueforge.ts[R589-593]

+    const missingTextReplacementPaths = [
+      ...new Set(
+        input.repairPatch.textReplacements
+          .map((replacement) => replacement.path)
+          .filter((path) => !includedPaths.has(path))

Relevance

●●● Strong

The stated PR intent is incomplete verified files, but unified-diff repairs are plainly excluded.

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The repair prompt permits unified diffs, extraction retains them, and repair verification sends them
to TrueForge, but the new fallback enumerates only fileReplacements and textReplacements;
downstream PR creation uses only the resulting changedFiles.

src/lib/trueforge.ts[1180-1183]
src/lib/trueforge.ts[1273-1285]
src/lib/trueforge.ts[671-675]
src/lib/trueforge.ts[579-595]
src/app/api/repositories/upgrade-runs/pull-request/route.ts[51-66]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Verified repairs expressed as `unifiedDiff` are not added when TrueForge returns an incomplete `changedFiles` payload.

## Issue Context
The handoff contract explicitly supports unified diffs, and repair verification applies them, but enrichment considers only file and text replacements.

## Fix Focus Areas
- src/lib/trueforge.ts[556-635]
- src/lib/trueforge.ts[660-687]
- src/lib/trueforge.ts[1273-1285]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. Repair retrieval errors are swallowed ✓ Resolved 📘 Rule violation ☼ Reliability

Description

includeVerifiedRepairFiles catches GitHub parsing, metadata, authorization, network, and
file-fetch failures and returns a partially enriched changedFiles result while retaining
VERIFIED, without an error signal. Callers may persist the run as verified and create an
incomplete pull request that silently omits repair files, or encounter only a later generic
conflict.

Code

src/lib/trueforge.ts[R630-631]

+    } catch {
+      return { ...input.verificationResult, changedFiles };

Relevance

●●● Strong

Returning VERIFIED after enrichment failure silently preserves incomplete output; recent precedent
accepts surfacing failed repair handoffs.

PR-#12

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

Compliance rule 2919014 forbids catch handlers that neither rethrow, return an error result, nor log
actionable context, and rule 2919016 requires external-service flows to explicitly handle
authorization, timeout, malformed, and empty responses. The broad catch instead converts every
failure into the same successful-looking partial result; because the status remains VERIFIED, the
store records the accumulated files and the pull-request route forwards them directly to GitHub
without knowing enrichment failed.

Rule 2919014: Do not silently swallow caught errors; surface actionable information
Rule 2919016: Explicitly handle all non-happy-path states for external feature flows
src/lib/trueforge.ts[601-631]
src/lib/upgrade-run-store.ts[297-306]
src/app/api/repositories/upgrade-runs/pull-request/route.ts[39-66]
src/lib/trueforge.ts[601-634]
src/lib/upgrade-run-store.ts[297-307]
src/app/api/repositories/upgrade-runs/pull-request/route.ts[51-66]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description

`includeVerifiedRepairFiles` silently converts GitHub parsing, metadata, authorization, network, and file-fetch failures into a partial `VERIFIED` changed-file list, allowing incomplete results to be persisted and submitted in a pull request.

## Issue Context

Do not discard enrichment failures. Distinguish expected missing files from authorization, timeout, malformed-response, empty-response, and other retrieval failures, and expose actionable operation and repository/path context by throwing, returning a blocked/error result, or using the project's structured logging mechanism. The run store currently persists the partial list because the run remains verified, and the pull-request route submits that list without knowing enrichment failed.

## Fix Focus Areas

- src/lib/trueforge.ts[601-634]
- src/lib/upgrade-run-store.ts[297-307]
- src/app/api/repositories/upgrade-runs/pull-request/route.ts[51-66]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

3. Reconstructed files remain VERIFIED ✓ Resolved 📘 Rule violation ≡ Correctness

Description

After deterministic verification succeeds, repair files are reconstructed from the repository's
movable default branch, while replacements whose old text is missing or non-unique are silently
skipped and unchanged files are omitted. The resulting PR payload can therefore be partial or
revision-mismatched relative to the sandbox-tested content while retaining VERIFIED, instead of
being blocked, failed, or re-verified.

Code

src/lib/trueforge.ts[R625-628]

+        if (repairedContent !== originalContent) {
+          changedFiles.push({ path, content: repairedContent });
+          includedPaths.add(path);
+        }

Relevance

●●● Strong

Partial or branch-mismatched files can retain VERIFIED; accepted precedent favors deriving outcomes
from actual repair success.

PR-#12

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

Compliance rule 2918965 requires success to derive from concrete execution artifacts, and rule
2918966 requires unsafe upgrades to be blocked. The cited code collects repair context and verifies
operations in the retained sandbox, but enrichment then fetches separate source bytes from
metadata.defaultBranch; the replacement helper skips missing or duplicated matches, the caller
includes a file only when the transformation changes its content, and the original VERIFIED status
is returned regardless, demonstrating that the PR payload can differ from what deterministic
verification tested.

Rule 2918965: Determine upgrade success from command exit codes and outputs, not inferred reasoning
Rule 2918966: Mark unsafe upgrades as blocked instead of forcing success
src/lib/trueforge.ts[556-563]
src/lib/trueforge.ts[602-626]
src/lib/trueforge.ts[1345-1353]
src/lib/trueforge.ts[641-657]
src/lib/trueforge.ts[607-626]
src/lib/trueforge.ts[1339-1356]
src/lib/trueforge.ts[634-634]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Post-verification reconstruction can produce partial or revision-mismatched PR file contents because text replacements that cannot be applied exactly are silently skipped while the result remains `VERIFIED`.

## Issue Context
Replacement context comes from the retained, verified sandbox, but reconstruction reads current content from the movable GitHub default branch. Ensure that the exact bytes submitted in the PR are the bytes tested by deterministic verification; a missing or duplicated match must invalidate enrichment rather than omit the edit, and any payload that cannot be reconstructed exactly should return a blocked/failed result or be re-verified.

## Fix Focus Areas
- src/lib/trueforge.ts[556-634]
- src/lib/trueforge.ts[641-657]
- src/lib/trueforge.ts[1339-1356]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

4. New repair files cannot commit ✓ Resolved 🐞 Bug ≡ Correctness

Description

The new enrichment path appends every missing full-file replacement, including a replacement path
that does not yet exist, but GitHubClient.createPullRequest requires an existing file SHA before
every write. A verified repair that creates a file consequently fails during pull-request creation
on the initial 404 lookup.

Code

src/lib/trueforge.ts[R582-585]

+    for (const replacement of input.repairPatch.fileReplacements) {
+      if (!includedPaths.has(replacement.path)) {
+        changedFiles.push({ path: replacement.path, content: replacement.content });
+        includedPaths.add(replacement.path);

Relevance

●●● Strong

Missing-file creation failure is a concrete correctness bug in the new verified-file path.

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The repair response schema accepts arbitrary repository-relative replacement paths and the new code
adds absent paths. PR creation then performs an unhandled existing-file GET and unconditionally
reads its SHA, while the shared JSON requester throws on 404 before the PUT can occur.

src/lib/trueforge.ts[1223-1227]
src/lib/trueforge.ts[582-587]
src/lib/github.ts[145-165]
src/lib/github.ts[257-268]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Enriched full-file replacements can reference new files, but pull-request creation only supports updating existing files.

## Issue Context
GitHub file creation must omit `sha` when the target path does not exist, while updates must continue supplying the existing SHA.

## Fix Focus Areas
- src/lib/trueforge.ts[582-587]
- src/lib/github.ts[145-165]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

View medium (1)

5. PR description omits required sections ✗ Dismissed 📘 Rule violation ✧ Quality

Description

The PR description contains Summary and Verification but no non-empty remaining-risk section and
no explicit agent-change section listing each modified application component. Because this PR
changes application code, both required description elements must be added.

Code

src/lib/trueforge.ts[R556-562]

+    const enrichedVerificationResult =
+      verificationResult.status === "VERIFIED"
+        ? await this.includeVerifiedRepairFiles({
+            repositoryUrl: input.repositoryUrl,
+            verificationResult,
+            repairPatch
+          })

Relevance

●●● Strong

Explicit repository rules require both sections; omission is a straightforward documentation
compliance issue.

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The supplied PR description has change and verification sections but lacks any remaining-risk
section. It also lacks a clearly labeled agent-change summary naming the modified application
components, while the cited changed production files establish that application code was modified.

Rule 2919021: Require PR descriptions to list changes, verification, and known risks
Rule 2919025: Document agent-made application code changes in pull request description
src/lib/trueforge.ts[556-562]
src/app/api/repositories/upgrade-runs/pull-request/route.ts[39-46]
src/lib/upgrade-run-store.ts[22-25]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The pull request description is missing the required `Remaining risk` and explicit `Agent Changes` sections.

## Issue Context
Add non-empty known risks or state that none are known, and list each modified application component with its purpose, including the pull-request route, TrueForge integration, and upgrade-run snapshot storage.

## Fix Focus Areas
- src/lib/trueforge.ts[556-562]
- src/app/api/repositories/upgrade-runs/pull-request/route.ts[39-46]
- src/lib/upgrade-run-store.ts[22-25]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Context sources

✅ Compliance rules (platform): 40 rules

Review mode: ⚖️ Balanced

Tip of the day

💡 Did you know, you can enable the Remediation agent and Qodo fixes findings in a dedicated fix PR

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗