Summary

coval dashboards create/update only accepted --name. This adds the rest of the dashboard fields the v1 API exposes (paired backend PR coval-ai/backend#4498) so the CLI can fully manage dashboards — including marking one as the organization's default /dashboard.

Linear: API-373

New flags (create + update)

These compose with --input-json like the existing flags. The dashboard response model and --format json output now include description, is_default, is_favorite, position, and config, and the table view gains a DEFAULT column.

Tests

cargo fmt, cargo clippy --all-targets -D warnings, and cargo test all pass. Added two tests asserting the new flags are serialized into the create POST and update PATCH bodies (via body_partial_json) and that responses carrying the new fields parse.

No version bump here — per this repo's convention version bumps land in a separate chore: PR after merge.

Summary by CodeRabbit

• New Features

  • Dashboards now accept description, favorite flag, default flag, position, and custom JSON config when creating or updating.

• Documentation

  • README example updated to show creating a dashboard and marking it as the organization default.

• Tests

  • Added integration tests verifying create/update commands serialize and send the new dashboard parameters.

Proof

CI: all 5 platform builds (macOS arm64/x64, Linux arm64/x64, Windows x64) + check green on this PR. Reproduced locally:

fmt + clippy — cargo fmt --check clean; cargo clippy --all-targets -- -D warnings clean (no warnings).

coval dashboards create --help (new flags wired, booleans constrained to true|false):

Options:
      --name <NAME>
      --description <DESCRIPTION>
      --favorite <FAVORITE>    Mark as a favorite (true/false) [possible values: true, false]
      --default <DEFAULT>      Make this the organization's default dashboard (true/false).
                               Omit to auto-default the first dashboard [possible values: true, false]
      --position <POSITION>    Ordering position (>= 0). Omit to append to the end
      --config <CONFIG>        Free-form JSON config: a JSON string or @path to a file

Tests — cargo test → 74 passed; 0 failed. The two new tests assert the flags serialize into the request body (wiremock body_partial_json) and that responses carrying the new fields parse:

test test_dashboard_create_with_full_fields ... ok
test test_dashboard_update_sets_default_and_position ... ok

test_dashboard_create_with_full_fields runs dashboards create --name Ops --description desc --favorite true --default true --position 3 --config '{"date_preferences":{"preset":"last-7-days"}}' and asserts the POST body contains display_name/description/is_favorite/is_default/position/config — a wrong flag→JSON-key mapping (e.g. --default not mapping to is_default) would 404 the mock and fail the test.

Note: a live run against current prod isn't shown because the new fields are server-side-gated on coval-ai/backend#4498 — current prod silently ignores unknown request fields, so a prod run wouldn't actually exercise them until that PR is deployed. End-to-end proof against the real API lands via that PR's post-merge integration suite.