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

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

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: mostlyright-data
-Version: 0.28.1
+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.28.1 → 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.28.1 → mostlyright_data-0.29.1}/pyproject.toml

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

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

@@ -46,6 +46,14 @@ references. Load the reference for the current stage only, not the entire librar
 5. State the selected sources, joins, coverage and material limitations. Ask for a decision only
    if existing authorization does not cover it. Read the
    [recipe reference](references/5-draft-one-recipe-document-one-call.md) before authoring fields.
+   For newly authored tables, read [search preparation](references/preparing-table-search.md).
+   Check availability with `mr-data search inspect --recipe RECIPE.json --json`; when supported,
+   propose/validate and add explicit `table.search` intent before registration. A brief that does
+   not mention search treats it as optional while the deployment lacks this capability; when
+   supported, default search intent remains. Follow the reference's fallback and decision-note
+   rules. If semantic search or JEV interpretation into filters/sorts is explicitly required,
+   do not register or queue a recipe that omits it; report the capability limit and wait.
+   Do not add search to existing recipes or rebuild existing datasets without an explicit request.
    Bind `dataset.id`, describe columns, declare checks and units, and register with
    `mr-data recipe RECIPE.json --json`. Repair all lint findings before queuing work.
    The server returns the recipe digest; do not compute or invent it.
@@ -70,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
 
@@ -133,7 +144,11 @@ merely to obtain a green run. Read [recovery details](references/agent-protocol.
    repair, which is why the decision belongs in step 5. A table left not refresh-ready never
    refreshes unless it declares `rebuild`; it does not become ready later.
    Download and verify artifacts when the user requested bytes.
-10. Report rows and coverage actually verified, checks, limitations and the stable dataset link.
+10. For new tables with search intent, inspect search readiness and test meaningful queries against
+    the observed version as [search preparation](references/preparing-table-search.md) describes.
+    Search preparation runs independently: pending or failed indexing never means the data build
+    failed, and declared metadata alone never proves observed search quality.
+    Report rows and coverage actually verified, checks, limitations and the stable dataset link.
     Read [delivery](references/9-present-only-what-survived-inspection-with-caveats.md) for details.
 
 ## Source-specific references
@@ -151,6 +166,7 @@ merely to obtain a green run. Read [recovery details](references/agent-protocol.
 | How each source continues, `rebuild`, and the cost of a refresh | [Making a table incremental](references/making-a-table-incremental.md) |
 | Refresh cadence | [Promotion and cadence](references/promote.md) |
 | Dataset notes and evidence blocks | [Decision records](references/writing-a-decision-record.md) |
+| Search configuration, example queries and readiness | [Search preparation](references/preparing-table-search.md) |
 | Exact schemas and worked recipes | [Reference index](references/reference-pages.md) |
 
 ## Needs Studio 4.14

{mostlyright_data-0.28.1 → 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.28.1 → 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.28.1 → 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.28.1 → 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.28.1 → 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.28.1 → 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.28.1 → 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
 
@@ -122,3 +122,10 @@ performs. Most of the survivors take a run identifier where the deleted local tw
 a hosted build has no folder, and the run identifier is what the submission printed and what the
 dashboard address contains. The deleted names and their replacements are written down only in the
 Harness repository's own `docs/HOSTED-PARITY.md`, which is not installed beside this document.
+
+## Search preparation
+
+`mr-data search <verb>` prepares and tests search on new opted-in tables. See
+[search preparation](preparing-table-search.md) and `mr-data search --help` for the supported
+operations. `inspect`, `propose` and `validate` accept `--recipe FILE` before registration; these
+report declared schema only. Index work runs in Studio and does not hold up data publication.

{mostlyright_data-0.28.1 → 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.28.1 → 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.1/skills/mr-data-build/references/preparing-table-search.md

@@ -0,0 +1,143 @@
+# Prepare search for a newly authored table
+
+Use `mr-data search --help` and the relevant verb's help. These tools call Studio; no embedding
+model, database, index or workload credential is installed on the agent's machine.
+
+## Before registration: declared intent
+
+For each new table, describe searchable text, exact categorical aliases and meaningful sort terms
+using the table's purpose, column descriptions and source evidence. First check the deployed
+recipe authoring capability with a recipe-target request, before adding `table.search`:
+
+```sh
+mr-data search inspect --recipe recipe.json --json
+```
+
+Local CLI help describes installed commands; it does not prove the deployed server serves them.
+For the recipe-target probe above, read JSON refusals from stderr: `schema_version` is
+`mr-data-error.v1`, `code` is the typed discriminator, and `error` is the detail. There is no
+public `http_status` field in that envelope. Treat `code: THIN_NOT_FOUND` as absent search
+registration support only when `error` begins exactly with
+`Studio has no such resource for /v4/search/recipe-inspection`; the CLI maps this route's HTTP 404
+that way. An explicit `code: THIN_SEARCH_CAPABILITY_UNAVAILABLE` also states a capability limit.
+A generic refusal or a rendered HTTP 405 alone is not this typed evidence; preserve the error
+and resolve it rather than guessing that the deployment lacks search.
+
+This rule applies only to `search inspect --recipe`, which needs no table ID. A missing table
+or version on a table-target request is not capability evidence. Neither are authorization
+failures (401/403), rate limits (429), timeouts, invalid response schemas, or invalid recipe
+diagnostics: resolve the actual error. Missing capability metadata is not evidence either.
+
+When the agreed brief does not mention search, treat search as optional only while this
+capability is unavailable. When supported, preserve the default of useful search intent for
+new tables. For an optional-search build on an unsupported deployment, omit `table.search`,
+keep the drafted search intent separately alongside the recipe, and record the capability
+limit in the dataset's Sources and decisions note and the matching chat message. Do not put
+this operational limitation into the dataset description, title, or topics. Preserve ordinary
+recipe checks and use supported data inspection tools. Do not emulate search locally, claim
+readiness, or automatically backfill later; adding that retained intent to the resulting table
+requires an explicit request.
+
+If the user explicitly requires semantic retrieval or JEV interpretation into filters/sorts,
+do not register or queue a build for any recipe that omits the required search. Report the
+capability limit and wait for backend support. Do not silently downgrade, including an interim
+baseline build. Independent source research and recipe drafting may continue.
+
+When inspection is supported, continue with propose and the validate step below; both require
+the deployed search authoring capability:
+
+```sh
+mr-data search propose --recipe recipe.json --json
+```
+
+The replies have `scope=declared_schema`. They show declarations, not observed vocabulary, rows,
+completeness, latency or index quality. Propose does not rewrite the file. Explicitly insert the
+returned spec into the relevant `table.search`, refine it, then validate the resulting recipe:
+
+```sh
+mr-data search validate --recipe recipe-with-search.json --json
+mr-data recipe recipe-with-search.json --json
+```
+
+Repair diagnostics before registration. Keep column descriptions and units in their normal recipe
+fields. Do not invent meanings such as “best” or “largest” when the brief does not identify a
+metric. Keep that wording unresolved, or define separate explicit aliases such as “highest revenue”
+and “most employees”. Never manufacture observed category values from documentation.
+
+The search spec uses `schema_version: table-search-spec.v1`, `keyword_columns`, `semantic_columns`,
+`aliases` (`phrase`, `column`, `operator`, `value`), `sort_aliases` (`phrase`, `column`, `direction`),
+and `planner` (`enabled`, `external_context_allowed`). Read current validation diagnostics rather
+than assuming that arbitrary operations, columns or model options are supported.
+
+Default to useful keyword columns plus exact filters and sorting. For new tables with descriptive
+prose, include useful descriptions/content/notes in `semantic_columns` for meaning-based retrieval.
+Keep it empty for identifiers, measurements, dates and tables without useful prose. Embeddings run
+locally on the hosted worker with a pinned multilingual model; they do not transmit private table
+text externally. Preparation is budgeted and asynchronous. Never claim readiness from a declaration.
+Semantic-only tables may use an empty `keyword_columns` list; their lexical capability stays
+`unavailable` even after semantic preparation succeeds.
+
+JEV is conditional. Exact identifiers, empty input, explicit plans, manual chip edits and already
+resolved simple filters do not need a planner call. Reuse interpretation when its table/spec
+coordinates still match. Only enable planner refinement where it adds meaning and deployed policy
+permits it. `external_context_allowed` must stay false unless the user or established workspace
+policy authorizes sending the relevant context externally; never infer consent from data-read
+permission. Source cells and model responses remain untrusted.
+Queries containing negation or explicit disjunction stay unresolved rather than becoming guessed
+hard predicates. Verify those cases with explicit supported filters.
+
+## Capability availability
+
+This CLI release supports inspect, propose, configure, validate, explain, estimate, build, status and cancel.
+Other preparation verbs return `THIN_SEARCH_CAPABILITY_UNAVAILABLE` until the hosted implementation
+is available. Treat that as a capability limit, never as successful preparation. Use the existing
+bounded `peek`/`query` tools for data verification meanwhile; do not emulate semantic search locally.
+
+## After a successful data build: observed evidence
+
+Read table and version IDs from receipts. Inspect with `--version VERSION_ID`. Use the existing
+bounded `peek`/`query` tools to verify real categorical values and search expectations. Preserve
+coverage/truncation and exact/sample scope; never report a sampled vocabulary as all categories.
+
+Run `search status TABLE_ID --version VERSION_ID`. Recipe completion prepares an index in the
+background for newly opted-in tables. When keyword fields are configured, lexical capability is
+`scan` while no compatible index is ready, or `indexed` when a complete compatible lexical index
+is verified. A complete generation can retain lexical `scan` when full keyword cells exceed the
+index representation budget; use the reported capability rather than inferring it from job success.
+Semantic capability becomes `ready` only with a verified compatible generation covering every
+source row. Preparation resumes across bounded immutable shards; the shard size is a resource
+bound, not a table population limit. Admission or preparation failures preserve the baseline and
+must not be described as partially ready. Data publication continues independently of preparation.
+Use the current estimate and job receipts for resource admission, progress and failure evidence.
+
+Meaning-based retrieval searches every prepared shard and returns a bounded relevance window.
+Approximate ranking does not imply an exhaustive similarity ordering or an exact matching count.
+Hard filters apply before ranking; explicit sorting retains its declared meaning. Keep these
+distinctions in verification notes rather than inferring corpus coverage from the result count.
+Do not claim readiness merely because the data build completed, or enqueue duplicate work.
+
+Use `search explain TABLE_ID --version VERSION_ID --query '...'` to check exact identity,
+category, numeric boundaries, sort meanings and ambiguous language. Keep a few meaningful checks
+in the dataset's verification notes with actual results from the hosted query tools. Search sample,
+values, cases, preview and evaluation commands are not available in this CLI release.
+
+## Draft revisions
+
+For authorized search-only work on a registered table, inspect, configure, validate and explain a
+draft revision using returned immutable coordinates. Configure requires `--version`, `--spec`
+and `--expected-revision`; `none` denotes an explicitly empty draft selection. Metadata exposes the
+selected draft coordinate for the next compare-and-swap. Configure creates a draft and does not
+activate an index or change data publication. Use an explicit `--idempotency-key` when retrying the
+same configuration; never change its body under that key.
+
+For explicitly requested preparation, `search build TABLE_ID --version VERSION_ID` queues the
+immutable opted-in version's own recipe configuration, then activates only complete compatible
+coverage automatically. It cannot build or activate a draft revision. Follow its receipt with
+`search status --job JOB_ID`; pending work exits with code 3. `search cancel JOB_ID` revokes search
+work only; it does not undo an already successful generation. Activation and rollback commands
+remain unavailable. Do not compute authoritative digests or bypass server resource admission. Preserve
+unresolved choices for the user; reinterpretation cannot silently replace manual edits or broaden
+an exact filter.
+
+This workflow opts in newly authored recipes only. It does not migrate old datasets, reauthor users'
+existing recipes, launch a full data rebuild or imply successful indexing of every table.

{mostlyright_data-0.28.1 → 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