Project Status

Project Status

Back to Home

The latest public release is v1.3.0, at 1bae329c, published October 10, 2026. All five exact-main CI jobs and the guarded publisher passed; independent readback verified Release assets, manifest, both amd64/arm64 OCI chains and stable aliases. This release publishes the Docker 29 correction, helper 0.5.0 and its separate supported upgrade CLI. An enrolled 1.2.0 host must upgrade its helper separately; an application image pull cannot replace host code. No operator action or migration is required; standing backup-queue guidance remains. See Releases for the public receipt and exact identities. The real 1.2.0 → 1.3.0 minor pair is available, but managed application qualification remains open with zero qualified scenarios. Development main is 1.4.0-dev after PR #1136; that reset published no release.

The previous public release is v1.2.0, at 56374e95. ARM64 baked identity, official source installation/enrollment, idle restart/reboot and separate ordinary restore passed over private HTTP. These source and ordinary-recovery results remain separate from managed apply and its fault matrix.

It is a support desk reachable by widget, email, and help centre, with a measurement surface of its own. Mailgun and Postmark can post directly to POST /api/mail/inbound when their matching verification is configured; the original Wayfindr-signed proxy format remains compatible. Public v0.7.0 predates direct-provider support. See the repository inbound-mail guide.

Self-hosting and upgrades from public artifacts have been proved repeatable on hosted runners and disposable bare-metal guests. The October 1 public-artifact hosted runs cover a v1.1.0 clean install and v0.2.0 → v1.1.0 upgrade with a custom backup queue. The newest owner-operated bare-metal guest evidence still covers v0.3.2; see Releases.

The newest hosted public-artifact runs cover a v1.1.1 clean install and a v0.2.0 upgrade with a custom backup queue. Both matched the published image digest, completed the support loop, backup/restore and stack restart, and read v1.1.1 from authenticated /operator before and after restore.

The Tier 1 and Tier 2 feature epics are closed in v0.9.0. The independent-install acceptance criterion, #797, closed on September 29, 2026: somebody who is not the author installed Wayfindr on a clean Ubuntu VM using only the public documentation and got it running. The owner decided that install is enough for 1.0.0; the non-author upgrade #994's scope also named was not required, and v1.0.0 published on September 30. The tag preconditions recorded in #970 were satisfied before v0.9.0 published. The account area that #994 scoped for 1.0.0 finished its restructure in v0.11.0, after the sidebar in v0.10.0. #985, the site-settings page length, closed on 2026-09-21: 11,333px to 7,610px of scroll, 23 sections to 17.

What's in v1.3.0

This section describes public v1.3.0 at 1bae329c. It includes the Docker 29 helper correction and supported host-helper replacement. Some foundation was available in older releases; consult their release notes when operating them.

1.2.0 adds read-only release review in Operator → Updates and hardens terminal upgrades. Optional managed execution on explicitly enrolled Linux/systemd hosts adds authenticated start/cancel/history, independent fencing and backup custody, reconnecting progress and explicit host recovery. The application container does not receive the Docker daemon socket. One additive audit-event deduplication migration runs automatically. No operator action is required; ordinary unenrolled installations retain their update path.

Managed execution is implemented but not qualified for production use. U8/#1115 and U9/#1116 remain open, with zero qualified managed scenarios. The first compatible source can prove enrollment, idle reboot and ordinary independent restore. The published 1.2.0 → 1.3.0 pair now supplies a real target for protection/apply tests. See the qualification boundary.

v1.1.1 changes, relative to v1.1.0: dashboard text, forms, pagination and work context are more consistent; Reports filters, long comments and chart scrolling are clearer; authentication feedback and keyboard tab selection stay in context; phone widget controls and focus after attachment removal are easier to use; and release checks identify the CI run blocking publication. It has no migrations and requires no operator action.

v1.1.0 changes, relative to v1.0.0: a contact can be erased on request, from an "Erase this contact" section on their profile that removes everything Wayfindr holds about that person and keeps their tickets as work items with the personal content removed; erasures survive a restore, because each is also recorded in storage/app/erasure-ledger/ on the storage volume, which backups do not carry, and a restore erases again anyone the archive brings back; and an "Export this contact" section downloads one ZIP of everything held about that person, with agents and operators shown by role, not by name. Both need the new Handle data requests permission, which Owners and Admins have and custom roles can be given alongside Manage contacts. It needs no operator action, and five migrations run themselves. Keep storage/app/erasure-ledger/ alongside your backups. ADR 0026 records the design.

v1.0.0 changes, relative to v0.11.0: none in the application. It is the first release whose version number carries the operator-action signal: only a new major can ask an operator for anything beyond pulling and restarting, a minor adds features and self-migrating schema, and a patch only fixes.

v0.11.0 changes, relative to v0.10.0: the account area is reorganised, with a Team page for the roster, site access and team alerts, API tokens and outbound webhooks as two tabs, and each Integrations connection's settings folded under its row; a failed provider connection form no longer stores its API token or webhook secret in the session; and dependencies are refreshed, including the Laravel AI SDK 1.0.

v0.10.0 changes, relative to v0.9.0: replies to email conversations are delivered (their email never rendered before, and the replies v0.9.0 queued from the conversation page or the API send after the upgrade); a visitor who left an address while the desk was away gets the reply by email; replies written on a linked ticket's page are emailed too; the account area has a context sidebar; and the widget is served minified. The release notes list the rest.

• Widget install, visitor identity, live chat, agent replies, and durable tickets.

• Email as a second channel: mail opens and continues conversations, so a customer replying to a notification is no longer replying into nothing. v0.9.0 and later verify Mailgun and Postmark directly and retain the original Wayfindr-signed proxy contract for existing integrations.

• A help centre: articles written in the dashboard and searchable from inside the widget, so a visitor can find the answer before asking.

• A public API and outbound webhooks: scoped tokens provide read and narrow write access, while signed thin events announce new conversations, messages and ticket lifecycle changes without pushing support content to the configured destination. Deliveries are durable, ordered per endpoint, retried with backoff, and visible to admins.

• Account authentication and authorization: TOTP with recovery codes and an account requirement; OIDC federation; account-owned custom roles; and owner-controlled JIT provisioning with deny-by-default claim mapping. SAML remains demand-gated and SCIM remains a separate lifecycle decision in #761.

• Support hours, away state and offline capture, per site and in the site's own timezone, with a pre-chat form for sites that need to know who is asking.

• Reporting: conversation and ticket volume, first-response and resolution times, reopen rates, per-agent workload, and visitor satisfaction ratings. Resolution and reopen figures are read from lifecycle logs, and the two halves have different memories: conversation closes began being recorded in v0.7.0, while ticket closes have been audited since well before it — so an upgraded desk can describe a quarter of ticket work while its conversation figures are still accumulating. The page states each boundary separately. Volume, first-response times and agent replies come from data the product always kept and reach back as far as the install does.

• Per-site widget appearance, and a widget that speaks the visitor's language — English and German.

• A dashboard an agent can read in their own language — English, German, and Italian — across the operator console and most dashboard workflows: profile, alerts, reports, conversations, tickets, sites, visitors, account security, SLA, automation, articles, API/webhooks, audit, operator access, Integrations, and the account overview. An agent who has chosen nothing reads the install's language, which the operator sets in the browser under Language and region; APP_LOCALE seeds a new install and is the fallback until somebody saves one.

  The ordinary dashboard pages still intentionally rendered in English are the agent home page and support-code lookup. Readiness and its guided setup checks are translated in this release. DashboardLanguage::EXTRACTED_ROUTES is the executable authority; it also includes writes and partials whose validation or refreshed content must match the page that invoked them. A write shared by translated and untranslated pages resolves from the surface it renders back to, so the language belongs to the page the agent is looking at rather than to the endpoint.

  The visitor and agent catalogues are deliberately different. Italian is agent-facing only: an Italian-speaking desk reads its dashboard in Italian, while visitors still receive English or German. Adding a widget language is a separate catalogue for a separate audience.

  The catalogue files remain the authority for review state too. German was drafted by hand in context by somebody who is not a professional translator, and much of the Italian catalogue is machine-assisted. Both trees have since been through the review the translation policy defines, and no catalogue in either still declares itself unreviewed — in English or in its own language. Three headers keep a narrower note recording that no native speaker has read them, which is true of every catalogue in both trees.

  That review is a reader rather than a speaker — the bar the policy sets on purpose, because it catches wrong terms, overflowing strings and misplaced register, which is what a reviewable diff is good for. Mechanical checks protect keys, terminology and placeholders. Neither establishes natural language quality, so do not promise either language to a customer until a qualified speaker has read the rendered screens.

• A dashboard an agent can read on their own clock. An agent picks a timezone on their profile beside their language; everyone who has not picked one follows the install's. The operator sets that in the browser, under Language and region, and it is authoritative — WAYFINDR_DASHBOARD_TIMEZONE seeds a new install and is the fallback until somebody saves one. It changes what is shown, never what is stored — every record stays in UTC — so changing it re-reads existing history rather than rewriting it, and it applies to report day boundaries as well as timestamps.

  A site's support hours are the deliberate exception: they belong to the site and stay in the site's own zone, because "visitors are told support is back at 09:00" would become untrue read on an agent's clock.

  app.timezone is the storage clock, and it is hardcoded to UTC in config/app.php — deliberately, and with no environment variable for it. Laravel writes created_at through that value into columns that carry no offset, so pointing it anywhere else would record local wall-clock time where every reader, and every report query, expects UTC. The display clock is a separate setting for exactly that reason.

• Numbers grouped the way the reading agent groups them — 4.213 for a German agent, 4,213 for an English one — on the same extracted pages, and in live updates as well as the first render. Values that something reads back are deliberately left alone: chart bar widths, data attributes, CSV cells, and anything on a broadcast.

• A visitor directory and contact workspace with account-defined typed attributes, exact-value filtering, private person-level notes, explicit same-site identity merge, and a contacts-only custom-role boundary; plus a public API with a decided isolation model, scoped reads, and a narrow write surface (ADR 0018).

• Live visitor presence (#747): who is on the site right now, on what page, for how long, and whether the desk has ever heard from them. It updates over the Reverb connection the agent pages already use, and resyncs on subscribe and on a timer so a missed frame costs a minute rather than the session.

  The decision that made it possible is ADR 0019: Wayfindr may observe visitors who never made contact, on a per-site operator switch, with a visitor-facing disclosure, a decline the widget honours, and the product's first automatic retention control.

  Off on every install until somebody turns it on. The switch is on the site page under Live visitor presence, behind the same permission as the masking rules, and a default install reports nothing and shows no visitor a notice. Turning it off again deletes the visitors it collected who never made contact, and a second switch decides whether reports may name the page at all — for sites whose paths carry invitation codes or reset tokens.

  Presence-only visitors are deleted 30 days after they were last seen, or sooner if the operator shortens the window; the maximum is the product's, not the operator's, and a longer value is clamped rather than honoured.

  Presence also feeds operator-configured proactive-message rules. Presence is still off by default, proactive messages are separately enabled, and the visitor-facing disclosure and decline remain in force.

• Team-scale support workflow: SLA policies and breach warnings, automatic assignment and routing, typed lifecycle conditions and actions, automation rules, macros, bulk actions, and a command palette with global shortcuts.

• Quieter, more useful alerting: background dashboard alerts, Web Push, quiet hours, and cross-channel de-duplication.

• An optional agent copilot inside the assistive boundary: on-demand summaries, editable reply drafts, ticket-conversion suggestions, and proposed knowledge snippets. Every result is reviewed by an agent; no provider is required, and Wayfindr does not autonomously answer visitors.

• Measured performance baselines for concurrent Reverb agents, heavy cobrowse transport, large attachment-retention sets, and data-heavy dashboard and report pages.

• Agent-initiated password recovery.

• Consent-based cobrowse observe mode with sanitized snapshots, bounded mutations, telemetry, and an inert replay preview.

• Private conversation-message attachments with visitor and agent UI, retention sweep, malware-scanner hook, and S3-compatible storage routing.

• Operator readiness, database-backed operator settings, guided onboarding, backup/restore surfaces, and release upgrade guidance.

• Scoped read-only break-glass grants for platform-operator support.

• GitHub/GitLab/Jira issue creation, state reflection, and comment relay foundations.

• Pull-request CI, branch protection, Dependabot, private vulnerability reporting, and this repo-authored Wiki.

Historical 0.4.0 Reliability Cycle

The 0.4.0 proof cycle was not broad feature expansion. It collected clean evidence for:

• disposable-VM clean installation;
• supported upgrade and advisory behavior;
• backup, restore, rollback, and reboot recovery;
• deployment-fork synchronization and release-readiness audit.

Use Disposable VM Evidence when recording those runs. Treat dated stage or fork observations as context, not current runtime proof.

Last Full Public-Artifact Evidence Snapshot

As of August 12, 2026, the public-artifact matrix had passing hosted runs for the then-current clean-install, published-upgrade, warning/recovery, and schema-compatible image rollback/retry scenarios:

• clean-install-latest for v0.3.2;
• upgrade-v0.2.0-latest-custom-backup-queue;
• upgrade-v0.1.0-latest;
• upgrade-v0.1.0-v0.2.0-latest;
• recovery-latest-synthetic-skew-restore;
• recovery-latest-v0.3.1-image-rollback-retry.

Together, those hosted runs prove fresh GitHub-hosted Ubuntu runners can install published artifacts, upgrade through the supported public-release paths, boot the Compose stack, run migrations, complete the support loop, take and restore a backup, repeat the support loop after restore, and restart the stack. The custom backup queue run also proves the backups-queue advisory appears during upgrade guidance and retires once the worker is observed. The recovery runs add hosted proof for the then-current restore warning path and for a narrow schema-compatible image rollback from 0.3.2 to 0.3.1, followed by retrying the v0.3.2 image.

The owner-operated bare-metal repeat adds two fresh Ubuntu 24.04.4 clean guests, a public v0.2.0 to v0.3.2 upgrade guest, database and exact attachment-byte restore, pre-mutation refusal with the previous release kept live, and real guest reboot/reverify passes. Both clean attempts found actionable Docker-only host gaps; PRs #707 and #708 fixed them before the final repeat. See Disposable VM Evidence for the sanitized matrix and its limits.

The deployment fork matched source at b8be095 after PR #708, with passing fork CI and an observed successful Forge deployment. The authenticated operator surface reported the same revision, PHP 8.4, a ready 13 / 0 / 2 installation posture, configured SMTP, Redis queueing, Reverb, writable storage, S3-compatible private attachment storage, and reachable ClamAV. Forge showed queue, backup queue, Reverb, and per-minute scheduler processes plus three-region HTTP 200 health checks. The operator's scheduler confirmation was stale and its backup/restore confirmation missing; those manual proof notes remain operational follow-up, not evidence of a failed process or restore.

The combined evidence still does not claim destructive-schema downgrade safety, real DNS/TLS configuration, real mail delivery, offsite-backup durability, or a production restore.

(Historical: this snapshot was recorded during the 0.4.0 evidence cycle, when v0.3.2 was the public artifact. Releases through v0.7.0 have been cut since. The evidence above stands as a record of what was proved then; it is not a statement about the current release.)

Current Release and Acceptance Gates

A cold, no-context Claude agent tested public v0.7.0 in a cloud sandbox. It matched the release, commit, and image digest and completed a synthetic visitor-to-agent support loop after working around two defects. The run found that the script-tag widget did not auto-initialize and that an unreachable GitHub release API was misdiagnosed as "no release." Those defects were fixed in v0.9.0 by #929 and #931.

That was valuable cold-start evidence, not #797 acceptance. It ran in a cloud sandbox rather than a real VM, warmed the image cache before timing, used localhost over HTTP, skipped public-origin and TLS/local-CA paths, and was performed by an AI agent rather than a human non-author.

Public v1.2.0 at 56374e95 has passed exact-main CI, guarded publication and independent public-chain verification. ARM64 never-started baked identity verification, official source installation/enrollment and autonomous idle restart/reboot passed, with runtime/private nonce/API checks. Ordinary separate-VM restore passed without force, using retained keys and a real post-archive erasure ledger with exact replay/survivor/decryption/sequence checks. Publication and ordinary recovery cannot close U8, U9 or the managed-update epic. Managed execution needs installed-helper and target-bound native proof. The Docker 29 fix #1131, helper upgrade CLI and newer target are now published in 1.3.0. Planning the running release still returns no_update_required. An already-enrolled 1.2.0 host also needs a supported helper upgrade path or a new published source enrolled with the fixed helper; an application image update alone does not replace host helper code.

At its October 2 publication, the v1.1.1 tag at 648caa1b and its release workflow verified the published manifest, multi-architecture image and digest (sha256:c816a46187549ea35ab04e7cae5fcbb96c3d80b1c06842951228a772ddc956a9), GitHub Release, and the stable 1.1 and latest aliases at that publication.

At its October 1 publication, the v1.1.0 tag at 9b634b23 and its release workflow verified the published manifest, multi-architecture image and digest (sha256:ef0f50c987aa56a796e627c93197c3bb5a8588fbb6f1fc43056c598681d05905), GitHub Release, and the 1.1 and latest aliases at that publication. Separate hosted runs verify a public-artifact clean install and a v0.2.0 → v1.1.0 upgrade with a custom backup queue. Both read Wayfindr version: v1.1.0 from authenticated /operator after the install or upgrade and after restore, and the upgrade matched the published image digest.

Before it, the v1.0.0 tag at d6e5875e and its release workflow verified the published manifest, multi-architecture image and digest, GitHub Release, and stable aliases. Separate hosted runs verified a public-artifact clean install and a v0.2.0 → v1.0.0 upgrade with a custom backup queue. Both matched the published image digest and read Wayfindr version: v1.0.0 from rendered authenticated /operator after install and after restore.

Before it, the v0.11.0 tag at 2bb7d5e3 and its release workflow verified the published manifest, multi-architecture image and digest, GitHub Release, and stable aliases. Separate hosted runs verified a public-artifact clean install and a v0.2.0 → v0.11.0 upgrade with a custom backup queue. Both matched the published image digest and read Wayfindr version: v0.11.0 from rendered authenticated /operator after install and after restore.

Before it, the v0.10.0 tag at 665faf09 and its release workflow verified the published manifest, multi-architecture image and digest, GitHub Release, and stable aliases. Separate hosted runs verified a public-artifact clean install and a v0.2.0 → v0.10.0 upgrade with a custom backup queue. Both matched the published image digest and read Wayfindr version: v0.10.0 from rendered authenticated /operator after install and after restore.

Before it, the v0.9.0 tag at b9ae8bcc and its release workflow verified that release the same way, with a public-artifact clean install, a v0.2.0 → v0.9.0 upgrade with a custom backup queue and a fresh-install operator probe that read Wayfindr version: v0.9.0. None of these synthetic runs was the human non-author install that #797 required; that install happened separately, on September 29, 2026, on a clean Ubuntu VM.

Publication, an install from the public artifact, and human acceptance are separate claims.

Parked or Demand-Gated

• External tracker labels, assignees, priorities, richer inbound comments, and assigned-agent notifications are documented parking-lot items, not active open issues. Reopen a narrow issue only when real support traffic identifies the provider, field direction, conflict policy, and operator pain.
• Direct ticket attachments, internal-note attachments, office-document opt-ins, and pre-signed attachment URLs wait for message attachments to prove the next shape.
• Live cobrowse replay is already handled through server-sanitized preview swaps. Literal incremental DOM patching inside the iframe should not proceed while it weakens the bare-sandbox, no-script, observe-only boundary; revisit only with measured dogfood pressure and a new architecture decision.
• Automation beyond the current rules, macros, bulk actions, and webhooks waits for real accounts to expose a specific edge. Host SDK polish remains demand-gated.
• A visitor-facing autonomous answer agent remains deferred by ADR 0004 and #762. The implemented copilot is assistive: a human reviews every suggestion before a visitor sees it. Four private captures under the same sixteen-case suite and prompt across three model/upstream routes produced one 16/16 pass and three machine-scored failures. The owner's September 10 adjudication found two Gemini misses were matcher brittleness and one was a real omission. The final disposition was no fixture or matcher change, preserving the recorded 13/16 failure. #997 later added a versioned scoring contract to the suite identity, changed the evaluator and Unicode phrase matching, and renamed a fixture policy key. The suite identity rotated while the prompt identity stayed the same. Those captures remain valid historical evidence, but cannot be compared with a new run under the current suite. Every proposed route needs recapture under the current identity before #762 can use same-route evidence after meaningful elapsed time or a model revision to revisit ADR 0004. All four September captures were recorded within about 78 minutes, so this is point-in-time variability, not long-term drift resistance, model-revision evidence, provider approval, or visitor-runtime safety; #762 and the ADR boundary remain open and unchanged.

The repository remains authoritative. See the README, Roadmap, and current GitHub issues.