diff --git a/docs/hardware-porting-plan.md b/docs/hardware-porting-plan.md
index 6ad6e6e..0844a98 100644
--- a/docs/hardware-porting-plan.md
+++ b/docs/hardware-porting-plan.md
@@ -297,7 +297,7 @@ commit `aab1925`.
|---|---|---|
| 0 | Remote-flash question researched — two viable paths, design rule derived (§2) | **done, and now measured on the board: neither works** (§2). First flash needs the MicroPython REPL or BOOTSEL; remote *update* is unsolved pending a `BOOTSEL` command |
| 2 | **Phase 2 gate: RP2040 + TMC5160-BOB at 3.3 V** | **PASSED** on tower 121, 2026-09-15: `IOIN Y=0x3000001E version=0x30`, encoder reading (`X_ENC`), one axis, `speed=3000` |
-| 3 | Yaw homing on the real drivetrain | **BLOCKED — no endstop found.** See below |
+| 3 | Yaw homing on the real drivetrain | **done** — the endstop was being sheared through at full torque; homing at 189 mA holds. See below |
### Phase 3, first attempt — 2026-09-16
@@ -314,17 +314,49 @@ direction without the encoder deviation ever exceeding ~100 counts** against the
1500 that marks a jam. The motor met no resistance at any speed.
Homing detects an endstop by the shaft falling behind the commanded position, so
-it cannot work if nothing stops the shaft. Two candidates, indistinguishable
-over the wire because the encoder sits on the motor side:
+it cannot work if nothing stops the shaft. Two candidates were considered,
+indistinguishable over the wire because the encoder sits on the motor side: no
+hard stop at all, or an output not following the motor.
-1. **No hard stop on this yaw** — it rotates continuously, and stall-based homing
- is the wrong strategy for this rig.
-2. **The output is not following the motor** — a slipping coupling or a loose
- grub screw. The encoder would track the motor perfectly either way.
+### RESOLVED, 2026-09-17 — the stop was there, and losing
+
+Neither. **The endstop is a screw head meeting another screw head, and the raised
+gear ratio gave the motor enough torque to shear one past the other.** The stop
+was resisting; it simply lost, every time, and a stop that yields is invisible to
+a detector watching for the shaft to fall behind.
+
+The fix is to make the search weak enough that the screw wins:
+
+| | |
+|---|---|
+| Homing current | **189 mA** (IRUN 7 at GLOBALSCALER 80, 75 mΩ sense resistor) |
+| Run current | 756 mA — unchanged, because the gear ratio exists for wind stability |
+| Measured travel | **1,210,778 counts**, repeatable to 0.27 % across three homes |
+| Free-running encoder gap | ~200 counts against the 1500 latch, and it does **not** scale with speed |
+| Full homing | ~2 min at VMAX 30000 |
+
+Declared per tower in `hardware.ini` as `[Motor.yaw] homing_current_ma`, converted
+to registers by the host and sent as `CURRENT` before every home — so retuning it
+is a restart, not a reflash. See [configuration.md](configuration.md) for the keys
+and `firmware/docs/hardware-notes.md` for the mechanism.
+
+Three things this exposed, all since fixed:
+
+- **`steps_per_rev` was inert**, still carrying the Delta's 177,000 against a real
+ turn of ~1.2 M, so it passed at 14 % of a turn. It is the only guard against a
+ *phantom* endstop, which reducing the current makes reachable.
+- **`STOP` did not end a homing** — it halted the motor but left the state machine
+ waiting for a stall that could no longer come, until the timeout.
+- **The host abandoned homing after a hard-coded 65 s**, which this drivetrain
+ needs more than. Now `[Motor] homing_timeout_s`.
+
+What the investigation looked like before it was resolved
**Resolving it needs a physical observation**: did the gimbal itself rotate ~1.8
turns, or did the motor spin while the platform stayed put? Check any cabling
through that joint before moving the axis further.
+
+