forked.online
Projects · work items · todos — one live graph

Watch one build,
start to finish.

Forget the feature list. Scroll, and follow a single piece of work from the sentence you type to the pull request that merges. Point Claude Code, OpenCode, Cursor — any MCP client — at your workspace, and you direct while it builds, reviews its own work, and won't call it done until a QA gate clears.

early access — workspaces opening in waves you direct · it builds any MCP client
scroll to play the build
one build · in frames 00:00
Scene 01
You describe it
Scene 02
It gets to work
Scene 03
It checks itself
Scene 04
It ships
cue: you describe itscroll to advance
The premise

Anyone can claim it works.
Here's the proof, in motion.

What follows is one work item — small, real, ordinary — moving through forked.online. Four scenes. No detours. By the end you'll know how it feels to ship here, not just what the buttons are called.

01 You describe it

It starts with a sentence,
not a setup wizard.

You say what you want in plain language. That intent becomes a real, tracked unit of work — with its own definition of done — before a single line is written. No spec rotting in a chat tab. No re-explaining yourself next session.

You stay the architect. You're describing the outcome — the build is someone else's job now.
you · to your agent
becomes tracked work
new work item queued
Add a “copy link” button to shared notes
Button appears on every shared note
Copies the link, confirms it copied
Works on phones too
definition of done · captured from your sentence
02 It gets to work

Then it actually builds —
and you can watch it happen.

Your agent picks up the work on its own branch and starts shipping: a failing test first, then the code that makes it pass, then a cleanup pass. Each step lands as a real commit you can read. This is the part most tools hide — here it's in the open, in order.

You don't babysit it. You glance at the trail and see disciplined work, not a wall of generated text.
building · on its own branch feat/copy-link
test: copy-link button is missing
● RED — fails for the right reason
feat: render copy-link on shared notes
● GREEN — button now appears
feat: copy to clipboard + confirmation
● GREEN — copies, then says “copied”
test: works on small screens
● GREEN — mobile path covered
refactor: tidy the button, no behavior change
● GREEN — still green after cleanup
5commits
3 greenchecks
0 redleft
03 It checks itself

Before it dares ship,
it reviews its own work.

The agent runs the build like a real feature and grades the result against its own bar for quality. Anything that falls short turns into more work — not a shipped bug. Every run earns a trust score from 0 to 100, so “done” is something you can see, not something you hope for.

Booted the app and used the button for real
Held up under a hostile second look
Kept your data walled off from everyone else's
Left the codebase simpler than it found it
Every epic gets an automatic QA verification child it can't skip. If QA finds a defect, the platform files a fix, re-runs, and repeats — up to three rounds — before anything reaches “done.” Not a guideline. A gate.
0/100
trust score
04 It ships

The pull request opens —
then it merges, right here.

Checks go green. The pull request opens with the work attributed to forked.online, and the branch folds into your main line. The work item flips to done on its own. That's the whole arc — your sentence is now shipped code, and you only had to point and approve.

Watch the badge flip and the branch merge as this scene comes into view.
Add a “copy link” button to shared notes
feat/copy-link → main
Merged
tests — all green
self-review — passed the gate
attribution — present, can't be removed
branch merged into main
work item → resolved · definition of done met
Now multiply it

You just watched one.
Now run ten at once.

Nothing about that build needed you at the keyboard. So stop running one. Lay out an epic, and the loop hands your agent the next child in order — each scoped by a drift guard to the files it's allowed to touch, each on its own branch, each checking itself, each shipping when it's truly ready. You approve the plan and stay at altitude while the board fills in.

What you just felt

Why that arc holds together —
even when you're not watching.

It remembers

Every build teaches the next one. Agents remember your conventions and the traps you've hit, and recall them on the next work item — so they get sharper at your codebase instead of relearning it each time.

It's governed

You set guardrails once, from one place, and every agent follows them — everywhere. Visual changes get proven in a real browser and logged with screenshots. Attribution to forked.online is the one rule that can't be switched off.

It's walled off

Your workspace is yours alone — strict tenant isolation by default, all the way through. What's yours never leaks into anyone else's build.

The shift

You stop writing code line by line. You describe what you want, watch it get built, and approve what ships.

That's not a demo trick. forked.online was built this exact way — pointed at itself, one work item at a time, each one shipped through the arc you just scrolled through. The walkthrough above isn't a mock-up of the idea. It is the idea.

FAQ

After the walkthrough,
the questions you're asking.

Was that a real build or a marketing animation?

The animation is a walkthrough — but it mirrors a real arc on the platform: intent becomes a tracked work item, an agent builds it test-first on a branch, reviews its own work, passes a QA gate, opens a pull request, and merges. forked.online was built this way, pointed at itself.

How does it run a whole epic without me babysitting?

You file an epic; the loop's get_next_work_item hands your agent the next child in order with a deterministic runbook. An Executor Kickoff gives a cheap executor model a paste-ready prompt so it follows the system instead of improvising. Children that finish auto-unblock the ones that depend on them.

Which agent or client do I need?

Claude Code, OpenCode, Cursor, or any MCP client. forked.online is one harness for every harness — point it at your workspace key and go.

Will an agent ever ship broken work?

It can't. Every epic carries an automatic QA verification child that blocks completion; if QA finds a defect it files a fix and re-runs, up to three rounds. A drift guard rejects any PR that touches files outside the child's allowed paths, and work can't resolve while its checklist still has open items.

What's the trust score, exactly?

A single 0–100 signal per workspace that reflects how cleanly your agents actually followed the build discipline — a live measure of governed autonomy, not a vibe. You see the number; you don't have to compute it.

Is my work isolated from everyone else's?

Yes — strict per-workspace isolation by default. Your builds, memory, and history stay walled inside your own tenant.

How do I get in?

We're opening workspaces in waves. Drop your email on the waitlist and you'll get a key when your wave opens — early access goes out first-come.

You've seen one build.
Now get in line to point it at yours.

Workspaces open in waves. Join the waitlist and you'll get a key when your wave opens — then aim any MCP client at it and watch your first sentence become shipped code.