Samraaj BathandClaude Fable 5
b66a993b35
Audited docs against the fork-salvage API surface (PR #17). SERVICE.md fixes: - Event stream: events are the compiler's granular {t, ...} log stream plus service phases, not a fixed capture/generate/verify enum. Corrected the "{seq, t, ...payload}" claim — returned bodies carry `t` but NOT `seq`. Documented that `after` is a seq cursor (DB filters seq > N) and that the in-memory backend ignores `after` and returns the full list each poll. - preview.html: new Preview section — the flat, self-contained generate-time artifact (file-map path `preview.html`, manifest `preview_html`, always present), fetched via /v1/clones/:id/files/preview.html. Documented its arrival on the `generated` event, relative `public/assets/...` resolution through the files route, the authenticated-iframe caveat + proxy recommendation, and the original→preview.html→deployed staging. Stated plainly that it is static/runtime-free: frozen animations, no interactions. - Added the `preview` option and clarified app-preview (built export) vs the flat preview.html. DEPLOY.md migration list (0000/0001/0002) verified accurate — no change. README.md / docs/README.md make no stale API claims — no change. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
ditto.site Documentation
The central index for ditto.site's docs. Start here.
First, the word "clone." In ditto.site, cloning means generating a codebase from a live URL — it is not
git clone. You do not need an existing Git repository, and you do not need the target site's source code. You give ditto.site a public URL; it captures what the page renders in a browser and writes you a fresh, runnable project. (The onlygit cloneinvolved is optionally cloning this tool's repository to run the compiler locally.)
Get started
| I want to… | Go to |
|---|---|
| Understand what ditto.site is and see it run | Project README |
| Call the hosted REST API or MCP server | Project README → Usage, SERVICE.md |
| Turn a clone result JSON into files on disk | Repo-local unpack CLI |
| Run the compiler locally from the command line | compiler/README.md |
| Deploy the service | DEPLOY.md |
| Read the development & evaluation method | METHODOLOGY.md |
| Understand responsible-use boundaries | RESPONSIBLE_USE.md |
| Cut a release | RELEASING.md |
API keys are secrets
Keys look like dtto_live_.... Keep them in an environment variable and reference
it in commands:
export DITTO_API_KEY="dtto_live_..."
curl -sS -H "authorization: Bearer $DITTO_API_KEY" "$DITTO_API_URL/v1/clones"
Never paste a raw key inline (it leaks into shell history, logs, and chat), and never commit one. Rotate a leaked key anytime from the dashboard. See SERVICE.md for the full auth model.
The short version of the workflow
- Clone a URL →
POST /v1/clones(API) ornpm run clone -- <url>(local CLI). - Get the app → unpack the result JSON with the repo-local unpack CLI,
download the
bundle?format=tgzarchive, or read files fromruns/<site>/latest/. - Preview it →
cdinto the app andnpm install && npm run dev(or let the local CLI do it for you with--serve/--open). - Edit safely → each generated app ships an
AGENTS.mddescribing what's safe to change (copy insrc/app/content.ts, components insrc/app/components/, etc.).
Full doc list
- SERVICE.md — REST + MCP service reference (endpoints, options, env vars).
- DEPLOY.md — production deployment.
- METHODOLOGY.md — how the compiler is developed and evaluated.
- RESPONSIBLE_USE.md — acceptable-use boundaries.
- RELEASING.md — release process.
- ../compiler/README.md — local compiler commands.
- ../packages/cli/README.md — the repo-local unpack CLI.