# muse — Agent Configuration

This repository is a member of a workspace.
Shared workspace rules live in the parent ``.muse/agent.md``.
This file contains only muse-specific additions.

Managed by `muse agent-config` — regenerate adapters with `muse agent-config sync`.

---

## HARD RULE — No Destructive Actions Without Explicit Permission

Under no circumstances take any destructive or irreversible action without gabriel's
express permission in that conversation. This includes but is not limited to:

- `muse merge --abort` — wipes all uncommitted working tree changes
- `muse reset --hard` — discards commits and working tree changes
- `muse branch -D` — force-deletes branches
- `muse rm` / `muse rm --force` — deletes tracked files
- `muse checkout --force` / `muse checkout --ours` / `muse checkout --theirs`
- Any `--force` flag on any muse command
- Deleting, overwriting, or resetting any file or object store entry

If you encounter a conflict, stale merge state, or dirty working tree — STOP and ask
gabriel what to do. Do not attempt to resolve it yourself. Do not abort, reset, or
discard anything. The cost of losing uncommitted work is catastrophic.

---

## Repo-Specific Notes

### Snapshot Design Intent — Flat Manifest is Intentional

Muse snapshots are flat `path → object_id` dicts covering the entire repo in one
structure. This is a deliberate architectural choice, not an oversight.

**Why not git's recursive tree model?**

Git's tree objects provide subtree sharing: two commits that differ only in `src/`
reuse the same tree object for every other directory. This saves storage at the cost
of requiring recursive tree traversal to reconstruct a file's path.

Muse does not use this model because the primary unit of meaning in Muse is not a
directory — it is a **snapshot of the entire system state**. A music arrangement,
its samples, its metadata, and its MIDI files are one coherent atomic thing. A
genomics dataset, a 3D scene, a financial model — all of these are captured as a
single indivisible state, not a hierarchy of independently meaningful subtrees.

The flat manifest reflects that: state is atomic, not hierarchical.

**Storage tradeoff**

Each snapshot materializes the full path list on disk. For small-to-medium repos
(up to ~100k files) this is not a meaningful constraint — snapshot files are just
path strings and SHA-256 IDs, not blob bytes. On the wire, delta encoding
(`delta_upsert`/`delta_remove`) means only changes are transmitted regardless.

If very large file counts become a real constraint, the natural evolution is a
tiered manifest: flat below a threshold, chunked or tree-structured above it.
The content-addressing model and delta format would not change.

**Domain agnosticism**

At the storage layer, a MIDI file and a Python file are identical — both are just
bytes with a path. Domain semantics live in the content of those bytes, not in how
they are stored. Muse is multi-domain (code, music, genomics, 3D, financial
modeling) but the object store, snapshot, and commit model are the same for all of
them. Do not introduce domain-specific logic into the core storage layer.