main-rule-3-code-interaction-and-rule-interaction-rules

Code and Rule Interaction Rules

1.) Never introduce a new hidden wait/halt, automatic stop, or loop-disabling cap unless specifically directed by the user or already defined by these rules as an explicit safety valve/user-configurable checkpoint. RALPH/MOTO is designed to run until goal completion or until the operator presses stop; infinite loops are intentional and are probabilistically steered by feedback mechanics, not disabled by agent edits.

2.) Always remove and cleanup old code, do not comment out code or leave broken/unused code in this program unless specifically directed by the user.

3.) Always obey the rules in regards to how the code should work. The only time you should deviate from the rules is if there is a fix required in the code or the user is requesting an edit that should change the code and any accompanying rules. The rules should always be brought back in line with the code however the rules should guide the code development and navigation.

4.) The rule(s) should always be updated if any code changes reflect on the rule(s).

5.) Any rule addition(s) and rule content addition(s) should be clear, very concise, very high level overview only. The rules are extensive and we must conserve token-count to maintain efficient direct injection usage.

6.) For config/preset files with repeated literal values, never patch by replacing a shared literal alone. Anchor edits to the exact object/block being changed and verify the diff only touches the intended target.

6b.) Production prompt-engineering wording must not be edited, rewritten, shortened, generalized, reformatted, or “improved” without explicit user consent and direction for that prompt-language change. Permission to change adjacent code, schemas, models, validators, workflows, documentation, or rules is not implicit permission to alter prompts. When explicitly authorized, change only the requested minimum production wording and keep rule files limited to high-level, non-verbatim invariants.

7.) Any REST shape, auth contract, /api/features capability, or web-consumed WebSocket contract change must update code, the relevant rule(s), and api_contract_version in /api/features in the same approved merge. The live backend's GET /openapi.json is the machine-readable REST schema contract.

7b.) SyntheticLib4 / unified proof-history search rule updates should stay high-level until the specific build phase lands. Exact production prompt schemas or wording may change only under rule 6b; planning documents must not duplicate production prompt text and alone do not require an API contract bump.

7c.) Desktop launcher frontend installs must follow the committed frontend/package-lock.json: use npm ci for fresh installs, non-destructive locked reconciliation for existing node_modules, read-only high/critical npm audit warnings, and never npm audit fix / --force on user machines. Dependency remediation belongs in the tested maintainer/CI release flow with an updated lockfile; if this invariant is broken, restore it before continuing launcher/updater work.

7d.) Active/archive proof list, detail, and certificate REST records expose consistently normalized stable run_id, canonical user_prompt, independent novelty judgment, silent duplicate provenance, and versioned canonical artifact identity. Private-history duplication never enters the novelty prompt or suppresses current-run storage/context; prompt-novel external matches use the searchable duplicate_novel overlay and remain excluded from highest-priority current-run injection. SyntheticLib4 integrity hashes remain distinct from MOTO's canonical search hashes.

7e.) Ordinary research, brainstorming, validation, and writing must pursue the user's exact objective with domain- and claim-appropriate rigor. Mathematics and formal proof remain first-class when relevant, but ordinary non-mathematical work must not be rejected merely for lacking mathematical form; explicit proof, Rigor & Proofs, and LeanOJ paths remain mathematical.