What Repave is
Repave modernizes a legacy system by first agreeing, in writing, what it does — and only then implementing that behaviour against a modern stack.
The behaviour is written as Gherkin: plain-language scenarios that describe what the system does from the outside. Scenarios extracted from the legacy codebase are the as-is specification, the record of what you have today. Scenarios you edit or add are the to-be specification, the record of what you want. Agents implement against the to-be specification and the same scenarios verify the result, so nothing ships that the specification does not describe.
The two kinds of project
Web application modernization takes a legacy web application — its screens, its rules, its database access — and produces a modern application feature by feature. You review the extracted scenarios, adjust them where the legacy behaviour is not the behaviour you want to keep, and implement each feature against the target stack.
Batch job conversion takes scheduled or triggered jobs that read and write a legacy database and produces equivalents against a modern target, with the same emphasis on an agreed description of what each job does before anything is rewritten.
What you will do, in order
- Upload the legacy codebase. Repave analyses it and builds a picture of its structure, its data access and its user journeys.
- Review the as-is specification. The extracted scenarios are the system as it behaves today, linked back to the code they came from.
- Decide the to-be specification. Keep, change or drop each behaviour. This is the decision the rest of the work depends on, and it is a human one.
- Implement feature by feature. Agents write the code for a feature against the to-be scenarios, in a workspace you can open and edit yourself.
- Verify. The scenarios are executed against the running application, in a browser, and the result is a report you can read rather than a claim.
Finding your way around
Everything in a project is reached from the sidebar on the left, grouped by the stage of the work it belongs to. Open a group to see its pages; one group is open at a time.
The Recent list at the top of the sidebar shows the last five pages you opened in the project, most recent first, so you can go back to one in a single click without remembering which group it lives in. The list belongs to the project and the browser: another project, or the same project on another computer, keeps its own. When the sidebar is collapsed to icons, your recent pages stay at the top, above a divider, and each shows its name when you hover over it.
The feature list works the same way for features. On the Discovered, Develop and Completed Features pages, Recent features above the list shows the last five features you opened in the project, newest first, each with its status and when you opened it. It shows the same features on all three pages, whatever stage each feature has reached, and a search or filter on the list does not hide them. The list belongs to you rather than the browser, so it follows you to another computer, and other members of the project see their own. It appears once you have opened a feature.
Tags let you group features your own way — by release, by risk area, by who asked for them. A feature can carry any number of tags, and a tag any number of features. Hover a feature in the list and choose + Tag, then type a name: pick an existing tag or press Enter to create a new one. Changes save as you make them. To tag several features at once, tick them and use Tags in the bar above the list. A feature's tags show under its title in the list and in the header of the feature itself.
To narrow the list, click a tag on any feature, or open Filters and choose tags under Tags. When you pick more than one, the list shows only the features that carry all of them; No tags shows the features that have none. The search box also finds features by tag name. The filter is part of the page address, so a link you share opens the same view. Anyone who can edit the project can tag features; viewers can see and filter by tags.
Tags belong to the project, and the Tags page under Management in the sidebar is where they are kept tidy — also reached from Manage tags at the foot of the Tags filter. It lists every tag a page at a time with how many features carry it (click the count to see those features), who created it and when; sort by any column, and use Unused to find tags nothing uses any more. From there you can create a tag ahead of using it, rename one, delete one, or tick several and Merge into… the one to keep. Renaming a tag to the name of another also offers to merge the two. Deleting and merging ask first, because neither can be undone.
Labels record settings on a feature as key/value pairs — release: q3, priority: high,
target-db: postgres — the way labels work on cloud resources. A feature has one value per key, so
setting release to q4 replaces q3. Open a feature and choose Edit labels (or + Add
labels): each row is a key and a value, + Add label adds another, and Save keeps every
change at once. Keys suggest the ones your project already uses, and values the ones already used
for that key. Keys are lowercase letters, numbers, - and _; values are any single line of text.
To set a label on many features, tick them in the list and use Labels in the bar above it.
The agents that plan, build, review and test a feature are told its labels, so a label such as
target-db: postgres is taken into account when the feature is implemented. A label never
overrides the feature's scenarios. Agents can also read and change labels themselves; hover a label
to see who last set it — a person, or an agent run.
The feature list shows a Labels column once any feature has a label (hide it from Columns). Click a label to filter the list by it, or open Filters → Labels, pick a key and then tick values, Any value or Not set. Filtering on several keys shows only the features that match all of them; the search box also finds features by label key or value. Anyone who can edit the project can change labels; viewers can see and filter by them.
Where to go next
- Install with Docker Compose — run Repave on your own host.
- GCP Marketplace — the packaged virtual machine.
- Features — what the product does, surface by surface.
- Methodology — why the work is shaped this way.