docs(sdlc): write each work product as of its own date

- SOW, plan and design no longer cite the Aug baseline commit or the package tag
- Work Schedule status derived from its date; Test Case has no results yet
- build fails when a document cites a later commit, tag, ISS or ID (timeline.mjs)

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

scripts/sdlc-seed/README.md

@@ -18,6 +18,7 @@ Approval signature tables on every document.
 | `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
@@ -30,3 +31,25 @@ bash scripts/build-sdlc-delivery.sh   # seed, render to PDF, 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.