feat(cli): send metadata to vNext localization endpoint

[cherkanovart]

Summary

• Add sessionId (unique per CLI invocation), triggerType ("cli" or "ci"), and metadata: { filePath } to vNext localization API requests
• Remove unused workflowId from request params
• Keep fast in params for potential future use

Closes ENG-415

Test plan

• Verify CLI builds cleanly (pnpm turbo build --filter=lingo.dev)
• Run the CLI with vNext localizer and confirm the request body includes sessionId, triggerType, and metadata.filePath
• Run with CI=true and verify triggerType is "ci"

🤖 Generated with Claude Code

Summary by CodeRabbit

• New Features
  • Localization requests now automatically include enhanced session identifiers, trigger type metadata, and file path information for improved operation tracking, visibility, and context management
  • Improved localization endpoint integration with richer metadata propagation, enabling better request identification, enhanced authentication context, and comprehensive operation monitoring across the pipeline

[coderabbitai]

📝 Walkthrough

Walkthrough

Adds file path metadata propagation through CLI localization flow and augments the vNext engine requests with sessionId and triggerType. Updates type definitions, extends localizer method signatures, adjusts request payload (adds metadata and params.fast, removes workflowId), and documents the change via a new changeset.

Changes

Cohort / File(s)	Summary
Changeset / Docs .changeset/send-metadata-to-endpoint.md	Adds patch note documenting that sessionId, triggerType, and filePath metadata are sent to the vNext localization endpoint.
CLI Execute Hook packages/cli/src/cli/cmd/run/execute.ts	Passes filePath (from assignedTask.bucketPathPattern) into localize input payload.
Localizer Types packages/cli/src/cli/localizer/_types.ts	Extends LocalizerData with optional filePath; expands ILocalizer.checkAuth return to include optional error.
vNext Localizer Engine packages/cli/src/cli/localizer/lingodotdev-vnext.ts	Introduces sessionId and triggerType in engine config; adds filePath to localizeObject and localizeChunk; request body now includes params: { fast }, sessionId, triggerType, and metadata.filePath; removes workflowId; minor refactors and formatting.

Sequence Diagram(s)

sequenceDiagram
  autonumber
  participant U as User/CLI
  participant EX as Execute.ts
  participant LZ as Localizer (VNext)
  participant EN as VNext Engine
  participant API as vNext Endpoint

  U->>EX: run localize
  EX->>LZ: localize({ data, filePath, ... })
  LZ->>EN: localizeObject(..., filePath)
  loop chunk over data
    EN->>API: POST /localize { dataChunk, params:{fast}, sessionId, triggerType, metadata:{filePath} }
    API-->>EN: 200 { translations }
  end
  EN-->>LZ: merged translations
  LZ-->>EX: result
  EX-->>U: output

Loading

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Suggested reviewers

• vrcprl

Poem

I tap my paws, a session spins anew,
With trigger sparks and paths that point true.
Hops of metadata, light as a breeze,
From burrow to endpoint, across data trees.
Fast flags flutter, chunks neatly align—
Carrots compiled, translations divine. 🥕✨

🚥 Pre-merge checks | ✅ 2 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 25.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately summarizes the main change: adding metadata to vNext localization endpoint requests, which is the primary focus of the changeset across all modified files.
Description check	✅ Passed	The description covers the summary and key changes, and includes a test plan. However, it lacks explicit testing results and doesn't fully align with the template's structure for business logic tests and checklist items.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

• 📝 Generate docstrings (stacked PR)
• 📝 Generate docstrings (commit on current branch)

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch eng-415/send-metadata-to-localization-endpoint

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

🧹 Nitpick comments (1)

packages/cli/src/cli/localizer/lingodotdev-vnext.ts (1)

81-86: The hardcoded whoami response is intentional but represents an architectural difference that should be documented.

vNext uses a different authentication model than the standard Lingo.dev provider. While all other implementations validate authentication through a server-side /whoami API call with Bearer tokens, vNext's whoami method returns static mock data without server validation. This is intentional (as indicated by the code comment), but it means:

• Authentication status is determined solely by API key presence in the localization endpoint calls, not by server-side verification
• The hardcoded user identity ("vnext-user") cannot be updated without code changes
• checkAuth() will always return authenticated: true if the method succeeds, regardless of API key validity

Consider clarifying the purpose and security implications of this design in the code comment.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/cli/src/cli/localizer/lingodotdev-vnext.ts` around lines 81 - 86,
Update the comment above the async whoami(...) method in lingodotdev-vnext.ts to
clearly document that this implementation intentionally returns static/mock
identity data (email: "vnext-user", id: config.processId) and does not perform
server-side validation, explain that authentication is determined by API key
presence on localization endpoint calls (not by whoami), note that checkAuth()
will always report authenticated:true if whoami() succeeds regardless of API key
validity, and call out the maintenance implication that the hardcoded identity
cannot be changed without code modifications so consumers should not rely on
dynamic user identity or server verification for security.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In `@packages/cli/src/cli/localizer/lingodotdev-vnext.ts`:
- Around line 81-86: Update the comment above the async whoami(...) method in
lingodotdev-vnext.ts to clearly document that this implementation intentionally
returns static/mock identity data (email: "vnext-user", id: config.processId)
and does not perform server-side validation, explain that authentication is
determined by API key presence on localization endpoint calls (not by whoami),
note that checkAuth() will always report authenticated:true if whoami() succeeds
regardless of API key validity, and call out the maintenance implication that
the hardcoded identity cannot be changed without code modifications so consumers
should not rely on dynamic user identity or server verification for security.

---

ℹ️ Review info

Configuration used: defaults

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 3f0d52f and 6a9e519.

📒 Files selected for processing (4)

• .changeset/send-metadata-to-endpoint.md
• packages/cli/src/cli/cmd/run/execute.ts
• packages/cli/src/cli/localizer/_types.ts
• packages/cli/src/cli/localizer/lingodotdev-vnext.ts