ใช้ issue สำหรับงานที่ตรวจสอบย้อนกลับได้ และ PR สำหรับการเปลี่ยนแปลงที่มี scope ชัดเจน ทุก PR ต้องระบุ test evidence, ผลกระทบ TH/EN, provider/deployment gate และ secret review
- bug: ใช้
ISSUE_TEMPLATE/bug_report.md - feature: ใช้
ISSUE_TEMPLATE/feature_request.md - provider: ใช้
ISSUE_TEMPLATE/integration_request.md - docs/i18n: ใช้
ISSUE_TEMPLATE/documentation_request.md - PR: ใช้
PULL_REQUEST_TEMPLATE.md
คำขอเชื่อมต่อ provider ต้องแนบ แบบฟอร์มอนุมัติ TH หรือ EN โดยลบ secret ออกทั้งหมด
ห้ามแนบ token, key, PIN, passphrase, .env หรือ database ที่มีข้อมูลจริง
Use issues for traceable work and pull requests for scoped changes. Every PR must include test evidence, TH/EN impact, provider/deployment gates, and a secret review.
- bugs:
ISSUE_TEMPLATE/bug_report.md - features:
ISSUE_TEMPLATE/feature_request.md - provider access:
ISSUE_TEMPLATE/integration_request.md - docs/i18n:
ISSUE_TEMPLATE/documentation_request.md - pull requests:
PULL_REQUEST_TEMPLATE.md
Provider requests must include the Thai approval workbook or English workbook, with all secrets removed.
Never attach tokens, keys, PINs, passphrases, .env files, or real databases.
The workflow at .github/workflows/ci.yml runs on pushes and pull requests. It
installs requirements-dev.txt, compiles app, scripts, and tests, runs the
full pytest suite, and checks git diff --check. A green workflow proves
repository checks only; it does not prove provider approval, public routing, or
live channel delivery.