# 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