[CLAUDE] Docs: R6 (ANH NEU) - user-memory ngoai repo = 0 git/0 backup/0 history
OWNER-RAISED: lead dang va TRIEU-CHUNG (hardcode $userMemDir) thi anh chi ra GOC: "UserMem phai ghi trong thu-muc du-an chu ko phai o C: -- cai nay lau lau drift dinh mai". DO DUOC: | user-memory C:\Users\<u>\.claude\projects\<slug>\memory\ | 48 file · 151,671 B | 0 git | 0 Dropbox | 0 history | agent-memory <repo>/.claude/agent-memory/ | 82 file tracked | git | Dropbox | history => BAT-DOI-XUNG khong co ly-do ky-thuat nao. RUI-RO THAT (khong phai chuyen gon-gang): bug #53 zero-byte Write -- da MAT INDEX THAT o S45 -- xay ra DUNG tai thu-muc KHONG CO HISTORY de phuc-hoi. Cung bug do o agent-memory => git checkout la xong. => lop phong-thu hien tai = "verify byte>0" = KY-LUAT NGUOI dung thay VERSION-CONTROL. settings.json (project + user) = 0 key cau-hinh memory-path => HARNESS EP. SE CO Y KHONG TU DOI: doi tay => harness thoi auto-inject => MAT memory khoi context = hong nang hon bug dang co. Cho hub tra loi 1 cau: doi duoc khong, va neu khong thi vi sao? SE KHONG ket-luan "harness sai" -- co the co ly-do dung ma SE chua thay (secret? cross-project? per-machine?). SE chi ket-luan: rui-ro la THAT va DO DUOC. HARDCODE = HE-QUA PHU, do chinh xac: sinhe70c0462026-06-18 20:44 -> vac39ba9d2026-07-15 15:12 = SONG 27 NGAY. Co-che KHONG phai "tai-pham nhieu lan" ma la "sinh 1 lan roi SONG SOT qua ra": git log -S bat 8 commit nhung 5/8 co ps1/js-touched=0 (chi doc/WAL NHAC toi path); chi 3 dong vao .ps1/.js that -- va 1 trong do laae957c4"double-check x2 + finalize": mot dot DOUBLE-CHECK da so DUNG FILE do va KHONG BAT DUOC. 🟢 Doi-chung: spawn-model-audit.ps1 (W1, HOM NAY) lam DUNG san + tu ghi-chu "NOT a hardcoded absolute path" => fleet BIET cach dung; thieu LUAT nen file cu khong ai quet. DE-XUAT: (1) memory song trong repo (doi-xung agent-memory) (2) hoac config path (3) hoac toi-thieu document ro "khong duoc version-control, project tu lo backup" + doc-lap: (4) luat no-absolute-path (spawn-model-audit = mau san) (5) khao-sat fleet. 2 LOI LEAD ghi vao request (du-lieu ve quy-trinh, khong phai loi xin loi): (a) va trieu-chung khong hoi goc -- feedback_root_cause_over_symptom DA nam trong memory cua lead ma lead khong tu bat ra; anh phai chi. (b) va dung cai duoc chi, khong quet cai khac -- WAL:30 neu 1 script, lead va roi DUNG; anh hoi moi loi ra script thu 2 cung doc user-memory. Thoat vi MAY, khong vi quy-trinh. Email: broadcasts/outbox/ai_infra/2026-07-15-se-to-ai_infra-r6-user-memory-outside-repo.md content_sha256 d204973b0a2358fb19da2b7a3f24431ccf7c70e1c33c2df1af41ff7caf1c31b7 SELFTEST-STAMP PASS. (KHONG sua email cu -- no da dong hash; sua = pha selftest.) Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
pqhuy1987
@ -0,0 +1,89 @@
|
||||
---
|
||||
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.
|
||||
Reference in New Issue
Block a user