wms-app/sdlc/SDLC_DOCS.md

SDLC Documentation Handoff

Current project status as of 17/08/26: CH-004 revises the project period to 05/01/26–24/08/26, with 14/08/26 retained as the original baseline. The project user retrospectively confirmed completion of verification, all 34 tests, all 12 UAT/validation scenarios, acceptance authorization, and closure activities ahead of the revised target. Final manual review and signature capture remain before export.

1. What we just built

This repository is preparing a full ISO/IEC 29110 Basic Profile work-product set for BRN WMS, a browser-based multi-company/multi-warehouse management system (PHP + two MariaDB databases + Node.js/Socket.IO real-time/scheduler services).

• Project code: 200-WMS-26-001-00
• Project name: BRN WMS / โครงการพัฒนาระบบบริหารจัดการคลังสินค้า
• Approved project period: 05/01/26–24/08/26 (original baseline: 05/01/26–14/08/26)
• All work products live under sdlc/, organized as 1-PM Process (10 Work Product)/, 2-SI Process (12 Work Product)/, 3-Other Document/

Reference package: /mnt/c/Users/TL/Documents/brn-ISO29110 (Windows: C:\Users\TL\Documents\brn-ISO29110) is an earlier, completed ISO 29110 project for the same company (project code 200-TAS-25-001-00, a corporate website project). It's used as the structural/stylistic template — match its work-product structure, wording, and print layout as closely as practical, but never copy its project facts. BRN WMS facts and Git evidence always take precedence. Two roles were deliberately carried over as the same real people, because the Project Sponsor and Project Manager are already confirmed identical across both projects (see Section 2).

End-to-end status: every one of the 22 canonical ISO 29110 work products (PM 1–10, SI 11–22) plus all 5 3-Other Document items now has a complete Markdown draft — 48 controlled work-product files total, including multi-instance records. Nothing under sdlc/ is empty. This was built in stages this session:

1. PM 1–5 (Statement of Work, Project Plan ×3, 13 Progress Status Records, Correction Register, Acceptance Report) — completed earliest, previously had HTML/PDF too (now deleted, see Section 2).
2. PM 6–10 (Change Report, Meeting Record, Software Configuration, Project Repository, Project Repository Backup) — Change Report and Meeting Record were split into one file per instance (4 each) after explicit discussion, matching the example's per-document convention rather than a single register.
3. SI 11–22 (SRS through Validation Result) — traced at Customer-Requirements granularity (34 requirements: FR-001–024, NFR-001–010), not the example's much finer CRUD-button granularity, since BRN WMS is a far larger system (31 backend classes vs. the example's ~6 modules).
4. 3-Other Document (List of Evidence, Stakeholder Register, Project Charter Report, Traceability Record Table, Training Report) — matches the example's 5-item roster, with two deliberate deviations explained in Section 4.
5. Several rounds of consistency auditing and role/content corrections — see Section 2 for what was found and fixed.

2. Current working status / files edited

Document completion state

Area	State
PM 1–5 (Statement of Work; Work Schedule; Software Project Plan; Customer Requirements; 13 Progress Status Records; Correction Register; Acceptance Report)	Markdown complete. All 19 HTML files and the exported PDF package were deleted 17/08/26 at the user's explicit direction (see below) — every file needs re-export from its current .md via VS Code Markdown PDF, HTML fine-tuning, then re-print to PDF.
PM 6–10 (Change Report ×4, Meeting Record ×4, Software Configuration, Project Repository, Project Repository Backup)	Markdown complete. HTML/PDF never yet produced.
SI 11–22 (SRS, Software Design, Traceability Record, Software Components, Test Cases, Test Report, Software, User Documentation, Product Operation Guide, Maintenance Documentation, Verification Results, Validation Result)	Markdown complete. HTML/PDF never yet produced.
3-Other Document (List of Evidence, Stakeholder Register, Project Charter Report, Traceability Record Table, Training Report)	Markdown complete. HTML/PDF never yet produced.

Corrections and additions made this session (why the HTML above is stale/missing)

Roles added — two people added to the confirmed roster, both at the user's explicit direction:

• ปริญ งามขำ, QA / Tester — independent of the Developer, now responsible for Test Cases (WP15), Test Report (WP16), and Validation Result (WP22). Added because the project previously had no independent tester (self-testing by the developer).
• คุณเยาวลักษณ์ บางชมภู, Document Control — carried over from the example reference project's identical role, on the same basis the Sponsor and PM were already carried over (same company, same people). Not yet performed any actual document review — being named ≠ work being done (see evidence discipline, Section 4).

Both were propagated to: SDLC_DOCS.md roster (below), Customer Requirements Section 3, Stakeholder Register, Software Project Plan (Organization table + new headcount table), and the relevant SI work products.

Traceability Record (WP13) — two real gaps found and fixed:

1. Added a "Correction/Change reference" column to the 34-row requirement matrix, plus a new Section 5 reverse cross-reference table (every one of the 29 Correction Register entries and 4 Change Report entries → its Git commit → the requirement(s) it affects). 18 of 34 requirements now show at least one link. CoR-010 is explicitly left unresolved (no recorded cause in the original correction) rather than guessed.
2. Cross-checked every ID cited (Req ID, SRS ID, Design Unit ID, Test Case ID, Correction ID) against its source document, and every Git commit hash against real git log. Found zero phantom/invented references, but found 15 SRS IDs and 1 Design Unit ID (UN12, StockTablesTrait) that existed in WP11/WP12 but weren't linked to any requirement row — now linked. 3 SRS items are noted as intentionally cross-cutting rather than forced into one row.

Correction Register (WP4): 10 "Git evidence" citations were truncated/paraphrased instead of verbatim commit subjects — tightened to exact git log text. No content/decision changed, just accuracy.

Acceptance Report (WP5): refreshed to reflect the completed work-product set and the project user's retrospective confirmation of verification, test/UAT completion, acceptance authorization, and closure readiness.

Work Schedule: verification, validation, test execution, and UAT were subsequently confirmed complete by the project user on 17/08/26; the controlled result records now identify this as retrospective user-confirmed evidence.

Software Project Plan — after actually reading the example's full PDF (not just headings), found 5 real structural gaps and closed them (doc grew from 17 to 18 top-level sections):

1. New Section 6, "Software development lifecycle methodology" — deliberately does not copy the example's "Waterfall" claim; Git evidence shows continuous incremental delivery instead (features and security fixes interleaved throughout, not phase-separated), and the document says so.
2. New Section 8.1, "Human resources and effort estimate" — states headcount (1 person per role) and calendar-duration-by-phase, and explicitly states why no man-day effort figure is given: no time-tracking evidence exists, so one is not fabricated (same treatment as budget, below).
3. New Section 8.5, "Computer and equipment resources" — discloses no equipment inventory exists rather than inventing one.
4. New Section 11.1, "Contingency actions for non-completed tasks."
5. New Section 12.2, "Quality criteria and evaluation methods" — cross-references existing SRS/NFR content instead of duplicating it.
6. Also added Section 16.1/16.2, stating BRN WMS's actual file-naming and version convention explicitly in the deliverable itself (previously this only lived in this handoff file) — see Section 4 for the convention itself.

Progress Status Record 13 (the last of the 13): its reporting period (15/08/26–17/08/26) remains historical evidence of the original closure overrun. CH-004 subsequently revised the closure target to 24/08/26.

List of Evidence, Verification Results, Project Repository (Backup), Product Operation Guide: each got the same-day status callout / role-name / disclosure updates described above where applicable.

Budget: deliberately not disclosed anywhere (Project Charter Report says so explicitly) — no contemporaneous budget record exists, so no figure is fabricated, unlike the example's ฿350,000 breakdown.

Database backup: developer-reported as a daily mysqldump script, output stored off-server with a retention policy — real information, but schedule/location/retention specifics and restoration testing are still open (Product Operation Guide item OP-001; Project Repository Backup items BK-001/BK-002).

Existing roles (confirmed roster)

Person	BRN WMS role
คุณเสรี วิริยะสกุลธรณ์	Project Sponsor / Customer Representative / Authorized Approver; Managing Director
คุณอภิรัชต์ สุภัทรประทีป	Project Manager
ธนกร สถิตวิทยากุล	Developer / System Analyst
ปริญ งามขำ	QA / Tester — added 17/08/26, independent of the Developer
คุณเยาวลักษณ์ บางชมภู	Document Control — added 17/08/26, carried over from the example project's same role/person, same company

Rule: the developer must never be presented as the independent approver of their own document. Use the Project Manager or Sponsor for review/approval per the example and available evidence. Do not invent additional named people — use TBD when a role is genuinely required but unassigned (currently none are TBD; all confirmed roles above are filled).

Naming, date, and version conventions

• Display dates as Gregorian DD/MM/YY (e.g. 09/03/26); filenames use compact Buddhist-calendar dates (e.g. 25690105).
• Filename pattern: [Project code] [Document name][ - distinguishing suffix if multi-instance] [YYYYMMDD Buddhist] V[version].
• Deviation from the example, on purpose: do not append author initials (example uses ...V1.0 ApS.pdf; BRN WMS does not).
• Deviation from the example, on purpose: no 0.1/0.2 Draft staging — documents release directly at V1.0 once complete. "Final" is document-control status, not proof of signature.
• Git-supported implementation begins 19/02/26; development substantially complete 29/05/26; stabilization evidence 03/08/26; agreed completion boundary 14/08/26.

HTML formatting decisions (for the fine-tuning step, once HTML exists)

• Statement of Work: A4 portrait formal letter; BRN emblem, company name/address, blue title band, signature area on the final page.
• Work Schedule: A4 landscape spreadsheet; dark-blue document bar, dense grid, repeated headers, separate approval page.
• Software Project Plan: A4 portrait multi-page; corporate header, blue section bars, controlled tables, approval page.
• Use app/assets/images/brn-document-header-left.png (derived from app/assets/images/brn-document-header.png) in every generated SDLC HTML document; render the blue/grey title band in HTML per-document. Never use the BRN WMS product logo as the company logo.
• Preserve the header image's aspect ratio — 25mm height corresponds to its approved width; don't change one dimension independently. Keep the title band right-aligned.
• Document-control tables: dark-blue header row/white text, light-blue label column, thin grey borders, consistent padding.
• Light blue for item/section headers only inside Customer Requirements — don't touch the corporate title band styling.
• Tables: prefer table-layout: auto; ID/status columns width: 1% + white-space: nowrap; description/value columns take the rest. Don't force unnecessary width.
• Chrome Print Preview: A4, Default/100% scale, Background graphics enabled. Landscape only where required (currently just Work Schedule).
• Software Design's Use Case/Component/Deployment diagrams and representative UI screenshots get added at the HTML stage, not in Markdown.
• Do not use scripts/format_progress_status_html.php — rejected earlier as less useful than direct per-document HTML formatting.

3. Next immediate tasks

1. Re-export PM 1–5 to HTML (all deleted 17/08/26), then convert PM 6–10, SI 11–22, and 3-Other Document to HTML for the first time — all via VS Code Markdown PDF (user-driven step).
2. AI fine-tunes each generated .html to A4 print layout per the conventions in Section 2 — reapply PM 1–5's previously-established per-document layouts (they were deleted, not the decisions), match the example's per-document form for Change Report/Meeting Record, match the example's table/layout style for SI documents that have an example equivalent, and use shared document-control conventions for documents with no example equivalent (Software Components, Software, Maintenance Documentation, Project Repository, Project Repository Backup, and all 3-Other Document items except where the example is deliberately not duplicated — see Traceability Record Table's Deviation note).
3. User prints each finished HTML to PDF and re-exports the PM 1–5 PDF package to C:\Users\TL\Documents\200-WMS-26-001-00\1-PM Process (10 Work Product), replacing the stale copies there.
4. Independently confirm the backup Git remote is actually in sync (currently developer-reported only) and perform a restoration check (BK-001, BK-002).
5. During manual review, confirm the retrospective user-confirmed test, UAT, verification, and acceptance wording is appropriate for final sign-off.
6. Capture any available tester, environment, execution-date, reviewer, attendee, and Sponsor-signature details in the relevant controlled records.
7. Confirm the final project-closure/signature date to be used in exported documents, within the approved period ending 24/08/26.
8. Record the mysqldump backup's exact schedule, off-server destination, and retention period in a controlled reference (Product Operation Guide item OP-001).
9. Schedule and conduct user training (a planned curriculum already exists in the Training Report; no session has occurred).
10. Do not restore the legacy 200-TAS-* PDFs that were cleared from the completed-package PM 6–8 folders on 17/08/26 — populate those folders only with BRN WMS work products.

4. Architectural constraints and decisions

Application scope (as reflected in the SDLC documents)

BRN WMS covers: multi-company/role-based access; inventory and warehouse operations (stock in/out/transfer, lot/serial/expiry, barcode); sales (quotation/order/invoice/return); purchasing (request/order/invoice/supplier-return); finance (receipts/payments); accounting (chart of accounts, journals, GL); reporting; controlled document numbering; Node.js/Socket.IO notifications and scheduled jobs; Docker Compose or manual LAMP deployment. Two MariaDB databases: wms (identity/company) and wms2 (WMS/accounting). 31 PHP manager classes under app/assets/utils/classes/.

Evidence discipline (the single most important working rule)

• Never claim a test, meeting, verification, validation, or acceptance occurred unless there is real evidence (a Git commit, or an explicit developer/user statement) — always disclose when something is reconstructed or still pending rather than presenting it as contemporaneous or complete.
• Status fields default to "pending" / "not yet executed" / "TBD" until real evidence exists. Don't flip them to "complete"/"passed" just because documentation work finished — documentation completeness and activity completeness are different things (this came up explicitly: the project stays WIP for exactly this reason, confirmed by the user after discussing ISO surveillance-audit use).
• Reconstructed planning activities (most of this project, since documentation was written after implementation) are acceptable only when transparently labeled as reconstructed.
• Never fabricate a figure with no evidentiary basis (budget, effort in man-days, equipment inventory) — state plainly that it isn't disclosed/available instead. This has been applied consistently three times: Project Charter budget, Software Project Plan effort, Software Project Plan equipment.
• When restating the example package's content (methodology, structure), don't just copy it if BRN WMS's actual evidence contradicts it — e.g., the example says "Waterfall," BRN WMS's Git history shows incremental/evolutionary delivery, so the SPP says the latter and explains why.
• Cross-document consistency matters more than making things look finished: verify every cited ID/commit hash actually exists in its source before trusting it. This class of check found and fixed real gaps twice this session (Traceability Record's ID linkage, Correction Register's commit-message accuracy) — worth repeating periodically, e.g. before major HTML/PDF export passes.
• Avoid unnecessary duplication of the same data across documents where two copies could drift out of sync — e.g., the Other Document "Traceability Record Table" is a pointer/summary to the single master matrix in SI work product 13, not a second full copy (explicit user decision after being asked).

Repository safety

• The repository has unrelated, pre-existing application changes — do not revert, reset, or overwrite them while working on SDLC documents.
• Limit changes to sdlc/, SDLC_DOCS.md, and explicitly requested support files.
• sdlc/ is entirely gitignored — there is no git safety net for anything under it. Deletions (e.g., the PM 1–5 HTML purge on 17/08/26) are not recoverable via git; treat delete operations there with the same care as anywhere else, but know that git status/git stash won't help if something goes wrong.

5. Manual review and edit notes

Use this space for any final human edits, comments, or review notes before HTML/PDF export.

Document / area	Manual edit, comment, or confirmation	Reviewer	Date