← All releases

Guildwise HQ 1.4.0

1 November 2026

Runner 0.1.65. Software and Business views, the six business workflows built in, any workflow as a variant base, releases from start to finish, and a clear way back when a computer is removed. Migrations 2751, 2791, 2800 and 2801. New optional environment variables `AOM_RELAY_MAX_BODY_BYTES`, `AOM_RELAY_RATE_PER_MINUTE`, `AOM_RELAY_RATE_BURST`, `AOM_RELAY_TIMEOUT_MS`, `AOM_RELAY_TIMEOUTS`, `AOM_RELAY_RETRY_AFTER_SEC`, `AOM_RELAY_MAX_IN_FLIGHT` and `AOM_RELAY_RETENTION_DAYS`.

What's new

Six business workflows, ready to use

Enquiry, Follow-up, Document request, Reminder, Report and Quote are now built-in workflows for every organization. New project explains each one in a sentence, and an agent drafts the reply, message or document for you to check and approve before anything goes out. Improvements to them now reach everyone automatically.

Your CEO can check your workstations

In your own chat with full power on, your CEO can now read the status and logs of your workstations and of the server to find out why something is not working. It only reads, keeps passwords and tokens hidden, and a refused command now says why and what to use instead.

Choose a computer when one was removed

When you remove a computer, its test and live environments no longer break. Before you confirm, Guildwise lists the environments that will need another computer, and afterwards each one says its computer was removed and offers Choose a computer to carry on from one of yours.

Customise any workflow

Every workflow can now be the starting point of your own version: Code, Research, Feed, the bug-fix workflow, the business workflows and the ones you built. Open the project's settings and choose Customise to add your own steps while the original keeps working as it did.

Releases from start to finish

Approving a release now prepares it for you: the changelog moves under the new version, version numbers go up and the release commit is pushed. Once it is merged, Guildwise tags it and creates the release page on GitHub or GitLab. If a step fails you get a clear message and Retry carries on from that step, without doing anything twice.

Software view and Business view

Pick how Guildwise HQ looks to you from the user menu: the Software view for building software, the Business view for running a business in plain words, or your organization's default. A view only changes what you see first; every organization can do everything, and switching never changes your projects, cards or agents.

Inbound webhooks for WhatsApp and forms

Business organizations can give WhatsApp, web forms and calendars a private address that passes each message straight to the runner on your workstation. Guildwise HQ keeps no message content and no secrets, and tells you when messages are waiting because the runner is offline.

Full changelog

Added

• Software view and Business view. What used to be the organization's Developer or Business mode is now a view, and a view is presentation only: every organization has every capability (repositories, builders, reviewers, testers, DevOps, packs by git URL, business roles, rule packs, Brief playbooks, inbound webhooks, all card types and workflows), and nothing is refused because of a view. The organization has a default view (Organization, General), and each person can pick their own from the user menu (Software view, Business view or the organization default); it is stored per organization membership (org_members.view, event OrgMemberViewSet, PUT /api/org/view). Switching is instant, never refused, and appends only the preference event: no data, workflow, project, repository, agent, deploy or card changes. The Business view uses plain words (Rules & decisions, Knowledge, Ask for technical help), leads with the business card types, roles and project types (the software ones sit under "More"), tucks away test environments and releases (their addresses show a note with one click to the Software view), collapses the repositories of a project and keeps workstations and Ask for technical help. A project in the Business view has a Build something button that walks through the workstation, the software conversion (with the repository) and the builder, using the existing screens. The six business workflows (Enquiry, Follow-up, Document request, Reminder, Report, Quote) are true built-in workflows, registered once for everybody at start like Code, Research and Feed; they are enabled on every project at start and when a project is created. A later version reaches every organization at the next start.
• Inbound webhook relay, for every organization. An Owner or Admin creates an integration (WhatsApp Cloud API, form webhook, incoming webhook, calendar push or generic) and gets a public URL /relay/in/<token> once. The server forwards each request, raw and with its headers, over the runner's connection to a workstation that serves the integration, and gives the provider the status the runner answers. The server keeps no content: only a hash of the token and metadata per request (time, integration, size, status, latency, outcome). With no runner connected the provider gets 503 with Retry-After and retries; nothing is queued. The runner has a relay command (list, add, remove) and a generic handler that stores events in its data folder.
• Approving a Ship release now makes the release commit. A workstation that has the repository moves the Unreleased entries of CHANGELOG.md under the new version and date (an empty Unreleased stays, and the intro line gets one sentence per component, such as Runner 0.1.63. or Runner 0.1.62 (unchanged).), raises the version file of every component whose files changed, commits chore(release): x.y.z as the project's commit identity (signed off when the repository asks for a DCO) and pushes it to the working branch without force. Repeating it makes no second commit. A failure leaves a "Release stopped" item with git's message, Retry continues from that step, and Dismiss abandons the release. The repository row shows the state. Migration 2780; new runner command release.ship, capability release-ship:1.
• Tag and release after the release PR is merged. Once the release commit is in the release PR and the PR is merged (or Guildwise merges it when the project lands work without pull requests), Guildwise tags the merge commit vX.Y.Z (annotated, never moved) and creates the release: GitHub (notes are the version's changelog section, marked latest) and GitLab; Azure DevOps, Bitbucket and plain git get the tag and a notice that no release page was created. A failed step leaves a "Release stopped" item with Retry that continues from that step and makes nothing twice. The repository row shows the last release with tag and release links. New repository setting "Release name" (expert mode, defaults to the project name). Migration 2790; new runner command release.publish, capability release-publish:1.
• A merge into a submodule now moves the pin before the deploy. When a card merges into repository X and an after_merge environment deploys another repository D that holds X as a git submodule, the server sends the new runner command repo.bump_submodule (runner 0.1.64) to a workstation with D. The runner finds the submodule by url in D's .gitmodules (nothing to set up), commits chore: pin <path> to <sha> with the project's commit identity and a Signed-off-by line, pushes D's working branch (never forced, once more from the new tip if origin moved) and answers D's new head, which is what the environment deploys. Several merges in the two-minute window give one bump with the newest commit. A failed bump (protected branch, refused push) is a desk notice and deploys nothing; D not holding X, or a runner older than 0.1.64, deploys D as it is (the latter with a notice that the pin was not moved).
• The CEO can read logs and status in full power. In your own chat the CEO has aom runner status and aom runner logs [--kind runner|service|shifts|env|audit] [--name <file>] [--lines N] [--grep text] [--since "-3 hours"] for this workstation (the runner's log, the systemd journal, shift, environment and CEO command logs), aom ceo diag workstation <name> for another workstation of yours (new runner command runner.diagnostics, capability ceo-diagnostics:1, runner 0.1.65 or newer, migration 2800) and aom ceo diag server [--kind status|logs] for the server's status and its recent log lines. Read-only, tokens and passwords masked on the runner and again on the server, and only in the Owner's own full-power turn: a standing-order turn, a wake and a CEO on another user's machine are refused with a message saying why.

Changed

• The six business workflows are built in, not copies in each organization. New project describes each one in plain words with its own icon, the organization page and the convert dialog show them as Built in, and a new version of one now reaches every organization (a per-organization copy never did). The boot data migration business-builtin-2026-11 moves the copies the 1.4.0 pre-release created: an unedited copy is retired so the built-in takes over (cards in flight finish on the version they started on); a copy the owner edited is kept as a normal custom workflow under <key>-custom (name "... (edited)"), and the projects that used it follow. A project repointed to <key>-custom does not get the built-in of that key enabled again (it counts as a workflow the project had); the owner can enable it in the project's settings. Skipped with AOM_DATA_MIGRATIONS=false. New events WorkflowVersionDeactivated and WorkflowKeyChanged.
• Any workflow can be the base of a project variant (Customise): Code, Research, Feed, the bug-fix workflow, the business workflows and your own. Only a variant itself cannot be extended again; extend the workflow it was made from. A variant of research, feed or code-bugfix follows the rules of its base: it can only run in a project of that kind (a research project runs research and its own variants), never next to Code, and a bug-fix variant is not a project workflow.

Fixed

• Unpairing a computer no longer breaks the places and environments that deployed from it. Each place (server or computer) and live environment that ran on the removed computer is now marked "computer removed" (new event DeployTargetComputerRemoved, migration 2801 deploy_targets.computer_removed_at; the place keeps its old computer for the record). Before, Check, Check again, Fix with DevOps, secrets, moves and deploys answered "workstation not found", the card kept offering Check and hid Reconnect. Now they answer 409 deploying_computer_removed ("The computer that deploys <place> was removed. Choose another computer for it."), the card and the Places panel say so and offer Choose a computer (a server opens Reconnect, a computer place offers your active computers), nothing probes a removed computer, and the daily server check skips it. The project owner can recover a live place. The Unpair dialog lists the places and environments that will need another computer (GET /api/workstations/:id/unlink-impact); unpairing still goes ahead once confirmed. The boot data migration deploy-removed-computers-2026-11 marks places whose computer was removed earlier (events only, idempotent, skipped with AOM_DATA_MIGRATIONS=false). When the project's vault lived on a removed computer, saving a setup now says the vault must be moved first.
• The workflow builder kept no date format on a field: a workflow with a date field (the business workflows) lost the format when saved from the builder.
• An organization vault can take a git remote after the automatic local one exists. Registering a git URL for the organization (or editing the local organization vault) converts that same vault and keeps its content, as a project's local vault already did, instead of 409 vault_exists / vault_local; Settings > Vaults offers it.
• Decisions, standing orders, investigation notes and conversion notes follow the same vault as the rest of the knowledge: the project's git vault, then the organization vault, then the project's automatic local vault. They no longer stay in the local folder when an organization vault exists.
• The Releases page of the app moved to /delivery/releases, so a reload or a shared link reaches the app (the public release blog keeps /releases and /releases/<version>). /releases and /deploys still lead there inside the app.
• A business workflow an owner turned off on a project stays off. The check at start and the install on a new project only add the workflows the project has never had (read from its event history); it no longer switches a disabled one back on.
• A deploy of a repository that holds another as a git submodule (the cloud holds the core) builds again: the runner fills each submodule of the deploy checkout at its pinned commit, from this workstation's own clone of that repository when it has one (a missing commit is fetched into that clone first), and removes such a checkout afterwards without leaving a worktree entry. Before, the submodule folder stayed empty and the build failed.
• Run regression (the manual full suite) in a project with several repositories asks which repository; before, it ran on the first by id. POST /api/projects/:id/full-suite takes an optional repoId (an active repository of the project); without it a project with several repositories is refused with choose_repo naming them, and a project with one behaves as before. Project settings shows a repository picker (name and working branch) when there is more than one.
• The New card form of a Business mode organization offers the business card types in their own order (Enquiry first, and the default) instead of the alphabetical order of their workflow keys.
• Saving the same component version rules again no longer records a new ProjectRepoComponentRulesSet event: the unchanged check compared the stored rules by their serialized key order, which the database does not keep, so it never matched.
• Every after_merge deploy failed with commit_unavailable in a project whose cards merge into one repository while the environment deploys another: the merge commit of the card's repository was handed to a clone of the other. A merge commit is now only used for the deploy of its own repository (the newest merge of that repository, else the head of its working branch), in the trigger, the automated-commit allow-list and the default commit. deploy_trigger_queue remembers the repository of the merge (migration 2751).
• Finalize no longer sends a card back to Rework with an empty "conflict" when nothing conflicted. A card branch that is already on the working branch (merged by hand, or by an earlier finalize whose answer was lost) is reported merged straight away, before any rebase. A merge that git refuses without a conflicted file (a lock, a missing ref, a refused signature) is reported as a finalize failure with git's own message, which reaches the desk, instead of a conflict for the builder that loops back through review.
• The CEO in full power no longer fails on permission checks it should not hit. The Owner's chat runs in Claude Code's auto mode, whose classifier refused ordinary reads (the runner's logs, the systemd journal, aom runner restart, aom ceo act...) without ever reaching the desk question, and the deny floor also blocked reading the runner's logs and status.json and every systemctl... aom-runner*, even status. Runner 0.1.65: the floor now only blocks stopping, starting or editing the runner service (reading it is allowed), and a hook says why a command was refused and what to use instead (aom runner logs, aom runner restart). The default permission mode is unchanged (auto, for new and existing opt-ins); guildwise-runner ceo full-power on --bypass is a new explicit opt-in to Claude Code's bypassPermissions for the Owner's own chat, where nothing is judged or asked like in your terminal (the deny floor, its hook, the audit and the masking of secrets still apply, and the runner's provider credential is kept out of the shell's environment); on --strict goes back to auto. A standing-order turn always runs in auto with the desk relay. In the Owner's chat a missing citation or a reached action limit now asks him with an inline confirmation instead of a refusal, and a refusal by the policy names where the owner changes it. CeoTurnFinished records the turn's permission mode and the first words of its commands.