RESERVE v1.2.1 is a deliberately focused release.

After the substantial workflow foundation introduced in v1.2.0, this release takes the next practical step: establishing where workflows belong, clarifying the boundaries between different kinds of workflow repositories, and adding a small set of examples that make the existing workflow system easier to understand.

It is a plumbing and documentation release.

There are no new remote workflow commands in v1.2.1. No catalog browsing, installation, publishing, private repository authentication, or remote execution has been added. Instead, the release prepares the project for those capabilities without prematurely building them.

Examples Are Examples

RESERVE now includes four curated workflow examples under:

examples/workflows/
├── simple-observation.yaml
├── transform-pipeline.yaml
├── multi-series-analysis.yaml
├── parameterized-workflow.yaml
└── README.md

Together, these examples demonstrate several parts of the workflow model:

a simple single-series observation;
a transformation pipeline;
multi-series analysis;
runtime parameters and workflow contracts.

They are intentionally readable and modest. Their purpose is to show workflow syntax and CLI capabilities, not to serve as production-grade economic research.

The examples also establish an important rule:

examples/workflows/ is educational source-tree content. It is not the official RESERVE workflow catalog.

That distinction matters as the project grows. Examples may demonstrate simplified data, unusual features, or authoring patterns that do not belong in a curated public collection.

A Clearer Workflow Ecosystem

RESERVE workflows now have clearly defined homes:

examples/workflows/
    Educational examples shipped with the source tree.

~/.reserve/workflows/personal/
    User-created and locally installed workflows.

reserve-workflows/
    The future canonical, curated public workflow collection.

Private repositories/
    Future user- or organization-controlled collections.

RESERVE workflow API/
    The future distribution boundary between the CLI and repositories.

The official repository is named reserve-workflows.

That name now exists as a first-class internal repository descriptor rather than as a collection of hard-coded GitHub URLs or storage-specific assumptions. The CLI’s future repository operations can depend on the concept of an official repository while remaining independent of how that repository is authored, published, indexed, or stored.

GitHub may be the source of truth for the curated workflow collection. A cloud-based API and supporting distribution services may eventually provide access to that collection. Those implementation details should remain behind the RESERVE workflow API boundary.

The Official Repository Boundary

The internal official repository descriptor identifies:

id:       official
name:     reserve-workflows
type:     official
endpoint: https://api.reservecli.dev/v1

This does not yet enable remote workflow operations. It simply establishes the abstraction that future releases can build upon.

The initial API boundary is intentionally small:

GET /workflows
GET /workflows/{id}
GET /workflows/{id}/{version}

The exact service implementation can evolve later without requiring the CLI to understand GitHub repository layouts, static object paths, R2 buckets, or other infrastructure details.

What Users Will Notice

For most installed users, v1.2.1 is intentionally quiet.

The existing workflow commands continue to work as before:

reserve workflow create
reserve workflow list
reserve workflow show
reserve workflow edit
reserve workflow remove
reserve workflow validate
reserve workflow render
reserve workflow contract

The release does not add commands such as:

reserve workflow browse
reserve workflow install
reserve workflow update
reserve workflow publish

The new examples are shipped in the RESERVE source repository for developers and contributors. They are not automatically copied into a user’s ~/.reserve/workflows/ directory, and they are not presented as the official catalog.

That keeps the local-first behavior of RESERVE unchanged while giving workflow authors clearer reference material.

Go 1.27.1

RESERVE v1.2.1 also updates the supported release toolchain note to Go 1.27.1.

This is a small implementation detail, but documenting the toolchain used for the release improves reproducibility and gives users and maintainers a clearer baseline for future builds.

A Small Release With a Long-Term Purpose

The goal of v1.2.1 is not to make the workflow system larger. It is to make its boundaries harder to misunderstand.

Examples should remain examples.

Personal workflows should remain local.

The official catalog should have its own repository.

Private repositories should arrive only when their authentication and authorization model is ready.

And the CLI should communicate with repositories through a stable RESERVE abstraction rather than through infrastructure-specific knowledge.

That gives future releases room to add official workflow browsing and installation without turning the local workflow foundation into a tangle of special cases.

RESERVE v1.2.1 establishes the physical and architectural boundaries of that ecosystem, while keeping the user-facing CLI focused, local, and predictable.