ZeroClaw proposes telemetry that must be previewed twice

zeroclaw-labs/zeroclaw issue #9621 is the inspected primary source: “RFC: staged opt-in product telemetry with operator-reviewed reports.” The two related records below were inspected as supporting context, not treated as independent confirmation.

The facts

- zeroclaw-labs/zeroclaw issue #9621 was created 2026-08-01T14:50:06Z and was open at inspection; its title is “RFC: staged opt-in product telemetry with operator-reviewed reports.” - zeroclaw-labs/zeroclaw issue #7232 was created 2026-06-05T00:52:24Z and was open at inspection; its title is “RFC: Structured Observability Enhancement — Rich Events, OTel Trace Correlation, and Bridge Refactoring.” - zeroclaw-labs/zeroclaw issue #8603 was created 2026-07-02T02:55:42Z and was open at inspection; its title is “RFC: ZeroClaw Chat Completions profile.” - The repository reported 32484 stars, 703 open issues, default branch master, and last push 2026-08-03T01:00:21Z. - The latest tagged-release baseline checked was v0.8.4 published 2026-08-02T21:00:00Z.

What changed

zeroclaw-labs/zeroclaw issue #9621 reports: Problem ZeroClaw maintainers often have to make support, removal, and investment decisions without knowing whether released features are used outside the issue tracker. Recent RFC discussions show the gap: #9103 asks whether Lucid or Qdrant has real production usage before deciding whether to retain, remove, or redesign those integrations. #8780 has to judge whether a large realtime speech-to-speech surface has demand proportional to its maintenance cost, but reactions and issue comments provide little evidence. Ballots on #8568 argued that a new Mixture-of-Agents subsystem lacked deployment, benchmark, implementation, or public-reaction evidence showing that the existing delegation path was insufficient. #9246 narrowed automatic Todo configuration migration requirements because there was not enough evidence that users had configured

zeroclaw-labs/zeroclaw issue #7232 reports: Problem ZeroClaw needs observability events that can be attributed to an agent and channel, correlated within one agent turn, and exported without making sensitive prompt or tool content part of the default telemetry surface. The original proposal combined turn metadata, OTel trace correlation, content capture, and a migration to one emission path. Review and implementation split those concerns. This RFC records the durable architecture that remains after that split. Decision One-turn correlation turn_id identifies one agent turn. It does not identify a conversation, delegated-agent tree, scheduled-job lifecycle, or cross-channel workflow. Observer events for a correlated turn may carry: turn_id for turn identity; agent_alias for agent attribution; channel for channel attribution; structured input and output token

zeroclaw-labs/zeroclaw issue #8603 reports: RFC: ZeroClaw Chat Completions profile Problem ZeroClaw currently exposes agent capabilities only through WebSocket, ACP, and per-channel webhooks. Clients that speak the OpenAI Chat Completions protocol — Open WebUI, LobeChat, Continue.dev, Aider, LangChain, the OpenAI SDK, and many others — cannot connect without building a custom adapter: translating request shapes, translating tool-call/tool-result events, and managing session state themselves. Every client re-implements this; every protocol change forces them all to catch up; and writing the adapter requires understanding ZeroClaw's internal turn model. We want to add a POST /v1/chat/completions endpoint so these clients can point at a base URL and drive an agent through their existing OpenAI-protocol integration, without writing their own adapter. But which layer

Why it matters

This is unusually concrete governance for a local-first project: a single pilot has a fixed purpose, schema, deadline, deletion path and retirement receipt. It also admits what the data cannot prove—unique users, market share or a safe default. The operational test is whether persisted state, execution authority and visible user outcome describe the same event. Broad retries, hidden suppression or permission expansion can hide the symptom while making the boundary less trustworthy.

Current

The primary record was open when captured on 2026-08-03. The release baseline was v0.8.4 published 2026-08-02T21:00:00Z. Current repository metadata, pull requests, issues, release records, Google News discovery, Hacker News discovery, Lobsters, Metamesh and the rendered ClawCharts HTML row were checked. ClawCharts selected the subject; it did not prove the claim.

Evidence

The primary URL is https://github.com/zeroclaw-labs/zeroclaw/issues/9621. Supporting records are https://github.com/zeroclaw-labs/zeroclaw/issues/7232 and https://github.com/zeroclaw-labs/zeroclaw/issues/8603. Their source bodies, timestamps and states were captured in the daily evidence bundle. Test counts, reproductions and deployment observations remain attributed to their authors unless explicitly identified as independently rerun.

Source boundary

Open work is described as open, closed work as closed, and operator reports as reports. A pull request is evidence of proposed or reviewed direction, not proof of a shipped release. Issue closure would not by itself prove a deployed fix. Search residue, package mirrors and historically published source spines were excluded.

Operator take

Do not let OTel become project analytics, require the second consent to bind exact bytes, publish the launch and retirement packets, and remove dormant study code unless separately renewed. Preserve a before-state receipt, make the smallest reversible change, and verify the original failure independently after intervention.

Caveat

Public project records are mutable. Status, scope and evidence can change after publication. This brief records the inspected state and does not authorize changes to a reader’s deployment.

Source inspected; source state, environment and release boundary remain explicit.