I Did Not Move the Repository Yet

Reading the Cursor Origin announcement reminded me of Haru Space. An agent changes code, a person reviews the PR, a Preview makes the result visible, and a merge sends it to production. Haru Space also aims to turn conversation into work, let AI prepare a result, and publish only what a person has approved.

I did not conclude that we should build or move repositories immediately. The workflow is similar; the product purpose is not. Origin is code hosting. Haru Space connects trusted people’s conversations, ideas, and reviewed outcomes. Similar pipes do not make a coffee machine and a fire hydrant interchangeable. Connecting them would make the morning unusually energetic.

I drew three official routes

Cursor’s official material describes three parts:

1. Origin-native repositories — Cursor hosts code, PRs, and permissions.
2. GitHub-synced repositories — Origin can display, comment, review, and merge while GitHub remains the source of truth.
3. The Vercel app — each Origin PR receives a Preview and a merge can deploy to Production.

GitLab is not part of the announced Origin sync. Vercel independently supports GitLab and Merge Request previews. The accurate map is:

Origin repository → Vercel

GitHub ↔ Origin → Vercel

GitLab → Vercel

Combining three lines into one makes the diagram shorter and the eventual permission incident longer.

Sources: Cursor Origin changelog, Vercel Git integration, Vercel for GitLab

The resemblance is an approvable workflow

The repository brand interested me less than the state transition:

conversation or idea → public-safe task → AI draft → verification → Preview → human approval → publication

Origin lets an agent create branches and PRs before a person reviews and deploys. Haru Space also allows AI to prepare results, but a person must stop at the public boundary. A green Preview does not tell us whether the content is publishable, image rights are cleared, or a private conversation slipped in. Build servers are fast. Reading the room remains a human job.

I want Haru Space states to be more explicit than a normal code deployment:

State	Meaning
private	Conversation and internal material outside publication
proposed	A person selected a public candidate
generated	AI or a tool created a draft
verified	Facts, rights, privacy, and build were checked
approved	A person approved publication
published	The public surface is live
withdrawn	Public access stops while history remains

The most important row is approved. Automation may accelerate the rows around it, but it must not jump over this one.

GitHub remains the source of truth for now

Origin is in early beta. Its own announcement says repositories that began on GitHub keep GitHub as the source of truth. That is practical: a team can test a new interface without discarding its recovery path.

I apply the same judgment to Haru Space:

• Keep the current GitHub repository and PR approval flow.
• Keep Vercel Preview separate from Production.
• Do not scatter one provider’s API throughout the product.
• Make GitLab or Origin an adapter that can be added later.
• Preserve the rule that merging is final publication approval.

A provider adapter needs at least:

provider, repositoryId, ref, changeId, actor, commitSha, checkStatus, previewUrl

Then a GitHub PR, GitLab Merge Request, and Origin PR can share the internal concept of a reviewable change. The meaning of the state matters more than the label on the button.

I retired one early assumption

My first thought was that an AI IDE owning hosting and deployment could quickly shrink GitHub and GitLab’s role. The official material made me lower that confidence. Origin prominently syncs GitHub and lets Depot or Buildkite run existing GitHub Actions workflows. This currently looks more like absorption and connection than immediate replacement.

That distinction matters for product work. Copying a competitor’s full structure can add menus before it solves a problem. Instead of building a repository screen for Haru Space, I will first check whether people can clearly see where they must wait and what evidence supports approval.

Four deliberately small experiments

1. Provider-neutral events

   Convert GitHub PR events into an internal ChangeRequest and check that provider names do not leak into product decisions.

2. Separate Preview from approval

   Test that a successful Preview cannot open the publication path without approved.

3. Prevent duplicate events

   Use provider + changeId + commitSha for idempotency when a webhook arrives twice.

4. Preserve withdrawal history

   Verify that a post with a later problem moves to withdrawn instead of having its history erased.

These tests will not use real member conversations, account data, or internal security settings. They need public-safe dummy content and an isolated test repository. Today’s rule is a small experiment and a long audit trail.

Conclusion

Cursor Origin partially resembles the direction of Haru Space: agents create outcomes, people review them, and a Preview leads toward publication. What Haru Space should borrow is not a new repository. It is a human-approvable state model and a replaceable provider boundary.

I did not move the repository today. I marked the doors that might be replaceable later. It is less glamorous than signing a new lease, but measuring the outlets first is kinder to one’s back on moving day.

The broader technology and market context is in Daily Issues: The Code Met the Bond Market.