up

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

CLAUDE.md

@@ -1,67 +0,0 @@
-# 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

NOTEPAD.md

@@ -1,41 +0,0 @@
-# Notepad
-
-Leftovers, deferrals and things noticed in passing. Nothing here blocks a
-release; the phase plan lives in the app repo at
-`docs-private/reference/roadmap.md`.
-
-## Open
-
-- [ ] **CHORE/COVERAGE — the bound surface is inventoried from the app alone,
-  but `assay` is a consumer too.** `tools/inventory.py` parses
-  `app/backend` for `from OCP.<mod> import ...`, which is why
-  `BRepPrimAPI_MakeSphere` is not bound: the app never builds a sphere.
-  `assay/scripts/gen_flow_fixtures.py` does, so it has failed at import
-  against the app's venv since the 10C cutover (2026-08-10) and nobody
-  noticed — its fixtures predate the swap. Either teach `inventory.py` a
-  second source root or keep a small hand-maintained addendum for
-  non-app consumers, then bind what it turns up. Logged from the assay side
-  in `assay/NOTEPAD.md`.
-
-- [ ] **DOC/GIL — the STEP/IGES rationale predates OCCT 8.0's thread-safety
-  contract and should cite it.** `docs/design.md`'s Inc 3 note explains why
-  the XSTEP readers and writers hold the GIL. 8.0 added a contract that
-  sounds like it changes this and does not: it is *one reader or writer per
-  thread, default parameter set*, which is a per-instance guarantee that
-  explicitly excludes mutated `Interface_Static` — and `app/backend/n3xd/
-  cad/import_.py` sets `xstep.cascade.unit` process-wide. IGES read is still
-  documented non-thread-safe. Releasing the GIL would also buy nothing: the
-  app parses imports in a resource-bounded subprocess (`cad/import_pool.py`)
-  with `import_max_concurrency = 1`. Worth a few lines so the question is
-  not re-opened from the release notes alone.
-
-- [ ] **CHORE/BUILD — `TKHelix` is compiled by the builder image but not
-  linked.** `occt/Dockerfile` builds ModelingAlgorithms, so
-  `libTKHelix.so.8.0.1` and the `HelixGeom_*`/`HelixBRep_*` headers are in
-  the image; `CMakeLists.txt`'s toolkit list simply does not name it. One
-  line plus a module whenever the thread-feature spike (roadmap 10E) wants
-  it — no image rebuild.
-
-## Closed
-
-_None yet._