Phản hồi người dùng thử — kế hoạch xử lý

1 — Quy trình khảo sát & xét chương trình DỰNG MỚI · 5 phần

Survey and program assignment procedure:
– List of proposed cases from school with prelim student information: UPLOAD THIS LIST AND CREATE CASES AUTOMATICALLY ON THE HUB
– At field trip coordinator will find the case on the hub and add photos, onsite information… SUGGEST TO MAKE AN APP ON CELL PHONE FOR THIS TASK?
– After field trip HMT members will discuss and assign student to appropriate program: NEED A FULL INFORMATION REPORT IN EXCEL FORMAT TO REVIEW AND DISCUSSION
– Fields to be added to the current survey form: Dan toc, gioi tinh…
– Nguoi giam ho fields: only 1 nguoi giam ho, others: thanh vien gia dinh

1a · Nạp danh sách đề xuất từ trường → tạo case hàng loạt

Hiện trạng: case chỉ tạo từng cái một qua biểu mẫu khảo sát Google. Mỗi lần submit, survey_intake.create_survey_folder() (tools/survey_intake.py:242–328) chèn 1 dòng candidate (so-khao-sat.sqlite) + tạo thư mục Drive + ghi phieu_json. Chưa có đường nạp hàng loạt.

Đề xuất:

1. Công cụ mới tools/survey_import.py + route hub POST /survey/import: tải lên 1 file Excel/CSV/Sheet (đúng mẫu cột), mỗi dòng → 1 case cho-xet-chon, dùng lại đúng logic create_survey_folder (mint ung-vien-NNNN, tạo thư mục anh/, ghi phieu_json).
2. Bản đồ cột bám theo các trường phiếu hiện có (họ tên, trường, lớp, người nuôi dưỡng, SĐT, hoàn cảnh…). Dòng thiếu trường bắt-buộc-khi-xét (tên / người nuôi dưỡng / SĐT) vẫn tạo được nhưng gắn cờ "thiếu thông tin" để bổ sung ở thực địa.
3. Phát kèm mẫu Excel chuẩn để các trường điền (đặt ở tab Mẫu văn bản — xem mục 6) để cột khớp 1-1 khi nạp.
4. Idempotent: nạp lại cùng file không nhân đôi case (khử trùng theo tên + trường + ngày sinh, dòng nghi trùng đưa vào review).

1b · Ghi thông tin thực địa — có nên làm app điện thoại?

Hiện trạng: thư mục case đã có anh/ cho ảnh, nhưng trang chi tiết case (survey_detail.html) chỉ đọc — không thêm ảnh / thông tin tại chỗ được. Thông tin thực địa hiện đi qua biểu mẫu khảo sát, không gắn vào case sẵn có.

Đề xuất (PWA ghi thực địa): trên /survey/{case_id} thêm khối "Ghi thực địa": chụp/tải ảnh thẳng vào anh/ của case, các ô thông tin tại chỗ (xác minh hoàn cảnh, quan sát nhà ở, ghi chú ĐPV) ghi bổ sung vào phieu_json + nhật ký case. Nút lớn, 1 cột, hợp ngón tay. Gắn liền với mục 2 (nhiều thành viên cùng góp ý).

1c · Báo cáo Excel đầy đủ để họp xét chương trình

Hiện trạng: chỉ có trang chi tiết HTML từng case; chưa có bản Excel gộp toàn bộ case chờ xét để mang ra họp.

Đề xuất: nút "Tải Excel để họp xét" trên /survey → xuất .xlsx (openpyxl), mỗi case 1 dòng, đầy đủ cột phiếu (đọc từ phieu_json qua hub_reads.survey_candidate_detail) + link thư mục Drive + link ảnh + đề xuất mức hỗ trợ + cờ thiếu thông tin. Có thể lọc theo trường / đợt. Đây là tài liệu hội đồng đánh dấu rồi quay lại hub bấm "Xét duyệt" để gán chương trình.

1d · Thêm trường vào phiếu khảo sát: Dân tộc, giới tính…

Hiện trạng: giới tính đã có trong phiếu (dropdown Nữ/Nam/Khác → phieu.gioi_tinh). Dân tộc thì chưa.

Đề xuất: thêm Dân tộc (dropdown 54 dân tộc, hoặc free-text gợi ý) vào mục "Thông tin học sinh" của _system/forms/survey-form-v1.yaml. Bắt buộc đồng bộ 3 nơi nếu không trường mới sẽ rơi mất khi submit:

• câu hỏi mới trong Google Form (sửa thủ công trên Form),
• TITLE_TO_FIELD_ID trong cloud/apps-script/onSurveySubmit.gs:49–70 (tiêu đề câu hỏi → field id),
• cột candidate.dan_toc (ALTER an toàn) + nhãn ở _PHIEU_LABELS (hub_reads.py) + ô seed hồ sơ khi admit.

Nếu có trường khác muốn thêm (ví dụ số anh chị em, thuộc diện hộ nghèo/cận nghèo) — liệt kê luôn để gộp 1 lần sửa Form.

1e · Người giám hộ: chỉ 1 người, còn lại là thành viên gia đình

Hiện trạng: phiếu có một khối người nuôi dưỡng: carer_name / carer_relationship (mẹ/bố/ông-bà/giám hộ khác/khác) / carer_phone. Không có chỗ ghi các thành viên gia đình khác.

Đề xuất: giữ khối hiện tại làm người giám hộ duy nhất (đổi nhãn mục thành "Người giám hộ"), và thêm trường "Thành viên gia đình khác" (paragraph, mỗi dòng 1 người: họ tên · quan hệ · ghi chú). Lưu vào phieu.thanh_vien_gia_dinh + cột mới. Hiển thị thành danh sách ở trang chi tiết case và trong sổ tay sau khi admit.

Cần bạn quyết định: (i) thứ tự ưu tiên 1a–1e; (ii) Dân tộc dùng dropdown 54 hay free-text; (iii) còn trường nào thêm vào phiếu nữa không (gộp 1 lần sửa Form); (iv) đồng ý hướng "trang web mobile-first / PWA" thay cho native app.

2 — Phiếu thực địa: nhiều thành viên cùng góp ý DỰNG MỚI

Field trip form: to be filed by 1 person but other members can add their own view, notes, comments to.

Hiện trạng: phiếu thực địa (_system/forms/coordinator-brief-form-v1.yaml) một người điền, kết quả là một brief.yaml duy nhất trong thư mục sự kiện. Có sẵn quote_1..7 và event_extra_content nhưng đó là nội dung của người điền, không phải luồng góp ý nhiều người.

Đề xuất: thêm luồng bình luận theo sự kiện/ca:

1. 1 người điền phiếu chính (như hiện nay) → tạo sự kiện/case.
2. Trên trang chi tiết sự kiện (hub), bất kỳ thành viên đăng nhập nào cũng "Thêm góp ý": tên · thời điểm · nội dung, ghi nối tiếp (append-only, không sửa của người khác). Lưu vào bảng comment mới khóa theo event_slug (hoặc case_id với khảo sát), hoặc một sidecar gop-y.yaml bên cạnh brief.yaml.
3. Góp ý hiện cùng phiếu để khi viết caption / khi họp xét đọc đủ nhiều góc nhìn.

Việc này dùng chung hạ tầng với 1b (ghi thực địa trên điện thoại) — nên làm cùng một lượt: trang chi tiết case/sự kiện vừa thêm ảnh + thông tin, vừa nhận góp ý nhiều người.

Cần chốt: phạm vi áp dụng — chỉ phiếu thực địa sự kiện (Stream A), hay cả case khảo sát (mục 1b), hay cả hai? Khuyến nghị làm cho cả hai vì cùng một mẫu.

3 — Cách nạp tài liệu: bài viết, SEL, học bạ / KQHT DỰNG MỚI

How to upload information: essays, SEL, school reports….

Hiện trạng: đã có ô nạp tài liệu theo từng học sinh trên hub — /children/{code}/school-doc (app/templates/school_doc.html) — nhưng chỉ 4 loại: học bạ, sổ điểm, chuyên cần, họp phụ huynh. Bài viết (viết văn) và SEL (đánh giá cảm xúc-xã hội) chưa có loại riêng trên hub; chúng hiện đi qua biểu mẫu "Upload tài liệu" chung (HMT_UPLOAD_FORM_ID) hoặc thư mục thả, rồi phân loại tay.

Đề xuất:

1. Mở rộng ô nạp theo-học-sinh thêm loại: bài viết / viết văn (→ essay_score + lưu bản gốc), phiếu SEL / đánh giá cảm xúc-xã hội (→ school_report/se hoặc ghi chú có cánh), và báo cáo trường khác (prose chung → profile_entry kèm nguồn gốc).
2. Đặt ô nạp trên hub làm đường chính thức, và viết một trang "Cách nạp tài liệu" (ở tab Mẫu văn bản / Trợ giúp) liệt kê rõ 4 kênh: hub (chính), Form Google chung, email, thư mục thả — mỗi kênh dùng khi nào.
3. Mọi tài liệu nạp đều giữ bản gốc trong Tai-lieu-goc/ của HS + một dòng source_doc để mọi dữ kiện truy ngược được (đúng quy tắc care-data v2).

Cần chốt: bài viết và SEL có cần trích xuất tự động (OCR/AI rút trường) như học bạ không, hay chỉ lưu bản gốc + nhập tay vài trường chính?

4 — Chuyển giao đoạn (sổ tay HS): ai điền + đổi 5 nhãn SỬA NHANH

Chuyen giao doan (so tay HS) comments: HS chuyen cap 2 sang cap 3: coordinator to file?
– Hanh dong = Su kien · Ngay tot nghiep = Thoi diem · Ly do roi = Ly do · Noi hoc tiep = Noi chuyen tiep · Lop moi = T/tin khac

Ai điền? Đúng — điều phối viên điền trên hub. Khi HS chuyển cấp 2 → cấp 3, mở trang HS /children/{code}, dùng khối "Chuyển giai đoạn / tốt nghiệp" (app/templates/child.html:182–208, gửi tới POST /children/{code}/transition). Một bước chuyển cấp = hành động "tốt nghiệp & học tiếp" + nhập trường mới. Đề xuất nhỏ: thêm hẳn một lựa chọn hành động "Chuyển cấp" cho rõ nghĩa (thay vì mượn "graduate-continue").

Đổi nhãn (chỉ đổi chữ hiển thị; giữ nguyên tên cột DB — không đụng dữ liệu). Việc đổi này cũng làm phiếu tổng quát hơn, hợp cả chuyển cấp chứ không chỉ tốt nghiệp:

Mức độ: nhỏ, gần như chỉ sửa chuỗi + 1 lựa chọn dropdown mới. Rủi ro thấp. Lưu ý: "Nơi học tiếp (ĐH/CĐ)" đổi thành "Nơi chuyển tiếp" thì bỏ gợi ý "(ĐH/CĐ)" để dùng được cho cả lên cấp 3.

5 — Phân tích: BC tài trợ đã nhận + đã chi DỰNG MỚI

Phan tich: – BC tai tro da nhan – BC tai tro da chi

Hiện trạng: trang Phân tích có bảng "Phúc lợi theo nguồn tài trợ" (app/main.py:1576–1608) gộp cam kết (dòng register_entry kind=funding) với phúc lợi per-student. Chưa tách rạch ròi tiền vào (đã nhận) với tiền ra (đã chi cho HS).

Đề xuất: trên tab Phân tích thêm hai bảng tổng toàn Quỹ (cộng mọi trường), mỗi bảng tách theo trường × năm học × nguồn:

1. BC tài trợ đã nhận — tổng cam kết theo nguồn + năm học (từ register_entry).
2. BC tài trợ đã chi — tổng đã trao cho HS theo trường + năm (từ benefit).
3. Thêm cột chênh lệch (nhận − chi) = phần cam kết chưa giải ngân. Tránh cộng trùng: mỗi nguồn tính một lần ở mỗi vế.

6 — Đổi nhãn "Trợ giúp" → "Mẫu văn bản" SỬA NHANH

Tro giup = Mau van ban

Hiện trạng: tab tên "Trợ giúp" (/tro-giup); bên trong đã có mục "Mẫu văn bản thường dùng" + "Biểu mẫu Google" + hướng dẫn. Nhãn tab nằm ở sidebar app/templates/hub/base.html và app/templates/base.html.

Đề xuất: đổi nhãn tab thành "Mẫu văn bản". Sửa chuỗi nhãn (giữ route /tro-giup để không vỡ link). Mức rất nhỏ.

Một điểm cần chốt: tab này hiện còn chứa biểu mẫu Google (phiếu hoạt động + khảo sát) và hướng dẫn gây quỹ — không chỉ mẫu văn bản. Bạn muốn (a) đổi cả tab thành "Mẫu văn bản" và để các thứ kia bên trong, hay (b) tách: tab "Mẫu văn bản" chỉ chứa mẫu, còn biểu mẫu/hướng dẫn sang chỗ khác? Khuyến nghị (a) cho nhanh, gọn.

7 — Báo cáo trường (BC trường) CẦN CHỐT

BC truong: add theo nam hoc va tat ca cac nam, add SL HS ban dau.
– Remove 6.1 item. – Item 7: what is it? – Item 8 = anh chi em tham gia lop HMT.

Hiện trạng — các mục BC trường (đánh số tự động từ thứ tự tiêu đề, tools/report_school.py:171–262):

Đã đọc báo cáo thật (THCS Tam Thanh, qua tài khoản dịch vụ của Quỹ): tiêu đề trong Doc không đánh số; cấu trúc cấp-1 đúng như bảng trên. Tiểu mục duy nhất giữa bài là §4 Top-5 / Bottom-5 điểm KQHT và §9 theo chương trình — không có "6.1" theo nghĩa đánh số. Xử lý từng ý:

• LÀM "Theo năm học & tất cả các năm": hiện số HS + khen thưởng/hỗ trợ tính trọn đời (chỉ §2 tài trợ đã tách theo năm). Thêm bộ chọn năm học + tách số HS và khen thưởng theo từng năm học cạnh cột "tất cả các năm". Khung nam-hoc=YYYY-YYYY đã có trong resolve_window (report_common.py:811–838).
• LÀM "SL HS ban đầu": thêm dòng "Số HS ban đầu" (quân số roster đầu mỗi lứa) cạnh "tổng đã tham gia" + "đang tham gia" ở mục 1.
• ĐÃ RÕ · BỎ "Mục 7 là gì": = "Nguồn ghi chú (trong kỳ)", một con số nội bộ (ghi chú từ trường hay ĐPV) — vô nghĩa với nhà trường. Bỏ khỏi báo cáo trường (giữ nội bộ nếu cần).
• LÀM "Mục 8 = anh chị em tham gia lớp HMT": thay nội dung mục 8 ("Phủ rộng 8 cánh" — cũng là thống kê nội bộ) bằng danh sách các em là anh/chị/em ruột cùng tham gia tại trường. Dữ liệu đã có: child.sibling_ids. Hiện thành từng cụm anh-chị-em (các em + lớp + lứa).
• XÁC NHẬN 1 Ý "Remove 6.1": Doc không có mục đánh số 6.1. Ứng viên gần nhất là §4.2 "Bottom 5 điểm KQHT thấp nhất" — bảng nêu đích danh 5 em điểm thấp nhất. Mình đề xuất bỏ bảng Bottom-5 này (phẩm giá: không xếp hạng/nêu tên em yếu nhất trong báo cáo gửi trường), giữ Top-5 + điểm trung bình. Xác nhận giúp: "6.1" = Bottom-5 (bỏ) đúng chứ? Nếu là mục khác, chỉ cần nói tên mục.

8 — Hiện vật: ghi chi tiết là gì ĐÃ CHỐT (ô tự do) · LÀM

Cac tai tro/ khen thuong hien vat: ghi chi tiet la gi.

Quyết định (bạn, 30/06): dùng ô mô tả tự do (không tách cấu trúc loại/số lượng/đơn vị).

Hiện trạng: đã có sẵn ô tự do — benefit.amount_inkind là TEXT ("1 xe đạp", "10 quyển vở"), hiện ở sổ tay (so_tay.py:699) và báo cáo HS (report_child.py:371–384). Vấn đề: (a) khi ghi phúc lợi hiện vật, mô tả không được nhắc/bắt nhập; (b) ở BC trường, hiện vật chỉ bị đếm số (report_school.py:133 — ví dụ thật "63 hiện vật"), không hiện là gì.

Sẽ làm:

1. Form ghi phúc lợi (POST /benefits, app/main.py:771): khi loại = hiện vật, nhắc/bắt nhập mô tả ("ghi rõ hiện vật là gì") vào amount_inkind.
2. Hiện mô tả ở mọi nơi — đặc biệt BC trường mục 3: thay "63 hiện vật" bằng danh sách/liệt kê "63 hiện vật: xe đạp, vở, áo ấm…".

9 — Tạo lại báo cáo thì thay bản cũ ĐÃ CHỐT (thay + lưu trữ) · LÀM

When a same report is created, have the old version one replaced.

Quyết định (bạn, 30/06): thay bản cũ VÀ giữ một bản lưu trữ.

Hiện trạng: tạo lại cùng báo cáo không ghi đè — so_tay.create_versioned_doc() (tools/so_tay.py:278–305) đẻ bản song song · bản 2, · bản 3… Kết quả: thư mục báo cáo đầy bản, đúng như bạn thấy.

Sẽ làm (thay tại chỗ + lưu trữ):

1. Một Doc hiện hành duy nhất mỗi (loại báo cáo × trường/lứa): cập nhật nội dung ngay trong Doc cũ qua Docs API → link giữ nguyên, luôn là bản mới nhất, không còn "bản 2/3". Tận dụng logic dọn/khử trùng đã có trong report_index + _publish_report_doc (app/main.py:321–337).
2. Lưu trữ bản cũ: trước khi ghi đè, copy bản hiện hành vào thư mục con Bao-cao/_luu-tru/<YYYY-MM-DD>/ để giữ vết lịch sử (không mất bản trước, nhưng không bày ra ngoài).

Lưu ý: phần "thay tại chỗ" cần Docs API + quyền ghi Drive sống → không chạy được trên Claude Code Web (chỉ-đọc). Web sẽ viết code + test với bản giả (fake Drive client); deploy + chạy thật làm sau từ máy Windows.

10 — Giới hạn số ký tự mỗi trường? TRẢ LỜI

In the survey/ field trip form is there any limit of typing character's number per field?

Trả lời: hệ thống của mình không đặt giới hạn riêng — không có ràng buộc độ dài trong file biểu mẫu (survey-form-v1.yaml, coordinator-brief-form-v1.yaml) cũng như trong code Cloud Run; câu trả lời được lưu nguyên văn, không cắt.

Giới hạn duy nhất là mặc định của Google Forms: ô ngắn (text) ~1.000 ký tự, ô đoạn văn (paragraph) ~40.000 ký tự. Hầu hết trường hoàn cảnh/ghi chú là đoạn văn nên dư sức.

Nếu bạn muốn: mình có thể (a) thêm nhắc độ dài gợi ý cho vài ô (ví dụ tóm tắt sự kiện nên ≤ X chữ để caption gọn), hoặc (b) xác nhận đang có ô nào bị người dùng than là chạm giới hạn — cho mình biết ô cụ thể.