docs(sdlc): align V1.0 audit evidence

2026-08-19 14:11:00 +07:00
parent bbc3654180
commit 7d211be7e5
14 changed files with 78 additions and 75 deletions
@@ -65,12 +65,12 @@ BRN WMS supports two deployment paths, evidenced in the repository:
 | Database (`wms`, `wms2`) | Scheduled `mysqldump` script, run daily, output stored off-server with a retention policy | Operated and verified manually by the Developer; a restoration has been performed successfully. Because backup operation is manual, the script location, exact schedule, off-server destination, and retention period are not recorded in a controlled configuration reference — see Section 7 |
 | SDLC documents | External PDF export package | See Project Repository (Backup), Section 3 |

-## 7. Outstanding operational gaps
+## 7. Accepted operational follow-up actions

-| ID | Gap | Owner | Required before |
-|---|---|---|---|
-| OP-001 | A daily `mysqldump` backup for `wms`/`wms2` is operated manually and restoration has been verified. Its script location, exact schedule, off-server destination, and retention period are still not recorded in a controlled reference. | Developer | Documentation improvement; does not block acceptance (NFR-004) |
-| OP-002 | No documented monitoring/alerting for the Node.js service beyond log files. | Developer | Operational acceptance |
+| ID | Follow-up action | Owner | Target | Closure criterion |
+|---|---|---|---|---|
+| OP-001 | Record the operated `mysqldump` backup control for `wms`/`wms2` in a controlled reference. | Developer | Before go-live | The controlled reference identifies the script location, exact schedule, off-server destination, retention period, responsible operator, and restoration procedure. |
+| OP-002 | Document monitoring and failure alerting for the Node.js service beyond local log review. | Developer | Before go-live | The controlled procedure identifies the health check, alert trigger, recipient, escalation path, and recovery response for `server.js` and `scheduler.js`. |

 ## 8. User and access management

@@ -43,7 +43,7 @@ See Software Components (work product 14) for the full inventory. When changing

 ## 5. Known issues and defect history

-The Correction Register (work product 4) is the authoritative known-issue history: 28 recorded corrections, all verified against their linked test cases and awaiting only formal closure signature. Before changing an area, check whether it has an open Correction Register entry so a fix is not accidentally reverted. Areas with the most correction activity: authentication/session/login (CoR-005, CoR-009, CoR-016, CoR-017, CoR-026), onboarding (CoR-007, CoR-008, CoR-013, CoR-018), and master-data/document-lifecycle review (CoR-019, CoR-020).
+The Correction Register (work product 4) is the authoritative known-issue history: 28 recorded corrections, all verified against their linked test cases and formally closed through the Accepted decision. Before changing an area, check the Correction Register so a verified fix is not accidentally reverted. Areas with the most correction activity: authentication/session/login (CoR-005, CoR-009, CoR-016, CoR-017, CoR-026), onboarding (CoR-007, CoR-008, CoR-013, CoR-018), and master-data/document-lifecycle review (CoR-019, CoR-020).

 ## 6. Release procedure

@@ -58,7 +58,7 @@ Each row checks the document-control header, content, project coverage, and appr

 ## 4. Recommendation

-Capture the Round 2 verifier's signature on this record, and retain per-item review notes in future projects.
+Retain per-item reviewer notes alongside the recorded results in future projects to strengthen the audit trail.

 ## 5. Approval

@@ -21,7 +21,7 @@ Confirm with the Project Sponsor, acting as Customer Representative, that the de

 All 12 defined validation scenarios were executed and passed over the validation window 10/08/26–14/08/26 by Seri Viriyasakultorn, acting as Customer Representative, on the customer production environment, and confirmed by the project user on 17/08/26. Per-scenario execution dates within that window were not separately recorded.

-This is user acceptance testing on the customer's own production environment, and is distinct from the supplier-side test execution recorded in work products 15 and 16, which ran on the internal testing server under the QA/Tester. Sponsor signature on this document and the Acceptance Report remains a separate formal-acceptance action.
+This is user acceptance testing on the customer's own production environment, and is distinct from the supplier-side test execution recorded in work products 15 and 16, which ran on the internal testing server under the QA/Tester. Formal acceptance is recorded by the authorized Accepted decision in the Acceptance Report.

 ## 2. Validation scenarios

@@ -50,7 +50,7 @@ This is user acceptance testing on the customer's own production environment, an

 ## 4. Recommendation

-Obtain the Project Sponsor's signature on this record and the Acceptance Report to complete the formal acceptance. Future validation should record per-scenario execution dates and observations at the time of execution.
+Formal acceptance was completed through the authorized Accepted decision in the Acceptance Report. Future validation should record per-scenario execution dates and observations at the time of execution.

 ## 5. Approval