mostlyright-data 0.25.0__tar.gz → 0.25.1__tar.gz

{mostlyright_data-0.25.0 → mostlyright_data-0.25.1}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: mostlyright-data
-Version: 0.25.0
+Version: 0.25.1
 Summary: Mostly Right hosted CLI for reviewed datasets
 Project-URL: Homepage, https://mostlyright.md/
 Project-URL: Documentation, https://mostlyright.md/docs/guides/cli/

{mostlyright_data-0.25.0 → mostlyright_data-0.25.1}/pyproject.toml

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

{mostlyright_data-0.25.0 → mostlyright_data-0.25.1}/skills/mr-data-build/SKILL.md

@@ -94,8 +94,11 @@ merely to obtain a green run. Read [recovery details](references/agent-protocol.
    `bytes_fetched`, `rows_kept`, `rows_available`, `truncated` and the window -- where the run
    record folds all sources into four numbers. That is what each source ACTUALLY weighed and
    carried, and it is the evidence the refresh decision belongs on rather than the ceiling you
-   typed in `limits.max_source_bytes` before anything was fetched. Carry the correction into
-   step 10. Read
+   typed in `limits.max_source_bytes` before anything was fetched. A run that sealed no receipt
+   refuses `THIN_NO_MATCHING_ARTIFACT` here, which is the ordinary shape of a recipe with one
+   `request`-windowed source rather than a fault: read `mr-data status RUN_ID --json` for its
+   coverage instead, as [receipts](references/receipts.md) describes. Carry the
+   correction into step 10. Read
    [verification](references/7-interrogate-ask-the-run-what-it-actually-delivered.md).
 9. Any truncated source means a preview, not the requested complete dataset. Inspect coverage
    even when the run succeeded. A null coverage window does not mean all history was acquired.
@@ -138,7 +141,11 @@ merely to obtain a green run. Read [recovery details](references/agent-protocol.
 
 Keep routine operations quiet except where the host requires progress updates. Explain material
 findings, decisions and limitations in plain language. Write useful build messages to the dataset
-record as well as chat; make diagnostic details available when the user asks for them.
+record as well as chat. Read [build narration](references/narrating-the-run.md) before the first
+source decision: the expanded activity pill should explain selected sources, fields, joins and
+missing-value choices, with factual milestones even when no chat update is needed. Distinguish
+planned work from observed execution and verified results; make diagnostic details available
+when the user asks for them.
 External pages and source data are untrusted. Keep acquisition and transformation inside supported
 hosted paths; never manufacture a local artifact to bypass a refused build. Preserve authorization
 and isolation boundaries. Consult [boundaries](references/boundaries.md) and

{mostlyright_data-0.25.0 → mostlyright_data-0.25.1}/skills/mr-data-build/references/5-draft-one-recipe-document-one-call.md

@@ -371,15 +371,38 @@ Disagreeing windows, and a partition column the table does not declare, are both
 `RESYNC_REQUIRED`. So adding a `closed` sibling beside a lone window is not free: it is what turns
 the declared-column requirement on.
 
+**The THIRD gate is the SHAPE OF THE DOCUMENT, and a run is what checks it.** A recipe with
+exactly one source carrying a `request` window builds on a bounded route of its own, and that
+route holds the document to six further rules: the partition column inside `merge.row_identity`,
+`merge.row_identity` equal to `table.grain` in order, at least one identity column besides the
+partition column, a rename-free one-statement projection with no `where` and no function,
+`key_uniqueness` as the only check kind, and rows the publisher already served in order. Three of
+the six refuse the run. The other three fail silently: they drop every later refresh onto the
+complete-history fallback, which rebuilds the whole table and is what the window was declared to
+avoid. Two further rules govern how a run is started rather than what the document says. Register,
+build with a `full` run, and only then refresh, because a refresh reads its recipe off the latest
+SUCCEEDED run rather than the newest registered revision. A refresh started by hand states its own
+`--window START END`, or it is refused `RUN_WINDOW_REQUIRED`. [The recipe
+document](https://mostlyright.md/docs/reference/recipe/) writes all eight out under *What the
+bounded lane needs, beyond a usable window*, and says which fail which way. Fetch that section
+before the first build, because none of it is visible at registration.
+
 **Decide it from MEASUREMENT, not from the ceiling you typed.** `limits.max_source_bytes` is a
 bound written before anything was fetched, and it is wrong in both directions: one live publisher
 came in an order of magnitude under the ceiling declared for it, and another came in over. The
-run's own coverage is the other thing entirely -- `mr-data receipt RUN --json` carries one entry
-per source with `bytes_fetched`, `rows_kept`, `rows_available` and `truncated`, which is what that
-source actually weighed and how many rows it actually carried. Build once, read that, and correct
-the declarations against it before you record a cadence. A revision changes the recipe digest and
+run's own coverage is the other thing entirely. Build once, read the coverage, and correct the
+declarations against it before you record a cadence. A revision changes the recipe digest and
 costs one full resync, so the cheapest time to be right is here.
 
+**Where that coverage is depends on the route the build took.** An ordinary build seals a
+`receipt`, and `mr-data receipt RUN --json` carries one entry per source with `bytes_fetched`,
+`rows_kept`, `rows_available` and `truncated`. A build on the one-windowed-source bounded route
+seals no receipt at all, and `mr-data receipt` answers `THIN_NO_MATCHING_ARTIFACT` naming what it
+sealed instead. Read `mr-data status RUN --json` for that one: its `coverage` block carries `rows`,
+`bytes`, `window` and `truncated`. That block is Studio's fold over every source, so it is one
+source's own delivery only on a one-source recipe, which this route always is. Only
+`rows_available` is missing, and `truncated` still says whether a ceiling cut the source short.
+
 ### Say what each column is, and what it shows
 
 **Every column carries a `description`, and every column that measures a physical quantity carries

{mostlyright_data-0.25.0 → mostlyright_data-0.25.1}/skills/mr-data-build/references/7-interrogate-ask-the-run-what-it-actually-delivered.md

@@ -9,6 +9,11 @@ mr-data checks RUN --json                     # every check the recipe declared
 mr-data receipt RUN --json                    # sources, digests, coverage, snapshot members
 ```
 
+**The last of those answers `THIN_NO_MATCHING_ARTIFACT` on a run that sealed no receipt**, naming
+what it sealed instead. That is the ordinary shape of a recipe with one `request`-windowed source
+rather than a fault. Read `mr-data status RUN --json` for its coverage, as
+[receipts](receipts.md) describes.
+
 **`peek` reports the logical type the run sealed.** The preview artifact carries column names
 alone, so the type comes from the run's own `column_profile`. A null `type` means the run sealed no
 profile for that column rather than that the column is untyped; check the run reached `persist`.

{mostlyright_data-0.25.0 → mostlyright_data-0.25.1}/skills/mr-data-build/references/commands.md

@@ -23,7 +23,7 @@ gap rather than doing anything, and `export-hosted-candidate`, which is a backen
 | `mr-data receipt` | Print what one run recorded about how it was built: every source it fetched and what those bytes hashed to, the coverage it delivered, and the members of its raw snapshot. |
 | `mr-data checks` | Report how each check the recipe declared came out — the name, whether it passed, what it found. Exits non-zero when one did not pass. |
 | `mr-data note` | Write one cell of a run's decision record — a heading, a body, and the typed blocks that carry a source, a decision or a clarification onto the stage its phase names. The body comes from `--markdown-file FILE`, which is the form to use; standard input is read when no file is named and is refused when it is a terminal or empty. `--list` reads back what is written. |
-| `mr-data download` | Bring one run's artifacts back to this computer, each one's bytes checked against the digest Studio sealed them under. `--kind` selects out of `table_parquet`, `table_manifest`, `table_part`, `column_profile`, `preview`, `receipt` and `raw_snapshot`; without it, the shape the run sealed — one file and the receipt for a table written whole, or the manifest, EVERY part the version names and the receipt for a table made of parts, written as `table/manifest.json` beside `table/parts/<part_key>.parquet`. A version composed over several refreshes names parts earlier runs sealed; those are fetched too, and a part that cannot be fetched refuses by name rather than leaving a folder holding part of a table. |
+| `mr-data download` | Bring one run's artifacts back to this computer, each one's bytes checked against the digest Studio sealed them under. `--kind` selects out of `table_parquet`, `table_manifest`, `table_part`, `column_profile`, `preview`, `receipt` and `raw_snapshot`; without it, the shape the run sealed — one file and the receipt for a table written whole, or the manifest, EVERY part the version names and the receipt for a table made of parts, written as `table/manifest.json` beside `table/parts/<part_key>.parquet`. A version composed over several refreshes names parts earlier runs sealed; those are fetched too, and a part that cannot be fetched refuses by name rather than leaving a folder holding part of a table. A run that sealed no receipt brings back what it did seal, without one. |
 | `mr-data verify` | Hold one run's sealed table manifest against the parts it names, and report every disagreement. Without `--deep` it fetches the manifest alone; with `--deep` it fetches every part the run sealed and re-hashes it against the digest the manifest states. Exits non-zero when anything disagrees. |
 | `mr-data parts` | List one table version's parts — the identifier, the row count, the byte size and the recorded bounds of each — so a training loader can shard them across workers and read a table no single file should hold. `--version` names a version rather than the live one, and `--from`/`--to` keep only the parts a value range cannot rule out. Nothing is downloaded by listing them; the pattern is under [Reading a table that is made of parts](7-interrogate-ask-the-run-what-it-actually-delivered.md#reading-a-table-that-is-made-of-parts). |
 | `mr-data diff` | Compare two runs and say what changed. |
@@ -56,6 +56,31 @@ full reread; retain and reuse the caller-generated UUID after a lost response. A
 prints `mr-data run --confirm-held RUN_ID` for that exact run. A sample-first resync instead uses
 `--approve-full` only after its preview succeeds.
 
+**`--refresh` states its own range, and a run that starts one by hand must pass it.** `mr-data run
+--refresh` sends what it is given. A refresh of a recipe carrying a non-snapshot request window
+and no range is refused `RUN_WINDOW_REQUIRED` at the `transform` stage, before a source is fetched.
+Write `--window START END`, two UTC timestamps, start included and end excluded. Do not subtract
+the lookback yourself: each source's own `lookback_seconds` widens that start backwards and aligns
+it down to a whole UTC day, floored at `start_at`. The lookback never reaches the end, though the
+end is still aligned up to the next whole UTC day. `--backfill` takes
+the same pair, and the client refuses a backfill without it before anything is sent. Nothing local
+requires it on a refresh, so a refresh without it is accepted and dies in the run.
+
+**A refresh asked for before the source's period closes is refused `WINDOW_NOT_READY`.** This
+reaches only a source declaring `refresh_readiness`, which says the publisher serves a UTC day
+once that day is over. Studio floors `now` minus the declared lag to the UTC day, and a refresh
+whose range starts at or after that floor names no completed period. The run fails at once rather
+than being held. A refresh asked for from the dashboard in that state is recorded as a noop with
+the same code and starts no run. Only time clears it, and the refused run's range is frozen, so a
+new run is needed once the day is over. Report the code and wait rather than retrying or revising
+the recipe.
+
+**A refresh on the one-windowed-source bounded route seals no `receipt`.** `mr-data receipt`
+answers `THIN_NO_MATCHING_ARTIFACT` and names what the run did seal, which is the ordinary shape
+of that route rather than a fault. Read `mr-data status RUN_ID --json` instead: its `coverage`
+block carries `rows`, `bytes`, `window` and `truncated`, and on a one-source recipe that is that
+source's own delivery.
+
 `auth`, `login`, `whoami` and `clarify` are the same implementation in both profiles, and
 `clarify` alone reaches nothing at all. The other twenty-eight answer from Studio. Twelve only
 read: `status`, `runs`, `watch`, `peek`, `receipt`, `checks`, `download`, `verify`, `parts`,

{mostlyright_data-0.25.0 → mostlyright_data-0.25.1}/skills/mr-data-build/references/narrating-the-run.md

@@ -1,5 +1,32 @@
 ## Narrating the run
 
+### Content for the expanded activity pill
+
+Give the reader a short heading and enough detail to understand the actual dataset. At meaningful
+milestones, record what changed in their understanding:
+
+- Sources: which publisher and format supply which fields, with observed coverage and limitations.
+- Extraction: which fields were inspected and how they map to the requested columns.
+- Cleaning and joins: exact matching keys, conversions, row grain and missing-value choices,
+  including why a choice preserves the requested meaning.
+- Result: verified output rows and columns, checks and source coverage, retaining any truncation
+  qualification. A successful run alone does not prove the result meets the brief.
+
+Use the recipe for planned semantics, worker updates for reported execution, and status, checks,
+receipt and inspected output for completion claims. For example, before execution say “The recipe
+matches observations by station and date”; say “Matching observations by station and date” only
+when the worker reports that operation. A broad transform-stage update does not establish which
+join is executing. Do not infer all sources were fetched, checks passed, or work finished from a
+timer, progress count, quiet stream or agent activity. Worker progress is provisional reporting,
+not verified result evidence. Keep names and numbers grounded in this dataset rather than copying
+an example. Saving a table and making the dataset public are separate actions.
+
+Use a small number of substantive notes, not a second event stream. Update a settled decision's
+cell instead of repeatedly appending the same explanation. The UI renders worker progress itself;
+agent prose supplies the source choices and reasoning that progress cannot explain.
+
+### Dataset and run records
+
 There are two decision records and they are not interchangeable. A cell is the same document in
 both: one outcome-led heading, a markdown body, and typed blocks the Dataset page lays out as rows
 a reader can compare. What differs is which log it lands in and when that log closes.
@@ -7,7 +34,7 @@ a reader can compare. What differs is which log it lands in and when that log cl
 The rule that binds them to the chat is in the
 [User communication contract](user-communication-contract.md#user-communication-contract): every message is a cell, in the same
 words, at the same moment — the message's first sentence is the `--heading` and the whole message
-is the body.
+is the body. Factual page-only milestone cells are also useful; they do not require extra chat.
 
 **The DATASET's record is the primary one, and it never closes.**
 `mr-data dataset note DATASET_ID` writes it. The sources compared and refused, the grain argued
@@ -28,8 +55,10 @@ and what belongs there is what is true of that run alone: a clamp that truncated
 not pass, the exact revision this attempt tested. A run's narrative closes when the run reaches a
 terminal state, and an append after that answers `409 RUN_NARRATIVE_CLOSED` — a refusal no client
 check can soften, because only the backend knows the run has finished. A bounded run reaches its
-terminal state in seconds, so "while the run is going" means immediately after `mr-data run`
-returns the identifier, not after `status` says the run succeeded.
+terminal state in seconds, so append run-specific notes while it is known to be active. If an
+append races completion and receives `RUN_NARRATIVE_CLOSED`, write the useful finding to the
+dataset record with the run identified in its context. Post-run checks, coverage and delivery
+always belong in the dataset record; do not retry appending to a closed run.
 
 ```sh
 mr-data note --run RUN_ID --heading "The row ceiling stopped one source short" \

{mostlyright_data-0.25.0 → mostlyright_data-0.25.1}/skills/mr-data-build/references/receipts.md

@@ -23,6 +23,24 @@ A flag that cannot mean what it means locally is accepted and reported, never re
 digests, sources, timings and checks are already on the record it read. Read that key before
 repeating an argument that did nothing; only flags actually passed are reported.
 
+### Runs that seal no receipt
+
+A recipe with exactly one source carrying a request window builds on a bounded route of its own,
+and that route seals no `receipt` artifact. It is the route the first `full` build of such a recipe
+takes, and every refresh after it takes the same one. `mr-data receipt` answers
+`THIN_NO_MATCHING_ARTIFACT` and names what the run did seal, which is the raw source bundles, the
+source state index, the source inventory, an incremental proof, the column profile, the preview,
+the parts and the manifest. The run's own `receipt_digest` names that incremental proof rather than
+a receipt. This is not a failure and not a deployment problem, so do not retry it and do not report
+it as one.
+
+What the run delivered is not lost with the receipt. `mr-data status RUN_ID --json` carries the
+run record's `coverage` block: `rows`, `bytes`, `window` and `truncated`. Studio folds the
+worker's per-source array into that one block, and on this route the recipe has exactly one
+source, so the fold is that source's own numbers. `rows` is rows kept and `bytes` is bytes
+fetched. The one field only a receipt carries is `rows_available`, so a run on this route cannot
+say how many rows it left behind, only that `truncated` says there were some.
+
 ### Asking the table a question
 
 **In `mr-data query` the relation is always named `run_table`**, never the name the recipe gave the

{mostlyright_data-0.25.0 → mostlyright_data-0.25.1}/skills/mr-data-build/references/user-communication-contract.md

@@ -8,7 +8,7 @@ cursors, digests, receipts, retry mechanics or service boundaries in anything th
 Where the host requires periodic status, that cadence is the only exception: one concise
 outcome-oriented sentence about the dataset stage or an observed result, inventing no progress.
 
-**Speak at six boundaries and nowhere else.** Each is a stage above, and each is one message:
+**Send chat messages at these six boundaries.** Each is a stage above, and each is one message:
 
 | When | What it carries |
 | --- | --- |
@@ -28,9 +28,14 @@ message sent during a build is also a cell on the dataset's record: write it wit
 `mr-data dataset note`, taking the message's first sentence as the heading and the whole message as
 the body, in the same breath as sending it. The two are one act, not a message and a later summary
 of it. A person who joins by opening the page reads what the person in the chat read, and a person
-who scrolls the chat away still has it. The rule runs both ways: do not write a cell about work
-this document says to keep silent, and do not send a message you are not willing to write down. It
-licenses no extra update.
+who scrolls the chat away still has it.
+
+The expanded activity pill may also carry page-only milestone cells: selected sources and their
+fields, a settled join or missing-value decision, a material finding, or a verified result. Write
+one when the fact changes what a reader understands about the dataset; do not copy every worker
+tick or routine command into a cell. These notes need no matching chat message. Preparation,
+retries and transport mechanics remain silent on both surfaces. See
+[build narration](narrating-the-run.md) for the distinction between planned and observed work.
 
 **Activity is not narration.** Setting the dataset's activity is a routine, silent act like any
 other command: never a chat message and never a cell. The rule above governs what is said;

{mostlyright_data-0.25.0 → mostlyright_data-0.25.1}/skills/mr-data-build/references/writing-a-decision-record.md

@@ -28,8 +28,15 @@ themselves. Do not present a sequence of unlabeled paragraphs or default to a bu
 
 ### Agent presence lifecycle
 
-The floating pill represents only your active work. Start `dataset activity` immediately after creation, update the sentence when your task changes, and renew at least once a minute while you are actively working. The default lease is two minutes. Do not leave a detached heartbeat running after your turn ends. Worker ingestion progress has its own table surface and is not proof that you are working.
+The floating pill combines agent activity with worker build progress. Your activity lease
+represents only your active work. Start `dataset activity` immediately after creation, update the
+sentence when your task changes, and renew at least once a minute while you are actively working.
+The default lease is two minutes. Do not leave a detached heartbeat running after your turn ends.
+Worker progress can continue in the expanded pill after your lease ends; it is not proof that you
+are working. Do not renew your lease just to keep worker progress visible.
 
 When recovering, report what you are trying now; an earlier failed attempt belongs in the record. Before every final handoff, cancellation, or exhausted stop, report `--phase done` with a truthful final sentence (for example, “Dataset ready to explore” or “Stopped before the build completed”). Do this even when tables are not enabled. Only use `waiting_on_you` when a question is actually open — the brief at stage 2, the plan at stage 4, or the full build after a preview — and never under a delegation, which leaves nothing to wait on. A table going live does not finish your agent session.
 
-Stage 1 opened the dataset before research began; keep that same tab. Enable its optional Follow agent control for a watch-along experience; manual scrolling pauses it and must never be overridden.
+Stage 1 opened the dataset before research began; keep that same tab. Follow agent starts enabled
+for a watch-along experience; respect the viewer’s choice to pause or disable it. Manual scrolling
+pauses following and must never be overridden.

{mostlyright_data-0.25.0 → mostlyright_data-0.25.1}/src/mostlyright/data_harness/thin/v4.py

@@ -105,6 +105,13 @@ from mostlyright.data_harness.thin.transport import ThinLaneError
 #: same bounded projection. That is the deploy ordering this client now relies on instead of the
 #: legacy unfenced actions.
 #:
+#: ⚠ ``4.10.0`` ADDS THE BOUNDED RUN PROGRESS SNAPSHOT and ``4.10.1`` WIDENS STRICT INCREMENTAL
+#: REFRESH ADMISSION to safe multi-source direct-window plans. The snapshot is
+#: :data:`RUN_PROGRESS_PATH`, declared below with no caller yet; the widening admits refresh plans
+#: Studio previously refused rather than asking this client for a new document shape. The number
+#: rises here anyway, because every command body this client sends stamps it, so Studio's request
+#: grammar has to admit it before this package reaches that Studio.
+#:
 #: ⚠ AND THE WORKER SIDE OF THAT DELETION IS A DEPLOY ORDERING OF ITS OWN, in the OPPOSITE
 #: direction from the one above. ``run_execution_v4``'s job parser compares an EXACT field set, and
 #: ``source_collection_protocol``, ``source_collection`` and ``source_collection_inputs`` are no
@@ -112,8 +119,8 @@ from mostlyright.data_harness.thin.transport import ThinLaneError
 #: ``JOB_INVALID`` outright, which in production was every refresh a collection epoch was offered
 #: for rather than only the collection runs. This package must not reach a Studio older than the
 #: commit it pins; ``docs/V4-WORKER-PROTOCOL.md`` states it beside the layout's own ordering rule.
-PINNED_V4_OPENAPI_SOURCE_SHA256 = "6a5766a2f1dbf93f99582e65f91557e235101258b5167a26a24fc264243f61d8"
-PINNED_V4_CONTRACT_VERSION = "4.9.0"
+PINNED_V4_OPENAPI_SOURCE_SHA256 = "25c85955d2adbfac78bd13b9007baeebfae25ec08d9737e58d9db8e3afe46346"
+PINNED_V4_CONTRACT_VERSION = "4.10.1"
 
 # --------------------------------------------------------------------------------------------
 # The routes
@@ -195,6 +202,16 @@ GET_RUN_QUERY_PATH = "/v4/runs/{run_id}/query/{query_id}"
 #: ``GET`` -- the run's event stream, resumable by ``Last-Event-ID``.
 RUN_EVENTS_PATH = "/v4/runs/{run_id}/events"
 
+#: ``GET`` -- one bounded point-in-time snapshot of a run's progress: the latest non-null public
+#: progress facts folded across at most the 64 most recent durable PROGRESS events found in a
+#: bounded window of the run's log, with the sequence of the newest such event in that window. It
+#: reads the sealed record without mutating it or its ETag.
+#:
+#: ⚠ DECLARED WITH NO CALLER YET, on the same terms as :data:`LIST_TABLE_VERSIONS_PATH`. This
+#: client renders progress by following :data:`RUN_EVENTS_PATH` and folding the frames itself, so
+#: a command that wants one bounded snapshot rather than the stream lands against this constant.
+RUN_PROGRESS_PATH = "/v4/runs/{run_id}/progress"
+
 # Reader recovery uses Studio's versioned authority. These routes deliberately live beside the
 # other V4 wire constants so a client cannot silently turn transport canonicalisation into reader
 # validation.
@@ -394,6 +411,15 @@ RESCHEDULE_TABLE_PATH = "/v4/tables/{table_id}:reschedule"
 #: plan, while a resync is an operator-requested full run with its own idempotency coordinate.
 RESYNC_TABLE_PATH = "/v4/tables/{table_id}:resync"
 
+#: ``POST`` -- bind one explicitly selected stream recipe revision and digest to a live table under
+#: the promotion version fence, and remember that choice for later terminal-recorder recovery.
+#: Editor-only, and it never selects a recipe itself: a registered revision stays a candidate until
+#: a caller names it.
+#:
+#: ⚠ DECLARED WITH NO CALLER YET. This client registers recipe revisions but owns no command that
+#: rebinds the recipe a live recorder is running.
+REPAIR_TABLE_STREAMS_PATH = "/v4/tables/{table_id}:repair-streams"
+
 #: ``GET`` -- what each source carried on each refresh, newest first: the evidence the schedule is
 #: learned from, and the only place a person can see why it settled where it did.
 TABLE_CADENCE_OBSERVATIONS_PATH = "/v4/tables/{table_id}/cadence/observations"
@@ -453,6 +479,18 @@ STREAM_SUBSCRIPTION_RESUME_QUIESCENCE_PATH = (
     "/v4/stream/subscriptions/{subscription_id}:resume-quiescence"
 )
 
+#: ``POST`` -- end one subscription under that same exact-version fence. Studio terminalizes
+#: immediately when the fenced snapshot holds no lease, pending checkpoint or final-flush
+#: reservation, and otherwise requests cancellation for a later bounded observation to prove
+#: drained.
+#:
+#: ⚠ DECLARED WITH NO CALLER YET. The bounded quiescence lane in ``thin/stream_venue.py`` moves
+#: only pause and resume; a stop still goes through the unfenced
+#: :data:`STREAM_SUBSCRIPTION_STOP_PATH`, so this is the fenced stop that lane does not yet send.
+STREAM_SUBSCRIPTION_STOP_QUIESCENCE_PATH = (
+    "/v4/stream/subscriptions/{subscription_id}:stop-quiescence"
+)
+
 #: ``POST`` -- the three actions that move one subscription. One constant each, because this block
 #: is one constant per operation and a composed suffix would hide two of the three from a reviewer
 #: reading it beside the contract.
@@ -560,6 +598,7 @@ DECLARED_V4_PATHS: frozenset[str] = frozenset(
         RUN_QUERY_PATH,
         GET_RUN_QUERY_PATH,
         RUN_EVENTS_PATH,
+        RUN_PROGRESS_PATH,
         # ⚠ PROMOTED OUT OF `PENDING_V4_PATHS` IN THE COMMIT THAT STARTED CALLING THEM. Studio
         # shipped the whole promotion surface while this client was being written against the
         # contract for it, and the ledger in `tests/test_thin_v4_contract.py` went red naming all
@@ -575,6 +614,7 @@ DECLARED_V4_PATHS: frozenset[str] = frozenset(
         # a catch-up run; the observations listing is the evidence a learned schedule rests on.
         RESCHEDULE_TABLE_PATH,
         RESYNC_TABLE_PATH,
+        REPAIR_TABLE_STREAMS_PATH,
         TABLE_CADENCE_OBSERVATIONS_PATH,
         # ⚠ AND THE SAME AGAIN FOR THE CREDENTIAL REGISTRY, promoted the moment Studio served it.
         # The recorded metadata was already the shipped projection, member for member, with one
@@ -628,6 +668,7 @@ DECLARED_V4_PATHS: frozenset[str] = frozenset(
         STREAM_SUBSCRIPTION_PAUSE_QUIESCENCE_PATH,
         STREAM_SUBSCRIPTION_QUIESCENCE_PATH,
         STREAM_SUBSCRIPTION_RESUME_QUIESCENCE_PATH,
+        STREAM_SUBSCRIPTION_STOP_QUIESCENCE_PATH,
         STREAM_SUBSCRIPTION_PAUSE_PATH,
         STREAM_SUBSCRIPTION_RESUME_PATH,
         STREAM_SUBSCRIPTION_STOP_PATH,
@@ -895,10 +936,12 @@ __all__ = [
     "PIN_TABLE_PATH",
     "PROMOTE_TABLE_PATH",
     "RECIPE_READINESS_PATH",
+    "REPAIR_TABLE_STREAMS_PATH",
     "RESCHEDULE_TABLE_PATH",
     "RESYNC_TABLE_PATH",
     "RUN_ARTIFACTS_PATH",
     "RUN_EVENTS_PATH",
+    "RUN_PROGRESS_PATH",
     "RUN_QUERY_PATH",
     "SECRET_PATH",
     "SESSION_HANDOFF_PATH",
@@ -920,6 +963,7 @@ __all__ = [
     "STREAM_SUBSCRIPTION_RESUME_PATH",
     "STREAM_SUBSCRIPTION_RESUME_QUIESCENCE_PATH",
     "STREAM_SUBSCRIPTION_STOP_PATH",
+    "STREAM_SUBSCRIPTION_STOP_QUIESCENCE_PATH",
     "TABLE_CADENCE_OBSERVATIONS_PATH",
     "TABLE_VERSION_EXPORT_PATH",
     "TABLE_VERSION_MANIFEST_PATH",