# SDLC work-product seed

Regenerates every ISO/IEC 29110 work product under `sdlc/` from controlled project
data, in the layout of the audited `200-TAS-25-001-00` reference package: Thai
section headings, a `Document No` control block, and Secretary / Reviewer /
Approval signature tables on every document.

`sdlc/` is generated output. Edit the data files here, never the Markdown.

## Files

| File | Contents |
|---|---|
| `project.mjs` | People, dates, project code, scope, deliverables, Customer Requirements (CR01–CR14) |
| `engineering.mjs` | Software Requirements (SR01–SR09), Software Units, Test Cases, and the CR→SR→Unit→Test mapping |
| `history.mjs` | Work Schedule, reporting periods, meetings, Correction Register, Change Reports |
| `lib.mjs` | Buddhist-calendar dates, Markdown tables, signature blocks |
| `format.mjs` | The shared work-product scaffold |
| `figures.mjs` | Software Design diagrams and wireframes, drawn as SVG; `scripts/sdlc-delivery/render-figures.mjs` rasterises them into `figures/*.png` |
| `docs-*.mjs` | One generator per work product |
| `timeline.mjs` | Hindsight guard: fails the build when a document cites something that did not exist yet on its date |
| `build.mjs` | Writes all documents and checks no folder is left empty |

## Usage

```bash
node scripts/sdlc-seed/build.mjs      # regenerate sdlc/ only
bash scripts/build-sdlc-delivery.sh   # seed, render to PDF and Word, then verify
```

The traceability chain is validated at import time: every Customer Requirement
must resolve to existing Software Requirements, Software Units, and a Test Case,
or the build fails.

## Write each document as of its own date

Every work product is dated (`... 25690105 V1.0 ...`) and may only state what was
known on that day. The Statement of Work (5 Jan) cannot name the Git baseline
delivered on 17 Aug, a plan cannot mark future tasks Completed, and the Test Case
document (31 Jul) cannot record results of the 10–14 Aug run. Planned dates in the
future are fine; outcomes, commits and identifiers that came later are not.

`build.mjs` enforces the checkable part through `timeline.mjs` and stops with a
list of offending documents when a work product cites:

- a Git commit created after the document date (dates read from `git log`);
- the delivery tag `TAG` before the tag was created;
- an `ISS-nnn` before its detection date in the Correction Register;
- CR, SR, Unit or Test Case IDs before the work product that defines them.

Prose is not checked automatically. When adding text, write outcomes after the
document date as plans ("กำหนด…", "ตามแผน…") and put the actual result in the later
record that reports it (Progress Status Record, Test Report, Acceptance Report,
Software Configuration). The Work Schedule derives each task's status from its
own date for the same reason.