Design principles

The principles every part of the build follows (section 2). Generated from requirements v0.5 by scripts/gen-requirements.ts; do not edit by hand. Cite one as req:aai-design-principles#<ID>.

ID	Level	Requirement
DP-01	SHALL	Create once, show many times. One issue can appear in several projects. Never clone an issue to report its status somewhere else.
DP-02	SHALL	Workstream leads own their delivery. The agent creates programme epics and the workstream template. It does not create features or stories in workstream repositories.
DP-03	SHALL	Programme work is not sprint work. Sprints are managed inside the workstream projects. The programme project tracks dates, milestones, delivery health and readiness, not sprints.
DP-04	SHALL	Open by default, and public. Everything on GitHub is public. What must not be public (section 6) is not put on GitHub.
DP-05	SHALL	Technical integration judgements sit with the Technical Integration Lead. The Technical Integration Lead owns technical integration readiness and validation, working with the relevant workstream leads and subject-matter experts. The role is currently held by the WHO WS1 lead, but the authority comes from the role, not from WS1. The PM manages sequencing, dates, dependencies, evidence and escalation, and does not make technical readiness judgements.
DP-06	SHALL	Automation must not make judgements. Automation may make deterministic administrative updates, such as adding items, lifecycle status changes and flags raised from labels. It never makes readiness, approval, risk-acceptance or decision judgements.
DP-07	SHALL	Keep it simple. Delivery health, risk category, impact and dates only. No probability or impact scoring model.
DP-08	SHALL	Prove it small before building it big. A pilot build (section 12) must pass before any bulk import.
DP-09	SHALL	Plain language. All titles, field options, view names and READMEs use plain, simple English. Use the role name “PM & Architecture Integration” exactly as written.