Add project plan, milestones and SQA framework; document actual capabilities

Adopt the SQA/QC framework as a submodule and plan the project before any
further code: Business Case, Stakeholder Analysis (S01-S05), Project Plan with
use case candidates and prioritisation, and milestones MIL-001..MIL-004
(24 tasks, synced to Gitea as milestones 18-21 and issues #1-#24).

README now separates implemented from planned capabilities, has an English
sequence diagram and points at the scoped workflow. The workflow file moves
out of the repository root and out of .gitea/workflows/; the scoped copy is
unchanged in behaviour here and still contains the known `exit 0` syntax
error, which MIL-001 fixes.

Refs #1
Refs #2
Refs #3
Refs #6

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>

AGENTS.md

@@ -0,0 +1,53 @@
+# AGENTS.md
+
+This project uses the SQA and QC framework mounted at `framework/`.
+
+For any document under `docs/` (create, edit or review) use the `artifact`
+skill. For planning a project or a phase into tasks, and syncing phases and
+tasks to Gitea/GitHub as Milestones and Issues, use the `project-planning`
+skill. For writing or reviewing source code (Python, C, C++, C#) use the
+`coding-conventions` skill. Skills are read from `.agents/skills/` (this harness and Codex CLI)
+and `.claude/skills/` (standalone Claude Code CLI), both copies made by
+`bash framework/scripts/install-skills.sh` — re-run it after updating the
+framework.
+
+**Never commit, push or open a PR unless asked.** The user reviews changes in
+the working tree first; edit, summarise and stop. The commit/PR rules below
+apply once a commit has been asked for.
+
+## Workflow order
+
+Business Case, Stakeholder Analysis, Project Plan, milestones, tasks synced as
+issues, then code. Nothing goes under `src/` or `tests/` unless a milestone
+document (`MIL-*`) is accepted and the task is a row in it (ideally a synced
+issue). If those are missing, plan with the `project-planning` skill, show the
+dry-run output of `bash framework/scripts/sync-project.sh`, and stop. The rule
+is defined once in `framework/process/plan-first-gate.md`.
+
+A "build X" request is planning-first: produce the plan and issues, then ask
+for a go-ahead. Only the user can waive the plan, in chat, for that request.
+Before planning, find the Product Owner's language (the prompt, or the
+`Languages` section of `docs/artifact-registry.md`); if neither states it, ask.
+
+To enforce the gate at commit time, run
+`bash framework/scripts/install-git-hooks.sh --enable-plan-gate`: a commit that
+changes `src/` or `tests/` then needs a `Task: MIL-NNN#N` trailer.
+
+Rules that apply to every document:
+
+1. Get the short name from `framework/registry/artifact-catalog.md` and the
+   next version from `docs/artifact-registry.md`. Create files with
+   `bash framework/scripts/new-artifact.sh <SHORT>`.
+2. Owners, reviewers and RACI use stakeholder IDs from the project's
+   Stakeholder Analysis, never invented role names.
+3. Every QC criterion is tagged with an ISO/IEC 25010:2023 characteristic.
+4. Every reviewed instance gets an `RC-*` record in `docs/sqa/reviews/`.
+5. Do not edit `framework/` from this project; propose changes upstream.
+6. Every PR description closes the issues its work completes, one
+   `Closes #N` per line (`Refs #N` for partial work); see the
+   `project-planning` skill.
+7. Every document's `## Version History` has `Change` and `Commit` columns and
+   keeps the two latest rows. After committing, run
+   `framework/scripts/resolve-pending-commits.sh` and commit the result before
+   opening the PR (no amend). Never ask for or perform the merge: a reviewer
+   merges.