Ruse v0.2.0 Is Live: Local Collections and a Cleaner Working-Tab Flow

Ruse v0.2.0 is live in the Chrome Web Store.

This is not a huge platform release, and that is intentional. The goal of this version is simple: make the first real browser API mocking workflow feel less clumsy.

When you are building frontend UI, the problem is often not that you need an entire fake backend. Sometimes the problem is much smaller:

• the API returns a happy path, but you need an error state
• staging has data, but you need an empty state
• the backend is healthy, but you need to test a 500
• the request is fast, but you need to inspect a loading state
• the endpoint exists, but the exact QA state keeps disappearing

Ruse is being built for that kind of moment: one real browser request, one local mock rule, one UI state you need to control.

What changed in v0.2.0

1. Ruse now starts from your working tab
The old tab selector flow is gone.

In v0.2.0, Ruse attaches to the current tab when the side panel opens. That sounds small, but it matters because the tool should follow the workflow you already have:

1. Open the app you are testing.
2. Open the Ruse side panel.
3. Capture a real request.
4. Create a local mock rule.
5. Reload and inspect the UI.

There is less setup before the first useful action.

2. Local collections for mock rules
Ruse v0.2.0 adds local collections so rules do not become one long, messy list. The current limits are intentionally small:

• up to 20 local rules
• up to 3 local collections
• each rule can belong to one collection or stay ungrouped

That is enough structure for the current product without pretending Ruse is already a full team platform.

Example collections:

• Checkout errors
• Dashboard empty states
• Slow API demos

3. Assign rules while creating or editing
Rules can now be assigned to a collection in the create and edit flows. This is useful when you are already thinking in scenarios:

• "this rule belongs to the billing screen"
• "this one is for a demo"
• "these three are all empty-state cases"

The rule organization happens close to the moment where the rule is created, instead of becoming cleanup work later.

4. Drag-and-drop between collections
You can move rules between collections and ungrouped rules with drag and drop.

This is a small interaction detail, but it keeps the local workflow fast. Ruse should feel like a tool you can use while thinking about the product state, not like another admin panel.

5. Rename and delete collections safely
Collections can be renamed or deleted. Deleting a collection does not delete its rules. The rules move back to ungrouped. That behavior is deliberate. In a local testing tool, destructive organization actions should not quietly destroy the mock rules you made while debugging.

What v0.2.0 is not

This release does not add cloud sync, auth, team workspaces, billing, shared collections, or rule version history. Those are bigger product directions, but they are not the current promise. The current promise is narrower:

Make browser-level local API mocks easier for frontend developers and QA engineers.

That means the product should stay honest about what it does today.

Why this release matters

The first version proved the basic idea: Ruse can help turn browser requests into local mock rules.

v0.2.0 is about making that idea easier to use once you have more than one rule.

One rule is a demo.
Several rules are a workflow.
Once you start testing a real screen, you quickly need more than one state:

• normal data
• empty data
• loading
• server error
• malformed response
• permission error

Collections make that local workflow easier to keep in your head.

The working-tab behavior also matters because a browser extension should feel attached to the thing you are testing. If you are already in the right tab, Ruse should not ask you to solve a tab-selection puzzle before you can work.

A practical v0.2.0 workflow

Try this with a real frontend screen:

1. Open the page you are building or testing.
2. Open Ruse on that tab.
3. Capture the request for the data you want to control.
4. Create a local mock rule.
5. Make one response return an empty list.
6. Make another response return an error.
7. Put both rules into a collection named after the screen or scenario.
8. Reload the UI and test the states intentionally.

This is where Ruse should be useful: when you need a fast local testing loop without asking the backend, staging, or a mock server to change.

Where Ruse goes next

The next active development focus is v0.3.0.

The current plan is another quality pass around HTTP rule creation:

• safer create-from-log drafts
• better response body editing
• JSON validation and formatting
• response header editing
• noisy header sanitization
• investigation into permission reduction where it is safe

The direction is still the same: make the local browser mocking loop feel faster, safer, and more predictable.

Try it
Ruse v0.2.0 is available now:

https://ruse.dev

If you try it, the most useful feedback is specific:

Was the working-tab flow obvious?
Did collections help organize real testing work?
Where did creating a mock rule still feel slow?
Which API state do you still find painful to reproduce?
That feedback is exactly what should shape the next release.