SA-1380 — FX Outstanding Notification: Implementation Plan

อ่าน FX_OUTSTANDING_NOTIFICATION_ARCHITECTURE.md ให้จบก่อน — เอกสารนี้ไม่อธิบายซ้ำว่า “ทำไม” อธิบายแค่ “ทำอะไร ตามลำดับไหน และรู้ได้ยังไงว่าถูก”

สถานะ ณ 06/08/2026 — แผนนี้ถูก implement ไปแล้ว

ยังไม่ได้ทำ (ติด gate): G-1 near-expiry endpoint ปลายทาง · G-2 provision topic จริงที่ ASB · E2E §5.4 — ทั้งหมดต้องรอของนอก 3 repo

สิ่งที่เปลี่ยนจากแผนตอนเขียนครั้งแรก หลังตรวจโค้ดจริง:

1. guard ของ topic key ย้ายจาก constructor ไป DI registration — scheduler resolve publisher ข้างใน tick แล้ว catch-and-log ดังนั้น throw ที่ ctor จะกลายเป็น retry loop เงียบ ๆ แทนที่จะเป็น startup failure · house pattern ของ FxEmailPublisher ก็ guard ที่ DI
2. IaC ต้องครบ dev/sit/uat ไม่ใช่แค่ dev/sit — เหตุผลใน architecture §8 (guard ไม่เคยรันให้ sit/uat เลย)
3. C-07 (cross-repo topic check) ยังไม่ได้เขียน — TopicName เป็น private const เข้าไม่ถึงจาก test project และค่าอีกฝั่งอยู่คนละ repo · ยังเป็นหนี้เปิดอยู่ ต้องเลือกระหว่าง internal const + InternalsVisibleTo หรือ CI script ที่ diff 2 ไฟล์

0. กฎที่ใช้ตลอดแผนนี้

0.1 🛑 STOP rule

ถ้าเจอ gate ที่ยังไม่เขียว หรือเจอว่าโค้ดจริงไม่ตรงกับที่แผนนี้เขียน — หยุดแล้วรายงาน ห้ามเลือกทางที่ compile ผ่าน

แผนนี้เขียนจากโค้ดที่อ่าน ณ 06/08/2026 ถ้า repo ขยับไปแล้ว ข้อเท็จจริงในแผนอาจไม่จริง การเดาต่อทำให้ pull request รีวิวไม่ได้

0.2 🔴 ต้อง git fetch ก่อนเริ่มทุก repo

ตอนวางแผนพบว่า local checkout ของทั้ง NotificationService และ UserService ค้างเก่ากว่า origin/development และข้อเท็จจริงสำคัญที่สุด 2 ข้อของงานนี้ (endpoint cust-codes และคอลัมน์ AppCode) มองไม่เห็นจาก working tree เลย

for r in Backend_NotificationService Backend_UserService Backend_FxOrchestratorService; do
  git -C "C:/Source/AzureDevOps_SuperAPP/$r" fetch origin
  echo "$r: HEAD=$(git -C "C:/Source/AzureDevOps_SuperAPP/$r" rev-parse --short HEAD) behind=$(git -C "C:/Source/AzureDevOps_SuperAPP/$r" rev-list --count HEAD..origin/development)"
done

0.3 ⚠️ NotificationService และ UserService มี .worktrees/

ทุก grep/glob ต้อง exclude .worktrees/ ไม่งั้นจะเจอไฟล์เดียวกัน 6-8 เวอร์ชันแล้วแก้ผิดตัว

0.4 build/test ต้องมี FEED_TOKEN

export FEED_TOKEN=$(az account get-access-token --resource 499b84ac-1321-427f-aa17-267ca6975798 --query accessToken -o tsv)

0.5 ห้ามมี migration ในงานนี้

ถ้ารู้สึกว่าต้องเพิ่มคอลัมน์/ตาราง = ออกนอกแนวทางที่ตกลงไว้ ให้หยุดแล้วถาม ไม่ใช่ไปเปิด branch MIGRATION (ถ้าสุดท้ายจำเป็นจริง ต้อง author บน branch MIGRATION ตามกฎบ้าน แล้ว merge กลับเข้า feature — ห้าม author บน feature branch)

1. สรุปงานต่อ repo

2. ตารางงาน (เรียงตาม dependency)

เส้นทางวิกฤต: G-1 → G-2 → (T-01 → T-02 → T-03 → T-04) ∥ (T-07 → T-08) → T-10 → T-11 งาน NS (T-01..T-06) กับงาน FX (T-07..T-09) ทำขนานกันได้หลัง T-01 ตกลง contract แล้ว · G-3 ต้องเสร็จก่อน T-08 (T-08 เพิ่ม config key)

🔑 ชื่อ topic/subscription ในเอกสารนี้เป็น placeholder จนกว่า G-2 จะปิด — ข้อเสนอคือ fx-inapp-event / FxInApp-Sub (เหตุผลและหลักฐานใน architecture §7) แต่ ห้าม copy ลงโค้ดก่อน G-2 ยืนยันและ provision จริง เพราะ ASB เปลี่ยนชื่อ topic กับค่า provisioning ทีหลังไม่ได้

3. งานฝั่ง NotificationService

T-01 — Message contract

ไฟล์ใหม่: src/Notification04.Domain/Messages/FxOutstandingNotificationMessage.cs

namespace Notification04.Domain.Messages;

/// <summary>
/// สัญญาข้อความจาก FxOrchestrator สำหรับ FX outstanding near-expiry (in-app).
/// ต้นทางส่ง "ข้อมูลสัญญา" มา ไม่ใช่ข้อความสำเร็จรูป — ข้อความประกอบที่ dispatcher.
/// </summary>
public sealed record FxOutstandingNotificationMessage(
    int SchemaVersion,
    string MessageId,
    string AppCode,
    string SourceService,
    string NotificationType,
    FxOutstandingRecipient Recipient,
    FxOutstandingContract Contract,
    DateTimeOffset OccurredAt);

public sealed record FxOutstandingRecipient(string UserId);

public sealed record FxOutstandingContract(
    string CustCode,
    string ContractNumber,
    string CurrencyCode,
    decimal OutstandingAmount,
    DateOnly MaturityDate,
    int DaysLeft);

Acceptance: record อยู่ layer 04.Domain (ไม่ใช่ Infrastructure), ไม่มี dependency กับ Azure SDK, field ตรงกับที่ฝั่ง FX ส่ง (T-07) ทุกตัว

Verify: dotnet build src/Notification01.API

T-02 — Dispatcher

ไฟล์ใหม่: src/Notification02.Infrastructure/Messaging/FxInAppNotificationDispatcher.cs — ประกาศ 3 type ในไฟล์เดียวกัน ตาม precedent (FxEmailDispatcher.cs:13-29 ทำแบบนี้): คลาส FxInAppNotificationDispatcher, record FxInAppDispatchResult(FxInAppDispatchAction Action, string? Reason, string? Description), และ enum FxInAppDispatchAction { Complete, DeadLetter }

ลอกโครงจาก 2 ที่ อย่าลอกจากที่เดียว:

เนื้อใน (โครง):

public async Task<FxInAppDispatchResult> DispatchAsync(
    FxOutstandingNotificationMessage? message,
    IInAppNotificationService inAppNotifications,
    CancellationToken ct)

1. Validate(message) — ถ้าไม่ผ่าน → DeadLetter(reason) ห้าม Abandon (retry ไม่ช่วย)
2. ประกอบข้อความ (§3.1)
3. await inAppNotifications.SendPersonalAsync(userId, payload, sourceService: message.SourceService, externalMessageId: message.MessageId, ct)
4. Complete()
5. แยก exception 2 ชนิด — ห้ามเหมารวม:
   • unique-violation (Postgres SQLSTATE 23505) ที่ index IX_in_app_notifications_external_message_dedup → Complete() เพราะแปลว่า ส่งไปแล้วจริง ไม่ใช่ความผิดพลาด
   • transient อื่น (connection, timeout, deadlock) → ปล่อย exception ขึ้นไปให้ consumer abandon เพื่อ retry

ทำไมต้องแยก: InAppNotificationService.cs:33-39 เช็คซ้ำแบบ read-then-write ซึ่ง ไม่ atomic — ถ้า ASB redeliver พร้อมกัน 2 ใบ ใบที่แพ้ race จะทะลุไปชน unique index แล้วโยน DbUpdateException ถ้าเหมาว่าเป็น transient แล้ว abandon มันจะ retry จนครบ MaxDeliveryCount แล้ว dead-letter ข้อความที่ส่งสำเร็จไปแล้ว — precedent ในบ้านทำถูกอยู่แล้ว: FxEmailEventConsumer.cs:116-126 จับ AneDuplicateRequestException แล้ว CompleteMessageAsync

Validate ต้อง reject (→ DeadLetter) อย่างน้อย:

⚠️ ContractNumber ว่าง — ต้องตกลงให้ตรงกันข้ามฝั่ง ปัจจุบัน scheduler แทนค่าว่างด้วย "-" (FxOutstandingNotificationScheduler.cs:167) แล้วใช้ค่าที่แทนแล้วนั้นในสูตร messageId แผนนี้กำหนดว่า: ส่งค่าที่ normalize แล้ว ("-") ลง Contract.ContractNumber บนสาย เพื่อให้ messageId กับ payload ตรงกัน ⇒ ผลคือกฎ MissingContractNumber จะไม่มีทางถูก trigger จาก FxOrchestrator แต่ยังต้องมีไว้กัน publisher อื่นในอนาคต — เคส D-11 จึงเป็น unit test ระดับ dispatcher เท่านั้น ไม่ใช่เคสที่คาดว่าจะเกิดบน production

Acceptance: เป็น plain class เรียกได้โดยไม่ต้อง mock ServiceBusClient; ไม่มี try/catch ครอบการประกอบ context นอก try (บทเรียนจาก InvitationEventConsumer ที่ประกอบ contextDict นอก try แล้ว input พังทำให้ throw แทนที่จะ dead-letter)

3.1 การประกอบข้อความ

var within = contract.DaysLeft <= 0 ? "ภายในวันนี้" : $"ภายใน {contract.DaysLeft} วัน";
var title = $"สัญญาใกล้ครบอายุ {within}";
var subtitle = $"สัญญาเลขที่ {contract.ContractNumber} ใกล้ครบอายุ {within} "
             + "กรุณาดำเนินการให้เสร็จสิ้นก่อนครบอายุสัญญา";

• ❌ ห้ามคำนวณ DaysLeft ใหม่ — ใช้ค่าจาก payload ตรง ๆ (เหตุผลใน architecture §4.1)
• ❌ ห้ามต่อ IEmailTemplateKeyRepository/IEmailMacroRepository — เป็นกลไกของสาย email
• 🔴 ตัดสินแล้ว: ไม่ encode — in-app Title/Subtitle เป็น plain text ไม่ใช่ HTML และไม่มี in-app writer ตัวไหนใน NotificationService encode วันนี้ (WorkflowMakerDispatcher ก็ไม่ encode) ⇒ ใช้ interpolation ตรง ๆ และ FE ต้องไม่ render ค่านี้เป็น HTML · กฎ “escape ทุกค่า” ที่เขียนไว้ใน architecture §4 ใช้กับสาย email ซึ่ง render เป็น HTML จริง ไม่ใช่กับ in-app
• ข้อจำกัดความยาวจริง: Title มี HasMaxLength(300) แต่สูตรข้างบนใส่แค่ DaysLeft ลง Title จึงยาวไม่เกิน ~40 ตัวอักษรเสมอ · Subtitle เป็น HasColumnType("text") ไม่มีเพดาน (InAppNotificationConfiguration.cs:23-25) ⇒ ไม่ต้องเขียน logic ตัดความยาว และ ห้ามเขียน test ที่พยายามทำให้ Title ล้น เพราะสร้างเงื่อนไขนั้นไม่ได้จากสูตรนี้

T-03 — Consumer

ไฟล์ใหม่: src/Notification02.Infrastructure/Messaging/FxInAppEventConsumer.cs

ลอกโครง FxEmailEventConsumer ทั้งไฟล์ แล้วเปลี่ยน:

// 🛑 ห้ามเขียนค่าเหล่านี้จนกว่า G-2 จะปิด — ค่าที่ใส่ต้องเป็นค่าที่ provision จริงที่ ASB
// และต้องตรงกับค่าที่ publisher ฝั่ง FX อ่านจาก ServiceBus:FxInAppTopicName เป๊ะ
private const string TopicName = "<ค่าจาก G-2>";
private const string SubscriptionName = "<ค่าจาก G-2>";

ต้องคง 3 พฤติกรรมนี้จากต้นแบบ:

1. StartProcessingAsync ห่อ try/catch ที่ LogCritical แล้ว return — ห้าม throw (ไม่งั้น BackgroundServiceExceptionBehavior.StopHost จะทำให้ทั้ง service ตายเพราะ consumer ตัวเดียว)
2. deserialize ไม่ได้ → DeadLetterMessageAsync("DeserializationFailed", …) ไม่ใช่ throw
3. result.Action == DeadLetter → DeadLetterMessageAsync(result.Reason, result.Description) · Complete → CompleteMessageAsync · exception หลุด → AbandonMessageAsync

⚠️ dispatcher เป็นคนตัดสินเรื่อง unique-violation แล้ว (T-02 ข้อ 5) — consumer ไม่ต้องรู้จัก 23505 เอง แค่ทำตาม result.Action และ abandon เมื่อมี exception หลุดออกมาเท่านั้น

T-04 — DI

ไฟล์: src/Notification02.Infrastructure/DependencyInjection.cs

🔴 register 2 จุด — branch Mode B (Entra RBAC) และ branch Mode A (connection string) ลงข้างหลัง AddHostedService<Messaging.FxEmailEventConsumer>() ทั้งคู่:

services.AddHostedService<Messaging.FxInAppEventConsumer>();

Acceptance: grep แล้วเจอ FxInAppEventConsumer 2 ครั้ง ในไฟล์นี้

Verify:

grep -c "FxInAppEventConsumer" src/Notification02.Infrastructure/DependencyInjection.cs   # ต้องได้ 2

4. งานฝั่ง FxOrchestratorService

T-07 — Publisher ตัวใหม่

ไฟล์ใหม่:

• src/FxOrchestrator04.Domain/Ports/Gateway/Notification/IFxOutstandingNotificationPublisher.cs + record FxOutstandingNotification (mirror ของ T-01 เป๊ะ)
• src/FxOrchestrator02.Infrastructure/Messaging/AsbFxOutstandingNotificationPublisher.cs
• src/FxOrchestrator02.Infrastructure/Messaging/NullFxOutstandingNotificationPublisher.cs

ลอกโครงจาก AsbPersonalNotificationPublisher ทั้งชุด แล้วเปลี่ยน 4 อย่าง:

1. topic จาก config key ใหม่ ServiceBus:FxInAppTopicName
2. body เป็น FxOutstandingNotificationMessage (โครง §4 ของ architecture) แทน {userId, eventName, payload}
3. คง JavaScriptEncoder.Create(UnicodeRanges.All) ไว้ ไม่งั้น custCode/ชื่อสัญญาที่มีอักขระไทยจะกลายเป็น \uXXXX
4. 🔴 ตัด default fallback ทิ้ง — ต้นแบบเขียน configuration["…"] ?? DefaultTopicName ซึ่งถ้า key หายจะเงียบ ๆ ไปยิง topic ผิด ตัวใหม่ต้อง throw เมื่อ key ไม่มี (เคส P-04)

🔴 guard ต้องอยู่ที่ DI registration ไม่ใช่ที่ constructor — scheduler resolve publisher ข้างใน RunTickAsync และ ExecuteAsync จับ exception แล้ว log อย่างเดียว ดังนั้น throw จาก ctor จะไม่ทำให้ app ตาย แต่จะกลายเป็น retry loop เงียบ ๆ ทุก tick แบบเดียวกับ G-1 พอดี · house pattern ทำถูกอยู่แล้ว: DependencyInjection.cs guard ServiceBus:NotificationTopicName ตอน register IForwardContractEmailGateway ⇒ ใส่ guard ในบล็อก if (hasAzureServiceBus) ให้ fail ตอน startup แล้วเก็บ throw ที่ ctor ไว้เป็น backstop

⚠️ คง sbMessage.MessageId = notification.MessageId ไว้ — เป็นทั้ง dedup ของ ASB (ถ้าเปิด) และค่าที่ปลายทางใช้เป็น ExternalMessageId

DI: ทำตาม pattern hasAzureServiceBus เดิมใน FxOrchestrator02.Infrastructure/DependencyInjection.cs — มี ASB → ตัวจริง, ไม่มี → Null

T-08 — Rewire scheduler

ไฟล์: src/FxOrchestrator01.API/BackgroundServices/FxOutstandingNotificationScheduler.cs

คงสูตร messageId เดิม:

fx-outstanding:{custCode}:{contractNo}:{userId:D}:{yyyyMMdd}:{HHmm}

config: เพิ่ม ServiceBus:FxInAppTopicName ใน appsettings.json + appsettings.Development.json และ Backend_Iac/config/fxorchestrator-service/{env}/appsettings.json ตามผลของ G-3

ตัดสินใจได้ 2 ทางเรื่อง AsbPersonalNotificationPublisher เดิม: (ก) ลบทิ้งพร้อม IPersonalNotificationPublisher/NullPersonalNotificationPublisher และ test ของมัน หรือ (ข) ปล่อยไว้เป็น dead code — แนะนำ (ก) เพราะเราเป็นคนทำให้มันกำพร้า (กฎ “ลบสิ่งที่เราทำให้ไม่ได้ใช้”) และการเหลือ publisher 2 ตัวที่ยิงคนละ topic คือกับดักรอคนถัดไป

5. Test coverage

Owner กำหนดว่า test ต้องครบ — ตารางนี้คือ definition of “ครบ” ทุกแถวต้องมีอยู่จริงก่อนปิดงาน

5.1 NotificationService — tests/Notification05.Tests

stack: xunit 2.9.3 + Moq 4.20.72 + EF Core InMemory · ต้นแบบ: Infrastructure/Messaging/PersonalSignalConsumerTests.cs

Dispatcher — FxInAppNotificationDispatcherTests

Consumer — FxInAppEventConsumerTests

DI — การยืนยันว่า register ครบ 2 branch

⚠️ ห้ามเขียนเป็น unit test ที่ build ServiceCollection จริง — tests/Notification05.Tests/Infrastructure/DependencyInjectionTests.cs:13-14 บันทึกไว้เองว่า AddInfrastructure ต่อ Redis แบบ synchronous ทันทีหลัง guard จึงมีแค่ branch เดียวที่เรียกได้โดยไม่ต้องมี Redis/Postgres/ServiceBus จริง (DependencyInjection.cs:95,104 เรียก ConnectionMultiplexer.Connect) แม้ AbortOnConnectFail = false (บรรทัด 261) จะทำให้ไม่ throw แต่จะ block ~5 วินาทีต่อ multiplexer กลายเป็น unit test ที่พึ่ง network และไม่มี precedent ใน repo

5.2 FxOrchestratorService — tests/FxOrchestrator05.Tests

Publisher — AsbFxOutstandingNotificationPublisherTests

Scheduler — ⚠️ ต้องเขียนใหม่ทั้งหมด ไม่ใช่ “เพิ่มใน test เดิม”

ยืนยันแล้วว่า ไม่มี FxOutstandingNotificationSchedulerTests อยู่ในrepo — scheduler test ตัวเดียวที่มีคือ tests/FxOrchestrator05.Tests/API/BackgroundServices/FxRateSyncSchedulerTests.cs ดังนั้น S-01..S-10 คือ test ใหม่ทั้งชุด (คำว่า regression ในคอลัมน์ “ชนิด” หมายถึง พฤติกรรมเดิมที่ต้องไม่เปลี่ยน ไม่ได้แปลว่ามี baseline test อยู่แล้ว)

ต้นแบบที่ใช้ได้จริง: FxRateSyncSchedulerTests.cs:26-60 (RunForAsync/RunUntilAsync helper) · scheduler เป็น internal sealed partial จึงเข้าถึงได้เพราะ InternalsVisibleTo ที่ FxOrchestrator01.API.csproj:39 — ถ้า test มองไม่เห็นคลาส ให้ตรวจบรรทัดนั้นก่อน อย่าเปลี่ยน accessibility ของ production code

เช่นเดียวกัน: T-08 ที่เขียนว่า “ลบ AsbPersonalNotificationPublisher … และ test ของมัน” — ไม่มี test ของ publisher ตัวเดิมอยู่ ลบเฉพาะ production code

5.3 Regression — พิสูจน์ว่า business logic อื่นไม่พัง (T-10)

นี่คือข้อที่ Owner เน้นที่สุด (“อย่าทำให้ Business Logic อื่นพังเด็ดขาด”) — ต้องมีหลักฐาน ไม่ใช่ความมั่นใจ

คำสั่งปิดงาน:

# NotificationService
dotnet build src/Notification01.API && dotnet test tests/Notification05.Tests
# FxOrchestratorService
dotnet build src/FxOrchestrator01.API && dotnet test tests/FxOrchestrator05.Tests

ทั้งสอง repo ต้อง exit code 0 และจำนวน test ที่ผ่านต้อง ไม่น้อยกว่า ก่อนเริ่มงาน

5.4 E2E บน dev (T-11)

1. ยืนยัน G-1 เขียว (near-expiry คืนข้อมูลจริง)
2. ตั้ง FX Codex config FxNotificationOutstanding: Enabled=true, StartTimes เป็นเวลาที่กำลังจะถึง, ExpireDate ที่ครอบสัญญาทดสอบ
3. รอ slot → ดู log [FxOutstandingNotification] run complete — Slots=… Found=… Sent=… Skipped=…
4. เปิดเว็บจริง login เป็น user ที่อยู่ในบริษัทเจ้าของสัญญา → กระดิ่งต้องเด้งแบบ realtime
5. refresh หน้า → GET api/notification-service/v1/notifications?appCode=FX ยังเห็นรายการเดิม (พิสูจน์ว่า persist ไม่ใช่แค่ push)
6. กดอ่าน → เรียก GET api/notification-service/v1/notifications/unread-count?appCode=FX แล้วเลขลดลง — ⚠️ ต้องเช็คจาก endpoint นี้เท่านั้น ห้ามดูจาก UnreadCount ใน envelope ของ list หรือจาก unreadCount ใน SignalR push เพราะสองจุดนั้นเป็นยอดรวมทุกแอป (ดู G-6) · เพิ่มขั้นตอนยืนยัน: ให้ user คนเดียวกันมี noti ของแอปอื่นค้างอยู่ด้วย แล้วดูว่าเลขจากสองแหล่งต่างกันจริง
7. รัน slot เดิมซ้ำ → ต้องไม่มีรายการซ้ำ (พิสูจน์ dedup ด้วย ExternalMessageId)
8. ตรวจว่า user ในบริษัทอื่น ไม่เห็น รายการนี้

⚠️ ตามกฎ E2E ของทีม: เปิด browser จริง (headed) กดผ่านหน้าจอทุก step ห้าม seed ข้อมูลด้วยการยิง API — ข้อ 2 (ตั้ง config) และการอ่าน log เป็น setup/observability ไม่ใช่การสร้างผลการทดสอบ

6. Owner decision ที่ยังเปิดอยู่

7. งานที่แผนนี้ ไม่ ครอบคลุม (โดยตั้งใจ)

• Jira AC2 — highlight รายการใกล้ครบกำหนดในหน้า Outstanding (Frontend) · Owner ตัด FE ออก
• Jira AC3 — ส่ง email · เฟสถัดไป และ ไม่ต้องสร้าง topic/consumer ใหม่ — ใช้ fx-email-event + FxEmailEventConsumer/FxEmailDispatcher ที่มีอยู่แล้ว แค่เพิ่ม template key (เส้นทางเต็มใน architecture §7)
• SA-1556 — หน้าจอตั้งค่าจำนวนวัน · ค่าจริงตั้งได้แล้วผ่าน FX Codex ExpireDate ขาดแค่ UI
• FX_400 / ThirdPartyFX near-expiry endpoint · เป็น gate G-1
• หนี้ที่พบระหว่างวางแผน แต่ไม่แก้ในงานนี้ (บันทึกไว้เพื่อไม่ให้หาย):
  • PersonalSignalConsumer ไม่เคยส่ง externalMessageId ให้ SendPersonalAsync → path in-app ที่ใช้ร่วมกันทุกวันนี้ไม่มี dedup ระดับ DB เลย ทั้งที่ unique index มีอยู่แล้ว
  • NotificationDelivery.ChannelId เป็น Guid? ที่ validator บังคับว่าต้องมี แต่ไม่มีตารางรองรับ

8. Definition of Done

• G-1 เขียวและมีหลักฐาน (ยิงจริง ได้ 200 + JSON) — ไม่ใช่ “น่าจะพร้อม”
• G-2 ปิดแล้ว: ชื่อ topic/subscription ถูกเคาะและ provision จริงทุก env — และค่าที่ใส่ในโค้ดคือค่านั้น ไม่ใช่ placeholder ในเอกสาร
• G-3 เขียว: check-config-parity.py exit 0 ทั้ง dev และ sit (รวม 8 key ที่ค้างอยู่เดิม + key ใหม่)
• dotnet test เขียวทั้ง 2 repo และจำนวน test ไม่ลดลง
• ทุกเคสใน §5.1-5.3 มีอยู่จริงและผ่าน (รวม D-13b unique-violation → Complete และ RG-09 unread ยอดรวม)
• topic ของ publisher (config) กับของ consumer (const) ถูกตรวจว่าตรงกันด้วยกลไกอัตโนมัติ ไม่ใช่ด้วยตา (C-07)
• git diff --name-only origin/development...HEAD ไม่มีชื่อไฟล์ในรายการห้ามแตะ (architecture §10)
• ไม่มี migration ใหม่ · has-pending-model-changes = none
• FxInAppEventConsumer ปรากฏ 2 ครั้งใน DependencyInjection.cs
• config key ใหม่อยู่ครบทั้ง service repo และ IaC ทุก env ที่กระทบ
• E2E §5.4 ผ่านครบ 8 ข้อ พร้อม screenshot
• G-5/G-6/G-7 ถูกบันทึกเป็นข้อเสนอ ไม่ถูกตัดสินเงียบ ๆ ในโค้ด
• FE ได้รับแจ้งว่ากระดิ่ง FX ต้องอ่าน unread จาก /unread-count?appCode=FX เท่านั้น (ผลของ G-6)