rivet-cli 0.23.1

Rivet: PostgreSQL/MySQL/SQL Server/MongoDB → Parquet/CSV (local, S3, GCS, Azure). Crate name rivet-cli; binary rivet.
Documentation 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43

# CLI-surface coverage matrix — CROSS-COMMAND behavioural contracts, keyed on
# COMMAND (not engine/target). The 0.21.2 dogfood audit found the "wired into
# only SOME commands" class: a contract every inspect command must honour,
# implemented in only a subset — `state files`/`chunks`/`progression` accepted a
# typo'd -e SILENTLY (empty-state, exit 0) while `metrics`/`journal`/`reset`
# rejected it with the known-exports list. This ledger makes each contract ×
# command a cell, so a NEW inspect command (or a new flag on one) that skips the
# contract shows a RED cell instead of a silent field surprise.
#
# Cell = { test: <fn> } | { na: "<why the flag/contract does not apply here>" }
#      | { gap: "<why, ratcheted>" }. Same drift-guard as the sibling ledgers
# (tests/offline/chunking_matrix_guard.rs): every `test:` fn must exist under
# src/ or tests/, every scenario covers every column, gaps ratcheted to 0.
#
# `engines:` is the guard's generic column-axis field (a matrix keyed on engines,
# targets, OR — here — commands). None of these names is a SourceType/ExportTarget,
# so the generative engine/target-column guard does not apply to this ledger.
#
# Columns are the STATE-INSPECT commands that share these contracts. The
# EXECUTION commands (`run`/`check`/`doctor`/`plan`) live on a different axis
# (exit-code classification, ${param} placeholder resolution) and are tracked by
# their own tests + the `cli_*` rows in docs/fail-loud-matrix.yaml, not here.

engines: [metrics, journal, files, chunks, progression, loads]

scenarios:
  - id: unknown_export_rejected
    what: "a typo'd -e/--export → loud error naming the known exports, never a silent empty-state exit 0 (dogfood MED — the wired-into-only-some class: files/chunks/progression accepted an unknown name silently while metrics/journal/reset rejected it). Shared seam: src/pipeline/cli.rs::require_known_export."
    metrics:     { test: show_metrics_unknown_export_bails_with_known_names }
    journal:     { test: show_journal_unknown_export_bails_with_known_names }
    files:       { test: inspect_handlers_reject_an_unknown_export }
    chunks:      { test: inspect_handlers_reject_an_unknown_export }
    progression: { test: inspect_handlers_reject_an_unknown_export }
    loads:       { na: "state loads has no -e/--export — it scopes by --target, whose empty-vs-filter-miss contract is the zero_row_request_not_empty_state row below." }

  - id: zero_row_request_not_empty_state
    what: "--last 0 asks for ZERO rows — an empty result is then a zero-row request, NOT an empty ledger, so the 'no <X> recorded yet' text is suppressed (the --json path already returns []). (dogfood LOW: the two were conflated, so a --last 0 on a POPULATED ledger read as empty state.)"
    metrics:     { test: is_zero_row_request_only_for_last_zero }
    journal:     { test: is_zero_row_request_only_for_last_zero }
    files:       { test: is_zero_row_request_only_for_last_zero }
    chunks:      { na: "state chunks takes no --last — it shows one export's LATEST chunk run, not a bounded list, so there is no zero-row request to conflate." }
    progression: { na: "state progression takes no --last — it lists ALL committed/verified boundaries, not a bounded window." }
    loads:       { test: empty_loads_message_distinguishes_zero_request_and_filter_miss }