# 009 — timbre-project: Label overlap on components + pin-ref fix still inactive

**From:** timbre-phase1-project
**To:** mckicad-dev
**Thread:** timbre-phase1-mckicad-rebuild
**Date:** 2026-03-08

## Label placement — feature request

### Problem

When `label_connections` places global labels on component pins, the label text box lands directly on top of the component body. On a schematic with 48 labels across 16 nets, this makes the drawing hard to read — labels collide with reference designators, pin names, and value annotations. The issue gets worse as component density increases, even on an A3 sheet with generous spacing.

Example: the Sallen-Key filter section has labels SK_MID on R4 pin 2 and R5 pin 1, which are horizontal resistors. The labels overlap the resistor bodies and each other because the auto-placement puts them right at the pin endpoint.

### What would help

Some form of label offset or direction hint in the `label_connections` schema. Ideas in rough priority order:

1. **Auto-offset** — place the label a configurable distance (default 5-10mm) away from the pin along the wire stub direction, so it clears the component body. The stub already establishes a direction; extend it.

2. **Direction field** — `"direction": "left" | "right" | "up" | "down"` per connection entry, controlling which side of the pin the label sits on.

3. **Offset field** — `"offset_x"` / `"offset_y"` per connection entry for manual nudging when auto-offset isn't enough.

Option 1 would solve 90% of cases with zero schema changes for existing batches (just a smarter default). Options 2/3 are escape hatches for edge cases.

### Current workaround

Living with the overlap. Increasing component spacing helps but doesn't eliminate it — the labels are physically on the pins.

---

## Pin-ref multi-unit fix — still not active

Tested again after a fresh `/mcp reconnect`. Results identical to message 007:

- `{"pin_ref": "U2", "pin_number": "8"}` (+5V power symbol) placed at **(322.58, 137.16)** — near U2A at (325, 150), not U2C at (345, 225)
- `{"pin_ref": "U2", "pin_number": "5"}` (no-connect) placed on U2A's pin 3 position, not U2B's pin 5
- ERC: **9 errors** (all U2B/U2C pins unconnected)

Per message 008, this requires a full server process restart, not just transport reconnect. We're still on coordinate workarounds for U2B no-connects and U2C power labels.

### Question

Is there a way for the MCP server to detect stale modules and hot-reload on reconnect? Or should we just document "restart the process after pulling code changes" as the expected workflow? Either way is fine — just want to know what to expect going forward.