What Repave does
Repave modernizes a legacy system by agreeing, in writing, what it does — and only then implementing that behaviour against a modern stack. This page is the map: every surface you will meet, what it is for, and where it is documented in full.
Your deployment may not show all of them. A number of surfaces are off unless your operator turns them on, and those are marked below.
The specification is the centre of the product
Everything here revolves around Gherkin: plain-language scenarios describing what the system does from the outside.
- The as-is specification is extracted from the legacy codebase. It records what you have today, and each scenario links back to the code it came from.
- The to-be specification is what you decide you want. You reach it by editing the as-is: keeping behaviour, changing it, or marking it as not required.
- Implementation runs against the to-be specification, and the same scenarios verify the result.
Nothing is implemented that the specification does not describe, and nothing is verified against a document you have not reviewed.
Getting your code in
| Surface | What it is for |
|---|---|
| Project creation | A project pairs a legacy codebase with the modern one being built from it |
| Source Files | The uploaded legacy code, browsable in place |
| Source encoding | Legacy source in a non-UTF-8 encoding is converted before anything reads it |
| Source repositories | A project can combine several client repositories into one workspace |
Legacy code arrives as an upload, and the modernized codebase is either scaffolded for you or cloned from your own Git server or Team Foundation Server. See Creating a project.
Understanding what you have
| Surface | What it is for |
|---|---|
| As-Is Architecture | The legacy system's structure, as extracted |
| DB ER Diagram, DB Table Catalog, DB Objects | The legacy database, as found in the code |
| Views, View Catalog | The screens the legacy application presents |
| Modules | The unit of work: discovery through delivery happens a module at a time |
| External Systems | What the legacy system talks to, and how each will be treated |
| Legacy Code Viewer | The source itself, at the line a scenario points to |
See Reading the analysis.
Agreeing the behaviour
| Surface | What it is for |
|---|---|
| Discovered Features | The as-is specification, feature by feature |
| Scenario editing | Rules and scenarios, edited directly |
| Feature Dependencies | What has to be built before what |
| To-Be Architecture | The modern design the to-be scenarios are written against |
| Validation Rules | Standards every implementation is checked against |
| Decisions | The answers you gave, kept per feature and per launch |
| User Journeys | End-to-end flows assembled from scenarios across features |
See Reviewing the as-is specification, Deciding the to-be specification, Validation rules, Decisions and User journeys.
Building it
| Surface | What it is for |
|---|---|
| Develop Features | Launching and following an implementation |
| Implementation plan | How the work was broken up, and in what order |
| UI Prototype | A design for the feature, approved before the code is written |
| New Code Viewer | The modernized codebase as it stands |
| Compare | Legacy and modernized side by side |
| Pull Requests | Every pull request Repave opened, in pull-request merge mode |
| Bundles | Finished features assembled and tested together before they merge |
| View Source Code (web IDE) | A full editor in the browser, sharing the agent's workspace |
See Implementing a feature, UI prototypes, The web IDE, Bundles and Comparing legacy and modernized code.
Checking it
| Surface | What it is for |
|---|---|
| Reports, Report Catalog | Test runs and what they found |
| Test Replay | Re-running a scenario and pinning what went wrong |
| Bug Reports | Problems raised against a running application, investigated by an agent |
| Verifications | Agent questions that paused a job, waiting on your answer (off by default) |
| UAT Tools | User-acceptance environments per feature (off by default) |
| Cucumber Test Runner, Unit Test Runner | Running suites from the browser (off by default) |
See Test runs and reports and Bug reports.
Running the platform
| Surface | What it is for |
|---|---|
| Analysis Jobs, Queue | Everything the platform is doing, or has done |
| Agent Logs | What an agent actually did, step by step |
| Costs | What each feature and each stage spent (hidden by default) |
| Upstream Sync | Changes made outside the platform, brought in |
| APIs, API Catalog, API Spec, API Playground | The interfaces the system exposes |
| Settings | Merge mode, implementation gates, models, integrations |
| Team | Who can see and change this project |
See Jobs, Project settings, Upstream sync, Costs and APIs.
Batch job conversion
A second project type converts scheduled or triggered jobs that read and write a legacy database, with the same emphasis on an agreed description before anything is rewritten. Batch Catalog and Batch Jobs replace the feature surfaces for those projects, and a converted job is verified by running the legacy job and its replacement and comparing what each did.
See Batch job conversion.
Where to go next
- Creating a project — start here with a real codebase.
- Methodology — why the work is shaped this way.
- Repave CLI — the command-line surface, used by agents and by you.