Skip to content

v0.8.0 Release Notes

Release Date: 2026-11-01

VisionStudio v0.8.0 takes the CLI and the MCP server to the cloud. With --remote, the same commands and MCP tools that run against the local database run against a VisionStudio Cloud tenant, including the agent work loop. The release also adds registry rename for repositories that were renamed, makes units of work real transactions, and makes Windows a first-class platform.

Highlights

  • Remote mode — --remote runs the CLI and visionstudio mcp against a VisionStudio Cloud tenant, with cloud login, cloud logout, and cloud status to manage the credential.
  • registry rename — move a repository to a new ID together with everything that references it, in one transaction.
  • Transactional units of work — on the Dolt store, an error in a unit of work now rolls back everything it wrote.
  • Windows — process handling, credential writes, and opening the dashboard go through oscompat, so visionstudio has no OS-specific code, and the Windows test run passes.

Remote Mode

# Save a cloud API key (read from stdin, the environment, or a hidden prompt)
visionstudio cloud login --remote https://cloud.example.com/o/my-tenant --with-token < key.txt
visionstudio cloud status

# Run any command against the tenant
visionstudio rmi list --remote https://cloud.example.com/o/my-tenant
export VISIONSTUDIO_REMOTE_URL=https://cloud.example.com/o/my-tenant
visionstudio work ready

Every command that opens the store, including visionstudio mcp, runs against the tenant when a remote URL is given; without one, nothing changes. The tenant comes from --remote-tenant, $VISIONSTUDIO_REMOTE_TENANT, a URL ending in /o/<tenant>, or the tenant saved at login. The credential comes from $VISIONSTUDIO_REMOTE_TOKEN or the saved login. --remote cannot be combined with --dsn or --data-dir.

Credentials are kept per cloud URL in credentials.json, apart from config.json, written atomically and owner-only where the platform enforces file modes. cloud status verifies access and shows the credential's principal and the tenants it belongs to.

The client, pkg/remote, is a store.Store over the tenant API, so the service layer runs on it unchanged. It covers programs, initiatives, RMIs, phases, dependencies, assignments, delivery evidence, read-only releases and repositories, spec workflows and documents, and judge results. A method the cloud API does not serve yet returns ErrNotSupported instead of a made-up result. Programs embedding it can supply a bearer token, a custom transport, or a request signer. See the remote mode guide.

Renaming a Repository

When a repository is renamed on GitHub, its tracker records can follow it:

visionstudio registry rename github.com/org/old-name github.com/org/new-name --dry-run
visionstudio registry rename github.com/org/old-name github.com/org/new-name

The rename registers the new ID, or reuses an existing record. It repoints the RMIs, spec documents, initiative home repositories, repository dependencies, PRISM roadmaps, goals, and documents, and DevX reports, then archives the old record as superseded by the new one. RMI and initiative IDs keep their names. Releases stay on the old ID unless --move-releases is given, since they were published under that name. --dry-run reports what would move, and running the command again finishes a rename done partly by hand. On Dolt the rename is one commit. See Repositories.

Other Additions

  • phase update renames a phase or changes its theme. Only the flags given change.
  • rmi dep remove removes the dependency edge between two RMIs, which roadmap import never removes. Removing an edge that does not exist is an error.

Fixed

  • Units of work are transactions. On the Dolt store, UnitOfWork.Execute ran its function outside the transaction it opened, so an error did not roll back the function's writes. A registry rename inside a unit of work joins its transaction, and a Dolt commit or a nested unit of work inside one is refused.
  • Windows process checks. Checking whether a database or dashboard process was still running always answered yes on Windows, so db stop and app stop could not tell a stopped process from a running one.
  • Phase changes on import. Roadmap import reported a renamed phase or a changed theme as updated but never saved it.
  • Postgres over one connection. A store built with NewPostgresFromConn panicked on every update. Transactions now begin on the connection and keep its session settings.
  • Regenerated IR schemas. The devx schema had fallen behind its Go types.

Changed

  • prism-build is part of visionstudio. The execution IR types are defined from this module's own pkg/store, and prism-build is no longer a dependency. Its specifications are under docs/specs/prism-build.
  • The execution and repo-snapshot IR schemas gain the optional hidden, visibility, and origin properties.
  • The dashboard opens the browser through oscompat and now also opens it on the BSDs.

Documentation

  • A remote mode guide.
  • registry rename on the Repositories page.
  • Specifications for INIT-VISIONSTUDIO-012 (phase-level work locking) and INIT-VISIONSTUDIO-013 (stable work item IDs).

Dependencies

  • github.com/grokify/oscompat v0.5.0 → v0.13.0
  • github.com/grokify/gogit v0.13.1 → v0.15.1
  • github.com/grokify/prism-maturity v0.14.0 → v0.15.0
  • github.com/plexusone/omnidevx-core v0.3.0 → v0.4.1
  • github.com/plexusone/structured-evaluation v0.14.0 → v0.15.0
  • github.com/go-chi/chi/v5 v5.3.2 → v5.5.0
  • golang.org/x/term v0.47.0, new as a direct dependency for the hidden prompt of cloud login
  • github.com/ProductBuildersHQ/prism-build removed
  • Routine updates to indirect dependencies

Upgrading

No changes are needed for local use: without --remote, commands behave as before. Code that embeds the store and implements store.Store must add three methods: RenameRepository, DeleteDependency, and UpdatePhase.