S7 — WPIS Core Business Flow + Phase 2 (Specification)¶

รายการ	ค่า
ระบบ	S7 ระบบงานคุ้มครองพยานในคดีอาญา (WPIS)
วัตถุประสงค์	อธิบายวงจรธุรกิจหลักของระบบ และแยกสิ่งที่เพิ่มใน Phase 2 ให้ตรวจสอบย้อนกลับได้
สถานะเอกสาร	Presentation-ready specification draft
วันที่อ้างอิง	12 กันยายน 2569
Code baseline	`develop@59b8f62`
Requirement baseline	SRS v3.0.0 + มติ/ADR/WO ที่ได้รับอนุมัติภายหลัง
Flow สำหรับนำเสนอ	เปิด Business Core Diagram แบบเต็มจอ
หน้าระบบหลัก	S7 — ระบบคุ้มครองพยาน
ที่มา	สังเคราะห์จาก repo `witness-protection-info-system` (`develop@59b8f62`) เมื่อ 12 กันยายน 2569

คำว่า CORE ในเอกสารนี้หมายถึงวงจรธุรกิจถาวรของงานคุ้มครองพยาน ไม่ได้แปลว่าความสามารถนั้นมีครบก่อน Phase 2 ส่วนเครื่องหมาย Phase 2 แสดง capability ที่เพิ่มหรือเปลี่ยนกติกาในโครงการระยะที่ 2

แผนภาพวงจรธุรกิจหลัก (Core Business Flow)¶

เปิดแบบเต็มจอ — Core Business + Phase 2

Problem Statement¶

ผู้บริหาร เจ้าของระบบ ทีมวิเคราะห์ และทีมพัฒนายังไม่มีภาพเดียวที่อธิบายว่า WPIS สนับสนุนภารกิจตั้งแต่รับคำร้องจนถึงสิ้นสุดการคุ้มครองอย่างไร และสิ่งใดคือความสามารถเดิม สิ่งใดเป็นการเพิ่มใน Phase 2 รวมถึงสิ่งใดมีเพียงโค้ดแล้วแต่ยังไม่เปิดใช้จริงในสภาพแวดล้อมตรวจรับ

เมื่อข้อมูลกระจายอยู่ใน SRS, FD, ADR, work order, traceability matrix และโค้ด การนำเสนอมีความเสี่ยงที่จะ:

เล่าโครงสร้างระบบแทนที่จะเล่ากระบวนการธุรกิจ
รวม “รอบคุ้มครอง” กับ “ใบประมาณการ” เป็นสิ่งเดียวกัน
อธิบายสถานะ “พัฒนาแล้ว” เท่ากับ “พร้อมใช้บน UAT” ทั้งที่ยังมี migration, deployment หรือ human gate
นำ requirement ที่ยังเปิดคำถามไปกล่าวเหมือนเป็นข้อตกลงแล้ว
อธิบาย Phase 2 เป็นระบบใหม่ทั้งก้อน ทั้งที่มติสถาปัตยกรรมคือการต่อยอด ASP.NET Core MVC monolith เดิม

Solution¶

ใช้วงจรธุรกิจเดียวเป็นแกนกลาง:

รับคำร้อง สคพ.1 จากช่องทางสำนักงานหรือ Portal
คัดกรอง รับเรื่อง และมอบหมายเจ้าของสำนวน
จัดทำข้อเท็จจริง ข้อมูลพยาน ผู้ใกล้ชิด และเอกสารประกอบ
ส่งเข้าสายพิจารณาหลายระดับ พร้อมทางเลือกส่งกลับ ยกคำร้อง ถอนคำร้อง หรือสั่งข้ามวาระกรณีเร่งด่วน
เมื่ออนุมัติ ให้สร้างและดำเนินรอบคุ้มครองตามคำสั่ง
จัดทำใบประมาณการหนึ่งหรือหลายใบภายใต้รอบ และบันทึกค่าใช้จ่ายจริงโดยผูกกับใบที่เลือก
ติดตามมาตรการและเหตุการณ์ระหว่างคุ้มครอง
สิ้นสุดหรือยุติการคุ้มครอง พร้อมสรุปวัน ค่าใช้จ่าย ประวัติ และผลลัพธ์สำหรับ Dashboard/รายงาน

Phase 2 ถูกนำเสนอเป็น capability overlay 4 กลุ่ม โดยไม่ทำให้สถานะเกินจริง:

กลุ่มส่งมอบ	สิ่งที่ Phase 2 เพิ่ม	สถานะ ณ 12 ก.ย. 2569
Phase 2-1 — Workflow	Workflow step/audit กลาง, ขั้นหัวหน้ากลุ่ม, มอบสำนวน, ถอนแยกจากยก, สรุปสิ้นสุด, ข้ามวาระพร้อมเหตุผล, ผูกพยานเดิม	ความสามารถหลัก merge แล้ว; ยังมีความเสี่ยง rework จาก Q-022 และ release/UAT gate ตามเอกสารแต่ละ WO
Phase 2-2 — Financial	แยก gate การบันทึกค่าใช้จ่าย, owner gate, หลายใบต่อรอบ, ระยะเวลา 30/60/90/120/กำหนดเอง, master ค่าแรงขั้นต่ำ, จังหวัด, ปิดใบตาม Covered Days	ทำแล้วหลายส่วน แต่ WIT-006 ทั้งข้อยังไม่ปิด; ADR-007/WO-2C-022 merge แล้วแต่ต้องมี migration 28 และ deploy ก่อนพฤติกรรมเกิดใน runtime เป้าหมาย
Phase 2-3 — Insight & Reports	KPI เพิ่ม, real-time dashboard, Thailand Map, รายงาน 4 ประเภท, รูปแบบเอกสารราชการ	KPI บางส่วน merge แล้ว; capability ที่เหลือทำบางส่วนหรือยังติด open question
Phase 2-4 — Digital & Integration	Portal intake อัตโนมัติ, e-Signature, SSO/MFA, AES-256, file scan/compression, E-AHT/IOT integration	e-Signature/SSO มีงานบางส่วน; capability ที่เหลือยังไม่เสร็จหรือรอ dependency ภายนอก

สถานะที่ใช้ใน Flow:

✅ = มี implementation/evidence ตาม RTM หรือ WO ที่อ้างถึง
◐ = ทำแล้วบางส่วน แต่ requirement ระดับ WIT ยังไม่ปิด
🔒 = ยังมี requirement, dependency, migration/deployment หรือ decision gate ที่ทำให้กล่าวว่า “พร้อมใช้ครบ” ไม่ได้
✅* = โค้ด merge แล้ว แต่ runtime เป้าหมายยังต้องผ่าน activation gate ที่ระบุ

User Stories¶

Core petition and case lifecycle¶

As a ผู้ยื่นคำร้อง, I want to submit a คำร้อง สคพ.1 through an authorized channel, so that my request enters the witness-protection process.
As a เจ้าหน้าที่รับคำขอ, I want to receive and verify petition documents, so that incomplete or invalid submissions do not enter case consideration silently.
As a เจ้าหน้าที่คัดกรอง, I want to classify and screen a petition, so that the case follows the appropriate protection process.
As a สารบรรณ, I want the receipt of a petition recorded as an auditable workflow step, so that the organization can trace when and by whom the case was accepted.
As a ผู้มอบหมายงาน, I want to assign one or more authorized case owners, so that responsibility for the petition is explicit.
As a เจ้าของสำนวน, I want to see only the case actions allowed by my ownership and permissions, so that confidential witness data is not changed by unrelated users.
As a เจ้าของสำนวน, I want to maintain petition facts, witness data, related persons, offenses, and supporting documents, so that the decision package is complete.
As a เจ้าของสำนวน, I want to link an existing witness or related person instead of creating duplicates, so that identity history remains connected across cases.
As a ผู้ตรวจสอบ, I want every material workflow action and denied attempt recorded, so that the case can be audited after the fact.

Consideration and approval¶

As a เจ้าของสำนวน, I want to submit a completed case for consideration, so that it enters the governed approval sequence.
As a หัวหน้ากลุ่ม, I want to review a submitted case when the configured step is enabled, so that group-level screening occurs before director approval.
As a ผู้อำนวยการ, I want to approve, return, or dismiss a case according to my authority, so that decisions follow the official chain.
As a เจ้าหน้าที่จัดวาระ, I want to prepare the meeting agenda and record the meeting decision, so that ordinary cases proceed through collective consideration.
As a ผู้อำนวยการ, I want to bypass the meeting agenda only when a mandatory reason is provided, so that urgent treatment remains exceptional and auditable.
As a รองอธิบดี, I want to review cases routed to my step, so that higher-level authorization is explicit.
As an อธิบดี, I want to make the final departmental decision on applicable cases, so that approval responsibility is traceable.
As a รัฐมนตรี, I want to review only petition types requiring ministerial approval, so that cases do not enter an unnecessary approval step.
As an approver, I want to return a case for correction with a recorded transition, so that the case owner can amend and resubmit without losing history.
As an approver, I want to dismiss or terminate a petition with a required reason, so that the outcome is distinguishable from a voluntary withdrawal.
As a เจ้าของสำนวน, I want to withdraw a petition under the ownership gate, so that withdrawal is not confused with an approver's dismissal decision.

Protection operations¶

As a เจ้าของสำนวน, I want an approved protection order to establish a protection round, so that dates, operations, and expenses have a clear business boundary.
As a เจ้าของสำนวน, I want an order extension to create a new protection round, so that repeated protection periods remain historically separate.
As a เจ้าหน้าที่คุ้มครอง, I want to record protection measures and field follow-up events, so that operational activity can be reviewed throughout the round.
As a เจ้าของสำนวน, I want protection duration to remain a discretionary date range, so that 30/60/90/120-day choices are shortcuts rather than a forced sequence.
As a เจ้าของสำนวน, I want to end protection through the governed workflow, so that the terminal status and summary are authoritative.
As a ผู้บริหาร, I want protection days and financial totals summarized at the end of protection, so that outcome reporting does not depend on manual recomputation.

Financial lifecycle — Phase 2-2¶

As a เจ้าของสำนวน, I want to create multiple estimate sheets within one protection round, so that separate estimate periods or purposes do not require creating a new round.
As a เจ้าของสำนวน, I want a new estimate sheet to start from an appropriate date while allowing an explicit override, so that drafting supports real operational timing.
As a เจ้าหน้าที่จัดทำประมาณการ, I want 30/60/90/120-day and custom-duration options, so that common periods are quick to enter without changing the underlying date-range truth.
As a เจ้าหน้าที่จัดทำประมาณการ, I want minimum-wage and province information applied only where the approved expense rules allow it, so that calculated estimates are consistent.
As a เจ้าหน้าที่การเงิน, I want to record actual expenses during the allowed protection lifecycle independently from approval-screen status, so that legitimate expense work is not blocked by an unrelated UI state.
As a เจ้าหน้าที่การเงิน, I want each actual expense linked to the selected estimate sheet, so that covered days and per-sheet variance can be calculated.
As a เจ้าหน้าที่การเงิน, I want the server to reject a closed, foreign-case, or tampered estimate-sheet reference, so that direct POST cannot bypass case boundaries.
As a เจ้าของสำนวน, I want an open estimate sheet to remain editable even after some actual expense exists, so that partial spending does not lock the whole round.
As a เจ้าของสำนวน, I want a sheet to close automatically when distinct covered calendar days reach the sheet duration, so that completion follows actual coverage rather than monetary amount.
As a เจ้าของสำนวน, I want overlapping expense date ranges counted once, so that covered days are not inflated.
As a เจ้าของสำนวน, I want an automatically closed sheet to reopen when linked covered days fall below its duration and the protection round is not terminal, so that corrections restore the correct state.
As a เจ้าหน้าที่การเงิน, I want a closed sheet visible for history but unavailable for new expense selection, so that auditability does not create a mutation path.
As a SpecialRole user, I want an explicitly audited bypass for approved exceptional corrections, so that rare remediation remains accountable.
As a ผู้บริหารงบประมาณ, I want closed-sheet estimates removed from outstanding estimate totals, so that remaining budget reflects only active commitments.
As a ผู้ตรวจสอบ, I want estimate-versus-actual variance calculated per sheet, so that one sheet cannot hide another sheet's variance.

Documents, identity, security, and integrations — Phase 2-3/2-4¶

As an เจ้าหน้าที่ผู้ลงนาม, I want to maintain an approved image signature and insert it into supported official documents, so that signing work is faster and traceable.
As an auditor, I want each signature insertion or removal recorded, so that document-signing actions can be investigated.
As a system user, I want centralized sign-in with controlled fallback, session, and role synchronization, so that identity is consistent across connected government systems.
As a security owner, I want confidential personal data protected with approved encryption and access controls, so that witness information is not exposed by legacy cryptography or authorization gaps.
As a system user, I want uploaded files size-checked, malware-scanned, and handled according to the approved compression/password rules, so that attachments do not become an attack or leakage path.
As an integration owner, I want petition and status exchanges to use agreed contracts, retries, timeouts, and data minimization, so that external outages do not silently lose updates.
As a ผู้บริหาร, I want dashboard KPIs to distinguish active, ended, withdrawn, dismissed, and bypassed cases, so that operational totals reconcile.
As a ผู้บริหาร, I want map, trend, budget, offense, organization, and witness views based on current governed data, so that decisions use a consistent picture.
As a ผู้ตรวจสอบ, I want report exports and sensitive dashboard actions audited, so that disclosure of confidential information can be traced.
As a เจ้าหน้าที่จัดทำรายงาน, I want official reports rendered with the approved Thai font and alignment behavior, so that deliverables meet document standards.
As a project owner, I want incomplete or externally blocked Phase 2 capabilities clearly marked, so that stakeholder presentations do not imply acceptance or production readiness.

Implementation Decisions¶

Phase 2 extends the existing ASP.NET Core MVC monolith and Razor UI. It does not introduce a React/Vite rewrite or a microservice decomposition. This follows ADR-001 and ADR-005.
The unit of case protection is the Protection Round. A new round is created by an approved order extension, not by a financial screen.
The unit of financial estimation is the Estimate Sheet. One protection round may contain multiple estimate sheets.
The workflow transition service is the authoritative mutation boundary for approval actions, role checks, transition validity, notifications, and audit entries.
Approval permission, case ownership permission, and notification routing remain separate concepts. A notification role must never be treated as an action permission.
The head-of-group step is controlled by configuration. The presentation must not state that the step is active in every environment merely because implementation exists.
Withdrawal and dismissal/termination are separate business outcomes with separate actors, permissions, reasons, audit actions, and dashboard implications.
Urgent meeting-agenda bypass is an alternative path from director consideration to deputy-director-general consideration and requires a reason, actor, timestamp, and audit evidence.
Existing witnesses and related persons are linked to cases through additive relationships rather than duplicated as new people.
Protection duration shortcuts calculate dates but do not encode a mandatory 60→90→120-day business sequence.
Actual-expense recording is governed by protection lifecycle and authorization rules, not by a browser-only approval-screen gate.
Estimate-sheet authorization is case-aware and must use persisted server-side identity and relationships instead of trusting identifiers submitted by the client.
Under ADR-007, estimate locking is per sheet, not per protection round. Monetary overspend does not close a sheet.
Covered Days are the union of valid linked actual-expense date ranges, inclusive of start and end dates. Overlaps are counted once; missing or invalid ranges contribute zero days.
Closed estimate sheets remain readable but cannot be edited, have rows deleted, be selected for a new actual expense, or be used for prefill by ordinary authorized users.
A day-closed sheet may reopen when covered days fall below its duration, except when the owning petition is already terminal or cannot be safely resolved.
SpecialRole bypass remains possible only with explicit audit evidence identifying the affected sheet and action.
The schema evolution strategy is additive-only. Phase 2 data relationships and audit structures must not remove or rename legacy fields.
Environment activation is distinct from code completion. Database migrations and deployment are human-controlled gates; a merged capability must not be presented as active on UAT until those gates are evidenced.
Dashboard, report, identity, encryption, upload, and external-integration requirements retain their blocked/partial status until their open questions and external dependencies are resolved.
Official specification statements use SRS v3.0.0 unless superseded by an accepted ADR or an approved meeting decision. Conflicts remain visible rather than silently normalized.

Testing Decisions¶

Primary acceptance seam¶

The preferred highest seam is the authenticated case-lifecycle boundary: exercise the real HTTP action as the relevant actor, then assert the externally observable status, available next actions, persisted business result, and audit record. This gives one common acceptance model across workflow and financial mutations without testing controller internals.

This seam is proposed for owner confirmation. The specification remains usable for presentation, but publication as ready-for-agent should wait until the owner confirms that this is the intended acceptance seam.

Supporting seams¶

Pure domain policies are tested with deterministic unit tests for state transitions, Covered Days, sheet closure/reopening, ownership, SpecialRole bypass, and invalid inputs.
Server-side guard tests send direct POST requests that omit, replace, or tamper with identifiers. A good negative test proves both the rejection and that persisted data did not change.
Browser tests cover the visible contract: buttons shown or hidden by actor/status, disabled closed-sheet controls, badges, progress, modal validation, navigation, and historical read-only access.
Persistence evidence verifies audit actions, actor identity, timestamps, sheet linkage, closure state, and budget recomputation using read-only checks only.
Document tests inspect generated Word/PDF output, signature placement, Thai fonts, and container rendering rather than asserting only that generation returned success.
Integration contract tests use mocks or approved non-production endpoints and verify timeout, retry, deduplication, redaction, and data minimization.
Regression acceptance requires Failed 0 and a passing count at least equal to the current develop baseline measured at execution time. No fixed test count is copied into this specification.
Runtime evidence is collected only after build freshness is proven; browser evidence must distinguish the deployed version from the local branch.

Prior art already exists in the repository for workflow transition contracts, direct-POST authorization proofs, estimate policy units, Covered Days units, source contracts, Playwright browser parts, document inspection, and guarded migration checks. These seams should be reused instead of adding parallel test frameworks.

Out of Scope¶

Rewriting the application in React/Vite or decomposing it into microservices.
Defining a new business rule for order-extension duration; duration remains officer discretion until an approved requirement says otherwise.
Treating a new estimate sheet as a new protection round.
Blocking actual expenses solely because their monetary total exceeds an estimate; ADR-007 does not define overspend as the sheet-closing condition.
Applying migrations, writing to any database, deploying, merging to develop, or creating/pushing a tag.
Claiming that Portal automation, ThaiD/MFA, AES-256 migration, malware scanning, E-AHT/IOT integration, real-time dashboard, report formats, screenshot prevention, or Thai Distribute behavior is complete without its own accepted evidence.
Resolving Q-022 or any other open requirement question in this document.
Publishing this specification to an issue tracker until the tracker and triage-label vocabulary are configured.

Further Notes¶

Presentation narrative¶

Begin with the citizen/petition path and state that the business objective is safe, governed protection—not document processing alone.
Explain the distinction between petition, protection round, estimate sheet, and actual expense before showing Phase 2-2.
Highlight Phase 2-1 as the governance layer: explicit actors, transitions, reasons, ownership, and audit.
Highlight Phase 2-2 as a shift from round-level locking to sheet-level Covered Days under ADR-007.
End with the delivery truth: green capabilities have evidence, amber capabilities are partial, and locked capabilities require decisions, dependencies, migration, deployment, or UAT.

Phase 2 traceability map¶

Requirement	Presentation label	Current truth
WIT-001	Portal intake + automatic case number	Existing intake functions are substantial, but automation and safe numbering remain blocked
WIT-002	e-Signature	Word-path implementation is substantial; remaining document/container/PDF gates prevent full closure
WIT-003	SSO/OTP/lockout/session	Work exists, but coverage and governance are incomplete
WIT-004	Six-level workflow, assignment, withdrawal/dismissal, end summary	Main Phase 2-1 capability implemented; Q-022 can cause rework
WIT-005	Real-time dashboard and map	Existing dashboard plus partial KPI improvement; remainder incomplete
WIT-006	Financial lifecycle	Multiple increments implemented; overall requirement remains partial
WIT-007	AES-256, MFA, E-AHT	Not complete; high-risk legacy/security and dependency work remains
WIT-008	Upload, compression, malware scan	Upload exists; required controls remain blocked/incomplete
WIT-009	Four report types	Blocked by report-format decisions
WIT-010	IOT API within one minute with retry	Existing synchronous integration is insufficient; contract dependency remains
WIT-011	Urgent agenda bypass	Implemented with mandatory reason and audit
WIT-012	Link witnesses/related persons	Implemented with additive relationships
WIT-013	Official document formatting	Thai font work exists; full formatting requirement remains incomplete

Assumptions¶

“Phase 2” means the contract Phase 2 scope represented by WIT-001…WIT-013, subdivided by the approved delivery plan into Phase 2-1…2-4.
“Core Business” means the enduring end-to-end protection lifecycle, not a claim about which release first introduced each screen.
Status is reported from the repository at develop@59b8f62; uncommitted files in the primary checkout are excluded from this specification.
The newest accepted decision overrides older conflicting behavior only within its declared scope; ADR-007 therefore overrides the earlier round-level estimate-lock behavior.
The interactive Flow intentionally keeps node copy short for projection readability; this document carries the full business detail.

Evidence¶

หลักฐานทั้งหมดอยู่ใน repo witness-protection-info-system (baseline develop@59b8f62) — path ด้านล่างอ้างอิงภายใน repo นั้น ไม่ใช่ใน Knowledge Base นี้

หลักฐาน	Path ใน repo
Domain glossary	`CONTEXT.md`
Phase 2 traceability matrix	`docs/ai/TRACEABILITY_MATRIX.md`
Phase 2C implementation plan	`docs/PHASE2C_IMPLEMENTATION_PLAN.md`
MVP1 role and workflow evidence	`docs/archive/work-orders/MVP1-ROLE-FLOW.md`
ADR-001 — extend MVC	`docs/adr/ADR-001-extend-mvc-no-react-rewrite.md`
ADR-005 — current architecture wins	`docs/adr/ADR-005-srs-v3-techstack-mismatch-keep-mvc.md`
ADR-007 — close estimate sheets by Covered Days	`docs/adr/ADR-007-estimate-sheet-lock-by-days-per-mom-mvp1-r1.md`
Work-order index	`docs/work-orders/README.md`
WO-2C-022 — estimate-sheet lock by days	`docs/work-orders/WO-2C-022-estimate-sheet-lock-by-days.md`
SRS v3.0.0 working copy	`docs/srs/SRS-S7-WPIS-v3.0.0.md`
MOM-MVP1-R1 working copy	`docs/srs/MOM-MVP1-R1-S7-WPIS-v1.0.0.md`

Risks¶

Q-022 may change actor naming and meeting responsibilities in the workflow presentation.
A capability can be merged but absent from UAT until its migration and deployment gates are completed; WO-2C-022 is the current material example.
WIT-006 has many completed increments, but presenting it as fully complete would overstate the RTM.
External dependencies block material Phase 2-4 scope, including identity, malware scanning, and integrations.
SRS architecture text conflicts with the accepted implementation architecture; ADR-005 is an internal decision and does not replace formal customer acceptance of the deviation.
Screenshot prevention and Thai Distribute requirements may not be technically achievable as literally written and require recorded acceptance criteria.
This document summarizes confidential-domain workflows and must not include real witness identities, credentials, production endpoints, or production evidence.

Tests run¶

Repository evidence was read and cross-checked across glossary, SRS working copy, RTM, accepted ADRs, work orders, and representative implementation seams.
The Archify workflow specification was validated with showcase quality: all 9 artifact checks passed, with 0 composition errors and 0 warnings.
Automated containment and readability passed at 1440×900, 1600×1000, 1920×1080, and 2048×1320 in the required viewer states.
Light and dark screenshots at 1440×900 and 2048×1320 were visually inspected; labels, status markers, routes, legend, and first-screen balance passed after two focused correction rounds.
No application build, unit test suite, browser test, database query, migration, or network call was required for this documentation-only change.

Remaining work¶

Confirm the proposed authenticated case-lifecycle acceptance seam before labeling the spec ready-for-agent.
Configure the project issue tracker and triage vocabulary, then publish this specification with the ready-for-agent label.
Reconcile Q-022 before using actor labels as contractual acceptance language.
Complete human-controlled migration/deployment/UAT gates before changing any ✅*, ◐, or 🔒 status in presentations.