oc-telemetry-ops

Topics in the source

• Telemetry Ops
• /oc-telemetry — Command Reference
• How This Skill Fits the Build Pipeline
• Installed runtime
• The telemetryhandle checkpoint field (wire 1.1)
• Principle 1: Local-first metering, content-free by schema
• Principle 2: Opt-in — tracked state is not consent
• Principle 3: Aggregate-only export

On first invocation, read references/orchestrator.md and follow its welcome protocol. Answer "is anyone actually using this, and which parts?" — without betraying opchain's local-first, no-backend stance. Telemetry Ops meters skill/phase usage into a local SQLite store (.checkpoints/usage.sqlite), strictly opt-in, and produces an anonymized local aggregate export (pipelines run, most-used skill, model-tier mix, cost-per-shipped-feature). The public /dashboard currently uses sample data; export ingestion is not implemented. The CLI does not publish the raw store or the aggregate. This is not a hosted analytics product and not PostHog (that's the site's consent-gated client analytics). Telemetry Ops is about the skills pipeline's own usage, recorded where the work happens — locally, in git-adjacent state — so the numbers are real (they come from actual runs) and private (they stay put unless you export an aggregate). Default OFF. Tracked state is not consent. Metering does nothing until /oc-telemetry enable records opt-in in the gitignored local SQLite store. A telemetryhandle checkpoint field, including a cloned legacy enabled: true, is never consent. See references/privacy-consent.

This is an excerpt. Refer to the complete source and its current requirements.