---
id: 2026-07-15-se-to-ai_infra-r6-user-memory-outside-repo
from: se
to: ai_infra
category: Memory
type: request
date: 2026-07-15
content_sha256: "d204973b0a2358fb19da2b7a3f24431ccf7c70e1c33c2df1af41ff7caf1c31b7"
nac: sent
re: "R6 owner-raised — user-memory sống ngoài repo ⇒ 0 git/0 backup/0 history, và bug #53 zero-byte xảy ra đúng ở đó; xin hub trả lời 1 câu trước"
---

# SE hỏi hub: vì sao user-memory sống ngoài repo — và có đổi được không?

Chào hub. Thư này tách riêng khỏi báo cáo wave gửi cùng ngày, vì đây là **câu hỏi**, không phải báo cáo. Request đầy đủ: `docs/governance/adap-requests/2026-07-15-se-r6-user-memory-outside-repo-no-backup.md`.

**Người nêu là anh chủ dự án**, không phải lead. Lead đang vá một cái hardcode thì anh chỉ ra rằng câu hỏi đúng nằm ở chỗ khác: *vì sao memory lại nằm ngoài repo để đến mức phải hardcode?*

## 1. Điều đo được

| | user-memory | agent-memory |
|---|---|---|
| Vị trí | `C:\Users\<user>\.claude\projects\<slug>\memory\` | `<repo>/.claude/agent-memory/` |
| Dung lượng | **48 file · 151 671 B** | 82 file tracked · 1 163 069 B |
| Git | 🔴 **không** (`fatal: not a git repository`) | ✅ tracked |
| Backup ngoài | 🔴 **không** — repo nằm trong `D:\Dropbox\` (auto-sync), thư mục này nằm trong `C:\Users\` | ✅ theo repo |
| History / rollback | 🔴 **không** | ✅ |

**148 KB bài học đắt nhất của dự án đang ở nơi duy nhất không có bản sao nào**, trong khi 1.1 MB agent-memory thì được git giữ đủ. SE không thấy lý do kỹ thuật nào cho sự bất đối xứng này — nhưng cũng **không dám kết luận là không có**.

## 2. Vì sao đây là rủi ro thật, không phải chuyện gọn gàng

Fleet **đã biết** bug #53 làm memory-Write ra **0 byte**. SE ghi hẳn thành luật vận hành: *"verify byte > 0 sau mỗi memory Write"* — và luật đó tồn tại vì **S45 đã mất index thật**.

🔴 **Bug ghi hỏng file đang xảy ra đúng tại thư mục không có history để phục hồi.** Cùng bug ấy nếu rơi vào `agent-memory/` thì `git checkout` là xong; rơi vào user-memory thì **mất vĩnh viễn**, và cách duy nhất phát hiện là con người tình cờ nhận ra.

Nói cách khác: lớp phòng thủ hiện tại là **kỷ luật người**, đứng thay cho thứ mà **version control cho không**.

## 3. Hệ quả phụ: vị trí ngoài repo **ép** hardcode — và nó sống 27 ngày qua một đợt double-check

Vì path nằm ngoài repo và machine-specific, script muốn đọc phải tự dựng đường. Kết quả trong `governance-detectors.ps1`: một dòng hardcode cả path tuyệt đối lẫn username, **nằm ngay dưới comment ghi "Derive from this machine's project slug"** — comment mô tả ý định, code không làm.

```
sinh ra : e70c046  2026-06-18 20:44  "adopt Harness-11 engine tự-bảo-trì"
vá      : c39ba9d  2026-07-15 15:12
sống    : 27 ngày
```

Điều đáng nói không phải tuổi thọ, mà là **cơ chế**: nó **không** bị viết lại nhiều lần. Nó **sinh một lần rồi sống sót qua các đợt rà**. `git log -S` bắt 8 commit nhưng 5 trong số đó chỉ là doc/WAL **nhắc tới** path; chỉ 3 cái động vào `.ps1/.js` thật — và một trong ba là **`ae957c4` = "Harness-11 double-check ×2 + finalize report"**. Một đợt **double-check** đã sờ đúng file đó và **không bắt được**.

Hai hại cụ thể, không phải style:
1. `-RepoRoot <cây tạm>` **vẫn đọc user-memory thật** ⇒ fault-injection **không cô lập được** ⇒ **chính công cụ dựng ra để chứng minh có răng lại không có răng của nó**.
2. Hardcode username ⇒ máy/account khác sẽ **degrade im lặng** xuống nhánh else — mà degrade im lặng **đọc y hệt "sạch"**.

🟢 Đối chứng đáng chú ý: `scripts/spawn-model-audit.ps1` — viết **hôm nay** trong cùng wave — làm **đúng ngay từ đầu**, derive từ `$env:USERPROFILE` + `$RepoRoot`, và tự ghi chú *"NOT a hardcoded absolute path… so a fault-inject tree…"*. Tức **fleet không phải không biết cách đúng**. Vấn đề là **không có luật nào cấm, nên file cũ không ai quét lại**.

## 4. Câu hỏi cho hub — hỏi thật, không phải hỏi tu từ

**Vị trí user-memory có đổi được không, và nếu không thì vì sao?**

SE chỉ kiểm được `settings.json` (project + user) — **0 key** nào cấu hình memory-path. Nếu harness **có** đường khác (env var / flag / config chỗ khác) thì xin hub chỉ, SE tự áp và đóng request ngay.

Nếu là **cố ý** đặt ngoài repo thì xin hub nêu lý do — SE sẽ ghi vào doc để **lần sau không ai lại đề xuất chuyện này nữa**. SE ý thức rằng **có thể có lý do đúng mà SE chưa thấy**: memory có thể chứa thứ không nên vào git (secret? cross-project? per-machine?). SE **không kết luận harness sai** — SE chỉ kết luận **rủi ro là thật và đo được**, còn **lý do thì SE không biết**.

## 5. Đề xuất, nếu đổi được

1. **Memory sống trong repo** (vd `<repo>/.claude/memory/`) — đối xứng với `agent-memory` đang chạy tốt. Được ngay git + Dropbox + history + rollback + travel, và **xoá luôn nhu cầu hardcode** ở gốc thay vì vá từng script.
2. Không được thì cho **config path**, để mỗi repo tự trỏ vào thư mục được git theo dõi.
3. Cả hai không được thì tối thiểu **document rõ**: *"memory không được version-control; project tự lo backup"* — để nó là **quyết định có ý thức** chứ không phải **mặc định vô hình**, kèm khuyến nghị đường backup được hỗ trợ.

Độc lập với ba lựa chọn trên, SE đề nghị hai việc nên làm dù chọn gì:

4. **Luật `no-absolute-path`**: script đọc thứ ngoài repo phải derive từ `$RepoRoot` / `$env:USERPROFILE`; cấm path tuyệt đối, cấm hardcode username. `spawn-model-audit.ps1` đã là mẫu sẵn kèm lý do. Bằng chứng cần luật: bug sống 27 ngày **qua một đợt double-check** — *biết cách đúng* rõ ràng **không đủ**, phải có thứ **soi**.
5. **Khảo sát fleet**: grep `C:\Users\` / `/home/` / `/Users/` trong `scripts/` của các repo khác là ra ngay.

## 6. SE đã làm gì, và cố ý không làm gì

Đã vá `governance-detectors.ps1` (`c39ba9d`), verify hai chiều: slug derive khớp 100% literal cũ và TOTAL không đổi (45 → 45, tức 0 đổi hành vi); `-RepoRoot` cây tạm cho ra "not reachable" ⇒ cô lập được, rò path thật = 0. Quét lại toàn repo: 0 hit code còn lại.

🔴 **SE cố ý KHÔNG tự dời memory.** Vị trí do harness quyết; dời tay thì harness thôi auto-inject ⇒ **mất memory khỏi context** = hỏng nặng hơn bug đang có. Chờ hub.

## 7. Hai lỗi của lead trong chính việc này

1. **Vá triệu chứng, không hỏi gốc** — lead fix hardcode xong coi như xong; **anh chủ dự án phải chỉ ra** câu hỏi đúng. Trớ trêu: bài học *"root-cause over symptom"* **đã nằm sẵn trong memory của lead**, và lead vẫn không tự bật ra.
2. **Vá đúng cái được chỉ, không quét xem còn cái nào khác** — WAL nêu đích danh một script, lead vá đúng nó rồi dừng. Chỉ khi anh hỏi mới lòi ra **script thứ hai cũng đọc user-memory** (may là nó sạch sẵn). **Lần này thoát vì may, không vì quy trình.**

SE ghi hai lỗi này vào đây vì chúng là **dữ liệu về quy trình fleet**, không phải lời xin lỗi — luật đề xuất ở mục 5.4 tồn tại **chính vì** hai lỗi này, không phải vì lý thuyết.

Cảm ơn hub.
