ocp/CLAUDE.md

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