README.md
markdown
| 1 | # Muse Demo Hub |
| 2 | |
| 3 | Two domains. One abstraction. Everything Git can't do. |
| 4 | |
| 5 | Muse is a domain-agnostic version control system built on a six-method plugin |
| 6 | interface. The same DAG, the same object store, the same branch and merge |
| 7 | engine — different semantic understanding of your data depending on which plugin |
| 8 | you use. |
| 9 | |
| 10 | The two demos below show the full depth of what that means. |
| 11 | |
| 12 | --- |
| 13 | |
| 14 | ## Choose Your Domain |
| 15 | |
| 16 | ### [Music Demo](tour-de-force-script.md) — MIDI files, note-level diffs |
| 17 | |
| 18 | The original Muse demo. A MIDI repository with five orthogonal dimensions: |
| 19 | melodic, rhythmic, harmonic, dynamic, structural. |
| 20 | |
| 21 | **What it demonstrates:** |
| 22 | |
| 23 | - A drummer and a pianist editing the same MIDI file simultaneously — no |
| 24 | conflict, because they touched different dimensions |
| 25 | - A single structural conflict resolved while four dimensions auto-merge |
| 26 | - Note-level diffs: not "file changed" but "insert note C4 at tick 480, |
| 27 | velocity 80, duration 240" |
| 28 | - Cherry-pick, stash, revert — the full VCS surface area |
| 29 | - OT Merge: two note insertions at different tick positions commute → auto-merge |
| 30 | - CRDT Semantics: `join()` always succeeds, never conflicts |
| 31 | |
| 32 | **The key insight:** Git can't diff a MIDI file at all. Muse understands every |
| 33 | note, every chord voicing, every tempo change — and uses that understanding to |
| 34 | resolve conflicts that Git would mark as binary file conflicts. |
| 35 | |
| 36 | **Runtime:** ~150ms · 14 commits · 6 branches · 1 conflict resolved |
| 37 | |
| 38 | --- |
| 39 | |
| 40 | ### [Code Demo](tour-de-force-code.md) — Source code, symbol-level diffs |
| 41 | |
| 42 | The code plugin demo. A software repository in Python, TypeScript, Go, and Rust |
| 43 | — eleven languages total. |
| 44 | |
| 45 | **What it demonstrates:** |
| 46 | |
| 47 | - `muse symbols` — list every function, class, and method in a snapshot |
| 48 | (impossible in Git — Git doesn't know what a function is) |
| 49 | - Rename detection via `body_hash`: same implementation, new name → `ReplaceOp` |
| 50 | annotated "renamed to X", not a delete + add |
| 51 | - Cross-file move detection via `content_id`: function moved to a new module → |
| 52 | connection preserved in the DAG forever |
| 53 | - Two engineers modify the same file, different functions → **auto-merge** |
| 54 | (commuting ops) |
| 55 | - `muse symbol-log` — track one function's complete history, through renames, |
| 56 | across the full commit graph (impossible in Git) |
| 57 | - `muse detect-refactor` — machine-generated semantic refactoring report: |
| 58 | renames, moves, signature changes, implementation changes (impossible in Git) |
| 59 | |
| 60 | **The key insight:** Git treats code as text files and lines. Muse treats code |
| 61 | as a structured graph of named, typed symbols with content-addressed identities |
| 62 | that persist across renames, moves, and refactors. Two engineers touching the |
| 63 | same file but different functions never conflict. |
| 64 | |
| 65 | **Languages:** Python · TypeScript · JavaScript · Go · Rust · Java · C · C++ · C# · Ruby · Kotlin |
| 66 | |
| 67 | --- |
| 68 | |
| 69 | ## The Shared Architecture |
| 70 | |
| 71 | Both demos run on the same engine. The only difference is the plugin. |
| 72 | |
| 73 | ``` |
| 74 | muse init --domain music # → MusicPlugin |
| 75 | muse init --domain code # → CodePlugin |
| 76 | ``` |
| 77 | |
| 78 | The DAG, object store, branch model, and merge state machine are identical. |
| 79 | Each plugin implements six methods that tell the engine how to interpret its data: |
| 80 | |
| 81 | | Method | What it does | |
| 82 | |--------|-------------| |
| 83 | | `snapshot()` | Walk the working tree; return a content-addressed manifest | |
| 84 | | `diff(old, new)` | Produce a `StructuredDelta` of typed ops (Insert/Delete/Replace/Move/Patch) | |
| 85 | | `drift(live, snapshot)` | Detect uncommitted working-tree changes | |
| 86 | | `apply(delta, state)` | Apply a delta to a state (used by checkout/revert/cherry-pick) | |
| 87 | | `merge(base, left, right)` | Three-way merge with domain-specific conflict detection | |
| 88 | | `schema()` | Declare the domain schema; engine auto-selects diff algorithms | |
| 89 | |
| 90 | Adding a new domain: `muse domains --new <name>`. Thirty seconds to scaffold. |
| 91 | |
| 92 | --- |
| 93 | |
| 94 | ## The Four Semantic Layers |
| 95 | |
| 96 | Both plugins implement all four capability levels: |
| 97 | |
| 98 | | Phase | Capability | What you gain | |
| 99 | |-------|-----------|---------------| |
| 100 | | 1 | **Typed Delta Algebra** | Typed op lists instead of opaque diffs | |
| 101 | | 2 | **Domain Schema** | Engine auto-selects the right diff algorithm per dimension | |
| 102 | | 3 | **OT Merge Engine** | Sub-symbol auto-merge via Operational Transformation | |
| 103 | | 4 | **CRDT Semantics** | `join()` always converges — no conflict state ever possible | |
| 104 | |
| 105 | --- |
| 106 | |
| 107 | ## What's Next |
| 108 | |
| 109 | - **Genomics plugin** — annotate genomes with CRDT `ORSet` semantics; concurrent |
| 110 | researcher annotations never conflict |
| 111 | - **3D spatial design** — version CAD models at the geometry level, not as binary |
| 112 | blobs |
| 113 | - **Scientific simulation** — checkpoint simulation state at the tensor level; |
| 114 | diff parameter sweeps by dimension |
| 115 | - **Neural network checkpoints** — version model weights by layer, not by file |
| 116 | |
| 117 | `muse domains --new <your_domain>`. The plugin interface handles the rest. |