8. Appendix

8.1 Release notes

Requirements: none - the version history of the design.

The design is versioned, one minor version per pull request that changes it and a major version only when a human says so, newest first; every version is tagged v<version> in every repository. Only the current major version is listed here: the older versions are in the Git tags, the last before v4.0 being v3.8. The version is shown in the site’s header and on the covers of the PDFs (how to add an entry).

v4.5 - 2026-10-21

• Page 1.5 Developer experience tells the three journeys of an application team as use cases - onboarding a new application, migrating an existing one and operating the ones in production (#119).
• Requirements R33 (the non-negotiable rules: the patch timetable binds every application, automated tests are the only gate) and R34 (previews per pull request and sandboxes per team inside dev), with their acceptance criteria, R23 and R24 allow jobs, scheduled jobs and queue consumers, and R22 says that an application is reached from outside its namespace only as HTTPS on 443 through the gateway and uses any protocol inside it; the design states platform-owned base images, the non-serving workloads of 3.4 rebuilt and promoted by the base image agent, and the preview and sandbox namespaces of dev (#119).

v4.4 - 2026-10-20

• The requirements table is ordered by the design’s reading order and numbered R1 to R32 without sub-letters, so the requirements a page cites sit together; every reference follows the new numbers (#118).

v4.3 - 2026-10-20

• The site has a Lab examples section beside the requirements and the design, generated by the documentation agent and in neither PDF (#114).

v4.2 - 2026-10-20

• Page 3.3 shows the stateless rollout with Flux and the stateful pipeline in two separate, readable pictures (#112).

v4.1 - 2026-10-20

• How we work is the front page, shorter and without what the requirements already say; the requirements PDF holds only the requirements and the acceptance criteria (#110).

v4.0 - 2026-10-20

• Requirements-driven collaboration: the requirements and acceptance criteria are in requirements/, owned by humans (part 0, page 0.1 How we work), and the design is in design/, owned by AI; a required Approvals check asks a human to approve a change to requirements/ and the AI to review a change to design/ (#109).
• The requirement texts of 1.2 are page 0.2 and design 1.2 shows how the design meets each of them; the acceptance tests of 7.1 are page 0.3 (#109).
• What no requirement names moved to the unpublished archive/: the pages 7.1 Implementation project and acceptance testing, 7.4 Outlook and the options kept open and 7.5 Other clouds, sovereignty and exit (its data services joined 1.3), and sections of 1.0, 1.2, 2.3 (GPUs), 4.1, 5.1, 5.2, 6.2, 7.2 and 7.3 (#109).
• Every design page names the requirements it serves under its title, and check.sh checks it; every link to a requirement jumps to its row in 0.2 (#109).
• The pages with a picture no longer repeat it in prose; the text keeps what the picture cannot show (reasons, decisions, numbers, exceptions) (#109).
• Two PDFs: the design with every design page, the summary first, and the requirements (#109).
• The decision log (7.2) and the open questions (7.3) left the design for archive/: the design states only what is chosen, without decision, sign-off or verification numbers (#109).