mostlyright-data 0.29.0__tar.gz → 0.29.1__tar.gz

{mostlyright_data-0.29.0 → mostlyright_data-0.29.1}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: mostlyright-data
-Version: 0.29.0
+Version: 0.29.1
 Summary: Mostly Right hosted CLI for reviewed datasets
 Project-URL: Homepage, https://mostlyright.md/
 Project-URL: Documentation, https://mostlyright.md/docs/guides/cli/
@@ -82,16 +82,16 @@ mr-data checks RUN_ID
 mr-data download RUN_ID --output ./out
 ```
 
-Full builds are progressive by default: one acquisition exposes an inspection checkpoint after
-about five minutes and continues toward the finished table. Inspect it with
+Full builds are progressive by default: one acquisition exposes an inspection checkpoint after about
+five minutes and continues toward the finished table. Inspect it with
 `mr-data status RUN_ID --inspection --json`; the checkpoint does not pause for approval or start
-another full acquisition. Any required spend confirmation happens before acquisition.
-When a run has sealed queryable table checkpoints, `mr-data status RUN_ID --checkpoints --json`
-lists their exact immutable identifiers and `mr-data query RUN_ID "SELECT …" --checkpoint
-CHECKPOINT_ID` reads one without advancing underneath the query. These workspace-private snapshots
-remain incomplete, keep checks pending, and never become the serving table.
-`--progressive` remains a compatibility alias. Use `--sample` only for an explicit standalone
-bounded inspection; row ceilings do not impose a five-minute acquisition limit.
+another full acquisition. Any required size confirmation happens before acquisition; it is not a
+charge (Mostly Right does not charge per build). When a run has sealed queryable table checkpoints,
+`mr-data status RUN_ID --checkpoints --json` lists their exact immutable identifiers and
+`mr-data query RUN_ID "SELECT …" --checkpoint CHECKPOINT_ID` reads one without advancing underneath
+the query. These workspace-private snapshots remain incomplete, keep checks pending, and never
+become the serving table. `--progressive` remains a compatibility alias. Use `--sample` only for an
+explicit standalone bounded inspection; row ceilings do not impose a five-minute acquisition limit.
 
 Run submission is idempotent: sending identical recipe, mode and bounds returns the same run,
 including a previous failure. The CLI reports a non-queued result as `run_returned` and exits
@@ -104,7 +104,7 @@ A scheduled refresh runs only Studio's persisted bounded source-action plan; it
 falls back to a mutable whole-source fetch. `mr-data table resync TABLE_ID --request-id UUID`
 explicitly requests a full source reread when that is needed. Choose and retain the UUID before
 submitting: if the response is lost, repeat that exact command with the same UUID rather than
-starting another reread. A persisted spend hold is still an accepted resync: its receipt names
+starting another reread. A persisted size hold is still an accepted resync: its receipt names
 the run, projection and exact `mr-data run --confirm-held RUN_ID` action. New full resyncs use
 progressive acquisition too. Existing legacy sample-first pairs can still finish through their
 original confirmation and approval actions. `mr-data recipe readiness` reads Studio's paginated,

{mostlyright_data-0.29.0 → mostlyright_data-0.29.1}/README.md

@@ -70,16 +70,16 @@ mr-data checks RUN_ID
 mr-data download RUN_ID --output ./out
 ```
 
-Full builds are progressive by default: one acquisition exposes an inspection checkpoint after
-about five minutes and continues toward the finished table. Inspect it with
+Full builds are progressive by default: one acquisition exposes an inspection checkpoint after about
+five minutes and continues toward the finished table. Inspect it with
 `mr-data status RUN_ID --inspection --json`; the checkpoint does not pause for approval or start
-another full acquisition. Any required spend confirmation happens before acquisition.
-When a run has sealed queryable table checkpoints, `mr-data status RUN_ID --checkpoints --json`
-lists their exact immutable identifiers and `mr-data query RUN_ID "SELECT …" --checkpoint
-CHECKPOINT_ID` reads one without advancing underneath the query. These workspace-private snapshots
-remain incomplete, keep checks pending, and never become the serving table.
-`--progressive` remains a compatibility alias. Use `--sample` only for an explicit standalone
-bounded inspection; row ceilings do not impose a five-minute acquisition limit.
+another full acquisition. Any required size confirmation happens before acquisition; it is not a
+charge (Mostly Right does not charge per build). When a run has sealed queryable table checkpoints,
+`mr-data status RUN_ID --checkpoints --json` lists their exact immutable identifiers and
+`mr-data query RUN_ID "SELECT …" --checkpoint CHECKPOINT_ID` reads one without advancing underneath
+the query. These workspace-private snapshots remain incomplete, keep checks pending, and never
+become the serving table. `--progressive` remains a compatibility alias. Use `--sample` only for an
+explicit standalone bounded inspection; row ceilings do not impose a five-minute acquisition limit.
 
 Run submission is idempotent: sending identical recipe, mode and bounds returns the same run,
 including a previous failure. The CLI reports a non-queued result as `run_returned` and exits
@@ -92,7 +92,7 @@ A scheduled refresh runs only Studio's persisted bounded source-action plan; it
 falls back to a mutable whole-source fetch. `mr-data table resync TABLE_ID --request-id UUID`
 explicitly requests a full source reread when that is needed. Choose and retain the UUID before
 submitting: if the response is lost, repeat that exact command with the same UUID rather than
-starting another reread. A persisted spend hold is still an accepted resync: its receipt names
+starting another reread. A persisted size hold is still an accepted resync: its receipt names
 the run, projection and exact `mr-data run --confirm-held RUN_ID` action. New full resyncs use
 progressive acquisition too. Existing legacy sample-first pairs can still finish through their
 original confirmation and approval actions. `mr-data recipe readiness` reads Studio's paginated,

{mostlyright_data-0.29.0 → mostlyright_data-0.29.1}/pyproject.toml

@@ -1,6 +1,6 @@
 [project]
 name = "mostlyright-data"
-version = "0.29.0"
+version = "0.29.1"
 description = "Mostly Right hosted CLI for reviewed datasets"
 readme = "README.md"
 requires-python = ">=3.11"

{mostlyright_data-0.29.0 → mostlyright_data-0.29.1}/skills/mr-data-build/SKILL.md

@@ -78,18 +78,21 @@ references. Load the reference for the current stage only, not the entire librar
    only for a deliberate standalone inspection. Preserve the agreed semantics and quality checks.
 7. Follow the returned run with `mr-data watch RUN_ID --json`. Its `source_rates` and
    `mr-data status RUN_ID --json` on a live run give each collection source's rate and time left.
-   Quote those numbers rather than doing the arithmetic. Read `run.status`: returning an
-   existing run does not mean new work was queued. Resume the known run after an interruption,
-   using the saved cursor where available. Read [run lifecycle](references/live-run.md) for
-   holds and continuation commands. Confirm projected spend before acquisition when required;
-   the progressive checkpoint needs no approval or second full run. Honor the user's
-   authorization; do not request an existing delegation again. Send a
-   concise chat update for each newly observed meaningful lifecycle transition: accepted or
-   queued, released after confirmation, started, failed, retried or replaced, completed, and
-   verified. Include the run ID so the user can tell attempts apart; state the supported failure
-   cause, name both the old and new run IDs for a retry or replacement, and include elapsed time or
-   throughput when the user requested a benchmark. Do not repeat an unchanged poll, and never
-   treat the app activity pill as a substitute for these updates.
+   Quote those numbers rather than doing the arithmetic. Read `run.status`: returning an existing
+   run does not mean new work was queued. Resume the known run after an interruption, using the
+   saved cursor where available. Read [run lifecycle](references/live-run.md) for holds and
+   continuation commands. When Studio holds a large run for a size confirmation, settle it with
+   `--confirm`. The hold is a size check, not a charge: Mostly Right never charges per build, so
+   never ask the user to pay or confirm a cost for the hold. A source whose own provider bills per
+   call is a separate, real cost: forecast it and ask before re-reading it, as the paid-source rules
+   above say. The progressive checkpoint needs no approval or second full run. Honor the user's
+   authorization; do not request an existing delegation again. Send a concise chat update for each
+   newly observed meaningful lifecycle transition: accepted or queued, released after confirmation,
+   started, failed, retried or replaced, completed, and verified. Include the run ID so the user can
+   tell attempts apart; state the supported failure cause, name both the old and new run IDs for a
+   retry or replacement, and include elapsed time or throughput when the user requested a benchmark.
+   Do not repeat an unchanged poll, and never treat the app activity pill as a substitute for these
+   updates.
 
 ## Recover without guesswork
 

{mostlyright_data-0.29.0 → mostlyright_data-0.29.1}/skills/mr-data-build/references/2-brief-two-to-four-questions-each-with-a-recommended-answer.md

@@ -65,9 +65,9 @@ mr-data dataset note DATASET_ID --heading "The brief is delegated to the agent"
 the same identifier, revising it rather than stacking a second — the one-command form for a
 delegation given after stage 2.
 
-**Do not re-ask delegated decisions.** State choices within that scope and the spend projection
-when authorized. Ask only what the delegation did not settle; a narrower delegation must not
-silently become permission to schedule recurring work.
+**Do not re-ask delegated decisions.** State choices within that scope and the projected size when
+authorized (never a price: Mostly Right does not charge per build). Ask only what the delegation did
+not settle; a narrower delegation must not silently become permission to schedule recurring work.
 
 **Registration refuses a dataset nobody was asked about.** `mr-data recipe` reads the dataset's own
 record and answers `THIN_BRIEF_MISSING` when it holds no answered `clarification` and no delegation

{mostlyright_data-0.29.0 → mostlyright_data-0.29.1}/skills/mr-data-build/references/3-probe-read-a-source-before-committing-to-it.md

@@ -104,7 +104,8 @@ not promise a short acquisition. Never derive source size from a truncated sampl
 
 **A reading run that came back whole IS the build, so stage 6 adopts it rather than repeating
 it.** Untruncated everywhere is the build, whichever stage started the run: keep this `run_id`.
-The run meets the ordinary spend confirmation before acquisition; its checkpoint requires no
+The run meets Studio's ordinary size confirmation before acquisition when it is large (a size
+check, not a charge); its checkpoint requires no
 second approval or second full build.
 
 That is stages 5 through 7 run once to settle the shape. Where the deployment does answer a probe,

{mostlyright_data-0.29.0 → mostlyright_data-0.29.1}/skills/mr-data-build/references/6-build-one-run-sized-to-acquire-every-measured-source-whole.md

@@ -15,9 +15,9 @@ mr-data run --recipe RECIPE_ID --digest RECIPE_DIGEST --full --json
 
 After about five minutes, inspect `mr-data status RUN_ID --inspection --json` while the same
 acquisition continues. This checkpoint is read-only, not a second approval gate or a hard runtime
-limit. A short build can finish before a checkpoint is needed. Do not submit another full run
-after inspecting it. Required spend confirmation happens before acquisition. The older
-`--progressive` flag is accepted for compatibility but is unnecessary.
+limit. A short build can finish before a checkpoint is needed. Do not submit another full run after
+inspecting it. A required size confirmation happens before acquisition; it is not a charge. The
+older `--progressive` flag is accepted for compatibility but is unnecessary.
 
 **A standalone sample is an explicit inspection choice.** Use `--sample --max-rows 2000` only
 when a separate bounded experiment is needed. Rows are clamped after acquisition, so a collection
@@ -48,8 +48,9 @@ sample. A full run reads such a source from its `start_at`. A source whose `star
 current UTC day has no completed day until that day is over, so neither a sample nor a full run of
 it reads anything before then.
 
-If existing authorization or a stage-2 delegation covers this full build and its spend, do not
-ask again: state the projection and run it. A narrower delegation does not authorize the full run.
+If existing authorization or a stage-2 delegation covers this full build, do not ask again: state
+the projected size and run it. There is no per-build payment to ask about. A narrower delegation
+does not authorize the full run.
 
 ```sh
 mr-data run --recipe RECIPE_ID --digest RECIPE_DIGEST --full --json
@@ -105,14 +106,14 @@ mr-data run --retry RUN_ID --json
 
   It re-states that run's own recipe, digest, mode and ceilings under one byte ceiling above what
   the recipe declares, because Studio replays a terminal result for an identical command and the
-  coordinate has to move — and the number that ceiling must clear is what the run is projected to
-  cost, not just what it may fetch. It refuses, with the triple, when the failure was the recipe's,
+  coordinate has to move — and the number that ceiling must clear is how large the run is projected
+  to be, not just what it may fetch. It refuses, with the triple, when the failure was the recipe's,
   which is the signal to repair the document instead. It also refuses three runs with no coordinate
   left to move: a replay, whose ceilings must equal its source run's; a run stating a byte ceiling
-  of its own below that floor, because raising it would fetch bytes the first attempt could not and could
-  carry the run under a spend gate it was held at; and half of a sample-first pair, whose preview
-  retried is a standalone run the held full never learns about. Retry a room fault at most three
-  times; report each new run once and keep unchanged polling quiet.
+  of its own below that floor, because raising it would fetch bytes the first attempt could not and
+  could carry the run under a size gate it was held at; and half of a sample-first pair, whose
+  preview retried is a standalone run the held full never learns about. Retry a room fault at most
+  three times; report each new run once and keep unchanged polling quiet.
 - **Anything that changes what the data MEANS** — a source that cannot be reached at all, a grain
   the feeds cannot deliver, a column that has to be dropped — is a stage 2 question, asked the
   stage 2 way, and never a silent substitution.
@@ -199,11 +200,13 @@ make every source or connector incremental.
 complete acquired response is told from one cut at fifty thousand rows without opening the
 receipt: read `coverage` off the run, not the row count off the table.
 
-A run over the spend threshold is not started. It answers with the projected bytes, runtime and
-cost, and waits; the same command again with `--confirm` settles it against the number already on
+A run over Studio's size threshold is not started. It answers with the projected bytes and runtime
+(and Studio's internal compute estimate, which is not billed: Mostly Right does not charge per
+build), and waits; the same command again with `--confirm` settles it against the number already on
 the record — `mr-data run --recipe RECIPE_ID --digest RECIPE_DIGEST --full --confirm`, which the
-held answer prints back as `confirm_command`. Any authenticated surface of the paying workspace may
-settle it. `mr-data run --cancel RUN_ID` stops a run that is queued or running.
+held answer prints back as `confirm_command`. Any authenticated surface of the subscribed workspace
+may settle it. Never present it to the user as a cost or a payment. `mr-data run --cancel RUN_ID`
+stops a run that is queued or running.
 
 Do not treat the accepted command vocabulary as execution evidence. Before proposing a schedule,
 classify every source under one truthful continuation strategy and record the supporting evidence,

{mostlyright_data-0.29.0 → mostlyright_data-0.29.1}/skills/mr-data-build/references/9-present-only-what-survived-inspection-with-caveats.md

@@ -30,29 +30,29 @@ was explicitly delegated. Report the effective schedule and whether it is still
 
 **Truncated anywhere is a preview, and this is the one place the build pauses.** State what the
 preview established, name the source that was cut and the row it stopped at, say what a full build
-would cover, and ask: it costs real time and money and it is a decision about the user's data. That
-decision and spend confirmation may already be settled by a delegation at stage 2; honor its
-scope. Cadence requires the update answer or explicit refresh delegation described above. Stage 6
-carries the run commands.
+would cover, and ask: it costs real time and it is a decision about the user's data (not a payment:
+Mostly Right does not charge per build). That decision and any size confirmation may already be
+settled by a delegation at stage 2; honor its scope. Cadence requires the update answer or explicit
+refresh delegation described above. Stage 6 carries the run commands.
 
 **The same decision can arrive as a run you did not start.** A person can start the full build from
 the dataset page, so before acting on this recipe again read `mr-data runs --json --mode full` and,
 for any run newer than the preview that you did not start, `mr-data status RUN_ID --json` to see
 whether it names this recipe and digest. One that does is theirs, and its state says what to do.
 `queued`, `running` or `succeeded` is the full build: adopt it as if you had started it — write its
-run cell, `mr-data watch RUN_ID --json` if it has not ended, then stage 7.
-`awaiting_confirmation` is the spend gate, which the same command settles with `--confirm`.
+run cell, `mr-data watch RUN_ID --json` if it has not ended, then stage 7. `awaiting_confirmation`
+is the size gate (not a charge), which the same command settles with `--confirm`.
 `awaiting_sample_approval` is stage 6's held full: read its `sample_run_id`, interrogate that
 preview, and release it with `mr-data run --approve-full`. `failed` is the full build too: read its
 triple and structured recovery. A known retry case can use `mr-data run --retry RUN_ID`; otherwise
 preserve the document until the evidence identifies a repair. A bare run of the same coordinate
-replays that failure. `cancelled` means they
-withdrew the decision, so say so and ask nothing further unless they raise it. Ask, then give the
-turn back; do not hold a stream open waiting for either answer.
+replays that failure. `cancelled` means they withdrew the decision, so say so and ask nothing
+further unless they raise it. Ask, then give the turn back; do not hold a stream open waiting for
+either answer.
 
 Then interrogate that run as stage 7 says, and present it with the preview's caveats removed and
 its own read off `coverage`. Do not start a full build because the preview looked good or because a
-dataset was asked for — the decision is whether THIS is the recipe to spend one on.
+dataset was asked for — the decision is whether THIS is the recipe to build.
 
 **Either way, offer the bytes.** A sealed table is downloadable whatever mode produced it —
 `mr-data download RUN --output DIR --json` — so somebody who wants to look before agreeing to

{mostlyright_data-0.29.0 → mostlyright_data-0.29.1}/skills/mr-data-build/references/autonomous-delivery.md

@@ -4,13 +4,13 @@ Own the run until the requested outcome is delivered: a run that succeeded, its
 read, its coverage inspected against the shape stage 2 settled, and its refresh cadence recorded.
 What is live is what Studio returns as live; catch-up and continuing freshness require separate
 durable evidence from the deployed component that owns them. The brief's questions, a material
-semantic revision, the cadence, a full build after a truncated preview and a spend confirmation are
-the valid user pauses. A delegation settles only decisions within its stated scope; ongoing
-refresh requires an update answer or explicit refresh delegation. Own the
-operational choices: Readers, engines, parsing formats, workspace plumbing, retry tactics, and
-every repair that preserves the meaning of the data. Source preferences and cleaning choices that
-change the meaning belong in the user conversation, even when the agent could technically choose
-for them.
+semantic revision, the cadence, a full build after a truncated preview and a size confirmation of a
+large run are the valid user pauses (none of them is a payment: Mostly Right does not charge per
+build). A delegation settles only decisions within its stated scope; ongoing refresh requires an
+update answer or explicit refresh delegation. Own the operational choices: Readers, engines, parsing
+formats, workspace plumbing, retry tactics, and every repair that preserves the meaning of the data.
+Source preferences and cleaning choices that change the meaning belong in the user conversation,
+even when the agent could technically choose for them.
 
 **`mr-data clarify` does not replace the user conversation.** Pass `--attended` when a person
 is available in chat, or `--unattended` for a scheduled invocation,

{mostlyright_data-0.29.0 → mostlyright_data-0.29.1}/skills/mr-data-build/references/cloud-authentication-preflight.md

@@ -19,6 +19,18 @@ present, carry on to the cloud command and let that command's credential resolve
 override; when it is absent, run `mr-data login`, complete the device approval, rerun
 `mr-data whoami --json`, and require an authenticated status before the cloud command.
 
+A credential belongs to one workspace for its whole life. An account in more than one workspace
+is asked which on an interactive terminal; with `--json`, or with nobody at the terminal, login is
+refused `LOGIN_WORKSPACE_REQUIRED` and the message lists the workspace names. Ask the user which
+workspace this machine is for, then rerun with `--workspace NAME` — `mr-data login` and
+`mr-data auth login` both take it, with the same meaning. Never choose a workspace for the user.
+`LOGIN_DEVICE_KEY_LIMIT` means the user already holds as many active CLI keys in that workspace
+as the cloud allows: tell them to revoke one they no longer use (in the dashboard, with that
+workspace selected, under Account → Security; or `mr-data auth logout` on a machine they are
+finished with), and do not retry until they have. Then rerun the command that was refused:
+`mr-data login` for a first sign-in, `mr-data auth rotate` or `mr-data login --force` for a
+replacement, because a rotation that hits the limit leaves this machine's credential in place.
+
 The hosted lane requires an `mr_cli_` device credential; a read-only live data key is refused with
 `THIN_AUTHENTICATION_FAILED` rather than failing three calls later.
 `mr-data export-hosted-candidate` is a backend operator step and needs neither this preflight nor a

{mostlyright_data-0.29.0 → mostlyright_data-0.29.1}/skills/mr-data-build/references/commands.md

@@ -14,7 +14,7 @@ gap rather than doing anything, and `export-hosted-candidate`, which is a backen
 | `mr-data dataset` | Bring the dataset page into existence before there is anything on it, then fill it in while somebody watches. `dataset create --name TEXT` mints it and prints the `dataset_id`, unless the user's own request already has an empty dataset open, in which case it answers `open_request_reused` with that `dataset_id` and mints nothing (`--separate` mints a new one for a different dataset); `dataset show ID` reads it back; `dataset set ID --name TEXT --topics "a,b,c" --license ID --description-file F` writes the title, the descriptive tags, the SPDX licence and the description under the version it was read at, retrying once if somebody else wrote first, and an empty `--topics` or `--license` takes that value off the page; send `--name` and `--topics` whenever you send `--description-file`, because a description sent on its own can make Studio write a new title and new tags, and read `changed` and `written_by_studio` on the receipt for every field the write moved; a saved write whose public sync fails exits 2 and reports `public_projection_synced: false` — use `dataset sync ID` to retry that sync without rewriting Studio; `dataset note ID --heading H --blocks-file B` writes one cell of the decision record that OUTLIVES every run, and `--list` reads it back; `dataset watch ID` follows the page's own event stream; `dataset activity ID --phase P --message TEXT` says what is happening right now, silently, and is never a chat message and never a cell; `dataset publish ID [--mode public|link|private]` says who can read the dataset — `public` lists it in the public directory and serves it at an address anybody can read, `link` serves it at an unlisted address, `private` takes it back to the workspace — and `dataset publish ID --show` reads that back without changing it; `dataset archive ID --confirm-name TITLE` retires the page and frees its title, deleting nothing. |
 | `mr-data recipe` | Register one recipe document — dataset, question, table plan, sources, transform, checks and units — in one call, and print the identifiers the server derived. The document is read first and every fault comes back in one refusal, each with the JSON pointer that names it; `--no-lint` sends it as written instead. Registration refuses `THIN_BRIEF_MISSING` when the dataset's record carries no answered question and no delegation, and `THIN_RECIPE_DATASET_UNBOUND` when the document names no `dataset.id`; `--delegated "their words"` writes the delegation onto the dataset and registers in the same command, and clears the first of those two and never the second. `mr-data recipe show ID` reads one back. `mr-data recipe explain FILE` (or a recipe identifier) lists every reason its table can or cannot refresh, each with a rule code and Studio's suggested repair, and exits 2 when one blocks it. `mr-data recipe forecast RECIPE_ID --digest DIGEST` says what one run would ask of each source before it runs, and exits 3 when the run would overrun today's platform quota or one attempt. `mr-data recipe readiness --table TABLE_ID --current-only` reads the revision one table runs now. [Making a table incremental](making-a-table-incremental.md#the-loop-explain-forecast-run-diagnose) says when to use each. |
 | `mr-data cover` | Generate and attach one branded 1200×630 dataset cover. Give it the dataset ID and what the image should depict; Studio fixes the model, single-color style, curated random palette, dimensions and storage. |
-| `mr-data run` | Start one run against a registered recipe, named as `--recipe RECIPE_ID --digest RECIPE_DIGEST` — both required, neither positional, and the digest is the bare hex the registration receipt printed. The mode is one of six: `sample`, `full`, `refresh`, `backfill`, `compact` and `replay`. Four have a shorthand flag (`--sample`, `--full`, `--refresh`, `--backfill`) and two do not, so write `--mode MODE`, which is accepted for every one of them. A refresh executes only Studio's persisted source-action plan, and a plan shape it does not refresh returns `RESYNC_REQUIRED` before acquisition; [which plans refresh](making-a-table-incremental.md#which-plans-refresh) lists them, and `mr-data recipe explain` says which one a table is. Use `mr-data table resync TABLE_ID --request-id UUID` for an explicit full source reread, retaining that UUID if the response is uncertain. `--backfill` states the exact window with `--window START END`. `--mode replay --sources-from RUN_ID` asks Studio to run the registered revision against the RETAINED RAW INPUTS of one named successful run of the same table: nothing is fetched from this computer, nothing is acquired again, the result is compared against that run and never becomes the live version, and it neither asks for nor records an approval. Where Studio has replay switched off, or the named run is not successful, not the same table, or no longer retains its inputs, it answers a typed refusal — report the code rather than retrying in another mode. `--sources-from` on any other mode is refused `THIN_ARGUMENT_INVALID` before anything is sent. `--max-rows` and `--max-source-bytes` bound ONE SOURCE rather than the finished table. A large run is held for a spend confirmation, which `--confirm` settles and whose printed `confirm_command` re-states every argument the request carried. `--approve-full RUN_ID` releases the full an existing legacy sample-first pair is holding once its preview has succeeded, naming either half of the pair; where the deployment still wants a person at a browser it answers `THIN_INTERACTIVE_HUMAN_REQUIRED` and names the run page. `--retry RUN_ID` tries one failed run again when its triple carries `room_fault: true`, re-stating that run's own coordinate under a byte ceiling that cannot narrow it, and refuses with the triple when the recipe was at fault. `--cancel RUN` stops one. |
+| `mr-data run` | Start one run against a registered recipe, named as `--recipe RECIPE_ID --digest RECIPE_DIGEST` — both required, neither positional, and the digest is the bare hex the registration receipt printed. The mode is one of six: `sample`, `full`, `refresh`, `backfill`, `compact` and `replay`. Four have a shorthand flag (`--sample`, `--full`, `--refresh`, `--backfill`) and two do not, so write `--mode MODE`, which is accepted for every one of them. A refresh executes only Studio's persisted source-action plan, and a plan shape it does not refresh returns `RESYNC_REQUIRED` before acquisition; [which plans refresh](making-a-table-incremental.md#which-plans-refresh) lists them, and `mr-data recipe explain` says which one a table is. Use `mr-data table resync TABLE_ID --request-id UUID` for an explicit full source reread, retaining that UUID if the response is uncertain. `--backfill` states the exact window with `--window START END`. `--mode replay --sources-from RUN_ID` asks Studio to run the registered revision against the RETAINED RAW INPUTS of one named successful run of the same table: nothing is fetched from this computer, nothing is acquired again, the result is compared against that run and never becomes the live version, and it neither asks for nor records an approval. Where Studio has replay switched off, or the named run is not successful, not the same table, or no longer retains its inputs, it answers a typed refusal — report the code rather than retrying in another mode. `--sources-from` on any other mode is refused `THIN_ARGUMENT_INVALID` before anything is sent. `--max-rows` and `--max-source-bytes` bound ONE SOURCE rather than the finished table. A large run is held for a size confirmation (not a charge), which `--confirm` settles and whose printed `confirm_command` re-states every argument the request carried. `--approve-full RUN_ID` releases the full an existing legacy sample-first pair is holding once its preview has succeeded, naming either half of the pair; where the deployment still wants a person at a browser it answers `THIN_INTERACTIVE_HUMAN_REQUIRED` and names the run page. `--retry RUN_ID` tries one failed run again when its triple carries `room_fault: true`, re-stating that run's own coordinate under a byte ceiling that cannot narrow it, and refuses with the triple when the recipe was at fault. `--cancel RUN` stops one. |
 | `mr-data status` | Report which of the seven states one run is in, what it delivered and whether a ceiling cut it short, and — on a failure — what failed, where, and whether the fault was the execution room's rather than the recipe's. Exits non-zero on a failed run. `--diagnose` adds everything else Studio can say about the run: its progress, a per-row source's plan counts, its checkpoints, and how each attempt ended, with a lost attempt's cause marked as an inference. |
 | `mr-data runs` | Report this workspace's own runs: identifier, mode, state and creation time, plus the failure triple of any that failed and whether that failure was the execution room's. `--status` and `--mode` narrow it and are refused `THIN_ARGUMENT_INVALID` for a word outside the seven states or the six modes; `--limit` says how many, and pages are followed to reach it. A narrow filter over a workspace of thousands of runs reads a long way to find its matches, and a listing that does not end says how many were read and suggests a smaller `--limit`. The answer prints `next_cursor`, and `--cursor` continues from it. |
 | `mr-data watch` | Stream one run's live progress under the durable event type of each stage, resuming across stream cuts. Exits non-zero when the run failed. |
@@ -38,16 +38,16 @@ gap rather than doing anything, and `export-hosted-candidate`, which is a backen
 | `mr-data unpin` | Ask Studio to resume pointer tracking; read the returned state before claiming it resumed. |
 | `mr-data demote` | Ask Studio to withdraw the pointer and any schedule it owns, for one table or for as many as you name: `demote TABLE [TABLE ...]` withdraws them one after another, attempts every one of them whatever the one before it answered, prints a line for each, and exits non-zero if any is still live. Pair it with `table archive` when you are retiring a set: a live table cannot be archived, so it is withdraw-then-archive, two commands rather than a loop. |
 
-Every `mr-data run --full` or `--mode full` build is progressive by default. The old
-`--progressive` flag remains a compatibility alias. Studio admits one full run and keeps acquisition moving while the
-owner inspects its five-minute checkpoint. A spend confirmation, when required, still comes
-before acquisition. Read `mr-data status RUN_ID --inspection --json` for the declared columns,
-missing-data policy, every source's bounded progress, and any observed table evidence. Source
-relation rows are not finished table rows; unknown transformed values remain null. A failed or
-cancelled progressive run may be followed by a new
-`--mode full --resume-capture-run-id RUN_ID` request under a registered compatible
-recipe. Studio decides which sealed captures can be reused. Keep the returned new run ID and
-verify its final receipt.
+Every `mr-data run --full` or `--mode full` build is progressive by default. The old `--progressive`
+flag remains a compatibility alias. Studio admits one full run and keeps acquisition moving while
+the owner inspects its five-minute checkpoint. A size confirmation, when Studio requires one, still
+comes before acquisition; it is not a charge. Read `mr-data status RUN_ID --inspection --json` for
+the declared columns, missing-data policy, every source's bounded progress, and any observed table
+evidence. Source relation rows are not finished table rows; unknown transformed values remain null.
+A failed or cancelled progressive run may be followed by a new
+`--mode full --resume-capture-run-id RUN_ID` request under a registered compatible recipe. Studio
+decides which sealed captures can be reused. Keep the returned new run ID and verify its final
+receipt.
 
 ### Strict refresh controls
 

{mostlyright_data-0.29.0 → mostlyright_data-0.29.1}/skills/mr-data-build/references/live-run.md

@@ -59,7 +59,8 @@ its row ceiling does not bound acquisition time.
 
 **Seven states, including legacy holds.** A run is `queued`, `running`, `awaiting_confirmation`,
 `awaiting_sample_approval`, `succeeded`, `failed` or `cancelled`; three are terminal and end a
-watch. `awaiting_confirmation` is the ordinary spend gate: nothing has been executed, and the same
+watch. `awaiting_confirmation` is the ordinary size gate (not a charge: Mostly Right does not charge
+per build): nothing has been executed, and the same
 run command with `--confirm` on the end of it releases it. `awaiting_sample_approval` is the held
 full of an existing legacy sample-first pair: its bounded preview must seal a downloadable table
 first, and then

{mostlyright_data-0.29.0 → mostlyright_data-0.29.1}/skills/mr-data-build/references/making-a-table-incremental.md

@@ -212,7 +212,8 @@ run evidence support a claim that a table is refreshing.
 ### Rebuild: the fifth continuation
 
 The other continuations say how to fetch less. `rebuild` says truthfully that there is no less. It
-is a table-level member, and it is the only consent Studio takes to spend on a scheduled full read:
+is a table-level member, and it is the only standing consent Studio takes to acquire a scheduled
+full read:
 
 ```json
 "rebuild": {"mode": "whole_table", "max_rebuild_bytes": 270000000, "min_interval_seconds": 604800}
@@ -223,7 +224,7 @@ is a table-level member, and it is the only consent Studio takes to spend on a s
 - **Size `max_rebuild_bytes` at 1.5 times a measured run.** Take the bytes the last full acquired:
   the sum of `bytes_fetched` over the receipt's sources, or `totals.projected_bytes` in
   `mr-data recipe forecast`. If they sum to 180 MB, state 270,000,000. Studio starts a scheduled
-  rebuild without a spend confirmation only while its projected acquisition fits inside this
+  rebuild without a size confirmation only while its projected acquisition fits inside this
   number. A revision that grows past it is refused `REBUILD_BUDGET_EXCEEDED` before any run
   exists.
 - **`min_interval_seconds`** is from 3,600 to 31,536,000. Choose it from how often the source
@@ -497,9 +498,9 @@ before you register:
 - if the horizon turns out short, register the corrected revision before the first refresh, while
   there is only one day to lose.
 
-Until a run of the source has been observed, Studio prices the first full at the declared
-`limits.max_source_bytes`, so a large ceiling can make that one full ask for a spend confirmation.
-Later runs are priced from what was observed.
+Until a run of the source has been observed, Studio sizes the first full at the declared
+`limits.max_source_bytes`, so a large ceiling can make that one full ask for a size confirmation.
+Later runs are sized from what was observed.
 
 Watch `mr-data recipe forecast`. Its `snapshot_history` reports the days held, the declared
 horizon and `days_remaining`, and it warns `SNAPSHOT_HISTORY_CEILING_NEAR` at 30 days or fewer. At

{mostlyright_data-0.29.0 → mostlyright_data-0.29.1}/skills/mr-data-build/references/promote.md

@@ -40,7 +40,7 @@ and — once there is one — the interval Studio measured and how many source u
 **Never describe a schedule as learned, settled or confirmed while that command says otherwise.**
 
 `mr-data reschedule TABLE_ID --cadence ... --why "..."` changes the schedule of a table that is
-already live without starting a run or spending anything. Adding `--lock` freezes the schedule so
+already live without starting a run or acquiring anything. Adding `--lock` freezes the schedule so
 Studio stops adjusting it, which is how a person overrides the evidence; `--unlock` lets it follow
 the source again. Do not lock a schedule on your own judgement — it is the same kind of decision as
 the cadence itself, and it belongs to the user. An explicit request for a fixed schedule is

{mostlyright_data-0.29.0 → mostlyright_data-0.29.1}/skills/mr-data-build/references/sources.md

@@ -215,7 +215,7 @@ breaks a rule above.
 | `opaque_reference` | `credential.secret_name` and `request.auth` | a key the user enrolled with `mr-data keys set` |
 | `platform` | no `credential` and no `auth` | an endpoint Mostly Right holds a key for |
 
-The platform credential needs no key from anyone, and any paying workspace may use it. It serves
+The platform credential needs no key from anyone, and any subscribed workspace may use it. It serves
 one binding today: `POST https://openrouter.ai/api/alpha/decisions`, with `/model` set to
 `typesafe/jev-1.13`. Pin that exact model. A floating alias such as `~typesafe/jev-latest` is
 refused at registration with `PLATFORM_CREDENTIAL_UNBOUND`. Keep the origin, method and path

{mostlyright_data-0.29.0 → mostlyright_data-0.29.1}/src/mostlyright/data_harness/thin/recipe.py

@@ -225,7 +225,8 @@ def declare_arguments(parser: argparse.ArgumentParser) -> None:
     parser.add_argument(
         "--confirm",
         action="store_true",
-        help="with `propose`, authorize the projected spend if the replay is held for one",
+        help="with `propose`, confirm the projected size if the replay is held for one (a size "
+        "check, not a charge)",
     )
     parser.add_argument(
         "--table",
@@ -973,8 +974,9 @@ def sample_span_warnings(sources: Any) -> list[str]:
         "A check on the whole table, such as a `row_expectation` floor, can fail on a sample "
         "for that reason alone, with nothing wrong in the recipe or the source",
         # ⚠ WHAT VERIFIES THE CHECK, AND NOT AN ORDER TO RUN IT. This is read at registration,
-        # before any run, and a full build spends money: the skill allows one only under an
-        # authorization that covers it, and Studio's spend gate holds only the large ones.
+        # before any run, and a full build is a real acquisition: the skill allows one only under
+        # an authorization that covers it, and Studio's size gate holds only the large ones. It is
+        # not a charge: Mostly Right does not charge per build.
         "A full run is what verifies a check on the whole table, once the full build is authorized",
     ]
     return [". ".join(said)]
@@ -1763,7 +1765,7 @@ def propose(
             "brief": registration["brief"],
             "replay": replay,
             "next": (
-                "Show the projected cost to the user, then call "
+                "Show the projected size to the user, then call "
                 f"`{replay.get('confirm_command', 'mr-data run --confirm …')}` only if they "
                 "agree. The replay produces repair evidence only; no full run is approved."
             ),

{mostlyright_data-0.29.0 → mostlyright_data-0.29.1}/src/mostlyright/data_harness/thin/v4.py

@@ -484,10 +484,11 @@ TABLE_VERSION_EXPORT_PATH = "/v4/tables/{table_id}/versions/{table_version_id}:e
 
 #: ``POST`` -- replace the effective refresh schedule under the version fence, dispatching no run.
 #:
-#: ⚠ THE ONLY WAY TO CHANGE A LIVE TABLE'S SCHEDULE WITHOUT SPENDING ANYTHING. A second promote on
+#: ⚠ THE ONLY WAY TO CHANGE A LIVE TABLE'S SCHEDULE WITHOUT ACQUIRING ANYTHING. A second promote on
 #: a live table is an idempotent replay that ignores the new cadence, so before this route the only
 #: way to move a schedule was demote plus promote -- which resets the table's bookkeeping and
-#: dispatches a paid catch-up refresh, neither of which anybody wanted from "make it hourly".
+#: dispatches an unwanted catch-up refresh, neither of which anybody asked for with "make it
+#: hourly".
 RESCHEDULE_TABLE_PATH = "/v4/tables/{table_id}:reschedule"
 
 #: ``POST`` -- explicitly create one full source reread for a table. This is deliberately a table

{mostlyright_data-0.29.0 → mostlyright_data-0.29.1}/src/mostlyright/data_harness/thin/v4_query.py

@@ -403,7 +403,8 @@ def declare_arguments(parser: argparse.ArgumentParser) -> None:
         action="store_true",
         help="when no warm worker is holding the workspace, refuse rather than open a research "
         "session for the run's dataset. Left out, this command opens one, waits for its worker, "
-        "asks, and closes it, so the wait is paid only for a question actually asked. When no "
+        "asks, and closes it, so a worker is waited for only when a question is actually asked. "
+        "When no "
         f"worker can be started for that session, it waits {SESSION_RETRY_WAIT_SECONDS:g} "
         "seconds and opens one more, once",
     )

{mostlyright_data-0.29.0 → mostlyright_data-0.29.1}/src/mostlyright/data_harness/thin/v4_runs.py

@@ -498,7 +498,7 @@ def declare_run_arguments(parser: argparse.ArgumentParser) -> None:
         action="store_const",
         const="full",
         help="build the whole dataset progressively; inspect its five-minute checkpoint while "
-        "acquisition continues, with spend confirmation before acquisition when required",
+        "acquisition continues, with a size confirmation before acquisition when Studio holds it",
     )
     mode.add_argument(
         "--refresh",
@@ -568,13 +568,15 @@ def declare_run_arguments(parser: argparse.ArgumentParser) -> None:
     parser.add_argument(
         "--confirm",
         action="store_true",
-        help="authorize the projected spend if this run is held for one, instead of printing it",
+        help="confirm the projected size if Studio holds this run for one, instead of printing it; "
+        "the hold is a size check, not a charge (Mostly Right does not charge per build)",
     )
     parser.add_argument(
         "--confirm-held",
         dest="confirm_held",
         metavar="RUN_ID",
-        help="authorize the projected spend of this exact persisted held run; use the run id a "
+        help="confirm the projected size of this exact persisted held run (a size check, not a "
+        "charge); use the run id a "
         "held table resync receipt prints",
     )
     parser.add_argument(
@@ -855,7 +857,7 @@ def create_run_body(args: argparse.Namespace) -> dict[str, Any]:
             "THIN_REQUEST_INVALID",
             "a sample needs at least one ceiling: --max-rows, --max-source-bytes or --window. A "
             "sample with none is a full run under another name, and it would be dispatched and "
-            "billed as one",
+            "sized as one",
         )
     if mode == "backfill" and "window" not in clamps:
         raise ThinLaneError(
@@ -1205,9 +1207,9 @@ def retry_clamps(run: Mapping[str, Any], *, declared_bytes: int = 0) -> dict[str
         raise ThinLaneError(
             ARGUMENT_INVALID_CODE,
             f"this run states max_source_bytes of {carried!r}, which bounds what it may transfer "
-            "and what it is projected to cost. A retry has to move the run's coordinate, and that "
-            "ceiling is the only member of it that can move; raising it would let the attempt "
-            "fetch bytes the first one could not, and could carry the run under a spend threshold "
+            "and how large it is projected to be. A retry has to move the run's coordinate, and "
+            "that ceiling is the only member of it that can move; raising it would let the attempt "
+            "fetch bytes the first one could not, and could carry the run under a size threshold "
             "the first one was held at. Start the run again yourself under a coordinate you mean, "
             "or register a revision",
         )
@@ -1368,7 +1370,7 @@ def retry(run_id: str, *, client: StudioV4RunClient) -> dict[str, Any]:
             f"run {run_id} is the preview of a sample-first pair, and the full it is holding "
             f"({linked}) is bound to THIS preview by identity. Another attempt would be a "
             "standalone run that the held full never learns about, so the pair would stay held "
-            f"and the work would be paid for twice. Cancel the pair with mr-data run --cancel "
+            f"and the work would be done twice. Cancel the pair with mr-data run --cancel "
             f"{linked} and start the run again",
         )
     if run.get("mode") == "replay":
@@ -1621,7 +1623,7 @@ def confirm_held(named: str, *, client: StudioV4RunClient) -> dict[str, Any]:
         raise ThinLaneError(
             ARGUMENT_INVALID_CODE,
             f"run {named} is {state!r}, and --confirm-held only settles a persisted "
-            "awaiting_confirmation spend hold",
+            "awaiting_confirmation size hold",
         )
     expected = parse_etag_version(headers.get("ETag") or headers.get("etag"))
     confirmed = client.confirm_run(named, expected_version=expected)

{mostlyright_data-0.29.0 → mostlyright_data-0.29.1}/src/mostlyright/data_harness/thin/v4_tables.py

@@ -825,7 +825,7 @@ def declare_arguments(command: str, parser: argparse.ArgumentParser) -> None:
             help=(
                 "with resync, the UUID that identifies this full reread. It is required: keep "
                 "it before submitting, then reuse it after a lost response to ask for the "
-                "same resync, not another one. If Studio persists it at the spend gate, the "
+                "same resync, not another one. If Studio persists it at the size gate, the "
                 "receipt prints mr-data run --confirm-held RUN_ID for that exact run; a "
                 "legacy sample-first receipt confirms its preview before its linked full can "
                 "be released"
@@ -1607,8 +1607,8 @@ def reschedule(
 
     ⚠ THIS IS WHY IT EXISTS RATHER THAN A SECOND ``promote``. A second promote on a live table is
     an idempotent replay that ignores the new cadence, so the only way to move a schedule used to
-    be demote plus promote -- which resets the table's bookkeeping and dispatches a paid catch-up
-    refresh. Neither is anything a person asking for "make it hourly" wanted to buy.
+    be demote plus promote -- which resets the table's bookkeeping and dispatches an unwanted
+    catch-up refresh. Neither is anything a person asking for "make it hourly" wanted.
 
     ⚠ READ BACK BEFORE WRITING. The version this write is fenced against is the one just read, so
     a schedule somebody else moved in between is a refusal rather than a silent overwrite.
@@ -1892,8 +1892,8 @@ def _resync_held_for_confirmation(
                 "release_full_command": release_full_command(full_run_id),
                 "full_watch_command": f"mr-data watch {full_run_id}",
                 "note": (
-                    "Studio persisted a preview for this full resync and is waiting for the "
-                    "projected spend to be confirmed. Confirm the preview command above; after "
+                    "Studio persisted a preview for this full resync and is waiting for its "
+                    "projected size to be confirmed. Confirm the preview command above; after "
                     "the preview succeeds, use the separate full-release command. The full is "
                     "not running yet. Reuse the same request id after a lost response."
                 ),
@@ -1904,7 +1904,7 @@ def _resync_held_for_confirmation(
             {
                 "run_id": held_id,
                 "note": (
-                    "Studio persisted this full resync and is waiting for the projected spend to "
+                    "Studio persisted this full resync and is waiting for its projected size to "
                     "be confirmed. Confirm the exact command above; the request id remains the "
                     "retry coordinate after a lost response."
                 ),