cassis-cli 2.2.0__tar.gz → 2.3.0__tar.gz

{cassis_cli-2.2.0 → cassis_cli-2.3.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: cassis-cli
-Version: 2.2.0
+Version: 2.3.0
 Summary: Validate, test and evaluate your Cassis ontology from your terminal, then publish it
 License: Apache-2.0
 License-File: LICENSE
@@ -38,7 +38,7 @@ Validate, test and evaluate your ontology from your terminal, then publish it. T
 - `cassis schema plan <ddl>` (or `--warehouse` on a project connected to a warehouse) previews what a schema update would change before anything is applied: the source schema diff, the ontology changes Cassis will make (every change on a table placed in the ontology, with everything a drop takes with it) and warnings, terraform-style. `cassis schema apply <ddl>` (or `--plan <id>`) writes the resulting ontology files into the local checkout, app untouched, for review with `git diff`. `cassis schema push <ddl> [--publish]` pushes the new schema and the local ontology to the app (`--yes` in CI). The file speaks only for the schemas it contains — pass `--complete` when it is the project's complete source schema so schemas absent from it are treated as dropped. With `--warehouse` the server introspects the connected warehouse instead of parsing a file; the plan is always whole-source. `cassis schema plan <ddl> --dry-run` is the prepare-ahead variant: the plan is computed synchronously and nothing is kept in Cassis (no plan to apply or resume, the current plan untouched), so a dbt model or migration still in a PR can be planned against safely; `--write-checkout` writes the ontology files it would produce into the checkout, to commit alongside the schema change.
 - `cassis projects list` lists the projects your API key can reach — id (what `--project` and `CASSIS_PROJECT_ID` take), name, published ontology version, and data-source dialect — so a pipeline or agent can discover the project id from the terminal instead of fishing it out of a webapp URL.
 - `cassis status` shows the project's published version (number, label, git commit), whether unpublished changes await publication, the git-sync binding, a schema plan waiting to be applied, and how your local git HEAD relates to the published commit (in sync / N commits ahead / diverged). `cassis status --watch` polls until the published commit matches your local HEAD — e.g. right after merging a PR whose CI publishes the ontology — instead of watching the GitHub Actions tab.
-- `cassis issues` triages the issues Cassis raised on the project — what it found wrong while answering questions (an ontology gap, missing data) — without leaving the checkout: `issues list` (filterable by status, impact, cause and ontology domain, and showing each issue's domain so you can work through one domain at a time), `issues show <id>` for the diagnosis, suggested action and the occurrences behind it, `issues evidence <id> <occurrence-id>` for what the agent actually saw, and `issues resolve` / `dismiss` / `reopen` once you've acted on it.
+- `cassis issues` triages the issues Cassis raised on the project — what it found wrong while answering questions (an ontology gap, missing data) — without leaving the checkout: `issues list` (filterable by status, impact, cause and ontology domain, and showing each issue's domain so you can work through one domain at a time), `issues show <id>` for the diagnosis, suggested action and the occurrences behind it, `issues evidence <id> <occurrence-id>` for what the agent actually saw, and `issues resolve` / `dismiss` / `reopen` once you've acted on it. When the fix ships through a pull request, write the `PR mention:` line `issues show` prints (`Resolves <id>`) in the PR description instead: Cassis resolves the issue when the PR merges, and `issues show` then reports how it was closed and through which PR.
 - `cassis verify` runs the full local gate in one verb — `ontology fmt --check`, `ontology check`, `eval run` — stopping at the first failure. One command in a checkout ("is this change safe to merge?"), one job in CI. `--no-eval` skips the eval suite.
 
 ## Install
@@ -160,7 +160,8 @@ cassis issues list --domain sales
 # Read what the agent saw for one occurrence (ids from `issues show`):
 cassis issues evidence 019f0000-0000-7000-8000-0000000000e1 019f0000-0000-7000-8000-0000000000c1
 
-# Close the loop once the fix is published (or reopen):
+# Close the loop once the fix is published (or reopen). When the fix ships in a pull
+# request, put `Resolves <id>` in its description instead and the merge closes the issue:
 cassis issues resolve 019f0000-0000-7000-8000-0000000000e1
 cassis issues dismiss 019f0000-0000-7000-8000-0000000000e1
 cassis issues reopen 019f0000-0000-7000-8000-0000000000e1

{cassis_cli-2.2.0 → cassis_cli-2.3.0}/README.md

@@ -16,7 +16,7 @@ Validate, test and evaluate your ontology from your terminal, then publish it. T
 - `cassis schema plan <ddl>` (or `--warehouse` on a project connected to a warehouse) previews what a schema update would change before anything is applied: the source schema diff, the ontology changes Cassis will make (every change on a table placed in the ontology, with everything a drop takes with it) and warnings, terraform-style. `cassis schema apply <ddl>` (or `--plan <id>`) writes the resulting ontology files into the local checkout, app untouched, for review with `git diff`. `cassis schema push <ddl> [--publish]` pushes the new schema and the local ontology to the app (`--yes` in CI). The file speaks only for the schemas it contains — pass `--complete` when it is the project's complete source schema so schemas absent from it are treated as dropped. With `--warehouse` the server introspects the connected warehouse instead of parsing a file; the plan is always whole-source. `cassis schema plan <ddl> --dry-run` is the prepare-ahead variant: the plan is computed synchronously and nothing is kept in Cassis (no plan to apply or resume, the current plan untouched), so a dbt model or migration still in a PR can be planned against safely; `--write-checkout` writes the ontology files it would produce into the checkout, to commit alongside the schema change.
 - `cassis projects list` lists the projects your API key can reach — id (what `--project` and `CASSIS_PROJECT_ID` take), name, published ontology version, and data-source dialect — so a pipeline or agent can discover the project id from the terminal instead of fishing it out of a webapp URL.
 - `cassis status` shows the project's published version (number, label, git commit), whether unpublished changes await publication, the git-sync binding, a schema plan waiting to be applied, and how your local git HEAD relates to the published commit (in sync / N commits ahead / diverged). `cassis status --watch` polls until the published commit matches your local HEAD — e.g. right after merging a PR whose CI publishes the ontology — instead of watching the GitHub Actions tab.
-- `cassis issues` triages the issues Cassis raised on the project — what it found wrong while answering questions (an ontology gap, missing data) — without leaving the checkout: `issues list` (filterable by status, impact, cause and ontology domain, and showing each issue's domain so you can work through one domain at a time), `issues show <id>` for the diagnosis, suggested action and the occurrences behind it, `issues evidence <id> <occurrence-id>` for what the agent actually saw, and `issues resolve` / `dismiss` / `reopen` once you've acted on it.
+- `cassis issues` triages the issues Cassis raised on the project — what it found wrong while answering questions (an ontology gap, missing data) — without leaving the checkout: `issues list` (filterable by status, impact, cause and ontology domain, and showing each issue's domain so you can work through one domain at a time), `issues show <id>` for the diagnosis, suggested action and the occurrences behind it, `issues evidence <id> <occurrence-id>` for what the agent actually saw, and `issues resolve` / `dismiss` / `reopen` once you've acted on it. When the fix ships through a pull request, write the `PR mention:` line `issues show` prints (`Resolves <id>`) in the PR description instead: Cassis resolves the issue when the PR merges, and `issues show` then reports how it was closed and through which PR.
 - `cassis verify` runs the full local gate in one verb — `ontology fmt --check`, `ontology check`, `eval run` — stopping at the first failure. One command in a checkout ("is this change safe to merge?"), one job in CI. `--no-eval` skips the eval suite.
 
 ## Install
@@ -138,7 +138,8 @@ cassis issues list --domain sales
 # Read what the agent saw for one occurrence (ids from `issues show`):
 cassis issues evidence 019f0000-0000-7000-8000-0000000000e1 019f0000-0000-7000-8000-0000000000c1
 
-# Close the loop once the fix is published (or reopen):
+# Close the loop once the fix is published (or reopen). When the fix ships in a pull
+# request, put `Resolves <id>` in its description instead and the merge closes the issue:
 cassis issues resolve 019f0000-0000-7000-8000-0000000000e1
 cassis issues dismiss 019f0000-0000-7000-8000-0000000000e1
 cassis issues reopen 019f0000-0000-7000-8000-0000000000e1

{cassis_cli-2.2.0 → cassis_cli-2.3.0}/cassis_cli/issues.py

@@ -186,8 +186,10 @@ def show(
     """Show one issue: its diagnosis, suggested action, and occurrences.
 
     Each occurrence's id feeds `cassis issues evidence`, which prints what the
-    agent saw. Exits 0 on success, 1 when the issue does not exist in the
-    project, 2 on usage errors, 3 on transport/API errors.
+    agent saw. The `PR mention` line is what to write in the description of
+    the pull request that fixes the issue (`Resolves <id>`): Cassis resolves
+    it when that PR merges. Exits 0 on success, 1 when the issue does not
+    exist in the project, 2 on usage errors, 3 on transport/API errors.
     """
     api_key = require_api_key(api_key)
     project_id = resolve_project_id(project_id, path / Path(base_path), quiet=json_output)
@@ -210,10 +212,16 @@ def show(
         f"{issue.get('occurrence_count_cache', len(occurrences))} occurrence(s)"
     )
     _field("Domains", ", ".join(issue.get("domains") or []) or None)
+    if issue.get("resolved_via"):
+        ref = issue.get("resolved_ref")
+        _field("Resolved via", f"{issue['resolved_via']}{f' ({ref})' if ref else ''}")
     _field("Description", issue.get("description"), blank_line=True)
     _field("Suggested action", issue.get("suggested_action"), blank_line=True)
     typer.echo("")
     typer.echo("Fix proposal: available (review it in Cassis)" if issue.get("fix_proposal") else "Fix proposal: none")
+    if issue.get("status") == "open":
+        # What to put in the PR that fixes it: Cassis resolves the issue when that PR merges.
+        typer.echo(f"PR mention: Resolves {issue.get('id')}")
     if occurrences:
         typer.echo("")
         typer.echo("Occurrences:")
@@ -308,8 +316,11 @@ def resolve(
 ) -> None:
     """Mark an issue resolved — the ontology change that fixes it is published.
 
-    Exits 0 on success, 1 when the issue does not exist in the project, 2 on
-    usage errors, 3 on transport/API errors.
+    For a fix that ships through a pull request, prefer writing `Resolves <id>`
+    in the PR description: Cassis resolves the issue itself when the PR
+    merges, and records the PR on it. Use this command for outcomes that never
+    go through a PR. Exits 0 on success, 1 when the issue does not exist in
+    the project, 2 on usage errors, 3 on transport/API errors.
     """
     _set_status(
         issue_id=issue_id,

{cassis_cli-2.2.0 → cassis_cli-2.3.0}/pyproject.toml

@@ -1,6 +1,6 @@
 [project]
 name = "cassis-cli"
-version = "2.2.0"
+version = "2.3.0"
 description = "Validate, test and evaluate your Cassis ontology from your terminal, then publish it"
 readme = "README.md"
 license = { text = "Apache-2.0" }