diff --git a/PLAN.md b/PLAN.md
index 6868468..c179a59 100644
--- a/PLAN.md
+++ b/PLAN.md
@@ -180,6 +180,28 @@ other. Approaches that could address this:
 
 These are significant complexity increases and out of scope for now.
 
+### File attribute tracking (TODO)
+
+Currently the manifest records only file content changes. File metadata (permissions, mtime,
+ownership, xattrs) is not tracked, meaning restore cannot faithfully reconstruct the original
+state.
+
+**Planned approach:**
+- On each run, compare attributes between PREV and PEND for every file in the change list
+- Encode attribute changes explicitly in the manifest alongside content changes
+- Restore walks the delta chain applying both content deltas and attribute deltas in sequence
+
+**Design considerations:**
+- `fs.stat()` gives mode, mtime, uid, gid — but not xattrs, ACLs, or fs-specific attributes
+- Attribute richness is highly filesystem-dependent (ext4, btrfs, APFS, NTFS all differ)
+- Need a pluggable attribute backend, similar to the delta backend, so the attribute set captured
+  and restored can be tuned per deployment without changing core logic
+- Restore must handle the case where an attribute from an older delta is no longer representable
+  on the target filesystem (e.g. restoring to a different fs type) — fail loudly rather than
+  silently skip
+- rsync `-a` already preserves attributes into PEND, so PEND is always the authoritative source
+  of truth for what attributes should be at that point in time
+
 ## Occasional Snapshots
 
 Delta chains are efficient but fragile over long chains. Periodic full snapshots (every N deltas,