fix(python-cli): allow qualitative goal creation without metric options - #13095
Conversation
The developer API (backend/routers/developer.py CreateGoalRequest) supports goals with all metric fields omitted (qualitative goals), but the CLI's 'omi goal create' required --target, exiting 2 with a usage error before any HTTP request. This made qualitative goals impossible from the CLI. Make --target/--type/--current/--min/--max optional. When no metric option is provided, send only the title (qualitative goal). When any metric option is provided, keep the historical defaults (type=scale, current=0, min=0, max=10) so existing scripts behave exactly as before. Fixes BasedHardware#13085
There was a problem hiding this comment.
All reported issues were addressed across 2 files
Reply with feedback, questions, or to request a fix.
Re-trigger cubic
Address cubic review findings on BasedHardware#13095: --unit without any metric flag was silently dropped by the backend for qualitative goals, and partial metric options without --target fabricated a target-less scale goal. Both now exit 1 with clear guidance; --target is always sent when a metric goal is requested. 🤖 Generated with Codebuff Co-Authored-By: Codebuff <noreply@codebuff.com>
|
Both review findings are fixed in daf249e:
New tests: |
kodjima33
left a comment
There was a problem hiding this comment.
Real bug: CLI requires --target even though the backend's CreateGoalRequest supports qualitative goals with no metric fields. Confirmed --target still required on main. Scoped fix (130 loc) with 5 new tests covering both qualitative and backward-compat metric paths. Confidence 5/5.
Problem
omi --json goal create "Build stronger relationships"exits 2 with a missing--targetusage error before any HTTP request is sent.The developer API explicitly supports qualitative goals by omitting all metric fields —
CreateGoalRequestinbackend/routers/developer.pydeclaresgoal_type,target_value,current_value,min_value,max_valueasOptional(all defaultNone). The CLI is stricter than the API it wraps, so qualitative goals are impossible to create from the CLI.Fixes #13085
Root cause
create_goalinsdks/python-cli/omi_cli/commands/goal.pydeclared--targetas required (typer.Option(...)) and always sent every metric field in the request body.Implementation
--target,--type,--current,--min,--maxoptional (Optional[float]/Optional[GoalType], defaultNone).{"title": ...}— a qualitative goal, exactly what the API accepts.type=scale,current=0,min=0,max=10) so existing scripts behave identically.--unitwithout any metric option is rejected (exit 1) — the backend only persistsuniton metric-backed goals, so it would be silently dropped on a qualitative goal.--targetare rejected (exit 1) — preserving the historical contract that every metric goal has a target, instead of fabricating a target-less scale goal.--unitcontinues to be attached whenever provided alongside a metric goal.Testing
test_goal_create_qualitative_omits_metrics— qualitative request body contains only the title.test_goal_create_metric_defaults_preserved—--target 2alone still produces the historical scale defaults (backward compat).test_goal_create_unit_without_metrics_rejected—--unitalone exits 1 with guidance.test_goal_create_partial_metrics_rejected—--current 5without--targetexits 1 with guidance.test_goal_create_unit_attached_to_metric_goal—--target 2 --unit literssendsunitthrough.tests/test_openapi_contract.pyon older runs are pre-existing on currentmainand unrelated to this change.blackclean on both touched files.Compatibility
No breaking change for valid invocations: every command that worked before produces the same request body. The only behavior changes are that omitting metric options now succeeds (qualitative goal) instead of exiting with a usage error, and previously broken partial-metric invocations now fail fast with a clear client-side message instead of creating a malformed goal server-side.