Logo Xantham

Xantham Goals — Acceptance Criteria

Single purpose: what "done" means, stated objectively so any claim can be checked against it. Context and analysis: LANDSCAPE.md. Execution steps and their closure: PLAN.md. Current state: STATUS.md.

The goal

Generate F# bindings for the Cloudflare SDK constellation that a consumer uses without reading Xantham internals: dotnet add package, write a Worker/Agent in F#, Fable-compile, run. Xantham itself is a general TypeScript→F#/Fable binding generator; no Cloudflare-specific logic in core — all target knowledge in the recipe (cloudflare.pilot.toml).

Near-term milestone (1:1 import→export): seven npm packages → seven F# libraries (Fidelity.CloudEdge.{Workers, Zod, PartySocket, PartyServer, Mcp, CodeMode, Agents}), sufficient to build a working Worker and a working Agent. Verification is by consumption, not inspection: the samples below compile and run.

End state (steady-state operation): an update run — pin bump → crawl → gates → drift report → regenerate → changed-only republish — processes each upstream Cloudflare release with human attention limited to the drift report and new advisories. Eventual shape: many SDK entries in, many namespaced libraries out, in one run.

Per-layer definitions of done

Reported per area × per layer in a generated STATUS.md (scripts/status-report.sh); a completeness claim exists only per cell, never for the project.

Phase exit criteria

Standing rules

No whole-project completeness claims — cells only. Per-area ratchets never regress. Fix at the owning tier (identity/twins → encoder; resolution/keying → decoder; naming/paths → generator; missing or degraded surface → recipe gap, never a codegen patch). Every gate failure names {area, owning layer, error class, fix location}.

Type something to start searching.