Ba thư mỗi tuần cho mọi địa chỉ (đề xuất 22.10.2026)

Mục tiêu của người soạn: bất kỳ ai có email trong hệ thống cũng nhận tối thiểu 3 thư mỗi tuần. Trang này là kết quả audit và lịch đề xuất. Nó dựa trên Nhịp thư (shared/email/orchestrator/), không thêm cổng gửi mới.

Audit (đo 22.10.2026, chỉ đọc D1)

Nhóm	Số địa chỉ	Ghi chú
Tổng địa chỉ khác nhau (users ∪ legacy_users)	1.272	1.246 là Gmail
Chỉ có ở legacy_users, chưa từng nhận thư nào	1.107	nhập từ hệ cũ, không có tài khoản mới
Đã từng nhận ít nhất một thư	170	102 người đã mở ít nhất một thư
Nhận thư trong 7 ngày qua	~25	phần lớn là thư giao dịch + profile_incomplete
Đã huỷ nhận (email_preferences)	2
Thư hỏng	1 / 713

Vì sao gần như không ai nhận thư đều: Nhịp thư đang ở mode = preview (chỉ người duyệt nhận bảng kế hoạch), ramp_pct = 0, daily_quota = 0, và legacy_cold = skip nên 1.107 địa chỉ cũ bị bỏ qua hoàn toàn. Mọi loại thư cần cho mục tiêu đã có sẵn trong danh mục; thứ thiếu là lịch và công tắc.

Lịch tuần đề xuất

Mỗi người đúng một "khe" mỗi ngày gửi, ba khe một tuần, giờ gửi 08:00 giờ VN (hoặc giờ người đó hay mở):

Ngày	Khe	Loại thư (chọn loại đầu tiên có dữ liệu cho người đó)
Thứ Hai	Nhịp tuần	whats_new_weekly → community_weekly (thành viên cộng đồng) → course_new
Thứ Tư	Bài đọc	xoay vòng unit_story → book_chapter → jtbd_case → playbook_pick (không lặp loại hai tuần liền)
Thứ Sáu	Hành động	event_upcoming / session_upcoming nếu có sự kiện 7 ngày tới → weekly_progress (đang học) → pro_offer (Free, đã đồng ý nhận khuyến mãi) → journey_day

Thư giao dịch (login_code, biên nhận, nhắc sự kiện đã đăng ký…) không tính vào ba khe và không bị chặn bởi chúng.

Theo nhóm người nhận

• Thành viên đang hoạt động (≈165): đủ ba khe ngay. Có dữ liệu cá nhân (khoá đang học, cộng đồng).
• Địa chỉ cũ chưa từng nhận thư (1.107): KHÔNG bật thẳng ba thư/tuần. Gửi reconnect trước (một thư, hỏi có muốn nhận tiếp không), rải theo trần tăng dần (cap_start 150 → cap_max 1.300) để giữ uy tín miền. Người bấm "có" hoặc mở thư vào lịch ba khe; người không phản hồi sau hai lần reconnect (cách 14 ngày) chuyển win_back một lần rồi dừng. Lý do: một nghìn địa chỉ lạnh nhận ba thư/tuần ngay là đủ để Gmail đẩy cả miền conan.school vào thư rác, kéo theo cả mã đăng nhập.
• Thư khuyến mãi (pro_offer) chỉ tới người có promo_consent_at (Luật BVDLCN 91/2025).
• Người chọn frequency = weekly nhận một khe (Thứ Hai); important chỉ nhận thư quan hệ; none không nhận gì.

Luật khe trong mã (đã có từ 22.10.2026)

WEEKLY_SLOTS, WEEKLY_FLOOR, WEEKLY_SLOT_GAP_DAYS ở orchestrator/config.ts; slotOf, weeklyOwed, chooseFloor ở orchestrator/score.ts (hàm thuần, kiểm ở tests/email-orchestrator.test.mts).

• Ngày có khe mà người đó còn nợ (số khe tới hôm nay trừ số thư gắn kết đã gửi hoặc đã lên kế hoạch trong tuần ISO, tính từ 00:00 Thứ Hai giờ VN), planner chọn một thư bỏ qua ngưỡng EV và nới khoảng cách tầng về 1 ngày. Ưu tiên loại của khe; không có thì loại bất kỳ qua cổng.
• Thứ Bảy là khe bù: ai còn thiếu (khe trước không ứng viên, hoặc vượt trần) nhận một thư loại bất kỳ.
• Dưới trần ngày, thư lấp khe xếp trước mọi tầng. Trần vẫn giữ: sàn không được phép làm vỡ uy tín miền.
• Không nới: huỷ nhận, nhịp important/none, đồng ý khuyến mãi, người hệ cũ chưa xác nhận (họ chỉ nhận reconnect), tầng dung, trẻ vị thành niên, cooldown, "đã gửi ref này", tầng ngu chỉ nhận loại dormantOk. Nhịp weekly có sàn 1 (khe Thứ Hai, bù Thứ Bảy).
• Lý do trong bảng kế hoạch ghi khe tuần mon (sàn 3/tuần, bỏ qua ngưỡng), người duyệt thấy được thư nào là thư sàn.

Công tắc cần đổi (việc của người vận hành, chưa làm)

1. Tách uy tín: bật Email Sending cho tin.conan.school, rồi sender_domain = tin.conan.school.
2. mode = live, ramp_pct tăng dần, legacy_cold = reconnect.
3. Ở chế độ live, live_classes phải gồm ban_tin và doc, nếu không khe Thứ Hai và Thứ Tư không có ứng viên (bộ lọc nhóm chạy TRƯỚC luật khe).

Xem Email của hệ thống.