← All releases

Guildwise HQ 1.5.0

5 November 2026

Runner 0.1.68 (capability `checks:1`). Forms builder, storage connections, public forms, journeys with waits, gates and webhooks, retiring a workstation with agent handover, and release prep. Migrations 2810, 2820, 2830, 2840, 2841 and 2850. New optional environment variables `AOM_STORAGE_WRITE_TIMEOUT_MS`, `AOM_STORAGE_MAX_FILE_BYTES`, `AOM_STORAGE_MAX_IN_FLIGHT`, `AOM_STORAGE_MS_TENANT`, `AOM_STORAGE_MS_CLIENT_ID`, `AOM_STORAGE_GOOGLE_CLIENT_ID`, `AOM_STORAGE_GOOGLE_CLIENT_SECRET`, the `AOM_FORMS_*` limits (`AOM_FORMS_POW_BITS`, `AOM_FORMS_MIN_FILL_MS`, `AOM_FORMS_SESSION_TTL_MIN`, `AOM_FORMS_SUBMISSION_TTL_MIN`, `AOM_FORMS_MAX_FILES`, `AOM_FORMS_MAX_SUBMISSION_BYTES`, `AOM_FORMS_IP_PER_MIN`, `AOM_FORMS_IP_BURST`, `AOM_FORMS_IP_SUBMITS_PER_HOUR`, `AOM_FORMS_IP_SUBMIT_BURST`, `AOM_FORMS_FORM_SUBMITS_PER_MIN`, `AOM_FORMS_FORM_SUBMIT_BURST`), the offline-link settings `AOM_FORMS_OFFLINE_LINK_DAYS`, `AOM_FORMS_OFFLINE_HOLD_DAYS`, `AOM_FORMS_OFFLINE_SETTLE_SEC`, `AOM_FORMS_OFFLINE_MAX_OPEN`, `AOM_FORMS_OFFLINE_IP_PER_HOUR`, `AOM_FORMS_OFFLINE_IP_BURST` and `AOM_FORMS_OFFLINE_FORM_PER_HOUR`, and `AOM_JOURNEY_HOOK_MAX_BYTES`, `AOM_JOURNEY_HOOK_PER_MIN`, `AOM_JOURNEY_HOOK_BURST` and `AOM_JOURNEY_HOOK_TOLERANCE_SEC`. Runner capabilities `storage:1` and `shift-limit:2`; new runner commands `storage.*`, `journey.webhook.call` and `release.docs_prep`.

What's new

Builders run your project's checks before review

When a builder hands a card over, the runner first runs the checks you confirmed for the project (lint, format, typecheck). A change that fails in a file it touched goes back to the builder with the failing lines, so it does not reach review broken. Guildwise proposes the checks from your repository; confirm them on the project's Environments page under Test copies > Tests and settings.

Build forms for your clients

Under Forms in the Work menu you can design a form: drag in short or long text, email, phone, number, date, dropdown, radio, checkbox and file upload fields, add your logo and check the result in a live preview. Every save is a new version, and earlier ones stay readable.

Journeys: a whole process on one record

A journey links your workflows into one process for a client, matter or deal. Steps can wait for a time, a date, a form or a webhook, ask a person to approve or reject, and call your own systems. Open Journeys in the Work menu; there is a rentals template to start from.

Share a form by public link, QR code or personal link

The new Share tab publishes a form at its own address with a QR code, and creates personal links for one client that work once and expire. Clients need no login; answers and files go to your own storage, and you can unpublish or replace the address at any time.

Release prep updates your docs and videos

Turn on release prep for a project and, before a release ships, Guildwise writes the changelog entries, updates the user guide and can re-record help videos. The new Release prep tab on Releases shows each step, and approving the release waits until it has passed.

Retire a workstation and move its agents

Retire on the Workstations page moves a workstation's agents to another one, or marks them as needing a new home. Move all agents does the same for an offline or removed workstation, and any agent can be moved from its card on the Agents page or the Org chart.

Connect your own storage

Under Organization > Storage you connect OneDrive, SharePoint, Google Drive, S3-compatible storage, a folder or a vault. Forms and journeys write client files there through your workstation; the sign-in stays on that workstation and Guildwise never holds your files.

Full changelog

Added

• Forms builder. Owners and Admins design forms under Work > Forms: drag fields from a palette (short text, long text, email, phone, number, date, dropdown, radio, checkbox, file upload) or add them with a tap or the keyboard, reorder, duplicate and delete them, and set label, required, placeholder, help text, min/max, options and upload types, size limit and destination. The form settings add a title, description, company logo, a destination for the answers and a confirmation text. A live preview shows the form as a client will see it, with the same validation messages. Every save is a new version; earlier versions stay readable. Migration 2820.
• Storage connections (Organization settings, Storage). An Owner or Admin connects the firm's own storage: OneDrive or SharePoint, Google Drive, S3-compatible storage (endpoint, bucket, region, access key), a local folder or NAS reachable from the runner's workstation, or a folder in a knowledge vault. Sign-in for OneDrive/SharePoint and Google Drive happens on the workstation with a code (device sign-in); S3 keys, the local path and the vault folder are sealed in the browser for the runner. Tokens and keys are stored encrypted on that workstation only (secrets/storage.json) and used only by the runner: the Guildwise server never receives, stores or logs them and knows only a connection id, its type, a display name, the workstation and the health. Each connection can be tested (the runner writes and deletes a small probe file and shows the result or a typed error), renamed and removed; removing it deletes the encrypted token from the workstation, also when the workstation was offline at the time (it is removed at the next connection). An expired or revoked sign-in shows as "Needs re-authentication" with a Reconnect action that keeps the folder settings.
• A write operation for forms and journeys. The server streams a file in 256 KiB chunks to the one runner that holds the connection, under a credit window and one deadline, without writing it anywhere: no table, file or log holds the content, and the only thing recorded is the health of the connection. The runner writes the file into the folder given by a folder and name template (for example {journey}/{client}/{field}-{date}), never overwrites (a clash becomes -2, -3) and answers a reference (connection id, path or object key, size, checksum) that the caller may keep. When the storage cannot be reached the write ends with a typed error (auth_expired, unavailable, quota, permission, not_found, too_large, runner_offline, timeout) in a bounded time and nothing is kept on the server. runner_offline is answered at once when the workstation is not connected.
• Public forms (migration 2830). An Owner or Admin publishes a form from its new Share tab and gets a public address (/f/ followed by a long random id) with a QR code that encodes exactly that address, to download as PNG or SVG. Unpublish closes it: the address then says "This form is not available", exactly like an address that never existed. Create a new link replaces the address for good. Publishing is refused while the answers or a file field has no storage connection. Publish changes moves the address to the newest saved version.
• Personal links. Each is for one client or record (use a client number, not a name), expires in 7 to 90 days, can be revoked, and works once: the first completed submission uses it up. The link carries no personal data (a random id, an expiry and a signature) and sits after a # in the address, so it is not sent to any server log. An expired, revoked or used link is refused with a clear message.
• Clients fill the form without a Guildwise login, on a phone or a computer, with the company logo and the same checks as the builder's preview. Answers and files are sent to the firm's own storage through its runner: the readable HTML copy and the JSON of the answers, and every upload at the folder and name the form sets. The server keeps only the status, the times, the form version, the personal link and the storage references. If the storage fails the client sees "Your answers are still here. Try again." and only what is missing is sent again; nothing is marked complete until everything is stored. When the firm's workstation is offline the form says it cannot accept submissions right now. The Share tab lists submissions with where they were stored.
• Public form security (review in docs/security/public-forms.md). The server checks everything again however the browser behaves: required fields and rules, file type by extension and by content (a renamed program is refused; programs, SVG and macro-enabled documents are never accepted), file size before the file is read, and the number of files. Requests are limited per address and per form (429), pages carry a single-use session with a hidden field, a minimum time and a small proof of work (no third-party CAPTCHA), and the page loads no third-party script and sends a policy without inline script or style. Logs never hold an answer, a file name, a token or an address.
• New optional environment variables AOM_FORMS_POW_BITS, AOM_FORMS_MIN_FILL_MS, AOM_FORMS_SESSION_TTL_MIN, AOM_FORMS_SUBMISSION_TTL_MIN, AOM_FORMS_MAX_FILES, AOM_FORMS_MAX_SUBMISSION_BYTES, AOM_FORMS_IP_PER_MIN, AOM_FORMS_IP_BURST, AOM_FORMS_IP_SUBMITS_PER_HOUR, AOM_FORMS_IP_SUBMIT_BURST, AOM_FORMS_FORM_SUBMITS_PER_MIN and AOM_FORMS_FORM_SUBMIT_BURST. Run the server behind a reverse proxy and set AOM_SECRET_KEY (rotating it ends every personal link).
• Move any agent to another workstation. Owners and Admins get Move on every agent of the Agents page (and Re-home for an agent that needs a home), listing the organization's workstations with their owner and connected or offline state. POST /api/agents/:id/rehome no longer requires the status needs_rehome; it refuses a retired agent, the CEO (it moves on the CEO page), an agent in a running shift (409 agent_busy), an unknown or other organization's workstation, an unpaired one and the current one. AgentRehomed records fromWorkstationId. New GET /api/agents/:id/move-targets. The hiring manager can also move their own agent; see Changed.
• Journeys (migration 2810; a database that already has 2820 applies it too, migrations run by file name): a new object (playbooks and workflows are unchanged) for one complete process from trigger to outcome, made of existing workflows linked by handoffs, all working on one shared record (a client, matter or deal). The designer (Journeys in the Work menu) adds workflow steps, orders them with Move up and Move down (works on touch), and defines handoffs: when a step is done, cancelled or either, go to another step or to the end, with an optional condition on a field of the finished card or on the record (type, status, visits). A handoff may go back to an earlier step (a loop, such as monthly rent). A journey is versioned; an instance keeps running on the version it started on. Saving sends the version it was based on (409 when someone else saved first).
• The shared record holds only status, current step, timestamps and references (documents, form submissions, cards, playbook sessions) plus a display name and the firm's own id. Never answers or document content: the record schemas refuse unknown keys, and a reference cannot hold whitespace or inline data. Tables journeys, journey_versions, journey_records, journey_record_refs, journey_instances, journey_step_runs; card origin journey; events JourneySaved, JourneyArchived, JourneyRecordCreated, JourneyRecordReferenceAdded, JourneyRecordClosed, JourneyInstanceStarted, JourneyStepEntered, JourneyStepCardStarted, JourneyStepRefused, JourneyStepCompleted, JourneyStepPlaybookStarted, JourneyInstanceStuck, JourneyInstanceCompleted, JourneyInstanceCancelled.
• Instances start by hand on a record. Each workflow step starts a card in the workflow; when the card is done or cancelled the instance follows the first matching handoff. A step with no handoff ends the journey; handoffs where none matches, or a step that cannot start (workflow not enabled, person no longer a member), leave the instance stuck with a desk notice, never silent. Transitions run under a row lock and are checked against the expected visit, so they happen once, also across a server restart. At most 240 visits of one step and 1000 in all.
• A workflow step can name a playbook. "Run playbook" starts it through the existing guided-session feature and keeps the session as a reference on the step and the record.
• Wait and gate steps are placeholders until the waits and gates change: they show on the designer and stop the instance with a "Continue past this step" action.
• The rentals template (lead, viewing, application, wait for forms and documents, screening, approval gate, lease signed, deposit and first-rent invoice, move-in, monthly rent loop) built on the business workflows.
• The Journeys page lists journeys and running instances with filters by journey, step and status; the instance page shows the current step, the history with times and the references.
• Journey waits, gates and webhooks (migration 2840). Wait steps pause a journey for a time, for a date taken from a field of the previous step's card, for a form or document upload through a personal link, or for a webhook event. Every wait has a deadline that shows on the journey and exactly one timeout action: remind and keep waiting (then ask on the desk or cancel), go to a named step, ask the project owner on the desk (Extend, Continue now, Go to step, Cancel the journey) or cancel the journey. Every wait that ends, for any reason, leaves an event on the instance; none ends silently. Timers are stored rows swept by the scheduler, so they survive a server restart and fire once; a wait that fell due during downtime fires once at the next pass and plans the next reminder from then on.
• A wait for a form creates a personal link for the record and shows it on the desk (a task: "Send this link to...") or passes it to a webhook step, and the journey goes on when the submission has been stored in the firm's storage. No e-mail address is added to the record.
• Approval gates ask a named person, a role, the project owner or the organization Owner on the desk. Approve follows the approved handoff and reject (a note is required) follows the rejected handoff; a handoff saved as done or cancelled is read as approve or reject. Only the approver decides, the first decision wins, and a gate cannot be passed with Continue. A named person who has left the project falls back to the organization Owner and it is shown.
• The journey designer has settings for every wait (what to wait for, how long, what happens on timeout), gate (who decides, an optional deadline) and webhook call (computer, URL, method, headers, body), and a Webhooks panel for inbound addresses (the secret is shown once). The instance page shows each wait and call with its deadline, reminders, link and events, and a person can extend, continue, move or cancel a wait, or decide a gate. Gates, timed-out waits and client links are desk items that can be decided there. A gate reminder raises a new question for the approver on the desk, so it is seen.
• Journeys can start from a signed webhook, POST /hooks/in/<token>. The signature (HMAC-SHA256 with a secret shown once, X-Guildwise-Signature and X-Guildwise-Timestamp, or X-Hub-Signature-256 over the body) is checked on the raw bytes before anything is read; a missing or wrong signature is answered 401 and logged without the payload. A mapping picks only an external id and an optional display name from the payload; the journey starts on the record that matches the external id or on a new one (422 ambiguous_record, 409 record_busy, 422 no_record when creating is off), in the name of the person who created the trigger. A repeated Idempotency-Key starts nothing. No payload is stored or logged, and a webhook trigger can also resume a wait for a webhook event.
• Webhook call steps call a URL (method, headers, a body from record values) from the firm's own workstation, which adds credential headers and an optional signature from its own encrypted store, so Guildwise never holds them. A failed call is retried after 1, 5, 30 and 120 minutes; the final result shows on the journey and a journey without a handoff for a failed call is stuck with a desk notice.
• New runner command journey.webhook.call; new optional environment variables AOM_JOURNEY_HOOK_MAX_BYTES (65 536), AOM_JOURNEY_HOOK_PER_MIN (60), AOM_JOURNEY_HOOK_BURST (30) and AOM_JOURNEY_HOOK_TOLERANCE_SEC (300). An unconfigured wait or gate keeps its earlier behaviour and waits until someone continues it.
• Runner offline: secure upload link sent later (migration 2850). When the firm's runner is offline, a public form shows an email box instead of the fields and sends nothing but that address: no answer or file reaches the server. The journey instance shows the wait "Documents pending, runner offline" with its start time. When the runner is back online for 30 seconds, each waiting client gets one email with the firm name and a secure link (signed, single use, 7 days by default; set per form under Settings, or AOM_FORMS_OFFLINE_LINK_DAYS), and the desk gets one notice per case with the client, the times and the journey. The journey continues when the form arrives through the link, or from the desk with Continue journey. The held email is encrypted (AES-256-GCM, a purpose key) in its own table, never in events, logs or desk items, and is deleted when the case closes (link used, journey continued, expired or cancelled; the runner must return within AOM_FORMS_OFFLINE_HOLD_DAYS, default 7). An Owner or Admin can Show email (audited) or Resend link (up to three times) on the desk notice. New optional variables: AOM_FORMS_OFFLINE_IP_PER_HOUR, AOM_FORMS_OFFLINE_IP_BURST, AOM_FORMS_OFFLINE_FORM_PER_HOUR, AOM_FORMS_OFFLINE_MAX_OPEN, AOM_FORMS_OFFLINE_HOLD_DAYS, AOM_FORMS_OFFLINE_LINK_DAYS, AOM_FORMS_OFFLINE_SETTLE_SEC.
• Write changelog in release prep. When release prep is on, a new Write changelog step adds user-facing entries for the release's changes to the Unreleased section of each repository's CHANGELOG.md, keeps the entries already there and never writes one twice. The Release prep tab on the Releases page lists the entries added per repository, and a changelog the release notes cannot read stops the step with the fix to make.
• Retire a workstation with agent handover. On the Workstations page an Owner or Admin can retire a workstation and either move all its agents to another workstation or mark them as needing a new home (re-home them one by one later). Retiring is refused while one of its agents is in a running shift, and the refusal names them. A workstation that was already unpaired but still holds agents is listed under "Removed workstations with agents" with a "Hand over agents" button. The retirement and each handover are written to the audit log. New events WorkstationRetired and AgentNeedsRehome; endpoints GET /api/workstations/:id/retire-preview and POST /api/workstations/:id/retire.
• Release prep (for the people who ship a project). Under Project settings > Release prep (docs and videos) the project Owner, or an organization Owner or Admin, switches release prep on and ticks its steps: Analyse changes, Update user guide, Write changelog, Generate videos and Commit results. On the Releases page a new Release prep tab (it shows only for a project that uses it) has Run release prep, the state of each step per repository, the change summary, the guide sections changed and the commits made. While prep has not passed, Approve release on the Ship release item is greyed out with the reason and a See release prep link, and the server refuses the approval too; a failed prep offers Retry prep or Skip prep for this release (the skip is recorded with your name). Off by default. Migrations 2830 (release_docs_prep), 2840 and 2850 (release prep output, step report and tasks); the runner command release.docs_prep does the work on a workstation.
• Move all agents off an offline or removed workstation. On the Workstations and Agents pages an Owner or Admin gets Move all agents from this workstation. A hiring manager gets the same button for an offline or removed workstation, and moves only the agents they hired. The dialog first previews who Will move and who is Blocked, each blocked agent with its reason (in a running shift, one DevOps engineer per workstation, workstation limit reached, runtime missing on the target, the CEO moves on the CEO page) and a button to move that agent on its own. After you confirm it lists who was moved and who was not.
• The CEO can move agents between workstations. In your own chat the CEO has aom ceo act move-workstation --agent <name|id> --to <workstation> and aom ceo act move-agents-off --from <workstation> --to <workstation>; they run the same checks as the Move and Move all dialogs.
• Builder handoff checks. A project's repository checks (lint, format, typecheck) now run on aom handoff, by the runner, on the builder's committed change, and the handoff is refused while the change fails a check in a file it changed. The refusal prints the failing lines, the log path and, for a formatter or import sorter, the fix command; the builder fixes (or runs the fix command), commits and hands off again, and nothing reaches review in between. Checks are a new suite kind, check, managed like the project's test suites in the project's Environments page under Test copies > Tests and settings (a new Checks section): the runner proposes them from what the repository declares (package.json lint, typecheck and format scripts, the CI workflow, Biome, ESLint, Prettier, ruff and dotnet format config; for this repository pnpm lint --max-diagnostics=none --diagnostic-level=error and pnpm -r --no-bail --if-present typecheck) and the owner confirms, edits or removes them. Only confirmed checks run and block; proposed ones never do. Only failures in files the change touched block; failures only in other files are recorded as information and shown to the reviewers (a change that breaks an unchanged file is not detected yet). A check that cannot run (missing tool, timeout, no sandbox on the workstation, output cut by the tool, a failure that names no file) never passes silently and never blocks: it is recorded as a warning on the evidence, on the card thread and in the owner approval, and the reviewers see it as unverified. Checks run under the run-step sandbox profile (bubblewrap; credential folders, the runner's data and.NET user secrets masked), at most 10 minutes each and 6 minutes in total per handoff. The result is stored with the build evidence, bound to the commit, and shown to the pre-reviewer, the reviewer and the owner. A runner without the capability hands off exactly as before and the server never requires checks. Builder role version 7 tells builders about the checks. No migration; the runner needs 0.1.68 on the workstations that run builders. Checks run only where bubblewrap is available (or the sandbox is switched off in the runner config).

Changed

• Moving an agent. The hiring manager can now move their own agent, and the Org chart agent card has Move to workstation next to the Agents page button. A move releases claims the agent holds without a running shift (ClaimReleased reason agent_moved) instead of refusing, and still refuses a running shift. A DevOps engineer moves only off an unpaired workstation onto one without a DevOps engineer (409 devops_stays / one_devops_per_workstation); the dialog warns first. GET /api/agents/:id/move-targets names the DevOps engineer on each target.
• Workstation shift limit. The setting on the Workstations page now decides how many shifts a workstation runs at once, and the runner reports the limit it enforces (runner capability shift-limit:2). Each workstation shows running of limit with where the limit comes from (workstation setting, platform cap, runner config, runner local fallback or shared with other pairings), how many chat and CEO shifts are not counted, who holds the slots when it is full ("Held by GWP-94 (Ada)"), and a warning when the runner enforces something other than what is set. A refused shift says N shifts already running (limit N), source:..., held by.... Update a runner that does not report its limit.
• A card that goes back to a build stage (rework) is offered first to the builder who worked it last.
• The runner refuses to commit leftovers that delete many tracked files or put an earlier version of the tree back, and says so on the card instead of committing.
• The phone layout keeps the tab bar fixed at the bottom, adjusts to the on-screen keyboard and keeps the open page when the window crosses the 768 px breakpoint.
• The tour has a Forms step.
• The platform Videos tab shows how many drafts are waiting (against a limit of twice the ticked days) instead of a weekly count, because the writer is limited by the waiting pile, not by the week.

Fixed

• Unpairing a workstation now retires its DevOps engineers in the same step (history is kept and an audit event is written for each), releases the work they held, and flags the other agents on that workstation as needing a new workstation. A one-off data migration (orphaned-devops-2026-11) retires DevOps engineers that were already left behind. The runner clears the old workstation's saved shifts, queued reports and DevOps agent folders when it is unpaired or paired again (runner 0.1.66).
• An agent that needs a new home can be re-homed even when its old shift was never ended.
• Chat with the CEO in bypass permission mode: the CEO's aom commands failed because the shift variables were removed from the commands the turn ran. The shift variables now reach aom through a file in the turn's folder.
• The "commits on another branch" check only counts a card's own branches. A shift is no longer refused because another card's branch moved without it.
• The architect check lets merges of the base branch through, and discarding out-of-scope changes no longer reverts work that was merged in.
• The card's own .git/worktrees/<card> folder is writable inside the shift sandbox, which ends index.lock failures in git commands.