Pipeline Guide — RepoPatch

01 — 📥

LOAD

Entry Point

The Load stage accepts your input and prepares it for the pipeline. RepoPatch supports two import modes:

Mode A — Patchset File Drop or upload a .txt file already formatted in Patch Language v1.3. RepoPatch parses it directly into the pipeline.

Mode B — Single Modified File Drop a file whose name exists in the workspace. RepoPatch auto-generates a REPLACE patchset by diffing the incoming file against the workspace version. The Load tab will show an "→ Converted from diff" badge.

Load tab output

load · status

input_kind patchset_file blocks_found 3 files_targeted src/utils.py, src/models.py workspace_ver v1.0 ✓ Ready — proceed to Conform

What Load checks

Load performs a lightweight top-level parse: it counts PATCH blocks, records target file paths, and detects the input kind. It does not validate anchors or execute anything — that's Conform and Validate's job.

Workspace & ZIP Import

Upload a ZIP file to create or reset a workspace
Each ZIP import atomically replaces the workspace and increments the major version (v1.0 → v2.0)
The "Parts ZIP" export in the Summary tab lets you download the current workspace state at any time
Pro: workspaces persist across deploys and the midnight retention sweep

02 — 🔍

CONFORM

Quality Gate

Conform runs across four subtabs: Convert, Run, Issues, and Code Quality. It performs a structural pass (is the patch language valid?) and a code quality pass (do the new lines introduce problems?). Issues are reported as diagnostic tiles.

Structural checks

The conformance checker verifies that every PATCHSET, PATCH, and ENDPATCH is correctly nested, all operation keywords (REPLACE, INSERT BEFORE, etc.) are well-formed, and prefix rules (- vs . ) are respected throughout.

Code Quality tiles

The Code Quality subtab surfaces issues found in the new content the patch is introducing. Free tier covers structural and integrity checks. Pro adds an audit layer.

DQ001

Malformed XML / unclosed tags — a new block contains an XML tag that is not closed within the same block. Example: <root> with no matching </root>. Free

BR001

Deleted function still called — the patchset deletes a function definition (e.g. def old_helper()) but another new block calls it. Potential runtime break. Free

BR002

Removed import still used — a symbol whose import was deleted is still referenced in new lines. Free

DQ021

Elevated system permission introduced — the patch enables ModifyAllData, ViewAllData, AuthorApex, or another sensitive permission in a Salesforce permission set or profile. Pro

DQ024

SOQL / DML / callout in loop (Apex) — governor-limit risk introduced inside a for or while block. Pro

Blocking vs. Warning Tiles Structural tiles can be blocking — Apply will not unlock until they are resolved. Code Quality tiles are warnings requiring your review approval before Apply proceeds. Both basic and advanced (Pro) tiles clear with a single approval click.

Approval Flow When only non-blocking warnings remain, an "I've reviewed these warnings — proceed" button appears. Clicking it marks the warnings as acknowledged and unlocks Validate → Apply.

03 — 🎯

VALIDATE

Anchor Check

Validate resolves every anchor block against the actual workspace files. An anchor must match exactly once. Zero matches and multiple matches are both hard failures.

What a passing validate looks like

validate · results

[PATCH 1] src/utils.py ✓ Anchor matched at line 42 (1 match) [PATCH 2] src/models.py ✓ Anchor matched at line 18 (1 match) [PATCH 3] src/constants.py ✓ CREATEFILE — target does not exist ✓ All 3 anchors resolved — Apply unlocked

Anchor mismatch diagnostics

When an anchor fails to match, RepoPatch shows you why — not just that it failed. You get a per-line comparison with ✓/✗ markers, the closest match found in the file, and the similarity percentage.

validate · mismatch detail

✗ PATCH 2 — anchor not found in src/models.py Expected block (2 lines): - class UserModel: - id = Column(Integer) Closest match in file (lines 18–19, 78% similar): ✓ class UserModel: ✗ id = Column(Integer, primary_key=True) ^ content difference (not whitespace)

04 — ⚡

APPLY

Writes Files

Apply executes all operations against the workspace. Files are written exactly as the . lines specify — indentation, blank lines, and all. The workspace version increments on success.

Operations

Operation	Effect
REPLACE	Swap matched old block for new content in-place
INSERT BEFORE	Add new lines immediately before the anchor
INSERT AFTER	Add new lines immediately after the anchor
DELETE	Remove matched block from the file
CREATEFILE	Write a new file with the supplied content
DELETEFILE	Remove an entire file from the workspace

Version increments

Versioning Rules

Each successful Apply increments the minor version: v1.0 → v1.1 → v1.2
Importing a new ZIP resets to the next major version: v1.x → v2.0
A Revert rolls back the last Apply and marks the version entry with ✗
Version history is visible in the picklist on the Summary tab
Pro: every version is snapshotted to disk — Revert restores file contents, and any historical version can be downloaded

05 — 📋

RECORD

Audit Trail

After Apply completes, two action buttons appear: Record Success and Revert Failed Release. This gives you a final human-in-the-loop checkpoint before committing the result to history.

Record Success Marks the applied version with a ✓ flag in the version history. The button text changes to "✓ Recorded". The workspace stays at the new version.

Revert Failed Release Marks the applied version with a ✗ flag and rolls all pipeline stages back to pending. Free tier rolls back stage state only; Pro restores file contents from snapshot.

Version history entries are always preserved — both ✓ and ✗ outcomes remain visible in the picklist, giving you a complete chronological audit trail of every patch applied to the workspace.

The five-stage
pipeline.