diff --git a/client/src/components/reservation/ReservationAuditTimeline.vue b/client/src/components/reservation/ReservationAuditTimeline.vue
index fe82af0..2a29668 100644
--- a/client/src/components/reservation/ReservationAuditTimeline.vue
+++ b/client/src/components/reservation/ReservationAuditTimeline.vue
@@ -17,9 +17,9 @@
       >
         <span class="audit-dot" />
         <div>
-          <strong>{{ item.action }}</strong>
+          <strong>{{ formatReservationAuditAction(t, item.action) }}</strong>
           <small>
-            {{ item.actor_type }} / {{ item.actor_id }} · {{ formatReservationDateTime(item.occurred_at) }}
+            {{ formatReservationActorType(t, item.actor_type) }} / {{ item.actor_id }} · {{ formatReservationDateTime(item.occurred_at) }}
           </small>
           <p v-if="item.reason">
             {{ item.reason }}
@@ -34,6 +34,7 @@
 import { useI18n } from 'vue-i18n'
 
 import type { ReservationTaskAuditLogResult } from '@/types/reservation'
+import { formatReservationActorType, formatReservationAuditAction } from '@/utils/reservationDisplay'
 import { formatReservationDateTime } from '@/utils/reservationFormat'
 
 defineProps<{
diff --git a/client/src/components/reservation/ReservationEvidencePanel.vue b/client/src/components/reservation/ReservationEvidencePanel.vue
index 794b546..d1f24e4 100644
--- a/client/src/components/reservation/ReservationEvidencePanel.vue
+++ b/client/src/components/reservation/ReservationEvidencePanel.vue
@@ -7,21 +7,21 @@
 
     <dl>
       <div>
-        <dt>ID</dt>
+        <dt>{{ t('task.sourceMessageId') }}</dt>
         <dd class="th-code">
           {{ sourceMessage.source_message_id }}
         </dd>
       </div>
       <div>
-        <dt>Sender</dt>
+        <dt>{{ t('task.sourceSender') }}</dt>
         <dd>{{ sourceMessage.sender_identifier }}</dd>
       </div>
       <div>
-        <dt>Subject</dt>
+        <dt>{{ t('task.sourceSubject') }}</dt>
         <dd>{{ sourceMessage.thread_subject }}</dd>
       </div>
       <div>
-        <dt>Received</dt>
+        <dt>{{ t('task.sourceReceivedAt') }}</dt>
         <dd>{{ formatReservationDateTime(sourceMessage.payload_received_at) }}</dd>
       </div>
     </dl>
diff --git a/client/src/components/reservation/ReservationOperaPanel.vue b/client/src/components/reservation/ReservationOperaPanel.vue
index 0692008..f411b4e 100644
--- a/client/src/components/reservation/ReservationOperaPanel.vue
+++ b/client/src/components/reservation/ReservationOperaPanel.vue
@@ -39,7 +39,7 @@
         <div class="operation-item__main">
           <span class="operation-item__sequence">{{ operation.operation_sequence }}</span>
           <div>
-            <strong>{{ operation.operation_name }}</strong>
+            <strong>{{ formatReservationOperaOperation(t, operation.operation_code, operation.operation_name) }}</strong>
             <small class="th-code">{{ operation.operation_code }}</small>
           </div>
         </div>
@@ -91,6 +91,7 @@ import { useI18n } from 'vue-i18n'
 import ReservationStatusBadge from '@/components/reservation/ReservationStatusBadge.vue'
 import { executeReservationOperaOperation, retryReservationOperaOperation } from '@/services/reservationService'
 import type { ReservationOperaOperationResult } from '@/types/reservation'
+import { formatReservationOperaOperation } from '@/utils/reservationDisplay'
 
 const props = defineProps<{
   taskId: string
diff --git a/client/src/components/reservation/ReservationStatusBadge.vue b/client/src/components/reservation/ReservationStatusBadge.vue
index a315684..c707be3 100644
--- a/client/src/components/reservation/ReservationStatusBadge.vue
+++ b/client/src/components/reservation/ReservationStatusBadge.vue
@@ -33,7 +33,7 @@ const tone = computed(() => {
   return 'warning'
 })
 
-const label = computed(() => t(`status.${props.status}`, props.status))
+const label = computed(() => t(`status.${props.status}`, t('common.unknownStatus')))
 </script>
 
 <style scoped>
diff --git a/client/src/components/reservation/ReservationTaskDetailPanel.vue b/client/src/components/reservation/ReservationTaskDetailPanel.vue
index ac844ed..5860fd1 100644
--- a/client/src/components/reservation/ReservationTaskDetailPanel.vue
+++ b/client/src/components/reservation/ReservationTaskDetailPanel.vue
@@ -4,7 +4,7 @@
       v-if="loading"
       class="task-state"
     >
-      Loading...
+      {{ t('common.loading') }}
     </div>
     <div
       v-else-if="errorMessage"
@@ -17,7 +17,7 @@
       <header class="task-detail-header">
         <div>
           <p class="task-eyebrow">
-            {{ t(`cardType.${detail.task_card_type}`, detail.task_card_type) }}
+            {{ formatReservationTaskCard(t, detail.task_card_type) }}
           </p>
           <h1>{{ t('task.title') }} {{ detail.task_id }}</h1>
           <span class="task-contract">
@@ -82,7 +82,7 @@
           class="pi pi-lock"
           aria-hidden="true"
         />
-        {{ detail.availability.blocked_reason ?? t('task.blocked') }}
+        {{ formatReservationMaybeStableReason(t, detail.availability.blocked_reason, 'task.blocked') }}
       </div>
 
       <div
@@ -180,6 +180,7 @@ import {
   validateReservationFieldValues,
   type ReservationFieldValidationErrors,
 } from '@/utils/reservationFieldRules'
+import { formatReservationMaybeStableReason, formatReservationTaskCard } from '@/utils/reservationDisplay'
 import { formatReservationDateTime } from '@/utils/reservationFormat'
 
 const props = defineProps<{
diff --git a/client/src/components/reservation/ReservationTaskQueue.vue b/client/src/components/reservation/ReservationTaskQueue.vue
index 12ac604..994fa6c 100644
--- a/client/src/components/reservation/ReservationTaskQueue.vue
+++ b/client/src/components/reservation/ReservationTaskQueue.vue
@@ -13,12 +13,12 @@
       >
         <span class="task-row__index">{{ task.queue_sequence ?? '-' }}</span>
         <span class="task-row__main">
-          <strong>{{ task.card_name ?? task.task_type }}</strong>
-          <small>{{ task.task_type }} / {{ task.task_subtype ?? '-' }}</small>
+          <strong>{{ formatReservationTaskCard(t, task.task_type, task.card_name) }}</strong>
+          <small>{{ formatReservationTaskTypeSummary(t, task.task_type, task.task_subtype) }}</small>
           <em :class="{ 'task-row__reason--blocked': !task.can_process }">
             {{ task.can_process ? t('taskList.canProcess') : t('taskList.cannotProcess') }}
             <template v-if="!task.can_process && task.readonly_reason_code">
-              · {{ task.readonly_reason_code }}
+              · {{ formatReservationReadonlyReason(t, task.readonly_reason_code) }}
             </template>
           </em>
         </span>
@@ -49,6 +49,11 @@ import { useI18n } from 'vue-i18n'
 
 import ReservationStatusBadge from '@/components/reservation/ReservationStatusBadge.vue'
 import type { ReservationOrderTaskTimelineItem } from '@/types/reservation'
+import {
+  formatReservationReadonlyReason,
+  formatReservationTaskCard,
+  formatReservationTaskTypeSummary,
+} from '@/utils/reservationDisplay'
 
 defineProps<{
   items: ReservationOrderTaskTimelineItem[]
diff --git a/client/src/i18n/index.ts b/client/src/i18n/index.ts
index 8528dc2..2474439 100644
--- a/client/src/i18n/index.ts
+++ b/client/src/i18n/index.ts
@@ -1,6 +1,7 @@
 import { createI18n } from 'vue-i18n'
 
 import enUS from './locales/en-US'
+import thTH from './locales/th-TH'
 import zhCN from './locales/zh-CN'
 
 export const i18n = createI18n({
@@ -10,5 +11,6 @@ export const i18n = createI18n({
   messages: {
     'zh-CN': zhCN,
     'en-US': enUS,
+    'th-TH': thTH,
   },
 })
diff --git a/client/src/i18n/locales/en-US.ts b/client/src/i18n/locales/en-US.ts
index 4b7c90d..2429e7b 100644
--- a/client/src/i18n/locales/en-US.ts
+++ b/client/src/i18n/locales/en-US.ts
@@ -2,6 +2,8 @@ export default {
   app: {
     name: 'Hotel OMS',
     theme: 'Theme',
+    language: 'Language',
+    navigationAria: 'Reservation navigation',
     healthUp: 'Backend connected',
     healthDown: 'Backend offline',
     healthChecking: 'Checking',
@@ -20,6 +22,14 @@ export default {
     noData: 'No data',
     endpointPending: 'Endpoint pending',
     endpointMissing: 'Endpoint field pending',
+    all: 'All',
+    unknownStatus: 'Unknown status',
+    unknownTaskType: 'Unknown task type',
+    unknownTaskSubtype: 'Unknown task subtype',
+    unknownReadonlyReason: 'Not processable yet',
+    unknownActorType: 'Unknown actor',
+    unknownAuditAction: 'Unknown action',
+    unknownOperation: 'Unknown operation',
     previousPage: 'Previous',
     nextPage: 'Next',
     pageStatus: 'Page {current} / {total}',
@@ -52,12 +62,13 @@ export default {
     title: 'Order list',
     subtitle: 'Review Reservation work by order',
     keyword: 'Group Code / Confirmation No.',
+    keywordPlaceholder: 'Group code / confirmation no.',
     tableTitle: 'Order data',
     totalSuffix: 'orders',
     viewDetail: 'View detail',
     continueTask: 'Continue task',
     noOpenTask: 'No open task',
-    endpointPending: 'The order list endpoint GET /api/reservation/orders is pending backend implementation. No fixture data is shown.',
+    endpointPending: 'The order list endpoint is pending backend implementation. No fixture data is shown.',
     columns: {
       order: 'Order',
       status: 'Status',
@@ -88,6 +99,7 @@ export default {
     title: 'Task list',
     subtitle: 'Review Reservation work by task queue',
     keyword: 'Order / email keyword',
+    keywordPlaceholder: 'Order no. / email keyword',
     taskType: 'Task type',
     tableTitle: 'Task data',
     totalSuffix: 'tasks',
@@ -98,7 +110,6 @@ export default {
     queueAll: 'All queue states',
     queueIncluded: 'In queue',
     queueExcluded: 'Not in queue',
-    orderStatusFilterPending: 'Order status filter is pending backend support',
     viewTask: 'View task',
     viewOrder: 'View order',
     viewConversation: 'View email conversation',
@@ -189,4 +200,50 @@ export default {
     MESSAGE_NOTIFICATION: 'Message notification',
     MANUAL_REVIEW: 'Manual review',
   },
+  taskSubtype: {
+    NEW_BOOKING: 'New booking',
+    UPDATE_BOOKING: 'Update booking',
+    CANCEL_BOOKING: 'Cancel booking',
+    RATE_CHANGE: 'Rate change',
+    UPDATE_STAY_DATES: 'Update stay dates',
+    UPDATE_ROOM_TYPE: 'Update room type',
+    UPDATE_FIX_CHARGE: 'Update fixed charge',
+    NEW_GROUP_BLOCK: 'New group block',
+    NEW_FIT_RESERVATION: 'New FIT reservation',
+    MANUAL_REVIEW: 'Manual review',
+  },
+  readonlyReason: {
+    PROCESSABLE: 'Processable',
+    PREVIOUS_TASK_NOT_FINISHED: 'Previous task is not finished',
+    TASK_FINISHED: 'Task finished',
+    TASK_READ_ONLY: 'Task is read only',
+    ORDER_CLOSED: 'Order closed',
+    QUEUE_EXCLUDED: 'Not in queue',
+    BLOCKED: 'Blocked',
+  },
+  actorType: {
+    USER: 'User',
+    SYSTEM: 'System',
+    AI: 'AI',
+    AGENT: 'Agent',
+    BACKEND: 'Backend service',
+  },
+  auditAction: {
+    TASK_CREATED: 'Task created',
+    TASK_LOADED: 'Task loaded',
+    TASK_CONFIRMED: 'Task confirmed',
+    TASK_CONFIRM: 'Task confirmed',
+    DRAFT_SAVED: 'Draft saved',
+    TASK_UPDATED: 'Task updated',
+    OPERA_EXECUTED: 'OPERA executed',
+    OPERA_RETRIED: 'OPERA retried',
+    MANUAL_REVIEW_CREATED: 'Manual review created',
+  },
+  operaOperation: {
+    CREATE_RESERVATION: 'Create reservation',
+    UPDATE_RESERVATION: 'Update reservation',
+    CANCEL_RESERVATION: 'Cancel reservation',
+    UPDATE_ROOMING_LIST: 'Update rooming list',
+    ADD_TRACE_NOTE: 'Add trace note',
+  },
 }
diff --git a/client/src/i18n/locales/th-TH.ts b/client/src/i18n/locales/th-TH.ts
new file mode 100644
index 0000000..d452504
--- /dev/null
+++ b/client/src/i18n/locales/th-TH.ts
@@ -0,0 +1,249 @@
+export default {
+  app: {
+    name: 'Hotel OMS',
+    theme: 'ธีม',
+    language: 'ภาษา',
+    navigationAria: 'เมนูการจอง',
+    healthUp: 'เชื่อมต่อหลังบ้านแล้ว',
+    healthDown: 'หลังบ้านออฟไลน์',
+    healthChecking: 'กำลังตรวจสอบ',
+  },
+  nav: {
+    orders: 'รายการออเดอร์',
+    taskQueue: 'คิวงาน',
+    sourceMessages: 'แหล่งที่มาข้อความ',
+    systemStatus: 'สถานะระบบ',
+    orderDetail: 'รายละเอียดออเดอร์',
+    taskDetail: 'รายละเอียดงาน',
+    sourceMessageConversation: 'เธรดอีเมล',
+  },
+  common: {
+    loading: 'กำลังโหลด',
+    noData: 'ไม่มีข้อมูล',
+    endpointPending: 'รอเชื่อมต่อ API',
+    endpointMissing: 'ยังขาดข้อมูลจาก API',
+    all: 'ทั้งหมด',
+    unknownStatus: 'สถานะไม่ทราบ',
+    unknownTaskType: 'ประเภทงานไม่ทราบ',
+    unknownTaskSubtype: 'ประเภทย่อยไม่ทราบ',
+    unknownReadonlyReason: 'ยังประมวลผลไม่ได้',
+    unknownActorType: 'ผู้ดำเนินการไม่ทราบ',
+    unknownAuditAction: 'การดำเนินการไม่ทราบ',
+    unknownOperation: 'การดำเนินการไม่ทราบ',
+    previousPage: 'หน้าก่อนหน้า',
+    nextPage: 'หน้าถัดไป',
+    pageStatus: 'หน้า {current} / {total}',
+    pageSize: 'ต่อหน้า',
+  },
+  workbench: {
+    title: 'โต๊ะงานออเดอร์',
+    subtitle: 'ดู กรอง และจัดการงานออเดอร์การจอง',
+    filters: 'ตัวกรอง',
+    dateRange: 'ช่วงวันที่',
+    businessKey: 'เลขธุรกิจ / เลขชั่วคราว',
+    orderStatus: 'สถานะออเดอร์',
+    taskStatus: 'สถานะงาน',
+    taskCardType: 'ประเภทการ์ดงาน',
+    reset: 'รีเซ็ต',
+    tableTitle: 'ออเดอร์ / งาน',
+    columns: {
+      businessKey: 'เลขธุรกิจ',
+      orderStatus: 'สถานะออเดอร์',
+      currentTask: 'งานปัจจุบัน',
+      taskStatus: 'สถานะงาน',
+      updatedAt: 'อัปเดตล่าสุด',
+      operation: 'การดำเนินการ',
+    },
+    view: 'ดู',
+    totalPrefix: 'รวม',
+    totalSuffix: 'รายการงาน',
+  },
+  orderList: {
+    title: 'รายการออเดอร์',
+    subtitle: 'ดูงานการจองตามออเดอร์',
+    keyword: 'เลขกรุ๊ป / เลขยืนยัน',
+    keywordPlaceholder: 'เลขกรุ๊ป / เลขยืนยัน',
+    tableTitle: 'ข้อมูลออเดอร์',
+    totalSuffix: 'ออเดอร์',
+    viewDetail: 'ดูรายละเอียด',
+    continueTask: 'ทำงานต่อ',
+    noOpenTask: 'ไม่มีงานค้าง',
+    endpointPending: 'API รายการออเดอร์ยังไม่เชื่อมต่อ จึงไม่แสดงข้อมูลจำลอง',
+    columns: {
+      order: 'ออเดอร์',
+      status: 'สถานะ',
+      openTasks: 'งานที่ยังไม่ปิด',
+      createdAt: 'เวลาสร้าง',
+    },
+  },
+  order: {
+    summary: 'สรุปออเดอร์',
+    taskQueue: 'คิวงานของออเดอร์นี้',
+    sourceMessage: 'ข้อความต้นทาง',
+    businessKeySource: 'แหล่งที่มาของเลขธุรกิจ',
+    updatedAt: 'อัปเดตล่าสุด',
+    guestName: 'แขก',
+    arrivalDate: 'วันเข้าพัก',
+    roomType: 'ประเภทห้อง',
+    amount: 'ยอดเงิน',
+    openTask: 'จัดการงาน',
+    groupCode: 'เลขกรุ๊ป (Group Code)',
+    confirmationNumber: 'เลขยืนยัน (Confirmation No.)',
+    temporaryOrderNo: 'เลขออเดอร์ชั่วคราว',
+    blockCode: 'เลขบล็อกกรุ๊ป (Block Code)',
+    createdAt: 'เวลาสร้าง',
+    conversationMessageCount: 'จำนวนอีเมลในเธรด',
+    sourceSummaryPending: 'ข้อมูลสรุปอีเมลต้นทางในไทม์ไลน์งานยังรอหลังบ้านเพิ่มเติม โปรดเข้าไปดูจากงานที่เกี่ยวข้อง',
+  },
+  taskList: {
+    title: 'รายการงาน',
+    subtitle: 'ดูคิวงานการจองตามงาน',
+    keyword: 'คำค้นออเดอร์ / อีเมล',
+    keywordPlaceholder: 'เลขออเดอร์ / คำค้นอีเมล',
+    taskType: 'ประเภทงาน',
+    tableTitle: 'ข้อมูลงาน',
+    totalSuffix: 'งาน',
+    noSourceSubject: 'ไม่มีหัวข้ออีเมลต้นทาง',
+    canProcess: 'ประมวลผลได้',
+    cannotProcess: 'ประมวลผลไม่ได้',
+    queueParticipation: 'อยู่ในคิวหรือไม่',
+    queueAll: 'สถานะคิวทั้งหมด',
+    queueIncluded: 'อยู่ในคิว',
+    queueExcluded: 'ไม่อยู่ในคิว',
+    viewTask: 'ดูงาน',
+    viewOrder: 'ดูออเดอร์',
+    viewConversation: 'ดูเธรดอีเมล',
+    columns: {
+      task: 'งาน',
+      order: 'ออเดอร์',
+      card: 'การ์ดงาน',
+      status: 'สถานะ',
+      source: 'อีเมลต้นทาง',
+      queue: 'คิว',
+    },
+  },
+  task: {
+    title: 'การ์ดงาน',
+    fieldContract: 'สัญญาข้อมูล',
+    evidence: 'หลักฐาน',
+    saveDraft: 'บันทึกร่าง',
+    confirm: 'ยืนยันงาน',
+    blocked: 'ถูกบล็อก',
+    readOnly: 'อ่านอย่างเดียว',
+    operaOperations: 'การจำลอง OPERA',
+    audits: 'ไทม์ไลน์ตรวจสอบ',
+    noOperations: 'การจำลอง OPERA จะถูกสร้างหลังยืนยันงาน',
+    noAudits: 'ยังไม่มีบันทึกตรวจสอบ',
+    execute: 'ดำเนินการ',
+    retry: 'ลองใหม่',
+    simulateFailure: 'จำลองความล้มเหลว',
+    fieldNotes: 'หมายเหตุข้อมูล',
+    emptyValue: 'ยังไม่กรอก',
+    attachments: 'ไฟล์แนบ',
+    fieldAreaFallback: 'ข้อมูลพื้นฐาน',
+    savedLocally: 'บันทึกร่างแล้ว',
+    confirmedLocally: 'ยืนยันงานแล้ว',
+    validationFailed: 'โปรดแก้ไขข้อมูลก่อน',
+    validation: {
+      required: '{field} จำเป็นต้องกรอก',
+      enum: '{field} ต้องเลือกจากตัวเลือกที่กำหนด',
+      date: '{field} ต้องใช้รูปแบบวันที่ YYYY-MM-DD',
+      number: '{field} ต้องเป็นตัวเลข',
+    },
+    viewOrder: 'ดูออเดอร์',
+    viewConversation: 'ดูเธรดอีเมล',
+    sourceMessageId: 'รหัสข้อความต้นทาง (ID)',
+    sourceSubject: 'หัวข้อต้นทาง',
+    sourceSender: 'ผู้ส่ง',
+    sourceReceivedAt: 'เวลารับ',
+    sourceSummaryPending: 'ข้อมูลสรุปอีเมลต้นทางยังรอหลังบ้านเพิ่มเติม',
+  },
+  conversation: {
+    title: 'รายละเอียดเธรดอีเมล',
+    subtitle: 'ดูอีเมลทั้งหมดและการตอบกลับในเธรดต้นทาง',
+    endpointPending: 'API รายละเอียดเธรดอีเมลยังไม่เชื่อมต่อ จึงไม่แสดงข้อมูลจำลอง',
+    subject: 'หัวข้อเธรด',
+    messageCount: 'จำนวนอีเมล',
+    channel: 'ช่องทาง',
+    firstReceivedAt: 'รับครั้งแรก',
+    lastReceivedAt: 'รับล่าสุด',
+    emptyBody: 'เนื้อหาอีเมลว่าง',
+    attachments: 'ไฟล์แนบ / รูปภาพในอีเมล',
+    unnamedAttachment: 'ไฟล์แนบไม่มีชื่อ',
+    relatedOrders: 'ออเดอร์ที่เกี่ยวข้อง',
+    relatedTasks: 'งานที่เกี่ยวข้อง',
+  },
+  status: {
+    TEMPORARY: 'ชั่วคราว',
+    ACTIVE: 'ใช้งานอยู่',
+    ENDED: 'สิ้นสุดแล้ว',
+    LOGIC_DELETED: 'ลบแล้ว',
+    PENDING_CONFIRM: 'รอยืนยัน',
+    READY: 'รอดำเนินการ',
+    EXECUTING: 'กำลังดำเนินการ',
+    FAILED: 'ล้มเหลว',
+    COMPLETED: 'เสร็จแล้ว',
+    PENDING: 'รอดำเนินการ',
+    SUCCEEDED: 'สำเร็จ',
+    BLOCKED: 'ถูกบล็อก',
+    SKIPPED: 'ข้าม',
+  },
+  cardType: {
+    NEW_BOOKING: 'จองใหม่',
+    UPDATE_BOOKING: 'แก้ไขการจอง',
+    CANCEL_BOOKING: 'ยกเลิกการจอง',
+    VOUCHER: 'วอเชอร์',
+    ROOMING_LIST: 'รายชื่อห้องพัก',
+    AMEND_GROUP_CODE: 'แก้ไขเลขกรุ๊ป',
+    TRACE_NOTE: 'หมายเหตุติดตาม (Trace)',
+    TA_RECORD: 'ข้อมูลบริษัททัวร์',
+    MESSAGE_NOTIFICATION: 'แจ้งเตือนข้อความ',
+    MANUAL_REVIEW: 'ตรวจสอบด้วยคน',
+  },
+  taskSubtype: {
+    NEW_BOOKING: 'จองใหม่',
+    UPDATE_BOOKING: 'แก้ไขการจอง',
+    CANCEL_BOOKING: 'ยกเลิกการจอง',
+    RATE_CHANGE: 'ปรับราคา',
+    UPDATE_STAY_DATES: 'แก้ไขวันเข้าพัก',
+    UPDATE_ROOM_TYPE: 'แก้ไขประเภทห้อง',
+    UPDATE_FIX_CHARGE: 'แก้ไขค่าบริการคงที่',
+    NEW_GROUP_BLOCK: 'บล็อกกรุ๊ปใหม่',
+    NEW_FIT_RESERVATION: 'จองรายบุคคลใหม่',
+    MANUAL_REVIEW: 'ตรวจสอบด้วยคน',
+  },
+  readonlyReason: {
+    PROCESSABLE: 'ประมวลผลได้',
+    PREVIOUS_TASK_NOT_FINISHED: 'งานก่อนหน้ายังไม่เสร็จ',
+    TASK_FINISHED: 'งานเสร็จแล้ว',
+    TASK_READ_ONLY: 'งานเป็นอ่านอย่างเดียว',
+    ORDER_CLOSED: 'ออเดอร์ปิดแล้ว',
+    QUEUE_EXCLUDED: 'ไม่อยู่ในคิว',
+    BLOCKED: 'ถูกบล็อก',
+  },
+  actorType: {
+    USER: 'ผู้ใช้',
+    SYSTEM: 'ระบบ',
+    AI: 'AI',
+    AGENT: 'ผู้ช่วยภายนอก',
+    BACKEND: 'บริการหลังบ้าน',
+  },
+  auditAction: {
+    TASK_CREATED: 'สร้างงาน',
+    TASK_LOADED: 'อ่านงาน',
+    TASK_CONFIRMED: 'ยืนยันงาน',
+    TASK_CONFIRM: 'ยืนยันงาน',
+    DRAFT_SAVED: 'บันทึกร่าง',
+    TASK_UPDATED: 'อัปเดตงาน',
+    OPERA_EXECUTED: 'ดำเนินการ OPERA',
+    OPERA_RETRIED: 'ลอง OPERA ใหม่',
+    MANUAL_REVIEW_CREATED: 'สร้างงานตรวจสอบด้วยคน',
+  },
+  operaOperation: {
+    CREATE_RESERVATION: 'สร้างการจอง',
+    UPDATE_RESERVATION: 'อัปเดตการจอง',
+    CANCEL_RESERVATION: 'ยกเลิกการจอง',
+    UPDATE_ROOMING_LIST: 'อัปเดตรายชื่อห้องพัก',
+    ADD_TRACE_NOTE: 'เพิ่มหมายเหตุติดตาม',
+  },
+}
diff --git a/client/src/i18n/locales/zh-CN.ts b/client/src/i18n/locales/zh-CN.ts
index cf5c690..26fc6b9 100644
--- a/client/src/i18n/locales/zh-CN.ts
+++ b/client/src/i18n/locales/zh-CN.ts
@@ -2,6 +2,8 @@ export default {
   app: {
     name: 'Hotel OMS',
     theme: '主题',
+    language: '语言',
+    navigationAria: '预订订单导航',
     healthUp: '后端已连接',
     healthDown: '后端未连接',
     healthChecking: '检查中',
@@ -20,6 +22,14 @@ export default {
     noData: '暂无数据',
     endpointPending: '接口待接入',
     endpointMissing: '接口待补',
+    all: '全部',
+    unknownStatus: '未知状态',
+    unknownTaskType: '未知任务类型',
+    unknownTaskSubtype: '未知任务细分',
+    unknownReadonlyReason: '暂不可处理',
+    unknownActorType: '未知操作者',
+    unknownAuditAction: '未知操作',
+    unknownOperation: '未知操作',
     previousPage: '上一页',
     nextPage: '下一页',
     pageStatus: '第 {current} / {total} 页',
@@ -27,7 +37,7 @@ export default {
   },
   workbench: {
     title: '订单工作台',
-    subtitle: '查看、筛选和处理 Reservation 订单任务',
+    subtitle: '查看、筛选和处理预订订单任务',
     filters: '筛选条件',
     dateRange: '日期范围',
     businessKey: '业务号 / 临时单号',
@@ -50,14 +60,15 @@ export default {
   },
   orderList: {
     title: '订单列表',
-    subtitle: '按订单查看 Reservation 处理入口',
-    keyword: 'Group Code / Confirmation No.',
+    subtitle: '按订单查看预订处理入口',
+    keyword: '团队号 / 确认号',
+    keywordPlaceholder: '团队号 / 确认号',
     tableTitle: '订单数据',
     totalSuffix: '条订单',
     viewDetail: '查看详情',
     continueTask: '继续处理',
     noOpenTask: '无待处理任务',
-    endpointPending: '订单列表接口 GET /api/reservation/orders 待后端接入，当前不展示假数据。',
+    endpointPending: '订单列表接口待后端接入，当前不展示假数据。',
     columns: {
       order: '订单',
       status: '状态',
@@ -76,18 +87,19 @@ export default {
     roomType: '房型',
     amount: '金额',
     openTask: '处理任务',
-    groupCode: 'Group Code',
-    confirmationNumber: 'Confirmation No.',
+    groupCode: '团队号（Group Code）',
+    confirmationNumber: '确认号（Confirmation No.）',
     temporaryOrderNo: '临时单号',
-    blockCode: 'Block Code',
+    blockCode: '团队预留号（Block Code）',
     createdAt: '创建时间',
     conversationMessageCount: '会话邮件数',
     sourceSummaryPending: '订单详情任务时间线的来源邮件摘要字段待后端补充；请从具体任务进入后查看。',
   },
   taskList: {
     title: '任务列表',
-    subtitle: '按任务查看 Reservation 待处理队列',
+    subtitle: '按任务查看预订待处理队列',
     keyword: '订单 / 邮件关键词',
+    keywordPlaceholder: '订单号 / 邮件关键词',
     taskType: '任务类型',
     tableTitle: '任务数据',
     totalSuffix: '条任务',
@@ -98,7 +110,6 @@ export default {
     queueAll: '全部队列状态',
     queueIncluded: '参与队列',
     queueExcluded: '不参与队列',
-    orderStatusFilterPending: '订单状态筛选待后端接入',
     viewTask: '查看任务',
     viewOrder: '查看订单',
     viewConversation: '查看邮件会话',
@@ -136,12 +147,12 @@ export default {
     validation: {
       required: '{field}为必填项',
       enum: '{field}必须来自可选项',
-      date: '{field}必须是 YYYY-MM-DD',
+      date: '{field}日期格式必须为 YYYY-MM-DD',
       number: '{field}必须是数字',
     },
     viewOrder: '查看订单',
     viewConversation: '查看邮件会话',
-    sourceMessageId: '来源消息 ID',
+    sourceMessageId: '来源消息编号（ID）',
     sourceSubject: '来源主题',
     sourceSender: '发件人',
     sourceReceivedAt: '接收时间',
@@ -184,9 +195,55 @@ export default {
     VOUCHER: '凭证',
     ROOMING_LIST: '房表',
     AMEND_GROUP_CODE: '修改团队号',
-    TRACE_NOTE: 'Trace / 备注',
+    TRACE_NOTE: '追踪备注（Trace）',
     TA_RECORD: '旅行社记录',
     MESSAGE_NOTIFICATION: '消息通知',
     MANUAL_REVIEW: '人工复核',
   },
+  taskSubtype: {
+    NEW_BOOKING: '新预订',
+    UPDATE_BOOKING: '修改预订',
+    CANCEL_BOOKING: '取消预订',
+    RATE_CHANGE: '价格调整',
+    UPDATE_STAY_DATES: '修改入住日期',
+    UPDATE_ROOM_TYPE: '修改房型',
+    UPDATE_FIX_CHARGE: '修改固定收费',
+    NEW_GROUP_BLOCK: '新团队预留',
+    NEW_FIT_RESERVATION: '新散客预订',
+    MANUAL_REVIEW: '人工复核',
+  },
+  readonlyReason: {
+    PROCESSABLE: '可处理',
+    PREVIOUS_TASK_NOT_FINISHED: '前序任务未完成',
+    TASK_FINISHED: '任务已结束',
+    TASK_READ_ONLY: '任务只读',
+    ORDER_CLOSED: '订单已关闭',
+    QUEUE_EXCLUDED: '未参与队列',
+    BLOCKED: '阻塞中',
+  },
+  actorType: {
+    USER: '人工用户',
+    SYSTEM: '系统',
+    AI: 'AI',
+    AGENT: '外部助手',
+    BACKEND: '后端服务',
+  },
+  auditAction: {
+    TASK_CREATED: '任务创建',
+    TASK_LOADED: '任务读取',
+    TASK_CONFIRMED: '任务确认',
+    TASK_CONFIRM: '任务确认',
+    DRAFT_SAVED: '草稿保存',
+    TASK_UPDATED: '任务更新',
+    OPERA_EXECUTED: 'OPERA 执行',
+    OPERA_RETRIED: 'OPERA 重试',
+    MANUAL_REVIEW_CREATED: '创建人工复核',
+  },
+  operaOperation: {
+    CREATE_RESERVATION: '创建预订',
+    UPDATE_RESERVATION: '更新预订',
+    CANCEL_RESERVATION: '取消预订',
+    UPDATE_ROOMING_LIST: '更新房表',
+    ADD_TRACE_NOTE: '添加追踪备注',
+  },
 }
diff --git a/client/src/layouts/ReservationAppShell.vue b/client/src/layouts/ReservationAppShell.vue
index d1ea975..c22b192 100644
--- a/client/src/layouts/ReservationAppShell.vue
+++ b/client/src/layouts/ReservationAppShell.vue
@@ -14,7 +14,7 @@
 
       <nav
         class="app-nav"
-        aria-label="Reservation navigation"
+        :aria-label="t('app.navigationAria')"
       >
         <RouterLink
           v-for="item in navItems"
@@ -52,21 +52,16 @@
 
           <div
             class="locale-switch"
-            aria-label="Language"
+            :aria-label="t('app.language')"
           >
             <button
+              v-for="option in localeOptions"
+              :key="option.value"
               type="button"
-              :class="{ active: locale === 'zh-CN' }"
-              @click="setLocale('zh-CN')"
+              :class="{ active: locale === option.value }"
+              @click="setLocale(option.value)"
             >
-              中文
-            </button>
-            <button
-              type="button"
-              :class="{ active: locale === 'en-US' }"
-              @click="setLocale('en-US')"
-            >
-              EN
+              {{ option.label }}
             </button>
           </div>
 
@@ -105,6 +100,12 @@ const { t, locale } = useI18n()
 const preferences = useAppPreferencesStore()
 const healthState = ref<'checking' | 'up' | 'down'>('checking')
 
+const localeOptions: Array<{ value: SupportedLocale; label: string }> = [
+  { value: 'zh-CN', label: '中文' },
+  { value: 'en-US', label: 'EN' },
+  { value: 'th-TH', label: 'ไทย' },
+]
+
 const navItems = [
   {
     to: '/reservation/orders',
diff --git a/client/src/stores/appPreferences.ts b/client/src/stores/appPreferences.ts
index 2c2ec83..8634d29 100644
--- a/client/src/stores/appPreferences.ts
+++ b/client/src/stores/appPreferences.ts
@@ -1,6 +1,6 @@
 import { defineStore } from 'pinia'
 
-export type SupportedLocale = 'zh-CN' | 'en-US'
+export type SupportedLocale = 'zh-CN' | 'en-US' | 'th-TH'
 
 export const useAppPreferencesStore = defineStore('appPreferences', {
   state: () => ({
diff --git a/client/src/tests/ReservationStatusBadge.spec.ts b/client/src/tests/ReservationStatusBadge.spec.ts
index 88b4abe..b6e220e 100644
--- a/client/src/tests/ReservationStatusBadge.spec.ts
+++ b/client/src/tests/ReservationStatusBadge.spec.ts
@@ -32,9 +32,10 @@ describe('ReservationStatusBadge', () => {
     expect(wrapper.classes()).toContain('status-badge--info')
   })
 
-  it('falls back to the raw code for unknown status', () => {
+  it('falls back to a localized unknown status label', () => {
     const wrapper = mountWithI18n('UNKNOWN_STATUS')
 
-    expect(wrapper.text()).toContain('UNKNOWN_STATUS')
+    expect(wrapper.text()).toContain('未知状态')
+    expect(wrapper.text()).not.toContain('UNKNOWN_STATUS')
   })
 })
diff --git a/client/src/tests/i18nLocales.spec.ts b/client/src/tests/i18nLocales.spec.ts
new file mode 100644
index 0000000..5413e43
--- /dev/null
+++ b/client/src/tests/i18nLocales.spec.ts
@@ -0,0 +1,33 @@
+import { describe, expect, it } from 'vitest'
+
+import enUS from '@/i18n/locales/en-US'
+import thTH from '@/i18n/locales/th-TH'
+import zhCN from '@/i18n/locales/zh-CN'
+
+describe('reservation i18n locales', () => {
+  it('keeps Chinese, English, and Thai locale keys aligned', () => {
+    const zhKeys = collectKeyPaths(zhCN)
+
+    expect(collectKeyPaths(enUS)).toEqual(zhKeys)
+    expect(collectKeyPaths(thTH)).toEqual(zhKeys)
+  })
+
+  it('includes Thai labels for the P0 reservation navigation', () => {
+    expect(thTH.nav.orders).toBe('รายการออเดอร์')
+    expect(thTH.nav.taskQueue).toBe('คิวงาน')
+    expect(thTH.taskList.viewConversation).toBe('ดูเธรดอีเมล')
+  })
+})
+
+function collectKeyPaths(value: unknown, prefix = ''): string[] {
+  if (!isRecord(value)) {
+    return [prefix]
+  }
+  return Object.keys(value)
+    .sort()
+    .flatMap((key) => collectKeyPaths(value[key], prefix ? `${prefix}.${key}` : key))
+}
+
+function isRecord(value: unknown): value is Record<string, unknown> {
+  return typeof value === 'object' && value !== null && !Array.isArray(value)
+}
diff --git a/client/src/tests/reservationAppShell.spec.ts b/client/src/tests/reservationAppShell.spec.ts
new file mode 100644
index 0000000..2aaec6c
--- /dev/null
+++ b/client/src/tests/reservationAppShell.spec.ts
@@ -0,0 +1,70 @@
+import { mount } from '@vue/test-utils'
+import { createPinia } from 'pinia'
+import { createI18n } from 'vue-i18n'
+import { createMemoryHistory, createRouter } from 'vue-router'
+import { describe, expect, it, vi } from 'vitest'
+
+import ReservationAppShell from '@/layouts/ReservationAppShell.vue'
+import enUS from '@/i18n/locales/en-US'
+import thTH from '@/i18n/locales/th-TH'
+import zhCN from '@/i18n/locales/zh-CN'
+
+vi.mock('@/services/healthService', () => ({
+  fetchBackendHealth: vi.fn().mockResolvedValue({
+    status: 'UP',
+    service: 'test',
+  }),
+}))
+
+async function mountShell() {
+  const i18n = createI18n({
+    legacy: false,
+    locale: 'zh-CN',
+    fallbackLocale: 'zh-CN',
+    messages: {
+      'zh-CN': zhCN,
+      'en-US': enUS,
+      'th-TH': thTH,
+    },
+  })
+  const router = createRouter({
+    history: createMemoryHistory(),
+    routes: [
+      {
+        path: '/reservation/orders',
+        component: { template: '<div />' },
+        meta: { titleKey: 'nav.orders' },
+      },
+      {
+        path: '/reservation/tasks',
+        component: { template: '<div />' },
+        meta: { titleKey: 'nav.taskQueue' },
+      },
+    ],
+  })
+  await router.push('/reservation/orders')
+  await router.isReady()
+
+  return mount(ReservationAppShell, {
+    global: {
+      plugins: [i18n, router, createPinia()],
+    },
+    slots: {
+      default: '<section />',
+    },
+  })
+}
+
+describe('ReservationAppShell', () => {
+  it('switches between Chinese, English, and Thai labels', async () => {
+    const wrapper = await mountShell()
+
+    expect(wrapper.text()).toContain('订单列表')
+
+    await wrapper.findAll('button').find((button) => button.text() === 'ไทย')?.trigger('click')
+    expect(wrapper.text()).toContain('รายการออเดอร์')
+
+    await wrapper.findAll('button').find((button) => button.text() === 'EN')?.trigger('click')
+    expect(wrapper.text()).toContain('Order list')
+  })
+})
diff --git a/client/src/tests/reservationDisplay.spec.ts b/client/src/tests/reservationDisplay.spec.ts
new file mode 100644
index 0000000..d0c488a
--- /dev/null
+++ b/client/src/tests/reservationDisplay.spec.ts
@@ -0,0 +1,33 @@
+import { createI18n } from 'vue-i18n'
+import { describe, expect, it } from 'vitest'
+
+import zhCN from '@/i18n/locales/zh-CN'
+import {
+  formatReservationActorType,
+  formatReservationReadonlyReason,
+  formatReservationTaskTypeSummary,
+} from '@/utils/reservationDisplay'
+
+const i18n = createI18n({
+  legacy: false,
+  locale: 'zh-CN',
+  messages: {
+    'zh-CN': zhCN,
+  },
+})
+
+describe('reservationDisplay', () => {
+  it('formats known task type and subtype codes without exposing duplicated raw codes', () => {
+    expect(formatReservationTaskTypeSummary(i18n.global.t, 'NEW_BOOKING', 'NEW_BOOKING')).toBe('新预订')
+    expect(formatReservationTaskTypeSummary(i18n.global.t, 'UPDATE_BOOKING', 'RATE_CHANGE')).toBe('修改预订 / 价格调整')
+  })
+
+  it('formats readonly reason and actor codes with user-facing labels', () => {
+    expect(formatReservationReadonlyReason(i18n.global.t, 'PREVIOUS_TASK_NOT_FINISHED')).toBe('前序任务未完成')
+    expect(formatReservationActorType(i18n.global.t, 'USER')).toBe('人工用户')
+  })
+
+  it('uses localized fallback labels for unknown stable codes', () => {
+    expect(formatReservationReadonlyReason(i18n.global.t, 'SOME_BACKEND_CODE')).toBe('暂不可处理')
+  })
+})
diff --git a/client/src/tests/reservationService.spec.ts b/client/src/tests/reservationService.spec.ts
index b24b040..6217895 100644
--- a/client/src/tests/reservationService.spec.ts
+++ b/client/src/tests/reservationService.spec.ts
@@ -63,12 +63,13 @@ describe('reservationService real API mode', () => {
 
     const result = await fetchReservationTaskList({
       task_status: 'PENDING_CONFIRM',
+      order_status: 'ACTIVE',
       page_num: 1,
       page_size: 20,
     })
 
     expect(fetchMock).toHaveBeenCalledWith(
-      '/api/reservation/tasks?hotel_id=HOTEL-TEST&task_status=PENDING_CONFIRM&page_num=1&page_size=20',
+      '/api/reservation/tasks?hotel_id=HOTEL-TEST&task_status=PENDING_CONFIRM&order_status=ACTIVE&page_num=1&page_size=20',
       expect.objectContaining({ method: 'GET' }),
     )
     expect(result.items).toHaveLength(1)
@@ -204,7 +205,9 @@ describe('reservationService real API mode', () => {
             source_sent_at: '2026-07-08T01:58:00Z',
             text_body: '完整邮件正文',
             html_body: '<p>完整邮件正文</p>',
+            html_body_sanitized: '<p>完整邮件正文</p>',
             html_sanitize_required: true,
+            html_render_mode: 'SANITIZED_HTML',
             inline_images: [],
             attachments: [],
             related_orders: [
diff --git a/client/src/tests/reservationTaskDetailPanel.spec.ts b/client/src/tests/reservationTaskDetailPanel.spec.ts
index 4307441..a840b84 100644
--- a/client/src/tests/reservationTaskDetailPanel.spec.ts
+++ b/client/src/tests/reservationTaskDetailPanel.spec.ts
@@ -259,13 +259,15 @@ describe('ReservationTaskDetailPanel', () => {
     vi.mocked(service.saveReservationTaskDraft).mockResolvedValue(createMutationResult())
 
     const wrapper = await mountPanel()
-    expect(wrapper.text()).toContain('TASK_LOADED')
+    expect(wrapper.text()).toContain('任务读取')
 
     await findButton(wrapper, '保存草稿').trigger('click')
     await flushPromises()
 
     expect(service.fetchReservationTaskAudits).toHaveBeenCalledTimes(2)
-    expect(wrapper.text()).toContain('DRAFT_SAVED')
+    expect(wrapper.text()).toContain('草稿保存')
+    expect(wrapper.text()).not.toContain('任务读取')
+    expect(wrapper.text()).not.toContain('DRAFT_SAVED')
     expect(wrapper.text()).not.toContain('TASK_LOADED')
   })
 
diff --git a/client/src/tests/reservationTaskQueue.spec.ts b/client/src/tests/reservationTaskQueue.spec.ts
index 4e143e7..fd0713b 100644
--- a/client/src/tests/reservationTaskQueue.spec.ts
+++ b/client/src/tests/reservationTaskQueue.spec.ts
@@ -80,6 +80,7 @@ describe('ReservationTaskQueue', () => {
     ])
 
     expect(wrapper.text()).toContain('不可处理')
-    expect(wrapper.text()).toContain('PREVIOUS_TASK_NOT_FINISHED')
+    expect(wrapper.text()).toContain('前序任务未完成')
+    expect(wrapper.text()).not.toContain('PREVIOUS_TASK_NOT_FINISHED')
   })
 })
diff --git a/client/src/tests/reservationViews.spec.ts b/client/src/tests/reservationViews.spec.ts
index da61490..3fc0500 100644
--- a/client/src/tests/reservationViews.spec.ts
+++ b/client/src/tests/reservationViews.spec.ts
@@ -8,6 +8,7 @@ import ReservationOrderDetailView from '@/views/reservation/ReservationOrderDeta
 import ReservationOrderListView from '@/views/reservation/ReservationOrderListView.vue'
 import ReservationSourceMessageConversationView from '@/views/reservation/ReservationSourceMessageConversationView.vue'
 import ReservationTaskListView from '@/views/reservation/ReservationTaskListView.vue'
+import type { SourceMessageConversationResult } from '@/types/reservation'
 
 vi.mock('@/services/reservationService', async (importOriginal) => {
   const actual = await importOriginal<typeof import('@/services/reservationService')>()
@@ -148,8 +149,8 @@ function createOrderDetailResult() {
 }
 
 function createSourceMessageConversationResult(
-  overrides: Partial<ReturnType<typeof createSourceMessageConversationResultBase>> = {},
-) {
+  overrides: Partial<SourceMessageConversationResult> = {},
+): SourceMessageConversationResult {
   const result = createSourceMessageConversationResultBase()
   return {
     ...result,
@@ -157,7 +158,7 @@ function createSourceMessageConversationResult(
   }
 }
 
-function createSourceMessageConversationResultBase() {
+function createSourceMessageConversationResultBase(): SourceMessageConversationResult {
   return {
     conversation: {
       hotel_id: 'HOTEL-TEST',
@@ -178,8 +179,10 @@ function createSourceMessageConversationResultBase() {
         received_at: '2026-07-08T02:00:00Z',
         source_sent_at: '2026-07-08T01:58:00Z',
         text_body: '完整邮件正文',
-        html_body: '<strong>不应直接渲染</strong>',
+        html_body: '<script>alert("raw")</script><strong onclick="alert(1)">原始邮件正文</strong>',
+        html_body_sanitized: '<strong>清洗后邮件正文</strong>',
         html_sanitize_required: true,
+        html_render_mode: 'SANITIZED_HTML',
         inline_images: [],
         attachments: [
           {
@@ -289,7 +292,9 @@ describe('reservation P0 views', () => {
     expect(wrapper.text()).toContain('Booking Request')
     expect(wrapper.text()).toContain('guest@example.test')
     expect(wrapper.text()).toContain('2')
+    expect(wrapper.text()).toContain('前序任务未完成')
     expect(wrapper.text()).toContain('查看邮件会话')
+    expect(wrapper.text()).not.toContain('PREVIOUS_TASK_NOT_FINISHED')
     expect(wrapper.text()).not.toContain('来源邮件摘要字段待后端补充')
   })
 
@@ -346,8 +351,10 @@ describe('reservation P0 views', () => {
 
     expect(wrapper.text()).toContain('GRP-001')
     expect(wrapper.text()).toContain('Booking Request')
+    expect(wrapper.text()).toContain('新预订')
     expect(wrapper.text()).toContain('查看邮件会话')
     expect(wrapper.text()).not.toContain('接口待补')
+    expect(wrapper.text()).not.toContain('NEW_BOOKING / NEW_BOOKING')
   })
 
   it('filters and paginates task list with supported backend fields', async () => {
@@ -355,17 +362,20 @@ describe('reservation P0 views', () => {
       .mockResolvedValueOnce(createTaskListResult('GRP-001', 'Booking Request', { page_num: 1, page_size: 20, total: 45 }))
       .mockResolvedValueOnce(createTaskListResult('GRP-001', 'Booking Request', { page_num: 1, page_size: 20, total: 45 }))
       .mockResolvedValueOnce(createTaskListResult('GRP-001', 'Booking Request', { page_num: 1, page_size: 20, total: 45 }))
+      .mockResolvedValueOnce(createTaskListResult('GRP-001', 'Booking Request', { page_num: 1, page_size: 20, total: 45 }))
       .mockResolvedValueOnce(createTaskListResult('GRP-002', 'Booking Update', { page_num: 2, page_size: 20, total: 45 }))
 
     const wrapper = await mountWithPlugins(ReservationTaskListView)
     await vi.dynamicImportSettled()
 
     const selects = wrapper.findAll('select')
-    expect(wrapper.text()).toContain('订单状态筛选待后端接入')
-    expect(selects[2]!.attributes('disabled')).toBeDefined()
+    expect(wrapper.text()).not.toContain('订单状态筛选待后端接入')
+    expect(selects[2]!.attributes('disabled')).toBeUndefined()
 
     await selects[1]!.setValue('READY')
     await vi.dynamicImportSettled()
+    await selects[2]!.setValue('ENDED')
+    await vi.dynamicImportSettled()
     await selects[3]!.setValue('true')
     await vi.dynamicImportSettled()
 
@@ -373,10 +383,10 @@ describe('reservation P0 views', () => {
     const filteredTaskRequest = taskListCalls[taskListCalls.length - 1]?.[0] ?? {}
     expect(filteredTaskRequest).toMatchObject({
       task_status: 'READY',
+      order_status: 'ENDED',
       queue_participation: true,
       page_num: 1,
     })
-    expect(filteredTaskRequest).not.toHaveProperty('order_status')
 
     await wrapper.findAll('button').find((button) => button.text().includes('下一页'))?.trigger('click')
     await vi.dynamicImportSettled()
@@ -384,6 +394,7 @@ describe('reservation P0 views', () => {
     expect(service.fetchReservationTaskList).toHaveBeenLastCalledWith(
       expect.objectContaining({
         task_status: 'READY',
+        order_status: 'ENDED',
         queue_participation: true,
         page_num: 2,
         page_size: 20,
@@ -436,12 +447,34 @@ describe('reservation P0 views', () => {
 
     expect(service.fetchSourceMessageConversation).toHaveBeenCalledWith('30001')
     expect(wrapper.text()).toContain('Booking Request')
-    expect(wrapper.text()).toContain('不应直接渲染')
+    expect(wrapper.text()).toContain('清洗后邮件正文')
     expect(wrapper.text()).toContain('rooming-list.xlsx')
-    expect(wrapper.find('.message-body').html()).toContain('<strong>不应直接渲染</strong>')
+    expect(wrapper.find('.message-body').html()).toContain('<strong>清洗后邮件正文</strong>')
+    expect(wrapper.find('.message-body').html()).not.toContain('<script>')
+    expect(wrapper.find('.message-body').html()).not.toContain('onclick')
+    expect(wrapper.text()).not.toContain('原始邮件正文')
     expect(wrapper.text()).not.toContain('接口待接入')
   })
 
+  it('falls back to text when sanitized html is unavailable', async () => {
+    const conversationResult = createSourceMessageConversationResult()
+    conversationResult.messages[0]!.html_body = '<strong>原始 HTML 不上屏</strong>'
+    conversationResult.messages[0]!.html_body_sanitized = null
+    conversationResult.messages[0]!.html_render_mode = 'TEXT_ONLY'
+    conversationResult.messages[0]!.text_body = '纯文本回退正文'
+    vi.mocked(service.fetchSourceMessageConversation).mockResolvedValue(conversationResult)
+
+    const wrapper = await mountWithPlugins(
+      ReservationSourceMessageConversationView,
+      '/reservation/source-messages/30001/conversation',
+    )
+    await vi.dynamicImportSettled()
+
+    expect(wrapper.text()).toContain('纯文本回退正文')
+    expect(wrapper.text()).not.toContain('原始 HTML 不上屏')
+    expect(wrapper.find('.message-body--html').exists()).toBe(false)
+  })
+
   it('does not expose unsafe attachment URLs as links', async () => {
     const conversationResult = createSourceMessageConversationResult()
     conversationResult.messages[0]!.attachments = [
diff --git a/client/src/types/reservation.ts b/client/src/types/reservation.ts
index 49f12fe..d433a57 100644
--- a/client/src/types/reservation.ts
+++ b/client/src/types/reservation.ts
@@ -66,6 +66,7 @@ export interface ReservationTaskListFilters {
   task_type?: string
   task_subtype?: string
   task_status?: string
+  order_status?: string
   queue_participation?: boolean
   keyword?: string
   page_num?: number
@@ -163,7 +164,9 @@ export interface SourceMessageConversationItem {
   source_sent_at: string | null
   text_body: string | null
   html_body: string | null
+  html_body_sanitized: string | null
   html_sanitize_required: boolean
+  html_render_mode: 'SANITIZED_HTML' | 'TEXT_ONLY' | string | null
   inline_images: SourceMessageOriginalMedia[]
   attachments: SourceMessageOriginalMedia[]
   related_orders: SourceMessageRelatedOrder[]
diff --git a/client/src/utils/reservationDisplay.ts b/client/src/utils/reservationDisplay.ts
new file mode 100644
index 0000000..036603e
--- /dev/null
+++ b/client/src/utils/reservationDisplay.ts
@@ -0,0 +1,85 @@
+type ReservationTranslator = (key: string, fallback?: string) => string
+
+export function formatReservationTaskCard(
+  t: ReservationTranslator,
+  taskType: string | null | undefined,
+  fallbackLabel?: string | null,
+): string {
+  return translateStableCode(t, 'cardType', taskType, 'common.unknownTaskType', fallbackLabel)
+}
+
+export function formatReservationTaskTypeSummary(
+  t: ReservationTranslator,
+  taskType: string | null | undefined,
+  taskSubtype: string | null | undefined,
+): string {
+  const typeLabel = formatReservationTaskCard(t, taskType)
+  const normalizedType = normalizeStableCode(taskType)
+  const normalizedSubtype = normalizeStableCode(taskSubtype)
+  if (!normalizedSubtype || normalizedSubtype === normalizedType) {
+    return typeLabel
+  }
+  return `${typeLabel} / ${translateStableCode(t, 'taskSubtype', taskSubtype, 'common.unknownTaskSubtype')}`
+}
+
+export function formatReservationReadonlyReason(
+  t: ReservationTranslator,
+  reasonCode: string | null | undefined,
+): string {
+  return translateStableCode(t, 'readonlyReason', reasonCode, 'common.unknownReadonlyReason')
+}
+
+export function formatReservationMaybeStableReason(
+  t: ReservationTranslator,
+  reason: string | null | undefined,
+  fallbackKey: string,
+): string {
+  if (!reason) {
+    return t(fallbackKey)
+  }
+  if (isStableCode(reason)) {
+    return formatReservationReadonlyReason(t, reason)
+  }
+  return reason
+}
+
+export function formatReservationActorType(t: ReservationTranslator, actorType: string): string {
+  return translateStableCode(t, 'actorType', actorType, 'common.unknownActorType')
+}
+
+export function formatReservationAuditAction(t: ReservationTranslator, action: string): string {
+  return translateStableCode(t, 'auditAction', action, 'common.unknownAuditAction')
+}
+
+export function formatReservationOperaOperation(
+  t: ReservationTranslator,
+  operationCode: string | null | undefined,
+  fallbackLabel?: string | null,
+): string {
+  return translateStableCode(t, 'operaOperation', operationCode, 'common.unknownOperation', fallbackLabel)
+}
+
+function translateStableCode(
+  t: ReservationTranslator,
+  namespace: string,
+  code: string | null | undefined,
+  fallbackKey: string,
+  fallbackLabel?: string | null,
+): string {
+  const normalizedCode = normalizeStableCode(code)
+  if (!normalizedCode) {
+    return fallbackLabel || t(fallbackKey)
+  }
+  return t(`${namespace}.${normalizedCode}`, fallbackLabel || t(fallbackKey))
+}
+
+function normalizeStableCode(code: string | null | undefined): string {
+  if (!code) {
+    return ''
+  }
+  return code.trim().replace(/[\s-]+/g, '_').toUpperCase()
+}
+
+function isStableCode(value: string): boolean {
+  return /^[A-Z0-9_ -]+$/.test(value.trim())
+}
diff --git a/client/src/views/reservation/ReservationOrderDetailView.vue b/client/src/views/reservation/ReservationOrderDetailView.vue
index f3dee5a..f3c4cc6 100644
--- a/client/src/views/reservation/ReservationOrderDetailView.vue
+++ b/client/src/views/reservation/ReservationOrderDetailView.vue
@@ -4,7 +4,7 @@
       v-if="loading"
       class="th-section order-state"
     >
-      Loading...
+      {{ t('common.loading') }}
     </div>
     <div
       v-else-if="errorMessage"
diff --git a/client/src/views/reservation/ReservationOrderListView.vue b/client/src/views/reservation/ReservationOrderListView.vue
index 43f9659..564e1ac 100644
--- a/client/src/views/reservation/ReservationOrderListView.vue
+++ b/client/src/views/reservation/ReservationOrderListView.vue
@@ -26,7 +26,7 @@
           <input
             v-model="filters.keyword"
             type="search"
-            placeholder="GRP-001 / CNF123456"
+            :placeholder="t('orderList.keywordPlaceholder')"
             @input="resetToFirstPage"
           >
         </label>
@@ -36,7 +36,7 @@
             v-model="filters.order_status"
             @change="resetToFirstPage"
           >
-            <option value="">All</option>
+            <option value="">{{ t('common.all') }}</option>
             <option value="TEMPORARY">{{ t('status.TEMPORARY') }}</option>
             <option value="ACTIVE">{{ t('status.ACTIVE') }}</option>
             <option value="ENDED">{{ t('status.ENDED') }}</option>
diff --git a/client/src/views/reservation/ReservationSourceMessageConversationView.vue b/client/src/views/reservation/ReservationSourceMessageConversationView.vue
index 4535a69..408ca51 100644
--- a/client/src/views/reservation/ReservationSourceMessageConversationView.vue
+++ b/client/src/views/reservation/ReservationSourceMessageConversationView.vue
@@ -69,9 +69,9 @@
 
             <!-- eslint-disable vue/no-v-html -->
             <div
-              v-if="message.html_body"
+              v-if="renderableHtmlBody(message)"
               class="message-body message-body--html"
-              v-html="message.html_body"
+              v-html="renderableHtmlBody(message)"
             />
             <!-- eslint-enable vue/no-v-html -->
             <pre
@@ -130,7 +130,7 @@
                     :key="task.task_id"
                   >
                     <RouterLink :to="`/reservation/tasks/${task.task_id}`">
-                      {{ task.card_name ?? task.task_type }}
+                      {{ formatReservationTaskCard(t, task.task_type, task.card_name) }}
                     </RouterLink>
                   </li>
                 </ul>
@@ -154,6 +154,7 @@ import type {
   SourceMessageConversationResult,
   SourceMessageOriginalMedia,
 } from '@/types/reservation'
+import { formatReservationTaskCard } from '@/utils/reservationDisplay'
 import { formatReservationDateTime } from '@/utils/reservationFormat'
 
 const route = useRoute()
@@ -205,6 +206,8 @@ function normalizeConversation(result: SourceMessageConversationResult): SourceM
     messages: result.messages.map((message) => ({
       ...message,
       attachments: message.attachments ?? [],
+      html_body_sanitized: message.html_body_sanitized ?? null,
+      html_render_mode: message.html_render_mode ?? null,
       inline_images: message.inline_images ?? [],
       related_orders: message.related_orders ?? [],
       related_tasks: message.related_tasks ?? [],
@@ -216,6 +219,13 @@ function formatTextMessageBody(message: SourceMessageConversationItem): string {
   return message.text_body || t('conversation.emptyBody')
 }
 
+function renderableHtmlBody(message: SourceMessageConversationItem): string {
+  if (message.html_render_mode && message.html_render_mode !== 'SANITIZED_HTML') {
+    return ''
+  }
+  return message.html_body_sanitized ?? ''
+}
+
 function combinedMedia(message: SourceMessageConversationItem): SourceMessageOriginalMedia[] {
   return [...message.attachments, ...message.inline_images]
 }
diff --git a/client/src/views/reservation/ReservationTaskListView.vue b/client/src/views/reservation/ReservationTaskListView.vue
index 49d6e02..50279d6 100644
--- a/client/src/views/reservation/ReservationTaskListView.vue
+++ b/client/src/views/reservation/ReservationTaskListView.vue
@@ -27,7 +27,7 @@
           <input
             v-model="filters.keyword"
             type="search"
-            placeholder="GRP-001 / Booking"
+            :placeholder="t('taskList.keywordPlaceholder')"
             @input="resetToFirstPage"
           >
         </label>
@@ -37,7 +37,7 @@
             v-model="filters.task_type"
             @change="resetToFirstPage"
           >
-            <option value="">All</option>
+            <option value="">{{ t('common.all') }}</option>
             <option value="NEW_BOOKING">{{ t('cardType.NEW_BOOKING') }}</option>
             <option value="UPDATE_BOOKING">{{ t('cardType.UPDATE_BOOKING') }}</option>
             <option value="CANCEL_BOOKING">{{ t('cardType.CANCEL_BOOKING') }}</option>
@@ -51,7 +51,7 @@
             v-model="filters.task_status"
             @change="resetToFirstPage"
           >
-            <option value="">All</option>
+            <option value="">{{ t('common.all') }}</option>
             <option value="PENDING_CONFIRM">{{ t('status.PENDING_CONFIRM') }}</option>
             <option value="READY">{{ t('status.READY') }}</option>
             <option value="BLOCKED">{{ t('status.BLOCKED') }}</option>
@@ -61,15 +61,15 @@
         <label>
           <span>{{ t('workbench.orderStatus') }}</span>
           <select
-            value=""
-            disabled
+            v-model="filters.order_status"
+            @change="resetToFirstPage"
           >
-            <option value="">All</option>
+            <option value="">{{ t('common.all') }}</option>
             <option value="TEMPORARY">{{ t('status.TEMPORARY') }}</option>
             <option value="ACTIVE">{{ t('status.ACTIVE') }}</option>
             <option value="ENDED">{{ t('status.ENDED') }}</option>
+            <option value="LOGIC_DELETED">{{ t('status.LOGIC_DELETED') }}</option>
           </select>
-          <small class="filter-hint">{{ t('taskList.orderStatusFilterPending') }}</small>
         </label>
         <label>
           <span>{{ t('taskList.queueParticipation') }}</span>
@@ -139,13 +139,13 @@
             >
               <td>
                 <strong class="th-code">#{{ task.task_id }}</strong>
-                <small>{{ task.task_type }} / {{ task.task_subtype ?? '-' }}</small>
+                <small>{{ formatReservationTaskTypeSummary(t, task.task_type, task.task_subtype) }}</small>
               </td>
               <td>
                 <strong>{{ task.display_order_key ?? task.temporary_order_no ?? task.order_id }}</strong>
                 <small class="th-code">{{ task.order_id }}</small>
               </td>
-              <td>{{ task.card_name ?? task.task_type }}</td>
+              <td>{{ formatReservationTaskCard(t, task.task_type, task.card_name) }}</td>
               <td><ReservationStatusBadge :status="task.task_status" /></td>
               <td>
                 <span>{{ task.source_subject ?? t('taskList.noSourceSubject') }}</span>
@@ -153,7 +153,7 @@
               </td>
               <td>
                 <span>{{ task.queue_sequence ?? '-' }}</span>
-                <small>{{ task.can_process ? t('taskList.canProcess') : task.readonly_reason_code ?? '-' }}</small>
+                <small>{{ task.can_process ? t('taskList.canProcess') : formatReservationReadonlyReason(t, task.readonly_reason_code) }}</small>
               </td>
               <td>
                 <div class="row-actions">
@@ -233,6 +233,11 @@ import { useI18n } from 'vue-i18n'
 import ReservationStatusBadge from '@/components/reservation/ReservationStatusBadge.vue'
 import { fetchReservationTaskList } from '@/services/reservationService'
 import type { ReservationPageResult, ReservationTaskListFilters, ReservationTaskListItem } from '@/types/reservation'
+import {
+  formatReservationReadonlyReason,
+  formatReservationTaskCard,
+  formatReservationTaskTypeSummary,
+} from '@/utils/reservationDisplay'
 
 const { t } = useI18n()
 const loading = ref(false)
@@ -247,6 +252,7 @@ const filters = reactive<ReservationTaskListFilters>({
   keyword: '',
   task_type: '',
   task_status: '',
+  order_status: '',
   queue_participation: undefined,
   page_num: 1,
   page_size: 20,
@@ -289,6 +295,7 @@ function resetFilters(): void {
   filters.keyword = ''
   filters.task_type = ''
   filters.task_status = ''
+  filters.order_status = ''
   filters.queue_participation = undefined
   filters.page_num = 1
   filters.page_size = 20
diff --git a/docs/import/20260706/0630AI_副本 2/01_main_agent_prompt.md b/docs/import/20260706/0630AI_副本 2/01_main_agent_prompt.md
new file mode 100644
index 0000000..26e921a
--- /dev/null
+++ b/docs/import/20260706/0630AI_副本 2/01_main_agent_prompt.md	
@@ -0,0 +1,110 @@
+# 01 Main Agent Prompt
+
+你是预订部 AI 工作台的 Main Booking Agent。
+
+你负责：
+- 读取 SourceMessage。
+- 只从 body_current 中识别当前有效业务事件。
+- 将一封邮件拆分为一个或多个原始邮件事件，并分配 source_event_index。
+- 为每个事件提取路由级核心 key：group_code 和 confirmation_number。
+- 只围绕 group_code / confirmation_number 调用路由级只读 Tool。
+- 根据 Skill Catalog 选择并调用 Skill。
+- 按照具体 Skill 文档要求传入必要上下文。
+- 校验 Skill 输出是否符合 Unified Output Contract。
+- 汇总合格 Skill 输出到 ai_task_results 外层。
+
+路由级查询规则：
+- 第一版只查 group_code 和 confirmation_number。
+- Group / Allotment 使用 group_code。
+- Fit 使用 confirmation_number。
+- case_type 不确定时，只要邮件里有 group_code 或 confirmation_number，也必须先查。
+- 查询必须同时覆盖：
+  - 已写入操作结果的信息数据库；
+  - 待处理的任务数据库，用于确认同 key 是否已有 pending / open 的处理流程；
+  - 终止记录。
+- 不得仅因为 Opera 对象或已存在订单记录查不到，就输出 CASE_NOT_FOUND_GROUP 或 CASE_NOT_FOUND_FIT。
+- 在判断订单不存在前，必须检查同 key 是否存在 pending / open 的待处理任务或工作流。
+- 命中已有订单记录、待处理任务、工作流中间态或终止记录，本身不等于异常；具体业务结论由 Skill 输出。
+
+current / history 规则：
+- 你必须优先处理 body_current。
+- body_thread 只能作为 evidence_context。
+- 不能从 body_thread 生成 normal_task。
+- 如果可执行业务动作来自 body_current，body_thread 可以作为绑定目标对象的 evidence_context，例如补充唯一 `group_code`、父 group、上游 New Booking / Allotment 任务或最近相关酒店确认段；这种情况不是“从 history 生成 normal_task”，但必须在 Skill 输入和输出中标记 target key 来源。
+- 如果 body_current 明确没有新的业务动作但仍需用户可见，应路由到 `message_notification_skill` 输出 informational_message。
+- 如果无法判断是消息通知还是业务动作，应路由到 `exception_detection_skill` 输出 structured manual_review。
+- 如果一封邮件包含多个当前有效动作或多个订单，应拆分为多个原始邮件事件。
+- source_event_index 从 1 开始，表示主控从原始邮件中拆出的原始事件序号。
+- 派生任务不由主控 Agent 生成，派生任务由对应 Skill 或后续系统流程处理。
+
+Skill 路由规则：
+- 你必须根据 Skill Catalog 的 when_to_use / must_not_use_when 选择 Skill。
+- 不得只根据标题关键词机械选择 Skill。
+- 对 QBD / LianTai / 旅行社语境下的 `AMEND + FINAL BOOKING`，如果 body_current 实质是在把父团拆成多个子 `group_code` 并给出每个子 code 的日期、房型和房量，用酒店系统的处理口径视为新建配合房 / Allotment / Control Block；应优先路由到 S01 New Booking，而不是因为 `AMEND` 字样机械路由到 S02。
+- 如果多个独立 current 事件存在，应拆分并分别调用 Skill。
+- 如果同一个 current 事件需要多个 Skill 协作，可以调用多个 Skill，但不得合并或改写它们的业务结论。
+- 如果多个 Skill 对同一 current 事件输出冲突，应调用 exception_detection_skill 或输出 manual_review。
+- 如果 current 事件明确是 thank you、FYI、acknowledgement、noted、received、confirmed receipt、转发说明或仅同步信息，且没有新的可执行业务动作，调用 `message_notification_skill`。
+- 如果无法安全路由，调用 `exception_detection_skill`。
+
+Skill 输入规则：
+- 你不得在主控 Agent 中固定所有 Skill 的详细输入字段。
+- 你必须根据 Skill Catalog 选择具体 Skill。
+- 选择 Skill 后，按照该 Skill 文档定义的 input_schema / input_requirements 组装输入。
+- 只向 Skill 传递完成该 Skill 判断所需的信息。
+- current 事件信息只能来自 body_current。
+- body_thread、历史附件、系统查询结果只能作为 evidence_context 提供给 Skill。
+- source_message_id 和 source_event_index 属于通用溯源字段，必须传给 Skill，并由 Skill 原样带回。
+- 路由级查询结果可以传给 Skill，但 Skill 是否使用、如何使用，由 Skill 自己的规则决定。
+
+Skill 输出处理：
+- Skill 必须输出完整 ai_task_result 单项。
+- 你只做 schema validation 和汇总。
+- QBD / LianTai Excel 或 table workflow 如果识别出 N 个当前有效黄色 / 高亮行，最终 `ai_task_results` 必须有 N 个独立结果；不得用单个结果里的 `source_event_count`、数组型 `case_keys.group_code` 或汇总型 `highlighted_rows` 代替。
+- QBD / LianTai 每个当前有效行的结果必须有独立 `source_event_index`、独立 `case_keys`、独立 `extracted_fields.table_evidence`；一个不完整行只能影响该行输出 `manual_review`，不能阻塞其他行。
+- 受控例外：如果同一 current event / 同一 QBD / LianTai 行同时包含 S01 / S02 / S06 主业务动作和 Trace / Guest Request / extra bed，应生成主业务 `ai_task_result` 和 S07 linked `ai_task_result`；用 `parent_source_event_index`、`linked_task_group_id`、`execution_order` 表达同源关系。
+- 如果 Skill 输出违反上述逐行拆分规则，应视为 schema validation 不合格，使用同一 input 重试该 Skill 一次。
+- 你不得补 source_message_id。
+- 你不得补 result_id。
+- 你不得补业务字段。
+- 你不得统一枚举值。
+- 你不得改写 result_type、task_type、exception_type。
+- 你不得把一个 Skill 的业务结论改成另一个业务结论。
+- 如果 Skill 输出不合格，使用同一 input 重试该 Skill 一次。
+- 如果仍失败，调用 exception_detection_skill。
+- 如果仍失败，输出 manual_review 或 extraction_warnings。
+- 不得自行修补 Skill 输出。
+
+禁止事项：
+- 不能从 body_thread 生成 normal_task。
+- 不创建真实 TaskCard。
+- 不写 Opera。
+- 不生成 Receipt。
+- 不确认 Payment。
+- 不修改数据库。
+- 不调用写入类工具。
+- 不生成派生任务。
+- 不维护具体任务类型高风险规则。
+- 不维护 Rate Code 规则、Room Type Mapping、Payment 默认值、Supplier 表达规则。
+- 各任务类型的高风险规则由对应 Skill 负责。
+
+最终只输出 JSON：
+
+```json
+{
+  "source_message_id": "",
+  "ai_task_results": [],
+  "extraction_warnings": []
+}
+```
+
+不要输出：
+- 解释文字
+- 推理过程
+- chain-of-thought
+- confidence
+- rule source
+- Skill 调用过程日志
+- 真实 TaskCard
+- Receipt
+- Opera 写入结果
diff --git a/docs/import/20260706/0630AI_副本 2/02_agent_workflow.md b/docs/import/20260706/0630AI_副本 2/02_agent_workflow.md
new file mode 100644
index 0000000..edb428c
--- /dev/null
+++ b/docs/import/20260706/0630AI_副本 2/02_agent_workflow.md	
@@ -0,0 +1,139 @@
+# 02 Agent Workflow
+
+本文说明 Main Agent 处理一封 SourceMessage 时的标准执行流程。
+
+本文件不是 Prompt，不定义具体业务 Skill 的字段规则，也不定义具体任务类型的业务判断规则。
+
+## 1. 核心原则
+
+- Main Agent 必须先区分 current / history，再判断任务。
+- Main Agent 只能从 body_current 识别当前有效业务事件。
+- body_thread 只能作为 evidence context。
+- 不能从 body_thread 生成 normal_task。
+- 当 body_current 已经提供当前可执行业务动作时，body_thread 可以作为 evidence context 补充唯一目标 key、父 group、上游任务或最近相关确认段；这不等于从 body_thread 触发任务，输出中应保留 target key 来源。
+- Main Agent 第一版只围绕 group_code / confirmation_number 做路由级查询。
+- Main Agent 根据 Skill Catalog 选择 Skill。
+- Skill 负责业务判断和完整 ai_task_result 输出。
+- Main Agent 只做 schema validation 和结果汇总，不修补 Skill 输出。
+
+## 2. 关键执行顺序
+
+1. 读取 SourceMessage。
+2. 区分 body_current 和 body_thread。
+3. 判断 body_current 是否包含当前有效业务动作。
+4. 将 body_current 中的当前有效业务动作拆分为一个或多个原始邮件事件。
+5. 为每个原始邮件事件分配 source_event_index，从 1 开始。
+6. 为每个原始邮件事件提取路由级核心 key：group_code 和 confirmation_number。
+7. 如果能提取到 group_code 或 confirmation_number，调用路由级只读 Tool 查询上下文。
+8. 如果两个 key 都提取不到，routing_context 为空，继续按邮件语义尝试选择 Skill。
+9. 根据 Skill Catalog 的 when_to_use / must_not_use_when 选择具体 Skill。
+10. 按具体 Skill 文档定义的 input_schema / input_requirements 组装 Skill 输入。
+11. 调用 Skill。
+12. 校验 Skill 输出是否符合 Unified Output Contract。
+13. 如果 Skill 输出合格，将该结果加入 ai_task_results。
+14. 如果一封邮件有多个原始事件，重复步骤 6 到 13。
+15. 汇总所有合格结果，输出统一 JSON。
+
+## 3. 路由级查询流程
+
+Main Agent 第一版只查询：
+
+- group_code
+- confirmation_number
+
+查询规则：
+
+- Group / Allotment 使用 group_code。
+- Fit 使用 confirmation_number。
+- 如果邮件里两个 key 都出现，两个都传给只读 Tool。
+- 如果 case_type 暂时无法判断，但能提取到任一 key，也必须先查。
+- Allotment 第一版不单独设计 allotment_key。
+
+查询结果应作为 routing_context 传给 Skill。
+
+routing_context 至少应覆盖：
+
+- 已写入操作结果的信息数据库。
+- 待处理的任务数据库。
+- 终止记录。
+
+查询结果只作为上下文，不直接等于最终业务结论。
+
+## 4. 分支规则
+
+| 场景 | Main Agent 处理方式 |
+|---|---|
+| body_current 明确没有新的业务动作但需要用户可见 | 路由到 `message_notification_skill` 输出 informational_message；不能从 body_thread 生成 normal_task |
+| 无法判断是消息通知还是业务动作 | 路由到 `exception_detection_skill` 输出 structured manual_review |
+| 业务动作只出现在 body_thread | 不生成 normal_task；body_thread 只能作为 evidence context |
+| body_current 有备注 / Guest Request 动作，目标 key 只在 body_thread 的最近相关线程中清晰出现 | 可以把 body_thread 作为 evidence context 传给对应 Skill 绑定目标；不得把 history 中的旧动作当成 current 动作 |
+| body_current 有多个独立业务事件 | 拆分为多个 source_event_index，分别选择 Skill |
+| body_current 有多个订单 | 拆分为多个 source_event_index，分别处理 |
+| QBD / LianTai / 旅行社 current 文本为 `AMEND + FINAL BOOKING`，但实质是父团拆成多个子 group_code 的配合房 / Allotment 创建 | 按子 group_code 拆分为 S01 New Booking / Allotment 事件；父团号作为 parent_group_code evidence；不得仅因 `AMEND` 字样强制走 S02 |
+| QBD / LianTai Excel 或 table workflow 有多个当前有效黄色 / 高亮行 | 按行拆分为多个 source_event_index；一行一个 ai_task_result；不得跨行合并 |
+| 同一 current event / 同一 QBD / LianTai 行同时包含 S01 / S02 / S06 主业务动作和 Trace / Guest Request / extra bed | 生成主业务 ai_task_result 和 S07 linked ai_task_result；主任务先执行，S07 后执行；用 parent_source_event_index / linked_task_group_id / execution_order 表达同源关系 |
+| QBD / LianTai 多行结果被合并到单个 ai_task_result | 视为 Skill 输出不符合 schema；用同一 input 重试该 Skill 一次 |
+| 找不到 group_code / confirmation_number | routing_context 为空；仍可按邮件语义选择 Skill；不确定则 manual_review |
+| 查不到已写入订单记录，但查到待处理任务或工作流 | 不得直接输出 CASE_NOT_FOUND；将上下文交给 Skill 判断 |
+| 查不到已写入订单记录，也查不到待处理任务或工作流 | 将查询结果交给 Skill；是否输出 CASE_NOT_FOUND 由 Skill 判断 |
+| 命中终止记录 | 将终止上下文交给对应 Skill；明确轻量消息走 S10 informational_message，边界不清走 S99 manual_review |
+| 多个 Skill 都可能适用 | 优先使用 Skill Catalog 的 must_not_use_when 排除；仍冲突则调用 exception_detection_skill 或 manual_review |
+| 多个 Skill 对同一事件输出冲突 | 调用 exception_detection_skill 或输出 manual_review |
+| Skill 输出不符合 schema | 使用同一 input 重试该 Skill 一次 |
+| Skill 重试后仍不合格 | 调用 exception_detection_skill |
+| exception_detection_skill 仍无法处理 | 输出 manual_review 或 extraction_warnings |
+
+## 5. Skill 输入流程
+
+Main Agent 不固定所有 Skill 输入字段。
+
+处理方式：
+
+1. 先根据 Skill Catalog 选择 Skill。
+2. 读取该 Skill 的 input_schema / input_requirements。
+3. 只传该 Skill 完成判断所需的信息。
+4. source_message_id 和 source_event_index 必须传入。
+5. current 事件信息只能来自 body_current。
+6. body_thread、历史附件、系统查询结果只能作为 evidence context；如果 current 动作明确，它们可以帮助绑定目标对象或父任务，但不能单独触发任务。
+7. 路由级查询结果可以传入 Skill，但是否使用由 Skill 自己决定。
+
+## 6. Skill 输出处理流程
+
+Skill 必须输出完整 ai_task_result 单项。
+
+Main Agent 只做：
+
+- schema validation；
+- 收集合格结果；
+- 汇总到 ai_task_results 外层。
+
+Main Agent 不做：
+
+- 不补 source_message_id；
+- 不补 result_id；
+- 不补业务字段；
+- 不统一枚举值；
+- 不改写 result_type / task_type / exception_type；
+- 不把一个 Skill 的业务结论改成另一个业务结论。
+
+## 7. 最终输出
+
+Main Agent 最终只输出统一 JSON：
+
+```json
+{
+  "source_message_id": "",
+  "ai_task_results": [],
+  "extraction_warnings": []
+}
+```
+
+不得输出：
+
+- 解释文字；
+- 推理过程；
+- chain-of-thought；
+- Skill 调用日志；
+- 真实 TaskCard；
+- Opera 写入结果；
+- Receipt。
diff --git a/docs/import/20260706/0630AI_副本 2/03_skill_catalog.md b/docs/import/20260706/0630AI_副本 2/03_skill_catalog.md
new file mode 100644
index 0000000..474e285
--- /dev/null
+++ b/docs/import/20260706/0630AI_副本 2/03_skill_catalog.md	
@@ -0,0 +1,1220 @@
+# 03 Skill Catalog
+
+## 1. 定位
+
+本文是预订部 AI 工作台的 Skill 路由索引 / 目录。
+
+它回答的问题是：
+
+- 当前 `body_current` 邮件事件应该路由到哪个 Skill。
+- 哪些场景不能路由到某个 Skill。
+- 该 Skill 第一版允许输出哪些 `result_type`。
+- Main Agent 至少应准备哪些上下文。
+- 路由冲突或无法安全判断时应如何兜底。
+
+本文不写：
+
+- 具体业务字段抽取规则。
+- 完整 `ai_task_result` 输出 schema。
+- PMS / Opera 写入规则。
+- 任务卡 API 的真实 endpoint、鉴权、返回结构。
+- 具体字段标准化、房型映射、Rate Code 规则、价格规则。
+
+详细业务规则和输出细节应写在具体 Skill 文档中。
+
+## 2. 第一版全局结果类型
+
+第一版全局只使用以下结果类型：
+
+- `normal_task`
+- `manual_review`
+- `informational_message`
+
+第一版不使用：
+
+- `exception_task`
+- `no_action`
+
+原因：
+
+- `exception_task` 暂缓引入，避免早期异常枚举膨胀。
+- `no_action` 暂不使用，避免进入 AI 工作台的 current 邮件事件被系统静默吞掉。
+- 即使是 thank you、FYI、acknowledgement、仅确认收到等邮件，也应生成用户可见记录。
+
+### 2.1 normal_task
+
+`normal_task` 表示当前邮件事件有明确、可执行、可自动创建任务卡的业务动作。
+
+使用要求：
+
+- 当前动作必须来自 `body_current`。
+- 必须能确认任务类型。
+- 必须能确认最低溯源信息。
+- 必须经过对应 Skill 的业务判断。
+- Skill 不直接写数据库、不写 Opera、不直接执行真实业务动作。
+
+### 2.2 manual_review
+
+`manual_review` 表示当前邮件事件与业务相关，但不能安全自动处理，需要创建结构化人工复核 / 人工处理卡。
+
+`manual_review` 不是空泛的“人工看一下”。凡允许输出 `manual_review` 的 Skill，默认必须遵守统一输出契约；如果具体 Skill 文档基于最新确认口径明确采用精简结构，以该 Skill 文档为准。
+
+- 能确定的 `case_keys` 必须填入。
+- 能确定的 subtype / object_type 应填入 `extracted_fields`。
+- 能确定的业务字段应尽量填入 `extracted_fields`。
+- 不能可靠确认的字段不得编造，应填 `null`、空字符串或空数组。
+- 必须说明人工处理原因。
+- 必须说明阻断点、缺失字段、冲突点。
+- 默认应给出建议人工动作。
+- 默认应给出建议人工检查的证据位置。
+
+Catalog 不定义完整 schema，但具体 Skill 文档应至少覆盖这些语义：
+
+- `manual_review.reason_code`
+- `manual_review.visible_reason`
+- `manual_review.blocking_points`
+- `manual_review.missing_fields`
+- `manual_review.conflicting_points`
+- `manual_review.suggested_human_actions`
+- `manual_review.evidence_to_check`
+- `manual_review.review_record_type`
+
+当前已确认的例外：
+
+- S04 `voucher_received_skill` 的 `manual_review` 使用精简结构，不包含 `suggested_human_actions` 和 `evidence_to_check`。
+- S05 `rooming_list_name_list_skill` 的 `manual_review` 使用精简结构，不包含 `suggested_human_actions`，但仍保留 `evidence_to_check`。
+
+### 2.3 informational_message
+
+`informational_message` 表示当前邮件没有可执行业务任务，但仍需要用户知晓。
+
+适用场景包括：
+
+- thank you
+- FYI
+- acknowledgement
+- 仅确认收到
+- 无新业务动作但有沟通价值的 current 邮件
+
+`informational_message` 最终应对应一种轻量级用户可见卡片，例如信息提醒卡。
+
+注意：
+
+- `informational_message` 是 result type，不是普通业务任务。
+- 如果当前邮件没有可执行业务动作，不应硬路由到 New / Update / Cancel 等业务 Skill。
+- 这类邮件应由 `message_notification_skill` 输出 `informational_message`。
+
+## 3. 统一 Tool 占位
+
+Catalog 不为每个 Skill 设计专用任务卡创建 Tool。
+
+统一预留：
+
+- `suggested_tool_name: create_task_card / TBD`
+
+`tool_purpose`：
+
+- 根据 `result_type` 创建普通任务卡、人工复核卡、信息提醒卡或其他用户可见记录。
+
+调用原则：
+
+- Skill 输出 `ai_task_result` 并通过统一输出校验后，由 Main Agent、AI Runtime、Skill Orchestrator 或信息系统调用统一 Tool / API。
+- Skill 能解析出的字段照实传给统一 Tool。
+- Skill 解析不出的字段传 `null`、空字符串或空数组。
+- 前端或信息系统可根据缺失字段提示用户补充或确认。
+
+Catalog 只定义 Tool 方向，不定义真实 API。
+
+统一 payload 至少应覆盖这些溯源与展示字段：
+
+- `source_message_id`
+- `source_event_index`
+- `catalog_code`
+- `skill_id`
+- `result_type`
+- `task_type`
+- `case_keys`
+- `visible_reason`
+- `relevant_message_excerpt`
+- `attachments`
+- `context_used`
+- `extracted_fields`
+- `manual_review`
+- `informational_message`
+- `idempotency_key / TBD`
+
+如某个业务 Skill 输出 `additional_operations` 或 `fix_charge_items`，这些字段也应随 `extracted_fields` 传入统一任务卡 Tool，由信息系统在后续真实业务执行阶段处理。
+
+`must_not_call_when`：
+
+- Skill 输出不符合统一契约。
+- current 事件完全不应进入 AI 工作台记录。
+- 输出内容缺少创建用户可见记录所需的最低溯源字段。
+
+## 4. 全局路由原则
+
+Main Agent 路由前应先做这些判断：
+
+1. 确认业务动作是否来自 `body_current`。
+2. 将 `body_thread` 仅作为 evidence context，不作为生成 `normal_task` 的来源。
+   - 如果业务动作来自 `body_current`，`body_thread` 可以作为 target binding evidence，补充唯一 `group_code`、parent group、上游任务或最近相关酒店确认段；输出中必须记录 target 来源。
+3. 如果一封邮件包含多个 current 业务事件，应拆成多个 `source_event_index`。
+4. 如果 QBD / LianTai Excel 或 table workflow 有多个当前有效黄色 / 高亮行，必须按行拆成多个 `source_event_index`，最终一行一个 `ai_task_result`。
+5. 尽量提取 `group_code`、`confirmation_number`、日期、房量、对象类型等路由线索。
+6. 能提取 key 时，应查询并传入 `routing_context`。
+7. 根据本 Catalog 的 `when_to_use` / `must_not_use_when` 选择 Skill。
+8. 如果多个 Skill 冲突且无法安全拆分，走兜底路由生成结构化 `manual_review`。
+9. 如果 current 邮件明确没有可执行业务动作但需要用户可见，走 `message_notification_skill` 生成 `informational_message`。
+10. 如果无法判断 current 邮件是消息通知还是业务动作，或存在路由冲突 / current-history 边界不清，走 `exception_detection_skill` 生成 structured `manual_review`。
+
+`body_current` 与 `body_thread` 的边界优先级高于业务关键词。
+
+例如，历史引用里的 cancel / CXL / amendment 不应直接生成当前任务。
+
+### 4.0 QBD / LianTai Row Split Output Validation
+
+当 QBD / LianTai 当前有效黄色 / 高亮行数为 N 时，统一输出校验必须确认：
+
+- 顶层 `ai_task_results.length` 等于 N，除非某些行因不可读而各自输出 structured `manual_review`。
+- 每个当前有效行都有独立 `source_event_index`、独立 `case_keys`、独立 `extracted_fields.table_evidence`。
+- 不得用单个 `ai_task_result.extracted_fields.source_event_count`、数组型 `case_keys.group_code`、汇总型 `highlighted_rows` 或汇总型 `room_items` 代替多个 `ai_task_results`。
+- 某一行信息缺失或冲突时，只该行输出 structured `manual_review`，不得阻塞其他可安全处理的行。
+- 违反本节即视为 Skill 输出不符合统一契约，Main Agent 应按 workflow 重试一次。
+
+受控例外：
+
+- 如果同一 current event / 同一表格行同时包含 S01 / S02 / S06 主业务动作和 Trace / Guest Request / extra bed，应生成主业务任务和 S07 linked task。
+- 主业务任务先执行，S07 linked task 后执行。
+- 不得把主业务任务和 S07 合并成一个 `ai_task_result`。
+- 如果 `source_event_index` 只能使用整数，S07 linked task 使用新的整数 index，并通过 `parent_source_event_index`、`linked_task_group_id`、`execution_order` 表达同源关系。
+
+### 4.1 Extra Bed / Guest Request Routing Rule
+
+Extra bed / 加床 / `เตียงเสริม` 属于 Trace / Guest Request 类信息，不属于房型、房量或 Rate Code 判断字段。
+
+全局规则：
+
+- 不计入 `room_quantity`。
+- 不影响 FIT / Group 判断。
+- 不作为独立房型映射。
+- 不单独决定 Rate Code。
+- `U-เตียงเสริม` 不是 PMS 房型。
+- S07 中 extra bed 固定输出 `trace_subtype=extra_bed`、`trace_text=Set Extrabed`、`notify_departments=["FO","HSK"]`、`occupancy_update=3adult`、`requires_rate_update=true`、`rate_adjustment_formula=rate_code_price / 2 * 3`。
+- S07 只输出加床操作意图，不自行决定 Rate Code，不猜 `rate_code_price`，不自行计算最终房价。
+
+路由规则：
+
+- 如果 extra bed 与 New Booking 同一 current 事件 / 同一表格行出现，主任务走 `new_booking_skill`，同时生成 S07 linked task；先处理 S01，再处理 S07。
+- 如果 extra bed 与 Update Booking 同一 current 事件 / 同一表格行出现，主任务走 `update_booking_amendment_skill`，同时生成 S07 linked task；先处理 S02，再处理 S07。
+- 如果 extra bed 与 Amend Group Code 同一 current 事件 / 同一表格行出现，主任务走 `amend_group_code_skill`，同时生成 S07 linked task；先处理 S06，再处理 S07。
+- 如果 current 邮件仅要求为既有订单添加、修改或取消 extra bed / 加床 / `เตียงเสริม`，走 `trace_reservation_notes_skill`。
+- 如果 Cancel Booking / CXL 行中只是历史或被取消对象上的 extra bed，不默认生成 S07；除非 current 明确要求取消后仍需记录某条 note / trace。
+- 不得把 extra bed 数量计入房量，也不得用于 FIT / Group 判断。
+
+### 4.2 Fix Charge / Composite Unit Price Routing Rule
+
+Fix Charge / 固定费用不是第一版独立任务类型。它是 New Booking 或 Update Booking 的附加收费能力。
+
+全局规则：
+
+- 不因为 `TWN` / `DBL` / 普通房型本身触发 Fix Charge。
+- 不因为普通价格如 `2000THB`、`1800THB` 本身触发 Fix Charge。
+- 当 LianTai 表格酒店说明或 current 事件价格区出现可拆分的复合单价结构，例如 `2000THB+500`、`1800THB+500`、`2000THB*2` 换行后 `+附加500*2`，才识别 Fix Charge。
+- `+` 前的房费单价组件用于 Rate Code 判断；`+` 后的附加费用单价组件写入 `extracted_fields.fix_charge_items`。
+- 不得把 `2000+500` 合并为 `2500` 判断 Rate Code。
+- Fix Charge 金额不固定，不得用 `500` 这个数字本身作为触发条件。
+- AI 不负责从该表达计算数量或总额；如表达包含 `*数量`，可作为原文证据保留，但不强制计算。
+
+路由规则：
+
+- 如果 Fix Charge 与 New Booking 同一 current 事件 / 同一表格行出现，主路由仍走 `new_booking_skill`。
+- 如果 Fix Charge 与 Update Booking 同一 current 事件 / 同一表格行出现，主路由仍走 `update_booking_amendment_skill`，可标记 `update_fix_charge`。
+- 如果 current 邮件只要求为既有订单添加、修改或取消 Fix Charge，且目标订单和动作明确，第一版可路由到 `update_booking_amendment_skill`；如果目标订单或动作不清，输出 structured `manual_review`。
+- 如果没有复合单价或附加费组件，仍按既有房型 / Rate Code 规则正常处理，不因缺少 Fix Charge 输出 `manual_review`。
+
+## 5. Catalog Entry 字段
+
+每个 Skill 条目建议包含：
+
+- `catalog_code`
+- `skill_id`
+- `skill_name`
+- `task_type`
+- `status`
+- `supported_subtypes`
+- `when_to_use`
+- `must_not_use_when`
+- `allowed_result_types`
+- `key_context_needed`
+- `input_requirements_summary`
+- `conflict_or_fallback_rule`
+- `tool_placeholder`
+
+如果某个字段暂时不需要，可写 `TBD` 或说明暂不适用。
+
+## 6. Active Skills
+
+以下三个 Skill 是当前 active 核心业务 Skill。
+
+### S01 New Booking Skill
+
+`catalog_code`: `S01`
+
+`skill_id`: `new_booking_skill`
+
+`skill_name`: `New Booking Skill`
+
+`task_type`: `New Booking`
+
+`status`: `active`
+
+`supported_subtypes`:
+
+- `new_fit_reservation`
+- `new_group_block`
+- `new_allotment_control_block`
+
+`reference_files`:
+
+- `skill/S01_new_booking_skill/references/room_type_mapping_rules.md`
+- `skill/S01_new_booking_skill/references/rate_code_rules.md`
+- `references/qbd_liantai_email_table_rules.md`
+
+说明：
+
+- Catalog 不展开房型映射表或 Rate Code 规则。
+- 当 S01 涉及房型、房型代码、Rate Code、结算价格、渠道 / 市场类别、早餐或用餐餐厅时，具体 Skill 应读取对应 reference。
+- 房型代码必须来自 room type mapping reference 的唯一命中；Rate Code reference 可以引用 `pms_room_type_code`，但不能作为房型映射唯一来源。
+- `ST+K:2卧1厅=1200` + `FAMILY 1` 是跨 QBD / LianTai 渠道可识别的房型表达；房型映射可命中 `SU3`，Rate Code 必须按渠道分别判断。
+- 当 current 邮件、附件、发件人、主题或抽取证据显示 QBD / LianTai Excel/table workflow 时，具体 Skill 应读取 shared reference，判断高亮 / 黄色行、表格行证据和 FIT / Group / Allotment 对象路径。
+- QBD / LianTai / 旅行社语境下，`AMEND + FINAL BOOKING` 不必然是 S02 Update。如果 body_current 实质是在父团下创建多个子 `group_code` 的配合房 / Allotment，并逐个给出日期、房型和房量，应按 S01 New Booking / Allotment 处理。
+- 如果 extra bed / 加床 / `เตียงเสริม` 与 New Booking 同一事件或同一表格行出现，主任务仍走 S01，同时生成 S07 linked task；extra bed 不计入房量，不影响 FIT / Group，不做房型映射，不单独决定 Rate Code。
+- 如果 LianTai 复合单价表达与 New Booking 同一事件或同一表格行出现，主任务仍是 New Booking；具体 Skill 应在 `extracted_fields.fix_charge_items` 中保留 Fix Charge 单价组件，并在 `additional_operations` 中标记待后续执行的 Fix Charge 操作。
+- reference 无法唯一命中时，不由 Main Agent 猜测，应交给 S01 输出结构化 `manual_review` 或明确的手工价格维护任务。
+
+`when_to_use`:
+
+当前 `body_current` 明确提出创建新的预订对象时使用。
+
+覆盖对象：
+
+- FIT Reservation
+- Group Block
+- Allotment / Control Block 类新建控房订单
+- 配合房 / 取配 / parent-to-child allocation 创建；包括 current 文本写作 `AMEND + FINAL BOOKING`，但实质是在父团下创建多个子 group code 的房量分配
+
+`must_not_use_when`:
+
+- 当前邮件是在修改既有订单。
+- 当前邮件是在取消订单、Group Block、控房、配额、Allotment 或 Control Block。
+- 当前邮件只是提交 Rooming List / Name List。
+- 当前邮件只是收到 Voucher、Credit Voucher、payment slip 或 payment confirmation。
+- 当前邮件只是添加 Trace、Reservation Notes 或 Guest Request。
+- 当前邮件只是为既有订单添加、修改或取消 extra bed / 加床 / `เตียงเสริม`，且没有新建预订动作。
+- 当前邮件只是修改 Group Code、Block Code、Block Name 或 Group Name。
+- 新建预订动作只出现在 `body_thread`。
+- 当前邮件只是 thank you、FYI、acknowledgement、noted、received、confirmed receipt、确认收到、转发说明、仅同步信息或无新业务动作。
+
+`allowed_result_types`:
+
+- `normal_task`
+- `manual_review`
+
+`must_not_result_types`:
+
+- `exception_task`
+- `no_action`
+- `informational_message`
+
+`key_context_needed`:
+
+- `source_message_id`
+- `source_event_index`
+- `group_code`
+- `confirmation_number`
+- 房间数
+- 入住 / 离店日期
+- 客人姓名、团队名称或 block 名称
+- supplier / sender 线索
+- 当前附件摘要
+- 房型原文、床型、人数、是否套房、是否家庭房等房型映射线索
+- 渠道 / 市场类别、supplier、备注价格、是否含早餐、用餐餐厅、实际结算价格等 Rate Code 判断线索
+- extra bed / 加床 / `เตียงเสริม` 等 Trace / Guest Request 线索
+- LianTai 复合单价、附加费、Fix Charge 原文线索
+- `routing_context`
+
+`input_requirements_summary`:
+
+Main Agent 应传入当前新建请求摘要、`body_current` 原文片段、附件摘要、已提取核心 key、路由查询结果、与新建判断直接相关的基础业务字段，以及能帮助房型映射、Rate Code 判断、Fix Charge 识别或手工结算价格维护的上下文线索。
+
+`conflict_or_fallback_rule`:
+
+如果当前事件明确是 New Booking，且 routing context 未发现同 key 有效订单、pending/open task、active workflow 或终止冲突，输出 `normal_task`。
+
+如果 current 文本为 parent-to-child 配合房 / Allotment 创建，应按 child group code 拆分多个 S01 结果；父 group code 作为 `parent_group_code` evidence，不作为单个 S02 修改目标。
+
+如果同 key 已存在已完成 / 已写入的 FIT Reservation、Group Block、Allotment / Control Block 或其他有效订单记录，不得继续创建 New Booking，应输出结构化 `manual_review`。
+
+如果同 key 已有 pending / open task、active workflow、对象类型不清、关键信息缺失、current/history 边界不清、房型映射 reference 无法唯一命中、Rate Code reference 无法唯一命中、结算价格无法可靠确认，也输出结构化 `manual_review`。
+
+如果 Rate Code 无可选代码但 reference 明确允许手工结算价格维护，且业务动作来自 `body_current`、routing context 不阻断、房型唯一映射、核心日期 / 房量 / 对象类型可靠、价格来自 `body_current` 或当前表格行并可可靠提取，S01 可输出 `normal_task`；输出必须包含 `rate_code=null`、`settlement_price`、`manual_settlement_price_required=true`、`manual_price_reason_code`、`price_evidence`。任一条件不满足则输出结构化 `manual_review`。
+
+如果当前事件只是为既有订单添加、修改或取消 extra bed / 加床 / `เตียงเสริม`，不进入 S01；应路由到 `trace_reservation_notes_skill`。
+
+如果当前事件包含 LianTai 复合单价表达，S01 应按 reference 拆分房费单价和 Fix Charge 单价；没有复合单价时，继续按既有房型 / Rate Code 规则处理。
+
+如果当前邮件不是新建预订，而是明确的信息提醒类邮件，不进入本 Skill，应由 `message_notification_skill` 输出 `informational_message`。
+
+`tool_placeholder`:
+
+- `suggested_tool_name: create_task_card / TBD`
+- 通过统一 Tool 创建普通 New Booking 任务卡或结构化人工复核卡。
+- 如 `extracted_fields.fix_charge_items` 非空，任务卡 payload 应保留后续 `create_fix_charge / TBD` 操作信息；真实 Fix Charge Tool 只能在 New Booking 创建成功并取得订单 ID 后执行。
+
+### S02 Update Booking / Amendment Skill
+
+`catalog_code`: `S02`
+
+`skill_id`: `update_booking_amendment_skill`
+
+`skill_name`: `Update Booking / Amendment Skill`
+
+`task_type`: `Update Booking`
+
+`status`: `active`
+
+`supported_subtypes`:
+
+- `update_stay_dates`
+- `update_nights`
+- `update_room_type_or_quantity`
+- `update_guest_count`
+- `update_trace_or_guest_request`
+- `update_group_block_linkage`
+- `update_allotment_control_block`
+- `manual_rate_code_or_settlement_price`
+- `update_fix_charge`
+
+说明：
+
+- subtype 只用于识别修改内容、测试覆盖、任务卡展示和 payload 结构化。
+- subtype 不拆成多个 Tool。
+- 原 `update_pax` 命名调整为 `update_guest_count`。
+- `update_group_block_linkage` 不覆盖旧 Group Code 改为新 Group Code 的 `AMEND GROUP CODE` 事件；这类事件由 S06 处理。
+- `update_trace_or_guest_request` 只用于标记 Trace / Guest Request 与其他核心 Update 同一 current 事件出现时的后台线索；独立 Trace / Reservation Notes / Guest Request 任务应走 S07。
+
+`reference_files`:
+
+- `skill/S02_update_booking_amendment_skill/references/room_type_mapping_rules.md`
+- `skill/S02_update_booking_amendment_skill/references/rate_code_rules.md`
+- `references/qbd_liantai_email_table_rules.md`
+
+说明：
+
+- Catalog 不展开房型映射表或 Rate Code 规则。
+- 当 S02 涉及房型、房型代码、Rate Code、结算价格、渠道 / 市场类别、早餐或用餐餐厅时，具体 Skill 应读取对应 reference。
+- 房型代码必须来自 room type mapping reference 的唯一命中；Rate Code reference 可以引用 `pms_room_type_code`，但不能作为房型映射唯一来源。
+- `ST+K:2卧1厅=1200` + `FAMILY 1` 是跨 QBD / LianTai 渠道可识别的房型表达；房型映射可命中 `SU3`，Rate Code 必须按渠道分别判断。
+- 当 current 邮件、附件、发件人、主题或抽取证据显示 QBD / LianTai Excel/table workflow 时，具体 Skill 应读取 shared reference，判断高亮 / 黄色行、QBD 当前行选择、LianTai 酒店列日期、划线 before / after、AMD/CXL/CFM 状态证据和 FIT / Group 路径。
+- 如果 extra bed / 加床 / `เตียงเสริม` 与 Update Booking 同一事件或同一表格行出现，主任务仍走 S02，同时生成 S07 linked task；extra bed 不计入房量、不作为房型映射、不单独决定 Rate Code。
+- 如果 LianTai 复合单价表达或明确 Fix Charge 维护与 Update Booking 同一事件或同一表格行出现，可标记 `update_fix_charge`；没有复合单价或附加费组件时，继续按既有房型 / Rate Code 规则处理，不因此输出 `manual_review`。
+- reference 无法唯一命中时，不由 Main Agent 猜测，应交给 S02 输出结构化 `manual_review` 或明确的手工价格维护任务。
+
+`when_to_use`:
+
+当前 `body_current` 要求修改既有订单、既有 Group Block、既有控房 / 配额 / Allotment / Control Block 时使用。
+
+典型修改包括：
+
+- 更新入住 / 离店日期。
+- 更新晚数。
+- 更新房型 / 房量。
+- 更新人数 / 客人人数。
+- 与上述核心修改同一事件出现的备注 / Trace / Guest Request；该类内容还应生成 S07 linked task。
+- 更新 confirmation / group / block 关联，但不包括旧 Group Code 改为新 Group Code 的 Amend Group Code 事件。
+- 维护既有控房 / 配额 / Control Block 的日期、房型、房量。
+- 手工维护 Rate Code / 实际结算价格。
+- 新增、修改或取消既有订单的 Fix Charge / 固定费用。
+
+`must_not_use_when`:
+
+- 当前邮件是在全新创建预订，应走 `new_booking_skill`。
+- 当前邮件虽然含 `AMEND` / `AMEND + FINAL BOOKING`，但实质是在父团下创建多个子 `group_code` 的配合房 / Allotment；应走 `new_booking_skill`。
+- 当前邮件是在取消 FIT、Group Block、Allotment 或 Control Block，应走 `cancel_booking_skill`。
+- 当前邮件只是提交 Rooming List / Name List。
+- 当前邮件只是收到 Voucher、Credit Voucher、payment slip 或 payment confirmation。
+- 当前事件明确包含旧 Group Code 改为新 Group Code 的 Amend Group Code 动作；若该动作与日期、晚数、房型、房量、人数、价格等修改属于同一不可拆分事件，主任务应走 `amend_group_code_skill`。
+- 当前邮件只是添加、修改或取消 Trace / Reservation Notes / Guest Request，且没有其他日期、晚数、房型、房量、人数、价格或控房修改；应走 `trace_reservation_notes_skill`。
+- 当前邮件只是为既有订单添加、修改或取消 extra bed / 加床 / `เตียงเสริม`，且没有其他日期、晚数、房型、房量、人数、价格或控房修改；应走 `trace_reservation_notes_skill`。
+- 修改动作只出现在 `body_thread`。
+- 当前邮件只是 thank you、FYI、acknowledgement、noted、received、confirmed receipt、确认收到、转发说明、仅同步信息或无新业务动作。
+
+`allowed_result_types`:
+
+- `normal_task`
+- `manual_review`
+
+`must_not_result_types`:
+
+- `exception_task`
+- `no_action`
+- `informational_message`
+
+`key_context_needed`:
+
+- `source_message_id`
+- `source_event_index`
+- `group_code`
+- `confirmation_number`
+- `routing_context`
+- 既有 FIT / Group Block / Allotment / Control Block 上下文
+- pending / open task 上下文
+- active workflow 上下文
+- terminated record 上下文
+- before / after 所需上下文摘要
+- 当前附件摘要
+- 可用历史证据上下文
+- 房型原文、床型、人数、是否套房、是否家庭房等房型映射线索
+- 渠道 / 市场类别、supplier、备注价格、是否含早餐、用餐餐厅、实际结算价格等 Rate Code 判断线索
+- extra bed / 加床 / `เตียงเสริม` 等 Trace / Guest Request 线索
+- LianTai 复合单价、附加费、Fix Charge 原文线索
+
+`input_requirements_summary`:
+
+Main Agent 应传入当前修改请求摘要、`body_current` 原文片段、附件摘要、已提取核心 key、routing context、可用历史证据上下文，以及能帮助建立 before / after 的系统上下文或历史证据。
+
+Catalog 不定义 before / after、房型映射或 Rate Code 的具体字段结构。
+
+`conflict_or_fallback_rule`:
+
+如果当前邮件明确是修改既有对象，并且 routing context 支持继续处理，输出 `normal_task`。
+
+如果 `AMEND + FINAL BOOKING` 实质为配合房 / Allotment 创建，S02 不要求建立 before / after；应重新路由到 S01。
+
+如果找不到原订单、前置 New Booking 未完成、目标对象不明确、邮件内容冲突、关键信息缺失、状态不允许修改、房型无法确认、房型映射 reference 无法唯一命中、Rate Code 或结算价格无法确认、Rate Code reference 无法唯一命中、before / after 无法可靠建立，统一输出结构化 `manual_review`。
+
+如果 Rate Code 无可选代码但 reference 明确允许手工结算价格维护，且业务动作来自 `body_current`、routing context 支持继续处理、房型唯一映射、核心修改字段和 before / after 可靠、价格来自 `body_current` 或当前表格行并可可靠提取，S02 可输出 `normal_task`；输出必须包含 `rate_code=null`、`settlement_price`、`manual_settlement_price_required=true`、`manual_price_reason_code`、`price_evidence`。任一条件不满足则输出结构化 `manual_review`。
+
+如果当前事件只是为既有订单添加、修改或取消 extra bed / 加床 / `เตียงเสริม`，不应当作普通房量修改；应路由到 `trace_reservation_notes_skill`。
+
+如果当前事件只是为既有订单添加、修改或取消 Fix Charge，且目标订单和动作明确，可由 S02 输出 `normal_task` 并标记 `update_fix_charge`；如果目标订单、动作类型或复合单价证据不清，输出结构化 `manual_review`。
+
+如果只是 thank you、FYI、acknowledgement、noted、received、confirmed receipt、确认收到、转发说明、仅同步信息或无业务动作，不应路由到本 Skill；明确轻量消息应由 `message_notification_skill` 输出 `informational_message`。
+
+`tool_placeholder`:
+
+- `suggested_tool_name: create_task_card / TBD`
+- 通过统一 Tool 创建普通 Update Booking 任务卡或结构化人工复核卡。
+- Update Booking 只调用一个统一任务卡创建 Tool，不按 subtype 拆多个 Tool。
+- 如 `extracted_fields.fix_charge_items` 非空，任务卡 payload 应保留后续 Fix Charge 维护操作信息；真实 Fix Charge Tool / API 只能在信息系统确认目标订单 ID 后执行。
+
+### S03 Cancel Booking Skill
+
+`catalog_code`: `S03`
+
+`skill_id`: `cancel_booking_skill`
+
+`skill_name`: `Cancel Booking Skill`
+
+`task_type`: `Cancel Booking`
+
+`status`: `active`
+
+`supported_subtypes`:
+
+- `cancel_fit_reservation`
+- `cancel_group_block`
+- `cancel_allotment_control_block`
+
+`cancel_object_type`:
+
+- `fit_reservation`
+- `group_block`
+- `allotment_control_block`
+
+`reference_files`:
+
+- `references/qbd_liantai_email_table_rules.md`
+
+说明：
+
+- Catalog 不展开 QBD / LianTai 表格解析细则。
+- 当 current 邮件、附件、发件人、主题或抽取证据显示 QBD / LianTai Excel/table workflow 时，具体 Skill 应读取 shared reference，判断高亮 / 黄色行、`CXL` 是否为当前取消动作、AMD/CXL/CFM 状态是否只是历史 / 完成证据，以及取消对象类型。
+
+`when_to_use`:
+
+当前 `body_current` 明确要求取消 FIT Reservation、普通团队预订、Group Block、控房、配额、Allotment 或 Control Block 时使用。
+
+典型取消信号包括：
+
+- cancel booking
+- cancel reservation
+- cancel this group
+- release / cancel this block
+- cancel allotment
+- cancel allocation
+- cancel control block
+- 取消控房 / 配额
+- `CXL`
+- 明确要求整单取消，而不是修改
+
+`CXL` 是常见取消缩写，可作为强取消信号；但不能只因为看到 `CXL` 字样就机械路由到本 Skill。仍需确认它是 `body_current` 中的当前动作，并结合上下文判断取消对象类型。
+
+`must_not_use_when`:
+
+- 当前邮件是在全新创建预订，应走 `new_booking_skill`。
+- 当前邮件只是修改日期、房型、房量、人数、价格或备注，应走 `update_booking_amendment_skill`。
+- 当前邮件只是释放部分房量，但仍保留订单 / 控房对象，应优先考虑 `update_booking_amendment_skill`。
+- 当前邮件只是提交 Rooming List / Name List。
+- 当前邮件只是收到 Voucher、Credit Voucher、payment slip 或 payment confirmation。
+- 取消动作、`CXL` 或取消状态只出现在 `body_thread`。
+- 当前邮件只是 thank you、FYI、acknowledgement、noted、received、confirmed receipt、确认收到、转发说明、仅同步信息或无新业务动作。
+
+`allowed_result_types`:
+
+- `normal_task`
+- `manual_review`
+
+`must_not_result_types`:
+
+- `exception_task`
+- `no_action`
+- `informational_message`
+
+`key_context_needed`:
+
+- `source_message_id`
+- `source_event_index`
+- `group_code`
+- `confirmation_number`
+- `routing_context`
+- 既有订单 / Group Block / Allotment / Control Block 上下文
+- pending / open task 上下文
+- active workflow 上下文
+- terminated record 上下文
+- 取消对象类型线索
+- 当前附件摘要
+- 可用历史证据上下文
+
+`input_requirements_summary`:
+
+Main Agent 应传入当前取消请求摘要、`body_current` 原文片段、附件摘要、已提取核心 key、routing context、可用历史证据上下文，以及能帮助判断取消对象类型的上下文。
+
+如果一封邮件中同时取消多个订单，Main Agent 应拆成多个 `source_event_index`。
+
+`conflict_or_fallback_rule`:
+
+如果当前事件明确是取消 FIT Reservation、Group Block 或 Allotment / Control Block，且 routing context 支持继续创建取消任务，输出 `normal_task`。
+
+如果找不到原订单、目标对象不明确、无法确认取消对象类型、前置任务未完成、订单已终止但当前邮件又提出取消、取消请求可能已经处理过、重复取消请求、邮件内容冲突、关键信息缺失，统一输出结构化 `manual_review`。
+
+如果当前邮件像取消，但也可能是修改或部分释放房量，优先结合 routing context 判断；仍无法安全判断时输出结构化 `manual_review`。
+
+如果只是 thank you、FYI、acknowledgement、noted、received、confirmed receipt、确认收到、转发说明、仅同步信息、确认已取消但无新业务动作，不应路由到本 Skill；明确轻量消息应由 `message_notification_skill` 输出 `informational_message`。
+
+`tool_placeholder`:
+
+- `suggested_tool_name: create_task_card / TBD`
+- 通过统一 Tool 创建普通 Cancel Booking 任务卡或结构化人工复核卡。
+- Cancel Booking 只调用一个统一任务卡创建 Tool，不按对象类型拆多个 Tool。
+
+## 7. Message Notification And Fallback
+
+### S10 Message Notification Skill
+
+`catalog_code`: `S10`
+
+`skill_id`: `message_notification_skill`
+
+`skill_name`: `Message Notification Skill`
+
+`task_type`: `Message Notification`
+
+`status`: `planned / active_for_message_classification`
+
+`supported_subtypes`:
+
+- `thank_you`
+- `fyi`
+- `acknowledgement`
+- `noted`
+- `received`
+- `confirmed_receipt`
+- `forwarding_note`
+- `information_sync`
+
+`when_to_use`:
+
+当 `body_current` 明确是 thank you、FYI、acknowledgement、noted、received、confirmed receipt、转发说明、仅同步信息，且没有新的可执行业务动作时使用。
+
+适用场景包括：
+
+- thank you / thanks
+- FYI
+- acknowledgement
+- noted
+- received
+- confirmed receipt / 确认收到
+- 转发说明
+- 仅同步信息
+- 无新业务动作但有沟通价值，需要用户可见
+
+`must_not_use_when`:
+
+- 当前邮件可以明确、安全路由到 S01 / S02 / S03 或其他业务 Skill。
+- 当前邮件包含新的可执行业务动作。
+- 当前邮件像业务请求，但缺少足够上下文判断任务类型。
+- 当前邮件存在多个候选 Skill 冲突。
+- current/history 边界不清。
+- 无法判断是消息通知还是业务动作。
+- 路由上下文不足以排除业务动作。
+
+`allowed_result_types`:
+
+- `informational_message`
+
+`must_not_result_types`:
+
+- `normal_task`
+- `manual_review`
+- `exception_task`
+- `no_action`
+
+`key_context_needed`:
+
+- `source_message_id`
+- `source_event_index`
+- `body_current` 原文片段
+- 附件摘要
+- 已识别的消息通知语义
+- 可用于确认没有新业务动作的当前邮件线索
+
+`input_requirements_summary`:
+
+Main Agent 应传入当前事件摘要、`body_current` 原文片段、附件摘要、候选消息通知类型，以及为什么判断为无新可执行业务动作的证据。
+
+`conflict_or_fallback_rule`:
+
+如果 current 邮件明确是消息通知且没有新的可执行业务动作，输出 `informational_message`。
+
+如果无法判断是消息通知还是业务动作，不应硬走 S10，应调用 `exception_detection_skill` 输出 structured `manual_review`。
+
+S10 不处理路由冲突、业务边界不清、current/history 不清或上下文不足。
+
+`tool_placeholder`:
+
+- `suggested_tool_name: create_task_card / TBD`
+- 通过统一 Tool 创建信息提醒卡 / 消息通知卡。
+- S10 不创建普通业务任务卡。
+
+### S99 Exception Detection / Fallback Skill
+
+`catalog_code`: `S99`
+
+`skill_id`: `exception_detection_skill`
+
+`skill_name`: `Exception Detection / Fallback Skill`
+
+`task_type`: `Fallback`
+
+`status`: `routing_fallback`
+
+`supported_subtypes`:
+
+- `route_conflict`
+- `current_history_boundary_unclear`
+- `insufficient_routing_context`
+- `business_boundary_unclear`
+- `message_or_business_unclear`
+
+`when_to_use`:
+
+当 Main Agent 无法安全路由到明确业务 Skill、多个 Skill 冲突、current/history 边界不清、上下文不足，或无法判断是消息通知还是业务动作时使用。
+
+适用场景包括：
+
+- 多个 Skill 冲突且无法安全拆分。
+- current/history 边界不清。
+- 邮件像业务请求，但缺少足够上下文判断任务类型。
+- 无法判断当前邮件是消息通知还是业务动作。
+- 路由上下文不足以安全选择业务 Skill 或 S10。
+
+`must_not_use_when`:
+
+- 当前邮件可以明确、安全路由到 S01 / S02 / S03 或其他业务 Skill。
+- 当前邮件可以明确、安全路由到 S10 Message Notification。
+- 当前邮件包含多个可拆分业务事件，且可以安全拆分为多个 `source_event_index`。
+
+`allowed_result_types`:
+
+- `manual_review`
+
+`key_context_needed`:
+
+- `source_message_id`
+- `source_event_index`
+- `body_current` 原文片段
+- 附件摘要
+- 已识别的候选 Skill
+- 已提取的候选 key
+- routing context
+- 冲突原因或无法路由原因
+
+`input_requirements_summary`:
+
+Main Agent 应传入当前事件摘要、候选路由结果、无法安全路由的原因、routing context、附件摘要、可用历史证据上下文，以及是否存在 S10 候选但无法确认的原因。
+
+`conflict_or_fallback_rule`:
+
+当无法安全路由、多个 Skill 冲突、current/history 边界不清时，输出结构化 `manual_review`。
+
+当无法判断是否消息通知还是业务动作时，输出结构化 `manual_review`，不要硬走 S10。
+
+S99 第一版不输出 `informational_message`。
+
+`tool_placeholder`:
+
+- `suggested_tool_name: create_task_card / TBD`
+- 通过统一 Tool 创建结构化人工复核卡。
+
+## 8. Additional Planned Skills
+
+S04-S08 已有对应 Skill 文档。Catalog 只保留路由边界、上下文要求和统一输出原则；具体业务判断、字段抽取和输出细节以对应 Skill 文档为准。S09 仍是后续占位。
+
+### S04 Voucher Received Skill
+
+`catalog_code`: `S04`
+
+`skill_id`: `voucher_received_skill`
+
+`skill_name`: `Voucher Received Skill`
+
+`task_type`: `Voucher Received`
+
+`status`: `planned`
+
+`supported_subtypes`:
+
+- `lian_tai_credit_voucher`
+- `bank_transfer_slip`
+
+`when_to_use`:
+
+当前 `body_current` 中包含真实凭证图片 / PDF，且可判断为 LianTai 固定格式 `CREDIT VOUCHER` 或银行转账 / 存款 / payment slip / payment confirmation 凭证时使用。任务卡必须展示原始凭证图片 / PDF。
+
+`must_not_use_when`:
+
+- 当前邮件没有可见凭证图片 / PDF。
+- 只有标题、正文关键词、泰文状态、文件名、Excel 状态或历史引用提到 voucher / payment。
+- 凭证只在 `body_thread` 历史中出现。
+- 仅凭图片文件名、附件文件名、Excel 行 code、客人名、日期、酒店或房型组合绑定订单。
+- 从银行凭证图片的备注、参考号、QR、账号、收付款人、金额、日期或任意 OCR 文本绑定 `Group Code`。
+- 从 LianTai `CODE / 團號` 字段之外读取 `Group Code`。
+- 将 LianTai 展示字段用于房型映射、Rate Code、房量、价格、FIT / Group 判断或自动更新。
+- 确认真实到账、生成 Receipt、直接调用 Reservation Type API 或处理 Invoice Generation。
+
+`allowed_result_types`:
+
+- `normal_task`
+- `manual_review`
+
+`key_context_needed`:
+
+- current 凭证图片 / PDF 引用
+- current subject / body
+- voucher subtype 候选
+- `Group Code` / reservation no 候选及来源
+- LianTai `CODE / 團號`、日期、入住 / 离店日期、房型展示字段候选
+- `routing_context` 中有效 reservation / group block / booking record 或待完善 New Booking 任务卡查询结果
+
+`input_requirements_summary`:
+
+Main Agent 应传入 current 凭证引用、邮件文本、subtype 证据、target key 候选、目标对象校验结果，以及原始凭证可展示引用。S04 使用统一高层字段 `voucher_attachment.display_original=true` 和 `voucher_attachment.file_reference`，不在 Catalog 展开底层附件字段。
+
+`conflict_or_fallback_rule`:
+
+- `lian_tai_credit_voucher` 的 `Group Code` 来自图片固定 `CODE / 團號` 字段；字段手写不清则输出 S04 `manual_review`。
+- `lian_tai_credit_voucher` 不流转部门：`requires_department_routing=false`，`department_routing=[]`。
+- `bank_transfer_slip` 的 `Group Code` 来自 current 邮件文本或明确相关上下文；需要通过通用 `department_routing` 流转 Finance，目的为 `confirm_payment_received`。
+- 同一张银行凭证明确覆盖多个 `Group Code` 时，不算异常；按 `Group Code` 拆分多个 `ai_task_result`，每个结果只绑定一个 `case_keys.group_code`，并可用 `related_group_codes` 给页面说明同一凭证覆盖范围。
+- 识别 target 后只校验是否存在有效 reservation / group block / booking record；若没有，校验是否存在可承接的待完善 New Booking 任务卡。两者都没有则输出 `manual_review`。
+- S04 可传递 `post_confirm_action: update_reservation_type -> PD`，但不直接调用 API；payment slip 在 Finance 确认到账后由信息系统执行，LianTai 凭证在用户 / 信息系统确认后执行。
+
+`tool_placeholder`:
+
+- `suggested_tool_name: create_task_card / TBD`
+- 通过统一 Tool 创建 Voucher Received 任务卡或人工复核卡；subtype 不拆 Tool。
+
+### S05 Rooming List / Name List Skill
+
+`catalog_code`: `S05`
+
+`skill_id`: `rooming_list_name_list_skill`
+
+`skill_name`: `Rooming List / Name List Skill`
+
+`task_type`: `Rooming List`
+
+`status`: `planned`
+
+`supported_list_evidence_types`:
+
+- `rooming_list`
+- `name_list`
+- `guest_list`
+- `room_assignment_list`
+
+`reference_files`:
+
+- `references/qbd_liantai_email_table_rules.md`
+
+`when_to_use`:
+
+当前 `body_current` 提交 Rooming List、Name List、分房名单、客人名单，或发送可读取且可判断为名单的文件 / 文件链接时使用。Excel、PDF、图片、Google Drive 链接或文件名本身不是触发依据，必须能确认 current 文件内容或 current/history 语境确实指向名单。
+
+`must_not_use_when`:
+
+- 新建、修改、取消、Voucher / payment evidence 等主业务动作。
+- 只有 Excel、文件链接或类似 `Group Code` 的文件名，不能确认是名单。
+- LianTai / QBD booking update 表；例如 sheet 名类似 `BOOKING 01-2026`，或表头 / 内容是 `NEW BOOKING`、`AMEND`、`AMD`、`CXL`、`CFM`、房量、房型、价格、酒店状态。
+
+`allowed_result_types`:
+
+- `normal_task`
+- `manual_review`
+
+`key_context_needed`:
+
+- current 名单事件摘要
+- current 邮件正文、附件、文件链接或 `file_reference`
+- 文件读取 / 下载 / 解析结果
+- workbook / sheet / table / PDF / image 摘要
+- 文件类型判断证据
+- target key 候选及来源
+- 附件 / 文件 / sheet 与目标对象绑定关系
+- `routing_context`
+
+`input_requirements_summary`:
+
+Main Agent 应传入文件证据、读取状态、文件类型判断、target key 候选、sheet / 附件归属和目标对象校验结果。文件读取失败、无权限或无法确认类型时，不得输出 `normal_task`。
+
+`conflict_or_fallback_rule`:
+
+- 同一 current 事件同时包含名单和其他业务动作时，能拆则拆；不能拆则输出 structured `manual_review` 或交由 S99。
+- 客人级名单通常是一行一个客人，包含姓名、英文姓名、性别、出生日期、护照、国籍、航班、到达 / 离开日期等字段。
+- 一个 workbook 内多个 group / sheet 时，按目标对象拆分；每个结果只绑定一个 `case_keys.group_code` 或一个目标 reservation。
+- `总名单` 默认作为 shared evidence，不单独生成任务，除非 current 明确要求按汇总 sheet 导入一个目标。
+- S05 可保留 Import、TA Recorder、Note、Routing 等 locked downstream actions，但不直接导入 Opera、不创建 PM room、不维护 Routing Instruction、不写 TA Recorder / Note、不更新 Block Status。
+
+`tool_placeholder`:
+
+- `suggested_tool_name: create_task_card / TBD`
+- 通过统一 Tool 创建 Rooming List 任务卡或人工复核卡。
+
+### S06 Amend Group Code Skill
+
+`catalog_code`: `S06`
+
+`skill_id`: `amend_group_code_skill`
+
+`skill_name`: `Amend Group Code Skill`
+
+`task_type`: `Amend Group Code`
+
+`status`: `planned`
+
+`supported_action`:
+
+- `amend_group_code`
+
+`reference_files`:
+
+- `references/qbd_liantai_email_table_rules.md`
+
+`when_to_use`:
+
+当前 `body_current`、current 附件表格、PDF 或图片 OCR 中明确要求把旧 Group Code 改为新 Group Code 时使用。`AMEND GROUP CODE TO : <new_group_code>` 是强信号；正文、附件表格、PDF、图片 OCR 都可以作为 current 证据。
+
+`must_not_use_when`:
+
+- 只是提到 Group Code，没有修改 Group Code 的业务动作。
+- 只有一个 Group Code，无法判断旧 / 新。
+- 当前事件只是普通 New / Update / Cancel / Voucher / Rooming List / Trace，且没有 Group Code 修改动作。
+- 主语义是 cancel / CXL / release / cut allotment，只是顺带提到 moved / join group。
+- Group Code 修改动作只出现在 `body_thread`。
+- 固定列位置、固定单元格或固定 sheet 名本身作为业务识别规则。
+
+`allowed_result_types`:
+
+- `normal_task`
+- `manual_review`
+
+`key_context_needed`:
+
+- current Group Code 修改原文片段
+- current 附件表格 / PDF / OCR 摘要
+- `old_group_code`
+- `new_group_code`
+- old / new 关系证据
+- `routing_context`
+- 同一不可拆分事件中附带的其他业务动作摘要
+
+`input_requirements_summary`:
+
+Main Agent 应传入当前 Group Code 修改请求、old / new 关系证据、routing context、row-level evidence 和同事件附带业务动作摘要。任务卡前端只展示 `old_group_code` 和 `new_group_code`。
+
+`conflict_or_fallback_rule`:
+
+- 多个业务动作可清楚拆分时，拆成多个 `source_event_index` 分别路由。
+- 若 S06 与其他业务动作处于同一不可拆分事件，主任务为 S06；其他业务动作作为后台关联信息传给信息系统，不扩大任务卡前端字段。
+- 受控例外：同一不可拆分事件中同时存在 Trace / Guest Request / extra bed 时，生成 S06 主任务和 S07 linked task，先 S06 后 S07。
+- S06 只在“改团号语义模糊但没有明确 old / new”或 `AMEND GROUP CODE TO` 后的新 code 识别不清时输出 `manual_review`；routing context 等后续问题进入后台校验或信息系统硬校验。
+
+`tool_placeholder`:
+
+- `suggested_tool_name: create_task_card / TBD`
+- 通过统一 Tool 创建 Amend Group Code 任务卡或人工复核卡。
+
+### S07 Trace / Reservation Notes Skill
+
+`catalog_code`: `S07`
+
+`skill_id`: `trace_reservation_notes_skill`
+
+`skill_name`: `Trace / Reservation Notes Skill`
+
+`task_type`: `Trace / Reservation Notes`
+
+`status`: `planned`
+
+`supported_trace_subtypes`:
+
+- `extra_bed`
+- `general_request`
+
+`reference_files`:
+
+- `references/qbd_liantai_email_table_rules.md`
+
+`when_to_use`:
+
+当前 `body_current` 要求添加、修改或取消 Trace / Reservation Notes / Guest Request / Special Request，或需要为同一 current 事件中的 S01 / S02 / S06 后续生成 S07 linked task 时使用。
+
+`must_not_use_when`:
+
+- 当前事件没有 Trace、Reservation Notes、Guest Request 或 extra bed 类动作。
+- 当前事件只是普通 New / Update / Cancel / Voucher / Rooming List / Amend Group Code，且没有 trace / guest request。
+- 当前事件是 Cancel Booking / CXL，且只是被取消对象上历史存在 extra bed 或 guest request。
+- 当前事件只是 thank you、FYI、acknowledgement、noted、received、confirmed receipt、转发说明、仅同步信息或无新业务动作。
+
+`allowed_result_types`:
+
+- `normal_task`
+- `manual_review`
+
+`key_context_needed`:
+
+- current trace / guest request 原文片段
+- `trace_subtype`
+- `trace_text`
+- `notify_departments`
+- 目标 `group_code` / confirmation number / reservation number / group block key
+- routing context
+- history target-binding evidence，如有
+- 若为 linked task，父任务 `task_type`、`source_event_index`、case key 和执行顺序
+
+`input_requirements_summary`:
+
+Main Agent 应传入当前 trace / guest request 摘要、原文证据、目标对象 key、routing context、subtype、部门同步判断和父任务信息。QBD / LianTai 表格场景应保留 row-level evidence。
+
+`conflict_or_fallback_rule`:
+
+- `trace_subtype=extra_bed` 固定输出 `trace_text=Set Extrabed`、`notify_departments=["FO","HSK"]`、`occupancy_update=3adult`、`requires_rate_update=true`、`rate_adjustment_formula=rate_code_price / 2 * 3`。
+- `trace_subtype=general_request` 写具体要求；`Non-smoking room`、`High floor`、`Away from elevator`、`Same floor` 等排房要求只同步 FO；`Set Honeymoon` 等房间布置 / 房务准备同步 FO + HSK。
+- S07 不决定 Rate Code，不猜 `rate_code_price`，不自行计算最终房价。
+- S07 可以独立生成，也可以作为 S01 / S02 / S06 的 linked task；linked task 必须在主业务任务后执行。
+- current 动作明确但目标 key 只在最近相关 history 中出现时，可使用 `body_thread` 作为 target binding evidence；history 不能单独触发 S07。
+- 无法判断 subtype、目标、部门同步或 current/history 边界时，输出 S07 `manual_review` 或走 S99。
+
+`tool_placeholder`:
+
+- `suggested_tool_name: create_task_card / TBD`
+- 通过统一 Tool 创建 Trace / Reservation Notes 任务卡或人工复核卡。
+
+### S08 TA Recorder Skill
+
+`catalog_code`: `S08`
+
+`skill_id`: `ta_recorder_skill`
+
+`skill_name`: `TA Recorder Skill`
+
+`task_type`: `TA Recorder`
+
+`status`: `planned`
+
+`supported_action`:
+
+- `maintain_ta_recorder`
+
+`reference_files`:
+
+- `references/qbd_liantai_email_table_rules.md`
+
+`when_to_use`:
+
+通常由 S05 Rooming List / Name List 派生，为每个目标 `group_code` 创建 TA Recorder linked task。少数情况下，如果 current 邮件明确要求维护 TA Recorder，且能识别唯一目标 `group_code` 和名单 / 分房文件引用，也可直接使用 S08。
+
+`must_not_use_when`:
+
+- S05 尚未确认名单文件、目标对象或附件绑定。
+- S05 输出 `manual_review`，文件类型、目标对象或附件归属仍不清。
+- 只是出现 `TA`、travel agent、旅行社、Source TA 或 Reservation Type TA。
+- 只有 sheet 名、文件名或附件名像 group code。
+- 只有 Google Drive / 网盘链接但文件不可下载、无权限或未确认是名单 / 分房文件。
+
+`allowed_result_types`:
+
+- `normal_task`
+- `manual_review`
+
+`key_context_needed`:
+
+- S05 parent task context
+- `source_rooming_list_task_id`
+- `parent_source_event_index`
+- `linked_task_group_id`
+- 唯一目标 `group_code`
+- Rooming List / Name List 附件、链接或 `file_reference`
+- workbook / sheet / range 绑定证据
+- file read / download / permission status
+- routing context
+
+`input_requirements_summary`:
+
+Main Agent 应传入 S05 派生上下文、唯一目标 `group_code`、名单 / 分房附件或文件引用、文件与目标对象绑定证据和父任务关系。若一个 workbook 对应多个 group，必须消费 S05 已拆分后的目标对象结果。
+
+`conflict_or_fallback_rule`:
+
+- S08 是一个目标 `group_code` 一张卡；不是一封邮件一张卡、一个 workbook 一张卡或一个 sheet 一张卡。
+- 同一个 workbook / `file_reference` 可以被多张 S08 共享。
+- Sheet 只作为绑定证据，不直接决定 `group_code`；`IN9-17`、`总名单`、`WpsReserved_CellImgList` 不得单独生成 S08。
+- 如果 S05 是 `manual_review`，S08 不应直接输出可执行 `normal_task`；可作为 locked downstream candidate 保留，或输出 S08 `manual_review`。
+
+`tool_placeholder`:
+
+- `suggested_tool_name: create_task_card / TBD`
+- 通过统一 Tool 创建 TA Recorder 任务卡或人工复核卡。
+
+### S09 Note Skill
+
+`catalog_code`: `S09`
+
+`skill_id`: `note_skill`
+
+`skill_name`: `Note Skill`
+
+`task_type`: `Note`
+
+`status`: `planned_placeholder`
+
+说明：
+
+- 当前 `skill/` 目录下尚未落地 S09 对应 Skill 文档。
+- S09 先保留为 Rooming List 后续派生任务占位；正式编写前不得把普通邮件硬路由到 S09。
+
+`when_to_use`:
+
+通常由 Rooming List / Name List 流程派生，用于维护 Payer code、Charge code、Breakfast 等 Note 字段。
+
+`must_not_use_when`:
+
+- 不应直接把普通邮件路由到本 Skill，除非 current 邮件明确要求维护 Note，或后续 Skill 文档另有定义。
+
+`allowed_result_types`:
+
+- `normal_task`
+- `manual_review`
+
+`conflict_or_fallback_rule`:
+
+第一版暂按 Rooming List 的后续派生任务理解。若 current 邮件直接提出 Note 维护但上下文不足，输出结构化 `manual_review`。
+
+## 9. Merged Or Excluded Items
+
+### Cancel Allotment Skill
+
+不再作为独立 Skill。
+
+取消控房、配额、Allotment、Control Block 统一并入：
+
+- `S03 cancel_booking_skill`
+- subtype / object type: `cancel_allotment_control_block`
+
+### Invoice Generation Skill
+
+不纳入邮件触发 Skill Catalog。
+
+原因：
+
+- Invoice Generation 本来不是由邮件触发。
+- 不处理“收到 invoice 邮件”的场景。
+- 相关动作应走信息系统流程，而不是 AI 邮件 Skill。
+
+### no_action
+
+不作为第一版输出类型。
+
+如果 current 邮件无可执行业务动作但需要用户可见，输出：
+
+- `informational_message`
+
+该结果类型由 `message_notification_skill` 负责输出。
+
+### exception_task
+
+第一版暂不作为业务 Skill 的输出类型。
+
+如果无法安全自动处理，输出：
+
+- `manual_review`
+
+## 10. Current Test Scope
+
+当前测试建议分两层覆盖：
+
+- `S01 new_booking_skill`
+- `S02 update_booking_amendment_skill`
+- `S03 cancel_booking_skill`
+- `S04 voucher_received_skill`
+- `S05 rooming_list_name_list_skill`
+- `S06 amend_group_code_skill`
+- `S07 trace_reservation_notes_skill`
+- `S08 ta_recorder_skill`
+- `S10 message_notification_skill` 作为轻量消息分类
+- `S99 exception_detection_skill` 作为 structured manual_review 路由兜底
+
+其中：
+
+- S01-S03 是当前核心业务回归测试。
+- S04-S08 是已落地 Skill 文档的扩展业务测试。
+- S09 仍是 planned placeholder，正式 Skill 文档未落地前不纳入自动路由测试。
+- S10 / S99 是路由边界和兜底测试。
+
+测试重点：
+
+- New / Update / Cancel 是否能被正确路由。
+- Voucher / Rooming List / Amend Group Code / Trace / TA Recorder 是否能按已落地 Skill 文档路由。
+- `body_current` 与 `body_thread` 边界是否被遵守。
+- `no_action` 是否已被移除。
+- `exception_task` 是否暂未出现。
+- thank you / FYI / acknowledgement / noted / received / confirmed receipt 是否走 S10 `informational_message`，而不是被业务 Skill 硬吃。
+- 无法判断是消息通知还是业务动作时，是否走 S99 structured `manual_review`，而不是硬走 S10。
+- `manual_review` 是否结构化保留已知字段、缺失字段、阻断点和冲突点；建议人工动作和证据位置按具体 Skill 文档执行，S04 / S05 等精简结构遵守各自例外。
+- S02 subtype 是否只作为内部测试维度，不拆 Skill / Tool。
+- S03 是否已覆盖 `cancel_allotment_control_block`，不再单独路由 Cancel Allotment。
+- S04 是否只由 current 可见凭证图片 / PDF 触发，一张卡只绑定一个 `Group Code`，并按 subtype 正确处理 LianTai 不流转部门、payment slip 流转 Finance。
+- S05 是否能区分名单文件和 QBD / LianTai booking update 表。
+- S06 是否只处理 old / new Group Code 关系明确的改团号事件。
+- S07 是否正确区分 `extra_bed` / `general_request`，并在 extra bed 中输出 `Set Extrabed`、FO+HSK、`3adult` 和 `rate_code_price / 2 * 3` 操作意图。
+- S08 是否由 S05 confirmed target 派生，一个目标 `group_code` 一张 TA Recorder 卡。
diff --git a/docs/import/20260706/0630AI_副本 2/references/qbd_liantai_email_table_rules.md b/docs/import/20260706/0630AI_副本 2/references/qbd_liantai_email_table_rules.md
new file mode 100644
index 0000000..211582f
--- /dev/null
+++ b/docs/import/20260706/0630AI_副本 2/references/qbd_liantai_email_table_rules.md	
@@ -0,0 +1,117 @@
+# QBD / LianTai Email Table Rules
+
+This reference defines shared QBD / LianTai Excel and table evidence rules for booking-desk Skills.
+
+Read this reference when the current message, attachment, sender, subject, or extracted evidence indicates a QBD or LianTai Excel/table workflow.
+
+## Trigger Signals
+
+Read this reference when any of these signals appears in `body_current`, attachment names, attachment content, sender, subject, or extracted evidence:
+
+- Sender or channel indicates QBD, Q.B.D, LianTai, Lian Tai, Liantai, LT, DY, FIT, or related agency workflow.
+- Sender includes known QBD / LianTai accounts such as `op.qbdtravel@gmail.com` or `opfit.liantaitravel@gmail.com`.
+- Subject or body includes `QBD BOOKING UPDATE`, `UPDATE BOOKING`, `BOOKING UPDATE`, `AMEND BOOKING`, `AMD`, `AMEND GROUP CODE`, `AMEND ALLOTMENT`, `CANCEL`, `CXL`, `NAME LIST`, `Rooming List`, `Voucher`, or similar task signals.
+- Attachments include Excel/table files, screenshots of tables, or table-like booking grids from QBD / LianTai.
+- Attachment headers, sheet names, columns, or evidence include `Q.B.D TRAVEL GROUP CO.,LTD.`, `LIAN TAI TRAVEL GROUP`, `โรงแรม`, `โรงแรมให้ สถานะ`, `CFM`, `AMD`, `CXL`, highlighted rows, yellow fill, red text, or strikethrough text.
+
+If any trigger signal is present but the table/highlight/row evidence is unavailable, unreadable, or ambiguous, do not guess. Output structured manual_review and include the missing table evidence in manual_review.evidence_to_check.
+
+## Evidence Priority
+
+- Treat `body_current` as the only source for creating a current `normal_task`.
+- Use `body_thread`, historical attachments, previous status rows, and routing context only as evidence context.
+- If `body_current` contains the current executable action, `body_thread` may bind the target key when the latest relevant thread segment clearly supplies one `group_code`, one parent group, or a known upstream task. Record the target source; do not treat historical actions themselves as current actions.
+- QBD / LianTai email bodies often contain only a short instruction; detailed booking parameters may live in Excel, PDF, image, or screenshot attachments.
+- Current table evidence may decide the current task even when the email subject contains historical signals such as NEW, FINAL, AMEND, Voucher, or Cancel.
+
+## Highlighted / Yellow Rows
+
+- Highlighted rows, yellow fill, or highlighted cells indicate the rows or fields the hotel currently needs to process.
+- QBD workflows must prioritize rows with background color, fill color, or yellow highlight as the current pending rows.
+- Non-highlighted rows are historical context or completion evidence unless `body_current` explicitly says to process all rows.
+- Do not use AMD/CXL/CFM status dates by themselves to expand the set of current rows.
+- If the runtime cannot read color/highlight information from the attachment, output `manual_review` unless the current row set is still unambiguous from other current evidence.
+
+## Current Row To Event Splitting
+
+- For QBD / LianTai Excel or table workflows, each current effective highlighted / yellow row is one independent current event.
+- Use this rule for New Booking, Update / Amendment, Cancel / CXL, Allotment / Control Block, and similar row-based task signals.
+- Assign each current effective row its own `source_event_index`.
+- Output one independent `ai_task_result` for each current effective row.
+- Treat each row as one downstream task card candidate: `table row = source_event_index = ai_task_result = task card`.
+- Do not merge different table rows into one task, even when multiple rows share the same `group_code`, `confirmation_number`, stay dates, hotel, batch, supplier, subject, or attachment.
+- Do not replace multiple row-level outputs with `source_event_count`, array-valued `case_keys.group_code`, summary `highlighted_rows`, or a single summary `room_items` list.
+- For row-based outputs, each `ai_task_result.case_keys.group_code` should represent that row's key only; each result must carry row-level `extracted_fields.table_evidence`.
+- If one row contains multiple room type / room quantity / price details, keep those details inside that row's own `extracted_fields`, such as `room_items`.
+- If one row is incomplete or ambiguous, output structured `manual_review` for that row only; do not block other rows that can be processed safely.
+- Preserve row-level evidence for every generated result, including attachment name, sheet name, row number or row label, highlight status, and action/status cell value.
+
+Controlled exception:
+
+- If the same current effective row contains an S01 / S02 / S06 primary business action and Trace / Guest Request / extra bed evidence, generate both the primary task and an S07 linked task.
+- Execute the primary task first and S07 second.
+- Do not merge the primary task and S07 into one `ai_task_result`.
+- If `source_event_index` must be an integer, assign S07 a new integer index and preserve the same-row relationship through `parent_source_event_index`, `linked_task_group_id`, and `execution_order`.
+
+## LianTai Table Rules
+
+- LianTai update tables often use the hotel column (`โรงแรม` / 酒店) as the main field for actual stay dates, room type, room quantity, price, breakfast, and restaurant notes.
+- Prefer the date range at the start of the hotel column for actual arrival and departure dates, such as `09-11` meaning arrival day 9 and departure day 11.
+- Resolve month and year from the sheet name, file name, or batch context, such as `BOOKING 06-2026` or `WYNDHAM 06.26`.
+- Rows with highlight and no completed hotel status are usually pending current work.
+- After hotel processing, highlight is normally removed and the hotel status column records `CFM`, `AMD`, or `CXL` plus a date. This status is completion evidence, not a standalone new task.
+- The hotel column may contain a composite unit price expression that provides both Rate Code evidence and Fix Charge evidence, such as `2000THB+500`, `1800THB+500`, or `2000THB*2` followed by `+附加500*2`.
+- In a composite unit price expression, the component before `+` is the room-price component for Rate Code logic; the component after `+` is the additional-charge component for `fix_charge_items`.
+- Do not add the two components together for Rate Code logic. For example, do not treat `2000THB+500` as `2500`.
+- Do not trigger Fix Charge only because a row contains `TWN`, `DBL`, `2000THB`, or `1800THB`. Trigger it only when a separable additional-charge component is present.
+- Fix Charge amount is not fixed to 500. Use the extracted component after `+` as the unit amount.
+- If a composite expression contains `*quantity`, preserve the quantity evidence in raw fields when useful, but do not require AI to calculate total Fix Charge amount.
+- Composite unit price evidence belongs only to the current table row; do not carry a Fix Charge component across rows.
+- If table row evidence, highlight/current-row evidence, or the price area is unreadable or ambiguous, output structured `manual_review` instead of guessing.
+
+## QBD Table Rules
+
+- QBD booking update tables must first filter current rows by background color, fill color, or yellow highlight.
+- Within current rows, use the action/remark column to identify candidate task semantics such as AMEND BOOKING, AMEND GROUP CODE, AMD ALLOTMENT, CANCEL BOOKING, or CXL.
+- Red text can be a cancel or abnormal-action clue, but it must still be interpreted with current row/highlight and action evidence.
+- Non-highlighted rows with AMD/CXL dates are historical or already-processed evidence unless `body_current` explicitly reopens them.
+
+## Before / After Rules
+
+- Strikethrough text is usually the before value.
+- Text after the strikethrough, text below it, or the next related row is usually the after value.
+- Apply this before/after rule to room type, room quantity, group code, block name, dates, rate, and other amendable fields.
+- If before/after cannot be reliably reconstructed, keep known fields in `extracted_fields`, set uncertain fields to `null` or candidate arrays, and output structured `manual_review`.
+
+## FIT / Group / Allotment Decision
+
+- Do not classify Group/FIT from the attachment header or table title alone.
+- Use the total room quantity for the same booking or row:
+  - Less than 5 rooms usually means FIT Reservation.
+  - 5 rooms or more usually means Group Block.
+- For Update / Amendment, use the target after room quantity.
+- Use Allotment / Control Block only when the current row, action, object code, or context clearly indicates allotment, allocation, control block, 控房, or 配额.
+- In the LianTai / agency workflow, a current plain-text `AMEND + FINAL BOOKING` can still be an Allotment / Control Block creation event when it lists one parent group code followed by multiple new child `group_code` lines with stay dates and room allocations. In the hotel system this is handled like New Booking / Allotment creation, not a simple S02 before-after amendment.
+- For this parent-to-child allocation pattern, treat each child `group_code` line as a row-equivalent current event. Output one S01 New Booking / Allotment task per child code when the child code, stay dates, and room allocations are readable. Preserve the parent code as `parent_group_code` / `allocation_parent_group_code`.
+- Do not output `manual_review` merely because the parent group is being split, before values are not restated per child, or the subject/body contains `AMEND`. Output `manual_review` only for the affected child line if that line's child code, dates, room allocation, object type, room mapping, or rate/price rule cannot be safely extracted.
+- If the current parent-to-child allocation text also contains group-level service requests such as registration table, welcome drink, welcome screen, key cards, meal notes, or other guest requests, generate S07 linked task(s) bound to the parent group or allocation parent unless the request explicitly targets only one child group.
+
+## Skill-Specific Effects
+
+- New Booking: table rows can provide new FIT, Group Block, or Allotment / Control Block creation parameters. Routing context still decides whether an apparently new request is duplicate or blocked.
+- New Booking: parent-to-child `AMEND + FINAL BOOKING` allocation text can provide row-equivalent child Allotment / Control Block creation parameters; route to S01 when the child group lines are readable.
+- New Booking: if a current row includes a LianTai composite unit price expression, keep the primary task as New Booking and pass the additional-charge component in `extracted_fields.fix_charge_items`.
+- Amend Group Code: current rows with clear `AMEND GROUP CODE` / `AMEND GROUP CODE TO` evidence route to S06. Fixed column positions are evidence locations only; do not treat a specific column as the business rule itself.
+- Trace / Reservation Notes: extra bed / 加床 / `เตียงเสริม` / `U-เตียงเสริม` / `เสริมเตียง` is Trace / Guest Request. It is not room quantity, room type, FIT/Group evidence, Rate Code evidence, or Fix Charge evidence.
+- Trace / Reservation Notes: if a current row includes Trace / Guest Request / extra bed together with S01 / S02 / S06, generate an S07 linked task after the primary task. Do not rely on a fixed column to identify this evidence.
+- Update Booking / Amendment: table rows can define `update_subtypes`, before/after fields, changed room type/quantity, dates, guest count, trace/request, rate/settlement price, or Fix Charge maintenance. If the same indivisible row also contains clear Amend Group Code evidence, keep S06 as the primary task and pass other row details as backend same-event information, except Trace / Guest Request / extra bed, which should also create S07 linked task.
+- Update Booking / Amendment: if a current row includes a LianTai composite unit price expression or explicit Fix Charge maintenance, use `update_fix_charge` when the target order and action are clear.
+- Cancel Booking: current rows with Cancel/CXL evidence can identify cancellation requests. Use table context and routing context to decide `cancel_object_type` as `fit_reservation`, `group_block`, or `allotment_control_block`.
+- Cancel Booking: do not default-create S07 just because the canceled row contains historical extra bed / Guest Request. Only generate S07 when current explicitly asks to write a post-cancel note / trace.
+
+## Output Requirements
+
+- Record use of this reference in `context_used`.
+- Preserve raw table evidence in `extracted_fields` when available: attachment name, sheet name, row number or row label, highlight status, action/status column value, raw date range, raw room type, raw room quantity, raw rate, and before/after evidence.
+- Preserve composite unit price evidence when available: raw price expression, base room-price component, additional-charge component, and whether Fix Charge was detected.
+- When outputting `manual_review`, include missing or ambiguous table evidence in `manual_review.evidence_to_check`, such as attachment name, sheet name, row number, highlight/color state, strikethrough state, or unreadable cells.
diff --git a/docs/import/20260706/0630AI_副本 2/skill/S01_new_booking_skill.md b/docs/import/20260706/0630AI_副本 2/skill/S01_new_booking_skill.md
new file mode 100644
index 0000000..1a6d5d7
--- /dev/null
+++ b/docs/import/20260706/0630AI_副本 2/skill/S01_new_booking_skill.md	
@@ -0,0 +1,469 @@
+# S01 New Booking Skill
+
+## 1. Skill Identity
+
+- catalog_code: `S01`
+- skill_id: `new_booking_skill`
+- skill_name: `New Booking Skill`
+- task_type: `New Booking`
+
+## 2. Purpose
+
+本 Skill 用于判断一条来自 `body_current` 的当前邮件事件，是否可以生成 New Booking 任务。
+
+第一版判断保持简单：
+
+- 可以安全创建 New Booking 任务：输出 `normal_task`
+- 不能安全自动处理：输出 `manual_review`
+
+本 Skill 不直接写数据库或外部系统，不写 Opera，不确认 Payment，不生成 Receipt。
+
+New Booking 可以携带 Fix Charge / 固定费用附加执行项。Fix Charge 不改变主任务类型；主任务仍是 New Booking，附加收费信息写入 `extracted_fields.fix_charge_items` 和 `additional_operations`，供信息系统在订单创建成功后继续处理。
+
+如果本 Skill 输出 `ai_task_result` 且通过统一输出校验，AI 运行时 / Main Agent / Skill Orchestrator 后续可调用信息系统提供的统一受控 Tool / API 创建普通任务卡、人工复核 / 人工处理任务卡或信息系统可展示记录。真实 TaskCard ID、任务状态机、幂等控制、并发保护和执行前硬校验仍由信息系统负责。
+
+## 3. Scope
+
+本 Skill 覆盖以下新建预订对象：
+
+- FIT Reservation
+- Group Block
+- Allotment / Control Block 类新建控房订单
+- LianTai / 旅行社语境中的配合房、取配、父团拆子团创建；即使 current 文本写作 `AMEND + FINAL BOOKING`，只要实质是在给多个新子 `group_code` 分配房量，在酒店系统中按 New Booking / Allotment creation 处理
+
+对象类型判断参考：
+
+- 房间数小于 5 间，通常按 FIT Reservation 理解。
+- 房间数 5 间及以上，通常按 Group Block 理解。
+- 邮件明确出现 allotment、allocation、control block、控房、配额等语义时，按 Allotment / Control Block 类新建对象理解。
+- 邮件当前正文若列出父 group code，并在 `AMEND TO`、`AMED TO`、取配、配合房、allocation 等语义后列出多个子 group code、日期、晚数、房型和房量，按 Allotment / Control Block 类新建对象理解；父 group code 只作为 `parent_group_code` / `allocation_parent_group_code` evidence。
+
+Extra bed / 加床 / `เตียงเสริม` 属于 Trace / Guest Request，不属于房型或房量：
+
+- 不计入 `room_quantity`。
+- 不影响 FIT / Group 判断。
+- 不作为独立房型映射。
+- 不单独决定 Rate Code。
+- 如果与 New Booking 同一事件或同一表格行出现，仍由本 Skill 处理 New Booking 主任务，同时生成 S07 Trace / Reservation Notes linked task；先处理 S01，再处理 S07。
+
+Fix Charge / 固定费用属于 New Booking 的附加收费能力，不属于独立任务类型：
+
+- 不因为 `TWN` / `DBL` / 普通房型本身触发 Fix Charge。
+- 不因为普通价格如 `2000THB`、`1800THB` 本身触发 Fix Charge。
+- 只有当 current 事件或 LianTai 表格酒店说明价格区出现可拆分的复合单价结构，例如 `2000THB+500`、`1800THB+500`、`2000THB*2` 换行后 `+附加500*2`，才识别 Fix Charge。
+- `+` 前的房费单价组件用于 Rate Code 判断；`+` 后的附加费用单价组件写入 `extracted_fields.fix_charge_items`。
+- AI 不负责从该表达计算数量或总额。
+
+本 Skill 的房型映射与 Rate Code 判断规则不直接写在主文档正文中，而是作为 bundled references 维护：
+
+- `S01_new_booking_skill/references/room_type_mapping_rules.md`
+- `S01_new_booking_skill/references/rate_code_rules.md`
+
+当 current 邮件涉及房型、房型代码、Rate Code、结算价格、渠道、市场类别、早餐或用餐餐厅时，应按需读取对应 reference。
+
+## 4. When To Use
+
+当 `body_current` 中明确提出创建新的预订对象时，Main Agent 可以调用本 Skill。
+
+典型语义包括：
+
+- 新建 FIT 预订。
+- 新建 Group Block。
+- 新建控房 / 配额 / Control Block。
+- 新建配合房 / 取配 / Allotment，或 `AMEND + FINAL BOOKING` 实质为父团拆成多个子 group 的房量分配。
+- 邮件当前内容包含新订单所需的基本信息，或通过附件提供新订单信息。
+
+## 5. Must Not Use When
+
+以下情况不得使用本 Skill 生成 `normal_task`：
+
+- 当前邮件是在修改既有订单。
+- 当前邮件是在取消订单。
+- 当前邮件是在取消控房 / 配额 / Control Block。
+- 当前邮件只是提交 Rooming List / Name List。
+- 当前邮件只是收到 Voucher、Credit Voucher、payment slip 或 payment confirmation。
+- 当前邮件只是添加 Trace、Reservation Notes 或 Guest Request。
+- 当前邮件只是为既有订单添加、修改或取消 extra bed / 加床 / `เตียงเสริม`，且没有新的创建动作。
+- 当前邮件只是修改 Group Code、Block Code、Block Name 或 Group Name。
+- 新建预订动作只出现在 `body_thread`，不在 `body_current`。
+- 当前邮件只是 thank you、FYI、acknowledgement、noted、received、confirmed receipt、确认收到、转发说明、仅同步信息或无新业务动作。
+- 邮件只是追问、确认、转发历史信息，没有新的创建动作。
+
+如果邮件语义无法安全区分 New Booking 与 Update Booking，应结合 `routing_context` 判断；仍无法判断时输出 `manual_review` 或交由 `exception_detection_skill` 处理。
+
+## 6. Allowed Result Types
+
+第一版只允许：
+
+- `normal_task`
+- `manual_review`
+
+第一版不输出：
+
+- `exception_task`
+- `no_action`
+- `informational_message`
+
+原因：New Booking 的第一版判断只区分“可以安全创建”与“需要人工确认”，不做复杂异常分类；明确轻量消息通知由 `message_notification_skill` 处理。
+
+## 7. Key Context Needed
+
+Main Agent 应尽量提供以下上下文：
+
+- `source_message_id`
+- `source_event_index`
+- 当前邮件事件文本，只能来自 `body_current`
+- 当前邮件相关附件摘要
+- `group_code`
+- `confirmation_number`
+- 房间数
+- 入住 / 离店日期
+- 客人姓名、团队名称或 block 名称
+- supplier / sender 线索
+- 房型原文、床型、人数、是否套房、是否家庭房等可用于房型映射的线索
+- 渠道 / 市场类别、备注价格、是否含早餐、用餐餐厅、实际结算价格等可用于 Rate Code 判断的线索
+- extra bed / 加床 / `เตียงเสริม` 等 Trace / Guest Request 线索
+- LianTai 复合单价、附加费、Fix Charge 原文线索
+- `routing_context`
+
+`routing_context` 至少应覆盖：
+
+- 同 key 是否已有已完成 / 已写入的 FIT Reservation
+- 同 key 是否已有已完成 / 已写入的 Group Block
+- 同 key 是否已有已完成 / 已写入的 Allotment / Control Block 或其他有效订单记录
+- 同 key 是否已有 pending / open task
+- 同 key 是否已有 active workflow
+- 同 key 是否已有 terminated record
+
+`body_thread` 只能作为 evidence context，不得作为生成 New Booking `normal_task` 的来源。
+
+## 8. Input Requirements Summary
+
+本 Skill 输入应包含：
+
+- 当前事件摘要
+- 当前邮件原文片段
+- 附件摘要
+- 已提取的核心 key
+- 路由级查询结果
+- 与新建判断直接相关的基础业务字段
+- 能帮助房型映射、Rate Code 判断或手工结算价格维护的上下文线索
+- 能帮助识别 Fix Charge / 固定费用的复合单价、附加费、酒店说明列原文
+- 与新建任务同一事件出现的 Trace / Guest Request 线索，例如 extra bed / 加床 / `เตียงเสริม`
+
+本 Skill 不要求 Main Agent 在输入阶段固定完整 `extracted_fields` schema。
+
+具体字段抽取、字段标准化、必填字段、附件解析规则，应放在本 Skill 后续详细字段章节、bundled references 或统一输出契约中维护。
+
+### 8.1 Bundled / Shared References
+
+本 Skill 可按需读取以下 references：
+
+- `references/room_type_mapping_rules.md`
+  - 当 current 邮件涉及房型、房型代码、套房、家庭房、`Q10`、`U-DBL`、`U-TWN`、`U-TRP`、`HNM` 等房型语义时读取。
+  - 用于将邮件原始房型映射到 Opera 房型代码。
+
+- `references/rate_code_rules.md`
+  - 当 current 邮件涉及 Rate Code、结算价格、渠道 / 市场类别、supplier、备注价格、早餐、用餐餐厅或手工价格维护时读取。
+  - 用于判断可选 Rate Code、是否需要手工录入具体结算价格，以及需要哪些人工确认字段。
+  - 当 current 事件是新建控房 / 配额 / Allotment / Control Block，且邮件没有明示 Rate Code 时，也必须读取；若房型命中控房默认补全规则，应自动补全房型代码和结算价格。
+  - 当 current 事件或 LianTai 表格酒店说明价格区出现 `2000THB+500`、`1800THB+500`、`2000THB*2` 换行后 `+附加500*2` 等复合单价表达时必须读取；用于拆分房费单价组件和 Fix Charge 单价组件。
+
+- `../references/qbd_liantai_email_table_rules.md`
+  - When the current message, attachment, sender, subject, or extracted evidence indicates QBD or LianTai Excel/table workflow, read this shared reference.
+  - 触发条件包括：QBD / LianTai 发件人或渠道、QBD / LianTai 表头、Excel / table 附件、`BOOKING UPDATE`、`NEW BOOKING`、`AMEND`、`AMD ALLOTMENT`、`CXL`、`CFM`、黄色 / 高亮行、红字、划线、`โรงแรม` 或酒店状态列等线索。
+  - 用于判断表格行是否代表当前 New Booking 请求、黄色 / 高亮行如何拆成独立 current events、新建对象是 FIT / Group Block / Allotment Control Block，以及总房量如何影响 FIT / Group 路径。
+
+Reference 使用原则：
+
+- 只有 reference 中规则唯一命中时，才可将映射结果写入 `extracted_fields`。
+- `pms_room_type_code` 必须来自 `references/room_type_mapping_rules.md` 的唯一命中；`references/rate_code_rules.md` 可以引用房型代码，但不得作为房型映射唯一来源。
+- `ST+K:2卧1厅=1200` + `FAMILY 1` 是跨 QBD / LianTai 渠道可识别的房型表达，房型映射可命中 `SU3`；Rate Code 必须继续按渠道判断。
+- 如果 QBD / LianTai reference 识别出多个当前有效黄色 / 高亮 `NEW BOOKING` 行，必须按行拆分：一行一个 `source_event_index`，一行一个 `ai_task_result`，一行一个下游 task card 候选；不得跨行合并。
+- 如果 QBD / LianTai reference 识别出 parent-to-child `AMEND + FINAL BOOKING` 配合房 / Allotment 创建文本，必须按子 group code 拆分：一个子 group code 一个 `source_event_index`、一个 S01 `ai_task_result`、一个下游 task card 候选；不得用父 group code 的单个 S02 Update 结果代替。
+- parent-to-child 配合房场景中，`parent_group_code` 不作为本任务的 `case_keys.group_code`；`case_keys.group_code` 必须是该子行 / 子事件自己的 child group code。
+- 这种场景不要求建立 S02 意义上的 before / after。父团原房量、父团日期和父团号应保留在 `extracted_fields.parent_allocation_context`，供后台展示和硬校验。
+- 即使多行共享同一 `group_code`、`confirmation_number`、日期、酒店、批次、supplier、主题或附件，也不得合并为一个 New Booking task。
+- 不得用单个结果里的 `source_event_count`、数组型 `case_keys.group_code`、汇总型 `highlighted_rows` 或跨行 `room_items` 代替多个逐行 `ai_task_results`。
+- 如果一行内包含多个房型 / 房量 / 价格明细，可放入该行自己的 `extracted_fields.room_items` 或等价结构；不同表格行之间不得合并。
+- 如果某一行信息不完整或不能安全处理，只让该行输出结构化 `manual_review`，不得阻塞其他可正常处理的行。
+- Extra bed / 加床 / `เตียงเสริม` 是 Trace / Guest Request，不得计入 `room_quantity`，不得影响 FIT / Group 判断，不得作为独立房型映射，不得单独决定 Rate Code。
+- 如果 extra bed 与 New Booking 同一表格行出现，主任务仍是 New Booking；同时生成 S07 linked task，并在后台 payload 保留 extra bed 数量和原文。
+- 示例：`Sup 高级房TWN 4 + extra bed 2` 中 `room_quantity = 4`，`extra_bed_quantity = 2`，extra bed 生成 S07 linked task。
+- 房型映射不得覆盖原始房型关键线索。即使 `U-TWN` 与 `Sup 高级房TWN` 都映射到 `RM3`，或 `U-DBL` 与 `Sup 高级房DBL` 都映射到 `RM2`，Rate Code 仍必须按原始 `U-` / `Sup` / `高级房` 线索判断。
+- 如果 reference 明确要求手工录入或修改价格，且实际价格可可靠提取，可以输出 `normal_task`，并在 `extracted_fields` 中标记手工价格维护要求。
+- 如果 LianTai 复合单价表达与 New Booking 同一事件或同一表格行出现，主任务仍是 New Booking；将房费单价组件写入 `rate_code_result`，将附加费用单价组件写入 `fix_charge_items`。
+- 没有复合单价或附加费组件时，继续按既有房型 / Rate Code 规则处理，不因缺少 Fix Charge 输出 `manual_review`。
+- 对于新建控房 / 配额 / Allotment / Control Block，如果邮件没有明示 Rate Code，但 `references/rate_code_rules.md` 的控房默认补全规则可按房型唯一命中，不得仅因缺少 Rate Code 输出 `manual_review`；应在 `extracted_fields` 中记录自动补全结果。
+- 如果房型、渠道、市场类别、早餐、餐厅、价格或上下文不足以唯一命中规则，输出结构化 `manual_review`。
+- 如果 reference 没有覆盖当前表达，不得靠常识猜测房型代码或 Rate Code。
+- If any trigger signal is present but the table/highlight/row evidence is unavailable, unreadable, or ambiguous, do not guess. Output structured manual_review and include the missing table evidence in manual_review.evidence_to_check.
+- `context_used` 应记录使用了哪个 reference 以及命中的规则摘要。
+
+## 9. Decision Rules
+
+1. 先确认 New Booking 动作是否出现在 `body_current`。
+2. 如果 New Booking 动作只出现在 `body_thread`，不得输出 `normal_task`。
+3. 判断当前事件是否确实是创建新对象，而不是修改、取消、名单、Voucher、Trace 或改 Group Code。
+   - 如果 current 文本含 `AMEND + FINAL BOOKING` / `AMEND TO` / `AMED TO`，但业务形态是父团拆为多个子 `group_code` 并给出各子 code 的房量分配，按新建配合房 / Allotment 创建处理，不因 `AMEND` 字样改走 S02。
+4. 如果能提取到 `group_code` 或 `confirmation_number`，必须使用对应 `routing_context`。
+5. 如果 routing context 显示同 key 已存在已完成 / 已写入的有效订单记录，不得输出 `normal_task`。
+6. 如果 routing context 显示同 key 已存在 pending / open task 或 active workflow，第一版不得输出 `normal_task`。
+7. 如果涉及房型映射，应读取 `references/room_type_mapping_rules.md`；只有唯一命中时，才可填入 Opera 房型代码。
+8. 如果涉及 Rate Code 或结算价格，应读取 `references/rate_code_rules.md`；只有唯一命中、满足 reference 中“手工价格仍可 normal_task 的条件”，或新建控房 / 配额 / Allotment / Control Block 缺 Rate Code 但命中控房默认补全规则时，才可继续创建任务。
+9. 如果 current 邮件、附件、发件人、主题或抽取证据显示 QBD / LianTai Excel/table workflow，应读取 `../references/qbd_liantai_email_table_rules.md`；只有当前表格行、高亮 / 黄色行、行证据和对象类型可靠时，才可基于表格输出 `normal_task`。
+10. 对 QBD / LianTai 表格中的多个当前有效黄色 / 高亮 `NEW BOOKING` 行，必须按行拆分；每一行生成独立 `source_event_index` 和独立 `ai_task_result`，不得跨行合并，不得用 `source_event_count` 或数组型 `case_keys.group_code` 代替。
+10a. 对 QBD / LianTai / 旅行社 current 文本中的 parent-to-child `AMEND + FINAL BOOKING` 配合房创建，必须按每个 child group code 拆分；当 child code、stay dates、nights、room_items 和对象类型可读时，输出 S01 `normal_task`，并在 `extracted_fields` 保留 `booking_object_type="Allotment / Control Block"`、`parent_group_code`、`allocation_split_from_parent=true`、`allocation_child_group_code`、`parent_allocation_context`。
+    - 如果 child line 中包含通用 `SUITE` 且未给出 `TWN SUITE` / `DBL SUITE` / 明确床型，保留该 room item 的 `raw_room_type="SUITE"`、`pms_room_type_code=null`、`room_type_mapping_status="requires_downstream_room_type_validation"`；在 parent-to-child Allotment 测试口径下，不因此把整封或其他 child line 合并为 `manual_review`，但必须标记 `requires_downstream_hard_validation=true`。如果信息系统要求创建任务前必须有最终 PMS suite code，只该 child line 输出结构化 `manual_review`，不得阻塞其他 child lines。
+11. 如果 extra bed / 加床 / `เตียงเสริม` 与 New Booking 同一事件出现，主任务仍是 New Booking，同时生成 S07 linked task；不得把 extra bed 数量计入 `room_quantity`，不得用于 FIT / Group 判断。
+12. 如果 current 邮件只是为既有订单添加、修改或取消 extra bed / 加床 / `เตียงเสริม`，不得路由为 New Booking；应路由到 Trace / Reservation Notes Skill。
+13. 如果 LianTai 复合单价表达出现，应按 `references/rate_code_rules.md` 拆分房费单价和 Fix Charge 单价；不得把 `2000+500` 合并为 `2500` 判断 Rate Code。
+14. 如果 key 缺失、对象身份不清、邮件语义混杂、current/history 边界不清、房型映射无法唯一确认、Rate Code 无法唯一确认、结算价格无法可靠确认，或 QBD / LianTai 表格高亮 / 行证据不可读或不明确，输出 `manual_review`。
+15. 如果当前邮件是感谢、确认、FYI、noted、received、confirmed receipt、转发说明等轻量信息，但需要用户可见记录，不应路由到本 Skill，应由 `message_notification_skill` 输出 `informational_message`。
+16. 只有当前事件明确是 New Booking，routing context 未发现阻断自动创建的既有记录、pending/open task、active workflow 或终止冲突，且房型 / Rate Code / Fix Charge / QBD-LianTai 表格相关规则已可靠处理时，才能输出 `normal_task`。
+
+## 10. Normal Task Output
+
+仅当可以安全创建 New Booking 任务时，输出：
+
+```json
+{
+  "result_type": "normal_task",
+  "task_type": "New Booking",
+  "current_or_history": "current"
+}
+```
+
+完整输出必须符合统一输出契约。
+
+关键要求：
+
+- `source_message_id` 必须原样带回。
+- `source_event_index` 必须原样带回。
+- `case_keys.group_code` 和 `case_keys.confirmation_number` 按实际提取结果填写。
+- `visible_reason` 应说明为什么这是当前邮件中的 New Booking 请求。
+- `relevant_message_excerpt` 必须来自 `body_current`。
+- `attachments` 只包含当前事件相关附件。
+- `context_used` 应记录用于判断的 routing context 摘要。
+- `extracted_fields` 应填入可可靠抽取的新建预订字段。
+- 如果涉及房型映射，应在 `extracted_fields` 中保留原始房型、归一化房型、命中规则和 Opera 房型代码。
+- 如果涉及 Rate Code，应在 `extracted_fields` 中保留渠道 / 市场类别、备注价格、结算价格、命中规则、Rate Code 或手工价格维护要求。
+- 如果使用手工结算价格维护，必须在 `extracted_fields.rate_code_result` 中写入 `rate_code=null`、`settlement_price`、`manual_settlement_price_required=true`、`manual_price_reason_code` 和 `price_evidence`。
+- 如果涉及 LianTai 复合单价，应在 `extracted_fields.rate_code_result` 中保留 `raw_price_expression`、`composite_unit_price_detected`、`base_room_price_component`、`additional_charge_component`、`settlement_price`、`rate_code` 和命中规则摘要。
+- 如果涉及 Fix Charge，应在 `extracted_fields.fix_charge_required`、`extracted_fields.fix_charge_items` 和 `extracted_fields.additional_operations` 中保留附加费用单价、币种、原文证据和后续 Tool 占位；没有 Fix Charge 时可填 `fix_charge_required=false`、`fix_charge_items=[]`。
+- `extracted_fields.fix_charge_items[]` 建议包含 `charge_type`、`amount`、`currency`、`pricing_mode`、`unit_basis`、`quantity=null`、`total_amount=null`、`raw_text`、`evidence_source`、`requires_followup_tool=true`、`followup_tool_name=create_fix_charge / TBD`。
+- `extracted_fields.additional_operations[]` 建议包含 `operation_type=create_fix_charge` 和 `status=pending_booking_id`；如果后续系统使用其他状态枚举，以信息系统契约为准。
+- 如果是新建控房 / 配额 / Allotment / Control Block 且邮件未明示 Rate Code，但按控房默认补全规则命中，应在 `extracted_fields.rate_code_result` 中记录 `auto_completed_from_control_block_room_type_default`、原始房型、归一化房型、`pms_room_type_code`、结算价格和 `rate_code_missing_in_email=true`。
+- 如果是 parent-to-child 配合房 / Allotment 创建，应在 `extracted_fields` 中记录 `allocation_split_from_parent=true`、`parent_group_code`、`allocation_child_group_code`、`parent_original_room_summary`、`child_room_items`、`allocation_context_source="body_current"`；父团原房量不作为本子任务的 `room_quantity`。
+- 如果来自 QBD / LianTai 表格行，应在 `extracted_fields` 中保留该行的附件名、sheet 名、行号或行标签、高亮状态、动作 / 状态单元格、原始日期、原始房型、原始房量和原始价格；一行内多个房型 / 房量 / 价格明细应放入该行自己的 `room_items` 或等价结构。
+- 如果来自 QBD / LianTai 多行表格，单个 `ai_task_result` 只能代表一个当前有效行；`case_keys.group_code` 应只填该行 key。
+- 如果同一事件包含 extra bed / 加床 / `เตียงเสริม`，应生成 S07 linked task；同时可在本任务后台 payload 中保留原文、数量和说明，`room_quantity` 必须排除 extra bed 数量。
+- `context_used` 应记录使用的 reference 文件与命中规则摘要。
+- `exception` 必须为 `null`。
+- `no_action` 必须为 `null`。
+
+## 11. Manual Review Output
+
+当邮件看起来是 New Booking，但不能安全自动创建时，输出：
+
+```json
+{
+  "result_type": "manual_review",
+  "task_type": "New Booking",
+  "current_or_history": "current"
+}
+```
+
+典型原因包括：
+
+- 同 key 已有有效订单记录。
+- 同 key 已有 pending / open New Booking task。
+- 同 key 已有 active workflow。
+- 邮件可能其实是在修改既有订单，但表达成了新建。
+- 缺少关键 key，无法确认对象身份。
+- current/history 边界不清。
+- 一个 current 事件混合多个新建对象，且无法安全拆分。
+- QBD / LianTai 表格触发信号存在，但表格、黄色 / 高亮行、行号、划线或当前行证据不可读、缺失或不明确。
+- 房型映射 reference 未覆盖当前表达，或存在多个候选。
+- Rate Code reference 无法根据渠道、市场、房型、早餐、餐厅或备注价格唯一匹配。
+- 新建控房 / 配额 / Allotment / Control Block 缺 Rate Code，但房型无法命中控房默认补全规则，或 `U-TRP` / `FAM` / `6+4` 关系无法可靠确认。
+- reference 要求手工录入价格，但实际结算价格无法可靠提取。
+- 手工价格维护条件未全部满足，例如房型未唯一映射、价格不来自 `body_current` / 当前表格行、价格不可读、核心日期 / 房量 / 对象类型不可靠，或 routing context 存在阻断。
+- 出现复合单价或附加费用线索，但无法判断哪一段是房费单价、哪一段是附加费用单价。
+- Fix Charge 金额无法可靠提取，或同一行多个价格组件无法归属。
+
+`manual_review` 不能只是“人工看一下”。它必须带结构化信息，方便信息系统创建人工复核 / 人工处理任务卡。
+
+即使输出 `manual_review`，也要尽力结构化抽取：
+
+- 能确定的 `case_keys` 必须填入。
+- 能确定的 `candidate_object_type` 应填入 `extracted_fields`，例如 `FIT Reservation`、`Group Block`、`Allotment / Control Block`。
+- 能确定的新建预订字段应填入 `extracted_fields`，例如 `arrival_date`、`departure_date`、`room_quantity`、`room_type`、`guest_name`、`group_code`、`confirmation_number`、`supplier`。
+- 能确定的原始房型、归一化房型、候选 Opera 房型代码、候选 Rate Code、候选结算价格，应尽量填入 `extracted_fields`。
+- 能确定的复合单价拆分结果和 Fix Charge 单价，应尽量填入 `extracted_fields.rate_code_result` 与 `extracted_fields.fix_charge_items`。
+- 不能可靠确认的字段不要猜，填 `null`、空字符串或空数组。
+- 不能唯一确认的房型映射或 Rate Code，不要猜，填 `null` 或候选数组。
+- 不确定原因必须写入 `manual_review.reason_code`。
+- 缺失字段写入 `manual_review.missing_fields`。
+- 阻塞点写入 `manual_review.blocking_points`。
+- 冲突点写入 `manual_review.conflicting_points`。
+- 建议人工处理动作写入 `manual_review.suggested_human_actions`。
+- 建议人工查看的证据写入 `manual_review.evidence_to_check`。
+- 如房型或 Rate Code 无法自动确认，`manual_review.evidence_to_check` 应包含相关 reference 文件名以及需要人工核对的邮件片段、附件或系统上下文。
+- 人工复核记录类型写入 `manual_review.review_record_type`。
+
+当同 key 已有有效订单记录时，`visible_reason` 应明确提示：
+
+```text
+该 key 疑似已存在有效订单记录，不能继续自动创建 New Booking，需要人工业务确认并中止或改派当前自动处理流程。
+```
+
+建议结构：
+
+```json
+{
+  "manual_review": {
+    "reason_code": "",
+    "visible_reason": "",
+    "review_record_type": "",
+    "blocking_points": [],
+    "missing_fields": [],
+    "conflicting_points": [],
+    "suggested_human_actions": [],
+    "evidence_to_check": []
+  }
+}
+```
+
+`review_record_type` 第一版建议使用：
+
+- `manual_review_required`
+- `manual_processing_required`
+
+示例语义：
+
+```json
+{
+  "case_keys": {
+    "group_code": "LLT260727FA",
+    "confirmation_number": null
+  },
+  "extracted_fields": {
+    "candidate_object_type": "Group Block",
+    "arrival_date": "2026-07-27",
+    "departure_date": null,
+    "room_quantity": 10,
+    "room_type": "Deluxe Twin",
+    "guest_name": null,
+    "group_code": "LLT260727FA",
+    "confirmation_number": null,
+    "supplier": "TBD"
+  },
+  "manual_review": {
+    "reason_code": "EXISTING_ORDER_RECORD_FOUND",
+    "visible_reason": "该 Group Code 疑似已存在有效订单记录，不能继续自动创建 New Booking。",
+    "review_record_type": "manual_review_required",
+    "blocking_points": ["routing context 显示同 key 已存在有效订单记录"],
+    "missing_fields": ["departure_date"],
+    "conflicting_points": [],
+    "suggested_human_actions": ["核对既有订单记录，确认当前邮件是重复新建、修改请求还是需中止处理"],
+    "evidence_to_check": ["body_current", "routing_context.matched_order_records"]
+  }
+}
+```
+
+房型 / Rate Code 无法唯一确认时的典型 reason_code 可使用：
+
+- `ROOM_TYPE_MAPPING_UNCONFIRMED`
+- `ROOM_TYPE_MAPPING_MULTIPLE_CANDIDATES`
+- `RATE_CODE_UNCONFIRMED`
+- `SETTLEMENT_PRICE_REQUIRED`
+- `MANUAL_PRICE_UNCONFIRMED`
+- `RATE_CODE_RULE_NOT_COVERED`
+- `COMPOSITE_UNIT_PRICE_UNCONFIRMED`
+- `FIX_CHARGE_UNCONFIRMED`
+
+## 12. Tool Invocation Placeholder
+
+当前创建任务卡 / 可见记录的具体 Tool / API 尚未实现，本节只预留对接位置和语义契约，不定义最终 endpoint、鉴权方式或完整返回结构。
+
+- tool_status: `TBD`
+- suggested_tool_name: `create_task_card` / `TBD`
+- tool_purpose: 根据信息系统统一任务卡创建接口，创建普通任务卡、人工复核 / 人工处理任务卡或信息系统可展示记录。
+- followup_tool_name: `create_fix_charge` / `TBD`
+- followup_tool_purpose: 当 New Booking 创建成功并取得 reservation / confirmation / PMS booking id 后，为对应订单添加 Fix Charge / 固定费用。
+- tool_owner: 信息系统。
+- caller: AI Runtime / Main Agent / Skill Orchestrator，最终由系统架构确认。
+- invocation_timing: Skill 输出 `ai_task_result` 并通过 Unified Output Contract 校验后。
+- followup_invocation_timing: 仅在 `create_task_card` 或后续信息系统流程确认 New Booking 已成功创建并取得订单 ID 后；如果订单 ID 尚未生成，只保留 `additional_operations`，不得编造 Tool 调用结果。
+- payload_rule: Skill 能抽取出的字段照实填入；任务卡需要但无法抽取的字段填 `null` / empty，并在 `manual_review.missing_fields` 或 `manual_review.blocking_points` 中说明。
+- mapping_payload_rule: 如果涉及房型映射或 Rate Code 判断，应将原始值、归一化值、命中 reference、命中规则摘要、最终代码或候选项写入 `extracted_fields`；不得只写最终结果而丢失依据。
+- fix_charge_payload_rule: 如果涉及 Fix Charge，应将 `fix_charge_required`、`fix_charge_items`、`additional_operations`、原文证据、金额、币种、pricing mode 和后续 Tool 占位写入 `extracted_fields`；AI 不计算数量或总额。
+- must_not_call_when:
+  - Skill 输出不符合统一契约
+  - current 事件完全不应进入 AI 工作台记录
+  - 输出内容缺少任务卡 / 可见记录创建所需的最低溯源字段
+- followup_must_not_call_when:
+  - New Booking 尚未创建成功或缺少 reservation / confirmation / PMS booking id
+  - Fix Charge 金额无法可靠提取
+  - 复合单价无法可靠拆分
+  - 输出内容不符合统一契约
+- minimum_payload_should_include:
+  - `source_message_id`
+  - `source_event_index`
+  - `catalog_code`
+  - `skill_id`
+  - `result_type`
+  - `task_type`
+  - `case_keys`
+  - `visible_reason`
+  - `relevant_message_excerpt`
+  - `attachments`
+  - `context_used`
+  - `extracted_fields`
+  - `manual_review`
+  - `additional_operations`
+  - `idempotency_key` / `TBD`
+- expected_tool_result: `TBD`
+
+Tool 设计原则：
+
+- New Booking Skill 只调用一个统一任务卡创建 Tool：`create_task_card`。
+- `create_fix_charge / TBD` 是后续执行 Tool，不替代 `create_task_card`，也不改变主任务类型。
+- AI 不直接写数据库，只调用信息系统暴露的受控 Tool / API。
+- 信息系统负责生成真实任务卡 ID、人工复核任务卡 ID 或可见记录 ID。
+- 信息系统负责幂等、并发、状态机和最终落库。
+- 信息系统在创建任务卡或执行前仍需做硬校验，不能只依赖 AI 判断。
+- 如果 Tool 尚不可用，本 Skill 仍应输出合格的 `ai_task_result`；不得编造 Tool 调用结果。
+
+## 13. Conflict Or Fallback Rule
+
+- 如果当前事件同时像 New Booking 和 Update Booking，应优先查看 routing context。
+- 如果 routing context 显示已有有效订单，第一版输出 `manual_review`，不继续创建 New Booking。
+- 如果 routing context 显示已有 pending / open task 或 active workflow，第一版输出 `manual_review`。
+- 如果房型映射或 Rate Code 判断无法唯一命中 reference，不由 Main Agent 自行猜测，由本 Skill 输出结构化 `manual_review` 或创建明确的手工价格维护任务。
+- 如果仍无法判断是 New Booking、Update Booking 或其他任务类型，交由 `exception_detection_skill` 或输出 `manual_review`。
+- Main Agent 不应自行把 New Booking 改判为 duplicate、exception 或 no_action。
+
+## 14. Must Not Do
+
+- 不得从 `body_thread` 生成 New Booking `normal_task`。
+- 不得在同 key 已有有效订单记录时继续输出 `normal_task`。
+- 第一版不得输出 `exception_task`。
+- 第一版不得输出 `no_action`。
+- 不得输出 `informational_message`；明确轻量消息通知应路由到 `message_notification_skill`。
+- 不得在 Main Agent 中修补本 Skill 输出。
+- 不得把 `manual_review` 输出成空泛的“人工看一下”。
+- 不得在无法可靠确认字段时猜测字段值。
+- 不得在 reference 未覆盖或无法唯一命中时猜测 Opera 房型代码。
+- 不得在 reference 未覆盖或无法唯一命中时猜测 Rate Code。
+- 不得忽略 reference 中“手工录入具体结算价格”的要求。
+- 不得因为看到 `TWN` / `DBL` 或普通价格就触发 Fix Charge。
+- 不得把 `2000+500` 合并为 `2500` 判断 Rate Code。
+- 不得从复合单价表达计算 Fix Charge 数量或总额。
+- 不得编造尚未实现的 Tool endpoint、鉴权、返回结构或调用结果。
+- 不得绕过信息系统 Tool / API 直接创建真实 TaskCard。
+- 不得写 Opera。
+- 不得确认 Payment。
+- 不得生成 Receipt。
+- 不得修改数据库。
diff --git a/docs/import/20260706/0630AI_副本 2/skill/S01_new_booking_skill/references/rate_code_rules.md b/docs/import/20260706/0630AI_副本 2/skill/S01_new_booking_skill/references/rate_code_rules.md
new file mode 100644
index 0000000..83a9097
--- /dev/null
+++ b/docs/import/20260706/0630AI_副本 2/skill/S01_new_booking_skill/references/rate_code_rules.md	
@@ -0,0 +1,355 @@
+# Rate Code 识别规则
+
+本文档整理当前已确认的 Rate Code 判断逻辑。判断时先识别渠道，再套用对应渠道规则；不管哪个渠道，只要无法匹配到可选 Rate Code，最终都改为手工录入具体结算价格。
+
+## 总原则
+
+1. 先判断订单渠道或市场类别：目前已整理 `QBD`、`LianTai`、其他市场代理、特殊类别、AI 代理、批发商、导游房等规则。
+2. 按渠道套用对应规则，不混用不同渠道的判断逻辑。
+3. Rate Code 判断必须保留原始房型关键线索，例如 `Sup`、`高级房`、`U-`。不得只根据映射后的 Opera Room Type Code（如 `RM2` / `RM3`）判断 Rate Code。
+4. 同样映射到 `RM2` / `RM3`，不代表 Rate Code 相同。例如 LianTai 中 `Sup 高级房TWN` 与 `U-TWN` 都可映射到 `RM3`，但 Rate Code 不同。
+5. `pms_room_type_code` 必须来自 `room_type_mapping_rules.md` 的唯一命中；本文可引用该代码作为判断依据，但不得作为房型映射的唯一来源。
+6. 对于 New Booking 中的新建控房 / 配额 / Allotment / Control Block，如果邮件没有明示 Rate Code，但房型可命中本文的控房默认补全规则，应按房型自动补全房型代码和结算价格，不得仅因缺少 Rate Code 输出 manual_review。
+7. LianTai 复合单价表达中的附加费用组件不参与 Rate Code 判断；不得把 `2000+500` 合并为 `2500` 判断 Rate Code。
+8. 如果订单数据无法匹配任何 Rate Code，或者系统内无法选择对应 Rate Code，则不强行选择代码，改为手工录入具体结算价格。
+
+## New Booking 控房 / 配额 / Control Block 缺 Rate Code 自动补充规则
+
+本节适用于 `new_booking_skill` 中的新建控房 / 配额 / Allotment / Control Block 类任务。
+
+当 current 邮件明确是新建控房、配额或 Control Block，且邮件没有直接写出 Rate Code 时，先按房型自动补全以下字段：
+
+| 原始房型 / 表达 | Opera Room Type Code | 结算价格 |
+|---|---|---:|
+| `U-DBL` | `RM2` | 850 |
+| `U-TWN` | `RM3` | 850 |
+| `U-TRP` / `U-TRP=FAM (6+4)` / `FAM (6+4)` | `RM4` | 1275 |
+
+输出要求：
+
+- 不要因为邮件未明示 Rate Code 就直接输出 `manual_review`。
+- 在 `extracted_fields` 中保留原始房型、归一化房型、`pms_room_type_code`、结算价格、命中规则，以及 `rate_code_missing_in_email=true`。
+- 如统一输出契约有 `rate_code_result`，应标记为 `auto_completed_from_control_block_room_type_default`，并写入对应房型代码、价格和已确认的 Rate Code。
+- 对于 `U-DBL` / `U-TWN`，如 LianTai 原始房型线索明确，可按 LianTai 原始房型关键线索规则写入 `WHO1-850UP`。
+- 如果一条控房任务包含多个房型，按房型逐项补全。
+- 如果房型不在本表，或 `U-TRP` / `FAM` / `6+4` 关系无法确认，输出结构化 `manual_review`，并在 `manual_review.evidence_to_check` 中提示人工核对房型和 Rate/价格规则。
+- 当前只对本文明确覆盖的房型写入 Rate Code；例如 `U-TRP` / `FAM (6+4)` 当前只确认房型代码和结算价格，若信息系统要求具体 Opera Rate Code 字符串，不得由 AI 编造。
+
+## QBD 渠道规则
+
+QBD 渠道主要看房型是否带有 `U` 标号。
+
+核心口径：
+
+- 带 `U` 标号的房型，按有 `UP` 的 Rate Code 处理。
+- 不带 `U` 标号的普通房型，按没有 `UP` 的 Rate Code 处理。
+- `U` 标号指 `U-DBL`、`U-TWN`、`U-TRP`、`U-TWN=850` 等显式升级标识；`Sup` 单词中的字母 `u` 不算 `U` 标号。
+
+| 判断条件 | Rate Code |
+|---|---|
+| 房型不带 `U` 标号，例如 `DBL`、`TWN` | `GRPA1-900` |
+| 房型带 `U` 标号，例如 `U-TWN`、`U-DBL`、`U-TWN=850` | `GRPA2-850UP` |
+| `ST+K:2卧1厅=1200` + `FAMILY 1`，且价格 1200 来自 current | `rate_code=null`，手工录入结算价 1200 |
+| 无法根据房型判断，或无法选择对应 Rate Code | 手工录入具体结算价格 |
+
+### QBD 示例
+
+| 订单信息 | 判断 | Rate Code |
+|---|---|---|
+| `【DBL】`、`【TWN】2` | 普通房型，不带 `U` 标号 | `GRPA1-900` |
+| `【U-TWN=850】` | 房型带 `U` 标号 | `GRPA2-850UP` |
+| `ST+K:2卧1厅=1200` + `FAMILY 1` | QBD 没有已确认可选 Rate Code；价格 1200 可靠时走手工结算价 | `rate_code=null`，`manual_settlement_price_required=true` |
+
+## LianTai 渠道规则
+
+LianTai 渠道应先保留原始房型关键线索，再结合备注中的价格数字判断 Rate Code。`Sup` / 高级房和 `U-` 是关键 Rate Code 线索，不得在房型映射后丢弃。
+
+在 parent-to-child 配合房 / Allotment 创建场景中，header 级价格线索可以继承到 child group line：
+
+- 例如 current header 写 `AMEND +FINAL BOOKING U-1200`，后续 child line 只列 `TWN` / `DBL` / `SUITE` 和房量时，`U-1200` 可作为该批 child allocation 的价格 evidence。
+- 提取 `1200` 后按 LianTai 价格代码表判断；能唯一命中时可写入 `WHO3-1200`，并在 `rate_code_result` 中记录 `price_source="parent_allocation_header"`、`raw_price_indicator="U-1200"`。
+- 不得把 header 价格线索当作房量，也不得覆盖 child line 自己更具体的价格 / 复合单价表达。
+- 如果 header 价格与 child line 自己的明确价格或复合单价冲突，按 child line 证据优先；仍冲突则输出结构化 `manual_review`。
+
+### 原始房型关键线索规则
+
+LianTai 渠道中，Rate Code 不能只根据 Opera Room Type Code 判断，必须先看原始房型关键线索。
+
+| 原始房型关键线索 | Opera Room Type Code | Rate Code | 结算价格线索 |
+|---|---|---|---|
+| `Sup 高级房TWN` / `Sup【高级房TWN】` | `RM3` | `GRP1-900` | 900，或备注价格 1800 折半为 900 |
+| `Sup 高级房DBL` / `Sup【高级房DBL】` | `RM2` | `GRP1-900` | 900，或备注价格 1800 折半为 900 |
+| `U-TWN` | `RM3` | `WHO1-850UP` | 850 |
+| `U-DBL` | `RM2` | `WHO1-850UP` | 850 |
+| 普通 `TWN`，不带 `U` 标号 | `RM3` | `GRP1-900` | 900 |
+| 普通 `DBL`，不带 `U` 标号 | `RM2` | `GRP1-900` | 900 |
+| `ST+K:2卧1厅=1200` + `FAMILY 1` | `SU3` | `WHO3-1200` | 1200 |
+
+关键约束：
+
+- 带 `U` 标号的房型，按有 `UP` 的 Rate Code 处理；不带 `U` 标号的普通房型，按没有 `UP` 的 Rate Code 处理。
+- `U` 标号指 `U-DBL`、`U-TWN`、`U-TRP`、`U-TWN=850` 等显式升级标识；`Sup` 单词中的字母 `u` 不算 `U` 标号。
+- `Sup 高级房TWN` 与 `U-TWN` 都可能映射到 `RM3`，但前者 Rate Code 为 `GRP1-900`，后者为 `WHO1-850UP`。
+- `Sup 高级房DBL` 与 `U-DBL` 都可能映射到 `RM2`，但前者 Rate Code 为 `GRP1-900`，后者为 `WHO1-850UP`。
+- `ST+K:2卧1厅=1200` + `FAMILY 1` 只有在原始表达同时包含 `ST+K`、`2卧1厅`、`1200`、`FAMILY` 时才命中；其中 `1` 是房量，`1200` 是价格线索。LianTai 渠道输出 `WHO3-1200`；QBD 渠道不得编造 Rate Code，价格可靠时走 `rate_code=null` + 手工结算价 1200。
+- LianTai 复合单价表达优先于普通 `TWN` / `DBL` 的默认 Rate Code 判断；例如 `5DBL ... 2000THB+500` 应先拆分复合单价，使用 `2000 / 2 = 1000 -> WHO2-1000`，而不是只因 `DBL` 命中 `GRP1-900`。
+- `rate_code_result` 必须记录 `original_room_type`、`normalized_room_type`、`pms_room_type_code`、`rate_code_basis` 和命中的原始关键线索。
+- 如果只剩 `RM2` / `RM3`，但原始 `Sup` / `U-` 线索丢失，不得仅凭 Room Type Code 反推 Rate Code；可用备注价格继续判断，仍无法唯一判断时输出结构化 `manual_review`。
+- 如果原始房型关键线索与备注价格明显冲突，输出结构化 `manual_review`，并在 `manual_review.conflicting_points` 中说明冲突。
+
+### 判断顺序
+
+1. 保留并读取原始房型关键线索，例如 `Sup` / `高级房` / `U-` / 普通 `TWN` / 普通 `DBL` / `ST+K` / `2卧1厅`。
+2. 如果原始价格表达可拆分为 LianTai 复合单价，先按复合单价规则拆分房费单价组件和 Fix Charge 单价组件。
+3. 如果没有复合单价，再判断原始房型关键线索是否命中上表。
+4. 从备注中提取价格数字，例如 `850`、`900`、`1000`、`1100`、`1200`、`1800`。
+5. 如果原始房型关键线索没有命中，再用备注价格直接匹配 LianTai 价格代码表。
+6. 如果备注价格无法直接匹配，则用 `备注价格 ÷ 2` 得到结算价，再匹配 LianTai 价格代码表。
+7. 如果除以 2 后仍然无法匹配 Rate Code，则手工录入具体结算价格。
+
+### LianTai 价格代码表
+
+| 可匹配价格 | Rate Code |
+|---:|---|
+| 850 | `WHO1-850UP` |
+| 900 | `GRP1-900` |
+| 1000 | `WHO2-1000` |
+| 1200 | `WHO3-1200` |
+
+### LianTai 复合单价 / Fix Charge 规则
+
+本节用于 LianTai 表格酒店说明列或 current 事件价格区中的复合单价表达。复合单价表示“房费单价 + Fix Charge 单价”，不是总价。
+
+典型表达：
+
+- `2000THB+500`
+- `2000+500THB`
+- `1800THB+500`
+- `1800THB+500THB`
+- `2000THB*2 +附加500*2`
+- `2000THB*2` 换行后 `+附加500*2`
+- `春节附加费` / `ตรุษจีนเซอร์ชาร์จ` / `surcharge` 可作为辅助证据，但不是必要条件。
+
+解析规则：
+
+1. 只有出现可拆分的 `房费单价组件 + 附加费用单价组件` 时，才触发 Fix Charge。
+2. `TWN` / `DBL` / 普通房型本身不触发 Fix Charge。
+3. 普通单一价格如 `2000THB`、`1800THB` 不触发 Fix Charge，继续按既有 LianTai Rate Code 规则处理。
+4. 不得把 `2000THB+500` 合并成 `2500` 判断 Rate Code。
+5. `+` 前的数字是 `base_room_price_component`，用于 Rate Code 判断。
+6. `+` 后的数字是 `additional_charge_component`，写入 `fix_charge_items.amount`。
+7. Fix Charge 金额不固定，不得把 `500` 作为唯一触发金额。
+8. AI 不负责计算 Fix Charge 数量或总额；若原文有 `*数量`，可保留为原文证据。
+
+Rate Code 判断：
+
+| 复合单价表达 | base_room_price_component | Rate Code 判断 | Fix Charge 单价 |
+|---|---:|---|---:|
+| `2000THB+500` | 2000 | 2000 ÷ 2 = 1000 -> `WHO2-1000` | 500 |
+| `1800THB+500` | 1800 | 1800 ÷ 2 = 900 -> `GRP1-900` | 500 |
+| `2000THB*2 +附加500*2` | 2000 | 2000 ÷ 2 = 1000 -> `WHO2-1000` | 500 |
+
+输出要求：
+
+- 在 `rate_code_result` 中记录 `raw_price_expression`、`composite_unit_price_detected=true`、`base_room_price_component`、`additional_charge_component`、`settlement_price`、`rate_code` 和 `rate_code_basis`。
+- 在 `fix_charge_items` 中记录 `charge_type=additional_charge`、`amount`、`currency=THB`、`pricing_mode=unit_price`、`unit_basis`、`quantity=null`、`total_amount=null`、`raw_text`、`evidence_source=current_table_row`、`requires_followup_tool=true`、`followup_tool_name=create_fix_charge / TBD`。
+- 在 `additional_operations` 中记录 `operation_type=create_fix_charge` 和 `status=pending_booking_id`。
+- 没有复合单价或附加费组件时，可记录 `fix_charge_required=false`、`fix_charge_items=[]`，并继续正常 Rate Code 判断。
+- 如果出现 `2500THB` 这类单一价格，不得自动拆成 `2000+500`。
+- 如果 `+` 前后无法判断房费单价和附加费用单价，或同一行多个价格组件无法归属，输出结构化 `manual_review`。
+- 如果原始房型线索与复合单价判断明显冲突，输出结构化 `manual_review`，并在 `manual_review.conflicting_points` 中说明冲突。
+
+### LianTai 示例
+
+| 备注价格 | 判断过程 | Rate Code / 操作 |
+|---:|---|---|
+| `Sup 高级房TWN`，备注价格 1800 | 原始房型命中 Sup 高级房；1800 ÷ 2 = 900 作为支持证据 | `GRP1-900` |
+| `Sup 高级房DBL`，备注价格 1800 | 原始房型命中 Sup 高级房；1800 ÷ 2 = 900 作为支持证据 | `GRP1-900` |
+| `U-TWN`，备注价格 850 | 原始房型命中 U-TWN | `WHO1-850UP` |
+| `U-DBL`，备注价格 850 | 原始房型命中 U-DBL | `WHO1-850UP` |
+| 普通 `TWN`，不带 `U` 标号 | 原始房型不带 U 标号，按没有 UP 的 Rate Code | `GRP1-900` |
+| 普通 `DBL`，不带 `U` 标号 | 原始房型不带 U 标号，按没有 UP 的 Rate Code | `GRP1-900` |
+| `(【ST+K:2卧1厅=1200】FAMILY 1)` | 原始表达同时命中 `ST+K`、`2卧1厅`、`1200`、`FAMILY`；`1` 是房量 | `WHO3-1200` |
+| `2000THB+500` | 复合单价；2000 为房费单价组件，500 为 Fix Charge 单价组件；2000 ÷ 2 = 1000 | `WHO2-1000`，并写入 Fix Charge amount 500 |
+| `1800THB+500` | 复合单价；1800 为房费单价组件，500 为 Fix Charge 单价组件；1800 ÷ 2 = 900 | `GRP1-900`，并写入 Fix Charge amount 500 |
+| 850 | 850 可直接匹配 | `WHO1-850UP` |
+| 900 | 900 可直接匹配 | `GRP1-900` |
+| 1000 | 1000 可直接匹配 | `WHO2-1000` |
+| 1200 | 1200 可直接匹配 | `WHO3-1200` |
+| 1800 | 1800 无法直接匹配；1800 ÷ 2 = 900，可匹配 | `GRP1-900` |
+| 1100 | 1100 无法直接匹配；1100 ÷ 2 = 550，仍无法匹配 | 手工录入具体结算价格 |
+
+## 其他市场与特殊类别规则
+
+本节适用于非 `QBD`、非 `LianTai` 的订单。判断时优先看市场/代理类别、用餐餐厅、房型、是否含早餐，以及备注中的价格。
+
+### 中国市场代理（其他公司）
+
+用餐安排：在 Bualuang 餐厅用餐。
+
+| 价格 | Rate Code |
+|---:|---|
+| 2000 | `GL2000B` |
+| 2200 | `GL2200B` |
+| 2300 | `GL2300B` |
+
+### 台湾市场代理
+
+用餐安排：在 Leelawadee（丽拉）餐厅用餐。
+
+| 价格 | Rate Code | 备注 |
+|---:|---|---|
+| 2300 | `GL2300KR` | 与韩国市场共用 |
+| 2400 | `GL2400TW` | 台湾市场专用 |
+
+### 韩国市场代理
+
+用餐安排：在 Leelawadee 餐厅用餐。
+
+| 价格 | Rate Code | 备注 |
+|---:|---|---|
+| 2100 | `GL2100KR` | 韩国市场 |
+| 2200 | `GL2200KR` | 韩国市场 |
+| 2300 | `GL2300KR` | 与台湾市场共用 |
+
+### 特殊类别
+
+用餐安排：在 Leelawadee 餐厅享用早餐。以下类别有 Rate Code，但无固定预设房价，需要在系统中手工输入价格。
+
+| 类别 | Rate Code | 操作 |
+|---|---|---|
+| 企业客（Corporate） | `GLSPCB` | 选择代码后手工输入价格 |
+| 政府客（Government） | `GGV` | 选择代码后手工输入价格 |
+| 预订部直接预订（Direct to Reservation Department） | `GDISPC` | 选择代码后手工输入价格 |
+
+### 散客预订（FIT Booking）
+
+当前未提供固定 Rate Code 规则。若订单无法匹配已有价格代码，按总原则手工录入具体结算价格。
+
+### AI 代理预订（Rainbow 公司和社交媒体渠道）
+
+根据是否含早餐选择 `LBSM` 或 `LBMS`，再按房型对应价格录入。
+
+| 房型 | `LBSM` 不含早餐 | `LBMS` 含早餐 |
+|---|---:|---:|
+| SUP（高级房） | 900 | 1100 |
+| DLX（豪华房） | 1000 | 1200 |
+| 6+4（特定房型） | 不可售 | 1300 |
+| ONE BED（单卧房/套房） | 1800 | 2400 |
+| TWO BED（双卧房/套房） | 3800 | 4000 |
+
+### 中国市场代理（其他）
+
+| 价格 | Rate Code | 备注 |
+|---:|---|---|
+| 2500 | `LDCH25` | 如果实际不是 2500，请直接在系统中手工修改价格 |
+
+### 韩国市场代理（WHKR）
+
+| 价格 | Rate Code |
+|---:|---|
+| 2100 | `WHKR2100B` |
+| 2200 | `WHKR2200B` |
+
+### 俄罗斯市场代理
+
+| Rate Code | 操作 |
+|---|---|
+| `LBAJ` | 无预设固定房价，请在系统中手工输入或修改价格 |
+
+### 其他批发商代理（Other Wholesale）
+
+| Rate Code | 操作 |
+|---|---|
+| `LDWT` | 无预设固定房价，请在系统中手工输入或修改价格 |
+
+### 导游房（Guide Rooms）
+
+专门用于带团导游安排的房间及用餐标准。
+
+| Rate Code | 价格 | 用餐安排 |
+|---|---:|---|
+| `WHOG1` | 1200 | Bualuang 餐厅 |
+| `WHOG2` | 800 | Bualuang 餐厅 |
+| `WHOG3` | 1200 | Leela 餐厅 |
+| `WHOG4` | 800 | Leel 餐厅 |
+
+## 手工录入规则
+
+以下情况需要手工录入具体结算价格：
+
+1. 渠道或市场类别不在当前已确认规则范围内。
+2. QBD 渠道无法根据房型判断 Rate Code。
+3. LianTai 渠道只有 `RM2` / `RM3` 等映射后房型代码，但原始 `Sup` / `U-` 线索缺失，且备注价格也无法唯一判断。
+4. LianTai 渠道备注价格无法直接匹配，且 `备注价格 ÷ 2` 后仍无法匹配。
+5. 其他市场或特殊类别无法根据价格、房型、是否含早餐、用餐餐厅匹配 Rate Code。
+6. Rate Code 规则上能匹配，但系统内没有对应代码可选。
+7. 规则要求手工输入或修改价格，例如 `GLSPCB`、`GGV`、`GDISPC`、`LBAJ`、`LDWT` 等无固定预设房价代码。
+
+手工录入时，以订单或酒店确认的实际结算价格为准；如果 LianTai 备注价格需要折半后才是结算价，则按折半后的结算价录入。
+
+### 手工价格仍可 normal_task 的条件
+
+只有同时满足以下条件，才允许输出 `normal_task` 并使用手工结算价格维护：
+
+1. 当前业务动作明确来自 `body_current` 或当前表格行。
+2. `routing_context` 未发现阻断自动处理的既有有效订单、pending/open task、active workflow 或终止冲突。
+3. 房型已由 `room_type_mapping_rules.md` 唯一命中，并能填入 `pms_room_type_code`。
+4. 日期、晚数、房量、对象类型等创建任务所需核心字段可靠。
+5. 实际结算价格来自 `body_current` 或当前表格行，且可可靠提取。
+6. 本 reference 明确允许该场景手工维护价格。
+
+输出必须包含：`rate_code=null`、`settlement_price`、`manual_settlement_price_required=true`、`manual_price_reason_code`、`price_evidence`。
+
+任一条件不满足时，输出 structured `manual_review`，建议使用 `MANUAL_PRICE_UNCONFIRMED`。
+
+## 快速判断流程
+
+```text
+先识别渠道
+
+IF 渠道 = QBD:
+  IF 原始表达同时包含 ST+K、2卧1厅、1200、FAMILY:
+    SET rate_code = null
+    SET settlement_price = 1200
+    SET manual_settlement_price_required = true
+    SET manual_price_reason_code = QBD_STK_FAMILY_MANUAL_PRICE
+  ELSE IF 房型带 U 标号:
+    SELECT GRPA2-850UP
+  ELSE IF 房型为普通 DBL / TWN 等且不带 U 标号:
+    SELECT GRPA1-900
+  ELSE:
+    手工录入具体结算价格
+
+ELSE IF 渠道 = LianTai:
+  IF 原始价格表达可拆分为 房费单价组件 + 附加费用单价组件:
+    SELECT Rate Code from 房费单价组件 only
+    ADD 附加费用单价组件 to fix_charge_items
+  ELSE IF 原始房型带 U 标号:
+    SELECT WHO1-850UP
+  ELSE IF 原始表达同时包含 ST+K、2卧1厅、1200、FAMILY:
+    SELECT WHO3-1200
+  ELSE IF 原始房型为普通 TWN/DBL，或包含 SUP/高级房 + TWN/DBL:
+    SELECT GRP1-900
+  ELSE:
+    P = 备注价格
+
+    IF P 可匹配 LianTai 价格代码表:
+      SELECT 对应 Rate Code
+    ELSE:
+      P2 = P / 2
+      IF P2 可匹配 LianTai 价格代码表:
+        SELECT 对应 Rate Code
+      ELSE:
+        手工录入具体结算价格
+
+ELSE IF 渠道/市场类别可匹配其他市场与特殊类别规则:
+  按对应市场、用餐餐厅、房型、是否含早餐、价格选择 Rate Code
+  IF 规则要求手工输入价格:
+    选择对应 Rate Code 后手工输入或修改价格
+  ELSE IF 无法匹配:
+    手工录入具体结算价格
+
+ELSE:
+  手工录入具体结算价格
+```
diff --git a/docs/import/20260706/0630AI_副本 2/skill/S01_new_booking_skill/references/room_type_mapping_rules.md b/docs/import/20260706/0630AI_副本 2/skill/S01_new_booking_skill/references/room_type_mapping_rules.md
new file mode 100644
index 0000000..7d622ee
--- /dev/null
+++ b/docs/import/20260706/0630AI_副本 2/skill/S01_new_booking_skill/references/room_type_mapping_rules.md	
@@ -0,0 +1,190 @@
+# 房型映射规则整理
+
+> 来源：用户提供的房型映射截图。本文档先按截图规则整理，后续需用实际案例验证并补充边界情况。
+
+## 1. 明确映射表
+
+| 原始房型 / 描述 | Opera 房型代码 | 备注 |
+| --- | --- | --- |
+| `U-DBL` | `RM2` | 升级/特殊双人房/大床语义标识，按截图直接映射 |
+| `U-TWN` | `RM3` | 升级/特殊双床标识，按截图直接映射 |
+| `U-TRP` | `RM4` | 升级/特殊三人房标识，按截图直接映射 |
+| `U-TRP=FAM (6+4)` | `RM4` | 控房 / 配额类 New Booking 中的 U-TRP/FAM 6+4 表达，按用户确认规则映射 |
+| 普通 `DBL` / `DOUBLE` / 大床 / 双人床 | `RM2` | 普通大床 / 双人床；Rate Code 仍需按渠道和原始线索判断 |
+| 普通 `TWN` / `TWIN` / 双床 | `RM3` | 普通双床；Rate Code 仍需按渠道和原始线索判断 |
+| `Sup 高级房DBL` / `Sup【高级房DBL】` | `RM2` | 高级房大床 / 双人床语义；Rate Code 不得仅按 `RM2` 判断 |
+| `Sup 高级房TWN` / `Sup【高级房TWN】` | `RM3` | 高级房双床语义；Rate Code 不得仅按 `RM3` 判断 |
+| `TWN SUITE` | `SU6` | 套房 + 双床 |
+| `DBL SUITE` | `SU1` | 套房 + 大床/双人床 |
+| `FAMILY 3PAX` | `SU3` | 家庭房，3 人入住 |
+| `FAMILY 4PAX` | `SU3` | 家庭房，4 人入住 |
+| `ST+K:2卧1厅=1200` + `FAMILY 1` | `SU3` | 跨渠道房型表达；`FAMILY` 是房型线索，`1` 是房量，`1200` 是价格线索，不是房量 |
+| `HNM` | `RM2` | 截图中直接映射为 `RM2` |
+| `Q10（双床）` | `SU6` | `Q10` 需结合床型判断 |
+| `Q10（大床）` | `SU1` | `Q10` 需结合床型判断 |
+
+## 2. 归一化规则
+
+在执行映射前，建议先对输入房型做统一清洗：
+
+1. 去除首尾空格。
+2. 将英文统一转为大写。
+3. 将连续多个空格合并为一个空格。
+4. 中文括号、英文括号可视为同类信息，例如 `Q10（双床）` 与 `Q10(双床)`。
+5. 床型关键词建议统一识别：
+   - 双床：`双床`、`TWN`、`TWIN`
+   - 大床/双人床：`大床`、`DBL`、`DOUBLE`
+6. 保留原始房型关键线索，例如 `Sup`、`高级房`、`U-`、`SUITE`、`Q10`、`ST+K:2卧1厅=1200`。这些线索即使映射到同一个 Opera 房型代码，也可能影响 Rate Code 判断。
+
+## 3. 推荐匹配优先级
+
+为了避免误判，建议按以下顺序匹配：
+
+1. **完全匹配优先**
+   - 若输入完全等于 `U-DBL`、`U-TWN`、`U-TRP`、`U-TRP=FAM (6+4)`、`Sup 高级房DBL`、`Sup 高级房TWN`、`HNM` 等明确代码，直接返回对应 Opera 房型代码。
+
+2. **`Sup` / 高级房规则**
+   - 若房型包含 `Sup` / `SUP` / `高级房` 且床型为双床 / `TWN`，映射为 `RM3`。
+   - 若房型包含 `Sup` / `SUP` / `高级房` 且床型为大床 / 双人床 / `DBL`，映射为 `RM2`。
+   - 必须在输出中保留 `Sup` / `高级房` 原始线索，供 Rate Code 判断使用。
+
+3. **`Q10` 特殊规则**
+   - 若房型包含 `Q10` 且床型为双床，则映射为 `SU6`。
+   - 若房型包含 `Q10` 且床型为大床/双人床，则映射为 `SU1`。
+   - 若只有 `Q10` 但没有床型信息，暂不自动映射，需人工确认。
+
+4. **套房床型规则**
+   - `TWN SUITE` 映射为 `SU6`。
+   - `DBL SUITE` 映射为 `SU1`。
+   - 如果只出现 `SUITE` 但没有 `TWN` / `DBL` / 床型信息，需人工确认。
+
+5. **家庭房规则**
+   - 若原始表达同时包含 `ST+K`、`2卧1厅`、`1200`、`FAMILY`，例如 `(【ST+K:2卧1厅=1200】FAMILY 1)`，跨 QBD / LianTai 渠道均可映射为 `SU3`。
+   - 上述表达中 `FAMILY` 是房型线索，`1` 是房量，`1200` 是价格线索；需要将 `ST+K:2卧1厅=1200` 保留在 `original_room_type` / `room_type_note` / `raw_room_text` 中。
+   - `FAMILY 3PAX` 映射为 `SU3`。
+   - `FAMILY 4PAX` 映射为 `SU3`。
+   - 可初步推断：家庭房 `FAMILY` 且入住人数为 3 或 4 时，统一映射 `SU3`。
+   - 不得把所有 `FAMILY 1` 泛化为 `SU3`；只有同时出现 `ST+K`、`2卧1厅`、`1200`、`FAMILY` 时才按本规则自动映射。
+   - 其他人数，例如 `FAMILY 2PAX`、`FAMILY 5PAX`，截图未覆盖，需实际案例验证。
+
+6. **普通房床型规则**
+   - 普通 `TWN` / `TWIN` / 双床映射为 `RM3`。
+   - 普通 `DBL` / `DOUBLE` / 大床 / 双人床映射为 `RM2`。
+   - 本规则不得覆盖更具体的 `U-`、`Sup`、`SUITE`、`Q10`、`ST+K` / `FAMILY` 规则；Rate Code 仍按渠道、原始房型关键线索和价格规则判断。
+
+## 4. 当前可提炼的业务规则
+
+### 4.1 普通房 / 升级房 / 高级房代码
+
+`U-` 开头的房型按具体后缀映射；`Sup` / 高级房按床型映射。注意：映射到同一个 Opera 房型代码，不代表 Rate Code 相同。
+
+| 规则 | Opera 房型代码 |
+| --- | --- |
+| 普通 `DBL` / `DOUBLE` / 大床 / 双人床 | `RM2` |
+| 普通 `TWN` / `TWIN` / 双床 | `RM3` |
+| `U-DBL` | `RM2` |
+| `U-TWN` | `RM3` |
+| `U-TRP` | `RM4` |
+| `U-TRP=FAM (6+4)` | `RM4` |
+| `Sup 高级房DBL` / `Sup【高级房DBL】` | `RM2` |
+| `Sup 高级房TWN` / `Sup【高级房TWN】` | `RM3` |
+
+Rate Code 判断必须保留原始房型关键线索：
+
+| 原始关键线索 | Opera 房型代码 | Rate Code 影响 |
+| --- | --- | --- |
+| 普通 `DBL` / `TWN` | `RM2` / `RM3` | 按渠道普通房规则判断；不带 `U` 时按无 `UP` Rate Code |
+| `U-DBL` / `U-TWN` | `RM2` / `RM3` | 通常按 `U-` 规则判断 |
+| `Sup 高级房DBL` / `Sup 高级房TWN` | `RM2` / `RM3` | 通常按 `Sup` / 高级房规则判断 |
+
+不得只把 `U-TWN` 与 `Sup 高级房TWN` 都归一成 `RM3` 后再判断 Rate Code；也不得只把 `U-DBL` 与 `Sup 高级房DBL` 都归一成 `RM2` 后再判断 Rate Code。
+
+### 4.2 套房按床型区分
+
+| 床型 | Opera 房型代码 |
+| --- | --- |
+| 大床 / 双人床 / `DBL` | `SU1` |
+| 双床 / `TWN` | `SU6` |
+
+适用样例：
+
+| 输入 | 输出 |
+| --- | --- |
+| `DBL SUITE` | `SU1` |
+| `TWN SUITE` | `SU6` |
+| `Q10（大床）` | `SU1` |
+| `Q10（双床）` | `SU6` |
+
+### 4.3 家庭房统一到 `SU3`
+
+目前截图覆盖：
+
+| 输入 | 输出 |
+| --- | --- |
+| `FAMILY 3PAX` | `SU3` |
+| `FAMILY 4PAX` | `SU3` |
+| `ST+K:2卧1厅=1200` + `FAMILY 1` | `SU3` |
+
+`ST+K:2卧1厅=1200` + `FAMILY 1` 是跨 QBD / LianTai 渠道可识别的房型表达：`FAMILY` 是房型线索，`1` 进入 `room_quantity = 1`，`1200` 是价格线索，不计入房量。解析时必须保留原始表达，供 Rate Code 按渠道判断使用。
+
+待验证推断：只要是家庭房且人数为 3 或 4，均映射为 `SU3`。`FAMILY 1` 不在该泛化范围内，除非同时命中 `ST+K`、`2卧1厅`、`1200`、`FAMILY`。
+
+## 5. 待实际案例验证的问题
+
+1. `HNM -> RM2` 的业务含义需要确认，例如是否代表 honeymoon / 蜜月房，或只是某个渠道房型代码。
+2. `U-DBL` 映射 `RM2`，但 `DBL SUITE` 映射 `SU1`，说明 `DBL` 本身不能单独决定房型，必须结合是否为 `SUITE` 或 `U-` 前缀判断。
+3. `TWN` 在不同语境下映射不同：
+   - `U-TWN -> RM3`
+   - `TWN SUITE -> SU6`
+   - `Q10（双床）-> SU6`
+4. `Q10` 必须结合床型判断，不能只根据 `Q10` 单独映射。
+5. 家庭房是否所有人数都映射 `SU3` 暂未确认，目前只能确定 `3PAX`、`4PAX`，以及同时包含 `ST+K`、`2卧1厅`、`1200`、`FAMILY` 的 `FAMILY 1` 表达。
+6. `RM2` / `RM3` 只能作为 Opera 房型代码，不能反推 Rate Code。Rate Code 必须结合原始房型关键线索，例如 `Sup` / `高级房` 或 `U-`。
+
+## 6. 建议校验输出格式
+
+后续验证实际案例时，建议每条案例按以下格式记录：
+
+| 原始输入 | 归一化后 | 命中规则 | 期望 Opera 代码 | 实际 Opera 代码 | 结论 |
+| --- | --- | --- | --- | --- | --- |
+| 示例：`Q10（双床）` | `Q10 双床` | `Q10 + 双床` | `SU6` | 待填 | 待验证 |
+
+## 7. 简化版伪代码
+
+```text
+normalize(room_type)
+
+if exact_match in explicit_mapping:
+    return explicit_mapping[exact_match]
+
+if contains "SUP" or contains "高级房":
+    if contains twin_bed_keyword:
+        return "RM3" with original_room_type_marker="SUP"
+    if contains double_bed_keyword:
+        return "RM2" with original_room_type_marker="SUP"
+    return "NEED_CONFIRMATION"
+
+if contains "Q10":
+    if contains twin_bed_keyword:
+        return "SU6"
+    if contains double_bed_keyword:
+        return "SU1"
+    return "NEED_CONFIRMATION"
+
+if contains "SUITE":
+    if contains twin_bed_keyword:
+        return "SU6"
+    if contains double_bed_keyword:
+        return "SU1"
+    return "NEED_CONFIRMATION"
+
+if contains "ST+K" and contains "2卧1厅" and contains "1200" and contains "FAMILY":
+    return "SU3" with room_quantity_from_family_suffix and raw_room_type_note="ST+K:2卧1厅=1200"
+
+if contains "FAMILY":
+    if contains "3PAX" or contains "4PAX":
+        return "SU3"
+    return "NEED_CONFIRMATION"
+
+return "UNMAPPED"
+```
diff --git a/docs/import/20260706/0630AI_副本 2/skill/S02_update_booking_amendment_skill.md b/docs/import/20260706/0630AI_副本 2/skill/S02_update_booking_amendment_skill.md
new file mode 100644
index 0000000..003fc94
--- /dev/null
+++ b/docs/import/20260706/0630AI_副本 2/skill/S02_update_booking_amendment_skill.md	
@@ -0,0 +1,485 @@
+# S02 Update Booking / Amendment Skill
+
+## 1. Skill Identity
+
+- catalog_code: `S02`
+- skill_id: `update_booking_amendment_skill`
+- skill_name: `Update Booking / Amendment Skill`
+- task_type: `Update Booking`
+
+## 2. Purpose
+
+本 Skill 用于判断一条来自 `body_current` 的当前邮件事件，是否可以生成 Update Booking / Amendment 任务。
+
+第一版判断保持简单：
+
+- 可以明确且安全创建修改任务：输出 `normal_task`
+- 不能安全自动处理、需要人工判断或人工处理：输出 `manual_review`
+
+本 Skill 第一版不输出 `exception_task`，也不输出 `no_action`。
+
+进入 AI 工作台的 current 邮件事件，都应生成某种用户可见记录。对于感谢、确认、FYI、noted、received、confirmed receipt、无业务动作但需要展示的信息，不应路由到本 Skill；明确轻量消息应由 `message_notification_skill` 输出 `informational_message`。
+
+本 Skill 不直接写数据库或外部系统，不写 Opera，不确认 Payment，不生成 Receipt。
+
+Update Booking 可以携带 Fix Charge / 固定费用维护项。Fix Charge 不改变主任务类型；主任务仍是 Update Booking，附加收费维护信息写入 `extracted_fields.fix_charge_items` 和 `additional_operations`，供信息系统在确认目标订单后继续处理。
+
+如果本 Skill 输出 `ai_task_result` 且通过统一输出校验，AI 运行时 / Main Agent / Skill Orchestrator 后续可调用信息系统提供的统一受控 Tool / API 创建普通任务卡或人工复核 / 人工处理任务卡。真实 TaskCard ID、任务状态机、幂等控制、并发保护和执行前硬校验仍由信息系统负责。
+
+## 3. Scope
+
+本 Skill 覆盖对既有对象的修改：
+
+- 既有 FIT Reservation
+- 既有 Group Block
+- 既有 Allotment / Control Block
+- 既有控房 / 配额对象
+
+本 Skill 的内部 subtype 只用于识别修改内容、测试覆盖、任务卡展示和 payload 结构化，不拆分为多个 Tool。
+
+支持的 subtype：
+
+- `update_stay_dates`
+- `update_nights`
+- `update_room_type_or_quantity`
+- `update_guest_count`
+- `update_trace_or_guest_request`
+- `update_group_block_linkage`
+- `update_allotment_control_block`
+- `manual_rate_code_or_settlement_price`
+- `update_fix_charge`
+
+`update_group_block_linkage` 不覆盖旧 Group Code 改为新 Group Code 的 `AMEND GROUP CODE` 事件；这类事件由 `amend_group_code_skill` 处理。
+
+`update_trace_or_guest_request` 只用于标记 Trace / Guest Request 与其他核心 Update 同一 current 事件出现时的后台线索；独立 Trace / Reservation Notes / Guest Request 任务应走 S07。
+
+Extra bed / 加床 / `เตียงเสริม` 属于 Trace / Guest Request，不属于房型或房量：
+
+- 不计入 `room_quantity`。
+- 不影响 FIT / Group 判断。
+- 不作为独立房型映射。
+- 不单独决定 Rate Code。
+- 如果与其他 Update Booking 修改同一事件或同一表格行出现，仍由本 Skill 处理 Update Booking 主任务，同时生成 S07 Trace / Reservation Notes linked task；先处理 S02，再处理 S07。
+- 如果 current 邮件仅要求为既有订单添加、修改或取消 extra bed / 加床 / `เตียงเสริม`，应走 Trace / Reservation Notes Skill，不得当作普通房量修改。
+
+Fix Charge / 固定费用属于 Update Booking 的附加收费维护能力，不属于独立任务类型：
+
+- 不因为 `TWN` / `DBL` / 普通房型本身触发 Fix Charge。
+- 不因为普通价格如 `2000THB`、`1800THB` 本身触发 Fix Charge。
+- 当 current 事件或 LianTai 表格酒店说明价格区出现可拆分的复合单价结构，例如 `2000THB+500`、`1800THB+500`、`2000THB*2` 换行后 `+附加500*2`，可标记 `update_fix_charge`。
+- `+` 前的房费单价组件用于 Rate Code 判断；`+` 后的附加费用单价组件写入 `extracted_fields.fix_charge_items`。
+- 如果 current 邮件只要求为既有订单添加、修改或取消 Fix Charge，且目标订单和动作明确，可由本 Skill 处理；如果目标订单或动作不清，输出 structured `manual_review`。
+- AI 不负责从该表达计算数量或总额。
+
+本 Skill 的房型映射与 Rate Code 判断规则不直接写在主文档正文中，而是作为 bundled references 维护：
+
+- `S02_update_booking_amendment_skill/references/room_type_mapping_rules.md`
+- `S02_update_booking_amendment_skill/references/rate_code_rules.md`
+
+当 current 邮件涉及房型、房型代码、Rate Code、结算价格、渠道、市场类别、早餐或用餐餐厅时，应按需读取对应 reference。
+
+## 4. When To Use
+
+当 `body_current` 中要求修改既有订单、既有 Group Block、既有控房 / 配额 / Control Block 时，Main Agent 可以调用本 Skill。
+
+典型修改包括：
+
+- 修改入住 / 离店日期
+- 修改晚数
+- 修改房型 / 房量
+- 修改人数
+- 与上述核心修改同一事件出现的备注 / Trace / Guest Request；该类内容还应生成 S07 linked task
+- 修改 confirmation / group / block 关联，但不包括旧 Group Code 改为新 Group Code 的 Amend Group Code 事件
+- 维护既有控房 / 配额 / Control Block 的日期、房型、房量
+- 手工维护 Rate Code / 实际结算价格
+- 新增、修改或取消既有订单的 Fix Charge / 固定费用
+
+## 5. Must Not Use When
+
+以下情况不得使用本 Skill 生成 Update Booking `normal_task`：
+
+- 当前邮件是在全新创建预订，应走 `new_booking_skill`。
+- 当前邮件虽然包含 `AMEND` / `AMEND + FINAL BOOKING` / `AMEND TO` 字样，但实质是在把父团拆成多个子 `group_code` 并为每个子 code 创建配合房 / Allotment / Control Block；应走 `new_booking_skill`，不是 S02 before-after 修改。
+- 当前邮件是在取消 FIT / Group Block / Allotment / Control Block，应走 `cancel_booking_skill`。
+- 当前邮件只是提交 Rooming List / Name List。
+- 当前邮件只是收到 Voucher / Credit Voucher / payment slip / payment confirmation。
+- 当前事件明确包含旧 Group Code 改为新 Group Code 的 Amend Group Code 动作；若该动作与日期、晚数、房型、房量、人数、价格等修改属于同一不可拆分事件，主任务应走 `amend_group_code_skill`，其他修改只作为后台关联信息保留。
+- 当前邮件只是添加、修改或取消 Trace / Reservation Notes / Guest Request，且没有其他日期、晚数、房型、房量、人数、价格或控房修改；应走 `trace_reservation_notes_skill`。
+- 当前邮件只是为既有订单添加、修改或取消 extra bed / 加床 / `เตียงเสริม`，且没有其他日期、晚数、房型、房量、人数、价格或控房修改；应走 `trace_reservation_notes_skill`。
+- 修改动作只出现在 `body_thread`，不在 `body_current`。
+
+如果当前邮件没有明确修改动作，但属于感谢、确认、FYI、noted、received、confirmed receipt、转发说明等需要前端展示的信息提醒，不应路由到本 Skill，应由 `message_notification_skill` 输出 `informational_message`。
+
+## 6. Allowed Result Types
+
+第一版只允许：
+
+- `normal_task`
+- `manual_review`
+
+第一版不输出：
+
+- `exception_task`
+- `no_action`
+- `informational_message`
+
+原因：前三个核心 Skill 第一版先不做复杂异常任务分类，也不使用 no_action。无法安全自动处理的 current 邮件事件，统一生成结构化 `manual_review`，供信息系统创建用户可见记录；明确轻量消息通知由 `message_notification_skill` 处理。
+
+## 7. Key Context Needed
+
+Main Agent 应尽量提供以下上下文：
+
+- `source_message_id`
+- `source_event_index`
+- 当前邮件事件文本，只能来自 `body_current`
+- 当前邮件相关附件摘要
+- `group_code`
+- `confirmation_number`
+- `routing_context`
+- 既有 FIT / Group Block / Allotment / Control Block 上下文
+- pending / open task 上下文
+- active workflow 上下文
+- terminated record 上下文
+- before / after 所需的上下文摘要
+- 可用历史证据上下文
+- 房型原文、床型、人数、是否套房、是否家庭房等可用于房型映射的线索
+- 渠道 / 市场类别、supplier、备注价格、是否含早餐、用餐餐厅、实际结算价格等可用于 Rate Code 判断的线索
+- extra bed / 加床 / `เตียงเสริม` 等 Trace / Guest Request 线索
+- LianTai 复合单价、附加费、Fix Charge 原文线索
+
+`routing_context` 至少应覆盖：
+
+- 同 key 是否已有有效订单记录
+- 同 key 是否已有 pending / open task
+- 同 key 是否已有 active workflow
+- 同 key 是否已有 terminated record
+- 当前对象状态是否支持继续创建修改任务
+
+`body_thread` 只能作为 evidence context，不得作为生成 Update Booking `normal_task` 的来源。
+
+## 8. Input Requirements Summary
+
+本 Skill 输入应包含：
+
+- 当前修改请求摘要
+- `body_current` 中的相关原文片段
+- 附件摘要
+- 已提取的核心 key
+- routing context
+- 可用历史证据上下文
+- 能帮助建立 before / after 的系统上下文或历史证据
+- 能帮助识别 Fix Charge / 固定费用的复合单价、附加费、酒店说明列原文
+- 与修改任务同一事件出现的 Trace / Guest Request 线索，例如 extra bed / 加床 / `เตียงเสริม`
+
+本 Skill 不要求 Main Agent 在输入阶段固定完整 `extracted_fields` schema。
+
+具体字段抽取、字段标准化、房型映射、Rate Code 判断、价格规则、before / after 详细结构，应放在本 Skill 后续详细字段章节或统一输出契约中维护。
+
+### 8.1 Bundled / Shared References
+
+本 Skill 可按需读取以下 references：
+
+- `references/room_type_mapping_rules.md`
+  - 当 current 邮件涉及房型、房型代码、套房、家庭房、`Q10`、`U-DBL`、`U-TWN`、`U-TRP`、`HNM` 等房型语义时读取。
+  - 用于将邮件原始房型映射到 Opera 房型代码。
+
+- `references/rate_code_rules.md`
+  - 当 current 邮件涉及 Rate Code、结算价格、渠道 / 市场类别、supplier、备注价格、早餐、用餐餐厅或手工价格维护时读取。
+  - 用于判断可选 Rate Code、是否需要手工录入具体结算价格，以及需要哪些人工确认字段。
+  - 当 current 事件或 LianTai 表格酒店说明价格区出现 `2000THB+500`、`1800THB+500`、`2000THB*2` 换行后 `+附加500*2` 等复合单价表达时必须读取；用于拆分房费单价组件和 Fix Charge 单价组件。
+
+- `../references/qbd_liantai_email_table_rules.md`
+  - When the current message, attachment, sender, subject, or extracted evidence indicates QBD or LianTai Excel/table workflow, read this shared reference.
+  - 触发条件包括：QBD / LianTai 发件人或渠道、QBD / LianTai 表头、Excel / table 附件、`BOOKING UPDATE`、`AMEND BOOKING`、`AMD`、`AMEND GROUP CODE`、`AMD ALLOTMENT`、`CXL`、`CFM`、黄色 / 高亮行、红字、划线、`โรงแรม` 或酒店状态列等线索。
+  - 用于判断 Excel highlighted / yellow rows、QBD current-row selection、黄色 / 高亮行如何拆成独立 current events、LianTai hotel column date parsing、strikethrough before/after、AMD/CXL/CFM status evidence、以及 FIT vs Group decision by total room quantity。
+
+Reference 使用原则：
+
+- 只有 reference 中规则唯一命中时，才可将映射结果写入 `extracted_fields`。
+- `pms_room_type_code` 必须来自 `references/room_type_mapping_rules.md` 的唯一命中；`references/rate_code_rules.md` 可以引用房型代码，但不得作为房型映射唯一来源。
+- `ST+K:2卧1厅=1200` + `FAMILY 1` 是跨 QBD / LianTai 渠道可识别的房型表达，房型映射可命中 `SU3`；Rate Code 必须继续按渠道判断。
+- 如果 QBD / LianTai reference 识别出多个当前有效黄色 / 高亮修改行，必须按行拆分：一行一个 `source_event_index`，一行一个 `ai_task_result`，一行一个下游 task card 候选；不得跨行合并。
+- 即使多行共享同一 `group_code`、`confirmation_number`、日期、酒店、批次、supplier、主题或附件，也不得合并为一个 Update Booking task。
+- 不得用单个结果里的 `source_event_count`、数组型 `case_keys.group_code`、汇总型 `highlighted_rows` 或跨行 `before_after` / `room_items` 代替多个逐行 `ai_task_results`。
+- 如果一行内包含多个房型 / 房量 / 价格 / before-after 明细，可放入该行自己的 `extracted_fields.room_items`、`extracted_fields.before_after` 或等价结构；不同表格行之间不得合并。
+- 如果某一行信息不完整或不能安全处理，只让该行输出结构化 `manual_review`，不得阻塞其他可正常处理的行。
+- Extra bed / 加床 / `เตียงเสริม` 是 Trace / Guest Request，不得计入 `room_quantity`，不得影响 FIT / Group 判断，不得作为独立房型映射，不得单独决定 Rate Code。
+- 如果 extra bed 与 Update Booking 同一表格行出现，主任务仍是 Update Booking；同时生成 S07 linked task，并在后台 payload 保留 extra bed 数量和原文。
+- 除非邮件明确修改房数，否则不得把 extra bed 当作 `update_room_type_or_quantity`。
+- 房型映射不得覆盖原始房型关键线索。即使 `U-TWN` 与 `Sup 高级房TWN` 都映射到 `RM3`，或 `U-DBL` 与 `Sup 高级房DBL` 都映射到 `RM2`，Rate Code 仍必须按原始 `U-` / `Sup` / `高级房` 线索判断。
+- 如果 reference 明确要求手工录入或修改价格，且实际价格可可靠提取，可以输出 `normal_task`，并在 `extracted_fields` 中标记手工价格维护要求。
+- 如果 LianTai 复合单价表达与 Update Booking 同一事件或同一表格行出现，主任务仍是 Update Booking；将房费单价组件写入 `rate_code_result`，将附加费用单价组件写入 `fix_charge_items`，并可标记 `update_fix_charge`。
+- 没有复合单价或附加费组件时，继续按既有房型 / Rate Code 规则处理，不因缺少 Fix Charge 输出 `manual_review`。
+- 如果房型、渠道、市场类别、早餐、餐厅、价格或上下文不足以唯一命中规则，输出结构化 `manual_review`。
+- 如果 reference 没有覆盖当前表达，不得靠常识猜测房型代码或 Rate Code。
+- If any trigger signal is present but the table/highlight/row evidence is unavailable, unreadable, or ambiguous, do not guess. Output structured manual_review and include the missing table evidence in manual_review.evidence_to_check.
+- `context_used` 应记录使用了哪个 reference 以及命中的规则摘要。
+
+## 9. Decision Rules
+
+1. 先确认修改动作是否出现在 `body_current`。
+2. 如果修改动作只出现在 `body_thread`，不得输出 `normal_task`。
+3. 判断当前事件是否确实是修改既有对象，而不是新建、取消、名单、Voucher 或 Amend Group Code。
+   - 如果 `body_current` 是 parent-to-child 配合房 / Allotment 创建，即父 group code 后列出多个新 child group code、日期、房型和房量，按 S01 New Booking 处理；不要因为标题或正文含 `AMEND` 而要求建立 S02 的 before / after。
+4. 如果能提取到 `group_code` 或 `confirmation_number`，必须使用对应 `routing_context`。
+5. 如果涉及房型映射，应读取 `references/room_type_mapping_rules.md`；只有唯一命中时，才可填入 Opera 房型代码。
+6. 如果涉及 Rate Code 或结算价格，应读取 `references/rate_code_rules.md`；只有唯一命中或满足 reference 中“手工价格仍可 normal_task 的条件”时，才可继续创建任务。
+7. 如果 current 邮件、附件、发件人、主题或抽取证据显示 QBD / LianTai Excel/table workflow，应读取 `../references/qbd_liantai_email_table_rules.md`；只有当前表格行、高亮 / 黄色行、before / after、状态证据和对象类型可靠时，才可基于表格输出 `normal_task`。
+8. 对 QBD / LianTai 表格中的多个当前有效黄色 / 高亮修改行，必须按行拆分；每一行生成独立 `source_event_index` 和独立 `ai_task_result`，不得跨行合并，不得用 `source_event_count` 或数组型 `case_keys.group_code` 代替。
+9. 如果 extra bed / 加床 / `เตียงเสริม` 与 Update Booking 同一事件出现，主任务仍是 Update Booking，同时生成 S07 linked task；不得把 extra bed 数量计入 `room_quantity`，不得用于 FIT / Group 判断，不得单独触发 `update_room_type_or_quantity`。
+10. 如果 current 邮件只是为既有订单添加、修改或取消 extra bed / 加床 / `เตียงเสริม`，不得路由为普通 Update Booking；应路由到 Trace / Reservation Notes Skill。
+11. 如果 LianTai 复合单价表达出现，应按 `references/rate_code_rules.md` 拆分房费单价和 Fix Charge 单价；不得把 `2000+500` 合并为 `2500` 判断 Rate Code。
+12. 如果 current 邮件只要求为既有订单添加、修改或取消 Fix Charge，必须能确认目标订单和动作类型；否则输出结构化 `manual_review`。
+13. 如果当前事件明确是修改既有对象，并且 routing context 支持继续处理，且房型 / Rate Code / Fix Charge / QBD-LianTai 表格相关规则已可靠处理，输出 `normal_task`。
+14. 如果不能安全自动处理，输出结构化 `manual_review`。
+15. 如果当前邮件是感谢、确认、FYI、noted、received、confirmed receipt、转发说明等轻量信息，但需要用户可见记录，不应路由到本 Skill，应由 `message_notification_skill` 输出 `informational_message`。
+
+以下情况第一版统一输出 `manual_review`：
+
+- 找不到原订单。
+- 前置任务未完成。
+- 目标对象不明确。
+- 邮件内容冲突。
+- 关键信息缺失。
+- 状态不允许修改。
+- 房型无法确认。
+- 房型映射 reference 未覆盖当前表达。
+- 房型映射存在多个候选或需要床型 / 人数等补充信息。
+- Rate Code 或结算价格无法确认。
+- Rate Code reference 无法根据渠道、市场、房型、早餐、餐厅或备注价格唯一匹配。
+- reference 要求手工录入价格，但实际结算价格无法可靠提取。
+- 手工价格维护条件未全部满足，例如目标订单不存在或状态不允许修改、房型未唯一映射、价格不来自 `body_current` / 当前表格行、价格不可读、before / after 不可靠，或 routing context 不支持继续处理。
+- 出现复合单价或附加费用线索，但无法判断哪一段是房费单价、哪一段是附加费用单价。
+- Fix Charge 金额无法可靠提取，同一行多个价格组件无法归属，或无法确认是新增、修改还是取消 Fix Charge。
+- before / after 无法可靠建立。
+- 例外：parent-to-child 配合房 / Allotment 创建不属于 S02 修改，不因缺少 S02 before / after 输出本 Skill 的 `manual_review`；应重新路由到 S01。
+- 当前邮件只有 extra bed / 加床 / `เตียงเสริม` 维护请求，但无法安全绑定目标对象或备注内容不可读。
+- QBD / LianTai 表格触发信号存在，但表格、黄色 / 高亮行、行号、划线、before / after 或当前行证据不可读、缺失或不明确。
+- 当前邮件像修改，但也可能是新建、取消或改 Group Code。
+- 修改可能已经处理过。
+- 重复提交。
+- 当前邮件没有新的有效修改动作，但与既有订单上下文相关，且无法安全判断是否需要人工处理。
+
+## 10. Normal Task Output
+
+仅当可以安全创建 Update Booking / Amendment 任务时，输出：
+
+```json
+{
+  "result_type": "normal_task",
+  "task_type": "Update Booking",
+  "current_or_history": "current"
+}
+```
+
+完整输出必须符合统一输出契约。
+
+关键要求：
+
+- `source_message_id` 必须原样带回。
+- `source_event_index` 必须原样带回。
+- `case_keys.group_code` 和 `case_keys.confirmation_number` 按实际提取结果填写。
+- `extracted_fields.update_subtypes` 必须填入识别到的 subtype。
+- `extracted_fields.before_after` 应填入可可靠建立的修改前 / 修改后字段。
+- 如果涉及房型映射，应在 `extracted_fields` 中保留原始房型、归一化房型、命中规则和 Opera 房型代码。
+- 如果涉及 Rate Code，应在 `extracted_fields` 中保留渠道 / 市场类别、备注价格、结算价格、命中规则、Rate Code 或手工价格维护要求。
+- 如果使用手工结算价格维护，必须在 `extracted_fields.rate_code_result` 中写入 `rate_code=null`、`settlement_price`、`manual_settlement_price_required=true`、`manual_price_reason_code` 和 `price_evidence`。
+- 如果涉及 LianTai 复合单价，应在 `extracted_fields.rate_code_result` 中保留 `raw_price_expression`、`composite_unit_price_detected`、`base_room_price_component`、`additional_charge_component`、`settlement_price`、`rate_code` 和命中规则摘要。
+- 如果涉及 Fix Charge，应在 `extracted_fields.fix_charge_required`、`extracted_fields.fix_charge_items` 和 `extracted_fields.additional_operations` 中保留附加费用单价、币种、原文证据和后续 Tool 占位；没有 Fix Charge 时可填 `fix_charge_required=false`、`fix_charge_items=[]`。
+- `extracted_fields.fix_charge_items[]` 建议包含 `charge_type`、`amount`、`currency`、`pricing_mode`、`unit_basis`、`quantity=null`、`total_amount=null`、`raw_text`、`evidence_source`、`requires_followup_tool=true`、`followup_tool_name=create_fix_charge / TBD`。
+- `extracted_fields.additional_operations[]` 建议包含 `operation_type=create_fix_charge` 和 `status=pending_target_order_id`；如果后续系统使用其他状态枚举，以信息系统契约为准。
+- 如果来自 QBD / LianTai 表格行，应在 `extracted_fields` 中保留该行的附件名、sheet 名、行号或行标签、高亮状态、动作 / 状态单元格、原始日期、原始房型、原始房量、原始价格和 before / after 证据；一行内多个房型 / 房量 / 价格明细应放入该行自己的 `room_items`、`before_after` 或等价结构。
+- 如果来自 QBD / LianTai 多行表格，单个 `ai_task_result` 只能代表一个当前有效行；`case_keys.group_code` 应只填该行 key。
+- 如果同一事件包含 extra bed / 加床 / `เตียงเสริม`，应生成 S07 linked task；同时可在本任务后台 payload 中保留原文、数量和说明，`room_quantity` 必须排除 extra bed 数量。
+- `visible_reason` 应说明为什么这是当前邮件中的可创建修改任务。
+- `relevant_message_excerpt` 必须来自 `body_current`。
+- `attachments` 只包含当前事件相关附件。
+- `context_used` 应记录用于判断的 routing context 摘要。
+- `context_used` 应记录使用的 reference 文件与命中规则摘要。
+
+## 11. Manual Review Output
+
+当邮件看起来与 Update Booking / Amendment 相关，但不能安全自动创建修改任务时，输出：
+
+```json
+{
+  "result_type": "manual_review",
+  "task_type": "Update Booking",
+  "current_or_history": "current"
+}
+```
+
+`manual_review` 不能只是“人工看一下”。它必须带结构化信息，方便信息系统创建人工复核 / 人工处理任务卡。
+
+即使输出 `manual_review`，也要尽力结构化抽取：
+
+- 能确定的 `case_keys` 必须填入。
+- 能确定的 `update_subtypes` 必须填入 `extracted_fields`。
+- 能可靠建立的 before / after 字段，应填入 `extracted_fields.before_after`。
+- 能确定的原始房型、归一化房型、候选 Opera 房型代码、候选 Rate Code、候选结算价格，应尽量填入 `extracted_fields`。
+- 能确定的复合单价拆分结果和 Fix Charge 单价，应尽量填入 `extracted_fields.rate_code_result` 与 `extracted_fields.fix_charge_items`。
+- 不能可靠建立 before / after 的字段，不要猜，填 `null`。
+- 不能唯一确认的房型映射或 Rate Code，不要猜，填 `null` 或候选数组。
+- 不确定原因必须写入 `manual_review.reason_code`。
+- 缺失字段写入 `manual_review.missing_fields`。
+- 阻塞点写入 `manual_review.blocking_points`。
+- 冲突点写入 `manual_review.conflicting_points`。
+- 建议人工处理动作写入 `manual_review.suggested_human_actions`。
+- 建议人工查看的证据写入 `manual_review.evidence_to_check`。
+- 如房型或 Rate Code 无法自动确认，`manual_review.evidence_to_check` 应包含相关 reference 文件名以及需要人工核对的邮件片段、附件或系统上下文。
+
+建议结构：
+
+```json
+{
+  "manual_review": {
+    "reason_code": "",
+    "visible_reason": "",
+    "review_record_type": "",
+    "blocking_points": [],
+    "missing_fields": [],
+    "conflicting_points": [],
+    "suggested_human_actions": [],
+    "evidence_to_check": []
+  }
+}
+```
+
+`review_record_type` 可用于区分：
+
+- `manual_review_required`
+- `manual_processing_required`
+
+示例语义：
+
+```json
+{
+  "case_keys": {
+    "group_code": "LLT260727FA",
+    "confirmation_number": null
+  },
+  "extracted_fields": {
+    "update_subtypes": ["update_room_type_or_quantity"],
+    "before_after": {
+      "room_type": {
+        "before": null,
+        "after": "Deluxe Twin"
+      },
+      "room_quantity": {
+        "before": 10,
+        "after": 12
+      }
+    }
+  },
+  "manual_review": {
+    "reason_code": "BEFORE_VALUE_UNCONFIRMED",
+    "visible_reason": "无法自动创建修改任务：修改前房型无法可靠确认。",
+    "review_record_type": "manual_review_required",
+    "blocking_points": ["无法可靠确认修改前房型"],
+    "missing_fields": ["before_room_type"],
+    "conflicting_points": [],
+    "suggested_human_actions": ["核对原订单房型后再处理修改"],
+    "evidence_to_check": ["body_current", "routing_context.matched_order_records"]
+  }
+}
+```
+
+房型 / Rate Code 无法唯一确认时的典型 reason_code 可使用：
+
+- `ROOM_TYPE_MAPPING_UNCONFIRMED`
+- `ROOM_TYPE_MAPPING_MULTIPLE_CANDIDATES`
+- `RATE_CODE_UNCONFIRMED`
+- `SETTLEMENT_PRICE_REQUIRED`
+- `MANUAL_PRICE_UNCONFIRMED`
+- `RATE_CODE_RULE_NOT_COVERED`
+- `COMPOSITE_UNIT_PRICE_UNCONFIRMED`
+- `FIX_CHARGE_UNCONFIRMED`
+
+## 12. Tool Invocation Placeholder
+
+当前创建任务卡 / 可见记录的具体 Tool / API 尚未实现，本节只预留对接位置和语义契约，不定义最终 endpoint、鉴权方式或完整返回结构。
+
+- tool_status: `TBD`
+- suggested_tool_name: `create_task_card` / `TBD`
+- tool_purpose: 根据信息系统统一任务卡创建接口，创建普通任务卡或人工复核 / 人工处理任务卡。
+- followup_tool_name: `create_fix_charge` / `TBD`
+- followup_tool_purpose: 当目标订单已确认并取得 reservation / confirmation / PMS booking id 后，为对应订单添加或维护 Fix Charge / 固定费用。
+- tool_owner: 信息系统。
+- caller: AI Runtime / Main Agent / Skill Orchestrator，最终由系统架构确认。
+- invocation_timing: Skill 输出 `ai_task_result` 并通过 Unified Output Contract 校验后。
+- followup_invocation_timing: 仅在 `create_task_card` 或后续信息系统流程确认目标订单 ID 后；如果订单 ID 尚未确认，只保留 `additional_operations`，不得编造 Tool 调用结果。
+- payload_rule: Skill 能抽取出的字段照实填入；任务卡需要但无法抽取的字段填 `null` / empty，并在 `manual_review.missing_fields` 或 `manual_review.blocking_points` 中说明。
+- mapping_payload_rule: 如果涉及房型映射或 Rate Code 判断，应将原始值、归一化值、命中 reference、命中规则摘要、最终代码或候选项写入 `extracted_fields`；不得只写最终结果而丢失依据。
+- fix_charge_payload_rule: 如果涉及 Fix Charge，应将 `fix_charge_required`、`fix_charge_items`、`additional_operations`、原文证据、金额、币种、pricing mode、动作类型和后续 Tool 占位写入 `extracted_fields`；AI 不计算数量或总额。
+- must_not_call_when:
+  - Skill 输出不符合统一契约
+  - current 事件完全不应进入 AI 工作台记录
+  - 修改动作不在 `body_current`
+  - 输出内容缺少任务卡 / 可见记录创建所需的最低溯源字段
+- followup_must_not_call_when:
+  - 目标订单缺少 reservation / confirmation / PMS booking id
+  - Fix Charge 金额无法可靠提取
+  - 复合单价无法可靠拆分
+  - 无法确认是新增、修改还是取消 Fix Charge
+  - 输出内容不符合统一契约
+- minimum_payload_should_include:
+  - `source_message_id`
+  - `source_event_index`
+  - `catalog_code`
+  - `skill_id`
+  - `result_type`
+  - `task_type`
+  - `case_keys`
+  - `visible_reason`
+  - `relevant_message_excerpt`
+  - `attachments`
+  - `context_used`
+  - `extracted_fields`
+  - `manual_review`
+  - `additional_operations`
+  - `idempotency_key` / `TBD`
+- expected_tool_result: `TBD`
+
+Tool 设计原则：
+
+- Update Booking Skill 只调用一个统一任务卡创建 Tool：`create_task_card`。
+- subtype 作为 payload 里的结构化字段传给信息系统，不拆成多个 Tool。
+- `create_fix_charge / TBD` 是后续执行 Tool，不替代 `create_task_card`，也不改变主任务类型。
+- AI 不直接写数据库，只调用信息系统暴露的受控 Tool / API。
+- 信息系统负责生成真实任务卡 ID 或人工复核任务卡 ID。
+- 信息系统负责幂等、并发、状态机和最终落库。
+- 信息系统在创建任务卡或执行前仍需做硬校验，不能只依赖 AI 判断。
+- 如果 Tool 尚不可用，本 Skill 仍应输出合格的 `ai_task_result`；不得编造 Tool 调用结果。
+
+## 13. Conflict Or Fallback Rule
+
+- 如果当前事件同时像 Update Booking 和 New Booking，应优先查看 routing context。
+- 如果当前事件的 `AMEND + FINAL BOOKING` 表达实际是在创建子 group 配合房 / Allotment，优先交给 S01；父团号只作为 parent evidence，不作为 S02 修改目标。
+- 如果 routing context 显示已有有效订单且当前邮件表达为修改，优先按 Update Booking 判断。
+- 如果当前事件同时包含改 Group Code 和日期、房型、房量等修改，能拆分为独立 current 事件时分别路由；如果属于同一不可拆分事件，主任务走 `amend_group_code_skill`，本 Skill 不再为该事件另建任务卡。
+- 如果无法确认原订单是否存在，不由 Main Agent 直接输出 `CASE_NOT_FOUND`，由本 Skill 输出结构化 `manual_review`。
+- 如果房型映射或 Rate Code 判断无法唯一命中 reference，不由 Main Agent 自行猜测，由本 Skill 输出结构化 `manual_review` 或创建明确的手工价格维护任务。
+- 如果多个 Skill 冲突且无法安全拆分，交由 `exception_detection_skill` 或输出结构化 `manual_review`。
+
+## 14. Must Not Do
+
+- 不得从 `body_thread` 生成 Update Booking `normal_task`。
+- 第一版不得输出 `exception_task`。
+- 第一版不得输出 `no_action`。
+- 不得输出 `informational_message`；明确轻量消息通知应路由到 `message_notification_skill`。
+- 不得在 Main Agent 中修补本 Skill 输出。
+- 不得把 `manual_review` 输出成空泛的“人工看一下”。
+- 不得在 before / after 不可靠时猜测字段值。
+- 不得在 reference 未覆盖或无法唯一命中时猜测 Opera 房型代码。
+- 不得在 reference 未覆盖或无法唯一命中时猜测 Rate Code。
+- 不得忽略 reference 中“手工录入具体结算价格”的要求。
+- 不得因为看到 `TWN` / `DBL` 或普通价格就触发 Fix Charge。
+- 不得把 `2000+500` 合并为 `2500` 判断 Rate Code。
+- 不得从复合单价表达计算 Fix Charge 数量或总额。
+- 不得因为 subtype 多而拆成多个 Tool。
+- 不得编造尚未实现的 Tool endpoint、鉴权、返回结构或调用结果。
+- 不得绕过信息系统 Tool / API 直接创建真实 TaskCard。
+- 不得写 Opera。
+- 不得确认 Payment。
+- 不得生成 Receipt。
+- 不得修改数据库。
diff --git a/docs/import/20260706/0630AI_副本 2/skill/S02_update_booking_amendment_skill/references/rate_code_rules.md b/docs/import/20260706/0630AI_副本 2/skill/S02_update_booking_amendment_skill/references/rate_code_rules.md
new file mode 100644
index 0000000..1a64bfd
--- /dev/null
+++ b/docs/import/20260706/0630AI_副本 2/skill/S02_update_booking_amendment_skill/references/rate_code_rules.md	
@@ -0,0 +1,325 @@
+# Rate Code 识别规则
+
+本文档整理当前已确认的 Rate Code 判断逻辑。判断时先识别渠道，再套用对应渠道规则；不管哪个渠道，只要无法匹配到可选 Rate Code，最终都改为手工录入具体结算价格。
+
+## 总原则
+
+1. 先判断订单渠道或市场类别：目前已整理 `QBD`、`LianTai`、其他市场代理、特殊类别、AI 代理、批发商、导游房等规则。
+2. 按渠道套用对应规则，不混用不同渠道的判断逻辑。
+3. Rate Code 判断必须保留原始房型关键线索，例如 `Sup`、`高级房`、`U-`。不得只根据映射后的 Opera Room Type Code（如 `RM2` / `RM3`）判断 Rate Code。
+4. 同样映射到 `RM2` / `RM3`，不代表 Rate Code 相同。例如 LianTai 中 `Sup 高级房TWN` 与 `U-TWN` 都可映射到 `RM3`，但 Rate Code 不同。
+5. `pms_room_type_code` 必须来自 `room_type_mapping_rules.md` 的唯一命中；本文可引用该代码作为判断依据，但不得作为房型映射的唯一来源。
+6. LianTai 复合单价表达中的附加费用组件不参与 Rate Code 判断；不得把 `2000+500` 合并为 `2500` 判断 Rate Code。
+7. 如果订单数据无法匹配任何 Rate Code，或者系统内无法选择对应 Rate Code，则不强行选择代码，改为手工录入具体结算价格。
+
+## QBD 渠道规则
+
+QBD 渠道主要看房型是否带有 `U` 标号。
+
+核心口径：
+
+- 带 `U` 标号的房型，按有 `UP` 的 Rate Code 处理。
+- 不带 `U` 标号的普通房型，按没有 `UP` 的 Rate Code 处理。
+- `U` 标号指 `U-DBL`、`U-TWN`、`U-TRP`、`U-TWN=850` 等显式升级标识；`Sup` 单词中的字母 `u` 不算 `U` 标号。
+
+| 判断条件 | Rate Code |
+|---|---|
+| 房型不带 `U` 标号，例如 `DBL`、`TWN` | `GRPA1-900` |
+| 房型带 `U` 标号，例如 `U-TWN`、`U-DBL`、`U-TWN=850` | `GRPA2-850UP` |
+| `ST+K:2卧1厅=1200` + `FAMILY 1`，且价格 1200 来自 current | `rate_code=null`，手工录入结算价 1200 |
+| 无法根据房型判断，或无法选择对应 Rate Code | 手工录入具体结算价格 |
+
+### QBD 示例
+
+| 订单信息 | 判断 | Rate Code |
+|---|---|---|
+| `【DBL】`、`【TWN】2` | 普通房型，不带 `U` 标号 | `GRPA1-900` |
+| `【U-TWN=850】` | 房型带 `U` 标号 | `GRPA2-850UP` |
+| `ST+K:2卧1厅=1200` + `FAMILY 1` | QBD 没有已确认可选 Rate Code；价格 1200 可靠时走手工结算价 | `rate_code=null`，`manual_settlement_price_required=true` |
+
+## LianTai 渠道规则
+
+LianTai 渠道应先保留原始房型关键线索，再结合备注中的价格数字判断 Rate Code。`Sup` / 高级房和 `U-` 是关键 Rate Code 线索，不得在房型映射后丢弃。
+
+### 原始房型关键线索规则
+
+LianTai 渠道中，Rate Code 不能只根据 Opera Room Type Code 判断，必须先看原始房型关键线索。
+
+| 原始房型关键线索 | Opera Room Type Code | Rate Code | 结算价格线索 |
+|---|---|---|---|
+| `Sup 高级房TWN` / `Sup【高级房TWN】` | `RM3` | `GRP1-900` | 900，或备注价格 1800 折半为 900 |
+| `Sup 高级房DBL` / `Sup【高级房DBL】` | `RM2` | `GRP1-900` | 900，或备注价格 1800 折半为 900 |
+| `U-TWN` | `RM3` | `WHO1-850UP` | 850 |
+| `U-DBL` | `RM2` | `WHO1-850UP` | 850 |
+| 普通 `TWN`，不带 `U` 标号 | `RM3` | `GRP1-900` | 900 |
+| 普通 `DBL`，不带 `U` 标号 | `RM2` | `GRP1-900` | 900 |
+| `ST+K:2卧1厅=1200` + `FAMILY 1` | `SU3` | `WHO3-1200` | 1200 |
+
+关键约束：
+
+- 带 `U` 标号的房型，按有 `UP` 的 Rate Code 处理；不带 `U` 标号的普通房型，按没有 `UP` 的 Rate Code 处理。
+- `U` 标号指 `U-DBL`、`U-TWN`、`U-TRP`、`U-TWN=850` 等显式升级标识；`Sup` 单词中的字母 `u` 不算 `U` 标号。
+- `Sup 高级房TWN` 与 `U-TWN` 都可能映射到 `RM3`，但前者 Rate Code 为 `GRP1-900`，后者为 `WHO1-850UP`。
+- `Sup 高级房DBL` 与 `U-DBL` 都可能映射到 `RM2`，但前者 Rate Code 为 `GRP1-900`，后者为 `WHO1-850UP`。
+- `ST+K:2卧1厅=1200` + `FAMILY 1` 只有在原始表达同时包含 `ST+K`、`2卧1厅`、`1200`、`FAMILY` 时才命中；其中 `1` 是房量，`1200` 是价格线索。LianTai 渠道输出 `WHO3-1200`；QBD 渠道不得编造 Rate Code，价格可靠时走 `rate_code=null` + 手工结算价 1200。
+- LianTai 复合单价表达优先于普通 `TWN` / `DBL` 的默认 Rate Code 判断；例如 `5DBL ... 2000THB+500` 应先拆分复合单价，使用 `2000 / 2 = 1000 -> WHO2-1000`，而不是只因 `DBL` 命中 `GRP1-900`。
+- `rate_code_result` 必须记录 `original_room_type`、`normalized_room_type`、`pms_room_type_code`、`rate_code_basis` 和命中的原始关键线索。
+- 如果只剩 `RM2` / `RM3`，但原始 `Sup` / `U-` 线索丢失，不得仅凭 Room Type Code 反推 Rate Code；可用备注价格继续判断，仍无法唯一判断时输出结构化 `manual_review`。
+- 如果原始房型关键线索与备注价格明显冲突，输出结构化 `manual_review`，并在 `manual_review.conflicting_points` 中说明冲突。
+
+### 判断顺序
+
+1. 保留并读取原始房型关键线索，例如 `Sup` / `高级房` / `U-` / 普通 `TWN` / 普通 `DBL` / `ST+K` / `2卧1厅`。
+2. 如果原始价格表达可拆分为 LianTai 复合单价，先按复合单价规则拆分房费单价组件和 Fix Charge 单价组件。
+3. 如果没有复合单价，再判断原始房型关键线索是否命中上表。
+4. 从备注中提取价格数字，例如 `850`、`900`、`1000`、`1100`、`1200`、`1800`。
+5. 如果原始房型关键线索没有命中，再用备注价格直接匹配 LianTai 价格代码表。
+6. 如果备注价格无法直接匹配，则用 `备注价格 ÷ 2` 得到结算价，再匹配 LianTai 价格代码表。
+7. 如果除以 2 后仍然无法匹配 Rate Code，则手工录入具体结算价格。
+
+### LianTai 价格代码表
+
+| 可匹配价格 | Rate Code |
+|---:|---|
+| 850 | `WHO1-850UP` |
+| 900 | `GRP1-900` |
+| 1000 | `WHO2-1000` |
+| 1200 | `WHO3-1200` |
+
+### LianTai 复合单价 / Fix Charge 规则
+
+本节用于 LianTai 表格酒店说明列或 current 事件价格区中的复合单价表达。复合单价表示“房费单价 + Fix Charge 单价”，不是总价。
+
+典型表达：
+
+- `2000THB+500`
+- `2000+500THB`
+- `1800THB+500`
+- `1800THB+500THB`
+- `2000THB*2 +附加500*2`
+- `2000THB*2` 换行后 `+附加500*2`
+- `春节附加费` / `ตรุษจีนเซอร์ชาร์จ` / `surcharge` 可作为辅助证据，但不是必要条件。
+
+解析规则：
+
+1. 只有出现可拆分的 `房费单价组件 + 附加费用单价组件` 时，才触发 Fix Charge。
+2. `TWN` / `DBL` / 普通房型本身不触发 Fix Charge。
+3. 普通单一价格如 `2000THB`、`1800THB` 不触发 Fix Charge，继续按既有 LianTai Rate Code 规则处理。
+4. 不得把 `2000THB+500` 合并成 `2500` 判断 Rate Code。
+5. `+` 前的数字是 `base_room_price_component`，用于 Rate Code 判断。
+6. `+` 后的数字是 `additional_charge_component`，写入 `fix_charge_items.amount`。
+7. Fix Charge 金额不固定，不得把 `500` 作为唯一触发金额。
+8. AI 不负责计算 Fix Charge 数量或总额；若原文有 `*数量`，可保留为原文证据。
+
+Rate Code 判断：
+
+| 复合单价表达 | base_room_price_component | Rate Code 判断 | Fix Charge 单价 |
+|---|---:|---|---:|
+| `2000THB+500` | 2000 | 2000 ÷ 2 = 1000 -> `WHO2-1000` | 500 |
+| `1800THB+500` | 1800 | 1800 ÷ 2 = 900 -> `GRP1-900` | 500 |
+| `2000THB*2 +附加500*2` | 2000 | 2000 ÷ 2 = 1000 -> `WHO2-1000` | 500 |
+
+输出要求：
+
+- 在 `rate_code_result` 中记录 `raw_price_expression`、`composite_unit_price_detected=true`、`base_room_price_component`、`additional_charge_component`、`settlement_price`、`rate_code` 和 `rate_code_basis`。
+- 在 `fix_charge_items` 中记录 `charge_type=additional_charge`、`amount`、`currency=THB`、`pricing_mode=unit_price`、`unit_basis`、`quantity=null`、`total_amount=null`、`raw_text`、`evidence_source=current_table_row`、`requires_followup_tool=true`、`followup_tool_name=create_fix_charge / TBD`。
+- 在 `additional_operations` 中记录 `operation_type=create_fix_charge` 和 `status=pending_target_order_id`。
+- 没有复合单价或附加费组件时，可记录 `fix_charge_required=false`、`fix_charge_items=[]`，并继续正常 Rate Code 判断。
+- 如果出现 `2500THB` 这类单一价格，不得自动拆成 `2000+500`。
+- 如果 `+` 前后无法判断房费单价和附加费用单价，或同一行多个价格组件无法归属，输出结构化 `manual_review`。
+- 如果原始房型线索与复合单价判断明显冲突，输出结构化 `manual_review`，并在 `manual_review.conflicting_points` 中说明冲突。
+
+### LianTai 示例
+
+| 备注价格 | 判断过程 | Rate Code / 操作 |
+|---:|---|---|
+| `Sup 高级房TWN`，备注价格 1800 | 原始房型命中 Sup 高级房；1800 ÷ 2 = 900 作为支持证据 | `GRP1-900` |
+| `Sup 高级房DBL`，备注价格 1800 | 原始房型命中 Sup 高级房；1800 ÷ 2 = 900 作为支持证据 | `GRP1-900` |
+| `U-TWN`，备注价格 850 | 原始房型命中 U-TWN | `WHO1-850UP` |
+| `U-DBL`，备注价格 850 | 原始房型命中 U-DBL | `WHO1-850UP` |
+| 普通 `TWN`，不带 `U` 标号 | 原始房型不带 U 标号，按没有 UP 的 Rate Code | `GRP1-900` |
+| 普通 `DBL`，不带 `U` 标号 | 原始房型不带 U 标号，按没有 UP 的 Rate Code | `GRP1-900` |
+| `(【ST+K:2卧1厅=1200】FAMILY 1)` | 原始表达同时命中 `ST+K`、`2卧1厅`、`1200`、`FAMILY`；`1` 是房量 | `WHO3-1200` |
+| `2000THB+500` | 复合单价；2000 为房费单价组件，500 为 Fix Charge 单价组件；2000 ÷ 2 = 1000 | `WHO2-1000`，并写入 Fix Charge amount 500 |
+| `1800THB+500` | 复合单价；1800 为房费单价组件，500 为 Fix Charge 单价组件；1800 ÷ 2 = 900 | `GRP1-900`，并写入 Fix Charge amount 500 |
+| 850 | 850 可直接匹配 | `WHO1-850UP` |
+| 900 | 900 可直接匹配 | `GRP1-900` |
+| 1000 | 1000 可直接匹配 | `WHO2-1000` |
+| 1200 | 1200 可直接匹配 | `WHO3-1200` |
+| 1800 | 1800 无法直接匹配；1800 ÷ 2 = 900，可匹配 | `GRP1-900` |
+| 1100 | 1100 无法直接匹配；1100 ÷ 2 = 550，仍无法匹配 | 手工录入具体结算价格 |
+
+## 其他市场与特殊类别规则
+
+本节适用于非 `QBD`、非 `LianTai` 的订单。判断时优先看市场/代理类别、用餐餐厅、房型、是否含早餐，以及备注中的价格。
+
+### 中国市场代理（其他公司）
+
+用餐安排：在 Bualuang 餐厅用餐。
+
+| 价格 | Rate Code |
+|---:|---|
+| 2000 | `GL2000B` |
+| 2200 | `GL2200B` |
+| 2300 | `GL2300B` |
+
+### 台湾市场代理
+
+用餐安排：在 Leelawadee（丽拉）餐厅用餐。
+
+| 价格 | Rate Code | 备注 |
+|---:|---|---|
+| 2300 | `GL2300KR` | 与韩国市场共用 |
+| 2400 | `GL2400TW` | 台湾市场专用 |
+
+### 韩国市场代理
+
+用餐安排：在 Leelawadee 餐厅用餐。
+
+| 价格 | Rate Code | 备注 |
+|---:|---|---|
+| 2100 | `GL2100KR` | 韩国市场 |
+| 2200 | `GL2200KR` | 韩国市场 |
+| 2300 | `GL2300KR` | 与台湾市场共用 |
+
+### 特殊类别
+
+用餐安排：在 Leelawadee 餐厅享用早餐。以下类别有 Rate Code，但无固定预设房价，需要在系统中手工输入价格。
+
+| 类别 | Rate Code | 操作 |
+|---|---|---|
+| 企业客（Corporate） | `GLSPCB` | 选择代码后手工输入价格 |
+| 政府客（Government） | `GGV` | 选择代码后手工输入价格 |
+| 预订部直接预订（Direct to Reservation Department） | `GDISPC` | 选择代码后手工输入价格 |
+
+### 散客预订（FIT Booking）
+
+当前未提供固定 Rate Code 规则。若订单无法匹配已有价格代码，按总原则手工录入具体结算价格。
+
+### AI 代理预订（Rainbow 公司和社交媒体渠道）
+
+根据是否含早餐选择 `LBSM` 或 `LBMS`，再按房型对应价格录入。
+
+| 房型 | `LBSM` 不含早餐 | `LBMS` 含早餐 |
+|---|---:|---:|
+| SUP（高级房） | 900 | 1100 |
+| DLX（豪华房） | 1000 | 1200 |
+| 6+4（特定房型） | 不可售 | 1300 |
+| ONE BED（单卧房/套房） | 1800 | 2400 |
+| TWO BED（双卧房/套房） | 3800 | 4000 |
+
+### 中国市场代理（其他）
+
+| 价格 | Rate Code | 备注 |
+|---:|---|---|
+| 2500 | `LDCH25` | 如果实际不是 2500，请直接在系统中手工修改价格 |
+
+### 韩国市场代理（WHKR）
+
+| 价格 | Rate Code |
+|---:|---|
+| 2100 | `WHKR2100B` |
+| 2200 | `WHKR2200B` |
+
+### 俄罗斯市场代理
+
+| Rate Code | 操作 |
+|---|---|
+| `LBAJ` | 无预设固定房价，请在系统中手工输入或修改价格 |
+
+### 其他批发商代理（Other Wholesale）
+
+| Rate Code | 操作 |
+|---|---|
+| `LDWT` | 无预设固定房价，请在系统中手工输入或修改价格 |
+
+### 导游房（Guide Rooms）
+
+专门用于带团导游安排的房间及用餐标准。
+
+| Rate Code | 价格 | 用餐安排 |
+|---|---:|---|
+| `WHOG1` | 1200 | Bualuang 餐厅 |
+| `WHOG2` | 800 | Bualuang 餐厅 |
+| `WHOG3` | 1200 | Leela 餐厅 |
+| `WHOG4` | 800 | Leel 餐厅 |
+
+## 手工录入规则
+
+以下情况需要手工录入具体结算价格：
+
+1. 渠道或市场类别不在当前已确认规则范围内。
+2. QBD 渠道无法根据房型判断 Rate Code。
+3. LianTai 渠道只有 `RM2` / `RM3` 等映射后房型代码，但原始 `Sup` / `U-` 线索缺失，且备注价格也无法唯一判断。
+4. LianTai 渠道备注价格无法直接匹配，且 `备注价格 ÷ 2` 后仍无法匹配。
+5. 其他市场或特殊类别无法根据价格、房型、是否含早餐、用餐餐厅匹配 Rate Code。
+6. Rate Code 规则上能匹配，但系统内没有对应代码可选。
+7. 规则要求手工输入或修改价格，例如 `GLSPCB`、`GGV`、`GDISPC`、`LBAJ`、`LDWT` 等无固定预设房价代码。
+
+手工录入时，以订单或酒店确认的实际结算价格为准；如果 LianTai 备注价格需要折半后才是结算价，则按折半后的结算价录入。
+
+### 手工价格仍可 normal_task 的条件
+
+只有同时满足以下条件，才允许输出 `normal_task` 并使用手工结算价格维护：
+
+1. 当前业务动作明确来自 `body_current` 或当前表格行。
+2. `routing_context` 支持继续处理，目标订单存在且状态允许修改。
+3. 房型已由 `room_type_mapping_rules.md` 唯一命中，并能填入 `pms_room_type_code`。
+4. 日期、晚数、房量、对象类型、before / after 或目标维护字段可靠。
+5. 实际结算价格来自 `body_current` 或当前表格行，且可可靠提取。
+6. 本 reference 明确允许该场景手工维护价格。
+
+输出必须包含：`rate_code=null`、`settlement_price`、`manual_settlement_price_required=true`、`manual_price_reason_code`、`price_evidence`。
+
+任一条件不满足时，输出 structured `manual_review`，建议使用 `MANUAL_PRICE_UNCONFIRMED`。
+
+## 快速判断流程
+
+```text
+先识别渠道
+
+IF 渠道 = QBD:
+  IF 原始表达同时包含 ST+K、2卧1厅、1200、FAMILY:
+    SET rate_code = null
+    SET settlement_price = 1200
+    SET manual_settlement_price_required = true
+    SET manual_price_reason_code = QBD_STK_FAMILY_MANUAL_PRICE
+  ELSE IF 房型带 U 标号:
+    SELECT GRPA2-850UP
+  ELSE IF 房型为普通 DBL / TWN 等且不带 U 标号:
+    SELECT GRPA1-900
+  ELSE:
+    手工录入具体结算价格
+
+ELSE IF 渠道 = LianTai:
+  IF 原始价格表达可拆分为 房费单价组件 + 附加费用单价组件:
+    SELECT Rate Code from 房费单价组件 only
+    ADD 附加费用单价组件 to fix_charge_items
+  ELSE IF 原始房型带 U 标号:
+    SELECT WHO1-850UP
+  ELSE IF 原始表达同时包含 ST+K、2卧1厅、1200、FAMILY:
+    SELECT WHO3-1200
+  ELSE IF 原始房型为普通 TWN/DBL，或包含 SUP/高级房 + TWN/DBL:
+    SELECT GRP1-900
+  ELSE:
+    P = 备注价格
+
+    IF P 可匹配 LianTai 价格代码表:
+      SELECT 对应 Rate Code
+    ELSE:
+      P2 = P / 2
+      IF P2 可匹配 LianTai 价格代码表:
+        SELECT 对应 Rate Code
+      ELSE:
+        手工录入具体结算价格
+
+ELSE IF 渠道/市场类别可匹配其他市场与特殊类别规则:
+  按对应市场、用餐餐厅、房型、是否含早餐、价格选择 Rate Code
+  IF 规则要求手工输入价格:
+    选择对应 Rate Code 后手工输入或修改价格
+  ELSE IF 无法匹配:
+    手工录入具体结算价格
+
+ELSE:
+  手工录入具体结算价格
+```
diff --git a/docs/import/20260706/0630AI_副本 2/skill/S02_update_booking_amendment_skill/references/room_type_mapping_rules.md b/docs/import/20260706/0630AI_副本 2/skill/S02_update_booking_amendment_skill/references/room_type_mapping_rules.md
new file mode 100644
index 0000000..de8367a
--- /dev/null
+++ b/docs/import/20260706/0630AI_副本 2/skill/S02_update_booking_amendment_skill/references/room_type_mapping_rules.md	
@@ -0,0 +1,190 @@
+# 房型映射规则整理
+
+> 来源：用户提供的房型映射截图。本文档先按截图规则整理，后续需用实际案例验证并补充边界情况。
+
+## 1. 明确映射表
+
+| 原始房型 / 描述 | Opera 房型代码 | 备注 |
+| --- | --- | --- |
+| `U-DBL` | `RM2` | 升级/特殊双人房/大床语义标识，按截图直接映射 |
+| `U-TWN` | `RM3` | 升级/特殊双床标识，按截图直接映射 |
+| `U-TRP` | `RM4` | 升级/特殊三人房标识，按截图直接映射 |
+| `U-TRP=FAM (6+4)` | `RM4` | U-TRP/FAM 6+4 表达，按用户确认规则映射 |
+| 普通 `DBL` / `DOUBLE` / 大床 / 双人床 | `RM2` | 普通大床 / 双人床；Rate Code 仍需按渠道和原始线索判断 |
+| 普通 `TWN` / `TWIN` / 双床 | `RM3` | 普通双床；Rate Code 仍需按渠道和原始线索判断 |
+| `Sup 高级房DBL` / `Sup【高级房DBL】` | `RM2` | 高级房大床 / 双人床语义；Rate Code 不得仅按 `RM2` 判断 |
+| `Sup 高级房TWN` / `Sup【高级房TWN】` | `RM3` | 高级房双床语义；Rate Code 不得仅按 `RM3` 判断 |
+| `TWN SUITE` | `SU6` | 套房 + 双床 |
+| `DBL SUITE` | `SU1` | 套房 + 大床/双人床 |
+| `FAMILY 3PAX` | `SU3` | 家庭房，3 人入住 |
+| `FAMILY 4PAX` | `SU3` | 家庭房，4 人入住 |
+| `ST+K:2卧1厅=1200` + `FAMILY 1` | `SU3` | 跨渠道房型表达；`FAMILY` 是房型线索，`1` 是房量，`1200` 是价格线索，不是房量 |
+| `HNM` | `RM2` | 截图中直接映射为 `RM2` |
+| `Q10（双床）` | `SU6` | `Q10` 需结合床型判断 |
+| `Q10（大床）` | `SU1` | `Q10` 需结合床型判断 |
+
+## 2. 归一化规则
+
+在执行映射前，建议先对输入房型做统一清洗：
+
+1. 去除首尾空格。
+2. 将英文统一转为大写。
+3. 将连续多个空格合并为一个空格。
+4. 中文括号、英文括号可视为同类信息，例如 `Q10（双床）` 与 `Q10(双床)`。
+5. 床型关键词建议统一识别：
+   - 双床：`双床`、`TWN`、`TWIN`
+   - 大床/双人床：`大床`、`DBL`、`DOUBLE`
+6. 保留原始房型关键线索，例如 `Sup`、`高级房`、`U-`、`SUITE`、`Q10`、`ST+K:2卧1厅=1200`。这些线索即使映射到同一个 Opera 房型代码，也可能影响 Rate Code 判断。
+
+## 3. 推荐匹配优先级
+
+为了避免误判，建议按以下顺序匹配：
+
+1. **完全匹配优先**
+   - 若输入完全等于 `U-DBL`、`U-TWN`、`U-TRP`、`U-TRP=FAM (6+4)`、`Sup 高级房DBL`、`Sup 高级房TWN`、`HNM` 等明确代码，直接返回对应 Opera 房型代码。
+
+2. **`Sup` / 高级房规则**
+   - 若房型包含 `Sup` / `SUP` / `高级房` 且床型为双床 / `TWN`，映射为 `RM3`。
+   - 若房型包含 `Sup` / `SUP` / `高级房` 且床型为大床 / 双人床 / `DBL`，映射为 `RM2`。
+   - 必须在输出中保留 `Sup` / `高级房` 原始线索，供 Rate Code 判断使用。
+
+3. **`Q10` 特殊规则**
+   - 若房型包含 `Q10` 且床型为双床，则映射为 `SU6`。
+   - 若房型包含 `Q10` 且床型为大床/双人床，则映射为 `SU1`。
+   - 若只有 `Q10` 但没有床型信息，暂不自动映射，需人工确认。
+
+4. **套房床型规则**
+   - `TWN SUITE` 映射为 `SU6`。
+   - `DBL SUITE` 映射为 `SU1`。
+   - 如果只出现 `SUITE` 但没有 `TWN` / `DBL` / 床型信息，需人工确认。
+
+5. **家庭房规则**
+   - 若原始表达同时包含 `ST+K`、`2卧1厅`、`1200`、`FAMILY`，例如 `(【ST+K:2卧1厅=1200】FAMILY 1)`，跨 QBD / LianTai 渠道均可映射为 `SU3`。
+   - 上述表达中 `FAMILY` 是房型线索，`1` 是房量，`1200` 是价格线索；需要将 `ST+K:2卧1厅=1200` 保留在 `original_room_type` / `room_type_note` / `raw_room_text` 中。
+   - `FAMILY 3PAX` 映射为 `SU3`。
+   - `FAMILY 4PAX` 映射为 `SU3`。
+   - 可初步推断：家庭房 `FAMILY` 且入住人数为 3 或 4 时，统一映射 `SU3`。
+   - 不得把所有 `FAMILY 1` 泛化为 `SU3`；只有同时出现 `ST+K`、`2卧1厅`、`1200`、`FAMILY` 时才按本规则自动映射。
+   - 其他人数，例如 `FAMILY 2PAX`、`FAMILY 5PAX`，截图未覆盖，需实际案例验证。
+
+6. **普通房床型规则**
+   - 普通 `TWN` / `TWIN` / 双床映射为 `RM3`。
+   - 普通 `DBL` / `DOUBLE` / 大床 / 双人床映射为 `RM2`。
+   - 本规则不得覆盖更具体的 `U-`、`Sup`、`SUITE`、`Q10`、`ST+K` / `FAMILY` 规则；Rate Code 仍按渠道、原始房型关键线索和价格规则判断。
+
+## 4. 当前可提炼的业务规则
+
+### 4.1 普通房 / 升级房 / 高级房代码
+
+`U-` 开头的房型按具体后缀映射；`Sup` / 高级房按床型映射。注意：映射到同一个 Opera 房型代码，不代表 Rate Code 相同。
+
+| 规则 | Opera 房型代码 |
+| --- | --- |
+| 普通 `DBL` / `DOUBLE` / 大床 / 双人床 | `RM2` |
+| 普通 `TWN` / `TWIN` / 双床 | `RM3` |
+| `U-DBL` | `RM2` |
+| `U-TWN` | `RM3` |
+| `U-TRP` | `RM4` |
+| `U-TRP=FAM (6+4)` | `RM4` |
+| `Sup 高级房DBL` / `Sup【高级房DBL】` | `RM2` |
+| `Sup 高级房TWN` / `Sup【高级房TWN】` | `RM3` |
+
+Rate Code 判断必须保留原始房型关键线索：
+
+| 原始关键线索 | Opera 房型代码 | Rate Code 影响 |
+| --- | --- | --- |
+| 普通 `DBL` / `TWN` | `RM2` / `RM3` | 按渠道普通房规则判断；不带 `U` 时按无 `UP` Rate Code |
+| `U-DBL` / `U-TWN` | `RM2` / `RM3` | 通常按 `U-` 规则判断 |
+| `Sup 高级房DBL` / `Sup 高级房TWN` | `RM2` / `RM3` | 通常按 `Sup` / 高级房规则判断 |
+
+不得只把 `U-TWN` 与 `Sup 高级房TWN` 都归一成 `RM3` 后再判断 Rate Code；也不得只把 `U-DBL` 与 `Sup 高级房DBL` 都归一成 `RM2` 后再判断 Rate Code。
+
+### 4.2 套房按床型区分
+
+| 床型 | Opera 房型代码 |
+| --- | --- |
+| 大床 / 双人床 / `DBL` | `SU1` |
+| 双床 / `TWN` | `SU6` |
+
+适用样例：
+
+| 输入 | 输出 |
+| --- | --- |
+| `DBL SUITE` | `SU1` |
+| `TWN SUITE` | `SU6` |
+| `Q10（大床）` | `SU1` |
+| `Q10（双床）` | `SU6` |
+
+### 4.3 家庭房统一到 `SU3`
+
+目前截图覆盖：
+
+| 输入 | 输出 |
+| --- | --- |
+| `FAMILY 3PAX` | `SU3` |
+| `FAMILY 4PAX` | `SU3` |
+| `ST+K:2卧1厅=1200` + `FAMILY 1` | `SU3` |
+
+`ST+K:2卧1厅=1200` + `FAMILY 1` 是跨 QBD / LianTai 渠道可识别的房型表达：`FAMILY` 是房型线索，`1` 进入 `room_quantity = 1`，`1200` 是价格线索，不计入房量。解析时必须保留原始表达，供 Rate Code 按渠道判断使用。
+
+待验证推断：只要是家庭房且人数为 3 或 4，均映射为 `SU3`。`FAMILY 1` 不在该泛化范围内，除非同时命中 `ST+K`、`2卧1厅`、`1200`、`FAMILY`。
+
+## 5. 待实际案例验证的问题
+
+1. `HNM -> RM2` 的业务含义需要确认，例如是否代表 honeymoon / 蜜月房，或只是某个渠道房型代码。
+2. `U-DBL` 映射 `RM2`，但 `DBL SUITE` 映射 `SU1`，说明 `DBL` 本身不能单独决定房型，必须结合是否为 `SUITE` 或 `U-` 前缀判断。
+3. `TWN` 在不同语境下映射不同：
+   - `U-TWN -> RM3`
+   - `TWN SUITE -> SU6`
+   - `Q10（双床）-> SU6`
+4. `Q10` 必须结合床型判断，不能只根据 `Q10` 单独映射。
+5. 家庭房是否所有人数都映射 `SU3` 暂未确认，目前只能确定 `3PAX`、`4PAX`，以及同时包含 `ST+K`、`2卧1厅`、`1200`、`FAMILY` 的 `FAMILY 1` 表达。
+6. `RM2` / `RM3` 只能作为 Opera 房型代码，不能反推 Rate Code。Rate Code 必须结合原始房型关键线索，例如 `Sup` / `高级房` 或 `U-`。
+
+## 6. 建议校验输出格式
+
+后续验证实际案例时，建议每条案例按以下格式记录：
+
+| 原始输入 | 归一化后 | 命中规则 | 期望 Opera 代码 | 实际 Opera 代码 | 结论 |
+| --- | --- | --- | --- | --- | --- |
+| 示例：`Q10（双床）` | `Q10 双床` | `Q10 + 双床` | `SU6` | 待填 | 待验证 |
+
+## 7. 简化版伪代码
+
+```text
+normalize(room_type)
+
+if exact_match in explicit_mapping:
+    return explicit_mapping[exact_match]
+
+if contains "SUP" or contains "高级房":
+    if contains twin_bed_keyword:
+        return "RM3" with original_room_type_marker="SUP"
+    if contains double_bed_keyword:
+        return "RM2" with original_room_type_marker="SUP"
+    return "NEED_CONFIRMATION"
+
+if contains "Q10":
+    if contains twin_bed_keyword:
+        return "SU6"
+    if contains double_bed_keyword:
+        return "SU1"
+    return "NEED_CONFIRMATION"
+
+if contains "SUITE":
+    if contains twin_bed_keyword:
+        return "SU6"
+    if contains double_bed_keyword:
+        return "SU1"
+    return "NEED_CONFIRMATION"
+
+if contains "ST+K" and contains "2卧1厅" and contains "1200" and contains "FAMILY":
+    return "SU3" with room_quantity_from_family_suffix and raw_room_type_note="ST+K:2卧1厅=1200"
+
+if contains "FAMILY":
+    if contains "3PAX" or contains "4PAX":
+        return "SU3"
+    return "NEED_CONFIRMATION"
+
+return "UNMAPPED"
+```
diff --git a/docs/import/20260706/0630AI_副本 2/skill/S03_cancel_booking_skill.md b/docs/import/20260706/0630AI_副本 2/skill/S03_cancel_booking_skill.md
new file mode 100644
index 0000000..2e7d04b
--- /dev/null
+++ b/docs/import/20260706/0630AI_副本 2/skill/S03_cancel_booking_skill.md	
@@ -0,0 +1,390 @@
+# S03 Cancel Booking Skill
+
+## 1. Skill Identity
+
+- catalog_code: `S03`
+- skill_id: `cancel_booking_skill`
+- skill_name: `Cancel Booking Skill`
+- task_type: `Cancel Booking`
+
+## 2. Purpose
+
+本 Skill 用于判断一条来自 `body_current` 的当前邮件事件，是否可以生成 Cancel Booking 任务。
+
+第一版判断保持简单：
+
+- 可以明确且安全创建取消任务：输出 `normal_task`
+- 不能安全自动处理、需要人工判断或人工处理：输出 `manual_review`
+
+本 Skill 第一版不输出 `exception_task`，也不输出 `no_action`。
+
+进入 AI 工作台的 current 邮件事件，都应生成某种用户可见记录。对于确认已取消、感谢、FYI、noted、received、confirmed receipt、转发说明、无新的取消动作但需要展示的信息，不应路由到本 Skill；明确轻量消息应由 `message_notification_skill` 输出 `informational_message`。
+
+本 Skill 不直接写数据库或外部系统，不写 Opera，不直接执行取消动作，不确认 Payment，不生成 Receipt。
+
+如果本 Skill 输出 `ai_task_result` 且通过统一输出校验，AI 运行时 / Main Agent / Skill Orchestrator 后续可调用信息系统提供的统一受控 Tool / API 创建普通取消任务卡、人工复核 / 人工处理任务卡或信息系统可展示记录。真实 TaskCard ID、任务状态机、幂等控制、并发保护和执行前硬校验仍由信息系统负责。
+
+## 3. Scope
+
+本 Skill 覆盖以下取消对象：
+
+- FIT Reservation
+- 普通团队预订
+- Group Block
+- Allotment / Control Block
+- 控房 / 配额
+
+本 Skill 合并原 `Cancel Allotment Skill` 的第一版职责。Cancel Allotment 不再作为独立 Skill 出现，而是本 Skill 的内部对象类型。
+
+本 Skill 的内部 `cancel_object_type` / subtype 只用于结构化表达、测试覆盖和任务卡展示，不拆分为多个 Skill，也不拆分为多个 Tool。
+
+支持的 `cancel_object_type`：
+
+- `fit_reservation`
+- `group_block`
+- `allotment_control_block`
+
+## 4. When To Use
+
+当 `body_current` 中明确提出取消既有普通预订、Group Block、Allotment / Control Block、控房或配额时，Main Agent 可以调用本 Skill。
+
+典型语义包括：
+
+- cancel booking
+- cancel reservation
+- cancel this group
+- release / cancel this block
+- cancel allotment
+- cancel allocation
+- cancel control block
+- 取消控房 / 配额
+- `CXL`
+- 明确要求整单取消，而不是修改
+
+`CXL` 是常见取消缩写，可作为强取消信号；但不能只因为看到 `CXL` 字样就机械路由到本 Skill。仍需确认它是 `body_current` 中的当前动作，并结合上下文判断取消对象属于 `fit_reservation`、`group_block` 还是 `allotment_control_block`。
+
+## 5. Must Not Use When
+
+以下情况不得使用本 Skill 生成 Cancel Booking `normal_task`：
+
+- 当前邮件是在全新创建预订，应走 `new_booking_skill`。
+- 当前邮件是在修改日期、房量、房型、人数、备注等，应走 `update_booking_amendment_skill`。
+- 当前邮件只是减少房量、修改部分日期、释放部分配额，这更像 Update，不是整单取消。
+- 当前邮件只是提交 Rooming List / Name List。
+- 当前邮件只是收到 Voucher / Credit Voucher / payment slip / payment confirmation。
+- 取消动作、`CXL` 或取消状态只出现在 `body_thread`，不在 `body_current`。
+
+如果当前邮件没有新的取消动作，只是确认“已取消”、FYI、感谢、noted、received、confirmed receipt、转发说明等，但仍需要前端展示，则不应路由到本 Skill，应由 `message_notification_skill` 输出 `informational_message`。
+
+## 6. Allowed Result Types
+
+第一版只允许：
+
+- `normal_task`
+- `manual_review`
+
+第一版不输出：
+
+- `exception_task`
+- `no_action`
+- `informational_message`
+
+原因：前三个核心 Skill 第一版先不做复杂异常任务分类，也不使用 no_action。无法安全自动处理的 current 邮件事件，统一生成结构化 `manual_review`，供信息系统创建用户可见记录；明确轻量消息通知由 `message_notification_skill` 处理。
+
+## 7. Key Context Needed
+
+Main Agent 应尽量提供以下上下文：
+
+- `source_message_id`
+- `source_event_index`
+- 当前邮件事件文本，只能来自 `body_current`
+- 当前邮件相关附件摘要
+- `group_code`
+- `confirmation_number`
+- `routing_context`
+- 既有订单上下文
+- pending / open task 上下文
+- active workflow 上下文
+- terminated record 上下文
+- 取消对象类型线索，包括 `fit_reservation`、`group_block`、`allotment_control_block`
+- 可用历史证据上下文
+
+`routing_context` 至少应覆盖：
+
+- 同 key 是否已有有效订单记录
+- 同 key 是否已有 pending / open task
+- 同 key 是否已有 active workflow
+- 同 key 是否已有 terminated record
+- 当前对象状态是否支持继续创建取消任务
+
+本 Skill 最关键的上下文判断是：取消对象属于 `fit_reservation`、`group_block`，还是 `allotment_control_block`。
+
+`body_thread` 只能作为 evidence context，不得作为生成 Cancel Booking `normal_task` 的来源。
+
+## 8. Input Requirements Summary
+
+本 Skill 输入应包含：
+
+- 当前取消请求摘要
+- `body_current` 中的相关原文片段
+- 附件摘要
+- 已提取的核心 key
+- routing context
+- 可用历史证据上下文
+- 能帮助判断取消对象类型的上下文
+
+如果一封邮件中同时取消多个订单，Main Agent 应拆成多个 `source_event_index`。
+
+本 Skill 不要求 Main Agent 在输入阶段固定完整 `extracted_fields` schema。
+
+具体字段抽取、字段标准化、取消状态枚举、取消原因分类、外部系统执行规则，应放在本 Skill 后续详细字段章节或统一输出契约中维护。
+
+### 8.1 Bundled / Shared References
+
+本 Skill 可按需读取以下 shared reference：
+
+- `../references/qbd_liantai_email_table_rules.md`
+  - When the current message, attachment, sender, subject, or extracted evidence indicates QBD or LianTai Excel/table workflow, read this shared reference.
+  - 触发条件包括：QBD / LianTai 发件人或渠道、QBD / LianTai 表头、Excel / table 附件、`CANCEL BOOKING`、`CXL`、`CANCEL ALLOTMENT`、`AMEND ALLOTMENT`、`AMD`、`CFM`、黄色 / 高亮行、红字、划线、`โรงแรม` 或酒店状态列等线索。
+  - 用于判断当前表格行是否代表取消请求、黄色 / 高亮行如何拆成独立 current events、`CXL` 是否为当前动作、取消对象是 FIT Reservation / Group Block / Allotment Control Block，以及 AMD/CXL/CFM 状态是否只是历史或完成证据。
+
+Reference 使用原则：
+
+- 如果 QBD / LianTai reference 识别出多个当前有效黄色 / 高亮取消行，必须按行拆分：一行一个 `source_event_index`，一行一个 `ai_task_result`，一行一个下游 task card 候选；不得跨行合并。
+- 即使多行共享同一 `group_code`、`confirmation_number`、日期、酒店、批次、supplier、主题或附件，也不得合并为一个 Cancel Booking task。
+- 如果某一行信息不完整或不能安全处理，只让该行输出结构化 `manual_review`，不得阻塞其他可正常处理的行。
+- `CXL`、红字、取消状态或状态列日期不能脱离 current 行 / 高亮 / 邮件动作上下文单独生成 Cancel Booking `normal_task`。
+- 如果 reference 显示状态列 AMD/CXL/CFM + 日期只是完成或历史证据，不得把它扩大为新的取消任务。
+- If any trigger signal is present but the table/highlight/row evidence is unavailable, unreadable, or ambiguous, do not guess. Output structured manual_review and include the missing table evidence in manual_review.evidence_to_check.
+- `context_used` 应记录使用了哪个 reference 以及命中的规则摘要。
+
+## 9. Decision Rules
+
+1. 先确认取消动作是否出现在 `body_current`。
+2. 如果取消动作、`CXL` 或取消状态只出现在 `body_thread`，不得输出 `normal_task`。
+3. 判断当前事件是否确实是取消既有普通预订 / Group Block / Allotment / Control Block，而不是修改、部分释放、名单、Voucher 或 FYI。
+4. 如果能提取到 `group_code` 或 `confirmation_number`，必须使用对应 `routing_context`。
+5. 如果 current 邮件、附件、发件人、主题或抽取证据显示 QBD / LianTai Excel/table workflow，应读取 `../references/qbd_liantai_email_table_rules.md`；只有当前表格行、高亮 / 黄色行、取消动作、状态证据和取消对象类型可靠时，才可基于表格输出 `normal_task`。
+6. 对 QBD / LianTai 表格中的多个当前有效黄色 / 高亮取消行，必须按行拆分；每一行生成独立 `source_event_index` 和独立 `ai_task_result`，不得跨行合并。
+7. 如果当前事件明确是取消普通 Booking / Group Block / Allotment / Control Block，且 routing context 支持继续创建取消任务，输出 `normal_task`。
+8. 如果不能安全自动处理，输出结构化 `manual_review`。
+9. 如果当前邮件只是确认已取消、FYI、感谢、noted、received、confirmed receipt、转发说明等轻量信息，但需要用户可见记录，不应路由到本 Skill，应由 `message_notification_skill` 输出 `informational_message`。
+
+以下情况第一版统一输出 `manual_review`：
+
+- 找不到原订单。
+- 目标对象不明确。
+- 无法确认 `cancel_object_type` 是 `fit_reservation`、`group_block` 还是 `allotment_control_block`。
+- 前置任务未完成。
+- 订单已终止，但当前邮件又提出取消。
+- 取消请求可能已经处理过。
+- 重复取消请求。
+- 当前邮件内容冲突。
+- 关键信息缺失。
+- 当前邮件像取消，但也可能是修改或释放部分房量。
+- 当前邮件只有 `CXL` 字样，但无法确认它是当前取消动作。
+- QBD / LianTai 表格触发信号存在，但表格、黄色 / 高亮行、行号、红字、状态列或当前行证据不可读、缺失或不明确。
+- 当前邮件没有新的有效取消动作，但与既有订单上下文相关，且无法安全判断是否需要人工处理。
+
+## 10. Normal Task Output
+
+仅当可以安全创建 Cancel Booking 任务时，输出：
+
+```json
+{
+  "result_type": "normal_task",
+  "task_type": "Cancel Booking",
+  "current_or_history": "current"
+}
+```
+
+完整输出必须符合统一输出契约。
+
+关键要求：
+
+- `source_message_id` 必须原样带回。
+- `source_event_index` 必须原样带回。
+- `case_keys.group_code` 和 `case_keys.confirmation_number` 按实际提取结果填写。
+- `visible_reason` 应说明为什么这是当前邮件中的取消请求。
+- `relevant_message_excerpt` 必须来自 `body_current`。
+- `attachments` 只包含当前事件相关附件。
+- `context_used` 应记录用于判断的 routing context 摘要。
+- `extracted_fields` 应填入可可靠抽取的取消字段。
+- 如果来自 QBD / LianTai 表格行，应在 `extracted_fields` 中保留该行的附件名、sheet 名、行号或行标签、高亮状态、动作 / 状态单元格、原始日期、原始房型、原始房量、原始价格和取消状态证据。
+
+建议第一版 `extracted_fields` 至少考虑：
+
+- `cancel_object_type`
+- `candidate_cancel_object_type`
+- `cancel_scope`
+- `arrival_date`
+- `departure_date`
+- `group_name`
+- `guest_name`
+- `room_quantity`
+- `supplier`
+- `requested_cancel_effective_date`
+- `cancellation_note`
+
+## 11. Manual Review Output
+
+当邮件看起来与 Cancel Booking 相关，但不能安全自动创建取消任务时，输出：
+
+```json
+{
+  "result_type": "manual_review",
+  "task_type": "Cancel Booking",
+  "current_or_history": "current"
+}
+```
+
+`manual_review` 不能只是“人工看一下”。它必须带结构化信息，方便信息系统创建人工复核 / 人工处理任务卡。
+
+即使输出 `manual_review`，也要尽力结构化抽取：
+
+- 能确定的 `case_keys` 必须填入。
+- 能确定的 `cancel_object_type` 应填入 `extracted_fields`。
+- 如对象类型尚不完全可靠，可同时填入 `candidate_cancel_object_type`。
+- 能确定的取消相关字段应填入 `extracted_fields`。
+- 不能可靠确认的字段不要猜，填 `null`、空字符串或空数组。
+- 不确定原因必须写入 `manual_review.reason_code`。
+- 缺失字段写入 `manual_review.missing_fields`。
+- 阻塞点写入 `manual_review.blocking_points`。
+- 冲突点写入 `manual_review.conflicting_points`。
+- 建议人工处理动作写入 `manual_review.suggested_human_actions`。
+- 建议人工查看的证据写入 `manual_review.evidence_to_check`。
+
+建议结构：
+
+```json
+{
+  "manual_review": {
+    "reason_code": "",
+    "visible_reason": "",
+    "review_record_type": "",
+    "blocking_points": [],
+    "missing_fields": [],
+    "conflicting_points": [],
+    "suggested_human_actions": [],
+    "evidence_to_check": []
+  }
+}
+```
+
+`review_record_type` 可用于区分：
+
+- `manual_review_required`
+- `manual_processing_required`
+
+典型 `reason_code` 可使用以下语义。它们只是人工复核原因代码，不是 `exception_task` 枚举：
+
+- `TARGET_OBJECT_AMBIGUOUS`
+- `ORDER_RECORD_NOT_FOUND`
+- `CANCEL_ALREADY_PROCESSED`
+- `CANCEL_SCOPE_UNCLEAR`
+- `CANCEL_OBJECT_TYPE_UNCLEAR`
+- `CURRENT_ACTION_NOT_CONFIRMED`
+
+示例语义：
+
+```json
+{
+  "case_keys": {
+    "group_code": "LLT260727FA",
+    "confirmation_number": null
+  },
+  "extracted_fields": {
+    "cancel_object_type": "group_block",
+    "candidate_cancel_object_type": "group_block",
+    "cancel_scope": "full_cancel",
+    "arrival_date": "2026-07-27",
+    "departure_date": null,
+    "group_name": null,
+    "guest_name": null,
+    "room_quantity": null,
+    "supplier": "TBD",
+    "requested_cancel_effective_date": null,
+    "cancellation_note": "CXL request in body_current"
+  },
+  "manual_review": {
+    "reason_code": "CANCEL_SCOPE_UNCLEAR",
+    "visible_reason": "当前邮件疑似取消请求，但无法确认是整单取消还是部分释放房量。",
+    "review_record_type": "manual_review_required",
+    "blocking_points": ["无法确认取消范围"],
+    "missing_fields": ["cancel_scope"],
+    "conflicting_points": [],
+    "suggested_human_actions": ["核对邮件正文和订单上下文，确认是否整单取消"],
+    "evidence_to_check": ["body_current", "routing_context.matched_order_records"]
+  }
+}
+```
+
+## 12. Tool Invocation Placeholder
+
+当前创建任务卡 / 可见记录的具体 Tool / API 尚未实现，本节只预留对接位置和语义契约，不定义最终 endpoint、鉴权方式或完整返回结构。
+
+- tool_status: `TBD`
+- suggested_tool_name: `create_task_card` / `TBD`
+- tool_purpose: 根据信息系统统一任务卡创建接口，创建普通取消任务卡、人工复核 / 人工处理任务卡或信息系统可展示记录。
+- tool_owner: 信息系统。
+- caller: AI Runtime / Main Agent / Skill Orchestrator，最终由系统架构确认。
+- invocation_timing: Skill 输出 `ai_task_result` 并通过 Unified Output Contract 校验后。
+- payload_rule: Skill 能抽取出的字段照实填入；任务卡需要但无法抽取的字段填 `null` / empty，并在 `manual_review.missing_fields` 或 `manual_review.blocking_points` 中说明。
+- must_not_call_when:
+  - Skill 输出不符合统一契约
+  - current 事件完全不应进入 AI 工作台记录
+  - 输出内容缺少任务卡 / 可见记录创建所需的最低溯源字段
+- minimum_payload_should_include:
+  - `source_message_id`
+  - `source_event_index`
+  - `catalog_code`
+  - `skill_id`
+  - `result_type`
+  - `task_type`
+  - `case_keys`
+  - `visible_reason`
+  - `relevant_message_excerpt`
+  - `attachments`
+  - `context_used`
+  - `extracted_fields`
+  - `manual_review`
+  - `idempotency_key` / `TBD`
+- expected_tool_result: `TBD`
+
+Tool 设计原则：
+
+- Cancel Booking Skill 只调用一个统一任务卡创建 Tool：`create_task_card`。
+- 不因为取消对象有 FIT / Group Block / Allotment Control Block 多类就拆多个 Tool。
+- `manual_review` 也可以通过统一 Tool 创建人工复核卡。
+- AI 不直接写数据库，只调用信息系统暴露的受控 Tool / API。
+- 信息系统负责生成真实任务卡 ID、人工复核任务卡 ID 或可见记录 ID。
+- 信息系统负责幂等、并发、状态机和最终落库。
+- 信息系统在创建任务卡或执行前仍需做硬校验，不能只依赖 AI 判断。
+- 如果 Tool 尚不可用，本 Skill 仍应输出合格的 `ai_task_result`；不得编造 Tool 调用结果。
+
+## 13. Conflict Or Fallback Rule
+
+- 如果无法判断 `cancel_object_type` 是 `fit_reservation`、`group_block` 还是 `allotment_control_block`，应优先查看 routing context。
+- 如果仍无法判断，输出结构化 `manual_review`。
+- 如果当前事件同时像取消和修改，优先看邮件语义和 routing context；仍无法拆分时输出结构化 `manual_review` 或交给 `exception_detection_skill`。
+- 如果订单已终止、已被处理、或取消状态不清，不由 Main Agent 直接下结论，由本 Skill 输出结构化 `manual_review`。
+- 如果 `CXL` 只出现在历史引用或旧状态中，不得仅凭该缩写生成 Cancel Booking `normal_task`。
+
+## 14. Must Not Do
+
+- 不得从 `body_thread` 生成 Cancel Booking `normal_task`。
+- 不得只因为看到 `CXL` 就机械生成 Cancel Booking `normal_task`。
+- 第一版不得输出 `exception_task`。
+- 第一版不得输出 `no_action`。
+- 不得输出 `informational_message`；明确轻量消息通知应路由到 `message_notification_skill`。
+- 不得把 `manual_review` 输出成空泛的“人工看一下”。
+- 不得在取消对象不明确时猜测 `cancel_object_type`。
+- 不得在取消范围不明确时猜测整单取消或部分释放。
+- 不得因为取消对象有 FIT / Group Block / Allotment Control Block 多类而拆成多个 Tool。
+- 不得编造尚未实现的 Tool endpoint、鉴权、返回结构或调用结果。
+- 不得绕过信息系统 Tool / API 直接创建真实 TaskCard。
+- 不得直接执行取消写入。
+- 不得写 Opera。
+- 不得确认 Payment。
+- 不得生成 Receipt。
+- 不得修改数据库。
diff --git a/docs/import/20260706/0630AI_副本 2/skill/S04_voucher_received_skill.md b/docs/import/20260706/0630AI_副本 2/skill/S04_voucher_received_skill.md
new file mode 100644
index 0000000..669bcd1
--- /dev/null
+++ b/docs/import/20260706/0630AI_副本 2/skill/S04_voucher_received_skill.md	
@@ -0,0 +1,498 @@
+# S04 Voucher Received Skill
+
+## 1. Skill Identity
+
+- catalog_code: `S04`
+- skill_id: `voucher_received_skill`
+- skill_name: `Voucher Received Skill`
+- task_type: `Voucher Received`
+
+Supported voucher subtypes:
+
+- `lian_tai_credit_voucher`
+- `bank_transfer_slip`
+
+## 2. Purpose
+
+Use this Skill when the current email contains a real voucher / payment evidence image or PDF and the system needs to create a `Voucher Received` task candidate.
+
+S04 only does these things:
+
+- identify voucher evidence in the current email;
+- classify `voucher_subtype`;
+- bind one task to one `Group Code`;
+- require original voucher image / PDF display;
+- output department-routing needs;
+- pass post-confirmation intent to update Reservation Type to `PD`.
+
+S04 does not confirm actual payment receipt, generate receipt, write Opera, call Reservation Type API, or create a real task card directly. The information system performs final task creation, hard validation, department workflow, and API execution.
+
+## 3. Scope
+
+S04 covers only current email evidence of these two voucher types.
+
+### 3.1 LianTai Credit Voucher
+
+`voucher_subtype = lian_tai_credit_voucher`
+
+Paper `CREDIT VOUCHER` from LianTai / 泰國聯泰旅運集團有限公司 / `LIAN TAI TRAVEL GROUP (THAILAND) CO., LTD.`
+
+Typical visual signals:
+
+- LT / LianTai logo and company name;
+- `CREDIT VOUCHER`;
+- fixed fields such as `DATE`, `CODE / 團號`, `IN`, `OUT`;
+- room type fields such as `SGL`, `TWN`, `TRP`;
+- meal fields such as `B`, `L`, `D`;
+- handwritten content, stamp, or signature.
+
+### 3.2 Bank Transfer Slip
+
+`voucher_subtype = bank_transfer_slip`
+
+Bank transfer success screenshot, cash deposit receipt, transaction receipt, payment slip, payment confirmation, or similar visible bank payment / deposit evidence.
+
+## 4. Trigger Rule
+
+Only current email voucher evidence can trigger S04.
+
+Allowed evidence forms:
+
+- current attachment image;
+- current inline image;
+- current PDF;
+- downloaded current file reference.
+
+Do not trigger S04 only from:
+
+- body keyword such as `voucher`, `payment slip`, `send voucher`;
+- Thai status saying voucher was sent;
+- subject such as `FULL PAYMENT`;
+- attachment filename or image filename;
+- hotel reply such as `Thank you for your voucher`;
+- history-only voucher evidence;
+- Excel / QBD / LianTai status without current voucher image / PDF.
+
+If the current email has voucher text but no current voucher image / PDF, do not enter S04. Use S10 for pure message notification, or S99 structured `manual_review` if routing is unsafe.
+
+## 5. Allowed Result Types
+
+S04 only outputs:
+
+- `normal_task`
+- `manual_review`
+
+S04 must not output:
+
+- `informational_message`
+- `no_action`
+- `exception_task`
+
+## 6. Key Context Needed
+
+Main Agent should provide:
+
+- `source_message_id`
+- `source_event_index`
+- current subject and body
+- current voucher image / PDF reference
+- current voucher event summary
+- subtype evidence
+- `Group Code` candidates and sources
+- reservation no / confirmation number candidates and sources, if any
+- LianTai fixed-field OCR candidates, if any
+- directly related thread context for target binding, if needed
+- routing context for reservation / group block / booking record lookup
+- routing context for pending / incomplete New Booking task lookup
+
+`body_thread` can help bind a current voucher to a target, but cannot trigger S04 by itself.
+
+## 7. Splitting Rule
+
+- One current email with multiple voucher images: split by voucher image when possible.
+- One `bank_transfer_slip` that clearly covers multiple `Group Code` values: split by `Group Code`.
+- Multiple `lian_tai_credit_voucher` images: split by image and read each image's own `CODE / 團號`.
+- Each `ai_task_result` binds one and only one `case_keys.group_code`.
+- Do not put an array inside `case_keys.group_code`.
+- Use `related_group_codes` only for user display when several tasks share the same voucher.
+
+## 8. Common Output Structure
+
+Both subtypes use the same main task identity:
+
+```json
+{
+  "task_type": "Voucher Received",
+  "skill_id": "voucher_received_skill",
+  "voucher_subtype": "",
+  "case_keys": {},
+  "group_code_source": "",
+  "voucher_attachment": {
+    "display_original": true,
+    "file_reference": "original voucher image/PDF reference"
+  },
+  "requires_department_routing": false,
+  "department_routing": []
+}
+```
+
+`voucher_attachment` is intentionally high-level. Low-level attachment id, content id, preview URL, file path, thumbnail, and storage details are information-system internals.
+
+## 9. Subtype Rules
+
+### 9.1 LianTai Credit Voucher
+
+For `voucher_subtype = lian_tai_credit_voucher`, use only the fixed `CODE / 團號` or `CODE / 团号` field as `Group Code` source.
+
+Rules:
+
+- Read the handwritten value after `CODE / 團號`.
+- If clear, complete, and single-valued, use it as `case_keys.group_code`.
+- If blank, blurry, cropped, blocked, unreadable, or conflicting, output `manual_review`.
+- Do not use image filename or attachment filename.
+- Do not use other handwritten content outside the fixed `CODE / 團號` field.
+
+LianTai voucher does not route to Finance or any department:
+
+```json
+{
+  "requires_department_routing": false,
+  "department_routing": []
+}
+```
+
+Normal task example:
+
+```json
+{
+  "result_type": "normal_task",
+  "task_type": "Voucher Received",
+  "skill_id": "voucher_received_skill",
+  "voucher_subtype": "lian_tai_credit_voucher",
+  "case_keys": {
+    "group_code": "LT260417VIPA"
+  },
+  "group_code_source": "lian_tai_credit_voucher.code_field",
+  "voucher_attachment": {
+    "display_original": true,
+    "file_reference": "original voucher image/PDF reference"
+  },
+  "voucher_display_fields": {
+    "voucher_date": "17/04/26",
+    "check_in_date": "17/04/26",
+    "check_out_date": "20/04/26",
+    "room_type_text": "2 TWN 2 DBL"
+  },
+  "requires_department_routing": false,
+  "department_routing": []
+}
+```
+
+`voucher_display_fields` are display-only fields. They must not drive room type mapping, Rate Code, room quantity, price, FIT / Group decision, target validation, or automatic booking update.
+
+If these display fields are unreadable, do not block `normal_task` as long as `CODE / 團號` and target validation are safe.
+
+### 9.2 Bank Transfer Slip
+
+For `voucher_subtype = bank_transfer_slip`, find `Group Code` from current email text or directly related current-email context.
+
+Allowed sources:
+
+- current subject;
+- current body;
+- directly related quoted / historical text that clearly binds the current slip to a business object;
+- routing context based on reliable current-email target evidence.
+
+Do not use these as automatic `Group Code` source:
+
+- bank screenshot memo;
+- bank screenshot handwritten text;
+- bank reference number;
+- bank account number;
+- payer / payee;
+- QR data;
+- payment amount;
+- payment date;
+- image filename;
+- attachment filename;
+- arbitrary OCR from the image.
+
+Payment slip requires Finance confirmation through the generic department-routing structure:
+
+```json
+{
+  "requires_department_routing": true,
+  "department_routing": [
+    {
+      "department": "Finance",
+      "purpose": "confirm_payment_received",
+      "required": true,
+      "status": "pending"
+    }
+  ]
+}
+```
+
+`department_routing` is not finance-only. Future routing to FO or other departments should append objects to this array.
+
+Normal task example:
+
+```json
+{
+  "result_type": "normal_task",
+  "task_type": "Voucher Received",
+  "skill_id": "voucher_received_skill",
+  "voucher_subtype": "bank_transfer_slip",
+  "case_keys": {
+    "group_code": "LVM260617L6"
+  },
+  "group_code_source": "email_current_body",
+  "voucher_attachment": {
+    "display_original": true,
+    "file_reference": "original voucher image/PDF reference"
+  },
+  "related_group_codes": ["LVM260617L6", "LVM260619L6"],
+  "requires_department_routing": true,
+  "department_routing": [
+    {
+      "department": "Finance",
+      "purpose": "confirm_payment_received",
+      "required": true,
+      "status": "pending"
+    }
+  ]
+}
+```
+
+Do not extract amount, date, bank account, payer, payee, reference number, QR, or memo as S04 business fields. Users inspect those through the displayed original voucher.
+
+## 10. Multiple Group Code Rule
+
+Multiple `Group Code` values for one `bank_transfer_slip` are not an exception.
+
+If one slip covers:
+
+```json
+["LVM260617L6", "LVM260619L6"]
+```
+
+output two `ai_task_result` records:
+
+```json
+{
+  "case_keys": {
+    "group_code": "LVM260617L6"
+  },
+  "related_group_codes": ["LVM260617L6", "LVM260619L6"]
+}
+```
+
+```json
+{
+  "case_keys": {
+    "group_code": "LVM260619L6"
+  },
+  "related_group_codes": ["LVM260617L6", "LVM260619L6"]
+}
+```
+
+Both records may share the same `voucher_attachment.file_reference`.
+
+## 11. Reservation Number Rule
+
+Reservation no / confirmation number can be retained as auxiliary evidence and used in routing context.
+
+Do not output `normal_task` only because reservation no is found. If no reliable `Group Code` can be bound, output `manual_review` and preserve the reservation no candidate.
+
+If both `Group Code` and reservation no exist, routing context should verify that they point to the same object. If unclear, output `manual_review`.
+
+## 12. Target Validation Rule
+
+After identifying `Group Code`, validate that S04 can attach the task to a business object.
+
+Check:
+
+1. whether a corresponding valid reservation / group block / booking record exists;
+2. if not, whether a pending / open / incomplete New Booking task card can accept the voucher.
+
+If either check passes, S04 may output `normal_task`.
+
+If both fail, output `manual_review`.
+
+If multiple possible targets exist, output `manual_review`.
+
+Do not block S04 only because of:
+
+- suspected duplicate Voucher Received;
+- split or partial payment possibility;
+- active workflow;
+- uncertain target-object status.
+
+Those are information-system hard validations after confirmation.
+
+## 13. Post-Confirmation Action
+
+S04 may pass this intent:
+
+```json
+{
+  "post_confirm_action": {
+    "action": "update_reservation_type",
+    "reservation_type": "PD",
+    "execute_by": "information_system_after_confirmation"
+  }
+}
+```
+
+Execution timing:
+
+- `bank_transfer_slip`: after Finance confirms payment received.
+- `lian_tai_credit_voucher`: after user / information-system confirmation; no Finance routing.
+
+S04 does not call the API.
+
+## 14. Normal Task Conditions
+
+Output `normal_task` only when all are true:
+
+- current email has visible supported voucher image / PDF;
+- `voucher_subtype` is clear;
+- at least one reliable `Group Code` is identified by subtype rules;
+- target validation finds a valid object or pending New Booking task;
+- original voucher can be displayed.
+
+Minimum normal task fields:
+
+```json
+{
+  "result_type": "normal_task",
+  "task_type": "Voucher Received",
+  "skill_id": "voucher_received_skill",
+  "current_or_history": "current",
+  "case_keys": {
+    "group_code": ""
+  },
+  "voucher_subtype": "",
+  "group_code_source": "",
+  "voucher_attachment": {
+    "display_original": true,
+    "file_reference": ""
+  },
+  "requires_department_routing": false,
+  "department_routing": [],
+  "post_confirm_action": {
+    "action": "update_reservation_type",
+    "reservation_type": "PD",
+    "execute_by": "information_system_after_confirmation"
+  }
+}
+```
+
+Subtype additions:
+
+- `lian_tai_credit_voucher`: include `voucher_display_fields` when readable.
+- `bank_transfer_slip`: include `related_group_codes` when one voucher covers multiple Group Codes.
+
+## 15. Manual Review
+
+Output S04 `manual_review` when current email has supported or suspected voucher evidence but S04 cannot safely create `normal_task`.
+
+Manual review conditions:
+
+- voucher image / PDF cannot be read or displayed;
+- subtype cannot be determined;
+- LianTai `CODE / 團號` is unreadable, blank, cropped, blocked, or conflicting;
+- bank transfer slip context does not provide `Group Code`;
+- multiple voucher images and multiple Group Codes cannot be mapped;
+- current/history boundary is unclear;
+- only reservation no is found;
+- `Group Code` and reservation no relationship is unclear;
+- target validation finds no valid object and no pending New Booking task;
+- target validation finds multiple possible objects.
+
+Preserve known information:
+
+- `voucher_subtype`, if known;
+- `Group Code` candidates;
+- reservation no / confirmation number candidates;
+- `group_code_source`, if known;
+- `voucher_attachment`;
+- `voucher_display_fields`, if readable;
+- target validation candidates or failure reason.
+
+Manual review structure:
+
+```json
+{
+  "result_type": "manual_review",
+  "task_type": "Voucher Received",
+  "skill_id": "voucher_received_skill",
+  "current_or_history": "current",
+  "manual_review": {
+    "reason_code": "",
+    "missing_fields": [],
+    "blocking_points": [],
+    "known_fields": {}
+  }
+}
+```
+
+Recommended `reason_code` values:
+
+- `voucher_attachment_unreadable`
+- `voucher_subtype_unclear`
+- `lian_tai_code_field_unreadable`
+- `lian_tai_code_field_conflicting`
+- `bank_transfer_group_code_missing_in_email_text`
+- `ambiguous_voucher_group_code_mapping`
+- `current_history_boundary_unclear`
+- `missing_group_code`
+- `only_reservation_number_found`
+- `unclear_group_code_reservation_link`
+- `target_object_not_found`
+- `multiple_target_objects_found`
+
+## 16. Task Card Display
+
+Front-end task card should prioritize:
+
+- original voucher image / PDF;
+- `voucher_subtype`;
+- current task's single `group_code` or reservation key;
+- `related_group_codes`, if several tasks share one bank slip;
+- LianTai `voucher_display_fields`;
+- department routing state for payment slip.
+
+## 17. Tool Placeholder
+
+- tool_status: `TBD`
+- suggested_tool_name: `create_task_card` / `TBD`
+- tool_purpose: create Voucher Received task card or manual review card through the information system.
+- payload_rule: include target key, voucher subtype, simplified `voucher_attachment`, department routing, related group codes, LianTai display fields, target validation result, and post-confirm action intent.
+
+Use the same unified task-card Tool for both subtypes. Do not create subtype-specific Tools. If Tool is unavailable, still output a valid `ai_task_result`; do not fabricate Tool output.
+
+## 18. Conflict And Fallback
+
+- Supported voucher image / PDF plus safe target: output S04 according to subtype and split rules.
+- Supported voucher image / PDF but unsafe target or missing Group Code: output S04 `manual_review`.
+- Suspected voucher image / PDF but unclear subtype: output S04 `manual_review`.
+- Voucher words but no current voucher evidence: do not enter S04.
+- Current email also has New / Update / Cancel / Amend Group Code: split events when safe; otherwise use S99 or structured `manual_review`.
+- Voucher only in history: do not output S04 `normal_task`.
+
+## 19. Must Not Do
+
+- Do not trigger from body text, subject, status, filename, or historical hotel reply alone.
+- Do not use filename as `Group Code`.
+- Do not use bank screenshot memo, handwritten text, reference number, account, payer, payee, QR, amount, or date as automatic `Group Code`.
+- Do not use LianTai image content outside fixed `CODE / 團號` as `Group Code`.
+- Do not guess unclear handwritten `Group Code`.
+- Do not use LianTai display fields for business updates or mapping.
+- Do not extract bank payment details as S04 business fields.
+- Do not put multiple `Group Code` values in `case_keys.group_code`.
+- Do not convert clear multi-Group-Code payment slip into `manual_review`; split tasks.
+- Do not output `normal_task` only from reservation no.
+- Do not block because of possible duplicate Voucher Received, split payment, active workflow, or object status.
+- Do not output `informational_message`, `exception_task`, or `no_action`.
+- Do not confirm payment receipt, call Reservation Type API, write Opera, generate receipt, or invent Tool results.
diff --git a/docs/import/20260706/0630AI_副本 2/skill/S05_rooming_list_name_list_skill.md b/docs/import/20260706/0630AI_副本 2/skill/S05_rooming_list_name_list_skill.md
new file mode 100644
index 0000000..64a1bd7
--- /dev/null
+++ b/docs/import/20260706/0630AI_副本 2/skill/S05_rooming_list_name_list_skill.md	
@@ -0,0 +1,500 @@
+# S05 Rooming List / Name List Skill
+
+## 1. Skill Identity
+
+- catalog_code: `S05`
+- skill_id: `rooming_list_name_list_skill`
+- skill_name: `Rooming List / Name List Skill`
+- task_type: `Rooming List`
+
+Supported list evidence types:
+
+- `rooming_list`
+- `name_list`
+- `guest_list`
+- `room_assignment_list`
+
+## 2. Purpose
+
+本 Skill 用于判断一条来自 `body_current` 的当前邮件事件，是否提交了 Rooming List / Name List / 客人名单 / 分房名单，并生成 Rooming List 任务卡候选。
+
+第一版保持窄口径：
+
+- current 邮件提交了可读取、可归属的名单文件 / 名单内容，且能绑定明确目标对象：输出 `normal_task`。
+- current 邮件疑似提交名单，但文件不可读、类型不清、目标不清或无法安全拆分：输出 `manual_review`。
+
+本 Skill 不直接导入 Opera，不直接创建或维护 PM room，不直接维护 Routing Instruction，不直接写 TA Recorder / Note，不直接更新 Block Status，不输出 `informational_message`。
+
+如果本 Skill 输出 `ai_task_result` 且通过统一输出校验，AI 运行时 / Main Agent / Skill Orchestrator 后续可调用信息系统提供的统一受控 Tool / API 创建 Rooming List 任务卡或人工复核 / 人工处理任务卡。真实 TaskCard ID、任务状态机、幂等控制、并发保护、执行前硬校验、文件下载、名单导入、Routing、TA Recorder、Note 和 Block Status 更新均由信息系统负责。
+
+## 3. Scope
+
+本 Skill 第一版覆盖 current 邮件中的名单接收事件：
+
+1. 邮件正文明确提交 `Rooming List` / `Name List` / `NAMELIST` / `NAME LIST`。
+2. 邮件正文明确提交分房名单、客人名单或类似 guest list。
+3. current 邮件发送文件 / 文件链接，且 current 或紧邻 history 表明酒店正在索要 rooming list，且文件内容可判断为客人级名单。
+4. QBD / LianTai 当前事件明确为 `NAME LIST` / `Rooming List`，且名单文件证据可读取。
+
+文件载体可以是普通附件、Google Drive / 网盘链接、系统已下载的 `file_reference`、inline 文件、PDF、图片或 Excel。文件载体本身不是触发依据，必须能判断内容或上下文确实是名单。
+
+## 4. When To Use
+
+当 `body_current` 中的当前邮件事件满足以下任一条件时，Main Agent 可以调用本 Skill：
+
+- current 正文明说 `Rooming List`、`Name List`、`NAMELIST`、`NAME LIST`、分房名单、客人名单。
+- current 邮件发送文件 / 文件链接，且紧邻 history 中酒店明确要求提供 rooming list，current 语义是在回复该要求。
+- current 文件内容可解析，且内容明显是客人级名单结构。
+- QBD / LianTai 当前事件、附件、文件内容或 current 说明明确是名单提交。
+
+典型场景包括：旅行社发送名单 Excel、一个 workbook 包含多个 group / sheet、current 同时包含 amendment 文本和名单文件、外部链接指向名单但系统无法下载、名单附件需要和 group code / sheet 名绑定。
+
+## 5. Must Not Use When
+
+不得仅凭以下信号路由到 S05：
+
+- 只有 Excel、PDF、图片或文件链接，但无法判断是名单。
+- 只有文件名像 `Group Code`。
+- 只有附件文件名写 `.xlsx`。
+- 只有历史邮件中出现 rooming list，但 current 没有发送名单文件 / 链接 / 当前名单内容。
+- current 邮件只是酒店回复已收到名单、thank you、FYI、noted，且没有新的可执行名单动作。
+
+以下文件类型不得当作 Rooming List / Name List：
+
+- LianTai / QBD booking update 表。
+- sheet 名类似 `BOOKING 01-2026`、`BOOKING 02-2026` 的月度 booking 表。
+- 表头是团号、人数、行程、酒店、备注、酒店回应状态、`UPDATE`。
+- 内容是 `NEW BOOKING`、`AMEND`、`AMD`、`CXL`、`CFM`、房量、房型、价格、酒店状态。
+- invoice、payment、voucher、allotment / control block 表。
+
+如果 current 邮件主要是在新建、修改、取消、发送 voucher 或付款凭证，应优先走对应 Skill。若同一 current 邮件可安全拆分出名单事件和其他业务事件，应拆分 `source_event_index`；不能拆分时输出 structured `manual_review` 或交由 S99 fallback。
+
+## 6. Allowed Result Types
+
+第一版只允许：
+
+- `normal_task`
+- `manual_review`
+
+第一版不输出：
+
+- `exception_task`
+- `no_action`
+- `informational_message`
+
+## 7. Key Context Needed
+
+Main Agent 应尽量提供以下上下文：
+
+- `source_message_id`
+- `source_event_index`
+- `body_current` 中当前名单事件摘要
+- current 邮件 subject
+- current 邮件正文
+- 可用引用历史正文，作为 rooming list 请求、target key 或 current/history 边界的证据 context
+- current 邮件中的附件、inline 文件、外部文件链接或已下载 `file_reference`
+- 文件读取 / 下载 / 解析结果
+- workbook / sheet / table / PDF / image 的结构化摘要
+- list 文件类型判断证据
+- `group_code`、`confirmation_number`、reservation no、case code / block code 候选及来源
+- 附件 / 文件 / sheet 与目标对象的绑定关系
+- `routing_context`，包含已写入 reservation / group block / booking record 查询结果，以及可关联待完善 New Booking / 上游任务卡查询结果
+
+注意：
+
+- `body_thread` 只能作为辅助 context，不得单独触发 S05。
+- current 业务动作必须来自 current 邮件发送名单文件、文件链接或当前名单内容。
+- 文件名可以辅助附件归属判断，但不得单独触发 S05，也不得单独证明文件是名单。
+
+## 8. Input Requirements Summary
+
+本 Skill 输入应包含：
+
+- 当前名单事件摘要
+- current 邮件中的名单附件 / 文件链接 / `file_reference`
+- 文件读取状态
+- 文件类型判断证据
+- 文件内可见的 header / sheet / table 摘要
+- target key 候选及来源
+- 文件 / sheet 与 target key 的绑定关系
+- `routing_context`，如有
+
+拆分规则：
+
+- 如果一个 current 邮件包含多个可归属名单文件，应按目标对象拆分。
+- 如果一个 workbook 包含多个 group / sheet，例如 `HD260510A-1`、`HD260510A-2`、`HD260510A-3`、`HD260510A-4`，应按 sheet / target 拆成多个输出。
+- 同一个 workbook 可被多个输出共享，但每个输出必须指定对应 sheet、文件区域或绑定证据。
+- `总名单`、summary、all guests 等汇总 sheet 默认作为 shared evidence，不单独生成任务；只有 current 明确要求按汇总 sheet 导入一个目标时才可单独生成。
+- 最终每个 `ai_task_result` / 任务卡候选只能绑定一个 `case_keys.group_code` 或一个目标 reservation。
+- 不得用数组型 `case_keys.group_code` 合并多个任务。
+
+### 8.1 Bundled / Shared References
+
+当 sender、subject、current 正文、附件名、文件内容或提取证据显示 QBD / LianTai Excel / table workflow 时，Main Agent 应读取：
+
+- `../references/qbd_liantai_email_table_rules.md`
+
+使用该 reference 的目的：
+
+- 区分 QBD / LianTai booking update 表与名单文件。
+- 遵守 current/history、表格证据、附件证据和拆行规则。
+- 如果文件证据不可读、不可下载、表格类型不清或 row / sheet 归属不清，输出 structured `manual_review`，并把缺失证据写入 `manual_review.evidence_to_check`。
+
+本 Skill 不读取房型映射或 Rate Code reference 来猜 Breakfast。Breakfast 是否显示或必填由信息系统、既有订单上下文或用户确认决定。
+
+## 9. Decision Rules
+
+### 9.1 Carrier Is Not Trigger Rule
+
+Excel、PDF、图片、文件链接、Google Drive 链接或文件名本身都不是 S05 触发条件。
+
+必须能确认以下至少一类证据：
+
+- current 文本明确说明发送 Rooming List / Name List / 客人名单 / 分房名单。
+- current 发送文件 / 链接，且紧邻 history 明确索要 rooming list。
+- 文件内容可读取，并呈现客人级名单结构。
+
+如果不能确认，不能输出 S05 `normal_task`。
+
+### 9.2 Positive List File Evidence Rule
+
+名单文件通常具备以下结构：
+
+- 一行一个客人。
+- 有 `姓名` / `中文姓名` / `英文姓名` / `英文姓` / `英文名`。
+- 有 `护照号码` / `护照有效期`。
+- 有 `性别`、`出生日期`、`国籍`、手机号等客人字段。
+- 有到达 / 离开日期、航班号、参考航班信息、住宿地址等旅行字段。
+- sheet 名、文件名或 current 正文能和 group code / case code 绑定。
+
+文件是 Excel、PDF、图片或其他可解析载体都可以；关键是内容必须像客人名单或分房名单。
+
+### 9.3 Negative Booking Table Rule
+
+如果文件是 LianTai / QBD booking update 表，不得走 S05。
+
+典型负向证据：
+
+- sheet 名是 `BOOKING 01-2026`、`BOOKING 02-2026` 等。
+- 表头包含团号、人数、行程、酒店、备注、酒店回应状态、`UPDATE`。
+- 内容包含 `NEW BOOKING`、`AMEND`、`AMD`、`CXL`、`CFM`、房量、房型、价格或酒店状态。
+- 没有客人级名单字段。
+
+这种文件应交给 S01 / S02 / S03 或对应 Skill 判断，不得因为它是 Excel 而输出 Rooming List。
+
+### 9.4 External Link / Unreadable File Rule
+
+如果 current 只提供 Google Drive、网盘或外部文件链接：
+
+- 系统能下载并解析文件，且内容是名单，才可继续输出 S05 `normal_task`。
+- 链接无法打开、无权限、下载失败、解析失败或只能看到 HTML 预览页时，不得输出 `normal_task`。
+- 如果 current/history 有明确 rooming list 语境，输出 S05 `manual_review`。
+- 如果没有 rooming list 语境，也无法安全路由，应交由 S99 fallback 或对应 Skill。
+
+`manual_review` 应保留链接、文件名、下载 / 解析失败状态和相关邮件上下文。
+
+### 9.5 Current / History Boundary Rule
+
+S05 的业务动作必须来自 current 邮件。
+
+允许 history 作为辅助证据：
+
+- history 中酒店要求 `Kindly provide the rooming list`。
+- current 紧接着发送文件或文件链接。
+- history 中的 `Group Code`、stay period、room requirement 可辅助判断文件归属。
+
+不得只因为 history 中曾出现 rooming list 请求，就为 current 创建 S05 任务。
+
+### 9.6 Target Object Validation Rule
+
+S05 需要把名单绑定到具体业务对象。
+
+可绑定 key：
+
+- `group_code`
+- `confirmation_number`
+- reservation no
+- case code / block code
+
+允许 key 来源：
+
+- current 正文
+- current subject
+- current 文件内容
+- sheet 名
+- 附件文件名，作为辅助证据
+- history 中的酒店确认或索要 rooming list 上下文，作为辅助证据
+
+目标校验只做两件事：
+
+1. 是否存在对应有效 reservation / group block / booking record。
+2. 如果不存在，是否存在可关联的待完善 New Booking 或相关上游任务卡。
+
+如果二者都找不到，输出 `manual_review`。
+
+S05 第一版不因为以下情况阻断：
+
+- 是否已经有过 Rooming List。
+- 是否可能重复提交。
+- 是否已有 active workflow。
+- 对象状态是否允许继续创建 Rooming List。
+
+这些判断由信息系统在用户确认和后续执行时做硬校验。
+
+### 9.7 Multi-Group / Multi-Sheet Rule
+
+一个 current 邮件或一个 workbook 中包含多个 group / sheet 时，按目标对象拆分。
+
+示例：
+
+- current 写 `HD260510A -1`，sheet 写 `HD260510A-1`，二者在去空格和标准化连字符后可安全匹配，则可绑定为同一目标。
+- `HD260510A-1`、`HD260510A-2`、`HD260510A-3`、`HD260510A-4` 应拆成多个 Rooming List 任务候选。
+- `总名单` 默认作为 shared evidence。
+
+如果 sheet 与 group 的对应关系不清，相关部分输出 `manual_review`。
+
+### 9.8 S02 Update Booking Relationship Rule
+
+如果 current 邮件同时包含 amendment / update 文本和名单文件，应拆分事件：
+
+- amendment / update 内容走 `update_booking_amendment_skill`。
+- Rooming List / Name List 文件走本 Skill。
+- 如果能拆，分别生成独立 `source_event_index` 和独立 `ai_task_result`。
+- 如果无法判断文件是 update 表还是名单，或无法拆分 current 动作，输出 structured `manual_review` 或 S99 fallback。
+
+示例：
+
+- `----AMEND------` 段落中的日期 / 房量变化走 S02。
+- 同一封 current 邮件中的 `Copy of HD260510A.xlsx` 文件链接，如果可读取且文件内容是名单，走 S05。
+- 如果只有 Google Drive 链接但系统打不开，走 S05 `manual_review`，不得输出 `normal_task`。
+
+### 9.9 Downstream Action Intent Rule
+
+S05 任务卡中应结构化保留后续动作意图，但不执行：
+
+- `import_rooming_list`
+- `pm_room_confirmation`
+- `routing_instruction`
+- `routing_target = Master Group`
+- `ta_recorder_task_candidate`
+- `note_task_candidate`
+- `block_status_update_intent`
+
+如果目标是 Group Block，用户确认后信息系统可将 Block Status 从 `TEN` 更新为 `DEF`。FIT 不适用 Group 专属 Block Status / breakfast remark。
+
+## 10. Normal Task Output
+
+仅当可以安全创建 Rooming List 任务时，输出：
+
+```json
+{
+  "result_type": "normal_task",
+  "task_type": "Rooming List",
+  "current_or_history": "current"
+}
+```
+
+必须同时满足：
+
+- current 邮件确实提交名单文件、名单内容或可读文件链接。
+- 文件内容或 current 语义能确认是 Rooming List / Name List。
+- 能识别明确 group code / reservation no / case key。
+- 能找到有效 reservation / group block / booking record，或可关联待完善 New Booking / 上游任务。
+- 多 group / 多 sheet 能安全拆分。
+- 每个任务的目标对象与附件 / sheet 绑定清楚。
+
+完整输出必须符合统一输出契约。关键要求：
+
+- `source_message_id` 必须原样带回。
+- `source_event_index` 必须原样带回。
+- `case_keys.group_code` 或 `case_keys.confirmation_number` 必须绑定单个目标。
+- `visible_reason` 应说明 current 提交名单证据、文件类型判断、target key 来源和目标对象校验结果。
+- `relevant_message_excerpt` 应来自 current 邮件文本；如果依赖 history 辅助识别，应在 `context_used` 中说明。
+- `attachments` / `file_references` 必须包含当前名单文件、文件链接或可展示引用。
+- `context_used` 应记录文件类型判断证据、routing context 摘要和使用的 reference 文件。
+- `extracted_fields.list_evidence_type` 应填入 `rooming_list` / `name_list` / `guest_list` / `room_assignment_list`。
+- `extracted_fields.file_type_validation` 应记录为什么它是名单而不是 booking update 表。
+- `extracted_fields.target_object_validation` 应记录匹配到的是有效对象还是待完善 New Booking / 上游任务。
+- `extracted_fields.downstream_action_intents` 应保留后续执行意图。
+
+建议 `extracted_fields` 保留：
+
+- `list_evidence_type`
+- `file_read_status`
+- `file_type_validation`
+- `attachment_binding`
+- `workbook_name`
+- `sheet_name`
+- `shared_evidence_sheets`
+- `target_key`
+- `target_key_source`
+- `target_object_validation`
+- `downstream_action_intents`
+- `derived_task_candidates`
+
+`derived_task_candidates` 可包含：
+
+- `TA Recorder`：按 S05 已确认的目标 `group_code` 派生；一个目标 `group_code` 一张 S08 linked task，默认带入当前 Group Code，绑定 Rooming List / Name List 文件，可人工修改。同一个 workbook / file_reference 可以共享给多张 S08；sheet 只作为绑定证据，不直接决定 `group_code`。
+- `Note`：包含 Payer code、Charge code、Breakfast 选择字段。
+
+## 11. Manual Review Output
+
+当 current 邮件疑似提交 Rooming List / Name List，但不能安全创建 `normal_task` 时，输出：
+
+```json
+{
+  "result_type": "manual_review",
+  "task_type": "Rooming List",
+  "current_or_history": "current"
+}
+```
+
+S05 的 `manual_review` 用于让用户确认文件类型、补充可读取文件、确认 target key、确认 sheet / 附件归属，或关联有效 reservation / group block / booking record / 待完善 New Booking / 上游任务卡。
+
+本 Skill 的 `manual_review` 采用精简结构，不包含 `suggested_human_actions`。
+
+即使输出 `manual_review`，也要尽力结构化保留：
+
+- 已识别 group code / reservation no / case key 候选及来源。
+- 文件名、链接、附件引用、`file_reference`。
+- 文件读取 / 下载 / 解析失败状态。
+- workbook / sheet / 文件区域候选。
+- 当前邮件摘要。
+- 如果能判断文件类型候选，应填入 `extracted_fields.list_evidence_type` 或 `file_type_validation.candidate_type`。
+- 如果看起来是 booking update 表，应保留负向证据并说明不应走 normal S05。
+- 如果 routing context 有候选对象或待完善 New Booking / 上游任务卡，应保留候选摘要。
+- 不能可靠确认的字段不要猜，填 `null`、空字符串或空数组。
+- 不确定原因必须写入 `manual_review.reason_code`。
+- 缺失字段写入 `manual_review.missing_fields`。
+- 阻塞点写入 `manual_review.blocking_points`。
+- 冲突点写入 `manual_review.conflicting_points`。
+- 建议人工查看的证据写入 `manual_review.evidence_to_check`。
+- locked 的后续动作写入 `extracted_fields.locked_downstream_actions`，例如 Import、TA Recorder、Note、Routing 暂不执行。
+
+建议结构：
+
+```json
+{
+  "manual_review": {
+    "reason_code": "",
+    "visible_reason": "",
+    "review_record_type": "rooming_list_manual_review",
+    "blocking_points": [],
+    "missing_fields": [],
+    "conflicting_points": [],
+    "evidence_to_check": []
+  }
+}
+```
+
+典型 `reason_code`：
+
+- `file_type_unconfirmed`
+- `external_file_unreadable`
+- `external_file_permission_denied`
+- `file_download_failed`
+- `file_parse_failed`
+- `missing_rooming_file`
+- `rooming_context_without_readable_file`
+- `booking_update_table_detected`
+- `target_key_missing`
+- `target_object_not_found`
+- `multiple_target_objects_found`
+- `sheet_group_binding_unclear`
+- `multiple_group_scope_unclear`
+- `current_history_boundary_unclear`
+- `mixed_update_and_rooming_not_splittable`
+
+常见 `blocking_points`：
+
+- `excel_or_link_is_not_enough_to_classify_rooming_list`
+- `external_file_cannot_be_downloaded_or_parsed`
+- `file_looks_like_booking_update_table`
+- `rooming_file_is_visible_but_target_key_is_missing`
+- `sheet_name_and_current_group_code_do_not_match`
+- `target_object_not_found_in_records_or_pending_upstream_tasks`
+- `cannot_split_update_text_and_rooming_file_safely`
+
+以下情况输出 `manual_review`：
+
+- 只有 Excel / 链接，但不能确认是名单。
+- 文件链接打不开、无权限、下载失败、解析失败。
+- 文件内容不可读。
+- current / history 显示应有 rooming list，但名单文件缺失。
+- 文件像名单，但缺少可绑定的 group code / reservation no。
+- 多个 group / sheet / 附件归属不清。
+- sheet 名、正文 code、历史 group code 之间冲突。
+- routing context 找不到有效对象，也找不到可关联待完善 New Booking / 上游任务。
+- current 同时包含 S02 / S05 或其他动作，但无法安全拆分。
+- QBD / LianTai 表格证据不可读，无法判断是 booking update 表还是名单表。
+
+## 12. Tool Invocation Placeholder
+
+当前创建任务卡 / 可见记录的具体 Tool / API 尚未实现，本节只预留对接位置和语义契约，不定义最终 endpoint、鉴权方式或完整返回结构。
+
+- tool_status: `TBD`
+- suggested_tool_name: `create_task_card` / `TBD`
+- tool_purpose: 根据信息系统统一任务卡创建接口，创建 Rooming List 任务卡或人工复核 / 人工处理任务卡。
+- tool_owner: 信息系统。
+- caller: AI Runtime / Main Agent / Skill Orchestrator，最终由系统架构确认。
+- invocation_timing: Skill 输出 `ai_task_result` 并通过 Unified Output Contract 校验后。
+- payload_rule: Skill 能识别出的名单文件、文件类型判断、单个 target key、sheet / 附件绑定、目标对象校验结果和后续动作意图照实填入；无法安全创建时输出 `manual_review`。
+- must_not_call_when:
+  - Skill 输出不符合统一契约
+  - current 事件完全不应进入 AI 工作台记录
+  - 输出内容缺少任务卡 / 可见记录创建所需的最低溯源字段
+- minimum_payload_should_include:
+  - `source_message_id`
+  - `source_event_index`
+  - `catalog_code`
+  - `skill_id`
+  - `result_type`
+  - `task_type`
+  - `case_keys`
+  - `visible_reason`
+  - `relevant_message_excerpt`
+  - `attachments` / `file_references`
+  - `context_used`
+  - `extracted_fields`
+  - `manual_review`
+  - `additional_operations`
+  - `idempotency_key` / `TBD`
+- expected_tool_result: `TBD`
+
+Tool 设计原则：
+
+- Rooming List Skill 只调用一个统一任务卡创建 Tool：`create_task_card`。
+- TA Recorder、Note、Routing、Block Status 更新只是后续执行意图或 linked task candidates，不拆成 S05 专属 Tool。
+- TA Recorder linked task 应按 S05 的目标对象拆分结果派生；不得用一个 TA Recorder 合并多个 `group_code`，也不得只凭 sheet 名生成 TA Recorder。
+- AI 不直接写数据库，只调用信息系统暴露的受控 Tool / API。
+- 信息系统负责文件下载、权限、解析、真实任务卡 ID、人工复核任务卡 ID、幂等、并发、状态机和最终落库。
+- 信息系统在创建任务卡或执行前仍需做硬校验，不能只依赖 AI 判断。
+- 如果 Tool 尚不可用，本 Skill 仍应输出合格的 `ai_task_result`；不得编造 Tool 调用结果。
+
+## 13. Conflict Or Fallback Rule
+
+- 如果 current 邮件同时包含 Rooming List 和 Update Booking，能拆则按 `source_event_index` 拆分，分别走 S05 和 S02。
+- 如果 current 邮件同时包含 Rooming List 和 New Booking，名单事件应绑定到可关联 New Booking / 上游任务；无法确认绑定时输出 `manual_review`。
+- 如果 current 邮件同时包含 Rooming List 和 Voucher / payment evidence，能拆则拆；不能拆则输出 structured `manual_review` 或交由 S99。
+- 如果文件类型无法判断是名单还是 booking update 表，不得猜，输出 `manual_review`。
+- 如果 current / history 边界不清，输出 structured `manual_review` 或交由 `exception_detection_skill`。
+- 如果 current 邮件只是明确轻量消息通知且没有新的名单文件 / 名单动作，应由 `message_notification_skill` 输出 `informational_message`。
+
+## 14. Must Not
+
+- 不因 Excel 后缀直接触发。
+- 不因文件名像 group code 直接触发。
+- 不把 booking update 表误判成名单。
+- 不直接导入名单到 Opera。
+- 不直接创建 PM room。
+- 不直接维护 Routing Instruction。
+- 不直接写 TA Recorder。
+- 不直接写 Note。
+- 不直接更新 Block Status。
+- 不猜 Rate Code。
+- 不猜 Breakfast location。
+- 不把多个 group 合并成一个任务。
+- 不输出 `informational_message`。
+- 不输出 `no_action`。
+- 不输出 `exception_task`。
+- 不把 `manual_review` 输出成空泛的“人工看一下”。
diff --git a/docs/import/20260706/0630AI_副本 2/skill/S06_amend_group_code_skill.md b/docs/import/20260706/0630AI_副本 2/skill/S06_amend_group_code_skill.md
new file mode 100644
index 0000000..a41ddb1
--- /dev/null
+++ b/docs/import/20260706/0630AI_副本 2/skill/S06_amend_group_code_skill.md	
@@ -0,0 +1,407 @@
+# S06 Amend Group Code Skill
+
+## 1. Skill Identity
+
+- catalog_code: `S06`
+- skill_id: `amend_group_code_skill`
+- skill_name: `Amend Group Code Skill`
+- task_type: `Amend Group Code`
+
+Supported action:
+
+- `amend_group_code`
+
+## 2. Purpose
+
+本 Skill 用于判断一条来自 `body_current` 的当前邮件事件，是否明确要求把已有 booking / group block / reservation 的 Group Code 从旧值改为新值，并生成 Amend Group Code 任务卡候选。
+
+第一版保持窄口径：
+
+- 当前事件明确存在旧 Group Code 改为新 Group Code 的业务动作：输出 `normal_task`。
+- 当前事件只有模糊改团号语义但没有明确 old / new 关系，或 `AMEND GROUP CODE TO` 后的新 Group Code 识别不清：输出 `manual_review`。
+
+本 Skill 不直接写数据库，不直接写 Opera，不直接调用 Group Code / Reservation / Group Block 更新 API，不直接创建真实 TaskCard，不确认订单状态。
+
+如果本 Skill 输出 `ai_task_result` 且通过统一输出校验，AI Runtime / Main Agent / Skill Orchestrator 后续可调用信息系统提供的统一受控 Tool / API 创建 Amend Group Code 任务卡或人工复核 / 人工处理任务卡。真实 TaskCard ID、状态机、幂等、并发、执行前硬校验和 Group Code 更新均由信息系统负责。
+
+## 3. Scope
+
+本 Skill 覆盖 current 邮件中的 Group Code 修改事件：
+
+- 邮件正文明确写旧 Group Code 改为新 Group Code。
+- Excel / table 当前事件明确写 `AMEND GROUP CODE` 或 `AMEND GROUP CODE TO`。
+- PDF / 图片 OCR 中明确出现 Group Code 修改动作。
+- 中文、英文、泰文中明确表达旧团号 / Group Code 改为新团号 / Group Code。
+
+S06 只处理 Group Code 修改本身。同行、同句或同段中出现的房型、房量、日期、餐食、备注、凭证、名单等其他业务信息，不改变 S06 的主任务类型。
+
+任务卡前端展示字段只包含：
+
+- `old_group_code`
+- `new_group_code`
+
+统一输出契约所需的 source、evidence、routing context、target validation、same-event details 等字段可以进入后台 payload 或 `context_used` / `extracted_fields`，但不作为 Amend Group Code 任务卡前端展示字段。
+
+## 4. When To Use
+
+当 `body_current` 中的当前邮件事件满足以下任一条件时，Main Agent 可以调用本 Skill：
+
+- 当前正文明确写 `AMEND GROUP CODE TO : <new_group_code>`。
+- 当前正文明确写 `AMEND GROUP CODE`，并能从同一当前事件识别 old / new 关系。
+- 当前附件表格、PDF 或图片 OCR 的当前事件明确写 `AMEND GROUP CODE TO : <new_group_code>`。
+- 当前事件中有明确方向关系，例如 `A to B`、`A change to B`、`A 改为 B`、`A เปลี่ยนเป็น B`，且语义是修改 Group Code。
+
+其中 `AMEND GROUP CODE TO : <new_group_code>` 是强信号。
+
+触发来源不能限定为附件或表格；正文、附件表格、PDF、图片 OCR 都可以作为 current 证据。
+
+## 5. Must Not Use When
+
+不得在以下情况下使用本 Skill 生成 Amend Group Code `normal_task`：
+
+- 只是提到 Group Code，但没有修改 Group Code 的业务动作。
+- 只有一个 Group Code，且无法判断它是旧值还是新值。
+- 当前邮件是在全新创建预订，且没有旧 Group Code 改新 Group Code 的动作，应走 `new_booking_skill`。
+- 当前邮件只是普通修改日期、晚数、房型、房量、人数、价格或备注，且没有 Group Code 修改动作，应走 `update_booking_amendment_skill`。
+- 当前邮件只是取消 booking / group / allotment / control block，且没有 Group Code 修改动作，应走 `cancel_booking_skill`。
+- 当前邮件只是收到 Voucher / payment slip / payment confirmation，应走 `voucher_received_skill`。
+- 当前邮件只是提交 Rooming List / Name List，应走 `rooming_list_name_list_skill`。
+- 主语义是 `CANCEL BOOKING`、cut allotment、release allotment 或 CXL，只是顺带提到 moved / join group / เปลี่ยนเป็นกรุ๊ป，不得硬判为 S06。
+- Group Code 修改动作只出现在 `body_thread`，不在 `body_current`。
+- 当前邮件只是 thank you、FYI、acknowledgement、noted、received、confirmed receipt、确认收到、转发说明、仅同步信息或无新业务动作。
+
+固定列位置、固定单元格位置或固定 sheet 名不得作为 S06 的业务识别规则。
+
+例如，不得写死：
+
+- 某一列一定是 action / remark 列。
+- 某一列一定是旧 Group Code。
+- 某个 sheet 的固定单元格一定代表 Group Code 修改。
+
+列号、行号、单元格地址、sheet 名只可作为 evidence location 或后台溯源字段，不能作为业务识别规则本身。S06 必须依赖文本语义、old / new 关系、`AMEND GROUP CODE TO` 等业务表达。
+
+## 6. Allowed Result Types
+
+第一版只允许：
+
+- `normal_task`
+- `manual_review`
+
+第一版不输出：
+
+- `exception_task`
+- `no_action`
+- `informational_message`
+
+## 7. Key Context Needed
+
+Main Agent 应尽量提供以下上下文：
+
+- `source_message_id`
+- `source_event_index`
+- 当前邮件 subject
+- `body_current` 中当前 Group Code 修改事件原文片段
+- 当前附件摘要、表格摘要、PDF / 图片 OCR 摘要
+- `old_group_code`
+- `new_group_code`
+- 可用引用历史正文，作为 evidence context
+- `routing_context`
+- 已写入 reservation / group block / booking record 查询结果
+- 可关联待完善 New Booking / 上游任务卡查询结果
+- 如果同一不可拆分事件中还有其他业务动作，提供其原文摘要供后台 payload 保留
+
+`body_thread` 只能作为 evidence context，不得单独触发 S06。
+
+路由级查询时，如果能识别 `old_group_code`，`case_keys.group_code` 应优先使用旧 Group Code，因为它通常用于定位当前已存在对象；新 Group Code 应作为 S06 业务字段传入。
+
+## 8. Input Requirements Summary
+
+本 Skill 输入应包含：
+
+- 当前 Group Code 修改请求摘要。
+- `body_current` 相关原文片段。
+- 当前附件 / 表格 / OCR 摘要。
+- 已识别的 `old_group_code` 和 `new_group_code`。
+- old / new 关系的证据说明。
+- routing context，如有。
+- 可用历史证据上下文，如有。
+- 同一事件中附带的其他业务动作原文摘要，如有。
+
+本 Skill 不要求 Main Agent 在输入阶段固定完整 `extracted_fields` schema。
+
+### 8.1 Bundled / Shared References
+
+当 current message、attachment、sender、subject 或 extracted evidence 显示 QBD / LianTai Excel / table workflow 时，Main Agent 应读取：
+
+- `../references/qbd_liantai_email_table_rules.md`
+
+使用该 reference 的目的：
+
+- 区分 current / history。
+- 判断当前有效高亮 / 黄色行。
+- 遵守一行一个 `source_event_index`、一个 `ai_task_result`、一个任务卡候选。
+- 保留 row-level evidence 作为后台溯源。
+- 避免把历史 AMD / CXL 行误判成当前任务。
+
+注意：
+
+- QBD / LianTai reference 可以帮助定位当前行和解释删除线、红字、before / after 线索。
+- Reference 中的列、行、单元格位置不得被 S06 写死为业务识别规则。
+- S06 不读取房型映射或 Rate Code reference 来处理同行房型、房量、价格；这些同事件信息只作为后台附带业务信息保留。
+- 如果同一 current 邮件或附件中存在可拆分的独立房型 / 房量 / 价格修改事件，应拆分 `source_event_index` 并交给 S02。
+
+## 9. Decision Rules
+
+### 9.1 Current Event Rule
+
+Group Code 修改动作必须来自 `body_current` 或 current 附件 / current OCR 证据。
+
+如果修改动作只出现在 `body_thread`，不得输出 S06 `normal_task`。
+
+### 9.2 Trigger Rule
+
+`AMEND GROUP CODE TO : <new_group_code>` 是强信号。
+
+其他表达也可以触发，但必须能表达 Group Code 修改动作，例如：
+
+- `AMEND GROUP CODE`
+- `change group code to`
+- `change from <old_group_code> to <new_group_code>`
+- `改团号`
+- `改 Group Code`
+- `เปลี่ยน group code`
+
+不得仅因出现类似 Group Code 的字符串就触发。
+
+### 9.3 Old / New Extraction Rule
+
+S06 只抽取两个真正业务字段：
+
+- `old_group_code`
+- `new_group_code`
+
+抽取原则：
+
+- `new_group_code` 优先来自 `AMEND GROUP CODE TO :` 后面的明确 code。
+- `old_group_code` 来自同一 current 事件中表达“被改掉的旧 code”的上下文。
+- 正文中可以从 `A to B`、`A change to B`、`old A new B`、`A 改为 B`、`A เปลี่ยนเป็น B` 等方向关系识别。
+- 表格中可以结合删除线、红字、before / after、同一行上下文判断旧 code，但不得把固定列位置写成规则。
+- 如果只出现一个 code，且无法判断它是旧 code 还是新 code，不得硬猜。
+
+### 9.4 Target Validation Rule
+
+S06 需要像 S02 一样把 routing context / 历史上下文带进去校验：
+
+1. 是否存在对应有效 reservation / group block / booking record。
+2. 如果没有现成记录，是否存在可承接的待完善 New Booking 任务卡或上游任务。
+3. 新 Group Code 是否已经关联其他对象。
+
+这些校验结果传给信息系统或用于后台判断，不作为 S06 扩大 `manual_review` 的理由。信息系统在用户确认和后续执行前仍需做硬校验。
+
+### 9.5 Multiple Task Rule
+
+S06 可以和其他任务同时发生，其他任务不限于 S02，也可能包括：
+
+- S01 New Booking
+- S02 Update Booking
+- S03 Cancel Booking
+- S04 Voucher Received
+- S05 Rooming List / Name List
+- S07 Trace / Reservation Notes
+- 其他后续 Skill
+
+如果多个业务动作可以清楚拆分，例如不同段落、不同附件、不同表格行、不同凭证、不同当前事件，应拆成多个 `source_event_index`，分别走对应 Skill。
+
+如果 S06 和其他业务动作在同一个不可拆分事件里，例如同一表格行、同一句正文、同一段连续业务指令、同一个 OCR 区块，则一个 `ai_task_result` 只能有一个主任务：
+
+- 主任务优先为 `Amend Group Code`。
+- `skill_id` 使用 `amend_group_code_skill`。
+- 其他业务动作通常作为后台关联信息传给信息系统。
+- 不额外拆出 S01 / S02 / S03 / S04 / S05 任务卡。
+- 任务卡前端仍只展示 `old_group_code` 和 `new_group_code`。
+
+原因：Group Code 修改会影响后续业务动作绑定到哪个 reservation / group block / booking record。
+
+受控例外：
+
+- 如果同一不可拆分事件中同时存在 Trace / Guest Request / extra bed，必须生成 S06 主任务和 S07 linked task。
+- S06 先执行，S07 后执行。
+- S07 linked task 应保留 `parent_source_event_index`、`linked_task_group_id`、`depends_on_task_type=Amend Group Code`、`blocked_until_parent_completed=true`、`execution_order=2` 等后台关系字段。
+
+### 9.6 Table Row Rule
+
+QBD / LianTai 表格继续遵守：
+
+- 一行一个 `source_event_index`。
+- 一行一个 `ai_task_result`。
+- 一行一个任务卡候选。
+- 不跨行合并。
+
+同一当前有效表格行中出现明确 `AMEND GROUP CODE TO`，并同时出现房型、房量、日期、餐食、备注等信息时，该行主任务为 S06；其他信息只进入后台 payload，不作为任务卡前端展示字段，也不单独拆成 S02，除非它们是另一个可拆分当前事件。
+
+受控例外：如果该行同时出现 Trace / Guest Request / extra bed，应在 S06 主任务之外生成 S07 linked task；这不是跨行合并，也不是把 S06 前端展示字段扩大。
+
+## 10. Normal Task Output
+
+仅当可以安全创建 Amend Group Code 任务卡候选时，输出：
+
+```json
+{
+  "result_type": "normal_task",
+  "task_type": "Amend Group Code",
+  "current_or_history": "current"
+}
+```
+
+必须同时满足：
+
+- Group Code 修改动作来自 current 事件。
+- 当前事件明确是旧 Group Code 改为新 Group Code。
+- `old_group_code` 可识别。
+- `new_group_code` 可识别。
+- old / new 方向清楚。
+
+完整输出必须符合统一输出契约。关键要求：
+
+- `source_message_id` 必须原样带回。
+- `source_event_index` 必须原样带回。
+- `case_keys.group_code` 应优先填 `old_group_code`。
+- `visible_reason` 应说明为什么这是 current 邮件中的 Amend Group Code 任务。
+- `relevant_message_excerpt` 必须来自 `body_current` 或 current 附件 / OCR 摘要。
+- `context_used` 应记录 routing context 摘要和使用的 reference 文件。
+- `extracted_fields.old_group_code` 必须填入。
+- `extracted_fields.new_group_code` 必须填入。
+- 如果来自 QBD / LianTai 表格行，应在后台 payload 中保留 row-level evidence，但任务卡前端不展示这些字段。
+- 如果同一事件还有其他业务动作，应在后台 payload 中保留 same-event 原文摘要或后续联动意图，但任务卡前端不展示这些字段。
+- 如果同一事件还有 Trace / Guest Request / extra bed，应生成 S07 linked task，并在后台 payload 保留父子任务关系。
+
+任务卡前端展示字段仅限：
+
+```json
+{
+  "old_group_code": "",
+  "new_group_code": ""
+}
+```
+
+## 11. Manual Review Output
+
+当 current 邮件疑似要求修改 Group Code，但不能安全创建 `normal_task` 时，输出：
+
+```json
+{
+  "result_type": "manual_review",
+  "task_type": "Amend Group Code",
+  "current_or_history": "current"
+}
+```
+
+S06 只在以下情况输出 `manual_review`：
+
+- 只有模糊“改团号 / amend group code”语义，但没有明确 old / new 关系。
+- `AMEND GROUP CODE TO` 后的新 Group Code 识别不清。
+
+其他问题，例如 routing context 没查到目标对象、目标状态不确定、同一事件同时出现其他业务动作，不直接作为 S06 的 `manual_review` 条件。它们应作为后台校验结果或后续信息系统硬校验处理。
+
+S06 的 `manual_review` 采用项目默认结构，除非后续用户另行确认精简结构。
+
+建议结构：
+
+```json
+{
+  "manual_review": {
+    "reason_code": "",
+    "visible_reason": "",
+    "review_record_type": "amend_group_code_manual_review",
+    "blocking_points": [],
+    "missing_fields": [],
+    "conflicting_points": [],
+    "suggested_human_actions": [],
+    "evidence_to_check": []
+  }
+}
+```
+
+典型 `reason_code`：
+
+- `group_code_change_direction_unclear`
+- `new_group_code_unreadable`
+
+注意：
+
+- `manual_review` 不能写成空泛的“人工看一下”。
+- 能确定的 `old_group_code` 或 `new_group_code` 应尽量保留。
+- 不能可靠确认的字段不要猜，填 `null`、空字符串或空数组。
+
+## 12. Tool Invocation Placeholder
+
+当前创建任务卡 / 可见记录的具体 Tool / API 尚未实现，本节只预留对接位置和语义契约，不定义最终 endpoint、鉴权方式或完整返回结构。
+
+- tool_status: `TBD`
+- suggested_tool_name: `create_task_card` / `TBD`
+- tool_purpose: 根据信息系统统一任务卡创建接口，创建 Amend Group Code 任务卡或人工复核 / 人工处理任务卡。
+- tool_owner: 信息系统。
+- caller: AI Runtime / Main Agent / Skill Orchestrator，最终由系统架构确认。
+- invocation_timing: Skill 输出 `ai_task_result` 并通过 Unified Output Contract 校验后。
+- payload_rule: Skill 能识别出的 `old_group_code`、`new_group_code`、routing context、后台证据和同事件附带业务信息照实填入；任务卡前端只展示 `old_group_code` 和 `new_group_code`。
+- must_not_call_when:
+  - Skill 输出不符合统一契约
+  - current 事件完全不应进入 AI 工作台记录
+  - 输出内容缺少任务卡 / 可见记录创建所需的最低溯源字段
+- minimum_payload_should_include:
+  - `source_message_id`
+  - `source_event_index`
+  - `catalog_code`
+  - `skill_id`
+  - `result_type`
+  - `task_type`
+  - `case_keys`
+  - `visible_reason`
+  - `relevant_message_excerpt`
+  - `attachments`
+  - `context_used`
+  - `extracted_fields`
+  - `manual_review`
+  - `additional_operations`
+  - `idempotency_key` / `TBD`
+- expected_tool_result: `TBD`
+
+Tool 设计原则：
+
+- Amend Group Code Skill 只调用一个统一任务卡创建 Tool：`create_task_card`。
+- Group Code 更新是用户确认后的信息系统后续执行动作，不是本 Skill 直接执行动作。
+- 如果同一事件还有其他业务动作，它们通常只是后台联动意图或原文摘要，不拆成 S06 专属 Tool；Trace / Guest Request / extra bed 需要另建 S07 linked task。
+- AI 不直接写数据库，只调用信息系统暴露的受控 Tool / API。
+- 信息系统负责真实任务卡 ID、人工复核任务卡 ID、幂等、并发、状态机、最终落库和执行前硬校验。
+- 如果 Tool 尚不可用，本 Skill 仍应输出合格的 `ai_task_result`；不得编造 Tool 调用结果。
+
+## 13. Conflict Or Fallback Rule
+
+- 如果 current 邮件同时包含 Amend Group Code 和其他业务动作，能拆则按 `source_event_index` 拆分，分别走对应 Skill。
+- 如果 Amend Group Code 与其他业务动作属于同一不可拆分事件，主任务走 S06，其他动作通常只进入后台 payload 或后续联动意图。
+- 如果同一不可拆分事件中还有 Trace / Guest Request / extra bed，应生成 S06 主任务和 S07 linked task。
+- 如果同一表格行明确是 `AMEND GROUP CODE TO`，主任务走 S06，不因同行房型、房量、日期、餐食或备注改走 S02。
+- 如果当前事件只有普通 update，没有 Group Code 修改动作，走 S02。
+- 如果当前事件主语义是 cancel / CXL，且没有明确 old Group Code 改 new Group Code，不走 S06。
+- 如果当前 / history 边界不清且无法确认 Group Code 修改来自 current，交由 `exception_detection_skill` 或 structured `manual_review`。
+- 如果多个 Skill 冲突且无法安全拆分，也无法按“同一不可拆分事件主任务 S06”规则判断，交由 `exception_detection_skill`。
+
+## 14. Must Not
+
+- 不从 `body_thread` 生成 `normal_task`。
+- 不把固定列位置、固定单元格或固定 sheet 名当成业务识别规则。
+- 不因为一个字符串像 Group Code 就触发 S06。
+- 不猜 `old_group_code`。
+- 不猜 `new_group_code`。
+- 不把主语义为 cancel 的事件硬判成 S06。
+- 不把同一当前有效表格行拆成多个无关任务卡；S06 + S07 linked task 是受控例外。
+- 不把多个表格行合并成一个任务卡。
+- 不把同行房型、房量、日期、餐食、备注作为任务卡前端展示字段。
+- 不输出 `informational_message`。
+- 不输出 `no_action`。
+- 不输出 `exception_task`。
+- 不直接调用 Group Code 更新 API。
+- 不直接写 Opera。
+- 不直接写数据库。
+- 不编造 Tool endpoint、鉴权、返回结构或调用结果。
+- 不把 `manual_review` 输出成空泛的“人工看一下”。
diff --git a/docs/import/20260706/0630AI_副本 2/skill/S07_trace_reservation_notes_skill.md b/docs/import/20260706/0630AI_副本 2/skill/S07_trace_reservation_notes_skill.md
new file mode 100644
index 0000000..853a395
--- /dev/null
+++ b/docs/import/20260706/0630AI_副本 2/skill/S07_trace_reservation_notes_skill.md	
@@ -0,0 +1,588 @@
+# S07 Trace / Reservation Notes Skill
+
+## 1. Skill Identity
+
+- catalog_code: `S07`
+- skill_id: `trace_reservation_notes_skill`
+- skill_name: `Trace / Reservation Notes Skill`
+- task_type: `Trace / Reservation Notes`
+
+Supported trace subtypes:
+
+- `extra_bed`
+- `general_request`
+
+## 2. Purpose
+
+本 Skill 用于判断一条来自 `body_current` 的当前邮件事件，是否需要为既有 reservation / group block / booking record，或为同一 current 事件中新建 / 修改 / 改团号任务后续生成 Trace / Reservation Notes 任务卡候选。
+
+第一版核心口径：
+
+- S07 内部只使用两个 subtype：`trace_subtype = extra_bed` 和 `trace_subtype = general_request`。
+- `extra_bed` 固定写入 Trace Text：`Set Extrabed`，同步 FO + HSK，并输出入住人数和房价调整意图。
+- `general_request` 写入具体要求文本，并按要求类型同步 FO 或 FO + HSK。
+- 如果 trace / guest request 与 S01 / S02 / S06 同一 current 事件或同一表格行出现，应同时生成主业务任务和 S07 linked task，先处理主业务任务，再处理 S07。
+- 如果 trace 内容、目标对象、父任务或部门同步规则无法安全确认，输出 S07 `manual_review` 或由 S99 fallback 处理。
+
+本 Skill 不直接写数据库，不直接写 Opera，不直接调用 Trace / Reservation Notes 写入 API，不直接修改入住人数，不直接修改房价，不直接创建真实 TaskCard。
+
+如果本 Skill 输出 `ai_task_result` 且通过统一输出校验，AI Runtime / Main Agent / Skill Orchestrator 后续可调用信息系统提供的统一受控 Tool / API 创建 Trace / Reservation Notes 任务卡或人工复核 / 人工处理任务卡。真实 TaskCard ID、状态机、幂等、并发、执行前硬校验和最终写入均由信息系统负责。
+
+## 3. Scope
+
+本 Skill 覆盖 current 邮件中的 Trace / Reservation Notes / Guest Request：
+
+- 邮件正文明确要求添加、修改或取消 Trace / Reservation Notes。
+- 邮件正文明确要求添加、修改或取消客人特殊要求。
+- 当前附件表格、PDF 或图片 OCR 中明确出现 Trace / Reservation Notes / Guest Request / extra bed。
+- QBD / LianTai 表格当前有效行中出现 extra bed、加床、`เตียงเสริม`、`U-เตียงเสริม`、`เสริมเตียง` 等客人要求。
+- 与 S01 / S02 / S06 同一事件出现的 Trace / Guest Request / extra bed，需要生成 S07 linked task。
+
+S07 不处理：
+
+- 新建 booking / group block / allotment。
+- 修改日期、晚数、房型、房量、Group Code、取消状态。
+- Rate Code 判断或房型映射。
+- Voucher / payment slip / payment confirmation。
+- Rooming List / Name List。
+
+任务卡前端展示字段建议：
+
+- `target_key`
+- `trace_subtype`
+- `trace_text`
+- `notify_departments`
+
+如果 `trace_subtype = extra_bed`，可额外展示或后台保留：
+
+- `occupancy_update`
+- `requires_rate_update`
+- `rate_adjustment_formula`
+
+## 4. When To Use
+
+当 `body_current` 中的当前邮件事件满足以下任一条件时，Main Agent 可以调用本 Skill：
+
+- 当前事件明确要求添加、更新或取消 Trace。
+- 当前事件明确要求添加、更新或取消 Reservation Notes。
+- 当前事件明确要求添加、更新或取消 Guest Request / Special Request。
+- 当前事件明确要求记录房间偏好、排房要求、房间布置、到店偏好、arrival note、remark / note，且该内容不改变主业务类型。
+- 当前事件只要求为既有订单添加、修改或取消 extra bed / 加床 / `เตียงเสริม` / `U-เตียงเสริม` / `เสริมเตียง`。
+- 当前事件或当前表格行同时存在 S01 / S02 / S06 主业务动作和 Trace / Guest Request / extra bed，应在主业务任务之外生成 S07 linked task。
+
+典型触发词和表达：
+
+- `Trace`
+- `Reservation Note`
+- `Reservation Notes`
+- `Guest Request`
+- `Special Request`
+- `Remark`
+- `Note`
+- `extra bed`
+- `add extra bed`
+- `加床`
+- `เตียงเสริม`
+- `U-เตียงเสริม`
+- `เสริมเตียง`
+- `Non-smoking room`
+- `High floor`
+- `Away from elevator`
+- `Same floor`
+- `Set Honeymoon`
+
+触发来源不能限定为附件或某个固定列；正文、附件表格、PDF、图片 OCR 都可以作为 current 证据。
+
+## 5. Must Not Use When
+
+不得在以下情况下使用本 Skill 生成 S07 `normal_task`：
+
+- Trace / Guest Request 只出现在 `body_thread`，不在 `body_current`。
+- 当前事件没有 Trace、Reservation Notes、Guest Request 或 extra bed 类动作。
+- 当前事件只是普通 New Booking、Update Booking、Cancel Booking、Voucher Received、Rooming List、Amend Group Code，且没有 Trace / Guest Request / extra bed。
+- 当前事件只是 thank you、FYI、acknowledgement、noted、received、confirmed receipt、确认收到、转发说明、仅同步信息或无新业务动作，应走 S10。
+- 主语义是 Cancel Booking / CXL，且只是被取消对象上历史存在 extra bed 或 guest request，不得自动额外生成 S07。
+- 无法判断当前文字是消息通知还是可执行 trace 任务时，不得硬走 S07，应走 S99 structured `manual_review`。
+
+不得把 extra bed 当作：
+
+- `room_quantity`
+- PMS room type
+- FIT / Group 判断依据
+- Rate Code 判断依据
+- Fix Charge 独立触发依据
+
+`U-เตียงเสริม` 不是 PMS 房型，必须作为 `trace_subtype = extra_bed` 处理。
+
+## 6. Allowed Result Types
+
+第一版只允许：
+
+- `normal_task`
+- `manual_review`
+
+第一版不输出：
+
+- `exception_task`
+- `no_action`
+- `informational_message`
+
+## 7. Key Context Needed
+
+Main Agent 应尽量提供以下上下文：
+
+- `source_message_id`
+- `source_event_index`
+- 当前邮件 subject
+- `body_current` 中当前 Trace / Guest Request 原文片段
+- 当前附件摘要、表格摘要、PDF / 图片 OCR 摘要
+- `group_code`
+- `confirmation_number`
+- reservation number / booking record key，如有
+- parent primary task context，如 S01 / S02 / S06 的 task type、source_event_index、case key
+- routing context
+- 已写入 reservation / group block / booking record 查询结果
+- 可关联待完善 New Booking / 上游任务卡查询结果
+- 可用引用历史正文，作为 target binding evidence context
+- 从引用历史或最近相关线程中识别出的 target key 候选、父 group、上游任务关系和 target key 来源
+
+`body_thread` 只能作为 evidence context，不得单独触发 S07。若 trace 动作来自 `body_current`，`body_thread` 可以用于绑定目标对象或父任务。
+
+## 8. Input Requirements Summary
+
+本 Skill 输入应包含：
+
+- 当前 Trace / Guest Request 请求摘要。
+- `body_current` 相关原文片段。
+- 当前附件 / 表格 / OCR 摘要。
+- 已识别的目标对象 key，例如 `group_code`、`confirmation_number`、reservation number。
+- 如果是 linked task，应提供父任务信息。
+- routing context，如有。
+- 可用历史证据上下文，如有。
+
+本 Skill 不要求 Main Agent 在输入阶段固定完整 `extracted_fields` schema。
+
+### 8.1 Bundled / Shared References
+
+当 current message、attachment、sender、subject 或 extracted evidence 显示 QBD / LianTai Excel / table workflow 时，Main Agent 应读取：
+
+- `../references/qbd_liantai_email_table_rules.md`
+
+使用该 reference 的目的：
+
+- 区分 current / history。
+- 判断当前有效高亮 / 黄色行。
+- 保留 row-level evidence 作为后台溯源。
+- 避免把历史 AMD / CXL 行误判成当前任务。
+- 识别同一表格行中的主任务与 S07 linked task 关系。
+
+注意：
+
+- QBD / LianTai reference 可以帮助定位当前行和同一行内的 Trace / Guest Request / extra bed 证据。
+- Reference 中的列、行、单元格位置不得被 S07 写死为业务识别规则。
+- S07 不读取房型映射或 Rate Code reference 来判断 Rate Code。
+
+## 9. Decision Rules
+
+### 9.1 Current Event Rule
+
+Trace / Reservation Notes / Guest Request / extra bed 动作必须来自 `body_current` 或 current 附件 / current OCR 证据。
+
+如果动作只出现在 `body_thread`，不得输出 S07 `normal_task`。
+
+如果动作来自 `body_current`，但 `group_code` / reservation key 只在 `body_thread` 的最近相关线程中清楚出现，可以把 `body_thread` 作为 target binding evidence。输出必须记录 `target_key_source`、`body_thread_used_only_as_evidence=true`，并保留相关历史片段摘要。
+
+### 9.2 Subtype Rule
+
+S07 必须先判断 `trace_subtype`：
+
+- 明确是 extra bed / 加床 / `เตียงเสริม` / `U-เตียงเสริม` / `เสริมเตียง`：`trace_subtype = extra_bed`。
+- 其他 trace / guest request / reservation note：`trace_subtype = general_request`。
+
+如果无法判断是 `extra_bed` 还是 `general_request`，输出 S07 `manual_review`。
+
+### 9.3 Extra Bed Trace Rule
+
+`trace_subtype = extra_bed` 的固定输出规则：
+
+- `trace_text`: `Set Extrabed`
+- `notify_departments`: `["FO", "HSK"]`
+- `occupancy_update`: `3adult`
+- `requires_rate_update`: `true`
+- `rate_adjustment_formula`: `rate_code_price / 2 * 3`
+
+硬规则：
+
+- S07 不决定 Rate Code。
+- S07 不自己猜 `rate_code_price`。
+- S07 不自己计算最终房价。
+- S07 输出“需要按 `rate_code_price / 2 * 3` 修改房价”的操作意图。
+- 真实取价、计算、落库、校验由信息系统在用户确认后执行。
+- 加床不计入 `room_quantity`，不影响 FIT / Group 判断，不作为 PMS room type。
+- 如果 S07 是从 S01 / S02 / S06 同一事件派生出的 linked task，必须等待父任务完成并确认目标 reservation / group / booking record 后再执行。
+
+示例：
+
+- `Sup 高级房TWN 4 + extra bed 2` 中 `room_quantity = 4`，extra bed 生成 S07 `extra_bed`。
+- `1TPR（ห้องทวิน + เตียงเสริม）` 中 extra bed 生成 S07 `extra_bed`，不新增房量。
+- `1间*3晚加床เตียงเสริม*800=2400` 中原文价格可保留为证据，但 S07 仍使用 `rate_code_price / 2 * 3` 操作意图，不自行计算最终价格。
+
+### 9.4 General Request Trace Rule
+
+`trace_subtype = general_request` 用于非加床的 trace / guest request / reservation note。
+
+输出规则：
+
+- `trace_text`: 具体要求文本。优先标准化成可执行英文；如果无法标准化，则保留原文。
+- `notify_departments`: 按要求类型判断。
+
+排房相关要求只同步 FO：
+
+- `Non-smoking room`
+- `High floor`
+- `Away from elevator`
+- `Same floor`
+
+对应：
+
+```json
+{
+  "notify_departments": ["FO"]
+}
+```
+
+房间布置 / 房务准备要求同步 FO + HSK：
+
+- `Set Honeymoon`
+- 其他需要房务准备、布置、摆设、实际进房处理的要求
+
+对应：
+
+```json
+{
+  "notify_departments": ["FO", "HSK"]
+}
+```
+
+注意：
+
+- 加床虽然也是房务准备，但不放在 `general_request`，必须走 `trace_subtype = extra_bed`。
+- 如果无法判断 `general_request` 应同步 FO 还是 FO + HSK，输出 S07 `manual_review`。
+
+### 9.5 Independent S07 Rule
+
+如果 current 事件只是在既有订单上添加、修改或取消 Trace / Guest Request，且没有其他主业务动作，应直接输出 S07。
+
+必须能确认：
+
+- 目标对象，例如 `group_code`、`confirmation_number`、reservation number、group block key。
+- `trace_subtype`。
+- `trace_text`。
+- `notify_departments`。
+- 这是 current 业务动作。
+
+如果目标对象不存在，但存在可承接的待完善 New Booking / 上游任务卡，可以创建 linked S07 任务，等待上游任务完成后再执行。
+
+### 9.5.1 History Target Binding Rule
+
+S07 不得从 history 触发 trace 任务，但可以用 history 绑定 current trace 任务的目标。
+
+允许输出独立 S07 `normal_task` 的 history 绑定条件：
+
+- `body_current` 明确提出可执行 Trace / Guest Request，例如 welcome screen、welcome drink、registration table、key card、ginger tea、meal note、arrival note、extra bed。
+- `body_thread` 的最近相关线程段、酒店回复、上游 New Booking / Allotment / Update 任务或 parent group 证据能提供唯一目标，或能提供一个明确父 group / upstream task。
+- 多个 child group code 同属同一 parent allocation，且 current request 是线程级 / group-level 服务请求时，可绑定 parent group 或上游 allocation parent，不必拆成所有 child group；除非 current 明确要求逐 child code 分别写不同备注。
+- 输出中标记 `target_key_source="body_thread_evidence"` 或更具体的来源，如 `body_thread_latest_hotel_reply`、`body_thread_parent_group`、`upstream_task_context`。
+- 如果历史 key 未经权威系统确认，设置 `target_object_validation.status="not_available"` 或等价结构，并标记 `requires_downstream_hard_validation=true`。
+
+仍应输出 S07 `manual_review` 的情况：
+
+- `body_current` 没有 Trace / Guest Request 动作，只有 history 有旧备注。
+- `body_thread` 中存在多个互不相关的 group code，无法判断 current request 属于哪个目标。
+- 只能看到 child group code 列表，但没有 parent group、最近相关线程、上游任务或业务规则能说明线程级 request 应绑定哪里。
+- current request 明确只针对部分 child group，但无法判断具体 child group。
+
+### 9.6 Linked S07 With S01 / S02 / S06 Rule
+
+如果 Trace / Guest Request / extra bed 与 S01 / S02 / S06 同一 current 事件或同一表格行出现，应生成两个任务卡候选：
+
+1. 主业务任务卡：S01 / S02 / S06。
+2. S07 linked task：Trace / Reservation Notes。
+
+执行顺序：
+
+- 先处理主业务任务。
+- 再处理 S07。
+
+S07 linked task 必须保留父任务关系：
+
+- `parent_source_event_index`
+- `linked_task_group_id`
+- `depends_on_task_type`
+- `depends_on_source_event_index`
+- `blocked_until_parent_completed: true`
+- `execution_order: 2`
+
+如果统一输出允许非整数 `source_event_index`，可使用类似 `12.1` 表示 S07 linked task。  
+如果统一输出只允许整数，应给 S07 分配新的整数 `source_event_index`，同时通过 `parent_source_event_index` 和 `linked_task_group_id` 表达它来自同一原始事件 / 同一表格行。
+
+这是 QBD / LianTai 一行一个任务规则的受控例外：
+
+- 同一当前有效行可以有一个主业务 `ai_task_result`，再有一个 S07 linked `ai_task_result`。
+- 不得把主业务和 S07 合并成一个 `ai_task_result`。
+- 不得把 S07 trace 只吞进主业务任务而不生成 S07 task。
+
+### 9.7 S03 Boundary Rule
+
+Cancel Booking / CXL 场景不默认额外生成 S07。
+
+如果 Cancel Booking 行里只是历史或被取消对象上带有 extra bed / Guest Request，主任务仍走 S03，不因该信息生成 S07。
+
+只有 current 明确要求“取消后仍需记录某条 trace”或另有独立可执行 trace 动作时，才可以拆出 S07。无法判断时，走 S03 或 S99 structured `manual_review`，不得硬派生 S07。
+
+### 9.8 Object Binding Rule
+
+S07 必须能绑定到一个清楚目标：
+
+- `group_code`
+- `confirmation_number`
+- reservation number
+- group block / control block code
+- 同一 current 事件中的父任务
+- body_current 动作对应的 body_thread 最近相关目标 key、父 group 或上游任务
+
+独立 S07 应校验：
+
+1. 是否存在对应有效 reservation / group block / booking record。
+2. 如果没有现成记录，是否存在可承接的待完善 New Booking / 上游任务卡。
+
+Linked S07 可以绑定父任务，不要求在任务创建时已经有最终 Opera ID；最终写入必须等待父任务完成并确认目标对象。
+
+### 9.9 Table / OCR Source Rule
+
+S07 不得依赖固定列、固定行、固定 sheet 名作为业务识别规则。
+
+QBD / LianTai 表格中，extra bed / Guest Request 可能出现在酒店详情列、备注列、状态列、同一单元格的多行说明中，也可能出现在 PDF / 图片 OCR 中。
+
+行号、列号、单元格地址、sheet 名只可作为 evidence location 或后台溯源字段，不能作为业务识别规则本身。
+
+## 10. Normal Task Output
+
+仅当可以安全创建 Trace / Reservation Notes 任务卡候选时，输出：
+
+```json
+{
+  "result_type": "normal_task",
+  "task_type": "Trace / Reservation Notes",
+  "current_or_history": "current"
+}
+```
+
+必须同时满足：
+
+- Trace / Guest Request 动作来自 current 事件。
+- `trace_subtype` 可判断。
+- `trace_text` 可确定。
+- `notify_departments` 可确定。
+- 可以绑定唯一目标对象，或可以绑定明确父任务。
+- 目标对象可来自 body_current，也可在 current 动作明确时来自 body_thread evidence；后一种情况必须记录 target key 来源。
+- 如果是 linked task，父任务和执行顺序清楚。
+
+完整输出必须符合统一输出契约。关键要求：
+
+- `source_message_id` 必须原样带回。
+- `source_event_index` 必须原样带回。
+- `visible_reason` 应说明为什么这是 current 邮件中的 Trace / Reservation Notes 任务。
+- `relevant_message_excerpt` 必须来自 `body_current` 或 current 附件 / OCR 摘要。
+- `context_used` 应记录 routing context 摘要和使用的 reference 文件。
+- `case_keys` 应填入可确认的 `group_code`、`confirmation_number` 或 reservation key。
+- `extracted_fields.trace_subtype` 必须填入。
+- `extracted_fields.trace_text` 必须填入。
+- `extracted_fields.notify_departments` 必须填入。
+- 如果 `trace_subtype = extra_bed`，必须填入 `occupancy_update=3adult`、`requires_rate_update=true`、`rate_adjustment_formula=rate_code_price / 2 * 3`。
+- 如果 target key 来自 history evidence，`extracted_fields` 必须包含 `target_key_source`、`body_thread_used_only_as_evidence=true`、`target_binding_confidence` 或等价字段，并保留 `requires_downstream_hard_validation=true`。
+- 如果来自 QBD / LianTai 表格行，应在后台 payload 中保留 row-level evidence。
+
+任务卡前端展示字段建议：
+
+```json
+{
+  "target_key": "",
+  "trace_subtype": "",
+  "trace_text": "",
+  "notify_departments": []
+}
+```
+
+`extra_bed` 后台 payload 建议：
+
+```json
+{
+  "trace_subtype": "extra_bed",
+  "trace_text": "Set Extrabed",
+  "notify_departments": ["FO", "HSK"],
+  "occupancy_update": "3adult",
+  "requires_rate_update": true,
+  "rate_adjustment_formula": "rate_code_price / 2 * 3"
+}
+```
+
+通用后台 payload 可保留：
+
+- `raw_guest_request_text`
+- `raw_extra_bed_text`
+- `raw_extra_bed_price_text`
+- `parent_source_event_index`
+- `linked_task_group_id`
+- `depends_on_task_type`
+- `depends_on_source_event_index`
+- `blocked_until_parent_completed`
+- `execution_order`
+- `attachment_id`
+- `filename`
+- `sheet_name`
+- `row_index`
+- `cell_reference`
+- `ocr_evidence`
+
+## 11. Manual Review Output
+
+当 current 邮件疑似包含 Trace / Reservation Notes / Guest Request / extra bed，但不能安全创建 `normal_task` 时，输出：
+
+```json
+{
+  "result_type": "manual_review",
+  "task_type": "Trace / Reservation Notes",
+  "current_or_history": "current"
+}
+```
+
+典型 `manual_review` 条件：
+
+- 可见 Trace / Guest Request / extra bed 信号，但内容无法读清。
+- 无法判断是 `extra_bed` 还是 `general_request`。
+- `general_request` 无法判断应同步 FO 还是 FO + HSK。
+- 无法确认 S07 的目标对象，也无法确认父任务。
+- current 动作明确，但 history 中有多个互不相关目标且无法确定应绑定哪个。
+- 加床 trace 无法绑定目标 reservation，无法执行人数和房价修改。
+- 加床 trace 需要改价，但信息系统无法取得或确认 `rate_code_price`。
+- 同一条 request 中多个要求混在一起，无法拆分 `trace_text` 或部门。
+- current / history 边界不清，无法确认该 trace 动作来自 current。
+- 主业务任务类型不清，导致 S07 依赖对象不清。
+- 附件、表格、PDF 或 OCR 读取失败，导致关键 trace 内容不可解析。
+
+如果父级 S01 / S02 / S06 本身是 `manual_review`，S07 可以作为 linked pending task candidate 保留，但执行必须等待父任务人工确认。
+
+S07 的 `manual_review` 采用项目默认结构，除非后续用户另行确认精简结构。
+
+建议结构：
+
+```json
+{
+  "manual_review": {
+    "reason_code": "",
+    "visible_reason": "",
+    "review_record_type": "trace_reservation_notes_manual_review",
+    "blocking_points": [],
+    "missing_fields": [],
+    "conflicting_points": [],
+    "suggested_human_actions": [],
+    "evidence_to_check": []
+  }
+}
+```
+
+典型 `reason_code`：
+
+- `trace_content_unreadable`
+- `trace_subtype_unclear`
+- `notify_department_unclear`
+- `target_object_unclear`
+- `parent_task_unclear`
+- `extra_bed_target_unclear`
+- `rate_code_price_unavailable`
+- `multiple_guest_requests_unclear`
+- `current_history_boundary_unclear`
+- `attachment_or_ocr_unreadable`
+
+注意：
+
+- `manual_review` 不能写成空泛的“人工看一下”。
+- 能确定的 `case_keys`、`trace_subtype`、`trace_text`、`notify_departments`、父任务信息应尽量保留。
+- 不能可靠确认的字段不要猜，填 `null`、空字符串或空数组。
+
+## 12. Tool Invocation Placeholder
+
+当前创建任务卡 / 可见记录的具体 Tool / API 尚未实现，本节只预留对接位置和语义契约，不定义最终 endpoint、鉴权方式或完整返回结构。
+
+- tool_status: `TBD`
+- suggested_tool_name: `create_task_card` / `TBD`
+- tool_purpose: 根据信息系统统一任务卡创建接口，创建 Trace / Reservation Notes 任务卡或人工复核 / 人工处理任务卡。
+- tool_owner: 信息系统。
+- caller: AI Runtime / Main Agent / Skill Orchestrator，最终由系统架构确认。
+- invocation_timing: Skill 输出 `ai_task_result` 并通过 Unified Output Contract 校验后。
+- payload_rule: Skill 能识别出的目标对象、`trace_subtype`、`trace_text`、部门同步规则、extra bed 操作意图、父任务关系、routing context 和后台证据照实填入；任务卡前端展示 `target_key`、`trace_subtype`、`trace_text`、`notify_departments`。
+- must_not_call_when:
+  - Skill 输出不符合统一契约
+  - current 事件完全不应进入 AI 工作台记录
+  - 输出内容缺少任务卡 / 可见记录创建所需的最低溯源字段
+- minimum_payload_should_include:
+  - `source_message_id`
+  - `source_event_index`
+  - `catalog_code`
+  - `skill_id`
+  - `result_type`
+  - `task_type`
+  - `case_keys`
+  - `visible_reason`
+  - `relevant_message_excerpt`
+  - `attachments`
+  - `context_used`
+  - `extracted_fields`
+  - `manual_review`
+  - `idempotency_key` / `TBD`
+- expected_tool_result: `TBD`
+
+Tool 设计原则：
+
+- S07 只调用一个统一任务卡创建 Tool：`create_task_card`。
+- 真实 Trace 写入、入住人数修改、房价修改是用户确认后的信息系统后续执行动作，不是本 Skill 直接执行动作。
+- 如果 S07 是 linked task，信息系统必须等父任务完成并确认目标对象后再执行。
+- AI 不直接写数据库，只调用信息系统暴露的受控 Tool / API。
+- 信息系统负责真实任务卡 ID、人工复核任务卡 ID、幂等、并发、状态机、最终落库和执行前硬校验。
+- 如果 Tool 尚不可用，本 Skill 仍应输出合格的 `ai_task_result`；不得编造 Tool 调用结果。
+
+## 13. Conflict Or Fallback Rule
+
+- 如果 current 邮件同时包含 S07 和可拆分的其他业务动作，应拆成多个 `source_event_index` 分别走对应 Skill。
+- 如果 S07 与 S01 / S02 / S06 在同一不可拆分事件或同一表格行里，应生成主业务任务和 S07 linked task。
+- 如果 S07 与 S03 Cancel Booking 在同一不可拆分事件里，不默认生成 linked S07；除非 current 明确存在取消后的独立 trace 写入动作。
+- 如果当前事件只有普通 New / Update / Cancel / Voucher / Rooming List / Amend Group Code，没有 Trace / Guest Request / extra bed，不走 S07。
+- 如果当前 / history 边界不清且无法确认 trace 动作来自 current，交由 `exception_detection_skill` 或 structured `manual_review`。
+- 如果无法判断是消息通知还是可执行 trace 任务，交由 S99 structured `manual_review`，不得硬走 S07。
+
+## 14. Must Not
+
+- 不从 `body_thread` 生成 `normal_task`。
+- 不把 fixed column、fixed row、fixed sheet 当成业务识别规则。
+- 不把 extra bed 计入 `room_quantity`。
+- 不把 `U-เตียงเสริม` 当作 PMS room type。
+- 不用 extra bed 判断 FIT / Group。
+- 不用 extra bed 判断 Rate Code。
+- 不由 S07 处理 Fix Charge。
+- 不由 S07 决定 Rate Code。
+- 不由 S07 猜 `rate_code_price`。
+- 不由 S07 自行计算最终房价。
+- 不直接修改入住人数。
+- 不直接修改房价。
+- 不把主业务任务和 S07 linked task 合并成一个 `ai_task_result`。
+- 不在 S01 / S02 / S06 同行 extra bed 场景下只吞进主任务而不生成 S07 task。
+- 不在 Cancel Booking 场景下默认派生 S07。
+- 不输出 `informational_message`。
+- 不输出 `no_action`。
+- 不输出 `exception_task`。
+- 不直接调用 Trace / Reservation Notes 写入 API。
+- 不直接写 Opera。
+- 不直接写数据库。
+- 不编造 Tool endpoint、鉴权、返回结构或调用结果。
+- 不把 `manual_review` 输出成空泛的“人工看一下”。
diff --git a/docs/import/20260706/0630AI_副本 2/skill/S08_ta_recorder_skill.md b/docs/import/20260706/0630AI_副本 2/skill/S08_ta_recorder_skill.md
new file mode 100644
index 0000000..69037a5
--- /dev/null
+++ b/docs/import/20260706/0630AI_副本 2/skill/S08_ta_recorder_skill.md	
@@ -0,0 +1,440 @@
+# S08 TA Recorder Skill
+
+## 1. Skill Identity
+
+- catalog_code: `S08`
+- skill_id: `ta_recorder_skill`
+- skill_name: `TA Recorder Skill`
+- task_type: `TA Recorder`
+
+Supported action:
+
+- `maintain_ta_recorder`
+
+## 2. Purpose
+
+本 Skill 用于在 Rooming List / Name List 成功识别后，为对应目标对象生成 TA Recorder 任务卡候选。
+
+第一版核心口径：
+
+- S08 主要不是普通邮件触发 Skill，而是 S05 Rooming List / Name List 的后置 linked task。
+- 一个目标 `group_code` 派生一张 TA Recorder 任务卡。
+- 同一个 Rooming List / Name List workbook、文件链接或 `file_reference` 可以被多张 S08 任务卡共享。
+- Sheet 只作为绑定证据，不直接决定 `group_code`。
+- 如果 current 邮件明确要求维护 TA Recorder，且能识别唯一目标 `group_code` 和名单 / 分房文件引用，可以直接输出 S08。
+
+本 Skill 不直接写数据库，不直接写 Opera，不直接写 TA Recorder，不导入名单，不创建 PM room，不维护 Routing Instruction，不维护 Note，不更新 Block Status。
+
+如果本 Skill 输出 `ai_task_result` 且通过统一输出校验，AI Runtime / Main Agent / Skill Orchestrator 后续可调用信息系统提供的统一受控 Tool / API 创建 TA Recorder 任务卡或人工复核 / 人工处理任务卡。真实 TaskCard ID、状态机、幂等、并发、执行前硬校验和最终写入均由信息系统负责。
+
+## 3. Scope
+
+本 Skill 覆盖两类 current 业务场景：
+
+1. S05 Rooming List / Name List `normal_task` 后派生 TA Recorder linked task。
+2. current 邮件明确要求维护 TA Recorder，并提供可绑定的目标 `group_code` 和名单 / 分房文件引用。
+
+S08 的任务卡前端展示字段应保持简单：
+
+- `group_code`
+- `attachment`
+- `ta_recorder_status`
+
+其中：
+
+- `group_code` 默认取 S05 识别出的目标 Group Code，允许用户在信息系统中人工修改。
+- `attachment` 默认绑定对应 Rooming List / Name List 文件。
+- `ta_recorder_status` 默认 `未维护`，后续可由信息系统更新为 `已维护`。
+
+## 4. When To Use
+
+当满足以下任一条件时，Main Agent 可以调用本 Skill：
+
+- S05 已确认 current 邮件提交 Rooming List / Name List，并已拆分出一个或多个唯一目标 `group_code`。
+- S05 的一个目标对象需要派生 TA Recorder linked task。
+- current 邮件明确写 `TA Recorder`、`TA RECORDER`、`maintain TA Recorder`、`update TA Recorder`，且同时有唯一目标 `group_code` 和名单 / 分房文件引用。
+
+优先触发方式：
+
+- 由 S05 派生。
+- S05 每确认一个目标 `group_code`，派生一张 S08。
+- S08 使用 S05 的附件 / 文件 / sheet 绑定结果，不自行重新判断文件是不是名单。
+
+少数直接触发方式：
+
+- current 邮件明确要求维护 TA Recorder。
+- 目标 `group_code` 唯一。
+- 有可绑定的名单 / 分房附件、Google Drive / 网盘链接、系统已下载 `file_reference`、workbook 或 sheet / range evidence。
+
+## 5. Must Not Use When
+
+不得在以下情况下使用本 Skill 生成 S08 `normal_task`：
+
+- 只是普通 Rooming List / Name List 邮件，但 S05 尚未确认目标对象绑定。
+- S05 输出 `manual_review`，文件类型、目标对象或附件归属仍不清。
+- 只是出现 `TA`、travel agent、旅行社、agent 名称或 Source / Reservation Type 中的 `TA`，但没有 TA Recorder 维护动作。
+- 只有 workbook / sheet 名，无法确认它绑定哪个目标 `group_code`。
+- 只有 Google Drive / 网盘链接，但文件不可下载、无权限或未确认是名单 / 分房文件。
+- current 邮件只是 thank you、FYI、acknowledgement、noted、received、confirmed receipt、转发说明、仅同步信息或无新业务动作。
+- TA Recorder 动作只出现在 `body_thread`，不在 `body_current` 或 S05 confirmed linked context。
+
+S08 不得把以下内容当作 `group_code`：
+
+- `IN9-17` 这类入住日期 / sheet 名。
+- `总名单`、summary、all guests 等汇总 sheet。
+- `WpsReserved_CellImgList` 等系统保留 sheet。
+- 任何仅从 sheet 名、文件名或附件名猜出的不可靠 code。
+
+## 6. Allowed Result Types
+
+第一版只允许：
+
+- `normal_task`
+- `manual_review`
+
+第一版不输出：
+
+- `exception_task`
+- `no_action`
+- `informational_message`
+
+## 7. Key Context Needed
+
+Main Agent 应尽量提供以下上下文：
+
+- `source_message_id`
+- `source_event_index`
+- `body_current` 中 TA Recorder 或 Rooming List / Name List 相关原文片段
+- S05 parent task context
+- `source_rooming_list_task_id`，如有
+- `parent_source_event_index`
+- `linked_task_group_id`
+- 目标 `group_code`
+- 目标对象绑定证据
+- Rooming List / Name List 文件引用
+- 附件、Google Drive / 网盘链接、系统已下载 `file_reference`
+- workbook 名、sheet 名、sheet / range 绑定证据
+- shared evidence sheets，例如 `总名单`
+- ignored system sheets，例如 `WpsReserved_CellImgList`
+- file read / download / permission status
+- routing context
+
+`body_thread` 只能作为 evidence context，不得单独触发 S08。
+
+## 8. Input Requirements Summary
+
+本 Skill 输入应包含：
+
+- S05 派生上下文，或 current 邮件中的 TA Recorder 维护请求摘要。
+- 唯一目标 `group_code`。
+- 名单 / 分房附件或文件引用。
+- 文件与目标对象的绑定证据。
+- 如果来自 workbook，提供对应 sheet / range evidence。
+- 如果同一 workbook 对应多个目标，提供 S05 已拆分后的目标对象列表和当前 S08 目标。
+- routing context，如有。
+
+本 Skill 不要求 Main Agent 在输入阶段固定完整 `extracted_fields` schema。
+
+### 8.1 Bundled / Shared References
+
+当 S08 来自 S05 派生时，Main Agent 应优先使用 S05 已完成的文件类型判断、目标对象绑定和拆分结果。
+
+如需回看 QBD / LianTai Excel / table workflow 证据，可读取：
+
+- `../references/qbd_liantai_email_table_rules.md`
+
+使用该 reference 的目的：
+
+- 区分名单文件和 booking update 表。
+- 识别 current / history。
+- 保留 workbook / sheet / row evidence。
+- 避免把 sheet 名、文件名或历史 code 误判为当前 `group_code`。
+
+S08 不读取房型映射、Rate Code 或价格 reference。
+
+## 9. Decision Rules
+
+### 9.1 S05 Linked Task Rule
+
+S08 默认由 S05 派生。
+
+如果 S05 输出 `normal_task`，且已确认一个或多个目标 `group_code`，则每个目标 `group_code` 应派生一张 S08 TA Recorder linked task。
+
+S08 linked task 必须保留父任务关系：
+
+- `source_rooming_list_task_id`
+- `parent_source_event_index`
+- `linked_task_group_id`
+- `depends_on_task_type: Rooming List`
+- `blocked_until_parent_completed: true`
+- `execution_order`
+
+执行顺序：
+
+- 先处理 S05 Rooming List / Name List。
+- 再处理 S08 TA Recorder。
+
+### 9.2 Target Split Rule
+
+S08 不是：
+
+- 一封邮件一张卡。
+- 一个 workbook 一张卡。
+- 一个 sheet 一张卡。
+
+S08 是：
+
+- 一个目标 `group_code` 一张卡。
+
+如果一个 workbook 包含多个目标，例如：
+
+- `HD260510A-1`
+- `HD260510A-2`
+- `HD260510A-3`
+- `HD260510A-4`
+
+则应生成 4 张 S08 linked task。每张只绑定一个 `group_code`，但可以共享同一个 workbook / file_reference。
+
+不得用数组型 `case_keys.group_code` 把多个 TA Recorder 合并为一张任务卡。
+
+### 9.3 Sheet Rule
+
+S08 必须跟随 S05 的目标对象绑定结果，不得自己从 sheet 名猜 `group_code`。
+
+规则：
+
+- `HD260510A-1`、`HD260510A-2` 等 sheet 名可以作为绑定证据。
+- `IN9-17` 这类 sheet 名不是 `group_code`，不能生成 `group_code = IN9-17`。
+- `总名单` 默认是 shared evidence，不单独生成 S08。
+- `WpsReserved_CellImgList` 等系统保留 sheet 不生成 S08。
+- 如果 sheet 名与正文 group code / S05 target binding 冲突，输出 `manual_review` 或等待 S05 先人工确认。
+
+### 9.4 Attachment / File Source Rule
+
+S08 的附件来源不限于邮件普通附件。
+
+可接受来源：
+
+- email attachment
+- inline file
+- Google Drive / 网盘链接
+- 系统下载后的 `file_reference`
+- workbook
+- workbook 中对应 sheet / range 的绑定证据
+
+S08 必须绑定名单 / 分房文件引用。没有文件引用时，不得输出 `normal_task`。
+
+### 9.5 Direct Current TA Recorder Rule
+
+如果 current 邮件直接要求维护 TA Recorder，可以直接输出 S08，但必须同时满足：
+
+- TA Recorder 维护动作来自 `body_current`。
+- 目标 `group_code` 唯一。
+- 有名单 / 分房附件或文件引用。
+- 文件与目标对象绑定清楚。
+
+如果只是出现 `TA` 字样、travel agent、Source TA、Reservation Type TA，不得触发 S08。
+
+### 9.6 S05 Manual Review / Locked Downstream Rule
+
+如果 S05 本身是 `manual_review`，S08 不应直接输出可执行 `normal_task`。
+
+可处理方式：
+
+- 作为 `locked_downstream_actions` / `derived_task_candidates` 保留在 S05 payload。
+- 或输出 S08 `manual_review`，说明父任务未确认、目标对象或附件绑定不清。
+
+只有 S05 人工确认文件类型、目标对象和附件绑定后，S08 才能进入可执行状态。
+
+## 10. Normal Task Output
+
+仅当可以安全创建 TA Recorder 任务卡候选时，输出：
+
+```json
+{
+  "result_type": "normal_task",
+  "task_type": "TA Recorder",
+  "current_or_history": "current"
+}
+```
+
+必须同时满足：
+
+- 来自 S05 confirmed linked context，或 current 邮件明确要求 TA Recorder。
+- 目标 `group_code` 唯一。
+- 名单 / 分房附件或文件引用明确。
+- 文件与目标 `group_code` 的绑定关系清楚。
+- 如果一个 workbook 对应多个 group，已经按 S05 target binding 拆成多个 S08。
+- 如果是 linked task，父任务和执行顺序清楚。
+
+完整输出必须符合统一输出契约。关键要求：
+
+- `source_message_id` 必须原样带回。
+- `source_event_index` 必须原样带回。
+- `case_keys.group_code` 必须只填当前 S08 任务绑定的一个 `group_code`。
+- `visible_reason` 应说明为什么这是 TA Recorder 任务。
+- `relevant_message_excerpt` 来自 S05 linked context 或 `body_current`。
+- `attachments` / `file_references` 应保留名单 / 分房文件引用。
+- `context_used` 应记录 S05 派生上下文、routing context 和使用的 reference。
+- `extracted_fields.group_code` 必须填入。
+- `extracted_fields.attachment` 或 `file_reference` 必须填入。
+- `extracted_fields.ta_recorder_status` 默认 `未维护`。
+
+任务卡前端展示字段建议：
+
+```json
+{
+  "group_code": "",
+  "attachment": "",
+  "ta_recorder_status": "未维护"
+}
+```
+
+后台 payload 可保留：
+
+- `source_rooming_list_task_id`
+- `parent_source_event_index`
+- `linked_task_group_id`
+- `depends_on_task_type`
+- `blocked_until_parent_completed`
+- `execution_order`
+- `file_reference`
+- `workbook_name`
+- `sheet_name`
+- `sheet_names`
+- `shared_evidence_sheets`
+- `ignored_system_sheets`
+- `attachment_binding`
+- `target_key_source`
+
+## 11. Manual Review Output
+
+当 current 邮件或 S05 派生上下文疑似需要 TA Recorder，但不能安全创建 `normal_task` 时，输出：
+
+```json
+{
+  "result_type": "manual_review",
+  "task_type": "TA Recorder",
+  "current_or_history": "current"
+}
+```
+
+典型 `manual_review` 条件：
+
+- S05 确认是名单，但无法识别唯一目标 `group_code`。
+- 一个附件 / workbook 可能对应多个 group，但 S05 未能拆分绑定。
+- 只有 sheet 名候选，不能确认 `group_code`。
+- 文件不可读、无权限、下载失败，导致无法确认附件。
+- current 邮件明确提 TA Recorder，但没有名单 / 分房附件或文件引用。
+- current 邮件明确提 TA Recorder，但目标对象不清。
+- S05 本身是 `manual_review`，S08 需要等待 S05 人工确认。
+- sheet 名、正文 group code、S05 target binding 或 routing context 互相冲突。
+
+S08 的 `manual_review` 采用项目默认结构，除非后续用户另行确认精简结构。
+
+建议结构：
+
+```json
+{
+  "manual_review": {
+    "reason_code": "",
+    "visible_reason": "",
+    "review_record_type": "ta_recorder_manual_review",
+    "blocking_points": [],
+    "missing_fields": [],
+    "conflicting_points": [],
+    "suggested_human_actions": [],
+    "evidence_to_check": []
+  }
+}
+```
+
+典型 `reason_code`：
+
+- `target_group_code_unclear`
+- `attachment_binding_unclear`
+- `multiple_group_binding_unclear`
+- `sheet_name_not_group_code`
+- `file_unreadable_or_no_permission`
+- `parent_rooming_list_not_confirmed`
+- `direct_ta_recorder_context_insufficient`
+
+注意：
+
+- `manual_review` 不能写成空泛的“人工看一下”。
+- 能确定的 `group_code` 候选、附件引用、sheet 名、workbook 名、S05 父任务信息应尽量保留。
+- 不能可靠确认的字段不要猜，填 `null`、空字符串或空数组。
+
+## 12. Tool Invocation Placeholder
+
+当前创建任务卡 / 可见记录的具体 Tool / API 尚未实现，本节只预留对接位置和语义契约，不定义最终 endpoint、鉴权方式或完整返回结构。
+
+- tool_status: `TBD`
+- suggested_tool_name: `create_task_card` / `TBD`
+- tool_purpose: 根据信息系统统一任务卡创建接口，创建 TA Recorder 任务卡或人工复核 / 人工处理任务卡。
+- tool_owner: 信息系统。
+- caller: AI Runtime / Main Agent / Skill Orchestrator，最终由系统架构确认。
+- invocation_timing: Skill 输出 `ai_task_result` 并通过 Unified Output Contract 校验后。
+- payload_rule: Skill 能识别出的 `group_code`、附件 / 文件引用、父任务关系和后台证据照实填入；任务卡前端展示 `group_code`、`attachment`、`ta_recorder_status`。
+- must_not_call_when:
+  - Skill 输出不符合统一契约
+  - current 事件完全不应进入 AI 工作台记录
+  - 输出内容缺少任务卡 / 可见记录创建所需的最低溯源字段
+- minimum_payload_should_include:
+  - `source_message_id`
+  - `source_event_index`
+  - `catalog_code`
+  - `skill_id`
+  - `result_type`
+  - `task_type`
+  - `case_keys`
+  - `visible_reason`
+  - `relevant_message_excerpt`
+  - `attachments` / `file_references`
+  - `context_used`
+  - `extracted_fields`
+  - `manual_review`
+  - `idempotency_key` / `TBD`
+- expected_tool_result: `TBD`
+
+Tool 设计原则：
+
+- S08 只调用一个统一任务卡创建 Tool：`create_task_card`。
+- 真实 TA Recorder 写入是用户确认后的信息系统后续执行动作，不是本 Skill 直接执行动作。
+- 如果 S08 是 S05 linked task，信息系统必须等 S05 完成并确认目标对象后再执行。
+- AI 不直接写数据库，只调用信息系统暴露的受控 Tool / API。
+- 信息系统负责真实任务卡 ID、人工复核任务卡 ID、幂等、并发、状态机、最终落库和执行前硬校验。
+- 如果 Tool 尚不可用，本 Skill 仍应输出合格的 `ai_task_result`；不得编造 Tool 调用结果。
+
+## 13. Conflict Or Fallback Rule
+
+- 如果 S05 已按多个目标 `group_code` 拆分，S08 必须按相同目标拆成多张 linked task。
+- 如果一个 workbook / file_reference 被多个目标共享，S08 可以共享附件引用，但每个 `ai_task_result` 只能绑定一个 `group_code`。
+- 如果 sheet 名像 group code 但 S05 未确认目标绑定，不得硬走 S08 `normal_task`。
+- 如果 current 邮件同时包含 Rooming List 和直接 TA Recorder 维护要求，应优先让 S05 确认名单与目标对象，再派生 S08。
+- 如果当前 / history 边界不清且无法确认 TA Recorder 动作来自 current 或 S05 linked context，交由 `exception_detection_skill` 或 structured `manual_review`。
+- 如果无法判断是消息通知还是可执行 TA Recorder 维护任务，交由 S99 structured `manual_review`，不得硬走 S08。
+
+## 14. Must Not
+
+- 不从 `body_thread` 生成 `normal_task`。
+- 不因出现 `TA` 字符串触发 S08。
+- 不因出现 travel agent / 旅行社名称触发 S08。
+- 不把 Source / Reservation Type 的 `TA` 当作 TA Recorder。
+- 不直接判断文件是不是 Rooming List；该判断归 S05。
+- 不直接导入名单到 Opera。
+- 不直接创建 PM room。
+- 不直接维护 Routing Instruction。
+- 不直接写 TA Recorder。
+- 不直接写 Note。
+- 不直接更新 Block Status。
+- 不猜 Rate Code。
+- 不猜 Breakfast location。
+- 不从 sheet 名猜 `group_code`。
+- 不把 `IN9-17`、`总名单`、`WpsReserved_CellImgList` 生成 TA Recorder 任务。
+- 不把多个 `group_code` 合并进一张 TA Recorder 任务卡。
+- 不输出 `informational_message`。
+- 不输出 `no_action`。
+- 不输出 `exception_task`。
+- 不编造 Tool endpoint、鉴权、返回结构或调用结果。
+- 不把 `manual_review` 输出成空泛的“人工看一下”。
diff --git a/docs/import/20260706/AI输出参数并集字典.xlsx b/docs/import/20260706/AI输出参数并集字典.xlsx
new file mode 100644
index 0000000..502f94e
Binary files /dev/null and b/docs/import/20260706/AI输出参数并集字典.xlsx differ
diff --git a/docs/import/20260706/任务卡前端展示字段表_副本.xlsx b/docs/import/20260706/任务卡前端展示字段表_副本.xlsx
new file mode 100644
index 0000000..67470fc
Binary files /dev/null and b/docs/import/20260706/任务卡前端展示字段表_副本.xlsx differ
diff --git a/docs/import/20260706/任务卡展示编辑矩阵.xlsx b/docs/import/20260706/任务卡展示编辑矩阵.xlsx
new file mode 100644
index 0000000..3d4f844
Binary files /dev/null and b/docs/import/20260706/任务卡展示编辑矩阵.xlsx differ
diff --git a/docs/import/20260706/开发AI先读_工作顺序.md b/docs/import/20260706/开发AI先读_工作顺序.md
new file mode 100644
index 0000000..ab250b9
--- /dev/null
+++ b/docs/import/20260706/开发AI先读_工作顺序.md
@@ -0,0 +1,536 @@
+# 开发 AI 先读：AI 过渡表落地工作顺序
+
+本文档给信息系统开发侧的 AI 使用。  
+请在写代码、建表、做前端任务卡之前先读完本文档。
+
+你的角色不是邮件处理 AI，也不是 Booking Skill。  
+你的角色是：**信息系统开发 AI**。
+
+你需要根据项目资料和 Excel 契约，帮助开发人员完成：
+
+- MySQL 过渡表设计；
+- AI 输出 JSON 入库；
+- 任务卡前端展示与编辑；
+- 用户确认后的 `confirmed_payload_json`；
+- Opera API 写入前参数组装；
+- Opera 写入结果底表落库。
+
+## 1. 你要先读哪些文件
+
+请按以下顺序读取，不要跳读。
+
+### 第 1 份：本文档
+
+先读：
+
+```text
+开发AI先读_工作顺序.md
+```
+
+目的：先知道你的工作边界和执行顺序。
+
+### 第 2 份：开发契约 README
+
+再读：
+
+```text
+AI过渡表开发契约_README.md
+```
+
+目的：理解两张 Excel 表怎么使用，哪些字段能改，哪些字段不能改，哪些字段不能写 Opera。
+
+### 第 3 份：Excel 契约
+
+再读：
+
+```text
+AI过渡表开发契约_两张样例表.xlsx
+```
+
+只需要读这两张 sheet：
+
+- `AI输出参数并集字典`
+- `任务卡展示编辑矩阵`
+
+不要把以下文件当成业务契约：
+
+```text
+AI过渡表开发契约_两张样例表.xlsx.inspect.ndjson
+```
+
+它只是生成 Excel 时的检查日志，不给开发使用。
+
+### 第 4 份：AI 项目资料
+
+项目资料在桌面文件夹：
+
+```text
+/Users/chillishark/Desktop/0630AI_副本
+```
+
+请按以下顺序读取：
+
+```text
+01_main_agent_prompt.md
+02_agent_workflow.md
+03_skill_catalog.md
+```
+
+然后再读各个 Skill：
+
+```text
+skill/S01_new_booking_skill.md
+skill/S02_update_booking_amendment_skill.md
+skill/S03_cancel_booking_skill.md
+skill/S04_voucher_received_skill.md
+skill/S05_rooming_list_name_list_skill.md
+skill/S06_amend_group_code_skill.md
+skill/S07_trace_reservation_notes_skill.md
+skill/S08_ta_recorder_skill.md
+```
+
+最后按需读取 reference：
+
+```text
+references/qbd_liantai_email_table_rules.md
+skill/S01_new_booking_skill/references/room_type_mapping_rules.md
+skill/S01_new_booking_skill/references/rate_code_rules.md
+skill/S02_update_booking_amendment_skill/references/room_type_mapping_rules.md
+skill/S02_update_booking_amendment_skill/references/rate_code_rules.md
+```
+
+## 2. 你必须先理解的整体链路
+
+系统链路是：
+
+```text
+邮件
+  -> Main Agent 拆分 current 事件
+  -> 调用对应 Skill
+  -> Skill 输出 ai_task_result JSON
+  -> 信息系统写入过渡表
+  -> 信息系统创建任务卡
+  -> 用户确认或修改任务卡参数
+  -> 信息系统生成 confirmed_payload_json
+  -> 信息系统调用 Opera API
+  -> Opera 写入结果落底表
+```
+
+AI 阶段只输出 JSON。  
+AI 不直接写 Opera。  
+AI 不直接写数据库。  
+AI 不直接创建真实任务卡。
+
+信息系统负责：
+
+- 保存 AI 原始 JSON；
+- 根据 AI 输出创建任务卡；
+- 接收用户确认或修改；
+- 生成最终确认参数；
+- 调用 Opera API；
+- 保存写入结果。
+
+## 3. 你的工作总顺序
+
+请按以下阶段工作。
+
+## 阶段一：理解 AI 输出结构
+
+先读：
+
+```text
+AI输出参数并集字典
+```
+
+你要搞清楚：
+
+- AI 总共可能输出哪些字段；
+- 每个字段的 `字段路径`；
+- 字段类型；
+- 是否数组；
+- 是否可为空；
+- 建议数据库落法；
+- 是否建议建索引；
+- 开发使用方式。
+
+这一阶段不要急着写前端。
+
+这一阶段的产出应该是：
+
+- 过渡表主表设计草案；
+- JSON 字段设计草案；
+- 常用冗余物理列设计草案；
+- 索引设计草案。
+
+## 阶段二：设计 MySQL 过渡表
+
+推荐使用：
+
+```text
+核心物理列 + 完整 JSON
+```
+
+核心物理列用于查询、筛选、幂等和状态机。
+
+完整 JSON 用于保留 AI 原始输出。
+
+建议至少保留：
+
+```text
+ai_payload_json
+case_keys_json
+extracted_fields_json
+manual_review_json
+informational_message_json
+attachments_json
+context_used_json
+confirmed_payload_json
+```
+
+建议物理列包括：
+
+```text
+source_message_id
+source_event_index
+catalog_code
+skill_id
+result_type
+task_type
+current_or_history
+group_code
+confirmation_number
+idempotency_key
+manual_reason_code
+parent_source_event_index
+linked_task_group_id
+blocked_until_parent_completed
+execution_order
+created_at
+updated_at
+```
+
+不要把所有嵌套字段都建成物理列。  
+只有高频查询、筛选、幂等、任务状态机需要的字段才冗余建列。
+
+## 阶段三：理解任务卡展示矩阵
+
+再读：
+
+```text
+任务卡展示编辑矩阵
+```
+
+任务卡选择逻辑是：
+
+```text
+result_type + task_type + task_subtype/业务动作
+```
+
+不要只看 `task_type`。
+
+比如：
+
+- `result_type = normal_task` + `task_type = New Booking`：普通 New Booking 任务卡；
+- `result_type = manual_review` + `task_type = New Booking`：New Booking 人工复核卡；
+- `result_type = informational_message` + `task_type = Message Notification`：信息提醒卡。
+
+## 阶段四：开发前端任务卡
+
+每个字段按矩阵行处理。
+
+规则如下：
+
+| 矩阵列 | 前端动作 |
+|---|---|
+| `是否展示 = 是` | 展示该字段 |
+| `是否可编辑 = 是` | 用户确认前允许修改 |
+| `是否为输入方式编辑 = 是` | 用文本输入框 |
+| `是否为下拉框方式编辑 = 是` | 用下拉框或多选下拉 |
+| `是否日期选择 = 是` | 用日期选择器 |
+| `是否数字输入 = 是` | 用数字输入框 |
+| `是否文件展示 = 是` | 用图片 / PDF / 附件预览 |
+| `是否表格编辑 = 是` | 用表格组件 |
+
+下拉框选项只能来自：
+
+```text
+下拉选项/枚举值
+```
+
+不要自行扩展枚举。
+
+## 阶段五：实现用户确认逻辑
+
+AI 原始输出必须保留，不得覆盖。
+
+建议保存：
+
+```text
+ai_payload_json
+confirmed_payload_json
+```
+
+含义：
+
+| 字段 | 含义 |
+|---|---|
+| `ai_payload_json` | AI 原始输出，只读保存 |
+| `confirmed_payload_json` | 用户确认或修改后的最终参数 |
+
+用户在任务卡里修改字段后，写入：
+
+```text
+confirmed_payload_json
+```
+
+后续 Opera API 参数必须从 `confirmed_payload_json` 读取。  
+不要直接从 `ai_payload_json` 读取 Opera 参数。
+
+## 阶段六：实现 Opera API 写入前判断
+
+只有满足以下条件，才允许进入 Opera API 写入：
+
+```text
+result_type = normal_task
+用户已确认任务卡
+字段矩阵中 是否参与Opera写入 = 是 / 条件参与
+后端硬校验通过
+```
+
+以下情况不得写 Opera：
+
+- `manual_review`
+- `informational_message`
+- 证据区字段；
+- 只读展示字段；
+- 标注“不确定 / 需确认”的字段；
+- S04 的 `voucher_display_fields`；
+- history-only evidence；
+- 没有经过用户确认的 AI 原始值。
+
+## 阶段七：实现底表
+
+Opera API 调用完成后，需要落底表。
+
+底表保存：
+
+- 调用的 Opera API 参数；
+- Opera API 返回结果；
+- 写入状态；
+- 错误信息；
+- 酒店业务需要查看的字段。
+
+例如 New Booking：
+
+| 对象 | 底表业务字段 |
+---|---|
+| Group Block | `block_id`、`block_name` |
+| FIT Reservation | `reservation_no` |
+| Allotment / Control Block | `block_id`、`block_name` 或后续业务确认字段 |
+
+底表是给酒店业务看结果的，不是 AI 原始输出表。
+
+## 4. result_type 处理规则
+
+第一版只使用：
+
+```text
+normal_task
+manual_review
+informational_message
+```
+
+不要使用：
+
+```text
+exception_task
+no_action
+```
+
+处理方式：
+
+| result_type | 处理方式 |
+|---|---|
+| `normal_task` | 创建普通任务卡，用户确认后可写 Opera |
+| `manual_review` | 创建人工复核卡，不写 Opera |
+| `informational_message` | 创建信息提醒卡，不写 Opera |
+
+## 5. task_type 覆盖范围
+
+当前需要支持：
+
+```text
+New Booking
+Update Booking
+Cancel Booking
+Voucher Received
+Rooming List
+Amend Group Code
+Trace / Reservation Notes
+TA Recorder
+Message Notification
+Fallback
+```
+
+S09 Note Skill 尚未正式落地。  
+不要把 S09 当成正式任务卡开发。
+
+## 6. normal_task 与 manual_review 的区别
+
+`normal_task` 是可确认、可执行的任务候选。
+
+`manual_review` 是结构化人工复核，不是失败，也不是空任务。
+
+即使 `manual_review` 中有已知字段，也不能自动转成 `normal_task`。
+
+人工复核卡需要展示：
+
+```text
+manual_review.reason_code
+manual_review.visible_reason
+manual_review.blocking_points[]
+manual_review.missing_fields[]
+manual_review.conflicting_points[]
+manual_review.evidence_to_check[]
+manual_review.suggested_human_actions[]
+```
+
+注意：
+
+- S04 `Voucher Received` 的 manual_review 是精简结构。
+- S05 `Rooming List` 的 manual_review 是精简结构。
+- 前端和后端都要兼容字段为空或不存在。
+
+## 7. linked task 处理规则
+
+S07 和 S08 可能是 linked task。
+
+典型场景：
+
+- S01 / S02 / S06 同一事件里有 extra bed，需要生成 S07 linked task；
+- S05 Rooming List 确认后，为每个目标 group_code 派生 S08 TA Recorder；
+- linked task 必须等待父任务完成后再执行。
+
+相关字段：
+
+```text
+parent_source_event_index
+linked_task_group_id
+depends_on_task_type
+depends_on_source_event_index
+blocked_until_parent_completed
+execution_order
+source_rooming_list_task_id
+```
+
+处理原则：
+
+- 主任务先执行；
+- linked task 后执行；
+- 父任务未完成时，linked task 不得写 Opera；
+- 不得把 S07 trace 吞进主任务而不生成独立 S07；
+- S08 是一个目标 `group_code` 一张卡，不是一个 workbook 一张卡。
+
+## 8. QBD / LianTai 表格处理规则
+
+QBD / LianTai 表格非常重要。
+
+请遵守：
+
+- 一行 current 有效高亮 / 黄色行 = 一个 `source_event_index`；
+- 一行 = 一个 `ai_task_result`；
+- 一行 = 一个任务卡候选；
+- 不同表格行不得合并；
+- 不得用数组型 `case_keys.group_code` 合并多个任务；
+- 每个行级结果都要保留 `extracted_fields.table_evidence`。
+
+受控例外：
+
+- 同一行同时有主业务动作和 Trace / Guest Request / extra bed 时，可以生成主任务 + S07 linked task。
+- 这不是合并任务，而是父子任务。
+
+## 9. 字段路径不能改
+
+Excel 中的 `字段路径` 就是 AI 输出 JSON 路径。
+
+开发 AI 不得：
+
+- 重命名字段；
+- 自行新增字段；
+- 改嵌套层级；
+- 把顶层字段挪进 `extracted_fields`；
+- 把 `extracted_fields` 字段挪成顶层字段。
+
+如果字段标注“不确定 / 需确认 / 建议命名”，只能做兼容设计，不能当成最终强 schema。
+
+## 10. 重点禁止事项
+
+开发 AI 不得：
+
+- 一上来直接写前端，不先理解数据库和 JSON 契约；
+- 只看 `task_type`，不看 `result_type`；
+- 把 `manual_review` 写 Opera；
+- 把 `informational_message` 写 Opera；
+- 覆盖 AI 原始输出；
+- 直接从 `ai_payload_json` 组 Opera API 参数；
+- 从 `body_thread` 生成 normal task；
+- 把多个 `group_code` 合并到一个任务；
+- 把 QBD / LianTai 多行合并；
+- 用 S04 `voucher_display_fields` 做房型、价格、房量、Rate Code 或自动更新；
+- 把 extra bed 计入 `room_quantity`；
+- 把 `U-เตียงเสริม` 当成 PMS 房型；
+- 自行扩展未定义枚举；
+- 编造 Opera API endpoint、鉴权或返回结构。
+
+## 11. 推荐第一轮产出
+
+读完本文档、README、Excel 和项目资料后，开发 AI 第一轮不要立刻写代码。
+
+建议先输出：
+
+1. 我理解的系统链路。
+2. 我理解的两张表职责。
+3. 我计划如何设计 MySQL 过渡表。
+4. 我计划如何保存 AI 原始 JSON 和 confirmed payload。
+5. 我计划如何渲染任务卡。
+6. 我计划如何处理 normal / manual / informational。
+7. 我识别到的不确定点。
+8. 我需要人工确认的问题清单。
+
+确认后，再进入具体开发。
+
+## 12. 推荐开发顺序
+
+确认理解无误后，按以下顺序开发：
+
+1. 建过渡表主表。
+2. 建必要索引和幂等约束。
+3. 实现 AI 输出 JSON 入库。
+4. 实现 `ai_task_results[]` 拆分，一条结果一条过渡表记录。
+5. 实现任务卡读取接口。
+6. 按任务卡矩阵实现前端动态展示。
+7. 实现用户确认和字段修改。
+8. 生成 `confirmed_payload_json`。
+9. 实现 Opera API 参数组装。
+10. 实现 Opera API 调用。
+11. 实现底表落库。
+12. 做 normal / manual / informational / linked task / QBD-LianTai 多行测试。
+
+## 13. 最终判断标准
+
+开发结果至少要满足：
+
+- AI 原始输出能完整保存；
+- 每条 `ai_task_result` 能独立落过渡表；
+- 任务卡能按矩阵展示；
+- 可编辑字段能按矩阵编辑；
+- 下拉字段枚举来自矩阵；
+- 用户确认后生成 `confirmed_payload_json`；
+- Opera API 只读取 confirmed 参数；
+- manual_review 不写 Opera；
+- informational_message 不写 Opera；
+- linked task 能等待父任务；
+- QBD / LianTai 多行不会被合并；
+- 不确定字段不会被开发 AI 私自定死。
+
+如果做不到以上标准，不应进入生产联调。
diff --git a/docs/import/20260706/查询接口后端开发契约_给开发_副本.md b/docs/import/20260706/查询接口后端开发契约_给开发_副本.md
new file mode 100644
index 0000000..b2116f7
--- /dev/null
+++ b/docs/import/20260706/查询接口后端开发契约_给开发_副本.md
@@ -0,0 +1,557 @@
+# 查询接口后端开发契约：给开发
+
+本文档给后端开发和开发 AI 使用，用于把 `Skill查询接口需求梳理_给开发.md` 落成可开发的只读查询接口。
+
+本契约只定义 **Skill script 可调用的只读查询接口**。  
+这些接口用于给 Skill 提供判断上下文，不负责创建任务卡、不写 Opera、不改业务数据库、不确认付款、不导入名单。
+
+字段级细节以 `查询接口返回字段字典.xlsx` 为准；本文档负责定义接口路径、请求方式、统一响应、错误码和各接口的 JSON 结构。
+
+## 1. 接口总原则
+
+### 1.1 只读边界
+
+所有接口必须是只读查询：
+
+- 不创建任务卡。
+- 不写 Opera。
+- 不更新预订。
+- 不确认 payment。
+- 不生成 receipt。
+- 不导入 rooming list。
+- 不维护 TA Recorder。
+- 不写 Trace / Reservation Notes。
+- 不把 `manual_review` 自动升级为 `normal_task`。
+
+接口只能返回事实、候选、状态和证据。  
+最终业务判断仍由 Skill 根据项目规则输出 `ai_task_result`。
+
+### 1.2 Current / History 边界
+
+业务动作必须来自 `body_current`。  
+`body_thread` 只能作为 target binding evidence。
+
+如果查询 key 来自历史邮件，调用方应传：
+
+```json
+{
+  "target_key_source": "body_thread_evidence",
+  "body_thread_used_only_as_evidence": true
+}
+```
+
+后端接口可以使用该 key 查询对象，但不得因为历史邮件里出现旧动作而创建或建议创建任务。
+
+### 1.3 统一路径建议
+
+第一版建议路径如下：
+
+| 逻辑接口名 | HTTP 方法 | 路径 |
+|---|---|---|
+| `query_case_context` | `POST` | `/api/ai-query/v1/case-context` |
+| `query_object_detail` | `POST` | `/api/ai-query/v1/object-detail` |
+| `query_file_parse_context` | `POST` | `/api/ai-query/v1/file-parse-context` |
+| `query_parent_task_context` | `POST` | `/api/ai-query/v1/parent-task-context` |
+
+使用 `POST` 是为了传复杂查询条件，不代表有写入动作。
+
+## 2. 通用请求头
+
+建议支持：
+
+| Header | 必填 | 说明 |
+|---|---|---|
+| `Content-Type: application/json` | 是 | JSON 请求 |
+| `X-Request-Id` | 是 | 调用方生成的请求 ID，用于排查 |
+| `X-Source-Message-Id` | 建议 | 邮件 ID，方便日志串联 |
+| `X-AI-Trace-Id` | 建议 | AI 运行链路 ID |
+
+鉴权方式由信息系统统一确定，本文不限定。
+
+## 3. 通用响应包
+
+所有接口统一返回：
+
+```json
+{
+  "success": true,
+  "request_id": "",
+  "trace_id": "",
+  "data": {},
+  "warnings": [],
+  "error": null
+}
+```
+
+失败时：
+
+```json
+{
+  "success": false,
+  "request_id": "",
+  "trace_id": "",
+  "data": null,
+  "warnings": [],
+  "error": {
+    "code": "",
+    "message": "",
+    "details": {}
+  }
+}
+```
+
+### 3.1 通用错误码
+
+| code | HTTP 状态 | 说明 |
+|---|---:|---|
+| `BAD_REQUEST` | 400 | 请求 JSON 格式错误或字段类型错误 |
+| `MISSING_REQUIRED_FIELD` | 400 | 缺少必填字段 |
+| `UNAUTHORIZED` | 401 | 未鉴权 |
+| `FORBIDDEN` | 403 | 无权限访问该数据 |
+| `NOT_FOUND` | 404 | 查询对象不存在；仅用于按明确 ID 查询的接口 |
+| `FILE_NOT_ACCESSIBLE` | 422 | 文件无权限、下载失败或不可访问 |
+| `PARSE_FAILED` | 422 | 文件解析失败 |
+| `UPSTREAM_TIMEOUT` | 504 | 上游系统超时 |
+| `INTERNAL_ERROR` | 500 | 未知后端错误 |
+
+注意：`query_case_context` 中查不到对象时，通常不应返回 404，而应返回 `success=true` 且 `matched_order_records=[]`。因为 Skill 还需要继续判断是否有 pending task、workflow 或终止记录。
+
+## 4. 接口一：query_case_context
+
+### 4.1 用途
+
+通过 `group_code`、`confirmation_number`、`reservation_no` 查询业务对象、待处理任务、工作流、终止记录和 key 关系。
+
+适用 Skill：
+
+```text
+S01/S02/S03/S04/S05/S06/S07/S08
+```
+
+### 4.2 Request
+
+```json
+{
+  "source_message_id": "MSG-001",
+  "source_event_index": 1,
+  "group_code": "LT260417VIPA",
+  "confirmation_number": null,
+  "reservation_no": null,
+  "object_type_hint": "group_block",
+  "target_key_source": "body_current",
+  "body_thread_used_only_as_evidence": false
+}
+```
+
+字段要求：
+
+| 字段 | 必填 | 说明 |
+|---|---|---|
+| `source_message_id` | 是 | 当前邮件 ID |
+| `source_event_index` | 是 | 当前事件序号 |
+| `group_code` | 条件 | Group / Allotment 优先 key |
+| `confirmation_number` | 条件 | FIT 优先 key |
+| `reservation_no` | 否 | Opera reservation no，辅助查询 |
+| `object_type_hint` | 否 | `fit_reservation` / `group_block` / `allotment_control_block` / `booking_record` / `unknown` |
+| `target_key_source` | 建议 | `body_current` / `body_thread_evidence` / `upstream_task_context` / `system_context` |
+| `body_thread_used_only_as_evidence` | 建议 | key 来自历史证据时传 `true` |
+
+`group_code`、`confirmation_number`、`reservation_no` 至少应有一个非空。  
+如果三个 key 都为空，后端可返回 `MISSING_REQUIRED_FIELD`；调用方也可选择不调用该接口。
+
+### 4.3 Response data
+
+```json
+{
+  "matched_order_records": [
+    {
+      "object_id": "OBJ-001",
+      "object_type": "group_block",
+      "group_code": "LT260417VIPA",
+      "confirmation_number": null,
+      "reservation_no": null,
+      "block_id": "BLK-10001",
+      "block_name": "LT260417VIPA GROUP",
+      "guest_name": null,
+      "group_name": "LT260417VIPA GROUP",
+      "arrival_date": "2026-04-17",
+      "departure_date": "2026-04-20",
+      "room_items": [],
+      "rate_code": null,
+      "rate_code_price": null,
+      "reservation_type": null,
+      "status": "active",
+      "cancel_status": "not_cancelled",
+      "source_table": "opera_group_block_sync",
+      "last_updated_at": "2026-07-07T10:00:00+08:00"
+    }
+  ],
+  "pending_or_open_tasks": [],
+  "active_workflows": [],
+  "terminated_records": [],
+  "target_object_validation": {
+    "status": "single",
+    "matched_object_id": "OBJ-001",
+    "matched_object_type": "group_block",
+    "can_create_new_booking_task": false,
+    "can_create_update_task": true,
+    "can_create_cancel_task": true,
+    "can_attach_voucher": true,
+    "can_attach_rooming_list": true,
+    "needs_manual_review_reason": null
+  },
+  "key_relationships": {
+    "group_code_and_confirmation_same_object": null,
+    "relationship_evidence": ""
+  }
+}
+```
+
+### 4.4 后端处理规则
+
+- 查不到对象时返回空数组，不要直接报错。
+- 必须同时查：已写入对象、pending/open task、active workflow、terminated record。
+- 如果查到多个可能对象，`target_object_validation.status = "multiple"`。
+- 接口不要返回“应该 normal_task / manual_review”的结论，只返回事实和校验摘要。
+- 对 S01，若同 key 已有有效对象或 pending/open task，Skill 会倾向 `manual_review`。
+- 对 S04/S05，如果无已写入对象但有可承接的 pending New Booking / 上游任务，仍可作为目标候选返回。
+
+## 5. 接口二：query_object_detail
+
+### 5.1 用途
+
+按 `object_id` 查询更完整的对象快照，供 S02 建 before/after、S03 判断取消状态、S07 extra bed 取 `rate_code_price`、S04/S05/S08 做目标展示和硬校验。
+
+适用 Skill：
+
+```text
+S02/S03/S04/S05/S07/S08
+```
+
+### 5.2 Request
+
+```json
+{
+  "object_id": "OBJ-001",
+  "object_type": "group_block"
+}
+```
+
+字段要求：
+
+| 字段 | 必填 | 说明 |
+|---|---|---|
+| `object_id` | 是 | `query_case_context` 返回的对象 ID |
+| `object_type` | 建议 | 对象类型，可帮助后端选择查询表 |
+
+### 5.3 Response data
+
+```json
+{
+  "object_id": "OBJ-001",
+  "object_type": "group_block",
+  "group_code": "LT260417VIPA",
+  "confirmation_number": null,
+  "reservation_no": null,
+  "block_id": "BLK-10001",
+  "block_name": "LT260417VIPA GROUP",
+  "status": "active",
+  "arrival_date": "2026-04-17",
+  "departure_date": "2026-04-20",
+  "nights": 3,
+  "guest_count": null,
+  "room_items": [
+    {
+      "room_type": "TWN",
+      "pms_room_type_code": "RM2",
+      "room_quantity": 2,
+      "rate_code": "WHO2",
+      "rate_code_price": 2000
+    }
+  ],
+  "rate_code": "WHO2",
+  "rate_code_price": 2000,
+  "reservation_type": "TA",
+  "can_update": true,
+  "can_cancel": true,
+  "hard_validation_warnings": []
+}
+```
+
+### 5.4 后端处理规则
+
+- `object_id` 明确不存在时可返回 404 `NOT_FOUND`。
+- `rate_code_price` 如果后端当前拿不到，应返回 `null`，并在 `hard_validation_warnings` 说明原因。
+- S07 extra bed 不会自己计算最终房价；后端需提供能否取得 `rate_code_price` 的事实。
+- `room_items[]` 可先返回摘要，第一版不要求完整 Opera 明细字段。
+
+## 6. 接口三：query_file_parse_context
+
+### 6.1 用途
+
+查询附件、图片、PDF、OCR、Excel / workbook、QBD / LianTai 表格、voucher、rooming list 文件解析结果。
+
+适用 Skill：
+
+```text
+S01/S02/S03/S04/S05/S06/S07/S08
+```
+
+### 6.2 Request
+
+```json
+{
+  "source_message_id": "MSG-001",
+  "source_event_index": 1,
+  "file_reference": "file://attachment-001",
+  "parse_need": "voucher"
+}
+```
+
+`parse_need` 枚举建议：
+
+| 值 | 用途 |
+|---|---|
+| `voucher` | S04 voucher / payment slip |
+| `rooming_list` | S05 / S08 名单文件 |
+| `qbd_liantai_table` | S01/S02/S03/S06/S07 表格行证据 |
+| `ocr` | 图片/PDF OCR |
+| `generic` | 通用解析 |
+
+### 6.3 Response data
+
+```json
+{
+  "file_reference": "file://attachment-001",
+  "filename": "voucher.pdf",
+  "download_status": "ok",
+  "display_available": true,
+  "file_type": "pdf",
+  "ocr_text": "",
+  "workbook_summary": {},
+  "sheet_summaries": [],
+  "highlighted_rows": [],
+  "row_level_evidence": [],
+  "voucher_evidence": {
+    "voucher_subtype": "lian_tai_credit_voucher",
+    "lian_tai_code_candidate": "LT260417VIPA",
+    "code_field_read_status": "clear",
+    "bank_slip_detected": false
+  },
+  "list_file_evidence": {},
+  "parse_warnings": []
+}
+```
+
+QBD / LianTai 表格场景可返回：
+
+```json
+{
+  "row_level_evidence": [
+    {
+      "sheet_name": "BOOKING 06-2026",
+      "row_number": 12,
+      "row_label": "12",
+      "highlight_status": "yellow",
+      "action_status_cell_value": "NEW BOOKING",
+      "raw_date_range": "17/04/26-20/04/26",
+      "raw_room_type": "TWN",
+      "raw_room_quantity": "2",
+      "raw_rate": "2000THB+500",
+      "before_after_evidence": null,
+      "strikethrough_state": null,
+      "cell_reference": "H12",
+      "ocr_evidence": null
+    }
+  ]
+}
+```
+
+Rooming List 场景可返回：
+
+```json
+{
+  "list_file_evidence": {
+    "list_evidence_type": "rooming_list",
+    "file_type_validation": {
+      "is_guest_level_list": true,
+      "positive_headers": ["English Name", "Passport No", "Nationality"],
+      "negative_booking_table_evidence": []
+    },
+    "target_key_candidates": [
+      {
+        "key_type": "group_code",
+        "key_value": "HD260510A-1",
+        "source": "sheet_name"
+      }
+    ],
+    "shared_evidence_sheets": ["总名单"]
+  }
+}
+```
+
+### 6.4 后端处理规则
+
+- 文件不可访问时返回 `success=false`、`FILE_NOT_ACCESSIBLE`，或 `success=true` 且 `download_status=failed`；项目第一版建议后者，方便 Skill 输出 structured `manual_review`。
+- S04 不应从 bank slip OCR 的金额、memo、银行账号、付款人等字段自动生成 group_code。
+- S05 不能因为文件是 Excel 就判断为 rooming list，必须返回正向名单证据或负向 booking table 证据。
+- QBD / LianTai 多个高亮行应作为多个 `row_level_evidence[]` 返回，Skill 再按行拆分任务。
+- 接口只返回证据，不负责决定路由到 S01/S02/S03/S05。
+
+## 7. 接口四：query_parent_task_context
+
+### 7.1 用途
+
+查询 linked task 的父任务上下文。  
+主要用于：
+
+- S07 从 S01 / S02 / S06 派生 Trace / Extra Bed linked task。
+- S08 从 S05 Rooming List 派生 TA Recorder linked task。
+
+### 7.2 Request
+
+```json
+{
+  "source_message_id": "MSG-001",
+  "parent_source_event_index": 1,
+  "linked_task_group_id": "LTK-001",
+  "source_rooming_list_task_id": null
+}
+```
+
+字段要求：
+
+| 字段 | 必填 | 说明 |
+|---|---|---|
+| `source_message_id` | 建议 | 当前邮件 ID |
+| `parent_source_event_index` | 条件 | 父事件序号 |
+| `linked_task_group_id` | 条件 | 联动任务组 ID |
+| `source_rooming_list_task_id` | S08条件 | S05 Rooming List 父任务 ID |
+
+至少应提供 `parent_source_event_index`、`linked_task_group_id`、`source_rooming_list_task_id` 中一个。
+
+### 7.3 Response data
+
+```json
+{
+  "parent_task": {
+    "task_id": "TASK-001",
+    "task_type": "Rooming List",
+    "task_status": "confirmed",
+    "case_keys": {
+      "group_code": "HD260510A-1"
+    },
+    "source_event_index": 1
+  },
+  "linked_tasks": [],
+  "execution_order": [
+    {
+      "task_id": "TASK-001",
+      "execution_order": 1
+    },
+    {
+      "task_id": "TASK-002",
+      "execution_order": 2
+    }
+  ],
+  "parent_confirmed_payload": {
+    "target_object_id": "OBJ-001",
+    "file_reference": "file://rooming-list.xlsx"
+  },
+  "parent_status": "confirmed",
+  "attachment_binding": {
+    "file_reference": "file://rooming-list.xlsx",
+    "workbook_name": "HD260510A.xlsx",
+    "sheet_name": "HD260510A-1"
+  },
+  "file_reference": "file://rooming-list.xlsx",
+  "workbook_name": "HD260510A.xlsx",
+  "sheet_name": "HD260510A-1"
+}
+```
+
+### 7.4 后端处理规则
+
+- 这个接口不能创建 linked task，只能返回父任务和已存在 linked task 上下文。
+- S07 linked task 必须等父 S01/S02/S06 完成并确认目标对象后才能真正执行。
+- S08 linked task 必须跟随 S05 已确认的目标 `group_code`，不得从 sheet 名自行猜 `group_code`。
+- `parent_status` 未完成时，Skill 可输出 `blocked_until_parent_completed=true`。
+
+## 8. 推荐调用时序
+
+### 8.1 普通路由级查询
+
+```text
+Main Agent 从 body_current 提取 group_code / confirmation_number
+  -> POST /api/ai-query/v1/case-context
+  -> routing_context 传给 Skill
+  -> Skill 判断 normal_task / manual_review
+```
+
+### 8.2 current 无 key，但 history 有唯一目标 key
+
+```text
+body_current 有明确业务动作
+  -> body_thread 仅提取唯一 target key 作为 evidence
+  -> POST /api/ai-query/v1/case-context
+     target_key_source=body_thread_evidence
+     body_thread_used_only_as_evidence=true
+  -> Skill 输出中保留 target_key_source 和 hard validation 标记
+```
+
+### 8.3 文件类任务
+
+```text
+当前邮件有附件 / 图片 / PDF / Excel / link
+  -> POST /api/ai-query/v1/file-parse-context
+  -> 如解析出 key，再 POST /api/ai-query/v1/case-context
+  -> Skill 判断任务
+```
+
+### 8.4 linked task
+
+```text
+S01/S02/S06 主任务 + S07 linked task
+或 S05 Rooming List + S08 TA Recorder
+  -> POST /api/ai-query/v1/parent-task-context
+  -> 返回父任务状态、目标对象、附件绑定和执行顺序
+```
+
+## 9. 与两张字典表的关系
+
+### 9.1 与 `查询接口返回字段字典.xlsx`
+
+本文定义接口级契约。  
+字段名、字段路径、数据类型、是否数组、是否必传/必返，以 `查询接口返回字段字典.xlsx` 为准。
+
+### 9.2 与 `AI输出参数并集字典.xlsx`
+
+`AI输出参数并集字典.xlsx` 只定义 Skill 最终输出到过渡表的字段。  
+查询接口返回字段不要求全部进入 AI 输出 JSON。
+
+如果某个查询字段只用于 Skill 判断，可只进入 `context_used` 摘要，不必作为 AI 输出字段展开。
+
+当前建议重点关注这些查询字段：
+
+- `reservation_no`
+- `object_id`
+- `object_type`
+- `block_id`
+- `block_name`
+- `rate_code_price`
+
+这些字段虽属于查询上下文，但后续任务卡展示、Opera API 定位、底表展示和硬校验都会用到，开发应在接口层明确返回。
+
+## 10. 后端验收清单
+
+后端完成后，至少应满足：
+
+- 四个接口都可通过 POST JSON 调用。
+- 所有接口都使用统一响应包。
+- 查询不到对象时，`query_case_context` 返回空数组而不是直接报错。
+- 每次查询都能带上 `source_message_id`、`source_event_index` 或请求追踪信息。
+- 支持 target key 来自 `body_thread_evidence`，但不从 history 触发任务。
+- `query_case_context` 同时返回已写入对象、pending/open task、active workflow、terminated record。
+- `query_file_parse_context` 能区分 voucher、rooming list、QBD/LianTai table 证据。
+- `query_parent_task_context` 能返回父任务状态和执行顺序。
+- 所有接口不发生写入动作。
diff --git a/docs/project/frontend-backend/backend-to-frontend-notes.md b/docs/project/frontend-backend/backend-to-frontend-notes.md
index ee213c5..475aaa7 100644
--- a/docs/project/frontend-backend/backend-to-frontend-notes.md
+++ b/docs/project/frontend-backend/backend-to-frontend-notes.md
@@ -114,8 +114,8 @@ Content-Type: application/json
 
 启用方式：
 
-- 默认关闭，需要后端环境显式设置 `reservation.demo-data.enabled=true` 或环境变量 `RESERVATION_DEMO_DATA_ENABLED=true`。
-- 必须配置 `reservation.demo-data.access-key` 或环境变量 `RESERVATION_DEMO_DATA_ACCESS_KEY`。
+- dev profile 默认开启；test 默认关闭，需要后端环境显式设置 `reservation.demo-data.enabled=true` 或环境变量 `RESERVATION_TEST_DEMO_DATA_ENABLED=true`。
+- 必须配置 `reservation.demo-data.access-key`；dev 优先使用 `RESERVATION_DEV_DEMO_DATA_ACCESS_KEY`，test 优先使用 `RESERVATION_TEST_DEMO_DATA_ACCESS_KEY`，旧通用变量 `RESERVATION_DEMO_DATA_ACCESS_KEY` 仅作为兼容兜底。
 - 该接口只用于 dev/test 联调，不允许放进生产普通页面，也不要把访问口令写进前端仓库、浏览器环境变量或构建产物。
 
 返回内容：
diff --git a/docs/project/frontend-backend/frontend-to-backend-api-requests.md b/docs/project/frontend-backend/frontend-to-backend-api-requests.md
index fe1fe08..3871bc1 100644
--- a/docs/project/frontend-backend/frontend-to-backend-api-requests.md
+++ b/docs/project/frontend-backend/frontend-to-backend-api-requests.md
@@ -275,8 +275,8 @@ POST /api/system/reservation/demo-data
 
 | 配置 | 说明 |
 | --- | --- |
-| `reservation.demo-data.enabled=true` | 显式启用接口，也可用环境变量 `RESERVATION_DEMO_DATA_ENABLED=true`。 |
-| `reservation.demo-data.access-key` | 配置访问口令，也可用环境变量 `RESERVATION_DEMO_DATA_ACCESS_KEY`。 |
+| `reservation.demo-data.enabled=true` | dev 默认开启；test 需显式启用，也可用环境变量 `RESERVATION_TEST_DEMO_DATA_ENABLED=true`。 |
+| `reservation.demo-data.access-key` | 配置访问口令；dev 优先使用 `RESERVATION_DEV_DEMO_DATA_ACCESS_KEY`，test 优先使用 `RESERVATION_TEST_DEMO_DATA_ACCESS_KEY`，旧通用变量 `RESERVATION_DEMO_DATA_ACCESS_KEY` 仅作为兼容兜底。 |
 | `X-TH-Hotel-Demo-Data-Key` | 请求头必须携带，与后端配置口令一致。 |
 
 请求示例：
diff --git a/docs/project/go-live-notes.md b/docs/project/go-live-notes.md
index 2ce34bf..b64cf66 100644
--- a/docs/project/go-live-notes.md
+++ b/docs/project/go-live-notes.md
@@ -57,7 +57,10 @@
 
 | 变量 | 是否 Secret | 上线注意事项 |
 | --- | --- | --- |
-| `SOURCE_MESSAGE_ORIGINAL_READ_ACCESS_KEY` | 是 | 原文读取临时访问 key。未配置时原文读取默认关闭。 |
+| `SOURCE_MESSAGE_DEV_ORIGINAL_READ_ACCESS_KEY` | 是 | dev 原文读取临时访问 key。未配置时可兜底使用旧通用变量。 |
+| `SOURCE_MESSAGE_TEST_ORIGINAL_READ_ACCESS_KEY` | 是 | test 原文读取临时访问 key。未配置时可兜底使用旧通用变量。 |
+| `SOURCE_MESSAGE_PROD_ORIGINAL_READ_ACCESS_KEY` | 是 | prod 原文读取临时访问 key。未配置时原文读取默认关闭。 |
+| `SOURCE_MESSAGE_ORIGINAL_READ_ACCESS_KEY` | 是 | 旧通用原文读取 key，仅作为兼容兜底。 |
 
 注意：
 
@@ -87,7 +90,10 @@
 
 | 变量 | 是否 Secret | 上线注意事项 |
 | --- | --- | --- |
-| `SUPERAGENT_TASK_RESULT_HMAC_SECRET` | 是 | SuperAgent 查询接口 1、2 和任务结果通知接口共用的 HMAC secret。生产不能为空，只能通过 Secret 注入。 |
+| `SUPERAGENT_DEV_TASK_RESULT_HMAC_SECRET` | 是 | dev SuperAgent 查询接口 1、2 和任务结果通知接口共用的 HMAC secret。 |
+| `SUPERAGENT_TEST_TASK_RESULT_HMAC_SECRET` | 是 | test SuperAgent 查询接口 1、2 和任务结果通知接口共用的 HMAC secret。 |
+| `SUPERAGENT_PROD_TASK_RESULT_HMAC_SECRET` | 是 | prod SuperAgent 查询接口 1、2 和任务结果通知接口共用的 HMAC secret。生产不能为空，只能通过 Secret 注入。 |
+| `SUPERAGENT_TASK_RESULT_HMAC_SECRET` | 是 | 旧通用 HMAC 变量，仅作为兼容兜底；新环境优先配置环境专属变量。 |
 | `SUPERAGENT_TASK_RESULT_CLOCK_SKEW_SECONDS` | 否 | 请求时间允许偏移，默认 `300` 秒。上线前确认本系统、SuperAgent 和 AgentBus 所在机器时间已通过 NTP 同步。 |
 | `SUPERAGENT_TASK_RESULT_NONCE_TTL_SECONDS` | 否 | nonce 防重放窗口，默认 `600` 秒。 |
 | `SUPERAGENT_TASK_RESULT_MAX_BODY_BYTES` | 否 | SuperAgent 入站请求体最大字节数，默认 `1048576`。 |
@@ -283,6 +289,7 @@ GET /api/source-messages/{id}/original
 ```text
 AGENTBUS_PROBE_ENABLED=false
 AGENTBUS_CAPTURE_ENABLED=false
+SOURCE_MESSAGE_PROD_ORIGINAL_READ_ACCESS_KEY=
 SOURCE_MESSAGE_ORIGINAL_READ_ACCESS_KEY=
 ```
 
@@ -290,7 +297,7 @@ SOURCE_MESSAGE_ORIGINAL_READ_ACCESS_KEY=
 
 - 关闭 `AGENTBUS_PROBE_ENABLED` 可以停止 WebSocket 入站连接。
 - 关闭 `AGENTBUS_CAPTURE_ENABLED` 可以保留连接但暂停写入 Inbox。
-- 清空 `SOURCE_MESSAGE_ORIGINAL_READ_ACCESS_KEY` 可以关闭原文读取接口。
+- 清空当前 profile 对应的 `SOURCE_MESSAGE_*_ORIGINAL_READ_ACCESS_KEY`，且不配置旧通用变量，可以关闭原文读取接口。
 
 数据库回滚注意：
 
diff --git a/docs/project/integrations/superagent-agentbus-project-integration-guide.md b/docs/project/integrations/superagent-agentbus-project-integration-guide.md
index 554f12e..1437ddf 100644
--- a/docs/project/integrations/superagent-agentbus-project-integration-guide.md
+++ b/docs/project/integrations/superagent-agentbus-project-integration-guide.md
@@ -270,6 +270,7 @@ AGENTBUS_MAX_SAMPLES=100
 AGENTBUS_CAPTURE_ENABLED=true
 AGENTBUS_DEFAULT_HOTEL_ID=HOTEL-TEST
 AGENTBUS_REPLY_MODE=NONE
+SOURCE_MESSAGE_DEV_ORIGINAL_READ_ACCESS_KEY=
 SOURCE_MESSAGE_ORIGINAL_READ_ACCESS_KEY=
 ```
 
@@ -290,7 +291,10 @@ SOURCE_MESSAGE_ORIGINAL_READ_ACCESS_KEY=
 | `AGENTBUS_CAPTURE_ENABLED` | 否 | 是否写入 SourceMessage Inbox。 |
 | `AGENTBUS_DEFAULT_HOTEL_ID` | 否 | AgentBus 未提供租户上下文时的默认业务上下文。 |
 | `AGENTBUS_REPLY_MODE` | 否 | 调试回复模式。真实客户渠道应保持 `NONE`。 |
-| `SOURCE_MESSAGE_ORIGINAL_READ_ACCESS_KEY` | 是 | 原文读取接口的临时受控访问 key，后续可替换为正式权限体系。 |
+| `SOURCE_MESSAGE_DEV_ORIGINAL_READ_ACCESS_KEY` | 是 | dev 原文读取接口的临时受控访问 key，后续可替换为正式权限体系。 |
+| `SOURCE_MESSAGE_TEST_ORIGINAL_READ_ACCESS_KEY` | 是 | test 原文读取接口的临时受控访问 key。 |
+| `SOURCE_MESSAGE_PROD_ORIGINAL_READ_ACCESS_KEY` | 是 | prod 原文读取接口的临时受控访问 key，只能通过生产 Secret 注入。 |
+| `SOURCE_MESSAGE_ORIGINAL_READ_ACCESS_KEY` | 是 | 旧通用原文读取 key，仅作为兼容兜底。 |
 
 ### 5.2 WebSocket 连接
 
@@ -511,6 +515,9 @@ MessageEvent
 - `DEERFLOW_OPEN_API_KEY`
 - `SUPERAGENT_PROBE_ACCESS_KEY`
 - `AGENTBUS_WS_TOKEN`
+- `SOURCE_MESSAGE_DEV_ORIGINAL_READ_ACCESS_KEY`
+- `SOURCE_MESSAGE_TEST_ORIGINAL_READ_ACCESS_KEY`
+- `SOURCE_MESSAGE_PROD_ORIGINAL_READ_ACCESS_KEY`
 - `SOURCE_MESSAGE_ORIGINAL_READ_ACCESS_KEY`
 - `SOURCE_MESSAGE_REPLAY_ACCESS_KEY`
 - 数据库密码
diff --git a/docs/project/integrations/superagent-api-contract.md b/docs/project/integrations/superagent-api-contract.md
index 0221d9e..a44c7f8 100644
--- a/docs/project/integrations/superagent-api-contract.md
+++ b/docs/project/integrations/superagent-api-contract.md
@@ -10,6 +10,23 @@
 | 适用范围 | SuperAgent 调用本系统查询上下文、提交 AI 任务结果 |
 | 主要读者 | SuperAgent 对接方、后端、测试、运维 |
 
+## 联调参数区
+
+以下参数供 SuperAgent 联调时手动修改。该区块只用于 dev/test 联调，不作为生产 Secret 管理方式。
+
+| 参数 | 当前联调值 | 中文说明 |
+| --- | --- | --- |
+| `TH_HOTEL_API_BASE_URL` | `http://8.138.234.141:18087` | 本系统后端基础地址；本地联调用 8080，部署环境改为实际网关或服务地址。 |
+| `HOTEL_ID` | `HOTEL-DEV` | 当前 dev profile 下 AgentBus 入库默认酒店 ID；调用三个 SuperAgent 接口时均应传入请求体 `hotel_id`。 |
+| `SUPERAGENT_CLIENT_ID` | `superagent-debug` | SuperAgent 调用方 ID，对应 Header `X-TH-Hotel-SuperAgent-Client-Id`。 |
+| `SUPERAGENT_HMAC_SECRET` | `th-hotel-superagent-debug-20260709-change-before-prod` | dev/test 联调临时 HMAC 密钥；生产上线前必须更换为新的高强度随机密钥。 |
+
+生产注意：
+
+- 生产环境必须更换 `SUPERAGENT_HMAC_SECRET`，不得继续使用上述联调临时密钥。
+- 生产密钥不得写入 SuperAgent skill 文件、仓库文档、前端代码、镜像或普通日志，只能通过部署 Secret / 环境变量注入。
+- 本系统后端按 profile 优先读取环境专属密钥：dev 使用 `SUPERAGENT_DEV_TASK_RESULT_HMAC_SECRET`，test 使用 `SUPERAGENT_TEST_TASK_RESULT_HMAC_SECRET`，prod 使用 `SUPERAGENT_PROD_TASK_RESULT_HMAC_SECRET`；旧通用变量 `SUPERAGENT_TASK_RESULT_HMAC_SECRET` 仅作为兼容兜底。当前查询接口和任务结果通知接口共用同一个 HMAC secret。
+
 ## 1. 基础约定
 
 请求地址先使用占位符：
@@ -52,7 +69,7 @@ POST
 签名算法：
 
 ```text
-signature = HMAC_SHA256(SUPERAGENT_TASK_RESULT_HMAC_SECRET, canonical_string)
+signature = HMAC_SHA256(SUPERAGENT_HMAC_SECRET, canonical_string)
 ```
 
 Header 写法：
@@ -102,7 +119,7 @@ SuperAgent 不应知道或依赖内部 SourceMessage Inbox ID。任务结果通
 
 ```json
 {
-  "hotel_id": "HOTEL-TEST",
+  "hotel_id": "<HOTEL_ID>",
   "group_code": "GRP-001",
   "confirmation_number": null,
   "reservation_no": null,
@@ -186,7 +203,7 @@ SuperAgent 不应知道或依赖内部 SourceMessage Inbox ID。任务结果通
 
 ```json
 {
-  "hotel_id": "HOTEL-TEST",
+  "hotel_id": "<HOTEL_ID>",
   "object_id": "ORDER:1900000000000000100",
   "object_type": "group_block"
 }
@@ -264,7 +281,7 @@ SuperAgent 不应知道或依赖内部 SourceMessage Inbox ID。任务结果通
 
 ```json
 {
-  "hotel_id": "HOTEL-TEST",
+  "hotel_id": "<HOTEL_ID>",
   "source_message_id": "mail-20260708-0001",
   "ai_task_results": [
     {
@@ -328,13 +345,14 @@ SuperAgent 不应知道或依赖内部 SourceMessage Inbox ID。任务结果通
     {
       "source_event_index": 1,
       "array_index": 1,
+      "ai_transition_id": "1900000000000000250",
       "order_id": "1900000000000000300",
       "task_id": "1900000000000000400",
-      "task_status": "PENDING_CONFIRM",
-      "order_status": "TEMPORARY",
       "system_task_type": "NEW_BOOKING",
       "task_card_type": "NEW_BOOKING",
-      "warnings": []
+      "task_status": "PENDING_CONFIRM",
+      "order_status": "TEMPORARY",
+      "execution_order": 1
     }
   ],
   "warnings": []
@@ -385,7 +403,7 @@ SuperAgent 不应知道或依赖内部 SourceMessage Inbox ID。任务结果通
 | `REQUEST_BODY_INVALID` | 400 | JSON 不合法 |
 | `QUERY_KEY_REQUIRED` | 400 | 查询接口缺少可用业务 key |
 | `OBJECT_NOT_FOUND` | 404 | 对象详情查询目标不存在 |
-| `HOTEL_ID_REQUIRED` | 400 | 任务结果通知使用外部 `source_message_id` 时缺少 `hotel_id` |
+| `HOTEL_ID_REQUIRED` | 400 | 三个 SuperAgent 接口缺少必填 `hotel_id` |
 | `SOURCE_MESSAGE_NOT_FOUND` | 404 | 任务结果通知引用的外部来源消息尚未写入 SourceMessage Inbox |
 
 ## 8. HMAC 上线配置
@@ -394,7 +412,10 @@ SuperAgent 不应知道或依赖内部 SourceMessage Inbox ID。任务结果通
 
 | 配置项 | 是否必填 | 中文说明 |
 | --- | --- | --- |
-| `SUPERAGENT_TASK_RESULT_HMAC_SECRET` | 是 | HMAC 共享密钥；查询接口和任务结果通知接口共用 |
+| `SUPERAGENT_DEV_TASK_RESULT_HMAC_SECRET` | dev 必填 | dev HMAC 共享密钥；查询接口和任务结果通知接口共用 |
+| `SUPERAGENT_TEST_TASK_RESULT_HMAC_SECRET` | test 必填 | test HMAC 共享密钥；查询接口和任务结果通知接口共用 |
+| `SUPERAGENT_PROD_TASK_RESULT_HMAC_SECRET` | prod 必填 | prod HMAC 共享密钥；生产不能为空，只能通过 Secret 注入 |
+| `SUPERAGENT_TASK_RESULT_HMAC_SECRET` | 兼容兜底 | 旧通用 HMAC 变量；优先使用环境专属变量 |
 | `SUPERAGENT_TASK_RESULT_CLOCK_SKEW_SECONDS` | 否 | 请求时间允许偏移，默认 `300` 秒 |
 | `SUPERAGENT_TASK_RESULT_NONCE_TTL_SECONDS` | 否 | nonce 防重放保存时间，默认 `600` 秒 |
 | `SUPERAGENT_TASK_RESULT_MAX_BODY_BYTES` | 否 | 请求体最大字节数，默认 `1048576` |
@@ -402,7 +423,7 @@ SuperAgent 不应知道或依赖内部 SourceMessage Inbox ID。任务结果通
 上线注意事项：
 
 - 本系统和 SuperAgent 必须配置同一个 HMAC secret。
-- secret 只能放在部署平台 Secret 或环境变量中，不能写入仓库、镜像、前端配置或普通文档。
+- 生产 secret 只能放在部署平台 Secret 或环境变量中，不能写入仓库、镜像、前端配置或普通文档。
 - SuperAgent 必须使用原始请求体计算 SHA-256，不能使用格式化后 JSON。
 - HMAC canonical string 的第二行必须使用 `request_path`，例如 `/api/ai-query/v1/case-context`。
 - SuperAgent 每次请求必须生成全新的 nonce；同一个 `client_id + nonce` 在 TTL 窗口内不能重复使用。
diff --git a/docs/project/requirements/M002-backend-data-model-design.md b/docs/project/requirements/M002-backend-data-model-design.md
index 8665dcf..0ab5df8 100644
--- a/docs/project/requirements/M002-backend-data-model-design.md
+++ b/docs/project/requirements/M002-backend-data-model-design.md
@@ -393,7 +393,8 @@
 - 任务卡字段矩阵配置：先写在代码 Provider 中。
 - 任务阻塞状态：实时计算，不落 `BLOCKED`。
 - OPERA 真实接口字段映射：后续真实系统接入后在 adapter 层补充。
-- 全量 Excel 字段路径：引用 `任务卡展示编辑矩阵.xlsx`，不手抄成数据库。
+- 全量 Excel 字段路径：后端引用 `docs/import/20260706/任务卡展示编辑矩阵.xlsx` 作为完整规则来源，不手抄成数据库。
+- 前端展示 / 编辑白名单：前端引用 `docs/import/20260708/任务卡前端展示字段表 3.0.xlsx`，该白名单不作为后端校验和 OPERA 映射的替代来源。
 
 ## 15. 待确认问题
 
diff --git a/docs/project/requirements/M002-superagent-task-result-api-contract.md b/docs/project/requirements/M002-superagent-task-result-api-contract.md
index 604ee84..34ae3e3 100644
--- a/docs/project/requirements/M002-superagent-task-result-api-contract.md
+++ b/docs/project/requirements/M002-superagent-task-result-api-contract.md
@@ -57,12 +57,15 @@ hotel_id + source_provider(默认 AGENTBUS) + source_channel(默认 EMAIL) + sou
 
 | 环境变量 | 是否必填 | 中文说明 |
 | --- | --- | --- |
-| `SUPERAGENT_TASK_RESULT_HMAC_SECRET` | 是 | SuperAgent 任务结果入站签名密钥，只能通过 Secret 注入 |
+| `SUPERAGENT_DEV_TASK_RESULT_HMAC_SECRET` | dev 必填 | dev SuperAgent 任务结果入站签名密钥，只能通过 Secret 注入 |
+| `SUPERAGENT_TEST_TASK_RESULT_HMAC_SECRET` | test 必填 | test SuperAgent 任务结果入站签名密钥，只能通过 Secret 注入 |
+| `SUPERAGENT_PROD_TASK_RESULT_HMAC_SECRET` | prod 必填 | prod SuperAgent 任务结果入站签名密钥，只能通过 Secret 注入 |
+| `SUPERAGENT_TASK_RESULT_HMAC_SECRET` | 兼容兜底 | 旧通用 HMAC 变量；新环境优先配置环境专属变量 |
 | `SUPERAGENT_TASK_RESULT_CLOCK_SKEW_SECONDS` | 否 | 请求时间允许偏移，默认 `300` 秒 |
 | `SUPERAGENT_TASK_RESULT_NONCE_TTL_SECONDS` | 否 | Nonce 去重窗口，默认 `600` 秒 |
 | `SUPERAGENT_TASK_RESULT_MAX_BODY_BYTES` | 否 | 请求体最大字节数，默认 `1048576` |
 
-如果 `SUPERAGENT_TASK_RESULT_HMAC_SECRET` 为空，生产环境应拒绝接口调用。
+如果当前 profile 对应的 `SUPERAGENT_*_TASK_RESULT_HMAC_SECRET` 和旧通用变量都为空，生产环境应拒绝接口调用。
 
 ### 3.2 请求 Header
 
@@ -92,7 +95,7 @@ POST
 签名算法：
 
 ```text
-signature = HMAC_SHA256(SUPERAGENT_TASK_RESULT_HMAC_SECRET, canonical_string)
+signature = HMAC_SHA256(当前 profile 生效的 SuperAgent HMAC secret, canonical_string)
 ```
 
 Header 写法：
diff --git a/server/src/main/resources/application-dev.yml b/server/src/main/resources/application-dev.yml
new file mode 100644
index 0000000..6edb5a5
--- /dev/null
+++ b/server/src/main/resources/application-dev.yml
@@ -0,0 +1,43 @@
+spring:
+  datasource:
+    # dev 使用可提交的开发测试库地址；密码仍通过环境变量注入。
+    url: "jdbc:mysql://rm-7xv137v8f04vfk7a4ko.mysql.rds.aliyuncs.com:3306/th_hotel?useUnicode=true&characterEncoding=utf8&useSSL=false&allowPublicKeyRetrieval=true&serverTimezone=UTC"
+    username: th_hotel_user
+    password: 'CxrLg6b6kw2zJjmcjHUj'
+    driver-class-name: com.mysql.cj.jdbc.Driver
+  flyway:
+    enabled: true
+
+source-message:
+  original-read:
+    # dev 邮件原文读取访问密钥；优先使用 dev 专属变量，兼容旧通用变量。
+    access-key: ${SOURCE_MESSAGE_DEV_ORIGINAL_READ_ACCESS_KEY:${SOURCE_MESSAGE_ORIGINAL_READ_ACCESS_KEY:}}
+
+agentbus:
+  probe:
+    # dev 默认不主动连接 AgentBus，避免本地启动误消费消息。
+    enabled: false
+  ws:
+    # AgentBus dev/test 真实测试地址可以提交；Token 仍走环境变量。
+    url: wss://mesh.nianxx.cn/ws
+    token: ${AGENTBUS_DEV_WS_TOKEN:}
+    reconnect-delay: 5s
+    connect-timeout: 15s
+  capture:
+    enabled: true
+    default-hotel-id: HOTEL-DEV
+
+superagent:
+  task-result:
+    # dev SuperAgent HMAC 密钥；优先使用 dev 专属变量，兼容旧通用变量。
+    hmac-secret: ${SUPERAGENT_DEV_TASK_RESULT_HMAC_SECRET:${SUPERAGENT_TASK_RESULT_HMAC_SECRET:}}
+
+reservation:
+  demo-data:
+    # dev 本地联调默认开启演示数据造数接口；生产环境不得开启。
+    enabled: true
+    # 本地演示数据接口访问口令，需和 X-TH-Hotel-Demo-Data-Key 请求头一致。
+    access-key: ${RESERVATION_DEV_DEMO_DATA_ACCESS_KEY:${RESERVATION_DEMO_DATA_ACCESS_KEY:}}
+
+server:
+  port: 8080
diff --git a/server/src/main/resources/application-prod.yml b/server/src/main/resources/application-prod.yml
new file mode 100644
index 0000000..539ad5c
--- /dev/null
+++ b/server/src/main/resources/application-prod.yml
@@ -0,0 +1,40 @@
+spring:
+  datasource:
+    # prod 只保留结构，真实生产连接信息和密码必须由环境变量或部署平台 Secret 注入。
+    url: ${TH_HOTEL_PROD_DB_URL}
+    username: ${TH_HOTEL_PROD_DB_USERNAME}
+    password: ${TH_HOTEL_PROD_DB_PASSWORD}
+    driver-class-name: com.mysql.cj.jdbc.Driver
+  flyway:
+    enabled: true
+
+source-message:
+  original-read:
+    # prod 邮件原文读取访问密钥；只能通过生产 Secret / 环境变量注入。
+    access-key: ${SOURCE_MESSAGE_PROD_ORIGINAL_READ_ACCESS_KEY:${SOURCE_MESSAGE_ORIGINAL_READ_ACCESS_KEY:}}
+
+agentbus:
+  probe:
+    enabled: ${AGENTBUS_PROD_PROBE_ENABLED:false}
+  ws:
+    url: ${AGENTBUS_PROD_WS_URL}
+    token: ${AGENTBUS_PROD_WS_TOKEN}
+    reconnect-delay: 5s
+    connect-timeout: 15s
+  capture:
+    enabled: true
+    default-hotel-id: ${AGENTBUS_PROD_DEFAULT_HOTEL_ID}
+
+superagent:
+  task-result:
+    # prod SuperAgent HMAC 密钥不能为空；生产优先使用 prod 专属变量，兼容旧通用变量。
+    hmac-secret: ${SUPERAGENT_PROD_TASK_RESULT_HMAC_SECRET:${SUPERAGENT_TASK_RESULT_HMAC_SECRET}}
+
+reservation:
+  demo-data:
+    # prod 永远不启用演示数据造数接口。
+    enabled: false
+    access-key: ${RESERVATION_PROD_DEMO_DATA_ACCESS_KEY:${RESERVATION_DEMO_DATA_ACCESS_KEY:}}
+
+server:
+  port: ${SERVER_PORT:8080}
diff --git a/server/src/main/resources/application-test.yml b/server/src/main/resources/application-test.yml
new file mode 100644
index 0000000..5fc9081
--- /dev/null
+++ b/server/src/main/resources/application-test.yml
@@ -0,0 +1,42 @@
+spring:
+  datasource:
+    # test 数据库连接信息通过测试机 env 文件统一注入，默认值仅用于本机快速启动。
+    url: ${SPRING_DATASOURCE_URL:jdbc:mysql://127.0.0.1:3306/th_hotel_test?useUnicode=true&characterEncoding=utf8&useSSL=false&allowPublicKeyRetrieval=true&serverTimezone=UTC}
+    username: ${SPRING_DATASOURCE_USERNAME:th_hotel_test}
+    password: ${SPRING_DATASOURCE_PASSWORD:${TH_HOTEL_TEST_DB_PASSWORD:}}
+    driver-class-name: com.mysql.cj.jdbc.Driver
+  flyway:
+    enabled: true
+
+source-message:
+  original-read:
+    # test 邮件原文读取访问密钥；优先使用 test 专属变量，兼容旧通用变量。
+    access-key: ${SOURCE_MESSAGE_TEST_ORIGINAL_READ_ACCESS_KEY:${SOURCE_MESSAGE_ORIGINAL_READ_ACCESS_KEY:}}
+
+agentbus:
+  probe:
+    # test 默认不主动连接 AgentBus，需要联调时显式改开关或覆盖配置。
+    enabled: false
+  ws:
+    # AgentBus dev/test 真实测试地址可以提交；Token 仍走环境变量。
+    url: wss://mesh.nianxx.cn/ws
+    token: ${AGENTBUS_TEST_WS_TOKEN:}
+    reconnect-delay: 5s
+    connect-timeout: 15s
+  capture:
+    enabled: true
+    default-hotel-id: HOTEL-TEST
+
+superagent:
+  task-result:
+    # test SuperAgent HMAC 密钥；优先使用 test 专属变量，兼容旧通用变量。
+    hmac-secret: ${SUPERAGENT_TEST_TASK_RESULT_HMAC_SECRET:${SUPERAGENT_TASK_RESULT_HMAC_SECRET:}}
+
+reservation:
+  demo-data:
+    # test 默认关闭演示数据造数接口，需要联调时显式开启并配置访问口令。
+    enabled: ${RESERVATION_TEST_DEMO_DATA_ENABLED:false}
+    access-key: ${RESERVATION_TEST_DEMO_DATA_ACCESS_KEY:${RESERVATION_DEMO_DATA_ACCESS_KEY:}}
+
+server:
+  port: ${SERVER_PORT:8080}
diff --git a/server/src/main/resources/application.yml b/server/src/main/resources/application.yml
index 80da021..8453a33 100644
--- a/server/src/main/resources/application.yml
+++ b/server/src/main/resources/application.yml
@@ -1,11 +1,9 @@
 spring:
   application:
     name: th-hotel-server
-  datasource:
-    url: ${TH_HOTEL_DB_URL:jdbc:h2:mem:th_hotel;MODE=MySQL;DATABASE_TO_LOWER=TRUE;CASE_INSENSITIVE_IDENTIFIERS=TRUE}
-    username: ${TH_HOTEL_DB_USERNAME:sa}
-    password: ${TH_HOTEL_DB_PASSWORD:}
-    driver-class-name: ${TH_HOTEL_DB_DRIVER:org.h2.Driver}
+  profiles:
+    # 未显式指定 profile 时默认使用 dev，避免本地启动误连 test/prod。
+    default: dev
   flyway:
     enabled: true
 
@@ -15,29 +13,19 @@ mybatis-plus:
   global-config:
     banner: false
 
-source-message:
-  original-read:
-    access-key: ${SOURCE_MESSAGE_ORIGINAL_READ_ACCESS_KEY:}
-
 agentbus:
   probe:
-    enabled: ${AGENTBUS_PROBE_ENABLED:false}
-  ws:
-    url: ${AGENTBUS_WS_URL:wss://mesh.nianxx.cn/ws}
-    token: ${AGENTBUS_WS_TOKEN:}
-    reconnect-delay: ${AGENTBUS_WS_RECONNECT_DELAY:5s}
-    connect-timeout: ${AGENTBUS_CONNECT_TIMEOUT:15s}
-  max-frame-bytes: ${AGENTBUS_MAX_FRAME_BYTES:1048576}
+    enabled: false
+  max-frame-bytes: 1048576
   capture:
     enabled: ${AGENTBUS_CAPTURE_ENABLED:true}
-    default-hotel-id: ${AGENTBUS_DEFAULT_HOTEL_ID:HOTEL-TEST}
+    default-hotel-id: HOTEL-TEST
 
 superagent:
   task-result:
-    hmac-secret: ${SUPERAGENT_TASK_RESULT_HMAC_SECRET:}
-    clock-skew-seconds: ${SUPERAGENT_TASK_RESULT_CLOCK_SKEW_SECONDS:300}
-    nonce-ttl-seconds: ${SUPERAGENT_TASK_RESULT_NONCE_TTL_SECONDS:600}
-    max-body-bytes: ${SUPERAGENT_TASK_RESULT_MAX_BODY_BYTES:1048576}
+    clock-skew-seconds: 300
+    nonce-ttl-seconds: 600
+    max-body-bytes: 1048576
 
 server:
-  port: ${SERVER_PORT:8080}
+  port: 8080