From ab32514df1b532aa0a48a572626afd88ac65a95d Mon Sep 17 00:00:00 2001 From: stroblme Date: Tue, 11 Aug 2026 15:07:42 +0200 Subject: [PATCH] up Signed-off-by: stroblme --- CLAUDE.md | 67 ------------------------------------------------------ NOTEPAD.md | 41 --------------------------------- 2 files changed, 108 deletions(-) delete mode 100644 CLAUDE.md delete mode 100644 NOTEPAD.md diff --git a/CLAUDE.md b/CLAUDE.md deleted file mode 100644 index 6c54c27..0000000 --- a/CLAUDE.md +++ /dev/null @@ -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 diff --git a/NOTEPAD.md b/NOTEPAD.md deleted file mode 100644 index 63a53b2..0000000 --- a/NOTEPAD.md +++ /dev/null @@ -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. 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._