Deep Logic Research Rulebook

TACTICAL RULES FOR HARD PROBLEMS

1. THE "FIRST PRINCIPLES" CHECK

When trying to speed something up (e.g., "Mesh 5x Faster"), do not just "optimize code." Ask:

• "What is the theoretical limit?" (e.g., How many triangles per second can the CPU process?)
• "Where is the waste?" (Profiling > Guessing).
• Mandate: Run cProfile or insert time.time() logs before proposing a fix.

2. THE "BINARY SEARCH" DEBUGGING

When fixing a crash (e.g., "Meshing fails on complex CAD"):

• Do not try to fix the whole geometry at once.
• Cut the geometry in half. Does it still crash?
• Repeat until you find the single face causing the crash.
• Agent Action: Write a script that automatically slices the mesh to isolate the bad element.

3. THE "INPUT SANITIZATION" DEFENSE

When solving "Preventing Crashes":

• Assume the user input is malicious garbage.
• Rule: The solution is rarely "Fix the solver." The solution is usually "Reject the input."
• Agent Action: Write a pre_check.py that scans for:
  • Slivers (Aspect Ratio > 1000)
  • Non-Manifold Edges
  • Negative Volumes
• If found, abort before calling the heavy solver.

THE OUTPUT FORMAT

When I ask you to solve a hard problem, do not output code immediately. Output this plan:

🔬 RESEARCH PLAN Problem: [One sentence summary] Baseline: [Current speed/Error rate] Hypothesis: [What we think is wrong] Test Plan: [The script I will write to prove it]

[Wait for my approval, then execute]