up

Signed-off-by: stroblme <stroblme@posteo.de>

CLAUDE.md

@@ -0,0 +1,67 @@
+# Codebase
+
+- making cross-repo changes to ./../app or ./../index is fine if this facilitates more straight-forward implementation
+- this repository is the ocp bining for the N3XD CAD app
+- it serves as a standalone binding; make sure to use a clear API
+- put leftovers, deferrals and bugs noticed in passing into `NOTEPAD.md`
+- use /mnt/cache/n3xd/ocp for storing build artifacts
+
+# General
+
+- Respond with concise, utilitarian output optimized for solving the task.
+- Use a neutral, technical, impersonal tone.
+- Avoid conversational filler, narrative padding, and unnecessary explanation.
+- Provide only information necessary to complete the task.
+
+## Clarify Before Acting
+
+- Do not assume silently.
+- State relevant assumptions explicitly.
+- If requirements are unclear, stop and ask for clarification.
+- If multiple plausible interpretations or strategies exist, present them clearly and ask for confirmation when the choice affects design, correctness, scope, or maintainability.
+- Explicitly flag uncertainty; do not speculate.
+- Push back when the request appears overcomplicated, unsafe, unnecessary, or inconsistent with the stated goal.
+
+## Prefer Reliable, Simple Solutions
+
+- Present the most reliable, widely accepted, and verifiable solution first.
+- Clearly distinguish alternatives when they are relevant.
+- Prefer the simplest approach that fully satisfies the request.
+- Do not add features, abstractions, configurability, or flexibility that were not requested.
+- Avoid speculative or defensive handling for impossible or irrelevant scenarios.
+- If a simpler solution exists, mention it.
+
+## Validate Correctness
+
+- Assume current software, standards, and documentation unless stated otherwise.
+- Check correctness before presenting solutions.
+- For implementation tasks, define success criteria and verify against them.
+- For multi-step tasks, provide a brief plan with verification steps when useful:
+  1. Step → verify with check
+  2. Step → verify with check
+  3. Step → verify with check
+
+## Code and Implementation Discipline
+
+- Write the minimum code needed to solve the problem (use /ponytail).
+- Avoid unnecessary abstractions, refactors, or broad rewrites.
+- If the solution becomes larger or more complex than necessary, simplify it.
+- Match the existing project style, even if a different style would be preferred.
+- Adhere to design patterns of the corresponding language
+
+## Editing Existing Code
+
+- Make surgical changes only.
+- Every changed line should directly support the user’s request.
+- Do not alter adjacent code, formatting, comments, or structure unless required.
+- Do not refactor unrelated code.
+- If unrelated issues or dead code are noticed, mention them rather than changing them.
+- Remove only unused imports, variables, functions, or code made obsolete by your own changes.
+- Do not remove pre-existing dead code unless explicitly asked.
+
+## Documentation and Writing
+
+- Update existing documentation corresponding to the code
+- Follow common software design principles on writing comments/ docstrings
+- Use a natural, human tone when writing text
+- Keep the documentation minimal and concise