Repave IDE

Repave IDE is a full editor in the browser, running against the same workspace the agents use. It is how you do the part of the work that is quicker to do yourself, without leaving the platform or cloning anything.

Opening a session

Open it from a feature, from a module, or from Repave IDE on the project. A chooser asks which codebase you want, because there is usually more than one:

• the modernized codebase on its integration branch,
• one of your own worktrees — a branch for a change that is not a feature (see below),
• a module worktree — the one branch a module's features are built on together, or
• a feature worktree — the branch a particular feature is being implemented on.

A module and its features share one worktree, so Open in Repave IDE on the module's page, on the module's card in the chooser, or on any of its features opens the same session. On the module's page and its card, the button stays disabled until the module's first implementation run creates that worktree, and says so.

Picking the wrong one is the common first mistake: edits made on the integration branch are not part of the feature you thought you were editing.

A progress page covers the start-up while the session comes up.

Worktrees for changes that are not a feature

Not every change is a feature: a dependency bump, a build fix, a README. For those, make a worktree — your own branch, opened in Repave IDE like any other — from the Worktrees section of the Repave IDE page, directly under the modernized codebase.

1. Click New worktree, type a name, and press Create. The branch is named for you — "Bump log4j" becomes work/bump-log4j — and cut from the project's integration branch.
2. Click Open in Repave IDE on the new row and make your change.
3. Land it: Create PR when the project merges through pull requests, or Merge to the integration branch when it merges directly. Merging directly asks you to confirm first.

Each row says where the branch stands — how many commits it is ahead of and behind the integration branch, and how many files are uncommitted — and carries the other actions:

• Push sends the branch to the repository. Anything uncommitted is committed first, as "name: changes from Repave IDE"; commit in the editor yourself if you want your own message. Once a pull request is open, pushing updates it.
• ⋯ → Pull brings in commits someone else pushed to the branch.
• ⋯ → Merge from the integration branch brings the worktree up to date.
• ⋯ → Delete removes the worktree and its local branch, and closes any editor open on it. The branch on the repository and any open pull request are left as they are.

Pull and Merge from need a clean worktree, so push or commit first. If the merge conflicts, it is left in the worktree for you: the row names the files and shows merge in progress until you resolve them in Repave IDE and commit. A merge into the integration branch that would conflict is not made at all — merge from the integration branch first, resolve there, then merge again.

Nothing about a worktree is generated or tested by Repave: it is your change, reviewed like any hand-written one. When its pull request merges, the worktree is removed and the page says so.

On a combined workspace the modernized codebase cannot be edited, so worktrees are where a change that is not a feature is made. Push and Pull go to each source repository the change touches, with the same preview a feature's push shows, and Create PR opens one pull request per touched repository, titled with the worktree's name. The worktree is removed once every one of them has merged.

Opened IDEs

Every session open on the project is listed at the top of the Repave IDE page, under Opened IDEs, with who opened it and when. Each one's Stop, Restart and Open in Repave IDE are on its row; the codebase cards below only open.

Each row also shows how much memory the session is using against its limit, in two parts:

• Editor — the IDE itself: the editor, its terminals, and anything run in them, such as the test browser.
• Docker — everything started from the IDE terminal with Docker: the dev stack, test databases.

A bar turns amber at 90% of its limit. When the kernel has had to kill a process because a limit was reached, the row says Out of memory, counts the processes killed since the session started, and names the limit to raise. Both limits are under Container resources in the project's General settings — Repave IDE session for the editor and Docker sandbox for Docker. A new limit applies when the session restarts, so restart it from its row afterwards.

When a feature's workspace cannot be opened, the chooser says why:

• the feature has no approved To-Be Gherkin yet, so there is nothing to open. Approve it first;
• another git checkout is in the feature's worktree folder, so it was left alone. Move it aside and open the feature again;
• the worktree could not be prepared. Opening it again retries, and the reason is in the server log.

What is already set up

A session is not an empty editor.

• The Repave CLI is signed in, and stays signed in for as long as the session runs. You can read the project's scenarios, settings and decisions from the terminal without authenticating.
• Git is configured. You can commit without setting up an identity first; commits the platform writes carry the platform identity.
• Claude Code is available, signed in the way your project settings say, sharing the project's memory, and told which feature the session is for. Codex is available too, with a Repave plugin of its own.
• A browser the developer and the agent share, with a viewer inside the IDE, so you can watch what an agent is looking at.
• Dev mode runs the application, and the preview is reachable from your browser through the platform rather than needing a port open on the host.
• The feature's target-stack prototype, when it has one — it is already in the workspace; see below.
• The feature's .feature file, in a feature session whose To-Be Gherkin is approved. It is written to the project's features path when the worktree has none, and never over a file that is already there, so reopening a session cannot replace your edits. To take a newer version of the scenarios into an existing file, run /repave:feature-file in the session.

The target-stack prototype is in the workspace

When a feature was prototyped on the project's own stack, that prototype is the first work on the feature's branch — so a session on the feature opens with it already in the workspace, as working code in the framework the project is being modernized into. git log shows where its commits end.

Build on it rather than deriving the screen a second time from the design: its routing, its component breakdown and its state shape are the structure the implementation should keep. Where the two disagree on visuals, the active design wins. Claude Code and Codex in the session are told the same.

PROTOTYPE-DUMMY markers mark what the prototype built to demonstrate the screen rather than to work — fixture rows, a button that only shows a toast, a hardcoded list — and name what should replace it. Replace each one with the real thing and delete the marker; the feature cannot be merged while one remains.

The browser viewer

The viewer streams the shared browser into a panel in the IDE, with the open tabs in a strip along the top. You can click and type in it as you would in your own browser.

• Dialogs are answered in the panel. When the app opens an alert, a confirmation or a prompt, it appears over the page, headed with the app's host, for you to answer. A dialog the agent answers first closes in the panel too.
• A page that stops answering says so. The header reads Page not responding — often a dialog that opened while you were on another tab. The reload button (⟳) loads the page again, and the tab strip stays, so another tab is one click away.
• A page the agent gave a fixed size is shown whole, scaled to fit the panel, with its size (for example 1024×768) beside the address.

The Repave sidebar

A sidebar specific to this product, not to the editor:

• Scenarios — the feature's Gherkin, without switching back to the web app.
• BDD Runs — test runs, with a Trace Viewer tab for looking at what a run actually did in the browser.

Working alongside an agent

You and an agent can be in the same workspace. The practical rules:

• An agent implementing a feature works in that feature's worktree on that feature's branch.
• A reused worktree is kept current with your base branch, so you are not editing against something stale.
• If you implement locally with the developer plugin, the same gates apply as on the platform's own pipeline — including that local implementation is gated on a concluded preflight. The plugin does not get a shortcut the platform does not have.

Session lifetime

A session's home directory outlives its container, so a restart does not lose your shell history, your editor state, or files you left outside the repository. Sessions are reconciled and cleaned up at platform start-up, so a session left running through a restart does not linger as a ghost.

Next: Test runs and reports.