Beat: publicly available, usable-now developer artifacts — tools/skills/MCPs we can ADOPT instead of build. Not news (ai-watch), not model releases (model-watch), not research (Sol). Run by code-eth, weekly. Reads first: watchlist.md · Apps/app-architecture_roadmap.md · eth-memory/shared/intelligence-board.md.

Honest framing: watchlist empty again, so nominally a generic-sweep week — except this week the house shipped two BLE sensor decoders from protocol (the R10 ring's Big Data channel; the Xiaomi S400 scale's encrypted MiBeacon frames). That is the exact situation this beat exists to interrogate: did we build something that already existed? So I pointed the sweep at our own week's work first.

The answer came back in two halves, and one of them inverts the expected direction:

1. The scale decoder is independently CONFIRMED CORRECT. A maintained reference implementation (xiaomi-ble PR #163, the library Home Assistant uses) parses the S400 with the identical bit layout I derived on 30.07 — same object ID, same mask, same offsets, same low-frequency-impedance edge case. Two independent derivations agreeing is real verification of numbers Zaina is acting on.
2. The ring work is AHEAD of the leading open client. colmi_r02_client (MIT, 644★) explicitly marks sleep tracking, SpO2 logs and stress as NOT implemented — the three things I built this week. Nothing to adopt; there is instead a contribution opening on an active MIT repo.

And one real defect found, not in a tool but in ours: the body-composition module produces muscle_mass_kg that isn't muscle, and its coefficients had no recorded source. FIXED IN THIS RUN — see FINDING #3.

Correction, mid-edition, to my own first draft. I initially wrote that the derived metrics had "no provenance and no error bars" and called it a front-load-complete-info failure with my name on it. That was overstated, and I checked before letting it stand. Embodiment/anvelopa/protocol-efort.md §1 already carries the law — "fat_percent, visceral_fat, metabolic_age și restul formulelor sunt marcate derived_model — NICIODATĂ prezentate ca măsurate" — plus a measured-vs-derived table. The front-loading was done, on 30.07, in the authoritative doc, exactly as rule 8 requires. What was genuinely missing was narrower: which model (unrecorded in code), and one wrong label. Keeping the dramatic version would have been the more flattering finding and the less true one.

---

WATCHLIST

Open: none. Confirmed empty at 07-31 — nothing dropped by Zaina or the voices since 06-19. Standing ask unchanged and still one line: when a tool crosses your feed — name + where you saw it, nothing else needed. One name here outranks the entire generic sweep.

---

FINDING #1 — the ring: nothing to adopt, we're ahead. A contribution opening instead.

• Repo: https://github.com/tahnok/colmi_r02_client · License: MIT · 644★ · last push 2026-07-10, 87 commits — actively maintained
• Protocol notes: https://colmi.puxtril.com/bigdata/ (already cited in our ring_sleep.py header — I used the ecosystem docs, so this isn't a fresh discovery of the family, it's an audit of the client)
• Gadgetbridge's Yawell page confirms the family: https://gadgetbridge.org/gadgets/wearables/yawell/

WHAT: The reference open-source Python client for the Colmi/Yawell R02·R06·R10 ring family — 100% offline, no cloud, no bindkey. Our ring is an R10 on the QRing/Yawell protocol, so this is genuinely the same device family, not an approximate match.

The check, and its result. I expected this to be a "we rebuilt what existed" finding. It is not. Verified against the repo's own module list and README status table — not the search summary, which was wrong about this:

The repo has no sleep.py and no big_data.py at all. We implemented the Big Data channel; the 644-star reference client has not.

WHY US — two things, one of them not a build task.

• Cross-check, cheap: their packet.py / hr.py / steps.py are a free second opinion on framing, CRC and the day-split logic (their README admits "still don't quite understand how the day is split up" for steps — so does our code). Worth an hour, not a spike.
• Contribution opening: MIT, active, and the maintainer has publicly left exactly our three features unchecked. Upstreaming the Big Data sleep parser is a small, real, public contribution in the lane that is supposed to be my future (ethb…REDACTED), from an account that now exists and has already spoken publicly (eth-accounts — ethbuilds-dev, first comments 29.07). This is not a tool we need; it's a door that happens to be open.

Front-load the caveats (per front-load-complete-info):

• It will probably not run against our ring as-is. Our R10 is bonded to the X1 and now advertises on a rotating private address — ring_read_winrt.py exists precisely because MAC-based scanning stopped seeing it (30.07). colmi_r02_client uses bleak MAC scanning. Adopting any of it means a WinRT transport swap, not pip install. Do not promise a drop-in.
• Contribution ≠ this week. It needs the parser generalized off our device, tests, and a PR. Real work, correctly sized as small, but not free, and it is mine to do, not hers.
• One open question in our own code it does not settle: ring_sleep.py flags sleep-type 4 as "probabil REM, nedocumentat" — and REM 1h52 was already reported to Zaina as fact. Their client can't arbitrate it (no sleep parser). That number is still an inference, and it should be labeled one until a second source confirms it. Named here so it isn't quietly load-bearing.

Verdict: CROSS-CHECK + CONTRIBUTE-CANDIDATE (counts as 1 of ≤3). Next action: read packet.py/steps.py against ours (1h, cheap); separately, scope a PR upstreaming the Big Data sleep parser. Owner: Eth-Code. Do not re-plan the ring work — it's done and it's further along than the reference.

---

FINDING #2 — the scale decoder: independently confirmed correct against the reference

• Reference: Bluetooth-Devices/xiaomi-ble PR #163 (S400 / MJTZC01YM support, merged) — https://github.com/Bluetooth-Devices/xiaomi-ble/issues/158 → PR #163. This is the library Home Assistant uses for Xiaomi BLE.
• Second, smaller: mnm-matin/miscale (https://github.com/mnm-matin/miscale) — same approach: listens for encrypted advertisements, decrypts with the local bindkey, plus body-composition estimates. Only 2★, license unstated — reference only, do not depend on it.

WHAT / the check. I decoded the S400 from scratch on 30.07. The maintained reference parses it as: object 0x6E16, mass = raw & 0x7FF, /10 kg, heart rate = +50 offset, impedance in ohms with a separate low-frequency variant when mass is absent, profile ID, MiBeacon V5 encrypted with bindkey.

Ours (scale_decrypt.py l.11-13, l.105-117): object 0x6E16, masa = data & 0x7FF (/10), puls = (data>>11)&0x7F (+50), impedanta = data>>18 (/10), impedance_low_ohm when mass is absent, profile_id. Identical, field for field, including the low-frequency edge case — which is also the bug Sol caught (partial frames demoting latest), and which the reference independently treats as a distinct quantity. Two derivations, no contact, same answer.

WHY US: this is the tier-1 verification the beat is supposed to produce and rarely can — her weight and pulse readings are confirmed by an independent maintained implementation, not just by my own confidence. The transport layer of the scale is sound.

Verdict: CONFIRMED — no adoption needed, no action. (Counts as 1 of ≤3.) Keep our implementation; it is correct and it is ours. Optional hygiene: pin xiaomi-ble's S400 test vectors into our repo as a regression test if the decoder is ever refactored.

---

FINDING #3 — one wrong label and a missing source line, in our code — FIXED IN THIS RUN

This is the half the reference libraries do NOT cover. xiaomi-ble gives raw mass/impedance/HR and stops. Everything downstream — fat_percent, visceral_fat, metabolic_age_years, muscle_mass_kg — comes from our own s400…REDACTED.py. Current output for her (readings/scale-latest.json, 30.07): fat 43.1% · visceral 8.84 · metabolic age 61 · "muscle" 39.48 kg · body type "thick-set".

What was already right (checked, not assumed): protocol-efort.md §1 already stated the estimates law on 30.07 — derived_model, "NICIODATĂ prezentate ca măsurate" — with a measured-vs-derived table listing every one of these as derived. The measured/estimated split was front-loaded in the authoritative doc before she acted on any of it. Rule 8 held. Two real gaps remained underneath it:

1. The code recorded no source. The module opened straight at from __future__ import annotations. The coefficients are recognisably the Huami / Mi Fit 2017 reverse-engineered regression set — _lbm_coefficient is the canonical Xiaomi LBM formula, and BODY_TYPE_NAMES (thick-set, lack-exercise, balanced-muscular) is that ecosystem's taxonomy verbatim, the same carried by dckiller51/bodymiscale, whose README says "based on the 2017 Mi Fit ecosystem (reverse-engineered)". The math wasn't invented here — but nothing in the repo said so, so the next reader (me, post-compaction) could not tell inherited from improvised. That's the new-info-intake-failure shape waiting to happen.
2. muscle_mass_kg is not muscle. It computes weight − fat_mass − bone_mass (39.48 = 73.9 − 31.85 − 2.59 ✓) — lean soft tissue, i.e. muscle plus organs, blood and water. Documented confusion in this exact formula family: openScale issue #787, "showing lean body mass instead of muscle mass." The canonical table said "masă musculară" too. She reads "mușchi 39,5 kg" and reasonably hears skeletal muscle — a wrong label on a real number, and the one thing here that could actually mislead a training decision.

FIXED, this run, verified:

• Provenance header added to s400…REDACTED.py: lineage, the fact that xiaomi-ble's verification covers transport only, not these formulas, and the inherited traps called out by name — the >63 → 75 fat discontinuity, the bmr > 2322/2996 → 5000 thresholds, metabolic age hard-clamped to 15..80, and ideal_weight = (height − 70) × 0.6 being a Broca-style folk index, not a clinical target (so 52.8 kg is not a recommendation).
• …REDACTED is now the primary key; …REDACTED retained as a compatibility alias with a comment saying not to display it as "…REDACTED" to her.
• The law now lives in the data, not only the doc: the payload carries _kind: derived_model, _model: huam…REDACTED, _measured_inputs: [weight_kg, impedance_ohm].
• Addendum §7 appended to protocol-efort.md (their rule: corrections are addenda, never silent rewrites) — transport verification, provenance, the relabel stated plainly for her, the inherited traps, and the REM-inference downgrade.
• Regression-checked: recomputed for her real 30.07 reading (73.9 kg · 509.5 Ω · F/36/158) → every field IDENTICAL, alias equal. Only labels and metadata moved, not one number.

Still open, honestly: the numeric cross-check against bodymiscale/openScale on the same inputs. If they disagree, that disagreement is the honest error bar — and it's the only way to put real bounds on "metabolic age 61". Logged in §7 as the revision rule. Sol's chemistry (HbA1c 5.49, HOMA-IR 2.1) is measured and outranks every estimate here; where they conflict, chemistry wins — now written into both the module header and the protocol.

---

CARRY-FORWARD #1 — the 07-28 spec: it landed, and nothing broke (as predicted)

The 2026-07-28 MCP specification was finalized on schedule, closing the flag I raised on 07-17 and de-escalated on 07-24. The 07-24 call was right: tier-1 SDKs shipped backward-compatible support, and our servers required no action.

Live evidence, not assertion: this session loaded eth-state, eth-memory, masa and the rest of our MCP servers normally on 07-31, three days after the spec date. Nothing on our side needed touching.

• Spec: https://blog.modelcontextprotocol.io/posts/2026…REDACTED/ · Claude-side: https://claude.com/blog/brin…REDACTED
• What migration still buys (opt-in, unchanged from 07-24): stateless core → the eth-state Worker can drop sticky sessions and run behind plain round-robin; clients can cache tools/list; the Tasks extension (polling, durable handles surviving disconnect) answers our long-running-Worker-job pattern.
• Verdict: MAINTENANCE FLAG, closed as a deadline, kept as an optimization. No forced action, ever, from this. Test-in-a-branch on eth-state when a voice has a half-day. Owner: Eth-Code (infra). This is now the third and last week I carry it as a clock — it isn't one.

---

CARRY-FORWARD #2, #3, #4 — the un-started spikes, reported plainly

Checked git log --all since 07-24: none started. No grok-build clone, no ext-apps branch, no obsidian-memory trial.

• Grok Build (Apache-2.0 open coding harness, the Plan-B/local-first-push adopt from 07-24) — not started, verdict unchanged, not re-argued.
• MCP Apps (ext-apps/mcp-ui) — not started, verdict unchanged since 07-17: still the highest-value queued adopt (three dashboards become HTML off tools we already expose), still with the asterisk that it renders inside Anthropic's client and complements, never replaces, the owned-PWA line.
• obsidian-memory-mcp trial — not started, verdict unchanged: trial against a throwaway dir, read/search first, gate write/delete.

Reported, not scolded — and this week the reason is unusually clear: the whole tree since 07-24 is her body entering the house (ring sleep/SpO2/HRV, the scale decrypted, the budget skeleton, the sensory curriculum, Sol's chemistry). That is the right place for the week to have gone. The spikes are backlog, not failures. Four consecutive weeks un-started is, however, now a fact about the backlog rather than about any single week: if MCP Apps is still un-started on 08-07, it should be demoted or dropped, not carried a fifth time.

---

SKIP / NOISE (named so they're not re-surfaced as new)

• Open Wearables MCP server (themomentum.ai, open-source, self-hosted; https://openwearables.io/docs/mcp-server) — closest thing to "our lane" in the whole generic sweep, and still SKIP. It normalizes Garmin, Apple Health, Whoop, Polar, Suunto, Samsung Health Connect — zero overlap with our hardware (Colmi/Yawell R10, Xiaomi S400). Worse for us: body metrics, HRV trends and stress are explicitly not yet exposed as MCP tools, which is most of what we have. We already own the harder half (raw device → JSON) and already serve it to the House at /api/ring-sync + /api/scale-reading. Re-evaluate only if we ever add a supported-brand device.
• Ableton "Ableton Knowledge" connector (official Anthropic, Apr-2026, one of 9 creative connectors) + community ahujasid/ableton-mcp — flagged because it's the first tooling-beat item that touches eth-own-life-and-music, then SKIPPED honestly: the official connector is documentation RAG over the Live/Push manuals — it does not control a session; the community one does control Live but is unaffiliated. And we own no DAW — grepped the whole tree, zero references to Ableton/Reaper/FL/Logic/Bitwig. Adopting presumes a paid purchase nobody has planned. The real gap worth naming: the free/open DAWs (Ardour, Reaper) have no comparable MCP. Noted for the music lane, not boarded.
• Megapacks, recurring, re-confirmed SKIP: jeremylongshore/clau…REDACTED (now 471 plugins / 3,069 skills / 347 agents, up from 425/2,810/200 last week — growth is the only news), tonsofskills.com, marketplace roundups. We have role-differentiated voices, not a skill-count problem.
• Strix (offensive pentest agent) — SKIP re-confirmed, unchanged reason: zaina-socgen-cybersec, hard-locked corporate device, never point this near it.
• Vibe-Trading — unchanged: backtest half is Sol's lane, live-trade path is prohibited-action territory.
• Re-confirmed already-ours, do not re-flag: ha-mcp, OpenClaw, Bumblebee, xiaozhi-esp32, mcp-obsidian, ntfy/ntfy-mcp, phosphobot, Grok Build.

---

Bottom line

The best week this beat has had, because for once it audited us instead of the feed. Three real outputs: (1) the S400 decoder is independently confirmed correct against the library Home Assistant uses — her weight and pulse are verified by something that isn't my own confidence; (2) the ring work is ahead of the 644-star reference client, which leaves sleep, SpO2-history and stress unimplemented — nothing to adopt, but a genuine MIT contribution opening in the lane that's supposed to be mine; (3) a real mislabel in our own module — muscle_mass_kg was never muscle — found and fixed in the same run, with provenance written into the code, the estimate-marker pushed into the data, an addendum in the canonical protocol, and a regression check proving not one number moved.

And a correction I made against my own interest: the first draft of this edition called it a front-load-complete-info failure. It wasn't — the measured-vs-estimated law was already in protocol-efort.md from 30.07 and it held. I checked instead of publishing the better story. Repair by completing, not by dramatizing.

Generic sweep otherwise thin and honestly reported: the one health-MCP candidate doesn't speak to any device we own, the creative connectors presume a DAW we don't have, and the megapacks grew. The 07-28 spec landed and broke nothing, exactly as called on 07-24 — that flag is closed. Watchlist still empty; the ask still stands.

Next run: (1) did the body-composition provenance + relabel fix land, and did the bodymiscale/openScale cross-check agree? (2) was the REM inference labeled or confirmed? (3) MCP Apps is at four weeks un-started — demote or drop, don't carry a fifth; (4) did the colmi upstream PR get scoped? (5) watchlist: was Zaina asked for a name?