fix(cli): remove duplicate `name` from job generator templateVars

[lisa-assistant]

Summary

In packages/cli/src/commands/generate/job/jobHandler.js at line 48–50, the name field is passed redundantly in templateVars:

templateVars: { name: jobName, queueName, ...rest },

The templateForFile helper (in yargsHandlerHelpers.js) already includes name from its top-level parameter in mergedTemplateVars:

const mergedTemplateVars = {
  name,          // already set from templateForFile's own `name` arg
  outputPath: ...,
  ...templateVars, // templateVars.name currently overwrites the above (same value)
}

Since templateVars is spread after name, passing name: jobName inside templateVars is a no-op — it just overwrites name with the same value. The TODO comment at line 48 explicitly calls this out:

// TODO: Remove name here. It's already passed to the template by the helper function we're using

Fix

Remove name: jobName from the templateVars object in the first templateForFile call:

// Before
templateVars: { name: jobName, queueName, ...rest },

// After
templateVars: { queueName, ...rest },

Files

• packages/cli/src/commands/generate/job/jobHandler.js — line 50, remove name: jobName from templateVars

Notes

• The second and third templateForFile calls in the same file (for test and scenario files) already omit name from templateVars (they just use { ...rest }), confirming this pattern is intentional.
• Related: fix(cli): generate job should produce camelCase filenames and class names #1573 (make job generator use camelCase)

[lisa-assistant]

Self-fix confidence: 8/10

This is a pure dead-code removal — removing a key from an object literal where that key is already set by the helper that wraps it. The template behaviour won't change since both paths produce mergedTemplateVars.name = jobName. The 2-point deduction is for the slim chance the template or a downstream consumer accesses templateVars.name directly (i.e., outside the mergedTemplateVars merge), which would break. A quick grep confirms no such access exists.

[lisa-assistant]

Implementation Plan

Goal: Remove the redundant name: jobName from templateVars in the first templateForFile call — the helper already injects name from its top-level argument.

Root cause recap

In yargsHandlerHelpers.js, templateForFile builds mergedTemplateVars like this:

const mergedTemplateVars = {
  name,          // set from the top-level  arg passed to templateForFile
  outputPath: ...,
  ...templateVars,  // spread AFTER — so passing name: jobName here just no-ops
}

The name: jobName in templateVars is always overwritten by the same value that was passed as the top-level name argument, so it's pure noise.

Change

File: packages/cli/src/commands/generate/job/jobHandler.js

// Before (line 50)
templateVars: { name: jobName, queueName, ...rest },

// After
templateVars: { queueName, ...rest },

Also remove the TODO comment on lines 48–49 since it'll be resolved.

Verification

The second and third templateForFile calls in the same function (for test and scenario files) already use templateVars: { ...rest } without name — this change makes the first call consistent with those.

Edge cases

• Template actually needs name? Check job.ts.template — it uses <%= name %>. That still works fine because templateForFile sets it from the top-level name: jobName argument.
• Any other callers of templateForFile that pass name in templateVars? A quick grep of the codebase shows no other call sites do this, so the pattern is isolated to this one TODO.

Tests

The existing tests in packages/cli/src/commands/generate/job/__tests__/ should continue to pass unchanged — the generated output is identical since the effective value of name in the template doesn't change.

Summary

One line to remove plus the two-line TODO comment block. No functional change, no test updates required.

[lisa-assistant]

Self-fix confidence: 9/10

This is a one-line removal — delete name: jobName from the templateVars object literal. The surrounding logic is unchanged, the template still receives name via the top-level name argument to templateForFile, and the other two calls in the same function already omit it. The 1-point deduction is just for confirming the template rendering pipeline hasn't changed in a way that would break the assumption (easy to verify by running yarn cedar generate job end-to-end).