Vision & Roadmap

The garden is the product. soft-fig exists to make that one object — the files that describe a machine — memorable, deployable, versioned, and safe. It does that through five pillars that share one config and one CLI, so you adopt the tool once instead of stitching four together. This page is the map of that ambition and an honest ledger of how much of it is real today.

The five pillars

Pillar	What it does	Instead of
Machine memory	The CLAUDE.md + concept-folder + snapshots schema as a first-class abstraction. This is the garden you live in.	ad-hoc notes and wikis
Templating + theming	Render source files into deployable configs with profile-scoped variables; secrets resolved at render time.	the toml-bombadil render side
Symlink deployment	A declarative source→target table that materializes a system from its sources.	bombadil link, GNU Stow
Integrated VCS	Linear, signed, intent-classified history over content-addressed ciphertext blobs and a queryable index.	git, for this use case
Vault	Encryption at rest, key management, secrets, and (planned) devices that can unlock each other.	LUKS + GPG + pass, partially

Machine memory is the pillar you spend your time in; the other four are what let the garden also deploy your dotfiles, keep its own history, and stay encrypted — without a second tool. The Keeper is the client that ties them together.

The Keeper

The Keeper is the user-facing client over the pillars: a per-device daemon that owns all writes and serves the FUSE mount, an MCP server so any local Claude session can propose garden writes through typed, convention-stamping verbs (reads stay native filesystem ops; Vault operations are deliberately never exposed to the model), a TUI for headless boxes, and a planned general GUI. It also owns cross-device sync: pairing your devices and moving encrypted history between them (built, and young).

Built vs. planned

soft-fig is a 1.0.0 alpha. The split below is kept deliberately honest; The Codebase → Status and the repository’s changelog are the detailed sources.

Built

• Vault. Whole-garden encryption at rest, selective secrets (whole-file seals and inline <vault> regions) with a user-initiated reveal, and a declared recovery policy: vault status reports it, and a recovery door can be removed only against a verified escrow copy. Not independently audited.
• VCS. A content-addressed ciphertext store with signed, intent-classified commits and a queryable index.
• Daemon, FUSE plaintext view, watcher. The engine that serves the garden and records every change.
• softfig onboard. First-run wizard that scaffolds a garden, born in the FUSE layout so no plaintext ever touches the root.
• Agent and human surfaces. The softfig-mcp write verbs (typed, convention stamping, including surgical edits, batching and leases for multiple writers) and the softfig-tui terminal UI.
• Cross-device sync. Device pairing with a confirmation code, a trust ring between your devices, a blind relay for off-LAN peers, zero-knowledge replica backup to a host that cannot decrypt it, and shared subtrees that let chosen parts of a garden be visible and writable on another device. Single owner per garden; no multi-master merging. Expect rough edges: two-device behavior is the least-exercised part of the system.
• Static deploy. softfig deploy materializes a declarative deploy.toml source-to-target table, dry-run and conflict-safe. See Deploy dotfiles.
• Growlight. The autonomous work loop, run by the growlightd fleet daemon across Claude Code or opencode backends, with a per-item queue, filed reports, and a TUI plus a feature-gated desktop console. A supporting tool, with its own section.

Planned, not built

• Template rendering and render-time secrets. MiniJinja rendering with profile-scoped variables, then secrets and posthooks at render time: the rest of the dotfile-manager pillar.
• Releases and packaging. Today you build from source. Planned: a release pipeline with prebuilt binaries and distro packages (AUR first).
• A general desktop GUI with parity to the TUI.
• Journey and recovery packs. Pre-crafted rules and milestones that run against your machine and verify the result.
• Guided mode. Machine-aware suggestions generated from the garden’s own knowledge of your system.
• A plugin system for the expert posture.

Smaller follow-ons, such as TPM-backed unlock, are tracked in the roadmap.

Where the design thinking lives

soft-fig’s implementation is the code repository. Its design, the per-pillar specs and the dated decision log, lives in the author’s own garden, the prototype this program generalizes. Those specs are thinking surfaces, not contracts: allowed to be incomplete and to contradict each other. The repository’s Design section explains the arrangement, and these docs surface the parts that are settled.