feat: [ENG-2486] Extend transport schemas with provider/model

[bao-byterover]

No description provided.

[github-actions]

Claude finished @bao-byterover's task in 2m 31s —— View job

---

PR Review: feat: [ENG-2486] Extend transport schemas with provider/model

• Gather context and read changed files
• Analyze code for correctness, security, and quality
• Post inline comments for specific issues
• Post general summary with overall score

---

Summary

This PR extends four files to carry provider and model as optional string fields through the task tracking layer:

File	Change
src/server/core/domain/transport/task-info.ts	+model?, provider? to TaskInfo
src/server/core/domain/transport/schemas.ts	+model?, provider? to TaskCreatedSchema and TaskListItemSchema
src/shared/transport/events/task-events.ts	+model?, provider? to TaskListItem interface
test/unit/core/domain/transport/schemas.test.ts	New test file covering both Zod schemas

The changes are backward-compatible (all new fields are optional), consistently applied across the type/interface/schema trio, and well-named with clear JSDoc.

---

Issues Found

question — task-info.ts line 23: Where does model/provider actually get written? The PR only defines the fields — no implementation change populates them from ProviderConfigResponse at task-creation time. If the write path lives in a separate PR, that should be noted; otherwise these fields will silently remain undefined in all task records.

suggestion — schemas.ts (TaskCreatedSchema, TaskListItemSchema): Both new fields are plain z.string(), which accepts "". Consider .min(1) to reject empty-string values that are semantically meaningless as provider/model identifiers.

suggestion — schemas.test.ts: Test coverage is good for happy paths (with both fields, with one field, with neither). Adding a negative test for provider: "" / model: "" would complete the picture — especially if the .min(1) suggestion above is adopted.

nitpick — task-events.ts TaskListItem and schemas.ts TaskListItemSchema define the same shape in two places (interface vs Zod). This is a pre-existing drift risk, not introduced here, but worth noting: deriving the interface via z.infer<typeof TaskListItemSchema> in the shared transport file would eliminate the duplication.

---

Overall Score: 4 / 5

Clean, minimal, well-targeted. The main concern is the missing write path for the new fields — if that's not in a follow-up PR, the fields will be dead weight. All other issues are minor improvements.

[github-actions]

question: Where does model (and provider below) get set on the TaskInfo object? I see it defined here but no implementation change populates these fields from ProviderConfigResponse. Without a write path, the fields will always be undefined in production task records. Can you point to the code that reads the active provider/model config and sets them at task-creation time?

[github-actions]

suggestion: Consider adding .min(1) validation to both provider and model here (and in TaskListItemSchema) to prevent meaningless empty-string values from passing validation:

Suggested change

	folderPath: z.string().optional(),
	model: z.string().min(1).optional(),

An empty string is technically valid as z.string() but semantically meaningless for a provider/model identifier. Failing fast with a clear error is better than silently storing "".

Fix this →

[github-actions]

suggestion: The test suite covers the happy paths well, but is missing a negative test for empty strings. Since provider/model are z.string(), Zod will accept "" silently:

it('rejects empty string for provider', () => {
  const result = TaskListItemSchema.safeParse({
    ...baseEntry,
    provider: '',
  })
  expect(result.success).to.equal(false)
})

This is only useful if you add .min(1) to the schemas (see the related schema comment), but worth adding to document the intent.

Fix this →