MuseHub server runs incompatible compute_commit_id formula vs published muse clients

TL;DR

musehub/muse_cli/snapshot.py:compute_commit_id is a stale vendored copy. Its formula diverges from muse 0.2.0rc7's muse.core.snapshot.compute_commit_id. Any commit created on the server (notably merge commits from proposal merges) has a hash that no current muse client can verify — muse pull aborts with a content-hash mismatch.

Reproducer

1. muse push staging feat/foo (succeeds)
2. muse hub proposal create --to-branch main (succeeds)
3. muse hub proposal merge sha256:<id> (succeeds — server creates merge commit with old formula)
4. muse pull staging main fails:

   Pull aborted: commit sha256:<hash> is not readable from the local store (corrupt or hash mismatch).
   

Root cause — exact diff

musehub/muse_cli/snapshot.py:compute_commit_id (server, ~line 31):

def compute_commit_id(parent_ids, snapshot_id, message, committed_at_iso) -> str:
    parts = [
        "|".join(sorted(parent_ids)),
        snapshot_id,
        message,
        committed_at_iso,
    ]
    payload = "|".join(parts).encode()
    return hashlib.sha256(payload).hexdigest()

muse 0.2.0rc7/muse/core/snapshot.py:compute_commit_id (client):

def compute_commit_id(parent_ids, snapshot_id, message, committed_at_iso,
                     author="", signer_public_key="") -> str:
    parts = [
        _SEP.join(sorted(split_id(p)[1] for p in parent_ids)),
        split_id(snapshot_id)[1],
        message,
        committed_at_iso,
        author,
        signer_public_key,
    ]
    payload = _SEP.join(parts).encode()
    return blob_id(payload)

Differences:

1. Field count: 4 (server) vs 6 (client; adds author, signer_public_key)
2. Separator: "|" (server) vs \x00 (client _SEP)
3. ID prefix: server hashes ids with "sha256:" prefix; client strips it
4. Return: raw hex (server) vs prefixed "sha256:<hex>" (client)

Note on the existing migration framework

muse/core/migrate.py was clearly designed to handle exactly this kind of formula change: it walks all local commits, recomputes their hashes with compute_commit_id, and rewrites the commit graph + refs accordingly. However, the migration is client-side and operates on already-stored commits.

This bug surfaces before migrate can help: the merge commit's bytes are rejected during pull verification and never reach the local store, so there is no commit object for migrate to rewrite.

Suggested resolution path leveraging the existing framework:

1. Update musehub/muse_cli/snapshot.py:compute_commit_id to match the canonical muse.core.snapshot.compute_commit_id (so future server-created commits use the new formula).
2. Optionally: run a one-time server-side migration that recomputes IDs for existing legacy server-created commits (mirrors what migrate.py does, but on the server's store).
3. Optionally (defense-in-depth): add a compute_commit_id_legacy function to muse/core/snapshot.py and have _verify_commit_id fall back to it on mismatch, queueing the commit for next-migrate. This would have caught and self-healed this incident on the client side.

Local-state inconsistency (secondary bug)

After the failed pull, refs/remotes/staging/main was advanced to the unverifiable commit ID, but the commit object was not persisted. Subsequent muse fetch staging reports staging/main is already up to date despite the object being absent. Suggested: do not advance the remote-tracking ref when the corresponding commit object failed verification, and improve the error message to distinguish "object missing" from "object corrupted".

Environment

• Client: muse 0.2.0rc7 (installed via https://staging.musehub.ai/install.sh)
• Python: 3.14.4
• Server: staging.musehub.ai (advertised as MUSE_VERSION="0.2.0rc7" by the installer)
• Affected repo: aaronrene/knowtation (sha256:aec36dd88481540a12c2dd82fdc49bba647ff66e229eb5926f731c060e1d73b3)
• Affected merge commit: sha256:f0b2ac2a663f8b9e9a75f5ae7482b18cde95bf9b142f0f2f3f82a87924cd05ce

Available for testing

I'm a contributor and happy to test patches and submit a PR.