git helper tool added and improved coding-standards

CODING_STANDARDS.md

@@ -1,14 +1,16 @@
 # Backend coding standards
 
 This document is the authoritative policy for handwritten production and test Java
-in `agiledancers-be`. Generated code and Java helpers outside that module are out
-of scope. Existing frontend conventions in README.md and agiledancers-fe remain in force.
+in `agiledancers-be`. Generated code is out of scope. The Java conventions below also apply to
+handwritten Java helpers outside that module. Existing frontend conventions in README.md and agiledancers-fe remain in force.
 
 ## Scope and authority
 
 - Cover handwritten production and test Java in `agiledancers-be`. Exclude
   generated code. Dependency injection and production architecture rules apply
-  where relevant. Frontend and Java helpers outside the backend are out of scope.
+  where relevant. The Java conventions also cover Java helpers outside the backend; backend
+  architecture, metrics, coverage and automated checks remain backend-only.
+  Frontend code is out of scope.
 - [Java coding guidelines](https://www.geeksforgeeks.org/java/coding-guidelines-in-java/)
   supplied source material. Only the rules adopted in this local document apply;
   changes to the article do not change project policy.
@@ -16,6 +18,15 @@ of scope. Existing frontend conventions in README.md and agiledancers-fe remain
   comment layout. S8 remains responsible for formatter integration.
 - Do not adopt unrelated static-analysis rule bundles.
 
+## General language guidance
+
+- Always prefer newer stable official APIs, language features and officially
+  recommended coding practices over older alternatives when they suit the task
+  and are supported by the project's configured language/runtime version.
+  Preserve required behavior and compatibility; document concrete reasons for
+  retaining an older approach. This guidance applies to every language used in
+  the project.
+
 ## Java conventions
 
 - Types use UpperCamelCase; methods and variables use lowerCamelCase; constants
@@ -25,9 +36,19 @@ of scope. Existing frontend conventions in README.md and agiledancers-fe remain
 - Opening braces stay on the declaration/control-statement line. All `if`, `for`
   and `while` bodies require braces, including enhanced for and do/while bodies.
 - No wildcard imports. Static imports are allowed only in test classes.
-- Comments explain intent or constraints. Document public contracts with Javadoc
-  where their meaning is not clear from the declaration; do not require boilerplate
-  documentation for every accessor.
+- Prefer `java.nio` APIs (including `java.nio.file` and `java.nio.charset`) over
+  equivalent `java.io` APIs. Use stream APIs where no suitable NIO equivalent
+  exists, such as process pipes or APIs requiring streams.
+- Use varargs (`Type... values`) when an array is the last method or constructor
+  parameter, including `main(String... args)`. Preserve required override signatures
+  and framework/API compatibility.
+- Prefer Java 25 `IO.print`/`IO.println` for direct standard output and `IO.readln`
+  for line-oriented standard input. `IO` has no standard-error variant; retain
+  `System.err` for error output. Use application logging where appropriate.
+- Comments explain intent or constraints. Require Javadoc on public classes and
+  public methods that do more than basic POJO/data-carrier work. Trivial accessors
+  and plain data carriers do not need boilerplate documentation. Describe behavior,
+  constraints and failure conditions where relevant.
 - Block comments use the following layout, subject to Palantir formatting:
 
   ```java
@@ -193,10 +214,11 @@ loops/catches and lambdas) and initialized fields. PMD's three selected finality
 rules additionally cover control-flow assignment and private constructor-initialized
 fields. Framework/lifecycle requirements, generated Lombok setters, and external
 writes to public/protected fields need review before changing field finality.
-No tool can infer whether a comment explains intent, whether a public contract
-needs Javadoc, whether a record is appropriate, or whether mutable components are
-sufficiently protected. These are **manual rules**, as are ambiguous type inference
-and architecture/DI design decisions. Review all `DESIGN` record-component entries
+Comment intent, Javadoc adequacy for nontrivial public contracts, record suitability
+and protection of mutable components require manual review. These are **manual
+rules**, as are ambiguous type inference, architecture/DI design decisions, NIO
+API selection, trailing-array varargs, console I/O selection and the POJO
+documentation boundary. Review all `DESIGN` record-component entries
 and `REVIEW` signals, even when a build passes, using `docs/backend-review.md`.
 
 Reports never rewrite Java. Formatter application remains S8's separate validate