{"id":48322706,"url":"https://github.com/metareflection/dafny-replay","last_synced_at":"2026-04-05T00:43:43.455Z","repository":{"id":331294297,"uuid":"1120365801","full_name":"metareflection/dafny-replay","owner":"metareflection","description":"Verified kernels, written in Dafny and compiled to JavaScript, for correct-by-construction state in interactive web applications","archived":false,"fork":false,"pushed_at":"2026-03-07T05:45:41.000Z","size":3863,"stargazers_count":27,"open_issues_count":0,"forks_count":1,"subscribers_count":2,"default_branch":"main","last_synced_at":"2026-03-07T13:29:32.399Z","etag":null,"topics":["dafny","javascript","llm","reactjs","verification"],"latest_commit_sha":null,"homepage":"https://midspiral.com/blog/from-intent-to-proof-dafny-verification-for-web-apps/","language":"TypeScript","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/metareflection.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null,"notice":null,"maintainers":null,"copyright":null,"agents":null,"dco":null,"cla":null}},"created_at":"2025-12-21T03:54:02.000Z","updated_at":"2026-03-07T05:45:45.000Z","dependencies_parsed_at":null,"dependency_job_id":null,"html_url":"https://github.com/metareflection/dafny-replay","commit_stats":null,"previous_names":["metareflection/dafny-replay"],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/metareflection/dafny-replay","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/metareflection%2Fdafny-replay","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/metareflection%2Fdafny-replay/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/metareflection%2Fdafny-replay/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/metareflection%2Fdafny-replay/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/metareflection","download_url":"https://codeload.github.com/metareflection/dafny-replay/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/metareflection%2Fdafny-replay/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":31420770,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-04-05T00:25:07.052Z","status":"ssl_error","status_checked_at":"2026-04-05T00:25:05.923Z","response_time":60,"last_error":"SSL_connect returned=1 errno=0 peeraddr=140.82.121.6:443 state=error: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["dafny","javascript","llm","reactjs","verification"],"created_at":"2026-04-05T00:43:43.281Z","updated_at":"2026-04-05T00:43:43.446Z","avatar_url":"https://github.com/metareflection.png","language":"TypeScript","funding_links":[],"categories":[],"sub_categories":[],"readme":"# dafny-replay\n\n[![CI](https://github.com/metareflection/dafny-replay/actions/workflows/ci.yml/badge.svg)](https://github.com/metareflection/dafny-replay/actions/workflows/ci.yml)\n\n**Verified kernels, written in Dafny and compiled to JavaScript, for correct-by-construction state in interactive web applications.**\n\n**Check out our blog posts**:\n- [_From Intent to Proof: Dafny Verification for Web Apps_](https://midspiral.com/blog/from-intent-to-proof-dafny-verification-for-web-apps/)\n- [_Building a React App with Formally Verified State_](https://midspiral.com/blog/building-a-react-app-with-formally-verified-state/)\n- [_Verifying State \u0026 Reconciliation in Collaborative Web Apps_](https://midspiral.com/blog/verifying-state-reconciliation-in-collaborative-web-apps/)\n- [_The Intent Envelope: Proofs for Completeness, Not Just Soundness_](https://midspiral.com/blog/intent-envelope-proofs-for-completeness-not-just-soundness/)\n\n**Check out [lemmafit](https://github.com/midspiral/lemmafit)**, which streamlines the dafny-replay methodology.\n\nThis project started as a verified replay (undo/redo) kernel for UI state—hence the name—and has grown into a broader exploration of verified state evolution across both local and client–server settings.\n\n`dafny-replay` provides small, reusable **verified kernels for application state**—including replayable (undo/redo, time-travel) state and experimental client–server authority kernels—where **global invariants are proved once and preserved by construction**.\n\nThe core idea is simple:\n\n\u003e If every state transition preserves an invariant (and the initial state satisfies it), then *every* state reachable through the system\n\u003e (including via replay or protocol interaction) also satisfies that invariant — by construction.\n\n\nThis repository contains:\n\n* a **generic replay kernel** proved once,\n* a **generic authority kernel** for server-authoritative client–server protocols,\n* a **generic multi-collaboration kernel** for server-authoritative protocols with offline clients,\n* a **generic effect state machine** for client-side effect orchestration with bounded retries,\n* a **generic multi-project kernel** for cross-project operations with per-project invariants,\n* multiple **concrete domains** proved against these kernels,\n* a **React demo pipeline** using the compiled JavaScript.\n\nIt also doubles as a **benchmark for Dafny + LLM proof assistance**, exercising non-local invariants and sequence/map reasoning.\n\n### List of Kernels\n\n| Kernel                 | Setting                        | Guarantees |\n|------------------------|--------------------------------|------------|\n| Replay                 | Local UI state                 | Undo/redo preserves global invariants |\n| Authority              | Client–server                  | State always satisfies invariants |\n| Multi-Collaboration    | Client–server, offline clients | State satisfies invariants; Anchor-based moves, candidate fallback, minimal rejection |\n| Effect State Machine   | Client-side effect orchestration | Bounded retries, mode consistency, pending preservation, no silent data loss |\n| Multi-Project          | Cross-project operations         | Per-project invariant preservation, pending preservation, bounded retries |\n\n### List of Apps\n\n| App         | Domain                    | Key Guarantees |\n|-------------|---------------------------|----------------|\n| Kanban      | Task board                | Exact card partition (no duplication/loss), WIP limits respected |\n| Canon       | Diagram constraint solver | Valid node/edge references, constraint integrity, undo/redo support |\n| ColorWheel  | Color palette generator   | Colors satisfy mood constraints (S/L bounds), hues follow harmony patterns |\n| ClearSplit  | Expense splitting         | Conservation of money (sum of balances = 0), delta laws for expenses/settlements |\n| CollabTodo  | Collaborative task lists  | Task uniqueness per list, exact partition, membership constraints, soft delete semantics |\n\n### List of [Backend](BACKEND.md)s\n\n| Backend                      | Features | Authorization | Trade-off |\n|------------------------------|----------|---------------|-----------|\n| [Supabase](SUPABASE.md)      | Managed auth (OAuth), RLS, built-in realtime | Database-level (RLS) | Batteries included, higher cost |\n| [Cloudflare](CLOUDFLARE.md)  | D1, Workers, Durable Objects, custom JWT | Application-level | Build your own, lower cost |\n\n---\n\n## List of [Kernels](kernels)\n\n### The Replay Kernel\n\nArchitecture:\n```\nAbstract Domain (spec)\n        ↓ refined by\nConcrete Domain (Model, Action, Inv, Apply, Normalize)\n        ↓ plugged into\nReplay Kernel (generic, proved once)\n        ↓ compiled to JS\nAppCore (React-facing API)\n```\n\nThe kernel maintains:\n\n```text\nHistory = { past, present, future }\n```\n\nand provides:\n\n* `Do(action)`\n* `Undo`\n* `Redo`\n\nIt is proved *once* that replay preserves the domain invariant.\n\n### Domain obligation (the only proofs you owe)\n\nFor a given domain, you must prove:\n\n```text\nInv(Init())\nInv(m) ⇒ Inv(Normalize(Apply(m, action)))\n```\n\nAfter that, **undo/redo correctness is automatic**.\n\n---\n\n## The Authority Kernel\n\n\u003cdetails\u003e\nIn addition to local replay, the repository includes an experimental **authority kernel** for **server-authoritative application state** with optimistic clients.\n\nThe authority kernel models a single authoritative server that maintains:\n\n```text\nServerState = { version, present }\n```\n\nand exposes two operations:\n\n* `Dispatch(clientVersion, action)`\n* `Sync()`\n\nClients may optimistically apply actions locally, but the server evolves its state **only through verified transitions**.\n\nEach request is handled as follows:\n\n* **Stale version** → rejected (client must resync)\n* **Invalid action** → rejected (domain-level failure)\n* **Valid action** → applied, version incremented\n\nOn success, the server returns the updated state; on failure, the server state remains unchanged.\n\n### Domain obligation (authority)\n\nFor a given domain, the only required proof is that **successful transitions preserve the invariant**:\n\n```text\nInv(m) ∧ TryStep(m, action) = Ok(m′) ⇒ Inv(m′)\n```\n\nThe authority kernel is proved once to preserve the invariant of the authoritative state across all protocol interactions, regardless of client behavior.\n\nThis kernel is intentionally minimal: it models a single authoritative state and versioned protocol. The Multi-Collaboration kernel generalizes it with rebasing and candidate fallback for handling stale clients.\n\u003c/details\u003e\n\n---\n\n## The Multi-Collaboration Kernel\n\n\u003cdetails\u003e\n\u003csummary\u003eA kernel for server-authoritative collaboration with offline clients.\u003c/summary\u003e\n\nSee also the [MULTICOLLAB](MULTICOLLAB.md) design note.\nSee also the original [SUPABASE](SUPABASE.md) design note for how this kernel can contribute the project model and the server reconciliation in a setup where Supabase contributes user management, database, and realtime.\n\nClients may submit actions based on stale versions. The server reconciles each action against the intervening history using a domain-defined function, then either accepts it (updating the authoritative log) or rejects it.\n\nAll accepted states are proved to satisfy the domain invariant.\n\nThe multi-collaboration kernel (`MultiCollaboration.dfy`) provides:\n\n* **Anchor-based placement**: Instead of positional indices, moves use `Place` (AtEnd, Before, After) to express intent relative to other cards. This is more robust to concurrent edits.\n\n* **Candidate fallback**: When an anchor is missing (e.g., moved or deleted by another client), the server tries a list of fallback candidates (e.g., AtEnd) before rejecting.\n\n* **Minimal rejection**: The server rejects a request only if no interpretation within the domain's declared intent envelope would succeed. For MoveCard, the server tries three candidates: original placement, AtEnd, and Before(first). Lemma `BeforeFirstImpliesAtEnd` proves Before(first) is redundant—if it succeeds, AtEnd also succeeds. This justifies defining `Explains` to cover only origPlace and AtEnd, and the kernel proves dispatch rejects only when both would fail.\n\n* **Server-allocated IDs**: Card IDs are allocated by the server (via `nextId`), eliminating client-side ID conflicts.\n\n* **Real invariants**: A comprehensive 7-part invariant covering column uniqueness, lane/WIP consistency, card existence, no duplicates, WIP limits, and allocator freshness.\n\nThe kernel is designed for domains where \"intent\" matters more than exact positioning, mirroring a common pattern in collaborative editors (e.g. Google Docs): preserve intent when possible, fall back deterministically, and reject only when no reasonable interpretation exists.\n\n- See the app kanban-multi-collaboration/ for an example with a non-persistent server.\n- See the app kanban-cloud/ for an example with user management and database persistence (supports Supabase or Cloudflare backends).\n\u003c/details\u003e\n\n---\n\n## The Effect State Machine\n\n\u003cdetails\u003e\n\u003csummary\u003eA verified model of client-side effect orchestration.\u003c/summary\u003e\n\nSee also the original [SUPABASE](SUPABASE.md) design note for how this kernel integrates with Supabase.\n\nThe Effect State Machine (`EffectStateMachine.dfy`) models the client-side logic that governs:\n\n* **When to flush** pending actions to the server\n* **How to handle responses** (accept, conflict, reject)\n* **Offline/online transitions** with automatic retry on reconnection\n* **Bounded retry logic** to prevent infinite loops\n\nThe state machine maintains:\n\n```text\nEffectState = { network, mode, client, serverVersion }\n```\n\nwhere `network` is `Online | Offline`, `mode` is `Idle | Dispatching(retries)`, and `client` is the verified `ClientState` from MultiCollaboration.\n\nEvents include user actions, dispatch responses, network errors, and manual offline toggles. Each event produces a new state and an optional command (e.g., `SendDispatch`, `FetchFreshState`).\n\n**Key invariants:**\n\n1. **Mode consistency**\n   If dispatching, there must be pending actions.\n\n2. **Bounded retries with eventual retry**\n   Immediate retries bounded by `MaxRetries` (default 5). After max retries, goes idle; next Tick retries with fresh count. This provides bounded hammering + persistent eventual success.\n\n3. **Invariant preservation**\n   All state transitions preserve the invariant.\n\n4. **Pending preservation**\n   Pending actions are never lost. On accept/reject, exactly one action is removed and the rest are preserved in order (`pending' == pending[1..]`).\n\n**Key properties proved:**\n\n* `RetriesAreBounded` — retries never exceed the maximum\n* `TickStartsDispatch` — if online, idle, and has pending, a Tick starts dispatch\n* `MaxRetriesLeadsToIdle` — exceeding max retries transitions to Idle\n* `StepPreservesInv` — all transitions preserve the invariant\n* `PendingNeverLost` — pending actions are never arbitrarily lost; at most one removed per event\n* `PendingSequencePreserved` — on accept/reject: `pending' == pending[1..]` (exact sequence equality)\n* `ConflictPreservesPendingExactly` — on conflict: `pending' == pending` (nothing lost)\n* `UserActionAppendsExact` — on user action: `pending' == pending + [action]`\n\n**System properties proved** (in `EffectSystemProperties.dfy`):\n\n* `NoSilentDataLoss` — every action in pending either stays in pending or is explicitly processed (accepted/rejected); actions never silently disappear\n* `UserActionEntersPending` — user actions are guaranteed to enter the pending queue\n* `FIFOProcessing` — actions are processed in order; only the first pending action can leave\n* `OnlineIdlePendingMakesProgress` — system makes progress when online with pending actions\n\nThe JS layer only handles I/O (network calls, browser events) and converts responses to events that feed back into the verified `Step` function.\n\nSee kanban-cloud/ for a complete example using the Effect State Machine.\n\u003c/details\u003e\n\n---\n\n## The Multi-Project Kernel\n\n\u003cdetails\u003e\n\u003csummary\u003eA kernel for cross-project operations that builds on Multi-Collaboration.\u003c/summary\u003e\n\nSee the [MULTIPROJECT](MULTIPROJECT.md) design note and the original [MULTIPROJECT_SUPABASE](MULTIPROJECT_SUPABASE.md) for Supabase integration details.\n\nThe Multi-Project kernel (`MultiProject.dfy`) is an abstract module that extends the Multi-Collaboration kernel to support operations spanning multiple projects (e.g., MoveTaskTo, CopyTaskTo). Concrete domains refine this module to add domain-specific cross-project actions.\n\n**Key insight:** The action itself declares which projects it touches via `TouchedProjects(action)`.\n\n**Data structures:**\n* `MultiModel` — map from project IDs to individual project models\n* `MultiAction` — actions that can span projects (Single, MoveTaskTo, CopyTaskTo)\n* `MultiClientState` — tracks versions per-project, not globally\n\n**Core functions:**\n* `TouchedProjects(action)` — returns set of project IDs the action affects\n* `MultiStep(mm, action)` — applies action; returns `Ok(newModel)` or `Err`\n* `MultiRebase` — rebases action through concurrent changes per project\n\n**Domain obligation (must be proved by each concrete multi-project domain):**\n\n```text\nMultiInv(mm) ∧ MultiStep(mm, a) = Ok(mm′) ⇒ MultiInv(mm′)\n```\n\nWhere `MultiInv(mm)` means every project in `mm` satisfies its individual invariant.\n\n**Kernel-proved properties (assuming the domain discharges its obligation):**\n\n*MultiProjectEffectStateMachine.dfy* proves:\n* `StepPreservesInv` — all state transitions preserve the effect state invariant\n* `PendingNeverLost` — pending actions are never arbitrarily lost\n* `RealtimeUpdatePreservesPendingExactly` — realtime updates preserve pending exactly\n* `ConflictPreservesPendingExactly` — conflicts preserve pending exactly\n* `PendingSequencePreserved` — on accept/reject: `pending' == pending[1..]`\n* `RetriesAreBounded` — retries never exceed MaxRetries\n* `UserActionAppendsExact` — user actions append exactly the action to pending\n\n**Architectural properties (unverified, trusted):**\n\nThe architecture uses the verified functions but adds unverified components:\n\n* **Server atomicity**: The database layer (`save_multi_update`) wraps updates in a single PostgreSQL transaction with optimistic locking. If any version check fails, the entire transaction rolls back.\n\n* **Realtime propagation**: Supabase Realtime sends per-row notifications separately. A cross-project operation updating two projects produces two events that arrive independently—clients may briefly see inconsistent state until both arrive.\n\n* **Edge function glue**: The edge function calls `MultiStep` and writes results to the database. This orchestration code is unverified.\n\nSee collab-todo/ for a complete example using the Multi-Project kernel (supports Supabase or Cloudflare backends).\n\u003c/details\u003e\n\n---\n\n## List of Apps/Domains\n\n### Toy domain (counter)\n\n\u003cdetails\u003e\n\u003csummary\u003eA minimal sanity check:\u003c/summary\u003e\n\n* `Model = int`\n* invariant: `m ≥ 0`\n\n\u003eUseful for bootstrapping the pipeline.\n\nSee counter/ and counter-authority/.\n\u003c/details\u003e\n\n### Kanban board (non-trivial)\n\n\u003cdetails\u003e\n\u003csummary\u003eA realistic, non-local domain with:\u003c/summary\u003e\n\n* dynamic columns (string IDs),\n* ordered cards per column,\n* per-column WIP limits,\n* model-allocated card IDs,\n* undo/redo over drag-and-drop operations.\n\n**Key invariants:**\n\n1. **Exact partition**\n   Every card exists in *exactly one* column\n   (no disappearance, no duplication).\n2. **WIP limits respected**\n   Column sizes never exceed their limits.\n\nThis domain requires substantial sequence and map reasoning and serves as a **stress test** for Dafny automation and LLM-assisted proof construction.\n\nSee kanban/ (replay kernel) and kanban-multi-collaboration/ and kanban-cloud/ (both multi-collaboration kernel).\n\u003c/details\u003e\n\n### Delegation Auth (capability delegation)\n\n\u003cdetails\u003e\n\u003csummary\u003eA permission system with transitive capability delegation:\u003c/summary\u003e\n\n* subjects (users/entities),\n* direct capability grants,\n* delegations (edges transferring capability access),\n* revocable delegation edges with unique IDs.\n\n**Key invariants:**\n\n1. **Referential integrity**\n   All grant subjects and delegation endpoints must exist in the subject set.\n2. **Fresh edge IDs**\n   Delegation IDs are always less than the allocator counter.\n\n**Access semantics:**\n\nA subject *can* access a capability if:\n* they have a direct grant, OR\n* there exists a delegation chain from a granted subject to them.\n\nThe `Reach` function computes transitive closure via bounded iteration, with a proof (`ReachCorrect`) that it matches the ghost specification `HasCap`.\n\u003c/details\u003e\n\n### Canon (diagram constraint solver)\n\n\u003cdetails\u003e\n\u003csummary\u003eA visual diagram editor with geometric constraints:\u003c/summary\u003e\n\n* nodes with (x, y) positions,\n* directed edges between nodes,\n* alignment constraints (horizontal/vertical),\n* even-spacing constraints,\n* automatic constraint solver (canonicalization).\n\n**Key invariants:**\n\n1. **Referential integrity**\n   All constraints and edges reference only existing nodes.\n2. **Constraint ID freshness**\n   Constraint IDs are always less than the allocator counter.\n\u003c/details\u003e\n\n### ColorWheel (color palette generator)\n\n\u003cdetails\u003e\n\u003csummary\u003eA verified color palette generator that enforces mood and harmony constraints by construction.\u003c/summary\u003e\n\n**Of note**:\n* This app separates the spec from the proof for the purpose of ensuring that the LLM is not independently making edits to the spec in order for the proof to go through. A change to the spec was made so that proofs could complete, but it was approved by the user first. \n* This app includes a helpful file `PROVED.md` which shows what implementations were actually proven and which were shipped as is. \n\n**Model:**\n* Base hue (0-359, the anchor for harmony calculations)\n* Mood (Vibrant, SoftMuted, Pastel, DeepJewel, Earth, Neon, or Custom)\n* Harmony (Complementary, Triadic, Analogous, SplitComplement, Square, or Custom)\n* Colors (always exactly 5 HSL colors)\n* Adjustment mode (Linked or Independent) —\n* Contrast pair (foreground/background indices) — *incomplete in UI*\n\n**Key invariants:**\n\n1. **Mood Satisfaction**\n   All 5 colors satisfy the current mood's saturation/lightness bounds (e.g., Vibrant requires S \u003e= 70, 40 \u003c= L \u003c= 60). When a color violates bounds, the system auto-transitions to Custom mood.\n\n2. **Harmony Coherence**\n   Hues follow the selected harmony pattern relative to the base hue (e.g., Complementary produces hues at H and H+180). When a hue deviates, the system auto-transitions to Custom harmony.\n\n3. **Graceful Degradation**\n   Adjustments that would break constraints automatically fall back to Custom mode rather than failing—the palette always remains valid.\n\u003c/details\u003e\n\n### ClearSplit (expense splitting)\n\n\u003cdetails\u003e\n\u003csummary\u003eA verified expense-splitting application with mathematically guaranteed conservation of money.\u003c/summary\u003e\n\n**Model:**\n* Members (group participants)\n* Expenses (payer, amount, shares per participant)\n* Settlements (payments between members)\n\n**Key invariants and theorems:**\n\n1. **Conservation Theorem**\n   The sum of all balances is always zero—money cannot appear or disappear.\n\n2. **AddExpense Delta Law**\n   When an expense is added:\n   * Payer's balance increases by amount (minus their share if they're a participant)\n   * Each participant's balance decreases by their share\n   * All other balances unchanged\n\n3. **AddSettlement Delta Law**\n   When a settlement is recorded:\n   * Payer's balance increases by amount (they owe less)\n   * Recipient's balance decreases by amount (they are owed less)\n   * All other balances unchanged\n\n4. **ExplainSumsToBalance**\n   A person's balance equals the sum of all their transaction deltas—providing an auditable history.\n\n**Architecture:**\n\nThe code is structured as an abstract specification module (`ClearSplitSpec`) containing user-facing types, predicates, and theorem signatures, refined by an implementation module (`ClearSplit`) containing all helper lemmas and proofs.\n\u003c/details\u003e\n\n### CollabTodo (collaborative task lists)\n\n\u003cdetails\u003e\n\u003csummary\u003eA verified collaborative todo application with projects, lists, and tasks.\u003c/summary\u003e\n\n**Model:**\n* Projects (Personal or Collaborative mode)\n* Lists (ordered, unique names per project)\n* Tasks (belong to exactly one list, unique titles per list)\n* Tags (project-scoped, attachable to tasks)\n* Soft delete with restore capability\n\n**Key invariants:**\n\n1. **Exact partition**\n   Every non-deleted task exists in exactly one list (no orphans, no duplicates).\n\n2. **Unique list names**\n   List names are unique within a project (case-insensitive).\n\n3. **Unique task titles per list**\n   Task titles are unique within each list (case-insensitive).\n\n4. **Membership constraints**\n   Task assignees must be project members; owner always in members; personal projects have exactly one member.\n\n5. **Referential integrity**\n   Tags referenced by tasks must exist; allocators are fresh.\n\n6. **Valid dates**\n   All due dates are valid calendar dates.\n\n**Conflict resolution:**\nUses anchor-based placement with candidate fallback for concurrent edits. DeleteTask conflicts honor the delete, with soft-delete enabling restore.\n\n**Architecture:**\nUses the Multi-Project kernel (see [MULTIPROJECT.md](MULTIPROJECT.md)) for cross-project operations (MoveTaskTo, CopyTaskTo). Integrates with Supabase for user management, database persistence, and realtime updates (see [MULTIPROJECT_SUPABASE.md](MULTIPROJECT_SUPABASE.md)).\n\nSee collab-todo/ for the full implementation.\n\u003c/details\u003e\n\n---\n\n## Why this is interesting\n\nUsing AI for code generation today means choosing between blind trust and heavy supervision. We want a third option: reduce the surface area of human review while increasing trust in correctness. `dafny-replay` demonstrates this approach with UI state:\n\n* The human expresses intent in natural language\n* The LLM generates a formal spec\n* The human reviews and approves the spec (the only review required)\n* The LLM writes implementations, automatically verified against the spec\n* All final implementations are mathematically guaranteed to satisfy the spec\n\n---\n\n## How to run\n\n### 0. Clone the repo\n\n```bash\ngit clone --recursive https://github.com/metareflection/dafny-replay\ncd dafny-replay\n```\n\n### 1. Verify the Dafny code\n\n```bash\n./verify.sh\n```\n\nAll files should verify.\n\n### 2. Compile to JavaScript\n\n```bash\n./compile.sh\n```\n\nThis produces JavaScript artifacts consumed by the demo.\n\n### 3. Run the React demos\n\n```bash\ncd counter           # counter\ncd kanban            # Kanban board\ncd delegation-auth   # capability delegation\ncd counter-authority # counter with client-server protocol\ncd kanban-multi-collaboration  # kanban with multi-collaboration\ncd kanban-cloud      # kanban with backend (requires setup)\ncd canon             # Canon diagram builder\ncd colorwheel        # color wheel app\ncd clear-split       # ClearSplit app\ncd clear-split-cloud # clear-split with backend (requires setup)\ncd collab-todo       # CollabTodo app (requires backend setup)\nnpm install\nnpm run dev\n```\n\n---\n\nSee [HOWTO.md](HOWTO.md) for a walkthrough of how to build a Dafny-verified React app.\n\nSee [INTEGRATION.md](INTEGRATION.md) for notes on integrating Dafny-compiled JavaScript into a JavaScript codebase.\n\nSee [GUARANTEES.md](GUARANTEES.md) for a precise statement of what is proved, what is assumed, and what is trusted.\n\n---\n\n## What this is not\n\n* Not a UI framework\n* Not a CRDT library\n* Not a security or authentication framework\n* Not optimized for performance\n\nThis is an experimental methodology that ensures **correctness by construction** for application state.\n\n---\n\n## Status\n\n* ✔ Generic replay kernel proved\n* ✔ Generic authority kernel for client–server architectures proved\n* ✔ Generic multi-collaboration kernel for client–server architectures proved\n* ✔ Generic effect state machine for client-side orchestration proved\n* ✔ JavaScript compilation\n* ✔ React integration\n* ✔ Backend integration: Supabase or Cloudflare (experimental)\n\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fmetareflection%2Fdafny-replay","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fmetareflection%2Fdafny-replay","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fmetareflection%2Fdafny-replay/lists"}