/**
 * SMI-6362 §1: `withTelemetry`'s second sink — a `tool_call` event dispatched
 * through `emitToolCallEvent` (`../audit/remote-audit.js`) alongside the
 * pre-existing `trackSkillInvoke` (PostHog `skill_invoke`) sink. Sibling to
 * `wrap.test.ts` (500-line file gate), matching the existing
 * `wrap.gate.test.ts` / `wrap.marker.test.ts` split convention for this file.
 *
 * The plan's AC-11 test-coverage row for "`wrap.ts` second sink" requires
 * proving, at the `withTelemetry` integration level (not re-testing
 * `emitToolCallEvent`'s own unit behaviour, already covered exhaustively by
 * `remote-audit.test.ts`):
 *   - gate-off ⇒ BOTH sinks stay silent, not just the legacy one (the D-1
 *     client-side invariant, asserted at the single enforcement point)
 *   - gate-on (with tool-name context installed) ⇒ both sinks fire
 *   - a transport-layer rejection from the second sink does not change the
 *     wrapped function's own return value or thrown errors
 *   - an identity provider returning `null` ⇒ no POST is attempted and
 *     `skippedNoIdentity` increments
 *
 * These tests exercise the REAL `remote-audit.js` (only `getOrCreateInstallId`
 * and global `fetch` are stubbed, matching `remote-audit.test.ts`'s own
 * convention) so they prove the actual wiring `wrap.ts` performs, not a
 * stand-in that could silently drift from it.
 */
export {};
//# sourceMappingURL=wrap.tool-call-sink.test.d.ts.map