Project plan and git workflow

[erikhfj]

Agree how we work so the process itself is part of the grade.

• milestones M1–M4 matching the four underveisinnleveringer
• labels for area / quality
• branch naming feat/<issue>-short-name
• conventional commits referencing the issue
• PR + peer review before merge (CODEOWNERS)

Acceptance: documented in README and everyone has merged at least one PR through it.

[erikhfj]

Before you open the PR: implement from the requirement, not by copying from archive/scaffold-prototype. The prototype is a reference you can check against when you get stuck. It is not a source to paste from.

The PR description must say what was done and what was tested. That is what we read when we review.

[erikhfj]

Plan (erikhfj, 24.09)

What the requirement asks for: that we document how we work (branches, commits, PRs, reviews) so the process itself is readable for fellow students and the course staff. On top of that, an AI log that actually shows our own control, not just which tools were used.

How I plan to solve it:

• docs/WORKFLOW.md: branch pattern feat/<issue>-short-name, conventional commits referencing the issue, PRs with one reviewer who is not the author, and the rule that the reviewer asks at least one real question.
• docs/AI-USAGE.md as a decision log per PR, not a credits list. Format: what I asked for / what I took / what I changed or rejected and why / what the reviewer pushed me on. The first entry explains the prototype branch and why it was not merged.
• A short README update covering the workflow and the links.

Unsure about: how much we should write about the prototype in the log. Too little looks like we are hiding it. Too much takes over the log. I am aiming for one honest paragraph explaining what it was for and why it is not the deliverable.

Not copied from the prototype. This is written from what the group actually agreed on this week.