Add Pretty Table project: plan, accepted documents and code

Business Case, Stakeholder Analysis, Project Plan and milestone MIL-001
with review records RC-001 to RC-003, then the Python project: PrettyTable
Pokemon table, constants, pytest tests, pyproject.toml, Doxyfile, CI
workflow and README.

Task: MIL-001#1
Task: MIL-001#2
Task: MIL-001#3
Task: MIL-001#4
Task: MIL-001#5
Task: MIL-001#6
Task: MIL-001#7
Task: MIL-001#8

AGENTS.md

@@ -0,0 +1,60 @@
+# 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, each step reviewed before the next (an artifact is done when
+its `RC-*` says `Go` and its row is `Accepted`; code is reviewed against its
+`qc-programming-*` checklist before the pull request). Nothing goes under `src/`
+or `tests/` unless a milestone document (`MIL-*`) is accepted, its latest review
+is a `Go`, 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.
+Each artifact type the registry marks "Written in the PO language" exists once,
+in that language, under its normal name; there is no translated twin. Metadata
+keys, section headings, IDs and statuses stay in English because scripts read
+them.
+
+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 for an
+accepted, reviewed milestone.
+
+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.