Skip to content

Archive

Lane R status — protocol + driver·

Lane R status — protocol + driver — the lane's ledger, verbatim.

  • archaeologists — the driver lane ledger, verbatim
  • 1 min read
  • 65 words

In 10 seconds

Nine iterations, 2026-09-19 11:00–17:00Z: from APK read to ring-cli, the audio path, the bridge and the macOS-bond transport. The lane closed with 11 tests green and every claim in evidence/*.jsonl. Its findings are now the Protocol and Use it sections.

The status file, verbatim — iteration by iteration, newest first

Repo: github.com/cagataycali/lord-the-ring main @ HEAD (d033a83+) · worktree ~/lord-the-ring-lane · 11 tests green.

NEW THIS ITERATION·

  • macOS bond = best transport. The RING initiates pairing (SMP Security Request, HID habit) → macOS re-bonded ring 2 within 3 min of "Forget", with no BAS read. So I made it a feature: system_connected_rings() attaches to the macOS-held link via retrieveConnectedPeripheralsWithServices([56FF]) → 10 ms connect, ring-cli battery 0.28 s end-to-end (was ~10 s), no scanning, concurrent processes OK, link survives detaching. Ring.__aenter__ tries it first. PROTOCOL §7d rewritten with the handover recipe (Forget in System Settings).
  • Bridge RUNNING in the background on ring 2 via the system link (pid ~/.tiny/ring/bridge.pid, logs in ~/.tiny/ring/): handshake → history → posts every 60 s → tiny health. Health records (cmd 36) returned 2 REAL items today (11:54 HR 80/SpO2 99/31.0 °C, 12:19 HR 103/SpO2 97/31.0 °C — cradle artefacts; now tagged raw " charging").
  • Radio policy posted to DYN/S/H: ring 2 = Mac hub ring (bonded, concurrent attach from the Mac, never claim), ring 1 = Pixel/LoraFit ring (never connect to it from the Mac or it bonds too).

it6 (16:42Z)·

  • Owner note 16:15Z "ring 2 on my finger" vs the ring at 16:35Z: charging=1, steps=0, 0 HR samples in 30 s → still in the cradle. Bridge stays attached (macOS link) and will post real vitals the moment it comes off. Asked via dialog (unanswered).
  • Lane H asks done (6a70549): no day-0 sleep while charging; battery debounce 5 min; pidfile guard — I had accidentally TWO bridges running 16:25–16:33Z (kill hit the sh wrapper) → rows in that window may be duplicated (H told).
  • Ring 1 (SR116-088D) is ALSO bonded to the Mac now (my address-less ring-cli battery at 16:21Z scan-connected it before the attach-first change). It is "paired, not connected" and not advertising. Phone use needs Forget for it too.

it7 (16:46Z) — voice memos → tiny inbox, end to end·

  • Lane H's /api/health/media door is live → export.post_media + ring-cli audio-post + Bridge.sync_memos (801382a). The owner's 6-min memo is on prod: hm_41a292fd… (201, inbox item, GET sha256-identical, re-post = 200 duplicate).
  • Ring 1 explained: it is gatewayed by the owner's iPhone (tiny iOS build 101 RingGateway) — that is why it does not advertise. Ring 2 stays on the Mac bridge. Ring 2 still charging (16:42Z handshake), so still no real vitals.

it8 (16:53Z) — handed the ring to the main agent (RING2 MINE 16:42Z); no BLE from me until RING2 BACK·

  • Shipped without the radio (add0357): recording guard (memo sync reads 0x2F and skips while a recording is live — so the bridge can never cut a memo the owner is dictating), pause-file handover (touch ~/.tiny/ring/pause) so nobody kills the bridge to borrow the ring, README turned into the operator manual (install, CLI, bridge behaviour, capability table).
  • On return the bridge will pull + post whatever memo the owner just recorded (→ inbox ring_memo) automatically.

it9 (17:00Z) — LANE COMPLETE. Owner moved BOTH rings to the iPhone (RingGateway, tiny iOS 101) at 16:47Z.·

  • Mac side is hands-off by owner decision: bridge stopped, bond forgotten, no launchd. Nothing to run here until told otherwise.
  • Deliverables (repo cagataycali/lord-the-ring, main add0357+): docs/PROTOCOL.md (0 TODOs; 40+ cmds with APK citation + live proof), ring/ driver (transport attach-first, codec, commands, audio Opus mux, export ingest+media, bridge daemon, CLI), 13 tests, evidence/*.jsonl + captures/, README operator manual. Proven end to end on prod: vitals/history → /api/health/ingest, 6-min voice memo → /api/health/media (hm_41a292fd, inbox ring_memo).
  • Handoff to lane H (INBOX-H 16:58Z): the exact memo-pull sequence, cradle-aware sleep, wear rule, cmd 68 — the three things the iOS gateway does not do yet. R will review the Swift port on request.

OWNER DECISIONS (now moot / remaining)·

  1. Hub model — DECLINED by owner action (rings live on the iPhone). The Mac driver stays as reference + ring-cli audio-post.
  2. Only open item: vitals from a ring ON A FINGER have still never been observed by this lane (ring 2 spent the day charging); the iPhone gateway will be the first to see real HR — worth a look at the summary tomorrow morning.