spec-file updates

specs/S7_define-coding-standards-to-be

@@ -1 +1,41 @@
-Create a file (or append to it) CODING_STANDARDS.md and have the coding standards in there, for the review skill. 
+As developer
+I want anyone, including agents to follow coding standards for the agiledancers-be folder
+so that the code stays readable and maintainable.
+
+The coding style should be desribed in CODING_STANDARDS.md. If the file does not exist, create it. If the file does exist, don't remove instructions for the front-end (Angular). This spec will ony do coding-standards for the backend (Java). 
+
+Make sure agents use these coding_standards as wel when coding or reviewing (with the code-review skill in the skills-folder). 
+
+For the guidelines we start with the guidelines described at https://www.geeksforgeeks.org/java/coding-guidelines-in-java/ as a basis.
+When we have a collision with the Java Palentir formatter this project uses, we will always favour the Palentir formatter. 
+For curly braces, we use the variant: A curly brace is applied at the end of the line that starts the class, method, loop, etc.
+Block comments will be enwrapped with /* and */. The actual text is on sererate lines and indented. Example:
+/*
+    This is an example of a blocked comment.
+    It may have more than one line.
+*/
+
+if-, for-, and while-loops must always have curly braces. 
+
+De volgende metrics moeten gehaald worden, met een streefwarde, een review-signal, en een absoluut maximum:
+Metric | Streefwaarde | Reviewsignaal | Blokkerende grens
+Cyclomatic complexity per methode/constructor | ≤ 5 | > 7 | > 10
+Cognitive complexity per methode | ≤ 10 | > 10 | > 15
+Methodlengte, zonder lege regels en commentaar | ≤ 20 regels | > 30 | > 50
+Parameters per methode | ≤ 3 | > 4 | > 5
+Parameters per constructor | ≤ 4 | > 5 | > 7
+Geïnjecteerde dependencies per klasse | ≤ 4 | > 5 | > 7
+Fan-out per klasse, unieke gebruikte types | ≤ 10 | > 15 | alleen review
+Depth of Inheritance Tree, eigen superclasslagen, exclusief Object | ≤ 1 | > 2 | > 3
+Nesting van control flow | ≤ 2 niveaus | > 3 | > 4
+Duplicated lines density | ≤ 1% | > 1% | > 3%
+Klasselengte, zonder lege regels en commentaar | ≤ 200 regels | > 300 | > 500
+Publieke methoden per klasse, exclusief triviale accessors | ≤ 10 | > 15 | Geen automatische grens
+
+De code-review skill wordt hier ook van op de hoogte gebracht. 
+De test-coverage moet minimaal 80% zijn. Dit mag gehaald worden met een combinatie van unit- en e2e-testen. unit- en e2e-testen mogen afzonderlijk onder de 80% blijven. 
+Indien mogelijk, wordt de ArchitectureTest geupdate of wordt er een nieuwe test gemaakt om zaken te controleren die met een test te controleren zijn. Verder mogen checks uitgevoerd worden met CheckStyle, FindBugs and PMD, plus eventuele andere checks die ze aanbevelen. Tot slot mogen er PIT-testen worden gemaakt om de code-coverage te checken. 
+Het toeveogen van een geconfigureerde Sonar in de pipeline is out-of-scope. Dit doen we later met spec S14. 
+
+The current code-base should be updated to adhere to these coding standards. 
+

specs/implemented/S9_spread-dancegroups-via-ortools-setup

@@ -1,6 +1,6 @@
 # S9 — Schedule dance groups across show dayparts with OR-Tools
 
-Status: IN_REVIEW
+Status: IMPLEMENTED
 
 Agreed after the grill-me review; shared understanding confirmed.