Spec: Extension telemetry

[inancgumus]

What?

Proposes how k6 should report which catalog extensions a test uses.

• Reports importable (k6/x/*) and subcommand (k6 x <name>) extensions.
• Filters to the catalog by reusing k6's cached catalog (k6 x already has it) to avoid reporting private extensions.
• Reports the same way whether the binary was built with xk6 or produced by binary provisioning.
• Reuses the existing usage-report opt-out, with no new endpoint and no backend change.

Why?

We have no idea which extensions users run. Now that there are binary provisioning and an extension catalog, we want to gather data to decide which extensions to promote, maintain, or retire.

Note

Spec and design only; the implementation lands in a separate PR. Every test name, function, and file reference in these docs is what that PR will create, not existing code (file:line anchors point at today's code).

Where to review what:

• proposal.md: scope and impact.
• spec.md: the behavior, as GIVEN/WHEN/THEN acceptance criteria. Most review value is here.
• design.md: the decisions and trade-offs. Disagreements go here.
• tasks.md: the implementer's step-by-step plan. Skim it unless you care about the build order.

The described tests point the report endpoint at a local test server, so no test data ever reaches BQ.

Related PR(s)/Issue(s)

• Add extension usage telemetry #6109

[joanlopez]

The whole capability is verified by two table-driven integration tests on the real command harness (internal/cmd/tests, NewGlobalTestState), one per surface: TestRunReportsExtensions for k6 run and TestSubcommandReportsUsage for k6 x.

Is this text explaining what the AI will need to implement later? It confused me to see such concrete and detailed technical references that aren't really there yet.

Nothing is mocked; extensions register through the normal paths and both the catalog and the report endpoint are local HTTP servers.

Does this mean that we'll have artificial data mixed with real data in BQ?

[inancgumus]

The task list is for the implementer, so everything it names is what the implementation will have. Fair point, though, it makes it read like the tests are already there. I'll reword it. BQ: Every test points to a local test server, so reports never leave the test process. Hopefully made that clearer now 🙇