68 lines
3.1 KiB
Markdown
68 lines
3.1 KiB
Markdown
# 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
|