How warOnSaaS works

Businesses rent the software they run on. warOnSaaS builds open-source replacements for the biggest of those products, so a business can own and run its own.

The work is done by AI coding agents. Contributors run them on their own machines, on their own Claude and ChatGPT subscriptions. wOS, the warOnSaaS operating system, coordinates the work: what to build, in what order, by whom, and whether it is good enough to merge.

Every app will be self-hostable. Hosted status is shown per app.

The public list of targets. Ten to start, in this order: Salesforce, HubSpot, Slack, Zoom, Shopify, QuickBooks, Jira, Zendesk, DocuSign, NetSuite.

TGT-00 is warOnSaaS itself. The system is built with its own process, so its feature list is written in the same format as every other target.

Each target reports three numbers, measured separately:

Mapped

How much of the product is on its roadmap.

Specified

How much has consensus Feature Contracts.

Built

How much is merged.

No mock data. If a number is 0%, the site shows 0%. Today every number is 0%.

Every target is broken down the same way, from the whole product to a single change:

APPLICATION        e.g. Zoom
  `- CAPABILITY    e.g. Meetings
      `- FEATURE   e.g. Video meeting
          `- REQUIREMENT
              `- ATOMIC BUILD UNIT
                  `- CONTRIBUTION / PR

The public site will let anyone drill down this chain, from an app to the PR that built a piece of it.

All work lands on GitHub as one of four kinds of pull request:

1. Roadmap

One canonical PR per application, e.g. “Zoom Replacement Roadmap”. Maps the product into capabilities and features.

2. Feature Contract

One per feature. States exactly what the feature must do.

3. Implementation

One per Atomic Build Unit. The code.

4. Architecture Resolution

Resolves a blocker where a shared contract is not enough.

ROADMAP PR
   | merged
   v
FEATURE CONTRACT PR  (one per feature)
   | merged
   v
IMPLEMENTATION PR    (one per unit)

ARCHITECTURE RESOLUTION PR
   when a shared contract blocks work

Reviews are not PRs. A review is a record attached to the work it reviewed.

Roadmaps and Feature Contracts are reviewed by two AI models from two labs: Fable (Claude, by Anthropic) and Astra (ChatGPT, by OpenAI). Both run at maximum reasoning.

Each one tries to prove the document incomplete. Neither sees the other’s current conclusion. The document is revised and reviewed again until both return NO MATERIAL GAPS. That is consensus.

  DRAFT
    |
    +--------------+
    v              v
  FABLE          ASTRA
  (Claude)       (ChatGPT)
    |  independent |
    `------+-------+
           v
 both NO MATERIAL GAPS?
    no -> REVISE -> DRAFT
    yes -> CONSENSUS

Nobody starts a competing roadmap. Contributors propose changes into the one canonical roadmap.

Reviewer requirements are written as machine-readable Agent Policies, not as prompt text.

Many products need the same features: contacts, threaded messaging, invoices, roles and permissions, an audit log. These are built once.

A Feature Contract is canonical and app-independent. It lives in one global Feature Catalog. Each app’s roadmap maps its capabilities to catalog features, or proposes a new one.

SALESFORCE -+
            +-> Contacts
HUBSPOT ----+
            `-> Audit log <-+
ZENDESK --------> Tickets   |
            `---------------+

• Each app lists the requirements it needs from a feature. A feature counts as specified or built for an app only when every requirement that app references is specified or built.
• Duplicates are a review finding. “This duplicates an existing catalog feature” is a material gap.
• When a shared contract changes, every affected app is listed and its requirements go into the review.
• A build unit is paid once, not once per app. Each app’s completion pool still pays out when its requirements reach 100%.

When a roadmap version merges, every feature it references becomes a tracked record for that app. Each feature opens, or links to, its Feature Contract workflow.

Every feature shows its own progress. Feature progress rolls up to the capability, and capability progress rolls up to the app.

FEATURE  %  -+
FEATURE  %  -+-> CAPABILITY %
FEATURE  %  -+        |
                      v
            APPLICATION %
   (mapped, specified, built)

• Progress is computed by fixed, tested functions.
• Weighting is fixed per roadmap version and published.
• Every number traces back to the records behind it.
• Numbers are recomputed when a merge happens on GitHub.

A merged Feature Contract is broken into a Build Graph of Atomic Build Units. A unit is small enough for one AI agent to finish.

The graph records which units depend on which. Units with no dependency between them are built at the same time, and they own separate files, so they never collide.

  ABU-1     ABU-2     ABU-3
    |         |    (parallel)
    `----+----+
         v
       ABU-4   unlocks when
               1 and 2 merge

Each agent has a context budget. A unit that cannot fit safely in the builder’s budget is rejected and split further.

Before anyone builds a unit, wOS leases it to them. A lease is a time-limited reservation held by one account. It fixes the base commit to build on and the files that may change.

• One unit, one lease holder at a time.
• Independent units from the same feature can be leased by different people at once.
• A lease requires a linked GitHub account.

Technical detail: wOS creates an isolated git worktree for the lease, hands the local Claude Code a context manifest for that unit, and enforces an allow-list of paths.

Pressing BUILD in wOS Desktop, or running wos build <task-id>, runs one fixed sequence:

LEASE -> BUILD -> VERIFY
                    |
   PR <- QUALIFY <- REVIEW

1. 01Check the contributor’s agent and model are eligible.
2. 02Issue the lease.
3. 03Create an isolated copy of the code at the base commit.
4. 04Assemble the builder’s exact context.
5. 05Launch the contributor’s local Claude Code.
6. 06Enforce which files may change.
7. 07Run the deterministic checks.
8. 08Send the result for independent review.
9. 09Qualify it.
10. 10Only then: the wOS GitHub App opens the PR.

Contributors never push. Their machine produces a signed submission: the changes against the base commit, the context manifest hash and the check output. It is uploaded to the control plane.

• You never review your own work.
• Fable review and Astra review are each a leased review task, assigned to eligible contributors other than the author, ideally two different people.
• Both reviews are bound to the exact diff they reviewed, by its hash.
• Checks are re-run in GitHub Actions on the PR. A contributor’s local “tests passed” is never trusted alone.

Not settled yet: at launch there are too few contributors to review each other. A bootstrap mode is being specified: who may review while the pool is small, how that is labelled in public, and when it switches off.

Nobody opens a pull request by hand. Only the wOS GitHub App opens PRs, and only after the work qualifies. The same gate applies to Roadmap and Feature Contract PRs: only the App adds commits to them.

Qualification is checked by machine, recorded, and listed in the PR body:

1. 01A valid, unexpired lease held by that account.
2. 02A linked GitHub account.
3. 03The base commit matches the lease.
4. 04Only allowed paths are touched. CI workflows, symlinks and generated files are rejected; lockfiles unless allowed.
5. 05The context manifest matches the one issued.
6. 06Model and reasoning effort are attested as the Agent Policy requires.
7. 07Astra and Fable reviews both pass, done by other contributors, bound to the same diff hash.
8. 08CI re-verification passes.

CONTRIBUTOR MACHINE
   | signed submission
   v
CONTROL PLANE
   | qualification checks
   v
wOS GITHUB APP
   | branch wos/<unit-id>
   v
PULL REQUEST
   | checks: wos/qualified + CI
   v
MERGE

• The PR author is the App. The contributor is credited with a Co-authored-by trailer for their linked GitHub account, and in the provenance record.
• Nobody pushes to main. Required checks include wos/qualified, which only the App can set, and CI verification.
• Who merges is a founder decision, not settled yet.

1. 01Provenance is recorded.
2. 02Progress updates: the feature, its capability, its app.
3. 03Tokens are recorded for the accepted work.
4. 04The leaderboard updates.
5. 05Units that depended on this one unlock.
6. 06The public Sniper List updates.

When a shared contract is not enough for a task, the builder does not change it quietly. It raises an architecture blocker: the contract, the reason, the evidence, the capability needed, the work affected, and a suggested fix if known.

A resolution arrives as an Architecture Resolution PR. If a shared contract changes, it is versioned, the affected work is identified and its context updated, and that work is reconciled before it continues.

WOS tokens are in-app credits with no cash value. They are not cryptocurrency. They cannot be transferred or sold. Transfer and redemption stay disabled.

Tokens are earned per person, for accepted work. The running total is your score, and the leaderboard ranks it. Opening a PR earns nothing.

Earned for

Accepted roadmap work, Feature Contract work, architecture resolutions, implementation, reviews and security work.

Pools

Completion pools pay out when a feature, or a whole app, reaches 100%.

Shared features

A unit is paid once, not once per app that uses it.

Ledger

One append-only ledger, one unit. Balances are derived, never edited.

Sign in with your email. To contribute (build, review, propose), link a GitHub account.

• An account is created from a verified email address.
• A GitHub account is linked later. It is required before any lease, review, proposal or resolution, anything that produces a commit, PR or review.
• Tokens and the leaderboard belong to the account, not the GitHub login. Provenance still records which GitHub identity authored each commit.

wOS holds no model API keys. The models run on the contributor’s machine, through the tools they already use:

Fable and Opus

Through Claude Code, signed in with the contributor’s Claude subscription.

Astra

Through the Codex CLI, signed in with the contributor’s ChatGPT account.

wOS starts these tools as local processes. It never reads, stores or passes on the contributor’s model credentials.

Because of that, the server cannot prove which model ran. Model identity is recorded as an attestation, and review by other contributors keeps it honest.

Architecture

Phase 0 in progress. Nothing merged.

Public website

This site. Static v0, data from a file.

Everything else

Not started.

All targets

Mapped 0%, specified 0%, built 0%.

Contributors

0.

warOnSaaS is its own first target, TGT-00. Its proposed feature list is on its dossier page.