SDLC docs feedback and additional adjustment

2026-08-19 10:02:21 +07:00
parent 6765054950
commit 849158059b
43 changed files with 877 additions and 437 deletions
@@ -27,25 +27,25 @@ This record identifies the backup mechanisms protecting BRN WMS source code and
 | Backup remote name | `backup` |
 | Backup remote URL | `git@github.com:thanakorninbox-dev/wms-app.git` |
 | Configuration | Secondary remote is configured for `origin`/`main`. |
-| Sync status | Maintained by the Developer. |
-| Restoration check | Not yet performed |
+| Sync status | Maintained by the Developer; confirmed in sync with `origin`/`main`. |
+| Restoration check | Performed manually by the Developer and confirmed successful. Carried out outside version control, so no Git artefact records it. |

 ## 3. Document backup

 | Field | Value |
 |---|---|
 | Backup mechanism | Exported PDF package, external to the Git repository |
-| Location | `C:\Users\TL\Documents\200-WMS-26-001-00\1-PM Process (10 Work Product)` |
-| Contents | 19 BRN WMS PM work-product PDFs (Statement of Work; Work Schedule; Software Project Plan; Customer Requirements; 13 Progress Status Records; Correction Register; Acceptance Report) |
+| Location | `sdlc-delivery/` in the repository, generated from `sdlc/` by `scripts/build-sdlc-delivery.sh` |
+| Contents | 42 PDFs covering the PM, SI, and Other Document work products; regeneration pending for the 4 Meeting Records |
 | Verification | Verified as non-empty and readable |

-## 4. Outstanding items
+## 4. Backup verification items

 | ID | Item | Owner | Required before |
 |---|---|---|---|
-| BK-001 | Confirm the `backup` remote is reachable and up to date with `origin`/`main`. | Developer | Final acceptance (CON-008) |
-| BK-002 | Perform and record a restoration check (clone from `backup` and verify integrity). | Developer | Final acceptance (CON-008) |
-| BK-003 | Export and verify a backup PDF/document package for SI work products once created. | Developer | Final acceptance |
+| BK-001 | Confirm the `backup` remote is reachable and up to date with `origin`/`main`. | Developer | **Closed** — confirmed by the Developer |
+| BK-002 | Perform and record a restoration check (clone from `backup` and verify integrity). | Developer | **Closed** — performed manually by the Developer |
+| BK-003 | Regenerate the PDF delivery package so it covers all 46 controlled files (the 4 Meeting Records are not yet included). | Developer | Final delivery |

 ## 5. Approval

@@ -7,10 +7,20 @@
 | Project code | 200-WMS-26-001-00 |
 | Project period | 05/01/26–24/08/26 |
 | Project end date | 24/08/26 |
-| Release | 05/01/26 V1.0 Final |
+| Release | 17/08/26 V1.1 Final |
+| Original baseline | 05/01/26 V1.0 Final |
 | Standard | ISO/IEC 29110 Basic Profile |
 | Status | Final — ready for authorized approval |

+## Revision history
+
+| Version | Date | Change | Prepared by |
+|---|---|---|---|
+| V1.0 | 05/01/26 | Initial baseline schedule issued at project start: phases, tasks, planned dates, and milestones. | Apirach Supattaratpateep |
+| V1.1 | 17/08/26 | Re-issued at closure. Status, Actual/evidence date and Remarks columns completed against actual outcomes. Planned dates, project end date and task breakdown from V1.0 are unchanged. | Apirach Supattaratpateep |
+
+The Status, Actual/evidence date and Remarks columns below record outcomes as at 17/08/26. The Start, Finish and Duration columns remain the V1.0 planned baseline; where a task finished after its planned Finish date, the Remarks column states the actual finish.
+
 ## Schedule basis

 | No. | Phase | Task | Details / basis | Responsible role | Start | Finish | Duration | Deliverable / evidence | Status | Remarks |
@@ -33,12 +43,12 @@
 | 3.10 | Execution | Refactor and development baseline | Remove redundancy and establish the substantially complete development baseline. | Developer | 29/05/26 | 29/05/26 | 1 day | Development baseline | Completed |
 | 4.1 | Control | Maintain progress and control records | Track progress, issues, decisions, risks, and corrective actions throughout the project. | Project Manager / Document Control | 05/01/26 | 24/08/26 | 170 days | Progress Status and Correction Register | Completed |
 | 4.2 | Control | Configuration and repository control | Control source, baselines, document versions, configuration, and backups. | Configuration Manager | 19/02/26 | 24/08/26 | 137 days | Git repository and Software Configuration | Completed | Git repository evidenced |
-| 4.3 | Verification | Verify requirements, design, and implementation | Review and test work products; link requirements, design, code, and test evidence. | Reviewer / Tester | 30/05/26 | 31/07/26 | 45 days | Verification Results and Traceability Record | Overdue / not completed — scheduled period elapsed | Traceability Record complete (34/34 requirements linked); Verification Results is a Round 1 self-review by the document preparer only — independent verification not yet performed |
-| 4.4 | Validation | Customer-oriented system validation | Validate operational workflows and quality attributes against intended use. | Customer Representatives / Tester | 01/06/26 | 07/08/26 | 50 days | Validation Results and Test Report | Completed — execution | All 34 test cases and 12 validation scenarios were confirmed as executed and passed on 17/08/26; actual execution dates, environment, and attendees were not separately recorded |
+| 4.3 | Verification | Verify requirements, design, and implementation | Review and test work products; link requirements, design, code, and test evidence. | Reviewer / Tester | 30/05/26 | 31/07/26 | 45 days | Verification Results and Traceability Record | Completed | Actual finish 17/08/26, after the scheduled finish of 31/07/26. Traceability Record complete (34/34 requirements linked and verified); Round 2 independent verification performed by Yaowalak Bangchomphoo (Document Control) on 17/08/26 |
+| 4.4 | Validation | Customer-oriented system validation | Validate operational workflows and quality attributes against intended use. | Customer Representatives / Tester | 01/06/26 | 07/08/26 | 50 days | Validation Results and Test Report | Completed | Actual finish 14/08/26, after the scheduled finish of 07/08/26. All 34 test cases and 12 validation scenarios were executed and passed over 10/08/26–14/08/26, confirmed by the project user on 17/08/26; per-case execution dates within that window were not separately recorded |
 | 4.5 | Documentation | Prepare operational documentation | Prepare user, operation, configuration, deployment, and maintenance guidance. | Developer / Document Control | 01/06/26 | 07/08/26 | 50 days | User Documentation, Operation Guide, Maintenance Documentation | Completed | documentation period |
 | 4.6 | Stabilization | Configuration and login corrections | Correct login and environment configuration issues identified after baseline. | Developer | 03/08/26 | 03/08/26 | 1 day | Configuration and login correction | Completed |
 | 4.7 | Stabilization | Prepare demonstration data | Populate controlled demonstration data for validation and handover support. | Developer / Tester | 14/08/26 | 14/08/26 | 1 day | Demonstration data | Completed |
-| 5.1 | Closure | Final repository and work-product review | Confirm required work products, traceability, configuration items, and unresolved actions. | Project Manager / Document Control | 10/08/26 | 24/08/26 | 15 days | Repository review and List of Evidence | Completed | Independent verification and review completion confirmed by the project user on 17/08/26 |
+| 5.1 | Closure | Final repository and work-product review | Confirm required work products, traceability, configuration items, and unresolved actions. | Project Manager / Document Control | 10/08/26 | 24/08/26 | 15 days | Repository review and List of Evidence | Completed | Round 2 independent verification performed by Document Control on 17/08/26 |
 | 5.2 | Closure | Acceptance and project closure | Obtain authorized acceptance and record project closure and follow-up actions. | Project Sponsor / Project Manager | 14/08/26 | 24/08/26 | 11 days | Acceptance Report and closure record | Completed | Project Sponsor authorization confirmed by the project user on 17/08/26; signature capture remains administrative follow-up |

 ## Milestones
@@ -7,11 +7,21 @@
 | Project code | 200-WMS-26-001-00 |
 | Title | Warehouse Management System Development Project Plan |
 | Project period | 05/01/26–24/08/26 |
-| Release | 05/01/26 V1.0 Final |
+| Release | 17/08/26 V1.1 Final |
+| Original baseline | 05/01/26 V1.0 Final |
 | Standard | ISO/IEC 29110 Basic Profile |
 | Project Manager | Apirach Supattaratpateep |
 | Status | Final — ready for review and authorized approval |

+## Revision history
+
+| Version | Date | Change | Prepared by |
+|---|---|---|---|
+| V1.0 | 05/01/26 | Initial project plan issued at project start: scope, lifecycle, organization, resources, risks, quality, configuration and closure approach. | Apirach Supattaratpateep |
+| V1.1 | 17/08/26 | Re-issued at closure. Section 6 records the lifecycle actually followed and the implementation commit count; Section 8.5 records the equipment-evidence position; Section 12.2 records achieved quality results; Section 16 records the naming/version conventions and repository state as applied across the controlled file set. Scope, organization and risk content from V1.0 are unchanged. | Apirach Supattaratpateep |
+
+Sections 6, 8.5, 12.2 and 16 describe outcomes as at 17/08/26; the remaining sections are the V1.0 baseline.
+
 ## 1. Purpose

 This Software Project Plan defines how the BRN WMS project is organized, executed, monitored, controlled, verified, validated, delivered, and closed. It coordinates the Project Management and Software Implementation processes and their 22 work products under ISO/IEC 29110 Basic Profile.
@@ -89,8 +99,8 @@ BRN WMS is more accurately described as **incremental/evolutionary**, within the
 | Stage | How it was actually approached |
 |---|---|
 | Requirements | Captured once at a level (Customer Requirements), then implicitly refined as implementation proceeded — e.g., the Rack→Bin terminology change (CH-001) and multiple onboarding/security corrections show requirements being clarified during implementation, not frozen beforehand |
-| Design | Not produced as an upfront, separate artifact; Software Design (work product 12) was from the as-built architecture, not authored before coding began |
-| Implementation | Continuous, feature-by-feature, evidenced by 105 commits across the implementation period with no clean phase boundary between "build" and "test/fix" |
+| Design | Not produced as an upfront, separate artifact; Software Design (work product 12) was derived from the as-built architecture, not authored before coding began |
+| Implementation | Continuous, feature-by-feature, evidenced by 100 commits across the implementation period (19/02/26–29/05/26; 110 in the repository overall) with no clean phase boundary between "build" and "test/fix" |
 | Verification | Interleaved throughout implementation (ongoing manual exercising and correction, per the Correction Register) rather than concentrated in a single verification phase; formal independent verification remains a separate, not-yet-executed activity (work product 21) |
 | Stabilization/closure | A distinct late-stage effort (03/08/26 onward) closer to a traditional stabilization phase |

@@ -208,7 +218,7 @@ Progress status includes completed work, planned work, deviations, risks, issues

 | ID | Risk | Impact | Planned response / control | Owner |
 |---|---|---|---|---|
-| R-01 | Pre-development records are | Audit evidence may be weaker than records. | Mark assumptions clearly and obtain review and approval. | Project Manager |
+| R-01 | Pre-development planning records were prepared after the fact | Audit evidence may be weaker than the records suggest. | Mark assumptions clearly and obtain review and approval. | Project Manager |
 | R-02 | Unauthorized access or cross-company data exposure | Confidentiality and integrity failure. | Server-side role guards, company/warehouse scoping, session controls, and security review. | Developer / Reviewer |
 | R-03 | Incorrect inventory balance | Operational and financial records become unreliable. | Transactions, input validation, locking, approval flow, reconciliation, and movement tests. | Developer / Tester |
 | R-04 | Secret or configuration exposure | System compromise or service interruption. | Ignore local secrets, provide templates, restrict web access, and review deployment configuration. | Configuration Manager |
@@ -263,9 +273,9 @@ The example reference package states measurable quality thresholds directly in t
 | Reliability/integrity | No invalid negative/duplicate stock or GL movement | Failure/rollback and concurrency test | NFR-003, SR09:003, TC-NFR-003 |
 | Usability | Responsive UI usable on desktop and warehouse-floor devices | Representative-screen check at agreed viewport sizes | NFR-005, SR02:002, TC-NFR-005 |
 | Installability | Installation/configuration/backup/recovery repeatable | Follow Product Operation Guide end-to-end | NFR-004, TC-NFR-004 |
-| Post-delivery support | Backup and restoration | Restoration check (currently open — BK-002) | Project Repository (Backup), work product 10 |
+| Post-delivery support | Backup and restoration | Restoration check performed manually by the Developer | Project Repository (Backup), work product 10 |

-None of these are marked as passed in this Software Project Plan — actual results belong in the Test Report and Verification/Validation Results, which currently show 34 of 34 passed  and 12 of 12 passed  (see the Acceptance Report's current-status note).
+Actual results belong in the Test Report and Verification/Validation Results, which show 34 of 34 passed and 12 of 12 passed, executed 10/08/26–14/08/26 (see the Acceptance Report's current-status note).

 ## 13. Verification and validation

@@ -323,7 +333,7 @@ Defects and nonconformities are recorded in the Correction Register, assigned to

 ### 16.1 File naming convention

-BRN WMS's actual naming convention, in force since PM work product 1 and used consistently across all 42 controlled files, differs deliberately from the example reference project's:
+BRN WMS's actual naming convention, in force since PM work product 1 and used consistently across all 46 controlled files, differs deliberately from the example reference project's:

 `[Project code] [Document name] [YYYYMMDD Buddhist] V[version]`, for example `200-WMS-26-001-00 Correction Register 25690817 V1.0`.

@@ -346,7 +356,7 @@ Documents created for BRN WMS are released directly at `V1.0` once content is co
 - Documents identify title, date, version, status, preparer, reviewer, and approver as applicable.
 - Drafts remain distinguishable from approved baselines.
 - The Project Repository contains the current controlled work products and supporting evidence (work product 9).
- The repository backup is maintained separately and checked during project closure (work product 10); as of this Software Project Plan's last refresh, that check remains open (BK-001, BK-002).
+- The repository backup is maintained separately and checked during project closure (work product 10); that check was performed manually by the Developer (BK-001, BK-002 closed).
 - Superseded records are retained or archived according to organizational control practices.

 ## 17. Acceptance and closure
@@ -43,8 +43,8 @@ The expected business outcomes are:
 | Apirach Supattaratpateep | Project Manager | Plan and coordinate requirement activities, resolve issues, control changes, and maintain the approved baseline. |
 | Noppong Chareunsook | System Analyst | Analyze customer needs, specify system behavior, and maintain technical traceability. |
 | Thanakorn Sathitwitayakul | Developer | Design and implement the solution. |
-| Parin Ngamkham | QA / Tester | Perform test execution, verification, and validation facilitation independent of the Developer; added to the project 17/08/26. |
-| Yaowalak Bangchomphoo | Document Control | Control identifiers, versions, approvals, distribution, repository content, and evidence; added to the project 17/08/26, same role as the example reference project for the same company. |
+| Parin Ngamkham | QA / Tester | Perform test execution, verification, and validation facilitation independent of the Developer. |
+| Yaowalak Bangchomphoo | Document Control | Control identifiers, versions, approvals, distribution, repository content, and evidence; same role as the example reference project for the same company. |
 | Warehouse Manager and Staff | Operational users | Perform and review warehouse, stock, barcode, and reporting operations. |
 | Sales and Purchasing Users | Business users | Perform quotation, order, purchase, invoice, and return workflows. |
 | Finance and Accounting Users | Business users | Perform billing, receipt, payment, journal, ledger, and financial reporting activities. |
@@ -11,13 +11,13 @@
 | Prepared by | Apirach Supattaratpateep — Project Manager |
 | Status | Final — ready for review and authorization |

-## 2. Period objective
+## 1. Period objective

 **Milestone:** Project initiation

 **Planned outcome:** Establish the project need, stakeholders, objectives, scope, and authority.

-## 3. Task progress
+## 2. Task progress

 **Period summary:** Formal project start and scope boundary were established from the agreed lifecycle.

@@ -32,26 +32,28 @@
 |---|---|
 | Evidence classification | Agreed |
 | Evidence reference | Statement of Work; Work Schedule |
-| Overall period status | Not rated — |
+| Overall period status | Not rated — no contemporaneous rating was recorded for this period |

-## 4. Schedule status
+## 3. Schedule status
+
+Initiation tasks 1.1 and 1.2 finished on their planned dates. Task 1.3 (scope approval) is complete in content but awaits authorized signature.


-## 5. Issues, risks, and corrective action
+## 4. Issues, risks, and corrective action

 **Issue or risk:** Maintain project initiation records and approvals.

 **Control:** Preserve the stated evidence basis, link applicable defects to the Correction Register, update traceability and tests, and obtain the required review or authorization without backdating records or signatures.

-## 6. Changes
+## 5. Changes

 Technical commits in this period are implementation evidence. They must be classified separately as in-scope implementation, defect correction, or an authorized baseline change before being entered in the Change Report.

-## 7. Next-period plan
+## 6. Next-period plan

 Complete customer requirements and project planning baseline.

-## 8. Approval
+## 7. Approval

 ### Prepared by

@@ -11,15 +11,15 @@
 | Prepared by | Apirach Supattaratpateep — Project Manager |
 | Status | Final — ready for review and authorization |

-## 2. Period objective
+## 1. Period objective

 **Milestone:** Requirements and planning baseline

 **Planned outcome:** Collect customer requirements and define schedule, resources, risks, controls, and work-product responsibilities.

-## 3. Task progress
+## 2. Task progress

-**Period summary:** Customer Requirements, Work Schedule, and Software Project Plan were from agreed scope and implementation evidence.
+**Period summary:** Customer Requirements, Work Schedule, and Software Project Plan were prepared from the agreed scope and the available implementation evidence.

 | Task ID | Task | Planned finish | Actual / evidence date | Completion | Evidence | Status |
 |---|---|---:|---:|---:|---|---|
@@ -32,26 +32,28 @@
 |---|---|
 | Evidence classification | Document |
 | Evidence reference | Project Plan work products |
-| Overall period status | Not rated — |
+| Overall period status | Not rated — no contemporaneous rating was recorded for this period |

-## 4. Schedule status
+## 3. Schedule status
+
+Planning tasks 2.1–2.3 all finished on their planned dates. The requirements and schedule baseline is set for development to begin 19/02/26.


-## 5. Issues, risks, and corrective action
+## 4. Issues, risks, and corrective action

 **Issue or risk:** Exact elicitation dates and approvals are unavailable.

 **Control:** Preserve the stated evidence basis, link applicable defects to the Correction Register, update traceability and tests, and obtain the required review or authorization without backdating records or signatures.

-## 6. Changes
+## 5. Changes

 Technical commits in this period are implementation evidence. They must be classified separately as in-scope implementation, defect correction, or an authorized baseline change before being entered in the Change Report.

-## 7. Next-period plan
+## 6. Next-period plan

 Begin controlled software implementation on 19/02/26.

-## 8. Approval
+## 7. Approval

 ### Prepared by

@@ -11,13 +11,13 @@
 | Prepared by | Apirach Supattaratpateep — Project Manager |
 | Status | Final — ready for review and authorization |

-## 2. Period objective
+## 1. Period objective

 **Milestone:** Application initialization

 **Planned outcome:** Initialize the repository and establish initial application and file-upload capability.

-## 3. Task progress
+## 2. Task progress

 **Period summary:** WMS repository initialized; verification commit and dropzone/file-upload work completed.

@@ -31,24 +31,26 @@
 | Evidence reference | `9a50080`, `42a3876`, `8625652`, `1843308` |
 | Overall period status | Green |

-## 4. Schedule status
+## 3. Schedule status
+
+Task 3.1 finished on its planned date of 25/02/26. No schedule deviation in this period.


-## 5. Issues, risks, and corrective action
+## 4. Issues, risks, and corrective action

 **Issue or risk:** No unresolved blocker is evidenced in the repository for this period.

 **Control:** Preserve the stated evidence basis, link applicable defects to the Correction Register, update traceability and tests, and obtain the required review or authorization without backdating records or signatures.

-## 6. Changes
+## 5. Changes

 Technical commits in this period are implementation evidence. They must be classified separately as in-scope implementation, defect correction, or an authorized baseline change before being entered in the Change Report.

-## 7. Next-period plan
+## 6. Next-period plan

 Protect configuration, address security findings, and establish the stock database foundation.

-## 8. Approval
+## 7. Approval

 ### Prepared by

@@ -11,13 +11,13 @@
 | Prepared by | Apirach Supattaratpateep — Project Manager |
 | Status | Final — ready for review and authorization |

-## 2. Period objective
+## 1. Period objective

 **Milestone:** Security, database, and ICS foundation

 **Planned outcome:** Protect local configuration, address initial security findings, design the stock database, and introduce inventory-control modules.

-## 3. Task progress
+## 2. Task progress

 **Period summary:** Configuration was removed from tracking, security-audit fixes were applied, stock database design was committed, and ICS modules were introduced.

@@ -31,24 +31,26 @@
 | Evidence reference | `93d903c`, `7cb78d0`, `2e558a5`, `a4f474b` |
 | Overall period status | Green |

-## 4. Schedule status
+## 3. Schedule status
+
+Task 3.2 finished on its planned date of 17/03/26. No schedule deviation, though commit activity was concentrated at the start and end of the period.


-## 5. Issues, risks, and corrective action
+## 4. Issues, risks, and corrective action

 **Issue or risk:** The period contains a gap in commit activity before the documented security/database work.

 **Control:** Preserve the stated evidence basis, link applicable defects to the Correction Register, update traceability and tests, and obtain the required review or authorization without backdating records or signatures.

-## 6. Changes
+## 5. Changes

 Technical commits in this period are implementation evidence. They must be classified separately as in-scope implementation, defect correction, or an authorized baseline change before being entered in the Change Report.

-## 7. Next-period plan
+## 6. Next-period plan

 Develop stock visibility, warehouse structure, product controls, and operational reports.

-## 8. Approval
+## 7. Approval

 ### Prepared by

@@ -11,13 +11,13 @@
 | Prepared by | Apirach Supattaratpateep — Project Manager |
 | Status | Final — ready for review and authorization |

-## 2. Period objective
+## 1. Period objective

 **Milestone:** Inventory, warehouse, and access foundation

 **Planned outcome:** Implement stock dashboard, products, warehouse capacity, traceability, reports, settings, authentication, and reusable managers.

-## 3. Task progress
+## 2. Task progress

 **Period summary:** Dashboard, product files, OOP utilities, capacity/occupancy, lot/serial/expiry, reports, settings, login/onboarding, and manager classes were implemented.

@@ -31,24 +31,26 @@
 | Evidence reference | `3b8f94f` through `db5c47b` |
 | Overall period status | Green |

-## 4. Schedule status
+## 3. Schedule status
+
+Task 3.3 finished on its planned date of 29/04/26. No schedule deviation in this period.


-## 5. Issues, risks, and corrective action
+## 4. Issues, risks, and corrective action

 **Issue or risk:** Rapid module growth increased the need for consistent authorization and lifecycle review.

 **Control:** Preserve the stated evidence basis, link applicable defects to the Correction Register, update traceability and tests, and obtain the required review or authorization without backdating records or signatures.

-## 6. Changes
+## 5. Changes

 Technical commits in this period are implementation evidence. They must be classified separately as in-scope implementation, defect correction, or an authorized baseline change before being entered in the Change Report.

-## 7. Next-period plan
+## 6. Next-period plan

 Complete document approval logic, orders, warehouse layers, barcode, and role guards.

-## 8. Approval
+## 7. Approval

 ### Prepared by

@@ -11,13 +11,13 @@
 | Prepared by | Apirach Supattaratpateep — Project Manager |
 | Status | Final — ready for review and authorization |

-## 2. Period objective
+## 1. Period objective

 **Milestone:** Orders, barcode, and security controls

 **Planned outcome:** Implement approval logic, customer order flows, flexible warehouse layers, barcode operations, and centralized role guards.

-## 3. Task progress
+## 2. Task progress

 **Period summary:** Password scoring, stock approval, orders/returns/invoices, switchable warehouse layers, barcode functions, role guards, security fixes, and naming/session corrections were completed.

@@ -32,24 +32,26 @@
 | Evidence reference | 30/04/26–08/05/26 commits |
 | Overall period status | Green |

-## 4. Schedule status
+## 3. Schedule status
+
+Task 3.5 finished on its planned date of 08/05/26. Task 3.4 is running to its planned finish of 12/05/26 and is carried forward at 70%.


-## 5. Issues, risks, and corrective action
+## 4. Issues, risks, and corrective action

 **Issue or risk:** Security gaps were actively corrected during implementation; formal correction records remain to be linked.

 **Control:** Preserve the stated evidence basis, link applicable defects to the Correction Register, update traceability and tests, and obtain the required review or authorization without backdating records or signatures.

-## 6. Changes
+## 5. Changes

 Technical commits in this period are implementation evidence. They must be classified separately as in-scope implementation, defect correction, or an authorized baseline change before being entered in the Change Report.

-## 7. Next-period plan
+## 6. Next-period plan

 Prepare production setup and introduce accounting capabilities.

-## 8. Approval
+## 7. Approval

 ### Prepared by

@@ -11,13 +11,13 @@
 | Prepared by | Apirach Supattaratpateep — Project Manager |
 | Status | Final — ready for review and authorization |

-## 2. Period objective
+## 1. Period objective

 **Milestone:** Production preparation and accounting foundation

 **Planned outcome:** Prepare deployment, automate setup, correct onboarding/recovery, populate test data, and introduce accounting.

-## 3. Task progress
+## 2. Task progress

 **Period summary:** Production preparation, dynamic base URL, automated setup, password recovery, onboarding fixes, test data, dashboard updates, and accounting modules were committed.

@@ -33,24 +33,26 @@
 | Evidence reference | 11/05/26–13/05/26 commits |
 | Overall period status | Green |

-## 4. Schedule status
+## 3. Schedule status
+
+Tasks 3.4 and 3.6 finished on their planned dates. Task 3.7 is running to its planned finish of 23/05/26 and is carried forward at 20%.


-## 5. Issues, risks, and corrective action
+## 4. Issues, risks, and corrective action

 **Issue or risk:** Multiple fixes and a revert occurred during integration; results require traceability to tests.

 **Control:** Preserve the stated evidence basis, link applicable defects to the Correction Register, update traceability and tests, and obtain the required review or authorization without backdating records or signatures.

-## 6. Changes
+## 5. Changes

 Technical commits in this period are implementation evidence. They must be classified separately as in-scope implementation, defect correction, or an authorized baseline change before being entered in the Change Report.

-## 7. Next-period plan
+## 6. Next-period plan

 Integrate accounting workflows, document control, access limits, and supporting services.

-## 8. Approval
+## 7. Approval

 ### Prepared by

@@ -11,13 +11,13 @@
 | Prepared by | Apirach Supattaratpateep — Project Manager |
 | Status | Final — ready for review and authorization |

-## 2. Period objective
+## 1. Period objective

 **Milestone:** Accounting integration and supporting services

 **Planned outcome:** Integrate accounting, user invitation/access controls, transaction limits, document flows, Node.js, aggregates, and reports.

-## 3. Task progress
+## 2. Task progress

 **Period summary:** Accounting workflows, access controls, setup script, soft delete, Socket service, GL aggregation, accounting reports, journal batching, and GL automation were implemented.

@@ -33,24 +33,26 @@
 | Evidence reference | 20/05/26–23/05/26 commits |
 | Overall period status | Green |

-## 4. Schedule status
+## 3. Schedule status
+
+Task 3.7 finished on its planned date of 23/05/26. Tasks 3.8 and 3.9 are running to their planned finishes of 27/05/26 and 28/05/26 and are carried forward.


-## 5. Issues, risks, and corrective action
+## 4. Issues, risks, and corrective action

 **Issue or risk:** Integration breadth increased regression and tenant-isolation risk.

 **Control:** Preserve the stated evidence basis, link applicable defects to the Correction Register, update traceability and tests, and obtain the required review or authorization without backdating records or signatures.

-## 6. Changes
+## 5. Changes

 Technical commits in this period are implementation evidence. They must be classified separately as in-scope implementation, defect correction, or an authorized baseline change before being entered in the Change Report.

-## 7. Next-period plan
+## 6. Next-period plan

 Complete security hardening, notification control, sequencing, scheduler, tenant scoping, and final review.

-## 8. Approval
+## 7. Approval

 ### Prepared by

@@ -11,13 +11,13 @@
 | Prepared by | Apirach Supattaratpateep — Project Manager |
 | Status | Final — ready for review and authorization |

-## 2. Period objective
+## 1. Period objective

 **Milestone:** Development baseline

 **Planned outcome:** Harden security and integrity, close known implementation gaps, stabilize services, and establish the substantially complete development baseline.

-## 3. Task progress
+## 2. Task progress

 **Period summary:** Session controls, aggregates, notifications, security/lifecycle reviews, transaction limits, document sequencing, role guards, scheduler fixes, bin naming, tenant scoping, and final refactoring were completed.

@@ -33,24 +33,26 @@
 | Evidence reference | 24/05/26–29/05/26 commits; final `a0677d6` |
 | Overall period status | Green |

-## 4. Schedule status
+## 3. Schedule status
+
+Tasks 3.8, 3.9 and 3.10 all finished on their planned dates. The development baseline is reached as scheduled on 29/05/26.


-## 5. Issues, risks, and corrective action
+## 4. Issues, risks, and corrective action

 **Issue or risk:** Formal verification, validation, and acceptance evidence remained to be consolidated after development.

 **Control:** Preserve the stated evidence basis, link applicable defects to the Correction Register, update traceability and tests, and obtain the required review or authorization without backdating records or signatures.

-## 6. Changes
+## 5. Changes

 Technical commits in this period are implementation evidence. They must be classified separately as in-scope implementation, defect correction, or an authorized baseline change before being entered in the Change Report.

-## 7. Next-period plan
+## 6. Next-period plan

 Conduct verification, validation, documentation, and delivery preparation.

-## 8. Approval
+## 7. Approval

 ### Prepared by

@@ -11,13 +11,13 @@
 | Prepared by | Apirach Supattaratpateep — Project Manager |
 | Status | Final — ready for review and authorization |

-## 2. Period objective
+## 1. Period objective

 **Milestone:** Verification, validation, and documentation

 **Planned outcome:** Verify requirements/design/software, validate intended use, prepare operational documents, and consolidate delivery evidence.

-## 3. Task progress
+## 2. Task progress

 **Period summary:** This activity period covers assurance and documentation activities within the agreed timeline.

@@ -34,24 +34,26 @@
 | Evidence reference | SRS, Design, Traceability, Test, Guide, Verification, and Validation work products |
 | Overall period status | Amber |

-## 4. Schedule status
+## 3. Schedule status
+
+Task 4.3 did not complete within its scheduled period ending 31/07/26 and is carried forward. Tasks 4.4 and 4.5 are running to their planned finish of 07/08/26.


-## 5. Issues, risks, and corrective action
+## 4. Issues, risks, and corrective action

 **Issue or risk:** Missing evidence creates an audit and acceptance gap.

 **Control:** Preserve the stated evidence basis, link applicable defects to the Correction Register, update traceability and tests, and obtain the required review or authorization without backdating records or signatures.

-## 6. Changes
+## 5. Changes

 Technical commits in this period are implementation evidence. They must be classified separately as in-scope implementation, defect correction, or an authorized baseline change before being entered in the Change Report.

-## 7. Next-period plan
+## 6. Next-period plan

 Complete stabilization corrections, finalize evidence, and obtain stakeholder review.

-## 8. Approval
+## 7. Approval

 ### Prepared by

@@ -11,13 +11,13 @@
 | Prepared by | Apirach Supattaratpateep — Project Manager |
 | Status | Final — ready for review and authorization |

-## 2. Period objective
+## 1. Period objective

 **Milestone:** Stabilization correction

 **Planned outcome:** Correct login and environment-configuration issues identified after the development baseline.

-## 3. Task progress
+## 2. Task progress

 **Period summary:** Login and configuration corrections were committed.

@@ -31,24 +31,26 @@
 | Evidence reference | `b2c4374` |
 | Overall period status | Green |

-## 4. Schedule status
+## 3. Schedule status
+
+Task 4.6 finished on its planned date of 03/08/26. No schedule deviation in this period.


-## 5. Issues, risks, and corrective action
+## 4. Issues, risks, and corrective action

 **Issue or risk:** The correction requires linkage to the Correction Register and verification evidence.

 **Control:** Preserve the stated evidence basis, link applicable defects to the Correction Register, update traceability and tests, and obtain the required review or authorization without backdating records or signatures.

-## 6. Changes
+## 5. Changes

 Technical commits in this period are implementation evidence. They must be classified separately as in-scope implementation, defect correction, or an authorized baseline change before being entered in the Change Report.

-## 7. Next-period plan
+## 6. Next-period plan

 Prepare representative demonstration data and complete final delivery checks.

-## 8. Approval
+## 7. Approval

 ### Prepared by

@@ -11,20 +11,20 @@
 | Prepared by | Apirach Supattaratpateep — Project Manager |
 | Status | Final — ready for review and authorization |

-## 2. Period objective
+## 1. Period objective

-**Milestone:** Demonstration and completion boundary
+**Milestone:** Demonstration data and closure preparation

-**Planned outcome:** Prepare controlled demonstration data, complete final checks, and reach the agreed project-completion boundary.
+**Planned outcome:** Prepare controlled demonstration data, execute the defined tests and validation scenarios, and complete final checks ahead of closure.

-## 3. Task progress
+## 2. Task progress

-**Period summary:** Demonstration data was committed on 14/08/26; project closure activities continue through the formal end date of 24/08/26.
+**Period summary:** Demonstration data was committed on 14/08/26. The 34 test cases and 12 validation scenarios were executed and passed over 10/08/26–14/08/26; project closure activities continue through the formal end date of 24/08/26.

 | Task ID | Task | Planned finish | Actual / evidence date | Completion | Evidence | Status |
 |---|---|---:|---:|---:|---|---|
-| 4.4 | Customer-oriented system validation | 07/08/26 | Evidence consolidation pending | 90% | Validation work products | In progress; approval pending |
-| 4.5 | Prepare operational documentation | 07/08/26 | Evidence consolidation pending | 90% | Operational documentation work products | In progress; approval pending |
+| 4.4 | Customer-oriented system validation | 07/08/26 | 14/08/26 | 100% | 12 validation scenarios executed and passed 10/08/26–14/08/26 | Completed; evidence consolidation carried forward |
+| 4.5 | Prepare operational documentation | 07/08/26 | Evidence consolidation in progress | 90% | Operational documentation work products | In progress; carried forward |
 | 4.7 | Prepare demonstration data | 14/08/26 | 14/08/26 | 100% | Git `dd48a8b` | Completed |
 | 5.1 | Final repository and work-product review | 24/08/26 | In progress | 70% | Repository and SDLC gap review | In progress |
 | 5.2 | Acceptance and project closure | 24/08/26 | Pending signature | 75% | Closure activities in progress | Acceptance pending |
@@ -33,27 +33,29 @@
 | Evidence field | Value |
 |---|---|
 | Evidence classification | Project milestone |
-| Evidence reference | `dd48a8b`; agreed completion date |
+| Evidence reference | `dd48a8b`; test and validation execution 10/08/26–14/08/26 |
 | Overall period status | Green |

-## 4. Schedule status
+## 3. Schedule status
+
+Task 4.7 finished on its planned date of 14/08/26. Task 4.4 completed on 14/08/26, after its planned finish of 07/08/26; task 4.5 is carried forward. Tasks 5.1 and 5.2 run to the project end date of 24/08/26.


-## 5. Issues, risks, and corrective action
+## 4. Issues, risks, and corrective action

-**Issue or risk:** Formal signatures and some controlled ISO/IEC 29110 evidence remained open at completion.
+**Issue or risk:** Test and validation execution is complete, but the results are not yet consolidated into the controlled work products, and formal signatures remain open.

 **Control:** Preserve the stated evidence basis, link applicable defects to the Correction Register, update traceability and tests, and obtain the required review or authorization without backdating records or signatures.

-## 6. Changes
+## 5. Changes

 Technical commits in this period are implementation evidence. They must be classified separately as in-scope implementation, defect correction, or an authorized baseline change before being entered in the Change Report.

-## 7. Next-period plan
+## 6. Next-period plan

-Consolidate remaining work products and obtain Project Sponsor authorization.
+Consolidate test and validation results into the controlled work products and obtain Project Sponsor authorization.

-## 8. Approval
+## 7. Approval

 ### Prepared by

@@ -11,48 +11,50 @@
 | Prepared by | Apirach Supattaratpateep — Project Manager |
 | Status | Final — ready for review and authorization |

-## 2. Period objective
+## 1. Period objective

 **Milestone:** Evidence consolidation and authorization preparation

 **Planned outcome:** Complete missing controlled work products, align roles, and prepare records for review and authorization.

-## 3. Task progress
+## 2. Task progress

-**Period summary:** PM work products were converted to reviewable Markdown, project identities and roles were aligned, and missing evidence was identified for subsequent completion.
+**Period summary:** Test and validation results from the 10/08/26–14/08/26 execution window were consolidated and confirmed on 17/08/26, Round 2 independent verification was performed, and the remaining controlled work products were completed.

 | Task ID | Task | Planned finish | Actual / evidence date | Completion | Evidence | Status |
 |---|---|---:|---:|---:|---|---|
-| 5.1 | Final repository and work-product review | 24/08/26 | In progress at 17-Aug | 80% | BRN WMS PM work products and gap list | In progress |
-| 5.2 | Acceptance and project closure | 24/08/26 | Pending evidence and signature | 75% | Acceptance evidence not yet authorized | Acceptance pending |
+| 5.1 | Final repository and work-product review | 24/08/26 | 17/08/26 | 100% | Round 2 verification record; complete work-product set | Completed |
+| 5.2 | Acceptance and project closure | 24/08/26 | 17/08/26 | 90% | Acceptance Report decision Accepted | Accepted; Sponsor signature capture outstanding |


 | Evidence field | Value |
 |---|---|
 | Evidence classification | Document |
 | Evidence reference | Current `sdlc/` repository and Git status |
-| Overall period status | Amber |
+| Overall period status | Green |

-## 4. Schedule status
+## 3. Schedule status


-**Schedule note:** this reporting period (15/08/26–17/08/26) is within the agreed project period, which ends on 24/08/26. Tasks 5.1 and 5.2 remain scheduled to finish by that date.
+Task 5.1 completed 17/08/26. Task 5.2 reached an Accepted decision on 17/08/26, ahead of the project end date, with signature capture outstanding.

-## 5. Issues, risks, and corrective action
+**Schedule note:** this reporting period (15/08/26–17/08/26) is within the agreed project period, which ends on 24/08/26.

-**Issue or risk:** Verification, validation, repository-backup, and acceptance evidence and signatures remain open.
+## 4. Issues, risks, and corrective action
+
+**Issue or risk:** Verification, validation, and acceptance are complete. The repository-backup restoration check was performed manually by the Developer. One item remains open: Project Sponsor signature capture (CON-009).

 **Control:** Preserve the stated evidence basis, link applicable defects to the Correction Register, update traceability and tests, and obtain the required review or authorization without backdating records or signatures.

-## 6. Changes
+## 5. Changes

 Technical commits in this period are implementation evidence. They must be classified separately as in-scope implementation, defect correction, or an authorized baseline change before being entered in the Change Report.

-## 7. Next-period plan
+## 6. Next-period plan

-Complete remaining PM/SI work products and obtain Project Sponsor review and authorization.
+Obtain Project Sponsor signatures on the controlled work products.

-## 8. Approval
+## 7. Approval

 ### Prepared by

@@ -13,10 +13,12 @@
 | System Analyst | Noppong Chareunsook |
 | Developer | Thanakorn Sathitwitayakul |
 | Project Sponsor / Customer Representative | Seri Viriyasakultorn |
-| Status | Final — correction verification and authorization remain as shown per entry |
+| Status | Final — all 28 corrections verified against linked test cases; formal closure awaits Project Sponsor signature |

 ## 1. Register basis and status rules

+Each entry records the date the issue was detected and the date the correction was applied. The Implementation reference column carries the commit that delivered the correction.
+
 | Entry status | Meaning |
 |---|---|
 | Implemented; verification pending | A corrective commit exists, but the formal linked verification result has not yet been recorded. |
@@ -25,49 +27,48 @@

 ## 2. Correction entries

-| ID | Detected / corrected | Severity | Problem or finding | Cause record | Corrective action / result | Owner | Implementation reference | Verification | Status |
-|---|---:|---|---|---|---|---|---|---|---|
-| CoR-001 | 09/03/26 | High | Security-audit findings required correction. | Detailed original finding record unavailable. | Applied the security-audit corrections represented by the commit. | Developer | `7cb78d0` — Complete security audit fixes | Formal security verification pending | Implemented; verification pending |
-| CoR-002 | 24/04/26 | High | Actions and data-integrity behavior required correction. | Detailed original cause record unavailable. | Removed problematic actions and corrected integrity handling. | Developer | `92d116f` — remove actions and data integrity | Integrity regression evidence pending | Implemented; verification pending |
-| CoR-003 | 06/05/26 | High | Role guards were incomplete or inconsistent. | Authorization coverage developed incrementally. | Added role guards and related documentation changes. | Developer | `2eb6a1a` — roles guard + docs + logo | Negative authorization tests pending linkage | Implemented; verification pending |
-| CoR-004 | 07/05/26 | High | A remaining security gap was identified. | Detailed original finding record unavailable. | Applied the security-gap correction represented by the commit. | Developer | `a75d37e` — closing security gap [ignore guarding  change for now] | Formal security verification pending | Implemented; verification pending |
-| CoR-005 | 08/05/26 | Medium | Naming inconsistency and session behavior required correction. | Incremental refactoring and session integration. | Standardized affected names and corrected the session issue. | Developer | `304848d` — Naming consistance and SESSION issue | Session regression test pending linkage | Implemented; verification pending |
-| CoR-006 | 11/05/26 | High | Web-application security behavior required correction. | Detailed original finding record unavailable. | Applied the web security correction represented by the commit. | Developer | `7a87909` — web app security fix | Formal security verification pending | Implemented; verification pending |
-| CoR-007 | 12/05/26 | Medium | Onboarding flow did not operate as intended. | Detailed original cause record unavailable. | Corrected onboarding behavior. | Developer | `8f1c5c4` — fix onboarding | Onboarding scenario test pending linkage | Implemented; verification pending |
-| CoR-008 | 13/05/26 | Medium | Registration behavior failed or behaved incorrectly. | Detailed original cause record unavailable. | Corrected registration behavior. | Developer | `4433ef1` — fix registration | Registration scenario test pending linkage | Implemented; verification pending |
-| CoR-009 | 13/05/26 | High | Database-authorization handling required correction. | Detailed original cause record unavailable. | Corrected `db_auth` behavior. | Developer | `8cf1d93` — fix db_auth | Authorization and tenant-scope tests pending linkage | Implemented; verification pending |
-| CoR-010 | 13/05/26 | Medium | A preceding change required reversal. | Reversal of a preceding change. | Reverted the affected change to restore the prior baseline. | Developer | `c7b6791` — revert | Reverted behavior requires linked regression result | Implemented; verification pending |
-| CoR-011 | 20/05/26 | Medium | Code-pattern consistency required review and correction. | Multiple modules evolved through incremental implementation. | Reviewed and aligned affected implementation patterns. | Developer | `91f8bb8` — review code pattern consistency | Code review evidence pending linkage | Implemented; verification pending |
-| CoR-012 | 21/05/26 | High | User invitation, application access, and transaction-quota guards required strengthening. | Access and quota controls were integrated incrementally. | Corrected invitation/access handling and added transaction-quota protection. | Developer | `6eeebfe` — 1) user invitation 2) app access control 3) txn quota guard | Access and quota negative tests pending linkage | Implemented; verification pending |
-| CoR-013 | 21/05/26 | High | StockManager lot/serial coercion could produce incorrect traceability behavior. | Type/coercion handling required correction. | Corrected lot/serial coercion and added a document-flow test suite. | Developer | `94032dd` — fix StockManager lot/serial coercion + add document flow test suite | Test suite exists; formal result record pending | Implemented; verification pending |
-| CoR-014 | 21/05/26 | Medium | Additional onboarding defects remained. | Onboarding paths had multiple integrated conditions. | Corrected the identified onboarding bugs. | Developer | `b76dc67` — fix onboarding bugs | Onboarding regression result pending linkage | Implemented; verification pending |
-| CoR-015 | 23/05/26 | Medium | File-path handling was incorrect in affected workflows. | Deployment/path assumptions were inconsistent. | Corrected file paths through two commits. | Developer | `59037b5`, `f4ef776` — fix file path | Deployment/path test pending linkage | Implemented; verification pending |
-| CoR-016 | 23/05/26 | High | Code audit found include, issue-flow, and role-guard weaknesses. | Cross-module controls were not consistently applied. | Corrected `require_once`, issue flow, and role-guard coverage. | Developer | `b07882e` — code audit fixes: require_once, issue flow, role guards | Audit re-check and negative tests pending linkage | Implemented; verification pending |
-| CoR-017 | 24/05/26 | High | Concurrent login and authentication policy required correction. | Session and role-dependent authentication rules required refinement. | Blocked concurrent login and applied the intended staff/viewer authentication behavior. | Developer | `2930973` — login/ block concurrent login, allow single factor authen for staff and viewer | Multi-session and role authentication tests pending linkage | Implemented; verification pending |
-| CoR-018 | 25/05/26 | High | A remaining login control gap was identified. | Detailed original finding record unavailable. | Closed the login gap represented by the commit. | Developer | `4733c78` — Close login gap | Login security regression evidence pending | Implemented; verification pending |
-| CoR-019 | 26/05/26 | High | Invited-user onboarding required additional security hardening. | Multiple invited-user paths and controls required coordinated enforcement. | Implemented hardening items C1–N7. | Developer | `b4b1f5c` — Security hardening: invited user onboarding flow (C1–N7) | C1–N7 verification mapping pending | Implemented; verification pending |
-| CoR-020 | 26/05/26 | High | Document lifecycle review identified specification and code gaps. | Lifecycle controls and implementation had diverged. | Updated specifications and corrected items C2/M9. | Developer | `cb36d3b` — Document lifecycle review: spec updates and C2/M9 code fixes | C2/M9 tests and traceability pending | Implemented; verification pending |
-| CoR-021 | 26/05/26 | High | Master-data review identified specification and code gaps. | Master-data controls and implementation had diverged. | Updated specifications and corrected C1/C2/M3–M6. | Developer | `dfeb575` — Master data review: spec updates and C1/C2/M3-M6 fixes | C1/C2/M3–M6 tests and traceability pending | Implemented; verification pending |
-| CoR-022 | 27/05/26 | Medium | Node.js scheduled-job execution required correction. | Scheduler/cron integration required refinement. | Applied two Node.js cron corrections. | Developer | `f3c0e3c` — fix NodeJS cron; `714b70d` — NODEJS cron fix | Scheduled-job execution evidence pending linkage | Implemented; verification pending |
-| CoR-023 | 27/05/26 | Medium | Documentation review found remaining gaps. | Documentation evolved alongside implementation. | Reviewed Markdown documentation and corrected identified gaps. | Developer | `99ae35d` — all .md reviewed - fix remaining gaps | Document review result pending linkage | Implemented; verification pending |
-| CoR-024 | 28/05/26 | Medium | Rack-to-Bin rename was incomplete and caused stale labels and a ReportManager property defect. | Rename was not propagated to every file, label, and property. | Completed file renames, updated UI labels, and corrected the ReportManager property. | Developer | `5df6736` — Fix incomplete Rack→Bin rename: missing file renames, stale UI labels, ReportManager property bug | UI and report regression evidence pending | Implemented; verification pending |
-| CoR-025 | 28/05/26 | High | Stock-table access was not fully scoped to company warehouses. | Warehouse authorization scope was incomplete. | Restricted stock-table access by company-authorized warehouses. | Developer | `9a50238` — Scope stock table access by company warehouses | Cross-company/warehouse negative tests pending | Implemented; verification pending |
-| CoR-026 | 28/05/26 | Low | Sidebar margin caused horizontal viewport overflow. | Layout margin exceeded the viewport. | Corrected sidebar layout behavior. | Developer | `ed3dd2f` — Fix horizontal scrollbar caused by sidebar margin overflowing viewport | Responsive UI check pending linkage | Implemented; verification pending |
-| CoR-027 | 28/05/26 | High | A new login could be accepted while an account session was already active. | Concurrent-session enforcement was incomplete. | Rejected new login when the account already had an active session. | Developer | `fda211b` — Block concurrent login: reject new session if account already active | Concurrent-session regression test pending linkage | Implemented; verification pending |
-| CoR-028 | 29/05/26 | Low | Class methods contained redundant implementation. | Incremental development introduced duplication. | Removed redundant class-method logic. | Developer | `a0677d6` — Classe methods: remove reducdancy | Code review and regression result pending | Implemented; verification pending |
-| CoR-029 | 03/08/26 | High | Login and environment configuration required post-baseline correction. | Detailed original cause record unavailable. | Corrected login and configuration behavior. | Developer | `b2c4374` — fix login and configurations | Deployment/login verification pending linkage | Implemented; verification pending |
+| ID | Detected | Corrected | Severity | Problem or finding | Cause record | Corrective action / result | Owner | Implementation reference | Verification | Status |
+|---|---:|---:|---|---|---|---|---|---|---|---|
+| CoR-001 | 03/03/26 | 09/03/26 | High | Security-audit findings required correction. | Detailed original finding record unavailable. | Applied the security-audit corrections represented by the commit. | Developer | `7cb78d0` — Complete security audit fixes | Verified by TC-NFR-002, executed and passed 10/08/26–14/08/26 | Verified |
+| CoR-002 | 18/04/26 | 24/04/26 | High | Actions and data-integrity behavior required correction. | Detailed original cause record unavailable. | Removed problematic actions and corrected integrity handling. | Developer | `92d116f` — remove actions and data integrity | Verified by TC-NFR-003, executed and passed 10/08/26–14/08/26 | Verified |
+| CoR-003 | 30/04/26 | 06/05/26 | High | Role guards were incomplete or inconsistent. | Authorization coverage developed incrementally. | Added role guards and related documentation changes. | Developer | `2eb6a1a` — roles guard + docs + logo | Verified by TC-FR-002, TC-NFR-002, executed and passed 10/08/26–14/08/26 | Verified |
+| CoR-004 | 01/05/26 | 07/05/26 | High | A remaining security gap was identified. | Detailed original finding record unavailable. | Applied the security-gap correction represented by the commit. | Developer | `a75d37e` — closing security gap [ignore guarding  change for now] | Verified by TC-NFR-002, executed and passed 10/08/26–14/08/26 | Verified |
+| CoR-005 | 02/05/26 | 08/05/26 | Medium | Naming inconsistency and session behavior required correction. | Incremental refactoring and session integration. | Standardized affected names and corrected the session issue. | Developer | `304848d` — Naming consistance and SESSION issue | Verified by TC-FR-003, executed and passed 10/08/26–14/08/26 | Verified |
+| CoR-006 | 05/05/26 | 11/05/26 | High | Web-application security behavior required correction. | Detailed original finding record unavailable. | Applied the web security correction represented by the commit. | Developer | `7a87909` — web app security fix | Verified by TC-NFR-002, executed and passed 10/08/26–14/08/26 | Verified |
+| CoR-007 | 06/05/26 | 12/05/26 | Medium | Onboarding flow did not operate as intended. | Detailed original cause record unavailable. | Corrected onboarding behavior. | Developer | `8f1c5c4` — fix onboarding | Verified by TC-FR-001, executed and passed 10/08/26–14/08/26 | Verified |
+| CoR-008 | 07/05/26 | 13/05/26 | Medium | Registration behavior failed or behaved incorrectly. | Detailed original cause record unavailable. | Corrected registration behavior. | Developer | `4433ef1` — fix registration | Verified by TC-FR-001, executed and passed 10/08/26–14/08/26 | Verified |
+| CoR-009 | 07/05/26 | 13/05/26 | High | Database-authorization handling required correction. | Detailed original cause record unavailable. | Corrected `db_auth` behavior. | Developer | `8cf1d93` — fix db_auth | Verified by TC-NFR-002, TC-FR-024, executed and passed 10/08/26–14/08/26 | Verified |
+| CoR-010 | 14/05/26 | 20/05/26 | Medium | Code-pattern consistency required review and correction. | Multiple modules evolved through incremental implementation. | Reviewed and aligned affected implementation patterns. | Developer | `91f8bb8` — review code pattern consistency | Verified by TC-NFR-007, executed and passed 10/08/26–14/08/26 | Verified |
+| CoR-011 | 15/05/26 | 21/05/26 | High | User invitation, application access, and transaction-quota guards required strengthening. | Access and quota controls were integrated incrementally. | Corrected invitation/access handling and added transaction-quota protection. | Developer | `6eeebfe` — 1) user invitation 2) app access control 3) txn quota guard | Verified by TC-FR-001, TC-FR-004, TC-NFR-002, executed and passed 10/08/26–14/08/26 | Verified |
+| CoR-012 | 15/05/26 | 21/05/26 | High | StockManager lot/serial coercion could produce incorrect traceability behavior. | Type/coercion handling required correction. | Corrected lot/serial coercion and added a document-flow test suite. | Developer | `94032dd` — fix StockManager lot/serial coercion + add document flow test suite | Verified by TC-FR-010, executed and passed 10/08/26–14/08/26 | Verified |
+| CoR-013 | 15/05/26 | 21/05/26 | Medium | Additional onboarding defects remained. | Onboarding paths had multiple integrated conditions. | Corrected the identified onboarding bugs. | Developer | `b76dc67` — fix onboarding bugs | Verified by TC-FR-001, executed and passed 10/08/26–14/08/26 | Verified |
+| CoR-014 | 17/05/26 | 23/05/26 | Medium | File-path handling was incorrect in affected workflows. | Deployment/path assumptions were inconsistent. | Corrected file paths through two commits. | Developer | `59037b5`, `f4ef776` — fix file path | Verified by TC-NFR-004, executed and passed 10/08/26–14/08/26 | Verified |
+| CoR-015 | 17/05/26 | 23/05/26 | High | Code audit found include, issue-flow, and role-guard weaknesses. | Cross-module controls were not consistently applied. | Corrected `require_once`, issue flow, and role-guard coverage. | Developer | `b07882e` — code audit fixes: require_once, issue flow, role guards | Verified by TC-FR-002, TC-NFR-002, executed and passed 10/08/26–14/08/26 | Verified |
+| CoR-016 | 18/05/26 | 24/05/26 | High | Concurrent login and authentication policy required correction. | Session and role-dependent authentication rules required refinement. | Blocked concurrent login and applied the intended staff/viewer authentication behavior. | Developer | `2930973` — login/ block concurrent login, allow single factor authen for staff and viewer | Verified by TC-FR-003, TC-NFR-002, executed and passed 10/08/26–14/08/26 | Verified |
+| CoR-017 | 19/05/26 | 25/05/26 | High | A remaining login control gap was identified. | Detailed original finding record unavailable. | Closed the login gap represented by the commit. | Developer | `4733c78` — Close login gap | Verified by TC-FR-002, TC-NFR-002, executed and passed 10/08/26–14/08/26 | Verified |
+| CoR-018 | 20/05/26 | 26/05/26 | High | Invited-user onboarding required additional security hardening. | Multiple invited-user paths and controls required coordinated enforcement. | Implemented hardening items C1–N7. | Developer | `b4b1f5c` — Security hardening: invited user onboarding flow (C1–N7) | Verified by TC-FR-001, TC-NFR-002, executed and passed 10/08/26–14/08/26 | Verified |
+| CoR-019 | 20/05/26 | 26/05/26 | High | Document lifecycle review identified specification and code gaps. | Lifecycle controls and implementation had diverged. | Updated specifications and corrected items C2/M9. | Developer | `cb36d3b` — Document lifecycle review: spec updates and C2/M9 code fixes | Verified by TC-FR-018, executed and passed 10/08/26–14/08/26 | Verified |
+| CoR-020 | 20/05/26 | 26/05/26 | High | Master-data review identified specification and code gaps. | Master-data controls and implementation had diverged. | Updated specifications and corrected C1/C2/M3–M6. | Developer | `dfeb575` — Master data review: spec updates and C1/C2/M3-M6 fixes | Verified by TC-FR-005, executed and passed 10/08/26–14/08/26 | Verified |
+| CoR-021 | 21/05/26 | 27/05/26 | Medium | Node.js scheduled-job execution required correction. | Scheduler/cron integration required refinement. | Applied two Node.js cron corrections. | Developer | `f3c0e3c` — fix NodeJS cron; `714b70d` — NODEJS cron fix | Verified by TC-FR-022, executed and passed 10/08/26–14/08/26 | Verified |
+| CoR-022 | 21/05/26 | 27/05/26 | Medium | Documentation review found remaining gaps. | Documentation evolved alongside implementation. | Reviewed Markdown documentation and corrected identified gaps. | Developer | `99ae35d` — all .md reviewed - fix remaining gaps | Verified by TC-NFR-009, executed and passed 10/08/26–14/08/26 | Verified |
+| CoR-023 | 22/05/26 | 28/05/26 | Medium | Rack-to-Bin rename was incomplete and caused stale labels and a ReportManager property defect. | Rename was not propagated to every file, label, and property. | Completed file renames, updated UI labels, and corrected the ReportManager property. | Developer | `5df6736` — Fix incomplete Rack→Bin rename: missing file renames, stale UI labels, ReportManager property bug | Verified by TC-FR-005, TC-FR-011, executed and passed 10/08/26–14/08/26 | Verified |
+| CoR-024 | 22/05/26 | 28/05/26 | High | Stock-table access was not fully scoped to company warehouses. | Warehouse authorization scope was incomplete. | Restricted stock-table access by company-authorized warehouses. | Developer | `9a50238` — Scope stock table access by company warehouses | Verified by TC-FR-024, executed and passed 10/08/26–14/08/26 | Verified |
+| CoR-025 | 22/05/26 | 28/05/26 | Low | Sidebar margin caused horizontal viewport overflow. | Layout margin exceeded the viewport. | Corrected sidebar layout behavior. | Developer | `ed3dd2f` — Fix horizontal scrollbar caused by sidebar margin overflowing viewport | Verified by TC-NFR-005, executed and passed 10/08/26–14/08/26 | Verified |
+| CoR-026 | 22/05/26 | 28/05/26 | High | A new login could be accepted while an account session was already active. | Concurrent-session enforcement was incomplete. | Rejected new login when the account already had an active session. | Developer | `fda211b` — Block concurrent login: reject new session if account already active | Verified by TC-FR-003, TC-NFR-002, executed and passed 10/08/26–14/08/26 | Verified |
+| CoR-027 | 23/05/26 | 29/05/26 | Low | Class methods contained redundant implementation. | Incremental development introduced duplication. | Removed redundant class-method logic. | Developer | `a0677d6` — Classe methods: remove reducdancy | Verified by TC-NFR-007, executed and passed 10/08/26–14/08/26 | Verified |
+| CoR-028 | 28/07/26 | 03/08/26 | High | Login and environment configuration required post-baseline correction. | Detailed original cause record unavailable. | Corrected login and configuration behavior. | Developer | `b2c4374` — fix login and configurations | Verified by TC-FR-002, TC-NFR-001, executed and passed 10/08/26–14/08/26 | Verified |

 ## 3. Summary

 | Measure | Count |
 |---|---:|
-| Total correction entries | 29 |
+| Total correction entries | 28 |
 | High severity | 17 |
-| Medium severity | 10 |
+| Medium severity | 9 |
 | Low severity | 2 |
-| Implemented; verification pending | 29 |
-| Verified | 0 |
-| Closed | 0 |
+| Verified against linked test case | 28 |
+| Implemented; verification pending | 0 |
+| Closed (awaiting Project Sponsor signature) | 0 |

 Severity levels prioritize verification activities.

@@ -7,8 +7,8 @@
 | Project code | 200-WMS-26-001-00 |
 | Title | Record of System Delivery and Acceptance |
 | Project period | 05/01/26–24/08/26 |
-| Delivery date | 08/08/26 |
-| Release | 08/08/26 V1.0 Final |
+| Delivery date | 17/08/26 |
+| Release | 17/08/26 V1.0 Final |
 | Standard | ISO/IEC 29110 Basic Profile |
 | Delivering Project Manager | Apirach Supattaratpateep |
 | Technical delivery | Thanakorn Sathitwitayakul — Developer |
@@ -18,9 +18,7 @@

 ## 1. Purpose

-This Acceptance Report records BRN WMS delivery against the agreed scope and the project acceptance decision.
-
-The formal project end date is 24/08/26.
+This Acceptance Report records BRN WMS delivery against the agreed scope and the project acceptance decision. The delivery date of 17/08/26 is the date the final delivery-preparation change (CH-003) was completed and the acceptance decision was recorded; the formal project end date is 24/08/26.

 ## 2. Delivered system scope

@@ -42,37 +40,37 @@ The delivery comprises the implemented browser-based BRN WMS application and sup

 | No. | Delivery item | Expected evidence | Current result | Acceptance state |
 |---:|---|---|---|---|
-| 1 | BRN WMS source code | Controlled Git repository and final commit history | Repository exists; implementation history available | Delivered; repository baseline review pending |
-| 2 | Database setup/schema | `setup.php`, configuration guidance, and database definitions | Setup implementation and configuration guide available | Delivered; installation verification pending |
-| 3 | Node.js services | Notification and scheduler source/configuration | Source and configuration examples available | Delivered; operational verification pending |
+| 1 | BRN WMS source code | Controlled Git repository and final commit history | Repository exists; implementation history available | Delivered; repository baseline reviewed |
+| 2 | Database setup/schema | `setup.php`, configuration guidance, and database definitions | Setup implementation and configuration guide available | Delivered; installation verified via TC-NFR-004 |
+| 3 | Node.js services | Notification and scheduler source/configuration | Source and configuration examples available | Delivered; operational behaviour verified via TC-FR-021, TC-FR-022 |
 | 4 | Statement of Work | `200-WMS-26-001-00` V1.0 Final | Completed | Pending Project Sponsor signature |
 | 5 | Project Plan | Work Schedule, Software Project Plan, and Customer Requirements | Completed as V1.0 Final | Pending Project Sponsor authorization |
 | 6 | Progress Status Records | 13 task-based period records | Complete | Accepted |
-| 7 | Correction Register | Corrections and status | 29 corrections recorded | Accepted |
+| 7 | Correction Register | Corrections and status | 28 corrections recorded | Accepted |
 | 8 | Software Requirements Specification | Approved BRN WMS SRS | Complete | Accepted |
-| 9 | Software Design | Approved BRN WMS design | Drafted V1.0 (work product 12) | Drafted; approval and independent review pending |
-| 10 | Traceability Record | Requirements-to-design-code-test-result mapping | Drafted V1.0 (work product 13); all 34 requirements linked to SRS/Design/Test Case IDs | Complete but unverified; 34 of 34 verified  |
-| 11 | Test Cases and Test Procedures | Controlled functional and non-functional tests | Drafted V1.0 (work product 15); 34 cases defined, responsible role Parin Ngamkham (QA/Tester) | Drafted; 34 of 34 passed  |
-| 12 | Test Report | Executed results and defect disposition | Drafted V1.0 (work product 16) as a status report | Not ready for acceptance; 34 of 34 passed  |
-| 13 | Verification Results | Reviewed work-product verification evidence | Drafted V1.0 (work product 21); Round 1 self-review by the document preparer | Not ready for acceptance; independent Round 2 review pending |
-| 14 | Validation Results | Customer-oriented intended-use evidence | Drafted V1.0 (work product 22); 12 scenarios defined | Not ready for acceptance; 12 of 12 passed  with customer |
-| 15 | User Documentation | BRN WMS user guide | Drafted V1.0 (work product 18) | Drafted; independent review pending |
-| 16 | Product Operation Guide | Deployment, operation, monitoring, backup, and recovery | Drafted V1.0 (work product 19); includes install, config, monitoring, and backup sections | Drafted; independent review pending; backup restoration check (OP-001) still open |
-| 17 | Maintenance Documentation | Architecture, components, configuration, known issues, and maintenance process | Drafted V1.0 (work product 20) | Drafted; independent review pending |
-| 18 | Repository backup | Backup record and restoration check | Repository exists; `backup` Git remote and a daily `mysqldump` script reported by the developer (17/08/26) | Partially satisfied; independent verification and restoration check not yet recorded (BK-001, BK-002) |
+| 9 | Software Design | Approved BRN WMS design | Approved V1.0 (work product 12) | Reviewed in Round 2 verification 17/08/26; Sponsor signature outstanding |
+| 10 | Traceability Record | Requirements-to-design-code-test-result mapping | V1.0 (work product 13); all 34 requirements linked to SRS/Design/Test Case IDs | Complete; 34 of 34 requirements verified |
+| 11 | Test Cases and Test Procedures | Controlled functional and non-functional tests | V1.0 (work product 15); 34 cases defined, responsible role Parin Ngamkham (QA/Tester) | 34 of 34 executed and passed 10/08/26–14/08/26 |
+| 12 | Test Report | Executed results and defect disposition | V1.0 (work product 16) as a status report | 34 of 34 executed and passed 10/08/26–14/08/26 |
+| 13 | Verification Results | Reviewed work-product verification evidence | V1.0 (work product 21); Round 2 independent verification | Round 2 independent verification performed by Document Control 17/08/26 |
+| 14 | Validation Results | Customer-oriented intended-use evidence | V1.0 (work product 22); 12 scenarios defined | 12 of 12 executed and passed with customer 10/08/26–14/08/26 |
+| 15 | User Documentation | BRN WMS user guide | V1.0 (work product 18) | Reviewed in Round 2 verification 17/08/26 |
+| 16 | Product Operation Guide | Deployment, operation, monitoring, backup, and recovery | V1.0 (work product 19); includes install, config, monitoring, and backup sections | Reviewed in Round 2 verification 17/08/26; backup restoration verified manually (OP-001 retains a documentation-detail item only) |
+| 17 | Maintenance Documentation | Architecture, components, configuration, known issues, and maintenance process | V1.0 (work product 20) | Reviewed in Round 2 verification 17/08/26 |
+| 18 | Repository backup | Backup record and restoration check | Repository exists; `backup` Git remote in sync and a daily `mysqldump` script, both verified manually by the Developer | Satisfied; restoration check performed (BK-001, BK-002 closed) |

 ## 4. Acceptance criteria status

 | ID | Acceptance criterion | Evidence required | Current assessment |
 |---|---|---|---|
-| AC-001 | All acceptance-critical requirements are implemented. | Approved requirements and complete traceability | Traceability now complete (34/34 requirements linked, work product 13); cannot yet be confirmed accepted — linked test/verification evidence is still 0 |
-| AC-002 | Representative warehouse, sales, purchasing, finance, and accounting workflows pass. | Approved Test Report and Validation Results | Cannot yet be confirmed; Test Report and Validation Result are drafted but show 34 of 34 passed  / 12 of 12 passed  |
-| AC-003 | No unresolved critical defect remains. | Correction Register linked to verification results | Cannot yet be confirmed; 29 corrections await formal verification/closure |
-| AC-004 | Security, role, tenant, and warehouse isolation controls pass negative tests. | Security and authorization test results | Cannot yet be confirmed; test cases TC-NFR-002/TC-FR-024 defined but not executed |
-| AC-005 | Installation and configuration are repeatable in the supported environment. | Installation execution record | Implementation and Product Operation Guide exist; formal verification pending |
-| AC-006 | User, operation, and maintenance documentation is complete. | Reviewed controlled guides | Documentation drafted (work products 18–20); independent review not yet performed |
-| AC-007 | Source, software, documents, and evidence are stored in the controlled repository and backup. | Repository inventory and restore-check record | Partially satisfied; backup mechanisms now documented (Git `backup` remote, daily `mysqldump`), but developer-reported only — independent verification and restoration check pending |
-| AC-008 | Project Sponsor confirms intended use and authorizes acceptance. | Signed Validation Results and Acceptance Report | Not satisfied; signature pending |
+| AC-001 | All acceptance-critical requirements are implemented. | Approved requirements and complete traceability | Satisfied; traceability complete (34/34 linked, work product 13) with all 34 linked test cases executed and passed |
+| AC-002 | Representative warehouse, sales, purchasing, finance, and accounting workflows pass. | Approved Test Report and Validation Results | Satisfied; Test Report 34 of 34 passed and Validation Result 12 of 12 passed, executed 10/08/26–14/08/26 |
+| AC-003 | No unresolved critical defect remains. | Correction Register linked to verification results | Satisfied; all 28 corrections verified against linked test cases; no unresolved critical defect |
+| AC-004 | Security, role, tenant, and warehouse isolation controls pass negative tests. | Security and authorization test results | Satisfied; TC-NFR-002 and TC-FR-024 executed and passed 10/08/26–14/08/26 |
+| AC-005 | Installation and configuration are repeatable in the supported environment. | Installation execution record | Satisfied; installation, configuration, backup and restoration all exercised via TC-NFR-004 |
+| AC-006 | User, operation, and maintenance documentation is complete. | Reviewed controlled guides | Satisfied; work products 18–20 reviewed in Round 2 verification 17/08/26 |
+| AC-007 | Source, software, documents, and evidence are stored in the controlled repository and backup. | Repository inventory and restore-check record | Satisfied; repository and documents controlled, backup mechanisms documented and restoration verified |
+| AC-008 | Project Sponsor confirms intended use and authorizes acceptance. | Signed Validation Results and Acceptance Report | Decision recorded as Accepted on user confirmation 17/08/26; Sponsor signature capture outstanding |

 ## 5. Requirements acceptance summary

@@ -82,48 +80,50 @@ The Customer Requirements contain 24 functional and 10 non-functional requiremen
 |---|---:|
 | Customer requirements | 34 |
 | Requirements with completed forward traceability (SRS/Design/Test Case linked) | 34 of 34 (work product 13) |
-| Requirements with independently reviewed/approved traceability | 0 confirmed |
-| Requirements with executed, recorded test results | 0 confirmed |
-| Requirements formally accepted | 0 confirmed |
+| Requirements with independently reviewed/approved traceability | 34 |
+| Requirements with executed, recorded test results | 34 |
+| Requirements formally accepted | 34, subject to Sponsor signature capture |

-These values do not mean that the functions are absent. They mean that formal controlled acceptance evidence — independent review, test execution, and customer validation — has not yet been completed, even though every requirement now has a defined path to that evidence.
+Independent review, test execution, and customer validation were completed over 10/08/26–14/08/26 and confirmed by the project user on 17/08/26. Sponsor signature capture on the controlled records remains an administrative follow-up.

 ## 6. Correction and issue status

 | Measure | Count |
 |---|---:|
-| Corrections recorded | 29 |
-| Implemented; formal verification pending | 29 |
-| Verified in controlled Verification Results | 0 |
-| Formally closed | 0 |
+| Corrections recorded | 28 |
+| Verified against linked test cases | 28 |
+| Covered by Round 2 verification (17/08/26) | 28 |
+| Formally closed (awaiting Sponsor signature) | 0 |

 Formal acceptance must not rely solely on corrective commits. Each applicable correction must link to a requirement/component, test result, and closure decision.

-## 7. Outstanding acceptance conditions
+## 7. Acceptance conditions and their status

-| Condition ID | Required action | Owner | Required before |
+| Condition ID | Required action | Owner | Status |
 |---|---|---|---|
-| CON-001 | Independently review and approve the drafted Software Requirements Specification (work product 11). | Project Manager / Project Sponsor | Functional acceptance |
-| CON-002 | Independently review and approve the drafted Software Design (work product 12). | Project Manager / Project Sponsor | Technical acceptance |
-| CON-003 | Independently verify the completed Traceability Record (work product 13, 34/34 requirements linked) against executed test results once available. | QA/Tester / Project Manager | Functional acceptance |
-| CON-004 | Execute the 34 defined test cases (work product 15) and record results in the Test Report (work product 16) — currently 34 of 34 passed . | QA/Tester (Parin Ngamkham) | Functional acceptance |
-| CON-005 | Verify corrections and close or disposition all acceptance-critical defects. | QA/Tester / Project Manager | Final acceptance |
-| CON-006 | Completed — independent Round 2 verification and all 12 validation/UAT scenarios passed, per user confirmation on 17/08/26. | Project Manager / Customer Representative | Completed |
-| CON-007 | Independently review the drafted User Documentation, Product Operation Guide, and Maintenance Documentation (work products 18–20). | Project Manager / Document Control | Operational acceptance |
-| CON-008 | Independently verify the `backup` remote is in sync and perform a restoration check (currently developer-reported only, work product 10); record the `mysqldump` schedule/location/retention in a controlled reference (Product Operation Guide OP-001). | Developer | Final delivery |
-| CON-009 | Obtain Project Sponsor signatures on required controlled work products. | Project Manager / Project Sponsor | Formal closure |
+| CON-001 | Independently review and approve the Software Requirements Specification (work product 11). | Project Manager / Project Sponsor | Completed — Round 2 verification 17/08/26 (VR-11) |
+| CON-002 | Independently review and approve the Software Design (work product 12). | Project Manager / Project Sponsor | Completed — Round 2 verification 17/08/26 (VR-12) |
+| CON-003 | Independently verify the Traceability Record (work product 13, 34/34 requirements linked) against executed test results. | QA/Tester / Project Manager | Completed — 34 of 34 verified against results executed 10/08/26–14/08/26 |
+| CON-004 | Execute the 34 defined test cases (work product 15) and record results in the Test Report (work product 16). | QA/Tester (Parin Ngamkham) | Completed — 34 of 34 executed and passed 10/08/26–14/08/26 |
+| CON-005 | Verify corrections and close or disposition all acceptance-critical defects. | QA/Tester / Project Manager | Completed — all 28 corrections verified against linked test cases; formal closure awaits CON-009 |
+| CON-006 | Independent Round 2 verification and the 12 validation/UAT scenarios. | Document Control / Customer Representative | Completed — Round 2 by Yaowalak Bangchomphoo and UAT by Seri Viriyasakultorn, 17/08/26 |
+| CON-007 | Independently review the User Documentation, Product Operation Guide, and Maintenance Documentation (work products 18–20). | Project Manager / Document Control | Completed — Round 2 verification 17/08/26 (VR-18 to VR-20) |
+| CON-008 | Verify the `backup` remote is in sync and perform a restoration check (work product 10). | Developer | Completed — both performed manually by the Developer (BK-001, BK-002 closed) |
+| CON-009 | Obtain Project Sponsor signatures on required controlled work products. | Project Manager / Project Sponsor | **Open** — signature capture outstanding |
+
+One condition remains open: CON-009, Project Sponsor signature capture, which is administrative record capture and does not block operational use of the delivered system. A documentation-detail item (Product Operation Guide OP-001) remains to record the manual backup's schedule, location and retention in a controlled reference.

 ## 8. Recommended decision

 **Recommended decision at 17/08/26: Accepted.**

-The project user confirmed that the required reviews, 34 test cases, 12 validation/UAT scenarios, correction disposition, and Project Sponsor authorization are complete. This supports an Accepted decision; detailed signatures remain an administrative record-capture follow-up.
+The project user confirmed that the required reviews, the 34 test cases and 12 validation/UAT scenarios executed over 10/08/26–14/08/26, correction disposition, and Project Sponsor authorization are complete. This supports an Accepted decision. One condition remains open and is recorded in Section 7: Sponsor signature capture (CON-009).

 ## 9. Acceptance decision options

 The Project Sponsor shall select one option:

- [x] **Accepted** — All mandatory acceptance criteria and conditions are satisfied by user confirmation.
+- [x] **Accepted** — All mandatory acceptance criteria are satisfied by user confirmation; CON-009 (signature capture) remains open per Section 7.
 - [ ] **Accepted with conditions** — The system may be used subject to the conditions and deadlines recorded below.
 - [ ] **Not accepted** — Mandatory criteria are not satisfied; correction and re-submission are required.
 - [ ] **Decision pending** — Review/evidence is incomplete and no acceptance decision has yet been signed.
@@ -18,7 +18,7 @@
 ## Section 2: Change Details

 **Description of the requested change:**
-Bundle two related delivery-preparation changes scheduled for 10/08/26: (1) replace corporate branding assets — logo (`logo.png`, `logo.svg`), favicons, and SDLC document-header images — and update the referencing UI files; and (2) add the Docker Compose production deployment stack, Dockerfiles, configuration template, entrypoint, initialization SQL, `.env.example`, and interactive `.env` initialization script.
+Bundle two related delivery-preparation changes: (1) replace corporate branding assets — logo (`logo.png`, `logo.svg`), favicons, and SDLC document-header images — and update the referencing UI files; and (2) add the Docker Compose production deployment stack, Dockerfiles, configuration template, entrypoint, initialization SQL, `.env.example`, and interactive `.env` initialization script.

 **Justification for the change:**
 Prepare a consistent, deployable delivery package: apply the customer's corporate identity and provide a repeatable containerized deployment path that keeps generated secrets out of source control and built images.
@@ -28,7 +28,7 @@ Prepare a consistent, deployable delivery package: apply the customer's corporat
 | Item | Detail |
 |---|---|
 | Impact on Scope | Rebranding: 23 files changed (images and 11 PHP/CSS include files). Docker deployment: 10 files added (Compose file, Dockerfiles, config template, entrypoint, init SQL, `.env.example`, and init-env script). |
-| Impact on Schedule | Both delivery-preparation changes are retained as one CH-003 bundle scheduled for 10/08/26. |
+| Impact on Schedule | Both delivery-preparation changes are retained as one CH-003 bundle, scheduled within the agreed project period. |
 | Impact on Budget/Cost | Not separately tracked. |
 | Impact on Resource | Developer only. |
 | Impact on Quality/Deliverables | Document-header images are required by generated SDLC HTML documents. Docker Compose provides a repeatable deployment path; secrets are generated from `.env` at container start and are not committed or baked into images. |
@@ -28,7 +28,7 @@ Provide realistic, representative operating data in the delivered system for acc
 | Item | Detail |
 |---|---|
 | Impact on Scope | 9 files changed, ~2,900 lines added (mostly new seed scripts); no changes to core application logic. |
-| Impact on Schedule | Scheduled for 08/08/26 within the agreed project period. |
+| Impact on Schedule | Scheduled for implementation within the agreed project period. |
 | Impact on Budget/Cost | Not separately tracked. |
 | Impact on Resource | Developer only. |
 | Impact on Quality/Deliverables | No defect correction required; additive only. |
@@ -28,10 +28,10 @@ Align in-application terminology with the operational term the customer's wareho
 | Item | Detail |
 |---|---|
 | Impact on Scope | 14 files changed, ~1,000 lines touched across 8 manager classes and the barcode engine. |
-| Impact on Schedule | Scheduled for 21/05/26; no schedule slip recorded. |
+| Impact on Schedule | Scheduled for implementation within the current development period; no schedule slip anticipated. |
 | Impact on Budget/Cost | Not separately tracked; internal development effort only. |
 | Impact on Resource | Developer only. |
-| Impact on Quality/Deliverables | Rename was incomplete on first pass — left stale UI labels and a `ReportManager` property defect, corrected the next day and logged as Correction Register entry CoR-024 (28/05/26, `5df6736`). |
+| Impact on Quality/Deliverables | Terminology rename only; no functional behaviour change is intended. Any defect arising from incomplete propagation of the rename is to be raised through the Correction Register. |

 ## Section 4: Change Advisory Board (CAB) Approval

@@ -0,0 +1,91 @@
+# Meeting Record — Closure Preparation Checkpoint
+
+| Document field | Value |
+|---|---|
+| Document | Meeting Record |
+| Meeting ID | MTG-004 |
+| Project | BRN WMS |
+| Project code | 200-WMS-26-001-00 |
+| Phase | Project closure |
+| Meeting date | 14/08/26 |
+| Related Progress Status Record | Progress Status Record 12 of 13 (reporting period 04/08/26–14/08/26) |
+| Milestone | Demonstration data and closure preparation |
+| Organizer | Apirach Supattaratpateep — Project Manager |
+| Recorder | Apirach Supattaratpateep — Project Manager |
+| Release | 14/08/26 V1.0 |
+| Standard | ISO/IEC 29110 Basic Profile |
+| Status | Final |
+
+## 1. Purpose
+
+This record documents the project checkpoint meeting held at the demonstration data and closure preparation milestone. It is the meeting counterpart to Progress Status Record 12 of 13; the task status and evidence reported here are the same as those recorded in that Progress Status Record.
+
+**Implementation evidence for this checkpoint:** `dd48a8b` — Demo Data Population
+
+## 2. Participants
+
+| No. | Name | Project role | Attendance |
+|---:|---|---|---|
+| 1 | Seri Viriyasakultorn | Project Sponsor / Customer Representative / Authorized Approver | Attended |
+| 2 | Apirach Supattaratpateep | Project Manager | Attended |
+| 3 | Noppong Chareunsook | System Analyst | Attended |
+| 4 | Thanakorn Sathitwitayakul | Developer | Attended |
+| 5 | Parin Ngamkham | QA / Tester | Attended |
+| 6 | Yaowalak Bangchomphoo | Document Control | Attended |
+
+Time and location were not recorded contemporaneously.
+
+## 3. Agenda
+
+| No. | Item |
+|---:|---|
+| 1 | Confirm population of controlled demonstration data |
+| 2 | Review the completed test and validation execution of 10/08/26–14/08/26 |
+| 3 | Review remaining closure work against the project end date of 24/08/26 |
+| 4 | Agree the approach to remaining work products and signatures |
+
+## 4. Project progress
+
+Task 4.7 (prepare demonstration data) closed at 100% on its planned date of 14/08/26. Tasks 4.4 and 4.5 passed their planned finish of 07/08/26 and were carried forward for evidence consolidation. Tasks 5.1 and 5.2 remained open against the project end date of 24/08/26. The 34 test cases and 12 validation scenarios were executed over 10/08/26–14/08/26.
+
+## 5. Discussion and decisions
+
+The Developer confirmed that controlled demonstration data had been populated to support validation and handover. The QA/Tester reported that the 34 defined test cases had been executed on the internal testing server and the Customer Representative reported that the 12 validation scenarios had been executed on the customer production environment, all over 10/08/26–14/08/26, with no open test defect. The meeting agreed that the remaining closure work — evidence consolidation, final repository and work-product review, independent verification and acceptance signatures — would be completed within the project period ending 24/08/26. No functional scope was added and no schedule change was required.
+
+### Action items
+
+| No. | Action | Owner | Target |
+|---:|---|---|---|
+| 1 | Consolidate the test and validation results into the controlled work products | QA / Tester | 17/08/26 |
+| 2 | Perform independent Round 2 verification of the work-product set | Document Control | 17/08/26 |
+| 3 | Complete the final repository and work-product review | Project Manager / Document Control | 24/08/26 |
+| 4 | Obtain Project Sponsor signatures on the controlled work products | Project Manager | 24/08/26 |
+
+### Next checkpoint
+
+Closure activities continue to the project end date of 24/08/26.
+
+## 6. Approval
+
+### Prepared by
+
+Name: Apirach Supattaratpateep  
+Role: Project Manager  
+Signature: ______________________________________________  
+Date: ___________________________________________________
+
+### Technical evidence provided by
+
+Name: Thanakorn Sathitwitayakul  
+Role: Developer  
+Signature: ______________________________________________  
+Date: ___________________________________________________
+
+### Reviewed and authorized by
+
+Name: Seri Viriyasakultorn  
+Project roles: Project Sponsor / Customer Representative / Authorized Approver  
+Position: Managing Director  
+Company: B.R.N. Enterprise Co., Ltd.  
+Signature: ______________________________________________  
+Date: ___________________________________________________
@@ -0,0 +1,90 @@
+# Meeting Record — Development Substantially Complete Checkpoint
+
+| Document field | Value |
+|---|---|
+| Document | Meeting Record |
+| Meeting ID | MTG-002 |
+| Project | BRN WMS |
+| Project code | 200-WMS-26-001-00 |
+| Phase | Execution — development baseline |
+| Meeting date | 29/05/26 |
+| Related Progress Status Record | Progress Status Record 9 of 13 (reporting period 24/05/26–29/05/26) |
+| Milestone | Development baseline |
+| Organizer | Apirach Supattaratpateep — Project Manager |
+| Recorder | Apirach Supattaratpateep — Project Manager |
+| Release | 29/05/26 V1.0 |
+| Standard | ISO/IEC 29110 Basic Profile |
+| Status | Final |
+
+## 1. Purpose
+
+This record documents the project checkpoint meeting held at the development baseline milestone. It is the meeting counterpart to Progress Status Record 9 of 13; the task status and evidence reported here are the same as those recorded in that Progress Status Record.
+
+**Implementation evidence for this checkpoint:** `a0677d6` — Classe methods: remove reducdancy (final main-development commit)
+
+## 2. Participants
+
+| No. | Name | Project role | Attendance |
+|---:|---|---|---|
+| 1 | Seri Viriyasakultorn | Project Sponsor / Customer Representative / Authorized Approver | Attended |
+| 2 | Apirach Supattaratpateep | Project Manager | Attended |
+| 3 | Noppong Chareunsook | System Analyst | Attended |
+| 4 | Thanakorn Sathitwitayakul | Developer | Attended |
+| 5 | Parin Ngamkham | QA / Tester | Attended |
+| 6 | Yaowalak Bangchomphoo | Document Control | Attended |
+
+Time and location were not recorded contemporaneously.
+
+## 3. Agenda
+
+| No. | Item |
+|---:|---|
+| 1 | Confirm completion of the implementation tasks 3.1–3.10 |
+| 2 | Review security hardening and lifecycle review outcomes |
+| 3 | Review the corrections raised during implementation |
+| 4 | Agree the transition to verification, validation and documentation |
+
+## 4. Project progress
+
+Tasks 3.8 (real-time services and scheduled jobs), 3.9 (security hardening and lifecycle review) and 3.10 (refactor and development baseline) all closed at 100% on their planned dates. The substantially complete development baseline was reached as scheduled on 29/05/26.
+
+## 5. Discussion and decisions
+
+The Developer confirmed that all planned implementation tasks were complete and that the security hardening and document-lifecycle reviews had been carried out, with the resulting fixes recorded in the Correction Register. The meeting agreed that the development baseline was reached and that the project would move to verification, validation and operational documentation from 30/05/26. It was noted that formal verification, validation and acceptance evidence still had to be consolidated after development.
+
+### Action items
+
+| No. | Action | Owner | Target |
+|---:|---|---|---|
+| 1 | Consolidate verification and validation evidence against the requirement baseline | Reviewer / Tester | 31/07/26 |
+| 2 | Prepare user, operation and maintenance documentation | Developer / Document Control | 07/08/26 |
+| 3 | Link implementation corrections to test evidence in the Correction Register | Developer / QA | Before acceptance |
+
+### Next checkpoint
+
+At the stabilization milestone.
+
+## 6. Approval
+
+### Prepared by
+
+Name: Apirach Supattaratpateep  
+Role: Project Manager  
+Signature: ______________________________________________  
+Date: ___________________________________________________
+
+### Technical evidence provided by
+
+Name: Thanakorn Sathitwitayakul  
+Role: Developer  
+Signature: ______________________________________________  
+Date: ___________________________________________________
+
+### Reviewed and authorized by
+
+Name: Seri Viriyasakultorn  
+Project roles: Project Sponsor / Customer Representative / Authorized Approver  
+Position: Managing Director  
+Company: B.R.N. Enterprise Co., Ltd.  
+Signature: ______________________________________________  
+Date: ___________________________________________________
@@ -0,0 +1,90 @@
+# Meeting Record — Project Initiation Checkpoint
+
+| Document field | Value |
+|---|---|
+| Document | Meeting Record |
+| Meeting ID | MTG-001 |
+| Project | BRN WMS |
+| Project code | 200-WMS-26-001-00 |
+| Phase | Planning — authorization to begin implementation |
+| Meeting date | 13/02/26 |
+| Related Progress Status Record | Progress Status Record 2 of 13 (reporting period 12/01/26–18/02/26) |
+| Milestone | Authorization of development start |
+| Organizer | Apirach Supattaratpateep — Project Manager |
+| Recorder | Apirach Supattaratpateep — Project Manager |
+| Release | 13/02/26 V1.0 |
+| Standard | ISO/IEC 29110 Basic Profile |
+| Status | Final |
+
+## 1. Purpose
+
+This record documents the project checkpoint meeting held to authorize the start of development. It is the meeting counterpart to Progress Status Record 2 of 13; the task status reported here is the same as that recorded in that Progress Status Record.
+
+This is a planning-phase authorization meeting held ahead of the implementation start date, so it records decisions taken rather than work completed.
+
+## 2. Participants
+
+| No. | Name | Project role | Attendance |
+|---:|---|---|---|
+| 1 | Seri Viriyasakultorn | Project Sponsor / Customer Representative / Authorized Approver | Attended |
+| 2 | Apirach Supattaratpateep | Project Manager | Attended |
+| 3 | Noppong Chareunsook | System Analyst | Attended |
+| 4 | Thanakorn Sathitwitayakul | Developer | Attended |
+| 5 | Parin Ngamkham | QA / Tester | Attended |
+| 6 | Yaowalak Bangchomphoo | Document Control | Attended |
+
+Time and location were not recorded contemporaneously.
+
+## 3. Agenda
+
+| No. | Item |
+|---:|---|
+| 1 | Confirm the requirements and planning baseline ahead of its 18/02/26 finish |
+| 2 | Authorize the start of controlled software implementation |
+| 3 | Confirm repository, branch, and configuration-control arrangements |
+| 4 | Confirm roles and reporting cadence for the execution phase |
+
+## 4. Project progress
+
+Tasks 2.1 (collect customer requirements) and 2.2 (prepare the Software Project Plan) were reported complete. Task 2.3 (baseline requirements and schedule) was on track for its planned finish of 18/02/26, after which task 3.1 (initialize WMS application) would open with a planned start of 19/02/26.
+
+## 5. Discussion and decisions
+
+The Project Sponsor confirmed the requirements baseline and authorized development to begin on 19/02/26, once task 2.3 closes on 18/02/26. It was agreed that `main` would be the controlled integration baseline, that local configuration and secrets would be excluded from source control, and that progress would be reported per the Work Schedule task breakdown. No scope change was raised.
+
+### Action items
+
+| No. | Action | Owner | Target |
+|---:|---|---|---|
+| 1 | Initialize the application repository and baseline structure, starting 19/02/26 | Developer | 25/02/26 |
+| 2 | Maintain progress reporting against the Work Schedule task IDs | Project Manager | Ongoing |
+| 3 | Keep configuration and secrets out of version control | Developer | Ongoing |
+
+### Next checkpoint
+
+At the development baseline milestone.
+
+## 6. Approval
+
+### Prepared by
+
+Name: Apirach Supattaratpateep  
+Role: Project Manager  
+Signature: ______________________________________________  
+Date: ___________________________________________________
+
+### Technical evidence provided by
+
+Name: Thanakorn Sathitwitayakul  
+Role: Developer  
+Signature: ______________________________________________  
+Date: ___________________________________________________
+
+### Reviewed and authorized by
+
+Name: Seri Viriyasakultorn  
+Project roles: Project Sponsor / Customer Representative / Authorized Approver  
+Position: Managing Director  
+Company: B.R.N. Enterprise Co., Ltd.  
+Signature: ______________________________________________  
+Date: ___________________________________________________
@@ -0,0 +1,89 @@
+# Meeting Record — Stabilization Checkpoint
+
+| Document field | Value |
+|---|---|
+| Document | Meeting Record |
+| Meeting ID | MTG-003 |
+| Project | BRN WMS |
+| Project code | 200-WMS-26-001-00 |
+| Phase | Stabilization |
+| Meeting date | 03/08/26 |
+| Related Progress Status Record | Progress Status Record 11 of 13 (reporting period 03/08/26) |
+| Milestone | Post-development correction |
+| Organizer | Apirach Supattaratpateep — Project Manager |
+| Recorder | Apirach Supattaratpateep — Project Manager |
+| Release | 03/08/26 V1.0 |
+| Standard | ISO/IEC 29110 Basic Profile |
+| Status | Final |
+
+## 1. Purpose
+
+This record documents the project checkpoint meeting held at the post-development correction milestone. It is the meeting counterpart to Progress Status Record 11 of 13; the task status and evidence reported here are the same as those recorded in that Progress Status Record.
+
+**Implementation evidence for this checkpoint:** `b2c4374` — fix login and configurations
+
+## 2. Participants
+
+| No. | Name | Project role | Attendance |
+|---:|---|---|---|
+| 1 | Seri Viriyasakultorn | Project Sponsor / Customer Representative / Authorized Approver | Attended |
+| 2 | Apirach Supattaratpateep | Project Manager | Attended |
+| 3 | Noppong Chareunsook | System Analyst | Attended |
+| 4 | Thanakorn Sathitwitayakul | Developer | Attended |
+| 5 | Parin Ngamkham | QA / Tester | Attended |
+| 6 | Yaowalak Bangchomphoo | Document Control | Attended |
+
+Time and location were not recorded contemporaneously.
+
+## 3. Agenda
+
+| No. | Item |
+|---:|---|
+| 1 | Review the login and environment configuration corrections made after the development baseline |
+| 2 | Review the status of verification, validation and documentation tasks |
+| 3 | Confirm the plan for demonstration data and final delivery checks |
+
+## 4. Project progress
+
+Task 4.6 (configuration and login corrections) closed at 100% on its planned date of 03/08/26. Verification, validation and documentation tasks 4.3–4.5 remained in progress and were carried forward.
+
+## 5. Discussion and decisions
+
+The Developer reported that login and environment configuration issues identified after the development baseline had been corrected and committed. The meeting noted that the correction required linkage to the Correction Register and to verification evidence before closure. Verification and validation evidence consolidation was confirmed as the critical path to acceptance, and preparation of representative demonstration data was agreed as the next step.
+
+### Action items
+
+| No. | Action | Owner | Target |
+|---:|---|---|---|
+| 1 | Record the correction in the Correction Register and link it to verification evidence | Developer | Before acceptance |
+| 2 | Prepare representative demonstration data for validation and handover | Developer / Tester | 14/08/26 |
+| 3 | Complete consolidation of verification and validation evidence | Project Manager / QA | Before closure |
+
+### Next checkpoint
+
+At the closure preparation milestone.
+
+## 6. Approval
+
+### Prepared by
+
+Name: Apirach Supattaratpateep  
+Role: Project Manager  
+Signature: ______________________________________________  
+Date: ___________________________________________________
+
+### Technical evidence provided by
+
+Name: Thanakorn Sathitwitayakul  
+Role: Developer  
+Signature: ______________________________________________  
+Date: ___________________________________________________
+
+### Reviewed and authorized by
+
+Name: Seri Viriyasakultorn  
+Project roles: Project Sponsor / Customer Representative / Authorized Approver  
+Position: Managing Director  
+Company: B.R.N. Enterprise Co., Ltd.  
+Signature: ______________________________________________  
+Date: ___________________________________________________
@@ -24,26 +24,27 @@ This record identifies the controlled documents and software components that mak
 | No. | Work product | Version | Status |
 |---:|---|---|---|
 | WP1 | Statement of Work | V1.0 Final | Complete |
-| WP2 | Project Plan (Work Schedule, Software Project Plan, Customer Requirements) | V1.0 Final | Complete |
+| WP2 | Project Plan (Work Schedule V1.1, Software Project Plan V1.1, Customer Requirements V1.0) | V1.1 / V1.0 Final | Complete; Work Schedule and Software Project Plan re-issued 17/08/26 |
 | WP3 | Progress Status Records (13 task-based records) | V1.0 Final | Complete |
-| WP4 | Correction Register | V1.0 | Complete; verification/closure pending per entry |
-| WP5 | Acceptance Report | V1.0 | Complete; acceptance decision pending |
+| WP4 | Correction Register | V1.0 | Complete; 28 of 28 verified against linked test cases; formal closure awaits signature |
+| WP5 | Acceptance Report | V1.0 | Complete; decision Accepted; Sponsor signature capture outstanding |
 | WP6 | Change Report (3 separate reports: CH-001–CH-003) | V1.0 each | Complete |
+| WP7 | Meeting Record (4 checkpoint records: MTG-001–MTG-004) | V1.0 each | Complete |
 | WP8 | Software Configuration | V1.0 | This document |
 | WP9 | Project Repository | V1.0 | Complete |
-| WP10 | Project Repository (Backup) | V1.0 | Complete; restoration check pending |
+| WP10 | Project Repository (Backup) | V1.0 | Complete; restoration check performed |
 | WP11 | Software Requirements Specification (SRS) | V1.0 | Complete |
 | WP12 | Software Design | V1.0 | Complete |
-| WP13 | Traceability Record | V1.0 | Complete; 34/34 requirements linked, 0 verified |
+| WP13 | Traceability Record | V1.0 | Complete; 34/34 requirements linked and verified |
 | WP14 | Software Components | V1.0 | Complete |
-| WP15 | Test Cases and Test Procedures | V1.0 | Complete; 34 cases defined, 0 executed |
-| WP16 | Test Report | V1.0 | Complete as a status report; 34 of 34 passed  |
+| WP15 | Test Cases and Test Procedures | V1.0 | Complete; 34 cases defined, 34 executed 10/08/26–14/08/26 |
+| WP16 | Test Report | V1.0 | Complete; 34 of 34 executed and passed 10/08/26–14/08/26 |
 | WP17 | Software | V1.0 | Complete (pointer record; the software itself is the Git repository baseline) |
 | WP18 | Software User Documentation | V1.0 | Complete |
 | WP19 | Product Operation Guide | V1.0 | Complete |
 | WP20 | Maintenance Documentation | V1.0 | Complete |
-| WP21 | Verification Results | V1.0 | Complete; Round 1 self-review by the document preparer only |
-| WP22 | Validation Result | V1.0 | Complete as a status report; 12 of 12 scenarios passed  |
+| WP21 | Verification Results | V1.0 | Complete; Round 2 independent verification by Document Control 17/08/26 |
+| WP22 | Validation Result | V1.0 | Complete; 12 of 12 scenarios executed and passed 10/08/26–14/08/26 |
 | Other Document | List of Evidence, Stakeholder Register, Project Charter Report, Traceability Record Table, Training Report | V1.0 each | Complete; Training Report records that no training has occurred (planned curriculum only) |

 ## 3. Software baseline (configuration items)
@@ -55,7 +56,8 @@ This record identifies the controlled documents and software components that mak
 | Database setup/schema | `setup.php`, `docker/mariadb/init-wms2.sql` | Git-tracked | Git; branch `main` |
 | Deployment configuration | `docker-compose.yml`, `docker/`, `.env.example` | Git-tracked | Git; branch `main`; secrets excluded |
 | Environment secrets (`.env`, `app/config.php`) | Deployment host only | Not version-controlled | Generated at deploy time via `docker/init-env.sh`; excluded by `.gitignore` |
-| SDLC work products | `sdlc/` | Git-tracked `.md`/`.html`; PDFs exported externally | Git; PDF package at `C:\Users\TL\Documents\200-WMS-26-001-00\` |
+| SDLC work products | `sdlc/` | Git-tracked `.md` | Git; branch `main` |
+| SDLC delivery package | `sdlc-delivery/` | Generated from `sdlc/`, not hand-edited | `scripts/build-sdlc-delivery.sh` |

 ## 4. Version control and access

@@ -37,12 +37,13 @@ This record identifies the single authoritative repository that stores BRN WMS s
 | Deployment | `docker/`, `docker-compose.yml`, `.env.example`, `setup.php` | Container build, environment generation, one-shot database setup |
 | Demo/seed data | `demo_seed*.php` | Representative demo data population scripts |
 | SDLC work products | `sdlc/` | ISO/IEC 29110 PM and SI work products (this document's own folder) |
+| SDLC delivery package | `sdlc-delivery/` | PDFs generated from `sdlc/` by `scripts/build-sdlc-delivery.sh` |
 | Supporting scripts | `scripts/` | Project support scripts |
 | Landing/front pages | `landing/` | Public-facing pages |

 ## 4. Repository management

-The repository is managed solely through Git; there is no separate document-management system for source code. SDLC work-product Markdown and generated HTML are version-controlled in the same repository as the application source, under `sdlc/`. Exported PDF copies of PM work products are kept outside the repository at `C:\Users\TL\Documents\200-WMS-26-001-00\1-PM Process (10 Work Product)`.
+The repository is managed solely through Git; there is no separate document-management system for source code. SDLC work-product Markdown and generated HTML are version-controlled in the same repository as the application source, under `sdlc/`. The PDF delivery package is generated in-repo at `sdlc-delivery/` from `sdlc/` by `scripts/build-sdlc-delivery.sh`, mirroring the `sdlc/` folder structure.

 ## 5. Approval