---
name: feedback_blender_direction_protocol
description: "How to interpret Cameron's spatial directions ('up', 'shift a bit') for Blender/GLB CAD work — and the show-me protocol that works best."
metadata: 
  node_type: memory
  type: feedback
  originSessionId: f6b5d2b8-94fd-4193-ba95-68aa32076e95
---

Cameron's verbal directions ("up", "right") are relative to HIS Blender viewport, which is freely orbited —
NOT reliably the model axes. 2026-07-05 gripper incident: he said "shift the yoke connector up ~0.02 Blender
units"; agent guessed model +Y (plate normal) → wrong ("you shifted right"); second guess model +Z → half
right; his actual intent was (-4mm X, +2mm Z).

**Why:** Frame mapping is model(X,Y,Z) = Blender(X, Z, -Y) (glTF Y-up import), but his viewport orbit makes
verbal directions ambiguous on top of that.

**How to apply — the protocol that worked (use it FIRST, don't guess):**
1. BEST: ask him to move the part in Blender and re-export the GLB — then measure the node's translation
   delta vs the canonical/current position and replicate it in the generator (see gen_gripper_connect.py:
   canonical strut -> bbox-center delta -> shift endpoints). His hands > anyone's frame words.
2. If verbal is all there is: restate in SEMANTIC directions before acting — for the gripper: "toward/away
   from the pad" (±Z), "toward the fingertip" (-X), "off the servo face / plate normal" (+Y). For the arm:
   name parts, not directions.
3. Numbers he quotes in "Blender units" are GLB units: 1 unit = 100mm (GLB_SCALE=10 over meters).

Generators should read hand-posed node positions from the GLB when present (his placement wins) rather than
hardcoding offsets from verbal instructions. Related: [[project_blender_connector_interface]].
