Redacted excerpt; full evidence withheld.

$ cd <host-path> && ls -la && cat README.md 2>/dev/null | head -200
exit: 0
ts").pl()`.

Any object with `write` and `read` that keeps those promises is a `Warehouse`, and works with `FetchPlan.store(client, warehouse=...)`; `goto_fetch.testing.check_warehouse` checks one, and `MemoryWarehouse` stands in for tests. For another SQL database, implement `SqlTables` (open a transaction, describe a table, alter it, load a file, delete keys) and call `write_run`, which keeps the promises; the DuckDB and SQLite warehouses are built that way.

`FetchPlan` describes one fetch as data (the API, its auth, paging, tracking and where to store), which is what the explorer builds. `plan.records(client)` runs it, `plan.store(client)` runs it into its warehouse, and `plan.script()` writes a uv script that does the same, from the same description, with secrets read from environment variables.

The interfaces are Protocols: your pieces match their shape and never inherit from ours, and a type checker confirms they fit. `Paging`, `RetryPolicy`, `Login`, `ResolvesUrls` (an auth with URLs of its own), `Tracker` (what a run delivers: `apply`, `track`, `state`), `ReportsDeletions` (a tracker that knows wh
[excerpt truncated]