RESERVE v1.2.2: Opening the Official Workflow Catalog

RESERVE v1.2.2 opens the first public window into the official RESERVE workflow catalog.

The previous release, v1.2.1, established an important architectural boundary: the official reserve-workflows collection would live separately from local workflows and examples, and the CLI would access that collection through the RESERVE workflow API rather than depending directly on GitHub, object storage, or another distribution mechanism.

v1.2.2 puts that boundary to work

For the first time, RESERVE can browse the official workflow catalog and retrieve versioned workflow definitions through the permanent API at:

https://api.reservecli.dev/v1

This is intentionally a read-only preview.

RESERVE does not install remote workflows in v1.2.2. It does not publish them, update them, authenticate private repositories, or execute downloaded pipeline content.

The goal of this release is narrower: make the official catalog visible through the CLI, prove the API boundary, and establish a foundation that later releases can build on without weakening the local-first workflow model.

Browsing the Official Catalog

The most visible addition is:

reserve workflow browse

This command lets users inspect the official workflow catalog directly from RESERVE.

The complete catalog can be browsed from the CLI, or the results can be narrowed to a particular collection.

Catalog output follows RESERVE’s existing output conventions. The normal command-line experience uses a readable table, while JSON output is available for tools, agents, scripts, and other programmatic consumers.

This is the first point at which the reserve-workflows catalog becomes something an installed RESERVE client can discover rather than merely an architectural concept.

In v1.2.1, the official repository had a name and an API boundary.

In v1.2.2, that boundary has something useful on the other side.

Retrieving an Official Workflow

Browsing tells you what exists. The second new command lets you inspect the workflow itself:

reserve workflow get [version]

RESERVE can retrieve an official workflow definition from the API, including a specific version when requested.

The default output is the raw workflow YAML.

That choice is deliberate. A workflow is ultimately a portable document, and when a user asks RESERVE to retrieve one, the most useful default is the document itself rather than an additional presentation layer around it.

For programmatic consumers, JSON envelopes are also supported.

Together, browse and get provide the first complete read path from the RESERVE CLI into the official workflow catalog:

reserve workflow browse

Find a workflow.

reserve workflow get ...

Retrieve its definition and then inspect it. Nothing is installed. Opening the door to this future ecosystem is a big thing and v1.2.2 deliberately takes a small step.

The preview does not include:

• remote workflow installation or updates;
• workflow publishing;
• repository management;
• private repository authentication;
• ratings or search;
• remote execution;
• user enrollment.

The catalog is available for inspection, but the CLI does not turn retrieved content into executable behavior. This keeps the new network boundary small enough to reason about. A remote workflow definition can be useful without automatically being trusted. RESERVE v1.2.2 treats those as separate concerns.

Retrieval Is Not Execution

That distinction is especially important for pipeline workflows.

RESERVE v1.2.2 never executes workflow pipeline content.

workflow render 

does not invoke Bash or another shell. Rendered pipeline stages remain descriptive output intended for operator or agent review.

They should not be interpreted as a promise that arbitrary pipeline content is portable, deterministic, or safe to execute across platforms. From a security perspective, this is critical. Repository-style references are also constrained so that they cannot traverse or escape the configured workflow root, including through symlinks. These restrictions are not temporary obstacles to work around. They reflect the security model RESERVE is trying to preserve as workflows become increasingly shareable.

Execution may come later, but only after its semantics are defined well enough to make it secure, deterministic, and cross-platform. Until then, remote workflow discovery and remote workflow execution remain intentionally separate capabilities.

# Browse the official workflow catalog
reserve workflow browse

# Browse one collection
reserve workflow browse inflation

# Retrieve the latest CPI workflow
reserve workflow get inflation cpi-history

# Retrieve a specific immutable version
reserve workflow get inflation cpi-history 1.0.0

# Retrieve workflow metadata as JSON
reserve workflow get inflation cpi-history 1.0.0 --format json

# Browse the official workflow catalog
reserve workflow browse

# Browse one collection
reserve workflow browse inflation

# Retrieve the latest CPI workflow
reserve workflow get inflation cpi-history

# Retrieve a specific immutable version
reserve workflow get inflation cpi-history 1.0.0

# Retrieve workflow metadata as JSON
reserve workflow get inflation cpi-history 1.0.0 --format json

The API Is the Contract

One of the most important parts of v1.2.2 may be something users never have to think about.

Official workflow reads go through:

https://api.reservecli.dev/v1

The CLI does not expose GitHub, R2, or another storage provider as the repository contract.

That follows directly from the architecture introduced in v1.2.1.

The official workflow collection may be authored in one place, indexed somewhere else, and distributed through infrastructure that changes over time. None of those choices should require users to learn a new workflow model or force the CLI to encode a particular hosting provider’s repository layout.

The RESERVE API is the stable boundary.

v1.2.2 includes typed internal registry client support for catalog, collection, and artifact reads so that this separation exists in the implementation as well as in the documentation.

That gives future releases room to evolve the service without making storage infrastructure part of RESERVE’s public CLI contract.

A Preview of a Larger Service Boundary

The API in v1.2.2 is deliberately public and read-only.

It is not yet RESERVE’s authenticated service model.

In particular, the preview does not use a FRED API key as RESERVE authentication.

That distinction matters because a FRED API key identifies access to FRED. It should not quietly become a general-purpose credential for RESERVE services.

The next stage of the service boundary is planned around explicit RESERVE identity and authentication: verified-email enrollment, one-time FRED-key validation, RESERVE token issuance, and authenticated API enforcement.

Those capabilities remain v1.2.3 work.

Keeping them out of v1.2.2 lets this release answer a simpler question first:

Can RESERVE expose a stable, useful, provider-independent read path to the official workflow catalog?

Now it can.

Local Workflows Still Stay Local

The addition of an official catalog does not change the role of RESERVE’s existing local workflow system.

The distinction established in v1.2.1 remains:

examples/workflows/

Educational examples shipped with the source tree.

~/.reserve/workflows/personal/

User-created and locally managed workflows.

reserve-workflows/

The curated official workflow collection.

RESERVE workflow API

The distribution boundary through which the CLI accesses official workflow content.

v1.2.2 connects the final two pieces for read operations.

It does not collapse them into the local workflow model.

Users can discover and retrieve official workflows while local authoring remains its own concern. That separation gives RESERVE room to introduce installation and repository management deliberately rather than making every remote artifact implicitly local.

# List locally available workflows
reserve workflow list

# Show a normalized workflow document
reserve workflow show examples/workflows/simple-observation.yaml

# Inspect required runtime inputs
reserve workflow contract examples/workflows/parameterized-workflow.yaml

# Validate a workflow
reserve workflow validate examples/workflows/parameterized-workflow.yaml

# Render a copy-ready pipeline without executing it
reserve workflow render examples/workflows/parameterized-workflow.yaml 2015-01-01 2024-12-31

# List locally available workflows
reserve workflow list

# Show a normalized workflow document
reserve workflow show examples/workflows/simple-observation.yaml

# Inspect required runtime inputs
reserve workflow contract examples/workflows/parameterized-workflow.yaml

# Validate a workflow
reserve workflow validate examples/workflows/parameterized-workflow.yaml

# Render a copy-ready pipeline without executing it
reserve workflow render examples/workflows/parameterized-workflow.yaml 2015-01-01 2024-12-31

Designed for People and Tools

The new commands also continue a pattern that is becoming increasingly important for RESERVE: CLI output should work for both human operators and programmatic consumers.

Catalog browsing supports the familiar table view for interactive use and JSON for structured consumption.

Workflow retrieval defaults to raw YAML because that is the natural representation for a workflow definition, while JSON envelopes are available when metadata and structured integration matter.

This makes the preview useful beyond an interactive terminal.

An operator can browse the catalog.

A script can consume the catalog as JSON.

An agent can retrieve a workflow definition for inspection.

And in every case, retrieval remains retrieval. RESERVE does not silently turn inspection into execution.

Verified Before Release

The v1.2.2 release has been tested across the CLI and internal packages.

make test passes, as does:

go test ./cmd ./internal/… ./tests

Registry client tests cover catalog reads, collection reads, versioned artifact retrieval, and bearer-header behavior.

go vet ./… also passes.

The release distribution build produces the expected platform archives and SHA256SUMS, with release documentation and manifests updated for v1.2.2.

From Boundary to Interface

v1.2.1 was about deciding where things belong.

v1.2.2 is about making one of those boundaries useful.

The official reserve-workflows collection is no longer only a future repository described by the architecture. It is now discoverable through the RESERVE CLI.

But the scope remains intentionally constrained.

• Browse.
• Retrieve.
• Inspect.
• Do not execute.
• Do not assume trust.
• Do not couple the CLI to the infrastructure behind the API.
• Those constraints give RESERVE a much stronger foundation for what comes next.

Future releases can add identity, authenticated access, installation, private repositories, publishing, and eventually carefully defined execution semantics on top of an API boundary that already exists and a catalog model that is already usable.

RESERVE v1.2.2 is the first public connection between the CLI and the official workflow ecosystem.

It opens the catalog without opening the door to everything at once.