Addressed the 3+ values test case in 718b048. The comment about supported array types is fair but the function is 20 lines and self-documenting — adding a comment would be noise.

TDD Assessment — PR #186

What's covered well

• Happy-path merges for both []map[string]string (option arrays) and []string (label arrays)
• Scalar overwrite behavior
• Type mismatch case (scalar existing + array new) — new value wins

Missing test cases for MergeFieldValues

Nil/empty inputs

• existing = nil, newVal = []string{"x"} — hits the default branch, new value wins, but not explicitly asserted
• existing = []string{}, newVal = []string{"x"} — zero-length append; append([]string{}, ...) works correctly but is unverified
• existing = []string{"x"}, newVal = []string{} — appending nothing; could silently return the original

Reverse type mismatch (not tested)

• existing = []string{"x"}, newVal = "scalar" — outer []string branch matches, inner newArr assertion fails, falls through to return newVal; the scalar wins. This is the opposite of the tested mismatch and has meaningfully different semantics worth documenting
• existing = []map[string]string{...}, newVal = []string{"x"} — also silent fallthrough to return newVal; a reviewer would ask whether that's intentional

Multiple-element accumulation

• Only one element on each side is tested. A three-call sequence (A → merge B → merge C) is not exercised, so growing-slice correctness across more than two inputs is unverified.

Gaps in create.go / update.go integration paths

The field-loop change in both files is not covered by any unit or integration test at the command level:

• No test exercises runCreate or runUpdate with duplicate --field keys
• The only coverage is the pure MergeFieldValues unit test; the if existing, ok := fields[fieldID] branch in the command code is never hit by the test suite
• The test plan in the PR description notes "Integration test: update a multi-checkbox field…" is unchecked

Business logic concern

FormatFieldValue can also return map[string]string (for option, user, issuelink, priority, etc.) and float64 (for number). When existing is one of those non-array types and newVal is also one of those types, MergeFieldValues correctly returns newVal (scalar overwrite). That's fine for most fields — but for a user array field (schema type array, items user), FormatFieldValue returns []string{value}, so repeated user fields would merge correctly. This edge case is present in the code but absent from tests.

What a reviewer would flag

1. No command-level test for the accumulation path — the fix to create.go and update.go is entirely untested; MergeFieldValues unit tests don't exercise the call sites
2. Nil inputs to MergeFieldValues are unspecified — Go's type-switch will fall through to return newVal, but the function contract doesn't document it
3. Reverse type-mismatch behavior (array existing + scalar new) silently discards the existing array; this likely matches the intent but no test or comment confirms it
4. Unchecked integration test item in the PR description — should be checked or converted to a follow-up issue before merge

Overall the unit tests cover the documented happy paths but leave the call-site integration and the nil/reverse-mismatch edge cases unverified.