model2data-studio 0.1.0__tar.gz → 0.3.0__tar.gz

{model2data_studio-0.1.0 → model2data_studio-0.3.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: model2data-studio
-Version: 0.1.0
+Version: 0.3.0
 Summary: Generate a model2data studio project's data from the command line, so CI can rebuild fixtures instead of committing them.
 Project-URL: Homepage, https://www.jbanalytica.com/model2data/
 Project-URL: Studio, https://studio.jbanalytica.com
@@ -69,11 +69,11 @@ the account, so put it in your CI provider's secrets rather than in a file.
 
 Leave the key's access on **Generate and export**, which is the default and
 covers everything below: reading a project, generating, exporting. A key with
-**Read only** access is refused by `generate` with a 403 saying so. The two
-levels above it are for things the CLI does not do — **Generate and save** adds
-writing the project back, for a pipeline that pushes a schema up rather than
-pulling data down, and **Full access** adds deleting a project and managing its
-share links. A key that leaks out of a CI log can only do what it was given.
+**Read only** access is refused by `generate` with a 403 saying so. **Generate
+and save** adds writing the project back, which `push` and `dashboard push` need — for a
+pipeline that pushes a model up rather than pulling data down — and **Full access** adds
+deleting a project and managing its share links, which the CLI never does. A
+key that leaks out of a CI log can only do what it was given.
 
 ## Commands
 
@@ -83,6 +83,17 @@ model2data-studio whoami                # the plan behind the key, and what it h
 
 model2data-studio generate --project <id> --out seeds/
 model2data-studio generate --project <id> --out . --format dbt --adapter duckdb
+
+model2data-studio push --project <id> shop.model2data.yml   # save a model as the project's
+
+model2data-studio metrics list --project ID            # what each metric computes
+model2data-studio metrics check --project shop.metrics.yml  # exits 1 on an error, for CI
+model2data-studio metrics values --project ID --seed 42 --as-of 2026-10-01
+model2data-studio metrics suggest --project shop.model2data.yml -o shop.metrics.yml
+
+model2data-studio dashboard pull <id> --out dashboards/       # one <name>.dashboard.yml each
+model2data-studio dashboard push <id> dashboards/*.dashboard.yml
+model2data-studio dashboard check dashboards/*.dashboard.yml --project <id>   # for CI
 ```
 
 `generate` takes every setting from the saved project — row counts, per-table
@@ -102,6 +113,8 @@ overrides, seed, locale, name — and each flag overrides one of them:
 | `--skew N` | how unevenly child rows spread over their parents, `0.0`-`1.0`. Pro. |
 | `--name NAME` | the dbt project's name |
 | `--adapter duckdb\|postgres` | the warehouse the dbt project targets |
+| `--metrics FILE` / `--no-metrics` | the metrics file to send instead of the project's own, or none (the metrics are then the ones the model implies). A dbt export holds `<project>.metrics.yml`, `metric_values.json` and a test per metric under `data-tests/metrics/`. |
+| `--defects PRESET` | break the data on purpose: `clean`, `messy`, `training` or `none`; the archive then holds `defects_report.json` (and, for dbt, `EXPECTED_FAILURES.md`), and the log lists the tests `dbt build` should fail. Defaults to the project's. Pro, bar `training` on a bundled example. |
 | `--force` | replace files already in `--out` |
 | `--check` | compare against `--out` instead of writing to it |
 
@@ -132,10 +145,34 @@ committed fixtures, or that needs a failing build to be reproducible on a
 laptop next week, wants the day pinned one way or the other; with `--seed`, the
 two together name one dataset for good.
 
-**The project must have been opened in the studio at least once** since the
-studio started saving its parse. The API never parses DBML — the browser does,
-and posts the result — so a project with no stored parse has nothing to generate
-from, and the CLI says so rather than failing later.
+**A project written as a model is generated from the model.** A project whose
+text is a model2data model — a `.model2data.yml` document, spec 0.2.0, with a
+top-level `model2data:` version key — is sent to the studio as that text, and
+the studio reads it with the engine's own loader, exactly as `model2data --file`
+would. A model the studio refuses fails the run with every issue at its path in
+the document (`tables.orders.columns.status.generate.weights: ...`). The
+project's settings, and every flag above, still win over the model's own `run:`
+section.
+
+**A DBML project must have been opened in the studio at least once** since the
+studio started saving its parse. Nothing on the server reads DBML into what the
+editor showed — the browser does, and saves the result beside the project — so
+a DBML project with no stored parse has nothing to generate from, and the CLI
+says so rather than failing later.
+
+**`push` saves a model file as the project's text.** The studio checks the model
+first and nothing is saved if it has an error (warnings are printed and do not
+stop it). The project's name, settings and canvas positions are kept; the
+browser's saved parse of the old text is cleared, since the model is read
+as-is from then on. It needs a key with **Generate and save** access. It takes
+a model, not DBML: convert a DBML file with the engine's
+`model2data convert schema.dbml` first.
+
+**`push` saves the metrics file beside the model too.** `shop.metrics.yml` next
+to `shop.model2data.yml` is checked by the studio and saved as the project's
+metrics file, or the file `--metrics` names. Without either — or with
+`--no-metrics` — the project keeps the metrics file it already has. A metrics
+file with an error saves nothing.
 
 **`--check` never writes into `--out`.** It regenerates into a scratch
 directory and diffs it against what is already there, printing what changed,
@@ -144,6 +181,79 @@ job can fail a build whose committed fixtures nobody regenerated after a schema
 change, instead of shipping them stale. Exits 0 and prints `Up to date: N
 files` when they match.
 
+## Metrics
+
+A project's metrics file — `<stem>.metrics.yml` beside `<stem>.model2data.yml`,
+metrics spec 0.1.0 — says what its numbers mean: `revenue` is the sum of
+`orders.total_amount` where the order was paid, shipped or delivered. The studio
+saves one per project (the Metrics tab); in a repository it is the file next to
+the model. Without one, the metrics are the ones the model implies: a sum per
+`measure` column and a row count per fact.
+
+Every `metrics` command takes `--project`: a saved project's id **or** a local file (the id also still works as a plain argument, as it did before 0.2.1): the
+model (`shop.model2data.yml`, or `shop.dbml`), or its metrics file, in which case
+the model beside it is used. A local model's metrics are the `shop.metrics.yml`
+beside it, unless `--metrics FILE` or `--no-metrics` says otherwise. **A local
+file needs no API key**: checking metrics is free, and without a key `values`
+runs on the free plan.
+
+| | |
+| --- | --- |
+| `metrics list --project TARGET` | each metric's name, label, kind, what it computes, its filter and its date column; a metric the model implies rather than the file writes is marked `*` |
+| `metrics check --project TARGET` | every issue as `file:line: error: path: message`, the shape a CI log viewer links; exits 1 on an error, 0 on warnings alone |
+| `metrics values --project TARGET` | generates the data (the same run `generate` makes with the same arguments) and prints each metric's known value. `--seed`, `--rows` and `--as-of` as for `generate`; `--by-month` adds each month; `--json` prints the values shaped like the export's `metric_values.json` (its `run` and `metrics`; the spec version and rounding note are the export's own) |
+| `metrics suggest --project TARGET` | a metrics file of the metrics the model implies, to start one from: stdout, or `-o FILE` (`--force` to replace one) |
+
+```console
+$ model2data-studio metrics values examples/ecommerce.model2data.yml --seed 42 --as-of 2026-10-01
+ecommerce: seed 42, dates anchored on 2026-10-01, 100 rows a table
+metric               label                     value
+-------------------  ------------------------  -----------------------
+revenue              Revenue                   4,012.30
+orders               Orders                    100
+average_order_value  Average order value       40.12 (exact 40.123)
+cancelled_orders     Cancelled orders          4
+cancellation_rate    Cancellation rate         4.00%
+...
+```
+
+The values are **known answers**: what a correct query over the generated seeds
+returns. A rounded value is followed by its exact one, since that is what the
+query will return. Metric values are Pro, except on a bundled example; on a
+plan without them `values` says so and exits 1.
+
+## Dashboards
+
+A project's dashboards are files, `<name>.dashboard.yml`: the file name is the
+dashboard's name. They name the project's metrics and columns, never a value;
+the studio draws them from the project's generated data. The format is
+model2data's open [dashboard spec](https://github.com/JB-Analytica/model2data/blob/main/model2data/spec/dashboards/README.md) (0.1.0),
+with a JSON Schema at
+`https://www.jbanalytica.com/model2data/spec/dashboards/0.1.0/dashboard.schema.json`
+for editor completion: a file starts with
+
+```yaml
+# yaml-language-server: $schema=https://www.jbanalytica.com/model2data/spec/dashboards/0.1.0/dashboard.schema.json
+model2data-dashboard: 0.1.0
+model: coffee_webshop
+```
+
+This client does not read the files: it moves them to and from the studio, which
+checks them and says what is wrong, by line and column. `dashboard guide` and
+`dashboard check` without `--project` need no key. Since 0.3.0.
+
+| | |
+| --- | --- |
+| `dashboard list PROJECT_ID` | the project's dashboards |
+| `dashboard pull PROJECT_ID` | writes each one into `--out DIR` (the current folder by default); `--name NAME` for just that one. A file there that differs from the studio's is left alone, and nothing is written, unless `--force` |
+| `dashboard push PROJECT_ID FILE...` | creates or replaces each dashboard by file name. Every file is checked first and nothing is saved if one has an error. Needs a key with **Generate and save** access |
+| `dashboard check FILE... [--project ID]` | every error and warning as `file:line:column: error: message`; exits 1 on an error, 0 on warnings alone. With `--project`, names the project lacks are warnings |
+| `dashboard guide [--project ID]` | the guide to writing one, as markdown: the dashboard spec, then what the studio adds; with a project, it ends with the metrics and columns that project offers |
+
+A dashboard file that names something the project does not have is still saved:
+that is a warning, not an error, so a dashboard can be sketched before the
+metric it needs exists.
+
 ## Regenerating dbt seeds in CI
 
 ```yaml
@@ -241,15 +351,22 @@ and for anything that reads a JSON config (Claude Desktop, Cursor, Zed):
 
 `MODEL2DATA_STUDIO_URL` works here too, for a self-hosted studio.
 
-Five tools:
+Twelve tools:
 
 | | |
 | --- | --- |
 | `account` | the plan and its caps, worth reading before asking for a lot of rows |
 | `list_projects` | the ids to pass to everything else |
-| `describe_project` | one project's tables, columns, refs and enums as text, generation hints included |
+| `describe_project` | one project's tables, columns, refs and enums as text, generation hints included, and its metrics |
 | `preview_data` | generate and return the rows themselves, capped at fifty a table |
 | `write_data` | generate and write the files, as `generate --out` does |
+| `list_metrics` | the project's metrics, a line each: what it computes, its filter, its date column |
+| `metric_values` | each metric's known value over a generated run, overall and by month (`seed`, `rows`, `as_of` as for `preview_data`). Pro, bar a bundled example. |
+| `list_dashboards` | the project's dashboards, by name |
+| `get_dashboard` | one dashboard file's text, to edit and save back |
+| `get_dashboard_guide` | how to write a dashboard file: the open dashboard spec, then what the studio adds (no key needed); with `project_id`, ending with that project's metrics and columns |
+| `check_dashboard` | a dashboard file's errors and warnings, each with its line and column, without saving (no key needed without `project_id`) |
+| `save_dashboard` | checks a dashboard file, then creates or replaces it by name; a file with errors is not saved and the errors come back. Answers with the link to the project |
 
 `preview_data` is the one worth having. An agent that can *read* generated rows
 can act on them — write an assertion against them, notice that `shipped_at`
@@ -257,7 +374,13 @@ precedes `ordered_at`, spot a column coming out as placeholder sentences. It
 answers with the rows inline and says how many there really are; `write_data` is
 for when it has decided and wants the fixtures on disk.
 
-Both go through the same `export.resolve` the CLI's `generate` does, so an agent
+`metric_values` is its other half: the numbers a correct query over those rows
+returns, one quotable line per metric —
+`revenue (Revenue): 4,012.30 — sum of orders.total_amount where orders.status in
+paid, shipped, delivered; by month (orders.order_date): 2025-10 472.39, …` — so an
+agent writing SQL against the seeds can check its own answer.
+
+All of them go through the same `export.resolve` the CLI's `generate` does, so an agent
 and a pipeline asking for the same project with the same arguments get the same
 rows — including the part where an unpinned project has a seed picked for it and
 is told which one, so the answer can be reproduced afterwards.
@@ -288,7 +411,7 @@ workflow refuses a tag that disagrees with any of them), merge, then tag the
 merge commit on `main` and push the tag:
 
 ```bash
-git tag cli-v0.1.0 && git push origin cli-v0.1.0
+git tag cli-v0.3.0 && git push origin cli-v0.3.0
 ```
 
 `.github/workflows/release-cli.yml` runs the tests, builds, publishes to PyPI

{model2data_studio-0.1.0 → model2data_studio-0.3.0}/README.md

@@ -40,11 +40,11 @@ the account, so put it in your CI provider's secrets rather than in a file.
 
 Leave the key's access on **Generate and export**, which is the default and
 covers everything below: reading a project, generating, exporting. A key with
-**Read only** access is refused by `generate` with a 403 saying so. The two
-levels above it are for things the CLI does not do — **Generate and save** adds
-writing the project back, for a pipeline that pushes a schema up rather than
-pulling data down, and **Full access** adds deleting a project and managing its
-share links. A key that leaks out of a CI log can only do what it was given.
+**Read only** access is refused by `generate` with a 403 saying so. **Generate
+and save** adds writing the project back, which `push` and `dashboard push` need — for a
+pipeline that pushes a model up rather than pulling data down — and **Full access** adds
+deleting a project and managing its share links, which the CLI never does. A
+key that leaks out of a CI log can only do what it was given.
 
 ## Commands
 
@@ -54,6 +54,17 @@ model2data-studio whoami                # the plan behind the key, and what it h
 
 model2data-studio generate --project <id> --out seeds/
 model2data-studio generate --project <id> --out . --format dbt --adapter duckdb
+
+model2data-studio push --project <id> shop.model2data.yml   # save a model as the project's
+
+model2data-studio metrics list --project ID            # what each metric computes
+model2data-studio metrics check --project shop.metrics.yml  # exits 1 on an error, for CI
+model2data-studio metrics values --project ID --seed 42 --as-of 2026-10-01
+model2data-studio metrics suggest --project shop.model2data.yml -o shop.metrics.yml
+
+model2data-studio dashboard pull <id> --out dashboards/       # one <name>.dashboard.yml each
+model2data-studio dashboard push <id> dashboards/*.dashboard.yml
+model2data-studio dashboard check dashboards/*.dashboard.yml --project <id>   # for CI
 ```
 
 `generate` takes every setting from the saved project — row counts, per-table
@@ -73,6 +84,8 @@ overrides, seed, locale, name — and each flag overrides one of them:
 | `--skew N` | how unevenly child rows spread over their parents, `0.0`-`1.0`. Pro. |
 | `--name NAME` | the dbt project's name |
 | `--adapter duckdb\|postgres` | the warehouse the dbt project targets |
+| `--metrics FILE` / `--no-metrics` | the metrics file to send instead of the project's own, or none (the metrics are then the ones the model implies). A dbt export holds `<project>.metrics.yml`, `metric_values.json` and a test per metric under `data-tests/metrics/`. |
+| `--defects PRESET` | break the data on purpose: `clean`, `messy`, `training` or `none`; the archive then holds `defects_report.json` (and, for dbt, `EXPECTED_FAILURES.md`), and the log lists the tests `dbt build` should fail. Defaults to the project's. Pro, bar `training` on a bundled example. |
 | `--force` | replace files already in `--out` |
 | `--check` | compare against `--out` instead of writing to it |
 
@@ -103,10 +116,34 @@ committed fixtures, or that needs a failing build to be reproducible on a
 laptop next week, wants the day pinned one way or the other; with `--seed`, the
 two together name one dataset for good.
 
-**The project must have been opened in the studio at least once** since the
-studio started saving its parse. The API never parses DBML — the browser does,
-and posts the result — so a project with no stored parse has nothing to generate
-from, and the CLI says so rather than failing later.
+**A project written as a model is generated from the model.** A project whose
+text is a model2data model — a `.model2data.yml` document, spec 0.2.0, with a
+top-level `model2data:` version key — is sent to the studio as that text, and
+the studio reads it with the engine's own loader, exactly as `model2data --file`
+would. A model the studio refuses fails the run with every issue at its path in
+the document (`tables.orders.columns.status.generate.weights: ...`). The
+project's settings, and every flag above, still win over the model's own `run:`
+section.
+
+**A DBML project must have been opened in the studio at least once** since the
+studio started saving its parse. Nothing on the server reads DBML into what the
+editor showed — the browser does, and saves the result beside the project — so
+a DBML project with no stored parse has nothing to generate from, and the CLI
+says so rather than failing later.
+
+**`push` saves a model file as the project's text.** The studio checks the model
+first and nothing is saved if it has an error (warnings are printed and do not
+stop it). The project's name, settings and canvas positions are kept; the
+browser's saved parse of the old text is cleared, since the model is read
+as-is from then on. It needs a key with **Generate and save** access. It takes
+a model, not DBML: convert a DBML file with the engine's
+`model2data convert schema.dbml` first.
+
+**`push` saves the metrics file beside the model too.** `shop.metrics.yml` next
+to `shop.model2data.yml` is checked by the studio and saved as the project's
+metrics file, or the file `--metrics` names. Without either — or with
+`--no-metrics` — the project keeps the metrics file it already has. A metrics
+file with an error saves nothing.
 
 **`--check` never writes into `--out`.** It regenerates into a scratch
 directory and diffs it against what is already there, printing what changed,
@@ -115,6 +152,79 @@ job can fail a build whose committed fixtures nobody regenerated after a schema
 change, instead of shipping them stale. Exits 0 and prints `Up to date: N
 files` when they match.
 
+## Metrics
+
+A project's metrics file — `<stem>.metrics.yml` beside `<stem>.model2data.yml`,
+metrics spec 0.1.0 — says what its numbers mean: `revenue` is the sum of
+`orders.total_amount` where the order was paid, shipped or delivered. The studio
+saves one per project (the Metrics tab); in a repository it is the file next to
+the model. Without one, the metrics are the ones the model implies: a sum per
+`measure` column and a row count per fact.
+
+Every `metrics` command takes `--project`: a saved project's id **or** a local file (the id also still works as a plain argument, as it did before 0.2.1): the
+model (`shop.model2data.yml`, or `shop.dbml`), or its metrics file, in which case
+the model beside it is used. A local model's metrics are the `shop.metrics.yml`
+beside it, unless `--metrics FILE` or `--no-metrics` says otherwise. **A local
+file needs no API key**: checking metrics is free, and without a key `values`
+runs on the free plan.
+
+| | |
+| --- | --- |
+| `metrics list --project TARGET` | each metric's name, label, kind, what it computes, its filter and its date column; a metric the model implies rather than the file writes is marked `*` |
+| `metrics check --project TARGET` | every issue as `file:line: error: path: message`, the shape a CI log viewer links; exits 1 on an error, 0 on warnings alone |
+| `metrics values --project TARGET` | generates the data (the same run `generate` makes with the same arguments) and prints each metric's known value. `--seed`, `--rows` and `--as-of` as for `generate`; `--by-month` adds each month; `--json` prints the values shaped like the export's `metric_values.json` (its `run` and `metrics`; the spec version and rounding note are the export's own) |
+| `metrics suggest --project TARGET` | a metrics file of the metrics the model implies, to start one from: stdout, or `-o FILE` (`--force` to replace one) |
+
+```console
+$ model2data-studio metrics values examples/ecommerce.model2data.yml --seed 42 --as-of 2026-10-01
+ecommerce: seed 42, dates anchored on 2026-10-01, 100 rows a table
+metric               label                     value
+-------------------  ------------------------  -----------------------
+revenue              Revenue                   4,012.30
+orders               Orders                    100
+average_order_value  Average order value       40.12 (exact 40.123)
+cancelled_orders     Cancelled orders          4
+cancellation_rate    Cancellation rate         4.00%
+...
+```
+
+The values are **known answers**: what a correct query over the generated seeds
+returns. A rounded value is followed by its exact one, since that is what the
+query will return. Metric values are Pro, except on a bundled example; on a
+plan without them `values` says so and exits 1.
+
+## Dashboards
+
+A project's dashboards are files, `<name>.dashboard.yml`: the file name is the
+dashboard's name. They name the project's metrics and columns, never a value;
+the studio draws them from the project's generated data. The format is
+model2data's open [dashboard spec](https://github.com/JB-Analytica/model2data/blob/main/model2data/spec/dashboards/README.md) (0.1.0),
+with a JSON Schema at
+`https://www.jbanalytica.com/model2data/spec/dashboards/0.1.0/dashboard.schema.json`
+for editor completion: a file starts with
+
+```yaml
+# yaml-language-server: $schema=https://www.jbanalytica.com/model2data/spec/dashboards/0.1.0/dashboard.schema.json
+model2data-dashboard: 0.1.0
+model: coffee_webshop
+```
+
+This client does not read the files: it moves them to and from the studio, which
+checks them and says what is wrong, by line and column. `dashboard guide` and
+`dashboard check` without `--project` need no key. Since 0.3.0.
+
+| | |
+| --- | --- |
+| `dashboard list PROJECT_ID` | the project's dashboards |
+| `dashboard pull PROJECT_ID` | writes each one into `--out DIR` (the current folder by default); `--name NAME` for just that one. A file there that differs from the studio's is left alone, and nothing is written, unless `--force` |
+| `dashboard push PROJECT_ID FILE...` | creates or replaces each dashboard by file name. Every file is checked first and nothing is saved if one has an error. Needs a key with **Generate and save** access |
+| `dashboard check FILE... [--project ID]` | every error and warning as `file:line:column: error: message`; exits 1 on an error, 0 on warnings alone. With `--project`, names the project lacks are warnings |
+| `dashboard guide [--project ID]` | the guide to writing one, as markdown: the dashboard spec, then what the studio adds; with a project, it ends with the metrics and columns that project offers |
+
+A dashboard file that names something the project does not have is still saved:
+that is a warning, not an error, so a dashboard can be sketched before the
+metric it needs exists.
+
 ## Regenerating dbt seeds in CI
 
 ```yaml
@@ -212,15 +322,22 @@ and for anything that reads a JSON config (Claude Desktop, Cursor, Zed):
 
 `MODEL2DATA_STUDIO_URL` works here too, for a self-hosted studio.
 
-Five tools:
+Twelve tools:
 
 | | |
 | --- | --- |
 | `account` | the plan and its caps, worth reading before asking for a lot of rows |
 | `list_projects` | the ids to pass to everything else |
-| `describe_project` | one project's tables, columns, refs and enums as text, generation hints included |
+| `describe_project` | one project's tables, columns, refs and enums as text, generation hints included, and its metrics |
 | `preview_data` | generate and return the rows themselves, capped at fifty a table |
 | `write_data` | generate and write the files, as `generate --out` does |
+| `list_metrics` | the project's metrics, a line each: what it computes, its filter, its date column |
+| `metric_values` | each metric's known value over a generated run, overall and by month (`seed`, `rows`, `as_of` as for `preview_data`). Pro, bar a bundled example. |
+| `list_dashboards` | the project's dashboards, by name |
+| `get_dashboard` | one dashboard file's text, to edit and save back |
+| `get_dashboard_guide` | how to write a dashboard file: the open dashboard spec, then what the studio adds (no key needed); with `project_id`, ending with that project's metrics and columns |
+| `check_dashboard` | a dashboard file's errors and warnings, each with its line and column, without saving (no key needed without `project_id`) |
+| `save_dashboard` | checks a dashboard file, then creates or replaces it by name; a file with errors is not saved and the errors come back. Answers with the link to the project |
 
 `preview_data` is the one worth having. An agent that can *read* generated rows
 can act on them — write an assertion against them, notice that `shipped_at`
@@ -228,7 +345,13 @@ precedes `ordered_at`, spot a column coming out as placeholder sentences. It
 answers with the rows inline and says how many there really are; `write_data` is
 for when it has decided and wants the fixtures on disk.
 
-Both go through the same `export.resolve` the CLI's `generate` does, so an agent
+`metric_values` is its other half: the numbers a correct query over those rows
+returns, one quotable line per metric —
+`revenue (Revenue): 4,012.30 — sum of orders.total_amount where orders.status in
+paid, shipped, delivered; by month (orders.order_date): 2025-10 472.39, …` — so an
+agent writing SQL against the seeds can check its own answer.
+
+All of them go through the same `export.resolve` the CLI's `generate` does, so an agent
 and a pipeline asking for the same project with the same arguments get the same
 rows — including the part where an unpinned project has a seed picked for it and
 is told which one, so the answer can be reproduced afterwards.
@@ -259,7 +382,7 @@ workflow refuses a tag that disagrees with any of them), merge, then tag the
 merge commit on `main` and push the tag:
 
 ```bash
-git tag cli-v0.1.0 && git push origin cli-v0.1.0
+git tag cli-v0.3.0 && git push origin cli-v0.3.0
 ```
 
 `.github/workflows/release-cli.yml` runs the tests, builds, publishes to PyPI

{model2data_studio-0.1.0 → model2data_studio-0.3.0}/model2data_studio/__init__.py

@@ -12,6 +12,6 @@ the studio's API does all of that, and this only knows how to ask.
 
 from __future__ import annotations
 
-__version__ = "0.1.0"
+__version__ = "0.3.0"
 
 __all__ = ["__version__"]