diff --git a/.claude/CLAUDE.md b/.claude/CLAUDE.md
new file mode 100644
index 0000000..00a623c
--- /dev/null
+++ b/.claude/CLAUDE.md
@@ -0,0 +1,10 @@
+# Agent guide
+
+Development principles for working in this repo. User-facing documentation lives in [`docs/`](../docs/).
+
+Topic-focused rules auto-load from [`.claude/rules/`](rules/):
+
+- [`project-stage.md`](rules/project-stage.md) — project maturity and compatibility stance (applies to all work)
+- [`testing.md`](rules/testing.md) — how tests are organized and when to add them
+
+To add a rule that should load **only** when editing certain files, create a new file in `rules/` with a `paths:` frontmatter glob list. Files without `paths:` load on every session.
diff --git a/.claude/rules/project-stage.md b/.claude/rules/project-stage.md
new file mode 100644
index 0000000..2c70c3a
--- /dev/null
+++ b/.claude/rules/project-stage.md
@@ -0,0 +1,8 @@
+# Project stage
+
+This is a fast-evolving, pre-launch project. There are **no production instances**, so:
+
+- **No backward compatibility constraints.** Don't preserve compatibility with existing deployed canisters, previously serialized stable state, or older on-disk formats — there are none to protect. Feel free to change stable-state shapes, drop legacy fields, and remove migration/fallback code paths.
+- **No compatibility with the "old" assets canister.** The canister code was seeded by trimming down a working implementation from the SDK repo, purely as a development shortcut. We do **not** aim to interoperate with or upgrade from that old implementation. Anything that only exists to support it can be removed.
+
+The only contract that matters is that the **canister and sync-plugin in this repo work well together**.
diff --git a/AGENT.md b/.claude/rules/testing.md
similarity index 82%
rename from AGENT.md
rename to .claude/rules/testing.md
index e835acd..e119f1c 100644
--- a/AGENT.md
+++ b/.claude/rules/testing.md
@@ -1,32 +1,28 @@
-# Agent guide
-
-Development principles for working in this repo. Documentation for users lives in [`docs/`](docs/).
-
-## Testing
+# Testing
 
 Tests are organized around three components. Each runs independently.
 
-### Canister (`canister-core`)
+## Canister (`canister-core`)
 
-- **Location**: [`crates/canister-core/src/tests.rs`](crates/canister-core/src/tests.rs)
+- **Location**: [`crates/canister-core/src/tests.rs`](../../crates/canister-core/src/tests.rs)
 - **Run**: `cargo test -p canister-core`
 
 `canister-core` is the library crate behind `canister`. Its unit tests cover all canister behaviors using a mock system context — no live replica needed: asset CRUD, encoding selection, HTTP semantics, certification, permissions, stable state, and streaming.
 
 **Add tests here when** you change anything inside `canister-core`: new canister endpoints, modified serving logic, certification changes, permission rules, or upgrade/downgrade behavior.
 
-### Plugin (`sync-core`)
+## Plugin (`sync-core`)
 
-- **Location**: inline `#[cfg(test)]` modules in each [`crates/sync-core/src/`](crates/sync-core/src/)`*.rs` file
+- **Location**: inline `#[cfg(test)]` modules in each [`crates/sync-core/src/`](../../crates/sync-core/src/)`*.rs` file
 - **Run**: `cargo test -p sync-core`
 
 `sync-core` is the library crate behind `sync-plugin`. It has no WASI dependency and compiles natively. Its unit tests cover all sync business logic: directory scanning, MIME detection and encoding, operation diffing, batch sequencing, canister API calls and pagination, and authorization.
 
 **Add tests here when** you change any sync logic: how files are discovered, how encodings are chosen, how diffs are computed, how batch operations are sequenced, or how permissions are managed. Prefer this over E2E for new logic — tests are fast and require no infrastructure.
 
-### End-to-end (`e2e`)
+## End-to-end (`e2e`)
 
-- **Location**: [`crates/e2e/`](crates/e2e/)
+- **Location**: [`crates/e2e/`](../../crates/e2e/)
 - **Run**: `cargo test -p e2e`
 
 E2E tests verify that the canister and plugin work correctly together through the `icp` CLI against a live local replica. Covers the basic sync workflow: deploy, no-op re-sync, content update, deletion, and multi-directory sync.