Configure and manage your workstation, your way.

Configuring a workstation is more than installing tools.

A workstation accumulates applications, command-line tools, runtimes, versions, configurations, files, services, and preferences. These resources may come from different origins, already exist before any management tool, and be distributed across distinct environments, such as Windows and WSL.

Reproducing or maintaining that environment is not just a matter of installing what is missing. It is necessary to understand what already exists, where it exists, how it was configured, and which changes can be made without overwriting decisions or resources that do not belong to the tool.

Rigset starts from this problem: allowing the user to describe how they want their workstation and bringing the current state closer to that desired state without treating the entire machine as something that can be changed freely.

Does the tool exist?

observation

Is it at the expected version?

state

Is it in the correct environment?

context

Has the configuration drifted?

drift

Who can change it?

authority

Has the result been proven?

evidence

The challenge is not to automate more changes. It is knowing which changes should happen — and which should not.

Manage state, not just run installations.

Rigset treats workstation configuration as a reconciliation process. The user defines the desired state, Rigset observes the current reality, and, from that context, builds an explicit plan to bring the two closer together.

That difference, however, is not enough to authorize changes. Planning also considers where each resource exists, what Rigset is permitted to manage, its compatibility, and the available evidence before deciding what can be done.

The result is a flow in which observing, planning, executing, and verifying are distinct stages — and no change should happen simply because a difference was found.

Before any mutation, Rigset produces a deterministic, explainable plan with the necessary actions, conflicts, privileges, risks, and relevant known effects.

Every mutating operation must have a non-mutating planning path.

Rigset executes only the approved changes. If the reality encountered during execution materially invalidates the plan, it does not improvise a different intent.

An operation is only considered complete after the resulting state is observed again. A command finishing successfully is not, by itself, proof that the desired result was achieved.

Observe automatically. Change deliberately.

Rigset manages what the user entrusts to it, not the entire machine.

A machine can contain more than one environment.

A workstation does not need to be treated as a single homogeneous environment. A Windows machine, for example, can run tools natively and also have different distributions in WSL, each with its own versions, configurations, providers, and state.

Rigset represents these contexts as independent Target Environments within the same Machine. This makes it possible to observe, evaluate, and manage each environment without assuming that the state found in one of them also applies to the others.

The same resource does not mean the same instance

For Rigset, Git is a Canonical Resource: the logical identity of the resource it knows. But each occurrence of that resource within a Target Environment is an independent Resource Instance.

CANONICAL RESOURCE + TARGET ENVIRONMENT = RESOURCE INSTANCE

Git on Windows ≠ Git on WSL Ubuntu

Same resource. Independent contexts and states.

Rigset first resolves where the resource should exist. Only then does it choose how that resource can be observed or managed in that environment.

1. The user wants Node.js
2. Which Target Environment?
3. WSL Ubuntu
4. Which strategy/provider is valid here?

Finding a difference does not mean having permission to fix it.

Rigset can discover software, configurations, and differences between the current and desired state without assuming that those resources belong to it.

Detecting a resource does not create ownership. Finding drift does not authorize overwriting a configuration. And removing something from Rigset’s configuration does not mean the corresponding software should be uninstalled.

Automation only proceeds when there is management authority compatible with the planned change and, when the action is consequential, explicit user consent.

• DETECTION≠OWNERSHIP
• CAPTURE≠ADOPTION
• MISSING≠PERMISSION TO REINSTALL
• DRIFT≠PERMISSION TO OVERWRITE
• UNMANAGE≠UNINSTALL
• DIAGNOSIS≠REMEDIATION AUTHORITY

Rigset manages only what has been entrusted to it

An already existing resource can be observed without being managed. For Rigset to assume responsibility over it, the user needs to perform an explicit adoption, preserving its origin and choosing which kinds of change will be authorized.

That authority can be limited. Allowing Rigset to manage a configuration, for example, does not automatically grant permission to install, update, or uninstall the resource.

Automation removes repetition, not consequential decisions.

Rigset does not assume that every change on the workstation can be reverted transactionally. When an operation fails partially, it preserves what actually happened, observes the current state again, and uses that reality to build the next safe plan.

Accurate recovery is more important than magical rollback.

Rigset’s essential operation is local-first. Observing the workstation does not authorize transmitting its data, and the Core does not depend on telemetry. In v1, telemetry is zero by default.

Local-first

Observation ≠ Transmission

Core telemetry dependency

None

v1 telemetry

Zero by default

A small catalog to prove different problems.

Rigset’s v1 does not aim to support as many tools as possible. The initial catalog is deliberately small to validate, end to end, the Core’s most important properties.

Git, Node.js, and VS Code with extensions were chosen as Reference Resources because they present different management problems. Together, they exercise reconciliation, ownership, versions, PATH, multiple environments, desktop applications, and child resources without requiring a broad catalog before those abstractions have been proven.

Desktop app
├ CLI
└ Extensions
   ├ declared
   ├ missing
   └ external → preserve

Depth before breadth

Each catalog resource should expose only capabilities it actually has. Core abstractions should emerge from the differences found in these concrete cases — not from universal interfaces created in advance for hypothetical resources.

Support is demonstrated, not presumed.

Development will be done in vertical slices. Each slice starts with a claim about Rigset’s behavior, defines what evidence is needed to prove it, and implements only what is necessary to produce that proof.

Planned in depth. Not yet implemented.

Rigset does not yet have a functional implementation. The work so far has focused on defining the product, modeling the domain, establishing the security limits, and designing an implementation and validation strategy before starting the Core.

These definitions form the initial contract of v1, but some technical decisions remain deliberately open and will need to be resolved with evidence during implementation.

Configure and manage your workstation, your way.