AUTOMATED DEPENDENCY REPAIR·CONTROLLED SPEC

See what breaks.
Review what fixes it.

Reproduce a dependency upgrade failure, inspect a candidate patch, and review the verification evidence.

Custom repository execution is currently disabled. Active runs are restricted to controlled demo tasks.

Repair Bench · 2.5D Isometric Simulation

Illustrative sequence

BASELINE VERIFIEDBaseline tests pass

Step 1 of 4

Runs existing test suite against pinned commit to verify baseline green status before upgrade.

THE BOTTLENECK

The silent break in dependency upgrades

When a library bumps a major version, code that compiled cleanly yesterday crashes today. Subtle API removals, renamed keyword parameters, and altered return shapes break CI test suites. Developers spend hours digging through migration notes to fix small syntactical mismatches.

sqlalchemy 1.4 → 2.0.19 breaking change

Example excerpt (sanitized fixture)

1. Baseline (sqlalchemy 1.4.48) — PASSsrc/shop/database.py

# Legacy SQLAlchemy 1.4 execution syntax
engine = create_engine(DATABASE_URL)

def get_active_orders():
    # Direct string execution allowed in 1.4
    result = engine.execute("SELECT id, total FROM orders")
    return [dict(row) for row in result]

pytest: 1 passed in 0.12s (Baseline verified)

2. Target Upgrade (sqlalchemy 2.0.19) — FAILpytest traceback

Traceback (most recent call last):
  File "src/shop/database.py", line 6, in get_active_orders
    result = engine.execute("SELECT id, total FROM orders")
AttributeError: 'Engine' object has no attribute 'execute'

# In 2.0, explicit connection context and text() required

FAILED tests/test_orders.py::test_database_connection

THE PROCESS

How RepoMedic resolves breaking upgrades

A disciplined four-stage pipeline isolates the upgrade, tests the failure, generates a candidate patch, and proves the fix in a sandbox.

01PASS CHECK

1. Baseline Check

Pins the exact repository commit and runs existing test suites in a clean container to prove the baseline was green before any version bump.

Input: Pinned commit SHA

02REPRODUCE

2. Reproduce Failure

Upgrades target dependency in isolation. Extracts full pytest output and stack trace to verify the exact failure matches expectations.

Output: Sanitized trace

03SYNTHESIS

3. Candidate Patch

Model analyzes failure and AST constraints to propose candidate source edits. Test files are never modified.

Note: A model-generated patch is a candidate; verification may fail.

Output: Unified diff patch

04VERIFIED

4. Verify & Evidence

Evaluates candidate in clean sandbox against the full test suite. Generates downloadable patch, execution logs, and cryptographic evidence.

Evidence: SHA256 & JSON

PRODUCT PREVIEW

Reviewable patches and verifiable evidence

RepoMedic produces verifiable evidence artifacts: exact git diffs, execution timings, AST integrity checks, and full container logs.

VERIFIED · 42/42 PASSTASK-084 · pydantic v1.10.8 → v2.0.2 migration in fastapi-service

Illustrative product preview

Candidate Patch · src/app/schemas.py+3 additions, -2 deletions

@@ -3,9 +3,8 @@
-from pydantic import BaseModel, Field
+from pydantic import BaseModel, Field, ConfigDict
 class AccountPayload(BaseModel):
     account_id: str
-    tenant_slug: str = Field(..., regex="^[a-zA-Z0-9]+$")
+    tenant_slug: str = Field(..., pattern="^[a-zA-Z0-9]+$")
     is_active: bool = True
-    class Config:
-        orm_mode = True
+    model_config = ConfigDict(from_attributes=True)

Verification Telemetry

Tests verified:42 / 42 passed (100%)

Execution time:24.2s

AST hash:sha256:d8a261...

Estimated usage:$0.04 USD

Downloadable Artifacts:

repomedic-fix.patchverification-evidence.json

PRODUCT INTEGRITY

Evidence, scope, and engineering limitations

We prioritize technical transparency over exaggerated claims. Here is what RepoMedic can and cannot do in this release.

Downloadable Artifacts

Every verified repair emits the exact candidate patch diff, full pytest execution logs, and machine-readable JSON evidence with AST integrity signatures.

Controlled Fixture Scope

Demonstrated successes are controlled fixtures (demo-shop has 1 test; pydantic has 42 tests). Controlled demo success does not establish arbitrary repository reliability.

Developer Review Required

Candidate patches are synthesized for developer review, not autonomous blind merges. A human engineer must inspect the candidate diff before committing to production.

Server-Side Execution Gating

Custom repository execution is disabled server-side to protect system stability. Custom configurations can be validated locally for format and contract rules.

Inspect a verified repair or explore repository recipes

Open our saved live run to view diffs, execution traces, and cryptographic evidence, or validate a custom repository configuration.

Controlled demo scenarios are available. Custom execution is gated.

See what breaks.Review what fixes it.