mammoth-cli 2.0.31__tar.gz → 2.0.32__tar.gz

{mammoth_cli-2.0.31 → mammoth_cli-2.0.32}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: mammoth-cli
-Version: 2.0.31
+Version: 2.0.32
 Summary: Command-line interface for the Mammoth Analytics platform
 Project-URL: homepage, https://mammoth.io
 Project-URL: repository, https://github.com/EdgeMetric/mammothsdk
@@ -17,7 +17,7 @@ Classifier: Topic :: Software Development :: Libraries :: Python Modules
 Requires-Python: <3.15,>=3.12
 Requires-Dist: jsonschema>=4.20
 Requires-Dist: keyring<26,>=25.7
-Requires-Dist: mammoth-io<0.8,>=0.7.13
+Requires-Dist: mammoth-io<0.8,>=0.7.14
 Requires-Dist: platformdirs<5,>=4.10
 Requires-Dist: pydantic<3,>=2.13
 Requires-Dist: pyyaml<7,>=6
@@ -30,7 +30,7 @@ Description-Content-Type: text/markdown
 
 Use [Mammoth Analytics](https://mammoth.io) from a terminal. The `mammoth`
 command covers data import and export, transformations, project organization,
-automation, and administration. Its interface is designed to be readable at a
+automation, and administration. Its interface is readable at a
 shell and predictable in scripts and agent runs.
 
 [![PyPI](https://img.shields.io/pypi/v/mammoth-cli)](https://pypi.org/project/mammoth-cli/)
@@ -38,14 +38,14 @@ shell and predictable in scripts and agent runs.
 [![License](https://img.shields.io/pypi/l/mammoth-cli)](https://github.com/EdgeMetric/mammothsdk/blob/main/mammoth-cli/LICENSE)
 
 - **Human-friendly by default.** In a terminal, commands print a readable table.
-- **Agent-native.** When output is piped, you get a stable JSON envelope with a
+- **Agent-native.** When you pipe the output, you get a stable JSON envelope with a
   documented schema, exit codes, and error codes — no flags required.
 - **Guarded mutations.** Commands expose their confirmation policy; promptless
   destructive operations require an explicit `--yes`.
 - **Discoverable.** `mammoth capability list` and `mammoth schema get` describe
   every command, so an agent can learn the surface at runtime.
 
-The CLI is built on the public [`mammoth-io`](https://pypi.org/project/mammoth-io/)
+The CLI uses the public [`mammoth-io`](https://pypi.org/project/mammoth-io/)
 SDK. It adds no second HTTP client and calls no private SDK members.
 
 See the [capability matrix](https://github.com/EdgeMetric/mammothsdk/blob/main/mammoth-cli/docs/release-capability-matrix.md)
@@ -103,8 +103,7 @@ history, or command arguments. On POSIX, put the required JSON credentials in a
 private owner-only (0600) file outside the repository and pass its path to:
 
 ```bash
-mammoth auth login --input /private/path/credentials.json --storage file \
- 
+mammoth auth login --input /private/path/credentials.json --storage file
 ```
 
 On Windows, use the approved OS keyring instead; do not use a file fallback
@@ -136,8 +135,7 @@ To pin it for a whole session, `export MAMMOTH_OUTPUT=json MAMMOTH_NO_INPUT=1`
 the private, permission-checked file described above:
 
 ```bash
-mammoth auth login --input /private/path/credentials.json --storage file \
- 
+mammoth auth login --input /private/path/credentials.json --storage file
 ```
 
 Feed multi-field requests as one document instead of many flags:
@@ -210,9 +208,10 @@ Use Mammoth Analytics only through the `mammoth` CLI in bash; run
 1. If `mammoth --version` fails, install, then re-check (new shell if needed):
    curl -fsSL https://raw.githubusercontent.com/EdgeMetric/mammothsdk/main/mammoth-cli/installers/mammoth-install.sh | bash
 2. Run `mammoth auth status`. If it shows no credentials, print exactly this
-   and wait until I say done: "In the Mammoth web app open account settings,
-   create an API key (key + secret) and note your workspace id, then run in
-   your own terminal: mammoth auth login" — never ask for, read, or pass a key
+   and wait until I say done: "In the Mammoth web app open Workspace settings
+   → API Tokens → Create token, copy the key and the secret (shown once), and
+   note the workspace id (the number after /workspaces/ in the address bar),
+   then run in your own terminal: mammoth auth login" — never ask for, read, or pass a key
    or secret yourself, and never run auth login.
 3. Require `mammoth doctor` to pass, then run `mammoth skill show` and
    follow the guide it prints.

{mammoth_cli-2.0.31 → mammoth_cli-2.0.32}/README.md

@@ -2,7 +2,7 @@
 
 Use [Mammoth Analytics](https://mammoth.io) from a terminal. The `mammoth`
 command covers data import and export, transformations, project organization,
-automation, and administration. Its interface is designed to be readable at a
+automation, and administration. Its interface is readable at a
 shell and predictable in scripts and agent runs.
 
 [![PyPI](https://img.shields.io/pypi/v/mammoth-cli)](https://pypi.org/project/mammoth-cli/)
@@ -10,14 +10,14 @@ shell and predictable in scripts and agent runs.
 [![License](https://img.shields.io/pypi/l/mammoth-cli)](https://github.com/EdgeMetric/mammothsdk/blob/main/mammoth-cli/LICENSE)
 
 - **Human-friendly by default.** In a terminal, commands print a readable table.
-- **Agent-native.** When output is piped, you get a stable JSON envelope with a
+- **Agent-native.** When you pipe the output, you get a stable JSON envelope with a
   documented schema, exit codes, and error codes — no flags required.
 - **Guarded mutations.** Commands expose their confirmation policy; promptless
   destructive operations require an explicit `--yes`.
 - **Discoverable.** `mammoth capability list` and `mammoth schema get` describe
   every command, so an agent can learn the surface at runtime.
 
-The CLI is built on the public [`mammoth-io`](https://pypi.org/project/mammoth-io/)
+The CLI uses the public [`mammoth-io`](https://pypi.org/project/mammoth-io/)
 SDK. It adds no second HTTP client and calls no private SDK members.
 
 See the [capability matrix](https://github.com/EdgeMetric/mammothsdk/blob/main/mammoth-cli/docs/release-capability-matrix.md)
@@ -75,8 +75,7 @@ history, or command arguments. On POSIX, put the required JSON credentials in a
 private owner-only (0600) file outside the repository and pass its path to:
 
 ```bash
-mammoth auth login --input /private/path/credentials.json --storage file \
- 
+mammoth auth login --input /private/path/credentials.json --storage file
 ```
 
 On Windows, use the approved OS keyring instead; do not use a file fallback
@@ -108,8 +107,7 @@ To pin it for a whole session, `export MAMMOTH_OUTPUT=json MAMMOTH_NO_INPUT=1`
 the private, permission-checked file described above:
 
 ```bash
-mammoth auth login --input /private/path/credentials.json --storage file \
- 
+mammoth auth login --input /private/path/credentials.json --storage file
 ```
 
 Feed multi-field requests as one document instead of many flags:
@@ -182,9 +180,10 @@ Use Mammoth Analytics only through the `mammoth` CLI in bash; run
 1. If `mammoth --version` fails, install, then re-check (new shell if needed):
    curl -fsSL https://raw.githubusercontent.com/EdgeMetric/mammothsdk/main/mammoth-cli/installers/mammoth-install.sh | bash
 2. Run `mammoth auth status`. If it shows no credentials, print exactly this
-   and wait until I say done: "In the Mammoth web app open account settings,
-   create an API key (key + secret) and note your workspace id, then run in
-   your own terminal: mammoth auth login" — never ask for, read, or pass a key
+   and wait until I say done: "In the Mammoth web app open Workspace settings
+   → API Tokens → Create token, copy the key and the secret (shown once), and
+   note the workspace id (the number after /workspaces/ in the address bar),
+   then run in your own terminal: mammoth auth login" — never ask for, read, or pass a key
    or secret yourself, and never run auth login.
 3. Require `mammoth doctor` to pass, then run `mammoth skill show` and
    follow the guide it prints.

{mammoth_cli-2.0.31 → mammoth_cli-2.0.32}/mammoth_cli/__init__.py

@@ -6,7 +6,7 @@ not implement a second HTTP client and does not call private SDK members.
 
 from __future__ import annotations
 
-__version__ = "2.0.31"
+__version__ = "2.0.32"
 
 # The versioned machine output envelope contract.
 SCHEMA_VERSION = 1

{mammoth_cli-2.0.31 → mammoth_cli-2.0.32}/mammoth_cli/bundled_skill/mammoth-cli/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: mammoth-cli
-version: 2.0.31
+version: 2.0.32
 description: "Use Mammoth Analytics from a terminal: install or authenticate the CLI, discover its live command contract, and safely manage projects, data, views, pipelines, dashboards, exports, and handoffs."
 ---
 
@@ -8,7 +8,7 @@ description: "Use Mammoth Analytics from a terminal: install or authenticate the
 
 Use this skill for Mammoth shell work, not for Python SDK integration. The
 CLI is the contract: it validates every request locally, returns one JSON
-envelope, and never needs a flag to do so when its output is piped.
+envelope, and needs no flag for that when you pipe its output.
 
 ## Start
 
@@ -21,8 +21,9 @@ mammoth project ensure 'PROJECT NAME'   # get-or-create; becomes the active proj
 command anyway. Production is the `app` endpoint; use `release` only when the
 task names it, and check `meta.profile`/`auth status` `endpoint` match the
 intended environment before doing anything. If no profile has credentials,
-tell the operator the exact `mammoth auth login --profile PROFILE` command to
-run in their own terminal and wait; never ask for a key or secret in chat,
+tell the operator to run `mammoth auth login` in their own terminal (add
+`--profile NAME` only for a profile other than `default`; [auth](references/auth.md)
+says where the key and secret come from) and wait; never ask for a key or secret in chat,
 never read one from a file or environment variable, never run `auth login`
 yourself. If any envelope carries `meta.update_available`, run its `command`
 before the next step.
@@ -62,7 +63,8 @@ before the next step.
   returns, never backend aliases.
 - `--dry-run` on any API-backed command resolves everything and reports the
   request instead of sending it; use it before a write you are not sure of.
-- Destructive commands need `--yes --confirm ID`. Preserve requested
+- Deletes need `--yes`; high-impact ones (`project delete`, access changes)
+  also need `--confirm ID`, and `schema get` shows which. Preserve requested
   deliverables; cleanup is exact-ID authorized and
   never means delete-all-owned-resources: delete only ids this run created,
   one per call, and read back that they are gone.

{mammoth_cli-2.0.31 → mammoth_cli-2.0.32}/mammoth_cli/bundled_skill/mammoth-cli/references/auth.md

@@ -17,8 +17,12 @@ An agent never receives the key or secret. When `auth status` reports a
 missing profile or `has_credentials=false`, stop and hand the login to the
 human operator:
 
-1. Tell the operator the exact command to run in **their own** terminal. For
-   production it is just:
+1. Tell the operator where the credentials come from: in the Mammoth web app,
+   **Workspace settings → API Tokens → Create token** gives a key and a secret;
+   the web app shows the secret only once (on an existing token, **Generate new
+   secret** replaces it). The workspace id is the number after `/workspaces/`
+   in the web app's address bar. Then give the exact command to run in
+   **their own** terminal. For production it is:
 
    ```bash
    mammoth auth login
@@ -30,6 +34,10 @@ human operator:
    hidden input, then the workspace id, so no secret enters chat, argv, or
    history. Credentials are per environment: a release key never
    authenticates on `app`.
+   On macOS the Keychain may show a dialog about `mammoth-cli`; tell the
+   operator to choose **Always Allow**. If the keychain cannot be used (for
+   example over SSH), login falls back to the owner-only file, or the operator
+   runs `mammoth auth login --storage file`.
 2. Wait for the operator to confirm, then re-run
    `mammoth auth status --profile PROFILE` and
    `mammoth doctor --profile PROFILE`.

{mammoth_cli-2.0.31 → mammoth_cli-2.0.32}/mammoth_cli/bundled_skill/mammoth-cli/references/capabilities-misc.md

@@ -33,7 +33,7 @@ Ran once: `automation.create`, `automation.delete`, `automation.list`
 
 | Command | State | Note |
 |---|---|---|
-| `automation.get` | observed blocker | backend_error: SUSPECTED DEFECT: automation.get on the id just returned by automation.create (id=1) returns HTTP 500 empty body every time (3 retries, several seconds apart), not e |
+| `automation.get` | observed blocker | backend_error: SUSPECTED DEFECT: automation.get on the id that automation.create returned (id=1) returns HTTP 500 empty body every time (3 retries, several seconds apart), not even |
 | `automation.update` | observed blocker | cli_error: CLI rejected 'name' field; error message says accepted field is 'patch' (nested patch object), not documented in agent_example |
 
 ## `batch`

{mammoth_cli-2.0.31 → mammoth_cli-2.0.32}/mammoth_cli/bundled_skill/mammoth-cli/references/commands/automation.md

@@ -30,7 +30,7 @@ Example: `mammoth automation get 123`. Placeholders are illustrative; resolve ID
 
 Result: `AutomationGetResult`; mutation `read`, confirmation `none`, wait policy `not_async`.
 
-Status on release: observed blocker — backend_error: SUSPECTED DEFECT: automation.get on the id just returned by automation.create (id=1) returns HTTP 500 empty body every time (3 retries, several seconds apart), not e. Re-check before relying on it.
+Status on release: observed blocker — backend_error: SUSPECTED DEFECT: automation.get on the id that automation.create returned (id=1) returns HTTP 500 empty body every time (3 retries, several seconds apart), not even. Re-check before relying on it.
 
 ### `automation.list`
 

{mammoth_cli-2.0.31 → mammoth_cli-2.0.32}/mammoth_cli/bundled_skill/mammoth-cli/references/handoff.md

@@ -11,15 +11,18 @@ operator logs in from their own terminal as described in [auth](auth.md).
 
 ## Required record
 
-Include `format: "mammoth-agent-handoff"`, `format_version`, producer
-`cli_version`, `sdk_version`, `contract_schema_version`, and `skill_version`
-(the `version:` field in this skill's `SKILL.md` frontmatter; `mammoth
---version` gives the other two);
-the intent and acceptance criteria; authorized `profile` name and exact
-workspace/project scope; observed resources with dataset/view parents and
-dependencies; last verified state and hashes of bounded secret-free evidence;
-pending known jobs and `unknown_outcomes`; completed actions; remaining
-objectives; and a cleanup owner plus dependency order.
+Include `format: "mammoth-agent-handoff"`, `format_version`, and the producer
+versions: `cli_version`, `sdk_version`, `contract_schema_version`, and
+`skill_version`. `skill_version` is the `version:` field in this skill's
+`SKILL.md` frontmatter; `mammoth --version` gives the other two. Also include
+the intent and acceptance criteria and the authorized `profile` name and exact
+workspace/project scope. Then add:
+
+- observed resources with dataset/view parents and dependencies;
+- the last verified state and hashes of bounded secret-free evidence;
+- pending known jobs and `unknown_outcomes`;
+- completed actions and remaining objectives;
+- a cleanup owner plus dependency order.
 
 Never include API keys, API secrets, tokens, headers, credentials files, raw
 secret-bearing input, or unredacted response bodies. IDs and display names are

{mammoth_cli-2.0.31 → mammoth_cli-2.0.32}/mammoth_cli/bundled_skill/mammoth-cli/references/jobs-drafts.md

@@ -5,7 +5,11 @@ A command's `wait_policy` (visible via `mammoth schema get`) determines what
 happens with the job, so you do not have to guess:
 
 - `always_wait` and `start_or_wait` commands resolve the job for you and return
-  the final result. You do NOT wait manually.
+  the final result. You do NOT wait manually. A `view transform` success
+  envelope says `"status": "done"` and `"pipeline_state": "ready"`: the
+  pipeline has finished, so do not poll its `future_id`; verify the values
+  with `view data get`. (With SDK ≤ 0.7.13 the same envelope said
+  `"processing"`; it meant the same thing.)
 - Only a `returns_job` command normally needs you to wait on the job id
   explicitly:
   ```bash

{mammoth_cli-2.0.31 → mammoth_cli-2.0.32}/mammoth_cli/bundled_skill/mammoth-cli/references/operations.md

@@ -1,12 +1,16 @@
 # Typed operations and verification
 
 The installed CLI manifest is the source of truth for local CLI routes. Use
-`schema list/find TEXT` to discover those routes; `capability list` is a
+`schema list/find TEXT` to discover those routes. `capability list` is a
 separate API-binding inventory and can omit typed/local commands such as view
-transforms. `schema get COMMAND_ID` returns the command path, typed positionals/options,
-request/result models, accepted input shape, effect/confirmation policy,
-wait policy, known restrictions, and recovery/verification metadata. Read the
-schema immediately before composing a request because support and fields can
+transforms. `schema get COMMAND_ID` returns the full contract of one command:
+
+- command path and typed positionals/options;
+- request/result models and the accepted input shape;
+- effect/confirmation policy and wait policy;
+- known restrictions and recovery/verification metadata.
+
+Read the schema immediately before composing a request. Support and fields can
 vary by release, profile, or backend.
 
 ## Which id is which
@@ -24,8 +28,8 @@ vary by release, profile, or backend.
 
 `schema find`/`schema get`/`schema list` read the installed manifest. They
 need no project and no stored credentials. `dataset list`, `folder list`, and
-`view list` call the live API and are scoped to one project through
-`--project`. `dataset find NAME` and `folder find NAME` search every project
+`view list` call the live API, and `--project` scopes them to one
+project. `dataset find NAME` and `folder find NAME` search every project
 the credential can see (or one, with `--project`); they still need
 credentials because they call the live API.
 
@@ -56,50 +60,50 @@ typed routes for combining views. Appending rows is a dataset-level
 operation: upload into the existing dataset with `file upload --input
 '{"append_to_ds_id": DATASET_ID}'`, not a view transform.
 
-Use the exact returned command ID, then read its schema and the current view
+Use the command ID exactly as the search returns it. Read its schema and the current view
 schema before composing input. Join only on keys confirmed in both exact view
-schemas. Create derived measures through the typed math route after numeric
-conversion and verify them from a `view data get` readback. Deduplication is a
-semantic operation: define the key/retention rule explicitly; never treat a
-successful task submission as proof that duplicates were removed.
+schemas. After numeric conversion, create derived measures through the typed
+math route. Verify them from a `view data get` readback. Deduplication is a
+semantic operation: define the key/retention rule explicitly. A successful
+task submission does not prove that the task removed duplicates.
 
 For deduplication, discover and use `view.transform.discard-duplicates`; see
 recipes/transforms.md for the full procedure.
 
 Prefer a typed `view transform <operation>` command. Its schema is the
 discoverable request contract. A job status or pipeline/task definition only
-proves the task ran; for any value-changing step the proof is `view data get`
-rows — see SKILL.md working rules and
-[report-checklist](report-checklist.md). Every transform and draft mutation
-carries the exact parent `dataset_id` in `--input`; it never falls back to
-project-wide discovery:
+proves that the task ran. For a value-changing step, the proof is the
+`view data get` rows; see SKILL.md and [report-checklist](report-checklist.md).
+A transform needs the view's parent dataset. The CLI remembers it from any
+earlier read of the view (`view list DATASET_ID`, `view get VIEW_ID`); pass
+`dataset_id` in `--input` only when the command asks for it. It never falls
+back to project-wide discovery:
 
 ```bash
 mammoth view transform math VIEW_ID --project PROJECT_ID \
-  --input '{"dataset_id":DATASET_ID,"expression":"Unit Price * Quantity","new_column":"Revenue"}' \
- 
+  --input '{"expression":"Unit Price * Quantity","new_column":"Revenue"}'
 mammoth view pipeline get VIEW_ID --project PROJECT_ID
 ```
 
 The low-level `view task add|preview|update` routes expose an opaque
 `task_spec` object in the current schema, not a discoverable task union. Prefer
-typed transform routes. Use a low-level task route only when an independently
-documented task specification is supplied for the target backend; never infer
-SDK/backend keys from `schema get` or an illustrative example. Read the
+typed transform routes. Use a low-level task route only with an independently
+documented task specification for the target backend. Never infer SDK/backend
+keys from `schema get` or an illustrative example. Read the
 task/list or pipeline/items result back after a successful write. Without that
 independent specification, report the route as unsupported/ambiguous and stop
 safely.
 
 Typed transforms and `view task add` append at the end of the pipeline and
-never reorder or delete an existing step. On a pipeline other people or
-agents also edit, make that checkable: read `view task list VIEW_ID`, plan,
-then write with `"expected_task_count": N` in the input; the CLI re-reads
-the list just before the write and refuses with `pipeline_changed` when the
-count moved ([safety](safety.md)). `--dry-run` on the same command shows the
+never reorder or delete an existing step. Other people or agents may also
+edit the pipeline. To guard against that, read `view task list VIEW_ID`,
+plan, then write with `"expected_task_count": N` in the input. The CLI
+re-reads the list just before the write. It refuses with `pipeline_changed`
+when the count moved ([safety](safety.md)). `--dry-run` on the same command shows the
 resolved call first.
 
-For a new workflow (a container for automation), discover and then read it
-back; workflow creation is not the same as adding a view pipeline task:
+A workflow is a container for automation. Creating one is not the same as
+adding a view pipeline task. Discover its schema, create it, and read it back:
 
 ```bash
 mammoth schema get workflow.create
@@ -125,8 +129,8 @@ before extracting a field.
 First inspect `view.export.list/get` for existing configuration and the exact
 export command schema. Local CSV and dataset exports have different result
 shapes from external-effect connectors. External destinations (database,
-cloud storage, email, and similar) require `--yes`, commonly return a job, and
-must be verified with `job get/wait` and then `view export get/list` or a
+cloud storage, email, and similar) require `--yes` and commonly return a job.
+Verify them with `job get/wait`, then with `view export get/list` or a
 destination-side artifact when the schema requires it.
 
 ```bash
@@ -136,9 +140,9 @@ mammoth view export csv VIEW_ID --project PROJECT_ID
 mammoth view export list VIEW_ID DATASET_ID --project PROJECT_ID
 ```
 
-Use `--input` for connector configuration. Keep fields listed as secret by the
-schema out of argv, logs, checkpoints, and handoffs; do not claim an export
-completed from a submitted job alone. Reconcile a timed-out or uncertain
+Use `--input` for connector configuration. Keep the schema's secret fields out
+of argv, logs, checkpoints, and handoffs. A submitted job alone does not prove
+that an export completed. Reconcile a timed-out or uncertain
 export before submitting another one.
 
 ## Capability boundaries

{mammoth_cli-2.0.31 → mammoth_cli-2.0.32}/mammoth_cli/bundled_skill/mammoth-cli/references/recipes/cleanup.md

@@ -3,8 +3,8 @@
 Read [deliverable retention and cleanup authorization](../retention.md) first.
 Classify temporary, intermediate, retained-deliverable, and protected
 resources before choosing a cleanup target. “Owned” is not by itself cleanup
-authorization: never delete all resources created by a task, and never delete
-a requested dataset, dashboard, view, or export artifact as incidental tidy-up.
+authorization. Never delete all resources created by a task. Never delete a
+requested dataset, dashboard, view, or export artifact as incidental tidy-up.
 
 ```bash
 mammoth schema find "trash"

{mammoth_cli-2.0.31 → mammoth_cli-2.0.32}/mammoth_cli/bundled_skill/mammoth-cli/references/recipes/dashboards.md

@@ -1,8 +1,8 @@
 # Dashboards
 
-`dashboard create` (legacy engine) is retired on release (HTTP 409
+Release has retired `dashboard create` (legacy engine; HTTP 409
 `4DASH012`): `schema find "dashboard create"` lists it first, do not use it.
-Create with `create-blank` (or `v3 generate` when an AI route is allowed).
+Create with `create-blank` (or `v3 generate` when the task allows an AI route).
 `dashboard source list` is an observed blocker on release (see
 capabilities); verify the view binding with `dashboard get DASHBOARD_ID`
 (`data.dataview_id`) instead.

{mammoth_cli-2.0.31 → mammoth_cli-2.0.32}/mammoth_cli/bundled_skill/mammoth-cli/references/recipes/end-to-end.md

@@ -14,7 +14,7 @@ mammoth project list          # baseline: ids that exist before you start
 mammoth project ensure 'From Claude'                # -> PROJECT_ID (data.project_id; reused next time)
 mammoth file upload orders.csv --project PROJECT_ID # -> data.datasets[].id/status
 mammoth file upload customers.csv --project PROJECT_ID
-# a dataset in need_action is not usable yet: follow need-action.md (file-settings update), then re-read
+# need_action: follow need-action.md (file-settings update), then re-read; needs_view: run its next_command (view create)
 mammoth dataset list --project PROJECT_ID
 mammoth view list ORDERS_DS --project PROJECT_ID    # -> ORDERS_VIEW
 mammoth view list CUSTOMERS_DS --project PROJECT_ID # -> CUSTOMERS_VIEW

{mammoth_cli-2.0.31 → mammoth_cli-2.0.32}/mammoth_cli/bundled_skill/mammoth-cli/references/recipes/index.md

@@ -5,14 +5,14 @@ only with IDs, display names, and fields returned by the immediately preceding
 read/schema command. Every command is illustrative; piped output is JSON
 without any flag.
 
-Each successful mutation must be verified from a remote read, terminal job,
+Verify each successful mutation from a remote read, terminal job,
 pipeline/task definition, or exported artifact. Retain only nonsecret IDs and
 hashes; stop on ambiguous schemas, authorization errors, or unknown effects.
 
 - [worked example: three CSVs to a per-region summary](end-to-end.md)
 - [auth and scope](auth-scope.md)
 - [files, datasets, views and settings](resources.md)
-- [datasets stuck in `need_action` after upload](need-action.md)
+- [datasets in `need_action` or `needs_view` after upload](need-action.md)
 - [typed transformations and drafts](transforms.md)
 - [typed ETL discovery](typed-etl-discovery.md)
 - [exports and artifacts](exports.md)

{mammoth_cli-2.0.31 → mammoth_cli-2.0.32}/mammoth_cli/bundled_skill/mammoth-cli/references/recipes/need-action.md

@@ -25,8 +25,7 @@ operator only when neither does.
 
 ```bash
 mammoth dataset file-settings update DATASET_ID --project PROJECT_ID \
-  --input '{"delimiter": ",", "has_header": true, "initial_skip_count": 0, "quotechar": "\"", "date_format": "US"}' \
- 
+  --input '{"delimiter": ",", "has_header": true, "initial_skip_count": 0, "quotechar": "\"", "date_format": "US"}'
 ```
 
 The response is a job (`operation: "understand_csv"`). Poll `dataset get`
@@ -35,22 +34,25 @@ the status leaves `need_action`. It usually reaches `ready` within seconds;
 on prague an ISO `YYYY-MM-DD` column was flagged ambiguous and took about
 three minutes, so poll for up to five minutes before treating it as stuck.
 Then `view list` returns the generated view and typed transforms can
-proceed. Which environments ask differs: release processed the same file
-straight to `ready`. If the status becomes `error`, read `status_info`
-and stop; do not retry with guessed settings.
+proceed. Every environment can ask, release included: on 2026-09-24 release
+flagged an ISO `YYYY-MM-DD` column too and reached `ready` within seconds of
+the update. If the status becomes `error`, read `status_info` and stop; do
+not retry with guessed settings.
 
-## All-text CSV: `ready` without a view
+## All-text CSV: ingested, but no view
 
 A CSV whose columns are all text (ids, names, regions, no number or date)
 comes back `status: "ready"` with `status_info.ready` = "This file has more
-than one plausible way to be read." and still gets no view. `file upload`
-reports this as `status: "need_action"` with the same `next_command` as
-above. Confirm the settings exactly as for ambiguous dates; `file-settings
-get` shows `at_least_one_non_text_column_present: false`.
-
-On the release backend the settings update returns a successful
-`understand_csv` job and a batch, but a view is still not created (backend
-defect, reported). If `view list DATASET_ID` stays empty after two polls of
-`dataset get`, stop and report it as a platform blocker for that file; do not
-retry the update. Where the task allows, a file with at least one numeric
-column is processed straight to `ready` with its view.
+than one plausible way to be read." The rows are ingested (`dataset get`
+shows `stats.row_count`), but the platform creates no view. This is not a
+parsing question: confirming file settings does not create a view.
+`file upload` reports it as `status: "needs_view"` with this `next_command`:
+
+```bash
+mammoth view create DATASET_ID --project PROJECT_ID
+mammoth view list DATASET_ID --project PROJECT_ID    # the new view, row_count set
+```
+
+The new view is ready at once and takes transforms like any other (verified
+on release, 2026-09-24). Run `view create` only when `view list DATASET_ID`
+is empty, so that a retry does not add a second view.

{mammoth_cli-2.0.31 → mammoth_cli-2.0.32}/mammoth_cli/bundled_skill/mammoth-cli/references/recipes/resources.md

@@ -11,7 +11,7 @@ Discover exact contracts, then upload and read back explicit parents.
 ## Where uploads land
 
 Unless the task names a project, work in one project of your own and put
-every dataset of the task there, so the user's real projects stay clean and
+every dataset of the task there. The user's real projects then stay clean, and
 one sweep removes everything. `project ensure` is idempotent get-or-create
 by exact name: re-running it (or a second task) returns the same id
 (`created: false`) instead of making another project. A one-off task can
@@ -68,8 +68,8 @@ retry in a loop.
 `file upload` takes the local path as its positional argument; there is no
 `--source`/`--file` option. A path that does not exist is a usage error
 (`Local file not found`) before any request. Its result carries the status the platform holds
-for each created dataset: `ready`, or `need_action` with a `next_command`, in
-which case follow [need-action](need-action.md) before looking for a view. `dataset delete` is asynchronous: re-read
+for each created dataset: `ready`, or `need_action` / `needs_view` with a
+`next_command`, in which case follow [need-action](need-action.md) before looking for a view. `dataset delete` is asynchronous: re-read
 `dataset list` (the id disappears once the job completes) before reporting.
 
 Use display names from the exact view schema. For settings, folders and other
@@ -113,8 +113,7 @@ that every freeform creation type or `dataset_spec` variant works:
 ```bash
 mammoth schema get dataset.create
 mammoth dataset create --project PROJECT_ID --input \
-  '{"ds_creation_type":"weburl","dataset_spec":{"url":"https://example.org/source.csv"}}' \
- 
+  '{"ds_creation_type":"weburl","dataset_spec":{"url":"https://example.org/source.csv"}}'
 ```
 
 Use the `data` keys actually returned by that response for the subsequent

{mammoth_cli-2.0.31 → mammoth_cli-2.0.32}/mammoth_cli/bundled_skill/mammoth-cli/references/recipes/transforms.md

@@ -29,8 +29,7 @@ lists them. Pick the operation by what it does, not by its name:
 ```bash
 mammoth view data get VIEW_ID DATASET_ID --project PROJECT_ID   # before: note which rows have a blank revenue, and a few non-blank values
 mammoth view transform set-values VIEW_ID --project PROJECT_ID \
-  --input '{"dataset_id":DATASET_ID,"existing_column":"revenue","values":[{"value":0}],"condition":{"column":"revenue","operator":"IS_EMPTY"}}' \
- 
+  --input '{"dataset_id":DATASET_ID,"existing_column":"revenue","values":[{"value":0}],"condition":{"column":"revenue","operator":"IS_EMPTY"}}'
 mammoth view data get VIEW_ID DATASET_ID --project PROJECT_ID   # after
 ```
 
@@ -52,12 +51,10 @@ command manifest; substitute only observed view IDs and display names:
 ```bash
 mammoth schema get view.transform.convert-type
 mammoth view transform convert-type VIEW_ID --project PROJECT_ID \
-  --input '{"dataset_id":DATASET_ID,"conversions":[{"column":"Amount","to":"NUMERIC"}]}' \
- 
+  --input '{"dataset_id":DATASET_ID,"conversions":[{"column":"Amount","to":"NUMERIC"}]}'
 mammoth schema get view.transform.math
 mammoth view transform math VIEW_ID --project PROJECT_ID \
-  --input '{"dataset_id":DATASET_ID,"expression":"GDP / Population","new_column":"GDP per capita"}' \
- 
+  --input '{"dataset_id":DATASET_ID,"expression":"GDP / Population","new_column":"GDP per capita"}'
 ```
 
 The released catalog exposes typed dedupe through `schema find duplicate` as
@@ -107,8 +104,7 @@ or use the SQL task with `MAX(monthly_target) AS monthly_target`.
 ```bash
 mammoth schema get view.transform.pivot
 mammoth view transform add-sql VIEW_ID --project PROJECT_ID \
-  --input '{"dataset_id":DATASET_ID,"query":"SELECT region, SUM(amount) AS total_amount, COUNT(*) AS order_count FROM \"view:VIEW_ID\" GROUP BY region"}' \
- 
+  --input '{"dataset_id":DATASET_ID,"query":"SELECT region, SUM(amount) AS total_amount, COUNT(*) AS order_count FROM \"view:VIEW_ID\" GROUP BY region"}'
 mammoth view data get VIEW_ID DATASET_ID --project PROJECT_ID
 ```