fix: Prefill every parameter editor with the value it has

[razor-x]

Closes the same hole as #624, and the rest of it: opening a parameter to change it should never start from a blank.

The problem

Interactive mode already lists every parameter with the value it was given — from --flags, from the JSON piped in, or from an earlier trip through the menu. But every editor behind that list opens from nothing:

Editor	Opening on --search 'foo bar', --limit 25, --sort-direction desc, …
text / id (promptText)	blank — retype the whole value to change one character
number (promptNumber)	blank
enum (promptSelect)	first choice, not the current one
enum list (promptAutocompleteMultiselect)	nothing selected — reselect everything
boolean (promptConfirm)	hardcoded true, even when the value is false
timestamp	blank
object (interactForBlueprintObject)	params: {} — the value is dropped as soon as it is looked at
resource picker (interactForResource)	first resource, not the one already set

The object row is the data-loss one #624 found, and it is worth restating: interactForBlueprintObject opens the sub-editor on params: {}, so leaving with [Back] or dismissing returns those empty params, the parent menu assigns them over what was given, and the request body goes out with {}. That is 30 request parameters in the current schema, /acs/users/create --access-schedule and /access_grants/create --user-identity among them. The list and metadata editors were already seeded (args.params[paramToEdit] || [] / || {}); the object editor was the one that was not.

All of it contradicts the README (--interactive "is prefilled with whatever you passed as arguments") and this function's own comment that dismissing a prompt returns to the menu "with the parameter left as it was".

What changed

• src/lib/prompt.ts — initialValue on the text, number and select options, initialValues on a new PromptMultiselectOptions, each passed to the clack prompt that already supports it. Undefined is stripped rather than passed through, since clack's option types plus exactOptionalPropertyTypes reject an explicit undefined.
• offeredValue / offeredValues — a value is only handed to a list prompt when the list offers it. This one is load-bearing rather than defensive: clack's autocomplete answers undefined for a selection with no choice behind it, so --device-id dev_deleted would have blanked the parameter on the way through the picker. Verified against the real prompt, not assumed:

  unmatched initialValue answers: undefined
  

• src/lib/interactions/blueprint-object.ts — each branch opens its editor on the current value, via toText / toNumber / toBoolean / toTextList / toRecord. Params are passed through as given, so a value need not match the format its parameter documents — the JSON piped in is arbitrary, and a schema can change under a script. A value the editor cannot start from is left out of it, opening the editor exactly as it does for an unset parameter. That also fixes interactForArray being handed a bare string and spreading it into characters.
• Resource pickers (resource, device, access-code, connected-account, user-identity, acs-*) — take the resource already chosen and open on it. interactForAcsSystem now takes an options object, so its message and initialValue cannot be confused for one another.
• interactForCustomMetadata — the one prompt that both adds and edits a key opens on that key's current value.
• src/lib/memory-prompt.ts — records what each question was seeded with, so a test can assert on what the user would see.
• README — says what is now true of every editor, not only the parameter list.

Nothing is taken away: Unset, Set to null and [Leave Empty] all still clear a value, and dismissing an editor still returns to the menu with the parameter as it was.

Verification

npm test, npm run typecheck, npm run lint — 311 tests passing (286 before), clean type-check and lint.

25 tests added across test/interactions/blueprint-object.test.ts, test/interactions/custom-metadata.test.ts and src/lib/prompt.test.ts. 13 of them fail on this tree without the source change; the "opens empty" cases stay green both ways, holding the unchanged behavior in place:

❯ test/interactions/blueprint-object.test.ts (40 tests | 13 failed)
   × opens a text prompt on the value the parameter has
   × opens a number prompt on the value the parameter has
   × opens an enum list on the value the parameter has
   × opens a confirm on the value true the parameter has
   × opens a confirm on the value false the parameter has
   × opens an enum list editor with the values the parameter has selected
   × opens the list editor empty for a value that is not a list
   × opens the timestamp prompt on the value the parameter has
   × opens an object editor on the value the parameter has
   × leaving an object editor keeps the value the parameter has
   × dismissing an object editor keeps the value the parameter has
   × edits one sub-property of the value the parameter has
   × leaves the given params unmodified

The clack behavior this rests on was also checked directly against the real prompts rather than inferred from the types — a prefilled text prompt renders its value and returns it edited ("foo bar" + " baz" → "foo bar baz"), and a list opens on the value given.

---

Generated by Claude Code