What's new in Qorvyn

A free personal plan, and a public npm release path

• The personal plan is free and does not expire. It replaces the seven-day trial. Every account starts on it with up to three personal projects; teams and Enterprise workspaces have no such limit. The server decides, so changing the local clock or reinstalling changes nothing. Migration 0007 turns the trial status into free. qorvyn activate status shows your plan (Free or Pro) and your Enterprise workspaces.
• Public releases are possible, on purpose. Builds stay private (unpublishable) by default. npm run release:public builds the packages for npm and checks that they hold no sources, source maps, tests or keys. docs/publishing.md has the steps, in order, and scripts/verify-published.mjs checks the real install on each operating system.
• Server binaries under the organization: the six platform packages are now @factn-software/qorvyn-server-<os>-<cpu>, so the factn-software npm organization controls who can publish them. The main package stays qorvyn, so npm i qorvyn and npx qorvyn are unchanged.
• Docs and website describe the free plan, the online account check before protected commands (there is no offline grace period) and what it sends.

Every platform: macOS, Linux and Windows

• Windows works for agent runs (platforms):
  • Starting agent CLIs: Claude Code, Codex, Gemini CLI, OpenCode and az are .cmd shims on Windows. Qorvyn now starts their real target directly, with no shell, so prompts with quotes or newlines arrive as they are and cannot run anything. A batch file it cannot imitate safely is refused with a clear message.
  • Stopping runs: cancel and timeout end the whole process tree there (no process groups on Windows).
  • Environment: the system variables that Node, Git and most CLIs need are passed to agents. Secrets still never are.
• Windows ARM64 joins the Go server packages (qorvyn-server-win32-arm64), next to macOS (arm64, x64), Linux (x64, arm64) and Windows x64.
• Tested on all of them: the whole suite passes on macOS and on Linux (arm64, Docker node:22). A new manual workflow (.github/workflows/platforms.yml) runs the type check, unit tests and a smoke test on Linux x64 and arm64, macOS and Windows before a release. The smoke test (scripts/smoke.mjs) sets up a repository, checks that no file is added to it, searches, and runs a writing agent in its own worktree.

Account and licensing

• Online enforcement (operations): the server decides about accounts, the seven-day personal trial, three personal-project slots, device revocation, supported client versions and five-minute capability leases. A lease is consumed once, before the protected command runs. Rollout has an audit mode (records the decision, still allows) and an enforce mode. The documentation is plain about the limit: downloaded local code can still be inspected or patched, and enforcement protects Qorvyn's own services.
• Device keys on macOS live in the login Keychain; other systems keep the file-based key.

Other

• Official SDKs for Dart, .NET, Go, Java, Kotlin, Python, Rust and Swift, over one OpenAPI contract of the local runtime (sdks/, contracts/).
• Control plane: independent verifier tasks.

Fixed

• The team server's sign-in pages showed without styles since the Go server (0.28). Affected: the home page, device code, sign-in, email code, device approval, error and not-found pages. They sent only the page's text, without the document, title and stylesheet. Now they render whole again. See the incident note. The dashboard and the admin area were not affected.
• /favicon.ico now shows the Q mark (it answered 404).
• A new test checks every page and resource. It crawls every web page signed out, as a member and as the system admin. Each page must be a whole document with styles its security policy allows, and every stylesheet, script and image must load.
• Data governance: the documentation now lists what the control plane keeps on the server:
  • runs started through it, with their results (output text, commit references, check results, costs);
  • runners and budgets;
  • the audit chain. Runs you start on your own computer still never reach the server.

Enterprise moves out of Core; a tamper-evident audit log for everyone

• Enterprise is its own Go module, in the Qorvyn Enterprise repository (ADR 0008).
  • It builds qorvyn-server-ee, the Core server with Enterprise attached. Core no longer contains any Enterprise code.
  • qorvyn-server is Core only.
  • The deploy script builds the Enterprise server when its checkout sits next to Core.
  • Extensions attach through internal/ext: they add routes and migrations, and use the control plane's hooks. Those hooks can only tighten what Core decides, never loosen it.
• The audit log is a hash chain.
  • Each new entry is linked to the previous entry of its workspace by SHA-256 (QORVYN-AUDIT-1 in pkg/protocol).
  • GET /v1/workspaces/{ws}/audit/verify recomputes every link. It reports the first entry that was changed, removed or inserted outside the server.
  • Entries written before this version have no link and are counted, not checked.
• Budgets:
  • a task can reserve against several budgets at once: its run's, and those an extension adds such as a monthly workspace budget;
  • each attempt remembers the budgets it reserved against, so its result settles exactly those.
• Safer locking: every control-plane change takes its workspace's audit lock first, and the lease sweeper handles each expired lease on its own. Concurrent claims, reports and sweeps cannot deadlock.

Qorvyn Enterprise (the qorvyn-server-ee build), new

• Governance (license feature governance):
  • dedicated runner pools;
  • minimum trust for each privilege and for external effects;
  • workspace concurrency quotas;
  • required budgets;
  • four-eyes spending approval above a threshold: the owner sets the budget, and another admin approves;
  • a monthly workspace budget;
  • cost reports.
• Assurance levels:
  • *enhanced*: every task has acceptance checks;
  • *high*: on top of that, people approve every plan, agent tasks need managed runners, and anything with external effects comes after an approval.
• Compliance (license feature compliance):
  • signed checkpoints: each workspace's audit chain is signed daily or on demand;
  • anchoring: each checkpoint is written once to an Azure Blob container with a locked retention policy, and also sent to audit webhooks;
  • exportable proofs: they can be verified offline;
  • legal holds: retention removes nothing while a hold is active. A broken chain is never signed: it is recorded and reported.
• Existing licenses keep their features. Governance and compliance need a license that includes them.

The control plane and runners (milestones 1–2 of the v3 plan)

The team server can now plan and run work across computers (ADR 0007). Nothing changes until an admin enrolls a runner.

• Goals and plan versions:
  • every plan is validated: tasks, dependencies, no cycles, known privileges and trust levels;
  • every plan is classified: *low risk*, or *elevated* when it has privileges or external effects;
  • versions are immutable. An elevated plan always waits for an admin, even when a workspace approves low-risk plans automatically, and a runner can never approve one.
• Runs: a run executes one approved plan version and keeps every attempt of every task. The dashboard and CLI parts come later; the API is /v1/workspaces/{ws}/goals|plans|runs|tasks|budgets|runners|control.
• Separate rights:
  • propose a plan and start runs: members;
  • approve plans and decide on tasks: admins;
  • add runners: admins;
  • set budgets: the owner.
• Runners: qorvyn runner enroll <server> <token>, then qorvyn runner start in a repository.
  • Identity: each runner is its own key, enrolled with a one-time token, and is never a person's device. The admin sets its trust and labels; what the runner says about itself is only shown.
  • Leases: runners connect outbound and lease tasks. Each lease has an expiry and a fencing epoch, and a report from an old lease is refused.
  • Placement: trust is never downgraded, labels must match, each runner's slots and each run's concurrency hold, and workspaces never mix.
  • What a task can make a runner do: a task names an agent of the runner's project and instructions; it never carries a command. Checks are commands the runner's owner configures (--check tests="npm test"), privileged capabilities need the owner's --approve, and the project's guardrails apply as always.
• Failures:
  • provider limits and lost leases retry;
  • the same quality failure twice stops retrying;
  • a security failure pauses the run and keeps the evidence;
  • a task with external effects whose runner disappears is never retried blindly: an admin checks and chooses retry, done or failed.
• Completion is not acceptance: a task is verified only when its required artifacts are present and its checks passed on the same commit as the result. Evidence from another commit is refused.
• Budgets:
  • amounts are integer micro-units, reserved atomically before a task starts;
  • a run that cannot afford the next task pauses;
  • costs settle as providers report them, and unreported costs are counted as unknown, not zero.
• Planning documents: the target, an audit of what exists and the delivery plan.

npm install brings the Go server

• The Go server comes with the package: one small package per platform (macOS and Linux on Intel or ARM, Windows on Intel), installed automatically. npx qorvyn server start runs it, with no Go toolchain needed. QORVYN_SERVER_IMPL=ts still starts the old TypeScript server, until it is removed.
• Linking a project checks your access first: qorvyn team link proves you can read the repository, using the sign-in you already have on this computer:
  • GitHub: a saved token, or gh auth token;
  • GitLab: glab;
  • Azure DevOps: a saved token, or az account get-access-token;
  • Bitbucket: an app password. The server checks the proof with the provider, then records the project as checked "from the CLI". The token is used once and never stored. --no-check skips the check.
• Deployment: the one-time cutover script starts the App Service before deploying (a deploy that restarts a stopped site waits forever).

The team server is now Go on PostgreSQL

• One Go binary (qorvyn-server), on PostgreSQL (ADR 0006). It has every feature the TypeScript server had:
  • sign-in, devices and signed requests;
  • workspaces, members, invitations and ownership;
  • projects, sync with the hash chain, and live streams;
  • the web portal and the system admin area;
  • Git connections, the project dashboard relay, account keys and usage statistics.
• Measured: about 4× more signed requests per second than the Node server on the same machine, and a quarter of the memory.
• PostgreSQL in Azure (Flexible Server) with Microsoft Entra sign-in only: the server uses its managed identity and there is no database password. Point-in-time restore for 14 days.
• Enterprise built in, turned on by the license, as before:
  • policies;
  • audit export, retention and HMAC-signed webhooks (secrets now encrypted at rest);
  • SSO group roles, SCIM 2.0 and seats.
• Layered code with enforced rules: handlers → services → repositories; SQL only in internal/store (checked on every go test).
• Safer checks:
  • the access-token check for other Git hosts refuses private addresses at the moment it connects, so DNS rebinding cannot reach the server's network;
  • paths with .. are refused.
• Your data moves as it is: ids, signatures, the hash chain and sessions are kept. People stay signed in, and devices keep working.
• Tests: the whole suite runs against either server (QORVYN_TEST_SERVER=go npm test).
• For development: a local Docker PostgreSQL (npm run db:up), and npm run go:dev.

• Faster portal (found by load testing): workspace pages handle 5,700 requests a second instead of 223, with a median of 8 ms instead of 220 ms.
  • Dates are formatted with one shared formatter (making one per date cost about 1 ms each).
  • The overview checks whether an invitation is open instead of counting them all.
  • Members lists the newest 100 pending invitations, with the total.
• Database indexes for the lists every request uses: invitations, memberships, projects, devices, identities, ownership transfers, events by project, shared items and audit actions. Applied automatically on start (migration 9).
• Decided: the team server moves to Go on PostgreSQL (ADR 0006); this server stays in service until the Go one passes the same tests. Engineering standards are in docs/standards/.

Projects from your Git provider, with access checked

• Git connections: a new page for workspace admins. Connect GitHub (by installing the Qorvyn GitHub App and choosing its repositories), GitLab (gitlab.com or self-managed), Azure DevOps (Microsoft work accounts, every organization you are in) or Bitbucket. Each provider's own sign-in page is used, and Qorvyn gets read access to repository names and addresses only, never code.
• Add project → pick a repository: a searchable list of the repositories the connection can see. Adding one makes it a project with all its clone addresses (https and ssh). The provider is asked again when you add it, and repositories already in a project are marked.
• Any other Git host: Add project → Another Git host (Gitea, GitLab self-managed, Bitbucket Data Center, AWS CodeCommit…) checks once that an access token can read the repository, then forgets the token. Only public addresses are contacted.
• Typed addresses still work. Those projects show as *address only*; projects checked with a provider show where (for example *GitHub · acme/api*). Editing a project's addresses by hand drops the check.
• Security:
  • provider tokens are encrypted on the server (AES-256-GCM, QORVYN_SECRET_KEY), refreshed when they expire, and never shown, logged or audited;
  • a connection attempt counts only in the browser that started it, once, within 15 minutes;
  • a person's own sign-ins stop being used when they leave the workspace;
  • everything is in the audit log (git.connected, git.disconnected, project.linked).
• System admin: each workspace's page lists its Git connections (provider, account, who connected it, whether it still works), with Disconnect.
• Operators: register each provider's app once (docs/team-server.md → Git providers). provision.sh passes the settings through.

• Invite links: in Invite people, Create an invite link (member or viewer) to share in a chat. It appears once on the page with a Copy button, works once for 7 days, and is listed under pending invitations, where it can be revoked. Links never make admins.
• Links stay out of addresses: when the server cannot send email, the invitation links are shown on the page, no longer in the page address (which browser history and request logs keep).
• Copy buttons: the portal's only script, a small file from the same server (/ui/portal.js); everything else works without it.

The web portal, redesigned (one look with the dashboard)

• Same app as the dashboard: the portal uses the dashboard's own stylesheet, icons and sidebar. A workspace switcher at the top (every workspace you are in, Create workspace), and your account menu at the bottom (system admin, sign out). The system admin portal uses the same shell.
• Overview: a getting-started checklist for new workspaces (add a project, invite your team, connect a computer), the numbers that matter, projects with live status, recent runs.
• Members: Invite people by email (several at once, with a role); the email's link signs them in and joins them. Change roles and remove members (same rules as the CLI), and see and revoke pending invitations. Without email set up, the portal shows the link to pass on.
• Settings: rename the workspace, leave it, and (owner) delete it after typing its address.
• Details: page headings with the main action on the right, compact action menus, empty states that say what to do, focus outlines, phone layouts; every form in a modal.

• Portal: example repository addresses are written without a scheme (github.com/acme/app); any form is accepted (https, ssh or bare).

Tenant portal: projects

• Manage projects in the portal: workspace admins add a project (name and repository addresses), edit it or remove it. A teammate's clone with a matching address joins the project on npx qorvyn init.
• Each project at a glance: its repositories, whether a computer serves its dashboard (Open dashboard), and Connect a computer with the exact commands. Projects also show on the Overview.
• Every form opens in a modal: in the tenant portal and the super admin portal (roles, ownership, suspending, deleting, erasing, signing out). Destructive actions say what will happen and, where it matters, ask for the name to be typed.

• Agents & providers in the web portal: the page loads again. The portal may see which keys are set (names and status, never values); setting, importing or testing keys still happens only on the computer itself.

The full dashboard in the team's web portal

• Share a project's dashboard: npx qorvyn dashboard --share on a computer with the project. The portal's Projects page shows who is serving it and Open dashboard: the same dashboard as on your computer (workflows, runs, Describe a goal, approvals, agents, code search, notes, guardrails, analytics, live activity), answered by that computer over an outgoing connection.
• Same rules, checked by the server first: members of the workspace only; viewers look, members act, admins also change guardrails and project setup; anti-forgery header on every change; every action in the audit log (relay.action).
• Stays on the computer: keys and secrets, and provider set-up (which commands run). Results pass through the server and are not stored.
• Server: relay routes, larger bodies only for relayed answers, clean disconnect; the role table gains relay.serve, relay.act and relay.admin (Go conformance vectors updated).

• Super admin portal is easier to reach: super admins who sign in with Microsoft land on the system admin portal (/admin); opening /admin goes straight to the Microsoft sign-in. A super admin signed in with an email code sees a banner in the tenant portal with Sign in with Microsoft.

Free account

• Qorvyn is free with a free account. qorvyn activate signs in once (Microsoft or an email code) and saves a key signed by FACTn Software: valid 30 days, renewed automatically, with 14 days of grace offline. Commands ask for it; help, --version, activate, telemetry and uninstall always work. qorvyn activate status | remove.
• Checked on your computer against FACTn Software's public key: a key signed by anyone else, or edited, is refused.
• Account server: POST /v1/account/key (with QORVYN_ACCOUNT_SIGNING_KEY). Disabled or erased people get no new key. Super admins see each person's activation and an "Activated accounts" total. Schema 7.
• Privacy: the account is never linked to the anonymous usage statistics (docs/data-governance.md).

Distribution

• Customer package: npm run release builds the package people receive: minified bundles without comments, source maps, sources or tests, type definitions for the public API only, and a minified dashboard. Bundles carry the copyright notice.
• Free Use License: Core is free to use (including for commercial work) under a proprietary license that does not allow modifying, reverse engineering, redistributing or getting around license checks. Your code and ideas remain yours.

• Ownership and license: Qorvyn is owned by FACTn Software (Pvt) Ltd. Core is proprietary for now (all rights reserved, free during early access) and stays private until it is mature (ADR 0005); the plan to open it later is on hold. Contact: factnsoftware.com.

• Usage statistics: the dashboard reports which page was opened (the page's name only), as documented in docs/telemetry.md. It was left out of 0.21.0.

Anonymous usage statistics (opt-out)

• What: weekly counts of commands, dashboard pages, provider kinds, run outcomes, duration buckets and error categories, with version, OS and a random install id. Never code, file or repository names, prompts or outputs. Every field is listed in docs/telemetry.md.
• Your control: a one-time notice; qorvyn telemetry status | show | on | off; DO_NOT_TRACK=1 and QORVYN_TELEMETRY=0; always off in CI; organizations can turn it off for everyone with "telemetry": false in the workspace policy (Enterprise).
• Collector: --accept-telemetry on the operator's team server accepts only the documented report, never stores IP addresses, keeps reports 13 months and shows totals on the super admin Telemetry page. Optionally forwards each report to Azure Application Insights (QORVYN_TELEMETRY_APPINSIGHTS), from the server, so no user's address reaches Azure.

Data governance

• New document docs/data-governance.md: what is kept where, for how long, who can see it, how it is protected, and your rights.
• Erase a person (super admin): removes memberships, devices, sign-in identities and sessions, and anonymises the account.
• Super admin visits are recorded: opening a tenant's page is in the audit log (admin.tenant_viewed).
• Browser sessions and their IP addresses are deleted 30 days after they end. Schema 6 stores usage reports.

Dashboard: calmer page loading

• No progress bar, no dimmed old page: a page that loads quickly simply appears. A slower one shows a skeleton of its own layout (its real title, KPI row, cards and tables in the same places) that the content replaces without anything moving.
• No sideways jumps: the scrollbar's space is always kept, so the layout keeps its width when a page gets taller or shorter (dashboard and team server pages).
• Scrolling: opening another page starts at the top; refreshing the same page after an action keeps your place. Pages fade in without sliding.
• Sidebar: the Enterprise label fits inside the sidebar.

Team server: super admin area

• For the server's operator (/admin, or Super admin in the dashboard header). Super admins are listed in --super-admin / QORVYN_SUPER_ADMINS and must sign in with the identity provider (Microsoft), never an email code. To everyone else the area does not exist.
• Overview: tenants, people, devices, browser sessions, projects and shared changes; version, edition, plugins, sign-in methods, database size, backups and recent super admin actions.
• Tenants: every workspace with its owner, members, projects and runs. Per tenant: change roles, remove members, make someone owner, revoke invitations, remove projects, read all shared agents, workflows and knowledge, and its audit log. Suspend or resume a tenant (suspended: refused to everyone, devices and sync included), or delete it after typing its slug.
• People: everyone with their workspaces, devices and browser sessions. Disable or enable an account (disabled: no sign-in, sync or dashboard), sign someone out everywhere, or sign out one device.
• Audit: the whole server's log, searchable. Every super admin action needs the page's token and is recorded as admin.*.
• Plugins: a new onWorkspaceDeleted hook removes a plugin's own data with a deleted tenant.
• Database: schema 5 (disabled people, suspended tenants, how each browser session signed in).

Team server: web dashboard (read-only, first stage)

• Sign in with a browser: /signin (or Open the dashboard on the home page) uses the same Microsoft or email-code sign-in as devices and starts a browser session. Nothing to install.
• Pages per workspace: an overview (waiting for approval, running, failed, projects, members, shared items), runs with their steps and filters by status, projects and their repositories, members and roles, shared agents, workflows and knowledge, and the audit log for admins.
• Same rules as the CLI: every page checks membership and role; other workspaces are not revealed. Runs show only what people chose to share (names and states, never code or outputs).
• Sessions: a random cookie whose hash is stored, 7 days at most and ended after 24 hours idle; sign-out needs the page's own token. A person deactivated by their organization is signed out of every browser.
• Database: schema 4 adds browser sessions. The server copies its database before upgrading, as before.

Team server

• Sign-in codes by email: --email-login acs sends them with Azure Communication Services Email, authenticated by the server's managed identity (no keys stored). Settings: --acs-endpoint / QORVYN_ACS_ENDPOINT and --email-from / QORVYN_EMAIL_FROM. deploy/azure/provision.sh … email creates the service, an Azure-managed sending domain and the role.
• Clear when an email can't be sent: the page says so (with other ways to sign in), and the server log says why.
• Console mode is honest: with --email-login console the page no longer says "We sent a code"; it says the code is in the server's output.

Team server

• Home page: opening the team server's address in a browser no longer shows "Not found". It explains that people use the server from Qorvyn on their own computer, shows the exact qorvyn login --server … command for this server, offers I have a device code, and lists the version and sign-in methods. Unknown pages link back to it.
• Sign-in pages on phones: the card fits the screen instead of running past both edges.

Team server

• Copy before upgrading: before the server changes its database structure, it saves a copy next to the database (server-pre-v<new>-from-v<old>-<time>.sqlite).
• Backups reach Blob Storage: a nightly copy whose upload failed is retried every hour until it is uploaded. Error messages now say which step failed (the managed identity token, or the upload) and what to check.

Sync integrity

• Tamper-evident history: every shared change is linked to the one before it by a hash chain.
  • Each device verifies every link as it syncs, and stops with a clear integrity error if past changes were altered, removed or reordered, even by the server.
  • Existing servers link their earlier changes once at startup.
• Replica check with automatic repair: after each sync, the device compares a fingerprint of its shared items and the history with the server's. On any mismatch it rebuilds its copy automatically and verifies the whole history from the first change. Unsent changes are kept.
• Commands: qorvyn sync verify checks now; qorvyn sync rebuild re-downloads and re-verifies everything on demand.
• Resolving conflicts: the dashboard's Team page shows each conflict side by side, with Keep mine (published on top of the latest version) and Take theirs (the shared version stays and your local copy is updated). CLI: qorvyn sync resolve <event> mine|theirs.
• Integrity status: the Team page shows "Integrity verified" or the problem found, with Verify now and Rebuild from server.

• Team server on Azure App Service and other platforms:
  • QORVYN_SQLITE_JOURNAL=delete uses a database mode that is safe on network storage; run a single instance;
  • --allow-host / QORVYN_ALLOWED_HOSTS adds host names such as the platform's own address.
• Built-in server backups: --backup-dir / QORVYN_BACKUP_DIR makes a daily consistent copy and keeps 7. With QORVYN_BACKUP_BLOB_URL, each copy is also uploaded to Azure Blob Storage with the platform's managed identity, so no keys are stored.

• New brand: the Qorvyn Q is the dashboard logo and browser-tab icon, and appears on the team server's sign-in pages and in the README.
• Edition label: the dashboard and the sign-in pages show Core (open source) or Enterprise. Enterprise appears when the linked team server runs a licensed Qorvyn Enterprise, and the dashboard Q gets a shield badge.
• License: Qorvyn Core is licensed under Apache-2.0 (LICENSE, NOTICE), copyright Supun Wijegunawardhana.
• Deployment files: deploy/azure/ holds the systemd service, Caddy HTTPS proxy, VM setup and nightly backup scripts for running the team server.

• qorvyn team api <METHOD> /v1/... [--body json]: a signed request to any team-server route, for admin features of server plugins.
• qorvyn server start --oidc-trust-email: for your own organization directory (for example Microsoft Entra ID). People provisioned in advance are recognised on their first sign-in.
• New package exports: qorvyn/server and qorvyn/team-client, for embedding and testing.

Team server plugins

• Server extensions: qorvyn server start --plugin <module> (or QORVYN_SERVER_PLUGINS) loads extensions. A plugin can:
  • add routes for signed-in devices, or its own HTTP endpoints (for example SCIM);
  • check or refuse sign-ins (for example seat limits), and act after sign-in (for example group-to-role mapping);
  • receive every audit entry;
  • supply a workspace policy.
• Visibility and boundaries: /v1/health lists loaded plugins and their features. Plugins cannot replace core routes. The interface is exported as qorvyn/server-plugin.
• Microsoft Entra ID: sign-in also works when Entra sends the address as preferred_username. Identity-provider group ids reach plugins.

Organization policies, enforced on every device

• Fetched with each sync: a linked project receives its workspace's policy every time it syncs.
• Combined with the project's own guardrails:
  • denied capabilities, protected paths, never-index paths and protected branches are added together;
  • allowed providers are intersected;
  • the shortest time limit wins;
  • delivery steps the organization blocks stay blocked.
• Stricter only: a project can make limits stricter but never loosen the organization's. The Guardrails page shows organization limits as locked.

• The dashboard never freezes:
  • Checks that run a tool, such as provider versions and the git host sign-in, are cached for a minute and refreshed in the background.
  • The git host check starts when the dashboard starts.
  • Pushing and opening or merging pull requests no longer hold up other requests.
• Pages show right away: slow parts (the Delivery agent, model lists, a run's Changes panel) appear as skeletons and fill in.
• Visible progress:
  • a loading bar at the top while a page loads, with the current page dimmed instead of frozen;
  • any button whose action takes a moment shows a spinner;
  • pages fade in, and buttons respond when pressed.

• Get changes in my working folder: a run's changes become ordinary uncommitted edits on your branch. They show in VS Code Source Control to review and commit yourself. Switch to the run's branch checks it out instead. CLI: qorvyn workflows deliver <run> --apply | --switch.
• A GitHub account per project: with several accounts signed in to gh, choose one on the Agents page (Delivery agent). Pushes and pull requests use that account's token, and your active gh account is not switched.
• Clear access errors: GitHub's "Repository not found" now says which account was refused and how to fix it.
• Out-of-date dashboard detected: if Qorvyn is updated while the dashboard is running, the page asks you to restart it, instead of an action failing with an unclear error.

Deliver what a run changed

• Changes from this run on every run that changed code:
  • the branch, commits and files, and how to look at them;
  • Merge into your branch, Push & open pull request, Merge pull request and Discard.
• Agents still commit only to their own branch, and your working folder is never touched.
• Merge safety: a merge is refused while your checkout has uncommitted changes, and conflicts are found before anything is touched.
• CLI: qorvyn workflows deliver <run> [--merge | --push | --pr | --merge-pr | --discard].

Delivery agent: GitHub, GitLab, Azure DevOps, Bitbucket

• Detects the host from your remote. It opens and merges pull requests with gh, glab, az repos or the Bitbucket API. Any other host gets a link.
• It is not AI: it runs fixed, checked commands, and every action is audited.
• Access: your existing CLI login, or a dedicated token saved under Keys and given only to that host's CLI. The Agents page shows the account, its permissions and how to fix a missing one.

Delivery guardrails

• Allow or block each step: local merge, push, pull requests, merging pull requests.
• Protected branches are never merged into (default main, master, release/*).
• Only approved runs can be delivered: a run must finish with every human approval passed.
• After approval: do nothing, open a pull request, or merge automatically.

Live progress

• Describe a goal plans in the background. You see each step: understanding the goal, exploring the code (the files Claude Code or Codex reads and the searches it runs), designing the steps, and checking the plan.
• Keep working: close the dialog and a pill shows progress; a toast with Review plan appears when the plan is ready.
• Animated reveal: plans appear step by step, and the full task of each step can be expanded.
• Running steps show live what the agent is doing ("Reading …", "Running …") and how long it has been going. Agent run pages have a live Activity log.

Planning reuses your workflows

• The planner checks your saved workflows first and reuses one that fits, with your goal as its input.
• New plans are saved under a name you choose and become reusable. Saving the same steps twice keeps one copy.
• qorvyn do --new plans from scratch anyway, and --save-as <id> names the workflow.

Keys you can check before you rely on them

• Live status in the key dialog, also in the provider form, as you type the name:
  • saved in Qorvyn;
  • available to this dashboard now;
  • in your shell profile but not visible to the dashboard (it started before the key was set);
  • not set anywhere.
• Copy from your shell: one click (or qorvyn keys import <NAME>) copies a key from your shell profile into the Keychain. The value never passes through the browser.
• Guidance: a link to where to get the key (Anthropic, OpenAI, OpenRouter, Google AI Studio, Groq, Mistral, Cursor) and what it should start with.
• Paste mistakes fixed: export NAME=…, quotes, Bearer and spaces are removed. A warning appears when a key does not look like that provider's.
• Test: checks the pasted or saved key against the provider and shows the provider's own answer, e.g. "refused it (401: invalid api key)".
• CLI: qorvyn keys check <NAME> [--test].

Keys, managed in Qorvyn

• Set API keys for any provider in the app: under Agents & providers → Keys, inline when you add a chat API provider, or with qorvyn keys set <NAME>.
• Write-only: you can set, replace or remove a key, but nobody can read it back. It is never sent to the dashboard, never written to the audit log, and never passed on the command line.
• Stored in the macOS Keychain, or in an encrypted file on other systems.
• Given only where needed: only the provider that names a key receives it, for its own runs.

Choose a model per agent

• Each agent card has a Model picker with the provider's models:
  • Claude Code: aliases and model names;
  • Codex: its own model list;
  • chat APIs: the API's model list;
  • added command providers: a list or command you configure.
• Provider default is used when you don't choose. Switching provider resets the agent to that provider's default. From the CLI: qorvyn providers models <id>.

Dashboard

• One dialog everywhere: title bar with a close button, a scrolling body, and Cancel next to the main action. Destructive actions use a red button.
• Typed toasts: every action reports success, warning or error with an icon. Errors stay longer and can be dismissed.
• Layout: the Providers, Keys and Agents section headers are aligned with their buttons, and the mock provider card has a shorter title.

Add any provider

• Add provider, on Agents & providers or with qorvyn providers add, works with any coding agent or model.
  • Command providers: any CLI agent. Presets cover Cursor, Gemini CLI, Aider and OpenCode, or point it at your own command.
  • Chat API providers: Anthropic (Claude) or anything OpenAI-compatible, such as OpenAI, OpenRouter or a local Ollama.
• Safety for tools Qorvyn does not know:
  • every run happens in its own worktree;
  • changes are kept only when the agent may write, otherwise they are discarded and the run says so;
  • shell and network use is declared, and a run must accept what Qorvyn cannot switch off;
  • chat APIs never touch files.
• Keys: they are never stored. A provider names the environment variable that holds its key, and only the variables it names reach it.
• Everywhere: added providers apply to every project on this machine and work with agents, workflows, the planner and guardrails.

Also

• The provider cards explain what mock is: a stand-in with no AI, for trying workflows for free and for tests.
• An open dashboard tab now offers Reload when Qorvyn or the dashboard was updated, so you never look at an old page.

Project setup

• Qorvyn sets up each project itself. qorvyn init (or qorvyn setup) reads what the repository already has: instruction files, Claude Code agents, skills, commands, MCP servers and the stack.
• What it creates:
  • agents: your existing Claude Code agents, plus templates that fit the stack;
  • workflows that use your own reviewers;
  • knowledge notes from your instructions, citing file and line.
• Starts safe: everything starts read-only and nothing is written to the repository. --dry-run previews; --no-setup skips it during init.
• Your work is kept: re-running never overwrites your edits and never brings back what you removed.

Review and refine

• A new Project setup page lists what was found and what was created, with a "needs review" count in the menu and on the overview.
• For each item: Mark reviewed, Refine (the agent or workflow editor) or Remove. From the CLI: qorvyn setup review.
• Reviewing grants nothing. You give access separately, on each agent, when you decide to.

Guardrails you manage

• A new Guardrails page and qorvyn guardrails command manage five limits:
  • denied capabilities;
  • protected paths;
  • allowed providers;
  • maximum run time;
  • paths never read or indexed.
• Enforced by Qorvyn itself:
  • a run that changes a protected path is discarded;
  • other providers are blocked, and the planner keeps to the allowed ones;
  • a denied capability is never effective;
  • the time limit is capped.
• Every change is in the audit log. Approval of privileged capabilities on each run stays fixed.

Describe a goal

• "Describe a task" is now Describe a goal. You describe what you want, and the planner turns it into a workflow of steps, each with its own agent and task. qorvyn do "<goal>" is unchanged.

Project files, local and never committed

• Hand-written files: write agents and workflows as YAML in <project>/.qorvyn/agents/ and .qorvyn/workflows/.
• Loaded automatically: from the CLI and the dashboard. A changed file becomes the next version, unchanged files are skipped, and a broken file is reported with the reason and never blocks the others.
• Never a git change: qorvyn init lists /.qorvyn/ in .git/info/exclude, inside .git. The files never show as changes and are never committed.
• Grants nothing: an agent loaded from a file can only read until you grant more.
• Commands: qorvyn files status | load | export [--force]. The dashboard's Agents and Workflows pages show what loaded and any errors, and can export your current agents and workflows to files.

• Search everything (⌘K) fixed: the box spans the full width with no stray focus box.
• Search covers more: it always offers Search code for "…" and also finds runs and notes, not only pages, workflows and agents.
• No duplicate buttons: "Describe a task" and "Run a workflow" now live only in the top bar. Page headers keep actions specific to the page, such as "Build a workflow".
• Accurate activity feed: a plan is recorded only when it is saved, so the feed never links to a plan that does not exist.

Tasks without a template

• Describe a task; the planner designs the workflow. It picks the agents, the order, what runs in parallel and where you decide, then shows you the plan. Use qorvyn do "<task>" or Describe a task in the dashboard.
• Planners:
  • claude-code (default) or codex, read-only: the planner may read the code to ground the plan.
  • rules: free, instant, no AI.
• Validation: every plan is checked like a hand-written workflow. An invalid plan gets one retry with the exact error, then the rules planner takes over, and Qorvyn tells you.
• Safety: plans use your own agents first, otherwise built-in templates created read-only. Privileged steps still need approval, and any plan that changes files ends with a human approval.
• Reuse: planned workflows are saved, so you can run them again, edit them in the builder or share them.

Who does the work, from the CLI too

• --providers cc-codex | codex-cc | claude-code | codex | mock and --step-adapter step=adapter on qorvyn workflows run and qorvyn do.

Release notes in the app

• qorvyn changelog and a What's new page in the dashboard.

• Dashboard: workflow graphs scale to fit their card.

Full dashboard

• Live mode:
  • live activity feed and a Live indicator, including runs started from the terminal;
  • background refresh that never interrupts typing or an open dialog.
• Visual workflow builder:
  • inputs, agent and approval steps, and tasks with one-click references to inputs and earlier outputs;
  • dependencies, retries and a live graph preview;
  • start from a template as is or customise it; YAML editor, versions, archive, delete, share.
• New run:
  • choose who does the work: each agent's own provider, "Claude Code builds · Codex reviews", the reverse, one provider or mock;
  • or choose a provider per step, and give approvals up front.
• Run detail:
  • graph, timeline, and duration, tokens and cost per step;
  • tabs for Changes (coloured diffs), Activity, Handoffs, Reviews and Artifacts.
• Approvals page: with a count in the menu.
• Runs: filter by status, agent and provider.
• Agents & providers:
  • Verify live, and what each provider can enforce;
  • create agents from scratch or a template, edit as a form or YAML;
  • grant or revoke each capability with a switch; switch provider inline; clone, archive, delete.
• Analytics: 7–90 days, completion rate, durations, retries, human decisions, Claude Code vs Codex, tokens and cost, failure categories.
• Also: Notes & knowledge, code search by app, an audit log of every change, and the ⌘K palette.

Engine

• Per-step provider overrides and run-wide acceptance of provider limits.
• Workflow event log and local audit log (local schema 4, backed up automatically before upgrading).

• Dashboard sign-in survives restarts: one token per project, 30-day cookie.
• qorvyn dashboard --link prints the sign-in link of the running dashboard.

• First dashboard (qorvyn dashboard): workflows, agents, runs, search and team, on 127.0.0.1:4317.

Workflows

• Typed workflows of agent steps and human approvals.
• Steps run in parallel.
• Each step's output is passed to the next as data.
• Writing steps build on each other.
• Retries, cancel, and resume after a crash.

Team sync

• Signed events through your team server.
• Live updates, an offline queue and conflict detection.
• Share agents, workflows, knowledge and opt-in workflow status.
• Removed members and revoked devices are cut off immediately.

• Agent Studio: 8 templates, versioned custom agents, effective permissions with approval on every run, and Claude Code, Codex and mock providers.
• Safe runs: each run gets its own worktree and branch, with time limits, cancel and orphan cleanup.
• Team identity: self-hosted server, OIDC or email-code sign-in, Ed25519 device keys, workspaces, roles, invitations and ownership transfer.
• Go protocol package: conformance-tested against TypeScript.
• No files in your repository: settings live in ~/.qorvyn.
• Local foundation: qorvyn init, cited search, MCP server, SDK and private notes.