Problem
select() review requests currently force the human to choose one of the generated options. In real dogfood, the human sometimes wants to keep using an existing / better option that is not in the generated list.
Concrete example: in the Palmer content workflow, the angle picker generated five fresh options, but Skylar wanted to continue with the established angle: skills are just suggestions.
Right now the Review Queue does not make that easy. The operator either has to pick the closest wrong option, route around the UI, or rely on an out-of-band/manual response.
Desired outcome
Selection review cards should include a way for the human to directly specify a custom option.
The custom option should:
- return the same typed schema as the listed options when a schema exists;
- preserve clear provenance that the value was human-entered, not model-generated;
- work from the dashboard / Review Queue path, not only from CLI/plugin internals;
- keep the generated options available as the fast path.
Scope / notes
Possible UX:
- Add an
Other / custom affordance to input_surface.kind = "selection" cards.
- If the selection value is a structured object, render editable fields from the schema descriptor.
- For simple scalar selections, show a single text input.
- Record both the chosen custom payload and a marker such as
source: human_custom / equivalent event provenance.
This should not weaken validation: custom input still has to satisfy the declared return schema.
Acceptance criteria
- A workflow using
select(key, options) can be completed from the dashboard with a custom human-entered value not present in options.
- The submitted custom value is validated against the same return schema as generated options.
- Run detail / event history makes it obvious the value was human-entered.
- Existing select-option behavior remains unchanged for normal option clicks.
- Add regression coverage for structured-object selections and simple scalar selections.
Problem
select()review requests currently force the human to choose one of the generated options. In real dogfood, the human sometimes wants to keep using an existing / better option that is not in the generated list.Concrete example: in the Palmer content workflow, the angle picker generated five fresh options, but Skylar wanted to continue with the established angle:
skills are just suggestions.Right now the Review Queue does not make that easy. The operator either has to pick the closest wrong option, route around the UI, or rely on an out-of-band/manual response.
Desired outcome
Selection review cards should include a way for the human to directly specify a custom option.
The custom option should:
Scope / notes
Possible UX:
Other / customaffordance toinput_surface.kind = "selection"cards.source: human_custom/ equivalent event provenance.This should not weaken validation: custom input still has to satisfy the declared return schema.
Acceptance criteria
select(key, options)can be completed from the dashboard with a custom human-entered value not present inoptions.