Record wrapper command context and errors without input snapshots

TELEMETRY.md

@@ -80,6 +80,8 @@ You may also opt out by setting the cross-tool environment variable
 
 The Rust and BAML toolchain wrappers share an independent PostHog event schema. Each invocation emits one canonical command event, such as `baml`, `baml check`, `baml toolchain status`, `baml toolchain update`, or `baml self-update`, with `event_kind = "invocation"`. All flags and argument values are discarded: `baml --help` becomes `baml`, and `baml toolchain update --help` becomes `baml toolchain update`. Only recognized command names enter telemetry; unknown commands collapse to the nearest recognized parent. Delegated CLI commands use their recognized top-level name, without inspecting the CLI's nested arguments. Internal telemetry and replacement helpers are excluded.
 
+The canonical `baml` label does not prove empty argv: it also covers root help, version, unknown commands, and `--` termination.
+
 Every wrapper event includes `schema_version = 2`, its canonical `command`, and a `client` discriminator: `rust-wrapper` or `baml-in-baml`. Both implementations also emit `wrapper_resolution`, `wrapper_install`, `wrapper_selection`, `wrapper_update`, and `wrapper_self_update` for bounded decisions and outcomes. `wrapper_unhandled_error` records errors escaping the wrapper command handler, including argument parsing and failed handoffs. Recovered errors and delegated CLI nonzero exit codes do not count as unhandled wrapper errors. A delegated CLI keeps its separate telemetry.
 
 Events include coarse OS/architecture/CPU/CI information, a random anonymous identity and session, and a salted project-root hash. Source categories, toolchain kinds, and outcomes are bounded labels; argument values, selectors, raw paths, panic payloads, and error text are not sent.
@@ -92,6 +94,10 @@ Wrapper events are written locally before a toolchain handoff. If a handoff fail
 
 The Rust wrapper sends only PostHog usage events. Release builds of the BAML-native wrapper additionally enable BCS runtime recording through an embedded public ingestion credential. BCS uses the existing packed-runtime policy: delivery runs on a background worker and shutdown waits for its normal bounded drain. The wrapper selects the existing `on_initial_telemetry_failure = "ignore"` policy. The PostHog queue retains its separate retry behavior. Set `BAML_TELEMETRY=off` to disable the BAML wrapper’s BCS recording.
 
+The BAML-native wrapper records error payloads at its explicit dispatch, argument-parser, management-parser/preflight/execution, toolchain-selection/acquisition, selected-CLI version reporting, passive freshness/refresh and self-update boundaries. It does not request full input snapshots or argument-bearing returned objects. Delegated and version calls retain only child exit code and signal in a `baml.sys.ProcessExit`; child stdout/stderr remain inherited and uncaptured. A delegated CLI/project keeps its own recording policy. Functions unwound by `sys.exit` have no returned output. Error payloads are retained as supplied and can quote offending arguments, selectors or paths, including secrets; suppressing input snapshots does not redact errors. Internal telemetry/replacement helpers bypass argument parsing, and command help bypasses management parsing and self-update. Capture applies to the requested invocation, not all descendants; errors recovered entirely inside an untraced utility retain its automatic policy. Other automatic functions do not acquire value capture from these requests or from `high`. For the packed wrapper, `BAML_TELEMETRY=on` keeps the baked default level (normally medium), while `off` disables BCS recording. HTTP network spans still exclude bodies. See the [wrapper capture boundary table](baml_language/wrapper/README.md) for exact scopes. This BCS policy does not change PostHog's metadata-only contract, identities, destinations or existing launch metadata.
+
+The BAML-native wrapper also attaches the same bounded canonical `command` to the foreground `user.dispatch` span and descendants, independently of PostHog and function value capture. Helpers remove this key in their dispatch scope. This does not update process launch metadata or add an identity; join dispatch to `processes` by `process_id` for process outcomes. See the [wrapper query example](baml_language/wrapper/README.md) for counting invocations without duplicating inherited spans.
+
 ## BCS environment metadata
 
 Enabled cloud runtime recordings automatically include the following scalar properties under the system-populated `baml.ctx.` prefix in the recorded process context's `metadata` map. The recording header's existing `initial_context_cas_id` references this context, which travels through the existing recording/CAS upload pipeline. This does not add a network request or change the recording format. The properties describe the process running BAML, including SDK calls, CLI commands and packed executables that select BCS delivery.