# เฉลยพร้อมขอบหลักฐาน

ใช้metadataสังเคราะห์เดิม4กรณีและCSV2ไฟล์รวม5แถว ไม่มีผลรันvalidator/analyzer/firmwareหรือบอร์ดใหม่ ผลคู่ไฟล์ในpair-answers.csvเป็นผลคาดจากไบต์/เวลาตัวอย่างและสัญญาเดิม

## Q1 · คู่ตรงยังมีข้อมูลเก่าได้

normal SHAที่คำนวณตรงf22d796cbeb7d679fe65c11bda9c0601acadc9b295c5acbd922239fc4618a4d0 เห็น3แถว fresh1/stale2; age20000usยังfreshในแถว3 ส่วน20001/40000stale Counterแรก/สุดท้าย0/0จึงdelta0/0 แต่ยังไม่มีหลักฐานcaptureก่อนแถวแรก/หลังแถวสุดท้ายหรือPCรับครบทุกrow แฮชตรงไม่รับรองfreshทุกแถว

## Q2 · ยอดสะสมกับหน้าต่าง

historicalเห็น2แถว fresh2/stale0 overflow7→7/dropped3→3 จึงdelta0/0ระหว่างสองแถว ไม่ใช่lossใหม่7/3ในหน้าต่างนี้ ไม่มีหลักฐานเวลาหรือสาเหตุก่อนแถวแรก และไม่มีfinalboundarysnapshotตอนจบcaptureให้รับรองว่าcounterไม่เพิ่มหลังแถวสุดท้าย

## Q3 · สองทางปฏิเสธ

wrong-hashอ้างnormal.csvแต่declaredSHAเป็นศูนย์64ตัว จึงไม่ตรงไบต์จริง ลำดับhosttimeยังถูก reversed-timeอ้างnormal.csvด้วยSHAที่ตรง แต่started00:00:01Z/ended00:00:00Zกลับลำดับ ต้องปฏิเสธคนละเหตุ เก็บต้นฉบับและตรวจประวัติก่อนแก้ ไม่เปลี่ยนdigestให้ผ่านเพื่อกลบไฟล์สลับ และเวลาประกาศhostกลับลำดับยังไม่ใช่หลักฐานMCUclockเสีย

## Q4 · หน่วยถูกแต่clockต่าง

normalระบุ00:00:00Z→00:00:01Z ได้1วินาที=1000000us เป็นdeclared_host_span_usของตัวอย่างสังเคราะห์ ไม่ใช่เวลาวัดจริง age_usมาจากclockของcallback จึงห้ามเอาhostUTCหรือspanไปลบกับageเพื่ออ้างIRQlatency/end-to-enddeadline ยังไม่มีข้อมูลclocksource/sync/errorbound

## Q5 · ป้ายชื่อเป็นคำประกาศ

origin=synthetic/source_kit=stm32-data-freshness@1.15.8/run_label=lesson-normalอ่านได้จากใบกำกับ แต่ความจริงเกี่ยวกับต้นทางที่ป้ายอ้างเป็นdeclared ต้องแยกการเห็นข้อความในไฟล์จากการยืนยันว่าออกโดยบอร์ด ป้ายoperatorไม่ได้ยืนยันbootID แม้schema/ค่าที่อนุญาตผ่าน ข้อมูลสังเคราะห์นี้ไม่มีbootIDที่ต้นทางออกให้

## Q6 · ผูกไบต์ไม่ยืนยันผู้ส่ง

ตัวอย่างประกาศในsource-recordsแปลงLFเป็นCRLFบนสำเนา105→109bytes decodedlinesเหมือนเดิมแต่SHAต่าง ใบกำกับnormalเดิมจึงไม่ตรงสำเนา ห้ามแก้ต้นฉบับ อ้างทั้งbefore/afterSHAจากsource-records SHAผูกข้อมูลไบต์ ไม่ใช่ลายเซ็น ผู้ที่เปลี่ยนทั้งCSVและJSONสามารถคำนวณคู่ใหม่ที่ตรงกันได้ จึงยังไม่มีหลักฐานยืนยันผู้ส่งหรือcaptureครบ ไม่มีการรันvalidatorกับตัวอย่างนี้

## Q7 · หลักฐานที่ยังขาด

คงcapture_completeness=not_proven และboot_identity=operator_label_only_not_verifiedตามคำตอบเดิม แม้normal/historicalคู่ไฟล์สอดคล้อง ต้องออกแบบbootIDจากต้นทาง capturesequence และstart/endboundarysnapshotsจริงรวมถึงหลักฐานผู้ส่ง/clockตามrequirementก่อนอ้างคุณสมบัติเหล่านั้น ชุดเดิมยังไม่เพิ่มในfirmware การเขียนmetadataเพิ่มเองไม่พิสูจน์ว่าอุปกรณ์ออกให้

## Q8 · รายงานสามชั้น

ตัวอย่างhistorical:ตรวจไบต์CSVกับdeclaredSHAตรง เห็น2แถว tick100→101 overflow7→7/dropped3→3 delta0/0 fresh2; ผู้จัดทำระบุorigin/source_kit/run_label=lesson-historicalและUTCห่าง1วินาที; ยังไม่ทราบcaptureครบ/bootจริง/ผู้ส่ง/การเพิ่มหลังแถวสุดท้าย เสนอเก็บต้นฉบับ/รุ่นและออกแบบsequence/boundary/bootจากจุดกำเนิดพร้อมclocksourceก่อนรับรอง ตัวอย่างนี้เป็นแนวเขียน ไม่ใช่ผลวัดจริง

## เกณฑ์ตรวจตนเองที่เสนอ

ข้อละ2:คำตอบ1+เหตุผล/หน่วย/ข้อจำกัด1 รวม16 Q1แถว/ขอบ Q2delta/หน้าต่าง Q3เหตุปฏิเสธ/ไม่เดา Q4หน่วย/clock Q5declared/identity Q6bytes/hash/ผู้ส่ง Q7ค่าที่ไม่พิสูจน์/หลักฐานเพิ่ม Q8อ้างแถว/สามชั้น เกณฑ์ใหม่ไม่แทน12คะแนนเดิม ไม่ใช่ผลผู้เรียนหรือการรับรองพร้อมบิน