App-Generation Microservice

Takes a JSON Product Requirements Document and emits a compiled Flutter application. Built as a LangGraph loop with four subagents and a QA gate that runs the real Flutter toolchain.

The design goal is not "generates plausible code" but zero-error compilation: if the output fails CI, the loop has failed.

Run it

PRD to Flutter APK on Apify Store — generate and read the source for free; pay only for the packaged APK. No account beyond Apify's own, nothing to install.

(An earlier version of this README pointed at a self-hosted x402 service on a VM. That deployment has been retired — the source and the payment-gate design it proved out are unchanged, just no longer running on that box.)

See what it produces, before paying

examples/generated-field-notes/ is unmodified output — 23 files generated from the 45-line todo_app.prd.json beside it, checked in so you can read exactly what a build gives you. Nothing was hand-fixed for presentation. Start with GENERATED.md.

Quick start

No credentials and no Flutter SDK needed — the defaults are fully offline:

poetry install
poetry run python src/supervisor.py examples/todo_app.prd.json --clean

That validates the PRD, runs the loop, and writes a Flutter project to generated_apps/current_build/.

To grade the output with the real toolchain instead of the offline stub:

poetry run python src/supervisor.py --clean --analyzer dart --flutter-root "C:\flutter" --run-tests

As a service

CLAUDE.md calls this an M2M microservice; this is the part a machine buyer calls.

X402_SHARED_SECRET=... FLUTTER_ROOT="C:\flutter"   poetry run uvicorn src.service.app:app --port 8000

Builds take minutes, so the API is asynchronous. x402_payment_verified in a submitted PRD is discarded: the PRD is buyer-supplied, so trusting that field would let anyone assert their own payment. Only the server's verifier sets it.

Payment is real x402: the buyer signs an EIP-3009 TransferWithAuthorization (EIP-712), and the service recovers the signer, checks recipient, amount, chain and validity window, and claims the nonce atomically so one signature buys exactly one build.

X402_TOKEN_CONTRACT=0x036CbD...  X402_CHAIN_ID=84532 X402_PAY_TO=0xYourAddress        X402_PRICE_ATOMIC=500000   poetry run uvicorn src.service.app:app --port 8000

Configure nothing and the service refuses every payment — it fails closed rather than falling back to the development shared secret. /healthz reports which mode is active.

Verification is not settlement. A valid signature proves the payer authorised a transfer; it does not prove they hold the balance or that the transfer landed on-chain. Set X402_FACILITATOR_URL and the service submits the authorization for on-chain execution and blocks the 202 until it confirms — so a build only starts once the money has actually moved. Without it, /healthz reports settlement: verification-only and the service is accepting signed promises.

Before the nonce is claimed the service asks the facilitator's /verify endpoint whether the payment would settle. Insufficient funds is recoverable — the payer tops up and re-presents the same signature — so burning their authorization for it would be needlessly destructive.

Settlement distinguishes three outcomes, not two. A refusal ("insufficient funds") is definite and is not retried. A timeout is unknown: the facilitator may have broadcast and failed to answer, so the build is refused while recording that

... View full README on GitHub