Configure e gerencie sua workstation do seu jeito.

Configurar uma workstation é mais do que instalar ferramentas.

Uma workstation acumula aplicações, ferramentas de linha de comando, runtimes, versões, configurações, arquivos, serviços e preferências. Esses recursos podem ter origens diferentes, já existir antes de qualquer ferramenta de gerenciamento e estar distribuídos entre ambientes distintos, como Windows e WSL.

Reproduzir ou manter esse ambiente não é apenas uma questão de instalar o que está faltando. É preciso entender o que já existe, onde existe, como foi configurado e quais mudanças podem ser feitas sem sobrescrever decisões ou recursos que não pertencem à ferramenta.

O Rigset parte desse problema: permitir que o usuário descreva como quer sua workstation e aproximar o estado atual desse estado desejado sem tratar toda a máquina como algo que pode ser alterado livremente.

A ferramenta existe?

observação

Está na versão esperada?

estado

Está no ambiente correto?

contexto

A configuração divergiu?

drift

Quem pode alterá-la?

autoridade

O resultado foi comprovado?

evidência

O desafio não é automatizar mais mudanças. É saber quais mudanças devem acontecer — e quais não devem.

Gerenciar estado, não apenas executar instalações.

O Rigset trata a configuração da workstation como um processo de reconciliação. O usuário define o estado desejado, o Rigset observa a realidade atual e, a partir desse contexto, constrói um plano explícito para aproximar os dois.

Essa diferença, porém, não é suficiente para autorizar mudanças. O planejamento também considera onde cada recurso existe, o que o Rigset tem permissão para gerenciar, sua compatibilidade e as evidências disponíveis antes de decidir o que pode ser feito.

O resultado é um fluxo no qual observar, planejar, executar e verificar são etapas distintas — e nenhuma mudança deve acontecer simplesmente porque uma diferença foi encontrada.

Antes de qualquer mutação, o Rigset produz um plano determinístico e explicável com as ações necessárias, conflitos, privilégios, riscos e efeitos relevantes conhecidos.

Toda operação que muta precisa ter um caminho de planejamento que não muta.

O Rigset executa somente as mudanças aprovadas. Se a realidade encontrada durante a execução invalidar materialmente o plano, ele não improvisa uma intenção diferente.

Uma operação só é considerada concluída depois que o estado resultante é observado novamente. Um comando terminar com sucesso não é, por si só, prova de que o resultado desejado foi alcançado.

Observe automaticamente. Mude deliberadamente.

O Rigset gerencia o que o usuário lhe confia, não a máquina inteira.

Uma máquina pode conter mais de um ambiente.

Uma workstation não precisa ser tratada como um único ambiente homogêneo. Uma máquina Windows, por exemplo, pode executar ferramentas nativamente e também possuir diferentes distribuições no WSL, cada uma com suas próprias versões, configurações, providers e estado.

O Rigset representa esses contextos como Target Environments independentes dentro de uma mesma Machine. Isso permite observar, avaliar e gerenciar cada ambiente sem presumir que o estado encontrado em um deles também vale para os demais.

O mesmo recurso não significa a mesma instância

Para o Rigset, Git é um Canonical Resource: a identidade lógica do recurso que ele conhece. Mas cada ocorrência desse recurso dentro de um Target Environment é uma Resource Instance independente.

CANONICAL RESOURCE + TARGET ENVIRONMENT = RESOURCE INSTANCE

Git no Windows ≠ Git no WSL Ubuntu

Mesmo recurso. Contextos e estados independentes.

O Rigset resolve primeiro onde o recurso deve existir. Só depois escolhe como aquele recurso pode ser observado ou gerenciado naquele ambiente.

1. Usuário quer Node.js
2. Qual Target Environment?
3. WSL Ubuntu
4. Qual Provider é válido neste Target Environment?

Encontrar uma diferença não significa ter permissão para corrigi-la.

O Rigset pode descobrir software, configurações e diferenças entre o estado atual e o desejado sem assumir que esses recursos pertencem a ele.

Detectar um recurso não cria propriedade. Encontrar drift não autoriza sobrescrever uma configuração. E remover algo da configuração do Rigset não significa que o software correspondente deve ser desinstalado.

A automação só avança quando existe autoridade de gerenciamento compatível com a mudança planejada e, quando a ação é consequencial, consentimento explícito do usuário.

• DETECÇÃO≠PROPRIEDADE
• CAPTURA≠ADOÇÃO
• AUSÊNCIA≠PERMISSÃO PARA REINSTALAR
• DRIFT≠PERMISSÃO PARA SOBRESCREVER
• DEIXAR DE GERENCIAR≠DESINSTALAR
• DIAGNÓSTICO≠AUTORIDADE DE REMEDIAÇÃO

O Rigset gerencia somente o que lhe foi confiado

Um recurso já existente pode ser observado sem ser gerenciado. Para que o Rigset assuma responsabilidade sobre ele, o usuário precisa realizar uma adoção explícita, preservando sua origem e escolhendo quais tipos de mudança serão autorizados.

Essa autoridade pode ser limitada. Permitir que o Rigset gerencie uma configuração, por exemplo, não concede automaticamente permissão para instalar, atualizar ou desinstalar o recurso.

A automação remove repetição, não decisões consequenciais.

O Rigset não presume que toda mudança na workstation possa ser revertida transacionalmente. Quando uma operação falha parcialmente, ele preserva o que realmente aconteceu, observa novamente o estado atual e usa essa realidade para construir o próximo plano seguro.

Recuperação precisa é mais importante do que rollback mágico.

A operação essencial do Rigset é local-first. Observar a workstation não autoriza transmitir seus dados, e o Core não depende de telemetry. Na v1, telemetry é zero por padrão.

Local-first

Observação ≠ Transmissão

Dependência de telemetry no Core

Nenhuma

Telemetry na v1

Zero por padrão

Um catálogo pequeno para provar problemas diferentes.

A v1 do Rigset não busca suportar o maior número possível de ferramentas. O catálogo inicial é deliberadamente pequeno para validar, de ponta a ponta, as propriedades mais importantes do Core.

Git, Node.js e VS Code com extensões foram escolhidos como Reference Resources porque apresentam problemas diferentes de gerenciamento. Juntos, eles exercitam reconciliação, propriedade, versões, PATH, múltiplos ambientes, aplicações desktop e recursos filhos sem exigir um catálogo amplo antes que essas abstrações tenham sido comprovadas.

Aplicação desktop
├ CLI
└ Extensões
   ├ declaradas
   ├ ausentes
   └ externas → preservar

Profundidade antes de amplitude

Cada recurso do catálogo deve expor apenas capacidades que realmente possui. As abstrações do Core devem surgir das diferenças encontradas nesses casos concretos — não de interfaces universais criadas antecipadamente para recursos hipotéticos.

O suporte é demonstrado, não presumido.

O desenvolvimento será feito em fatias verticais. Cada fatia começa com uma alegação sobre o comportamento do Rigset, define qual evidência é necessária para comprová-la e implementa somente o necessário para produzir essa prova.

Planejado em profundidade. Ainda não implementado.

O Rigset ainda não possui uma implementação funcional. O trabalho até aqui concentrou-se em definir o produto, modelar o domínio, estabelecer os limites de segurança e desenhar uma estratégia de implementação e validação antes de iniciar o Core.

Essas definições formam o contrato inicial da v1, mas algumas decisões técnicas permanecem deliberadamente abertas e deverão ser resolvidas com evidência durante a implementação.

Configure e gerencie sua workstation do seu jeito.