Skip to main content
Version: 0.1.126 – latest

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, 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, or
  • a feature worktree — the branch a particular feature is being implemented on.

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, and sessions can be stopped and restarted from the chooser.

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 project's target-stack prototype, when it has one — 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 beside the workspace​

A project whose prototypes were built on its own stack already has working code for those screens, in the framework the project is being modernized into. When it does, the session has the whole prototype checkout mounted read-only next to the workspace, and the terminal names its location in $REPAVE_PROTOTYPE_DIR.

ls "$REPAVE_PROTOTYPE_DIR"

It is live: a prototype rebuilt or refined while you are working shows up there without reopening the session.

The checkout holds every feature's prototype and the application shell they run in — more than the feature you are working on. Find your feature's screen there, by its route and its names, and reproduce what that feature needs: its routing, its component breakdown and its state shape are the structure the implementation should have, rather than the screen being derived a second time from the design. Where the two disagree on visuals, the active design wins. Claude Code and Codex in the session are told the same, including to take only what the feature needs.

Two things to know about it:

  • PROTOTYPE-DUMMY markers are expected in it. Each one marks something built to demonstrate the screen rather than to work — fixture rows, a button that only shows a toast, a hardcoded list — and names what should replace it. The implementation has to do the real thing; a marker left in the implementation is rejected.
  • Its files are read-only in the session. The prototype branch is never merged, and it is shared by the whole project: do not commit, reset or check anything out in it. Copy what you need into the real source tree instead of importing from it.

When $REPAVE_PROTOTYPE_DIR is not set, the project had no prototype when the session started. If one has been built since, stop the session and open it again.

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.