feat: persist patch outcomes across generation and verification stages

[mithaliphadtare]

Before opening: make sure there is an issue tracking this work, and link it below. PRs without a linked issue may be closed without review.

Linked issue

Closes #192

What this PR does

This pull request introduces the patch_outcomes database table and hooks it directly into the /fix and /verify endpoints to accurately track the performance of generated patches. As highlighted in the issue, the pipeline previously lacked a persistent mechanism to link an AI-generated fix with its subsequent validation results. By logging the model details, job metadata, and pass/fail outcomes across both lifecycle stages, this change enables data-driven evaluation of patch reliability and model effectiveness.

Type of change

• New feature

ML tier (if applicable)

• Not ML-related

Stack affected

• Backend

---

Changes

Backend

Meaningful Backend Changes

1. Database Schema Extension: Added the patch_outcomes table to the SQLite initialization script to store unique patch IDs, associated job and finding IDs, the LLM model name, prompt token usage, validation statuses, and timestamps.

2. Database Utility Functions (backend/app/db.py):
   Implemented insert_patch_outcome to asynchronously record metadata whenever an LLM generates a fix.
   Implemented update_patch_verification to asynchronously update the validation success status (passed) and verification timestamp of an existing patch record.

3.API Integration (backend/app/main.py):
Updated the /fix endpoint to generate unique tracking UUIDs and asynchronously invoke insert_patch_outcome for each requested fix.
Updated the /verify endpoint to dynamically invoke update_patch_verification, persisting whether the specific patch passed or failed validation.

Database & Schema Changes

This change introduces a new database schema definition to persistently track the lifecycle of AI-generated fixes. Since the application handles schema generation on startup, the initialization setup was updated without needing a separate migration script.

New Table: patch_outcomes

Column Name	Data Type	Description
id	TEXT (Primary Key)	Unique UUID string tracking the specific patch instance.
job_id	TEXT	Foreign identifier linking the patch to its specific background workspace job.
finding_id	TEXT	Identifier mapping the patch directly to the security finding it is attempting to fix.
model	TEXT	The name of the LLM model (e.g., Ollama-Local) that generated the fix.
passed	INTEGER	Nullable boolean flag (1 for true, 0 for false) updated after validation executes.
prompt_tokens	INTEGER	Nullable count of token usage recorded during the prompt generation stage.
verified_at	TEXT	Timestamp indicating when the verification status was officially updated.

---

Testing

How did you test this?

The changes were verified using an end-to-end integration test running the backend locally against an SQLite database instance.

1. Test Setup

• Test Repository: A target repository containing an insecure sample application was packaged as a zip file and processed through the system's setup pipeline to assign a tracking job_id.

2. Execution & Observations

• Generation Stage (/fix): Executed a POST request to the /fix endpoint for the given job.
  • Observation: Verified via database query that a new row was successfully appended to the patch_outcomes table containing the generated patch UUID, job_id, finding_id, and default model string, while the validation field (passed) correctly remained NULL.
• Validation Stage (/verify): Executed a POST request to the /verify endpoint using the matching identifier.
  • Observation: Verified that the existing row in the patch_outcomes table was dynamically updated, transitioning the passed column from NULL to an integer (1 or 0 based on the pipeline's test results) and automatically embedding the current timestamp under verified_at.

Checklist

• Tested locally end-to-end (upload ZIP or GitHub URL → scan → findings returned correctly)
• New ML model falls back gracefully when model file is absent
• No new console.error or unhandled Python exceptions introduced
• Added or updated tests where applicable
• requirements.txt / package.json updated if new dependencies added
• New model files (.pkl, .pt, etc.) are gitignored, not committed

---

[github-actions]

🎉 Thank you @mithaliphadtare for submitting a Pull Request!

We're excited to review your contribution.

Before Review

✅ Ensure all CI checks pass
✅ Complete the PR template
✅ Link the related issue

⚡ Want faster reviews and contributor support?

Join our Discord community:

🔗 https://discord.gg/FcXuyw2Rs

Maintainers and mentors are active there and can help resolve blockers quickly.

Happy Contributing! 🚀

[github-actions]

⚠️ Automated Check: This PR does not strictly follow the required template. Please ensure you have not deleted any checkboxes or mandatory headings, and that you have written explanations under What this PR does and How did you test this?.

Correct PR Template

Please copy and paste the raw template below into your PR description and fill it out:

> **Before opening:** make sure there is an issue tracking this work, and link it below. PRs without a linked issue may be closed without review.

## Linked issue

Closes #

## What this PR does



## Type of change

- [ ] Bug fix
- [ ] New feature
- [ ] ML model / training pipeline
- [ ] Refactor (no behaviour change)
- [ ] Documentation
- [ ] Tests only

## ML tier (if applicable)

- [ ] Tier 1 — Triage
- [ ] Tier 2 — Predictive
- [ ] Tier 3 — Autonomous
- [ ] Not ML-related

## Stack affected

- [ ] Backend
- [ ] Frontend
- [ ] Both

---

## Changes

### Backend



-

### Frontend



-

### New dependencies



-

### Database / schema changes



-

---

## Testing

**How did you test this?**



**Checklist**

- [ ] Tested locally end-to-end (upload ZIP or GitHub URL → scan → findings returned correctly)
- [ ] New ML model falls back gracefully when model file is absent
- [ ] No new `console.error` or unhandled Python exceptions introduced
- [ ] Added or updated tests where applicable
- [ ] `requirements.txt` / `package.json` updated if new dependencies added
- [ ] New model files (`.pkl`, `.pt`, etc.) are gitignored, not committed

---

## Anything reviewers should focus on



## Screenshots (if UI changed)

[arpit2006]

@mithaliphadtare , Do fix template and CI fails.