fix(telemetry): drop profile field [skip-runtime-e2e]

[saurabhjain1592]

Summary

The v1 telemetry schema (#220) added a profile field on TelemetryPayload sourced from process.env.AXONFLOW_PROFILE. That env var name was already taken by the agent's governance enforcement layer (platform/agent/profile.go, allowlist dev | default | strict | compliance, ADR-036), while the telemetry validator on prod-checkpoint accepts only dev | prod | unknown.

Customer sets AXONFLOW_PROFILE=	Governance engine	Telemetry validator
dev	accepts	accepts
strict	accepts	rejects (HTTP 400)
compliance	accepts	rejects (HTTP 400)
production	rejects	rejects (HTTP 400)

The deployment_mode field already covers topology classification (self_hosted | community_saas | unknown) — the analytics dimension profile was meant to add. No consumer reads the stored profile column on the server side either, so removal loses no signal that's actually being used and lets AXONFLOW_PROFILE revert to its single governance meaning.

This is the TypeScript SDK leg of the coordinated 10-PR train tracked under axonflow-enterprise#2033.

Changes

• src/telemetry.ts — remove the profile: string field on the TelemetryPayload interface plus its doc comment, remove the two process.env.AXONFLOW_PROFILE reads (one in sendTelemetryPingNow, one in sendTelemetryPing), and remove the corresponding profile assignment in both payload literals. Updated the surrounding doc comments to drop the AXONFLOW_PROFILE mention.
• tests/telemetry.test.ts — drop the expect(payload.profile).toBe('unknown') assertion in the payload-shape test.
• test/telemetry-endpoint-type.test.ts — drop profile: 'unknown' from the two TelemetryPayload literals used by the type-shape and URL-leak tests.
• package.json + package-lock.json + src/version.ts — version bump 8.0.0 → 8.0.1 (re-stamped via npm run stamp-version).
• CHANGELOG.md — new [8.0.1] entry under ### Removed noting the env-var collision rationale.

Audit grep

$ grep -rnE 'AXONFLOW_PROFILE|profile:.*string|profile.*=' --include='*.ts' src tests test
(no matches)

$ grep -rn 'profile' --include='*.ts' src test tests
src/types/llm-providers.ts:20: * free-form provider-specific record (e.g. Bedrock inference-profile id,

The remaining hit is the unrelated Bedrock inference-profile reference in the LLM provider types — not telemetry-related.

Self-review (5-question protocol per hunk)

Walked the diff hunk-by-hunk:

1. TelemetryPayload interface — removed profile field + doc comment. Does the change do what the commit message says? Yes. Are there other call-sites that construct a TelemetryPayload? Checked: two production sites in src/telemetry.ts (covered) and two test sites in test/telemetry-endpoint-type.test.ts (covered). Are there public re-exports affected? TelemetryPayload is exported but the field is being removed, not added — consumers were already loose-typing or not setting it. Is the build green? Yes. Is the lint clean? Yes.
2. sendTelemetryPingNow — removed env read + payload assignment + comment update. Same five — yes, yes, yes, yes, yes.
3. sendTelemetryPing — same shape as fix: generatePlan sends incorrect user_token causing auth errors #2. Same five — yes, yes, yes, yes, yes.
4. tests/telemetry.test.ts — removed expect(payload.profile).toBe('unknown'). Does it leave the test still meaningful? Yes — the surrounding payload-shape test still asserts every other field. Does it match a removed type member? Yes. CI green? Locally: 56/56 telemetry tests pass.
5. test/telemetry-endpoint-type.test.ts — removed profile: 'unknown' from two literals. Same shape. Both literals also keep all other fields. Type-shape compiles after the removal.
6. package.json + package-lock.json + src/version.ts — 8.0.0 → 8.0.1. Patch bump per the briefing. Lock-file bump was scoped to the two @axonflow/sdk self-references at lines 3 and 9 only; nested deps untouched. src/version.ts was re-stamped via the prebuild script.
7. CHANGELOG.md — new [8.0.1] entry. Customer-facing language only, no internal repo paths or deployment automation references.

Test plan

• npm install clean
• npm test -- --testPathPattern='telemetry' — 56/56 pass
• npm run build — green (CJS + ESM + ESM-imports fix)
• npm run lint — clean
• npm run format:check — clean
• CI green on PR
• Runtime-proof against staging-checkpoint after the train merges (per #2033 plan)

Pre-existing local test failures

test/client.test.ts has 5 LLM-routing test failures (lines 268, 285, 301, 317, 333) that reproduce on main as well, unmodified by this PR. CI on main runs the same suite green (894 passed of 907 most recently), so the failures appear to be a local environment / mock issue rather than a regression. Not in scope for this revert.

Coordination

Part of the 10-PR train under axonflow-enterprise#2033. Per the brief, do not tag/release this repo until the full train (1 server + 9 clients) merges and the staging-checkpoint runtime proof is committed.

Skip-runtime-e2e justification

This PR is part of the #2033 coordinated train across 1 server + 9 client repos. Per the session-2033 brief, runtime proof is deferred to the post-server-merge staging-checkpoint deploy:

1. axonflow-enterprise#2035 (server) merges + gh workflow run deploy-checkpoint.yml -f environment=staging deploys the new code to staging-checkpoint.getaxonflow.com.
2. Each of the 9 client builds is then driven against staging-checkpoint with verification that (a) POST returns 200 (no validator complaint about missing profile) and (b) the resulting DDB row has no profile attribute.
3. EVIDENCE lands at runtime-e2e/profile_field_removal/EVIDENCE/<utc-ts>/ post-deploy.

Adding a same-PR runtime-e2e/ test here would either:

• exercise a fake checkpoint server (forbidden by lint-no-mocks-in-runtime-e2e.sh), or
• run against the live deployed Lambda BEFORE the server PR has deployed, which would either silently pass (ignored field) or fail (depending on deploy ordering) — neither outcome is informative.

The post-deploy proof against staging-checkpoint is the only meaningful runtime test for this train.