chore(refactor): mục chung của Team Gamma — khung, hợp đồng, cổng CASAN

Sáu việc trong "mục chung" của bản phân công, làm trước khi ba nhánh tính năng
tách ra.

1. Khung 5 tầng theo đúng đường dẫn plan.md: domain/ application/
   infrastructure/ presentation/ platform/ + tests/fakes/ — 38 __init__.py.
   Trước đó là 0 file, mà mọi task của cả ba người đều ghi vào đây.
   Đã kiểm platform/ không che khuất module platform của stdlib.

2. Hợp đồng SecretStore và ConfigRepository (Protocol, chưa cài đặt) + fake
   chạy trong bộ nhớ. Danh sách thuộc tính không bịa: đếm 156 lời gọi
   ctx.config.* trong 29 file rồi lấy những cái dùng thật, xếp theo số lần.
   Cố ý bỏ config.data (36 lời gọi, nhiều nhất) — bê dict thô sang kiến trúc
   mới là bê nguyên vấn đề cũ.

3. tests/test_contracts.py — bài nghiệm thu, không phải test cho vui. Bài
   chính chạy tiến trình riêng và khẳng định dùng fake KHÔNG kéo theo
   cowork_local.config lẫn PySide6; đó là điều kiện để N2 và N3 code ngay hôm
   nay thay vì đợi bản thật ngày 23 và 26/08.

4. scripts/audit_security.py — CASAN Check 1, Gamma chủ trì (hạn 30/08). Viết
   sớm để kiểm liên tục trong lúc chuyển API key, không đợi tới ngày cổng.
   Lần chạy đầu ra 3 báo động giả (secret_in_output là tên quy tắc, api_key="x"
   là dữ liệu test) nên đã siết: ngưỡng độ dài, hằng liệt kê, hình dạng khoá
   i18n, và dấu "# casan: allow" làm lối thoát chuẩn.
   --self-test cắm 4 credential thật + 5 mẫu vô hại để chứng minh nó còn cắn
   được — một máy quét không tìm thấy gì chỉ có giá trị nếu chứng minh được nó
   biết tìm.

5. Ba check CASAN vào CI, chạy mọi PR thay vì dồn tới 30/08. Check 2 và 3
   thuộc Team Hoa và Team Duy, chưa có script — bước CI bỏ qua nếu file chưa
   tồn tại, để thêm cổng không làm đỏ CI của hai team kia.

6. docs/refactor/GammaTeam_decisions.md — hai quyết định chờ nhóm trưởng chốt:
   provider_conf() còn trả api_key hay không (ảnh hưởng 5 nơi, 3 nằm ngoài
   team), và số phận 24 checker UI sẽ vỡ khi file bị dời.

96 test xanh (90 cũ + 6 mới). CASAN Check 1: 0 credential lộ.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

docs/refactor/GammaTeam_decisions.md

@@ -0,0 +1,107 @@
+# Hai quyết định chờ nhóm trưởng chốt — Team Gamma
+
+Hai việc này không code được cho tới khi có người quyết. Cả hai đều ảnh hưởng
+ra ngoài phạm vi một người, nên để đây thay vì chôn trong comment.
+
+Trạng thái: **chưa chốt**. Hạn: trước khi N1 bắt đầu R02-T05 (26/08).
+
+---
+
+## Quyết định 1 — `provider_conf()` còn trả `api_key` hay không
+
+### Vì sao phải quyết trước khi code
+
+R02-T05 chuyển API key sang Keyring. Câu hỏi là sau khi chuyển, dict do
+`provider_conf()` trả về **còn chứa `api_key` không**.
+
+Có 5 nơi đang đọc trực tiếp — đo trên `main` ngày 21/08:
+
+| Nơi đọc | Thuộc |
+|---|---|
+| `providers/anthropic.py:26` | **Team Duy** |
+| `providers/openai_compat.py:36` | **Team Duy** |
+| `core/image_gen.py:50` | Team Duy (routing/model) |
+| `core/ext_connectors.py:98` | Team Hoa |
+| `ui/ext_connector_dialog.py:87` | Team Gamma |
+
+Ba trong năm nằm ngoài team. Quyết một mình rồi im lặng là làm vỡ code người khác.
+
+### Hai đường
+
+**A. Giữ `api_key` trong dict, `ConfigRepository` tự lấy từ `SecretStore` rồi ghép vào**
+
+- 5 nơi đọc **không phải sửa dòng nào**
+- Không cần báo team khác, không cần đồng bộ lịch
+- Đổi lại: bí mật vẫn đi lang thang trong dict, dễ lọt vào log hoặc màn hình debug
+- CASAN Check 1 vẫn PASS vì nó quét **file trên đĩa**, không quét bộ nhớ
+
+**B. Bỏ `api_key` khỏi dict, ai cần thì gọi `secrets.get(provider_key(name))`**
+
+- Sạch về nguyên tắc: bí mật chỉ xuất hiện đúng chỗ cần
+- Đổi lại: **5 nơi phải sửa**, 3 trong đó phải chờ team khác xếp lịch
+- Rủi ro: quên một chỗ thì mất API key lúc chạy thật, mà test có fake nên không bắt được
+
+### Đề xuất
+
+**Đường A cho sprint này, đường B ghi vào nợ kỹ thuật.**
+
+Lý do: mục tiêu của cổng CASAN là *không còn secret nằm trên đĩa*, và đường A
+đạt được điều đó. Đường B giải quyết thêm chuyện secret trong bộ nhớ — đúng
+nhưng không phải việc của 10 ngày này, và nó kéo hai team khác vào một thay đổi
+họ không lên kế hoạch.
+
+Nếu chọn B thì **phải báo Team Duy và Team Hoa trong hôm nay**, không phải lúc
+đã sửa xong.
+
+> Nhóm trưởng chốt: ☐ A ☐ B — ngày ____
+
+---
+
+## Quyết định 2 — số phận 24 checker UI
+
+### Vấn đề
+
+`tools/check_*.py` là bộ kiểm tra giao diện viết trong 2 tuần vừa rồi, hiện
+**24 file**. Chúng bám vào đường dẫn cũ:
+
+| Import | Số chỗ |
+|---|---|
+| `cowork_local.config` | 34 |
+| `cowork_local.app` | 16 |
+| `cowork_local.state` | 22 |
+| `cowork_local.ui.*` | ~12 |
+
+R08 dời hết những module đó sang `presentation/`. Nghĩa là **cả 24 checker chết
+ngay ngày N1 đụng `config.py`** — và đó là lưới an toàn duy nhất cho phần giao
+diện, vì `pytest` không kiểm giao diện (90 test hiện tại là logic).
+
+### Ba đường
+
+**A. Ai dời file thì cập nhật checker tương ứng, ngay trong PR đó**
+
+- Giữ được lưới suốt 10 ngày
+- Tốn thêm ~15% thời gian mỗi PR
+- Rủi ro: người sửa vội có thể nới lỏng phép kiểm cho nó xanh — đã xảy ra một
+  lần trong quá trình làm UI, khi một checker được sửa thành *không thể đỏ*
+
+**B. Đóng băng: bỏ khỏi CI, sửa một lượt ngày 31/08**
+
+- Nhanh nhất trong 10 ngày
+- Đổi lại: **không có gì canh hồi quy giao diện** suốt cả sprint. Refactor là lúc
+  dễ vỡ giao diện nhất
+- Rủi ro cuối sprint: sửa 24 file cùng lúc, không ai nhớ cái nào đo gì
+
+**C. Bỏ hẳn**
+
+Không khuyến nghị. Vứt đi hai tuần công sức kiểm chứng, và ba tài liệu refactor
+không có gì thay thế cho phần giao diện.
+
+### Đề xuất
+
+**Đường A**, kèm một ràng buộc: PR nào *sửa* checker phải nói rõ trong mô tả
+**sửa gì và vì sao** — để việc nới lỏng phép kiểm không lọt qua review.
+
+`tools/check_probes_bite.py` đã có sẵn cơ chế chứng minh checker còn cắn được;
+chạy nó sau mỗi đợt sửa là bắt được ngay chuyện đó.
+
+> Nhóm trưởng chốt: ☐ A ☐ B ☐ C — ngày ____