# O · แผนคน ทรัพยากร และการส่งต่อ

**พื้นฐานก่อนทำ:** อ่าน [M06](/knowledge/drone-applications/disaster-assessment/), [M07](/knowledge/drone-applications/search-support/), [M10](/knowledge/drone-applications/communications-support/) และ [M01](/knowledge/drone-applications/survey-mapping/) เฉพาะ QA/coverage/handoff; รู้ว่าคำขอทรัพยากรไม่ใช่การยืนยันความพร้อม และข้อมูลแต่งไม่ใช่คำอนุญาตบิน.

**ผลลัพธ์ KSEC:** `APP-CSF-O-K01` เทียบวิธีและชุดตามคำถามเดียวกัน; `APP-CSF-O-S01` วางงานจากคำขอถึงผู้รับทวน; `APP-CSF-O-E01` คุมสิทธิ์และคำอ้างใน package; `APP-CSF-O-C01` ติดตามการขอทรัพยากร/คำทักและแก้ O-v0 → O-v1. ใช้ [rubric](rubric.md).

**O-v0** ต้องมีตารางนี้ก่อนเลือกวิธี:

| ทรัพยากร/หน้าที่ | requested | confirmed พร้อมหลักฐาน | ถ้ายังไม่ยืนยัน |
|---|---|---|---|
| ผู้รับผิดชอบคำขอและพื้นที่ | ระบุบทบาทสมมติและช่องติดต่อที่จะตรวจ | `unknown` ในชุดฝึก | ขอชื่อผู้มีหน้าที่/ขอบอนุมัติ; ไม่ถือว่าอนุญาต |
| ผู้เก็บข้อมูล/ผู้ควบคุมบิน/ผู้ช่วย/ผู้ตรวจ QA | จำนวนตามแผนที่จะเสนอ | `unknown` | เลือกข้อมูลเดิมหรือวิธีอื่นที่มีผู้รับผิดชอบ |
| ชุด RGB, แบตเตอรี่, storage, ลิงก์และสำรอง | ตามผลส่งมอบที่ผู้รับต้องใช้ | `unknown`; ไม่มีคู่มือรุ่นจริง | ไม่ใส่ endurance, range, payload หรือเวลาเที่ยวบิน |
| ทีมภาคพื้น/ทีมสมทบตรวจ R07 และคู่ขัดแย้ง | requested พร้อมผู้ขอ/เจ้าของคำตอบ/เวลาตอบ | `unknown` จนมีการตอบรับที่ตามรอยได้ | รักษาคิว pending; ไม่ประกาศพบคนหรือเส้นทางผ่านได้ |
| ช่องทางส่ง/ผู้รับ `INCIDENT`, `PUBLIC` | ส่ง manifest ตามสิทธิ์ | `unknown` จนมี receipt/ack จริง | failed/unknown พร้อม owner/retry |

1. ตกลง request, snapshot 10:20+07, deadline 10:40+07, Z-A–Z-D และผลที่รับได้. บันทึกผู้ตัดสินใจเรื่องลำดับตรวจ ไม่ย้ายหน้าที่นั้นให้ผู้คัด CSV.
2. เทียบข้อมูลเดิม, วิธีภาคพื้น, บริการ/ทีมอื่น และโดรนด้วยเวลา/coverage/ความเสี่ยง/สิทธิ์/QA/ต้นทุนรวมเดียวกัน. สำหรับโดรนเทียบ multirotor/fixed-wing/VTOL และ RGB กับทางเลือกเซนเซอร์อื่นตาม *task fit*, การเข้าถึง, พื้นที่ขึ้นลง, คน, มวล/CG, พลังงาน, สภาพอากาศ, คู่มือและสิทธิ์; ทุกค่าสมรรถนะจริง `unknown` จนมีชุด/คู่มือ/ผู้รับผิดชอบ. แผนที่เลือก C ไม่บินและขอข้อมูลต่อได้หากเงื่อนไขไม่พร้อม.
3. วางหกช่วง: รับคำขอ → ตัดสินวิธี/จุดพัก → รับหรือเก็บข้อมูลตามสิทธิ์ → QA ทุกแถวรวมประวัติ/duplicate/conflict → จัดสอง package → ส่งและให้ผู้รับอ่านกลับ. ระบุ owner, เวลา, หลักฐาน, fallback และเกณฑ์พักในทุกช่วง.
4. ทำแผนทวน R01v0/v1, R02 cloud edge, R03 stale, R04 missing, R05/R06 ที่ดูเหมือนขัดกันโดยขอ footprint ก่อน, R07 private possible signal, R08/R09 rights/recipient, R10 next snapshot, R11 duplicate. งานตรวจต่อแต่ละข้อมี owner และเวลาตอบ; Z-D ยังไม่ถูกปิด.
5. ทำ manifest `INCIDENT-v0` และ `PUBLIC-v0`. `INCIDENT` รับรายการที่ขอบสิทธิ์สมมติอนุญาต, `PUBLIC` ได้สรุปที่ลดข้อมูลและผ่านการตรวจข้อความ; ลง redaction log ว่าลด R07 และ raw rows เพราะอะไร. แยก `sent`, `received`, `acknowledged`; เมื่อ offline ให้คิวส่งซ้ำโดยใช้ package ID/revision เดิมและตรวจ receipt ก่อนเพิ่มสถานะ. ห้ามกรอกเวลารับแทนผู้รับ.
6. ให้ผู้ตรวจทัก resource ที่เพียง `requested` และข้อจำกัด public package. เขียนตอบ/ผู้ติดตาม/หลักฐานที่ยังขาด แล้วส่ง **O-v1** พร้อมผลทวน. การเปลี่ยน package ต้องเพิ่ม revision และบอกฉบับที่แทน, เก็บ v0 และแจ้งผู้รับเดิมหากเคยส่ง.

**ตัวอย่างไม่ผ่าน:** ใส่ “โดรนพร้อมและทีมช่วยเหลือยืนยันแล้ว” จากแถว requested; หรือขึ้น `acknowledged` เพราะกดส่ง. ส่ง O-v0/v1, ตารางทางเลือก, resource ledger, six-stage plan, QA ledger, manifest/redaction/receipt log และคำทัก. แผนนี้เป็น tabletop เท่านั้น; กฎหมาย/สิทธิ์พื้นที่/อากาศ/คู่มือ/ทีม/ความปลอดภัยของงานจริงยัง `pending_field_review`.