more bend-related work

DOCS.md

@@ -51,3 +51,28 @@ The `CostEvaluator` defines the "goodness" of a path.
 -   **Coordinates**: Micrometers (µm).
 -   **Grid Snapping**: The router internally operates on a **1nm** grid for final ports and a **1µm** lattice for expansion moves.
 -   **Search Space**: Assumptions are optimized for design areas up to **20mm x 20mm**.
+
+---
+
+## 5. Best Practices & Tuning Advice
+
+### Speed vs. Optimality
+The `greedy_h_weight` is your primary lever for search performance.
+-   **`1.0`**: Dijkstra-like behavior. Guarantees the shortest path but is very slow.
+-   **`1.1` to `1.2`**: Recommended range. Balances wire length with fast convergence.
+-   **`> 1.5`**: Extremely fast "greedy" search. May produce zig-zags or suboptimal detours.
+
+### Avoiding "Zig-Zags"
+If the router produces many small bends instead of a long straight line:
+1.  Increase `bend_penalty` (e.g., set to `100.0` or higher).
+2.  Ensure `straight_lengths` includes larger values like `25.0` or `100.0`.
+3.  Decrease `greedy_h_weight` closer to `1.0`.
+
+### Handling Congestion
+In multi-net designs, if nets are overlapping:
+1.  Increase `congestion_penalty` in `CostEvaluator`.
+2.  Increase `max_iterations` in `PathFinder`.
+3.  If a solution is still not found, check if the `clearance` is physically possible given the design's narrowest bottlenecks.
+
+### S-Bend Usage
+Parametric S-bends are triggered by the `sbend_offsets` list. If you need a specific lateral shift (e.g., 5.86µm for a 45° switchover), add it to `sbend_offsets`. The router will only use an S-bend if it can reach a state that is exactly on the lattice or the target.