AppSweet backend 0.1.0-build.115

One AppSweet server can now host several organisations. The server owner creates and renames them in
the console, and people use one account to join and switch between the organisations they belong to.

Use the matching new AppSweet desktop release. Older desktops must update before connecting to this
server. Servers already using built-in sign-in follow the normal update process; servers from before
that switch still need a fresh installation, and their earlier backups cannot be restored here.
Arrange the new desktop's one-time local reset with your team before its first launch: send pending
work, export local copies to keep and sign out of the earlier desktop first.

New

• Create and rename organisations in the console, with separate workspaces and membership for each.
• Invite existing account holders to another organisation, invite owners, and let recipients decline
  an invitation.
• See whether invitations are queued, sent or failed, and retry delivery after fixing email settings.
• Receive security emails when a password or two-step verification setting changes.

Improved

• Switch an account's active organisation without exposing another organisation's data.
• Account removal and membership changes revoke the affected access while keeping other
  organisations available.
• Changes waiting to be sent are counted before leaving, and server restores can be distinguished
  from the previous installation.
• Invitation and sign-in pages clearly show the server, recipient and organisation in English or Dutch.
• File documents in nested folders and open resources linked from other items.

Fixed

• Organisation settings recover from an interrupted save or failed list refresh without losing a
  confirmed change.
• Member actions refresh the list before another action can use outdated information.
• Setup reports clearer storage errors and waits for new HTTPS addresses before verifying them.

AppSweet desktop 0.1.0-build.39

AppSweet desktop 0.1.0-build.39 for Apple Silicon. Each installer is byte-identical to the signed candidate published at https://releases.appsweet.app/desktop/builds/0.1.0-build.39/candidate.json.

AppSweet backend 0.1.0-build.114

New

• Open on a Today dashboard of personal Do today todos
• Simpler Dokploy install

Fixed

• Name the Do today marks policy like every tenant policy

AppSweet backend 0.1.0-build.113

No user-facing changes were recorded for this build.

AppSweet backend 0.1.0-build.112

Sign-in is now built into the AppSweet server. The separate sign-in service, its database and its own
web address are gone: people sign in at the app's address, and the server sends invitation and
password-reset emails itself, with the company's email settings.

This version cannot be installed as an update. A server running an earlier version is refused before
anything changes and stays on its current version. To move to this version, install it fresh and
invite your team again: data from the earlier server does not carry over, and backups made before this
version cannot be restored into it (a restore refuses them and names the version that made them). The
owner's first app password is the console password; after that the two are separate. Use the latest
AppSweet desktop app: earlier desktop apps are asked to update before they connect.

New

• Invite teammates by email, change their role or remove them in the desktop app (Settings → Members).
  The invitation carries the desktop download link and the company address.
• Forgot your password? Reset it by email from the sign-in page.
• Optional two-step verification with an authenticator app, with single-use recovery codes.
• Change your name, password and two-step verification in the desktop app (Settings → Account
  security).
• The console sends a test email, and activation needs one that the mail server accepted.
• The console lists the company's members and can issue a one-time password-reset link or reset
  someone's two-step verification when email cannot help.

AppSweet backend 0.1.0-build.111

New

• Re-apply the retained definition over platform drift (task 6.3)
• Automatic Dokploy key rotation (task 6.5)
• Dormant update-hop executor and eligibility mode (stage 7.2)
• Hop document formats, contract probe and the hop/1 image label
• Repair credential-only platform drift automatically (stage 6.8)
• Per-operation credentials and the Dokploy key-minting probe (stage 6.1-6.2)
• Read-only platform drift detection (stage 5)
• Record and show why an update stopped (stage 4, failure codes)

Fixed

• The minted key's id is committed beside the key, so a lost rotation journal still retires it
• An unsettled mint stays pending, rotation work refreshes drift, and old repair outcomes stay off general drift
• A pending key rotation resumes with a one-time key when the drift key is unreadable
• A rotation writes past registry drift, and the credential-file writer is bounded
• A pending key rotation that cannot finish is named in the drift status
• A key rotation is verified by the Dokploy key slot alone
• An eligibility decision must agree with its reason
• Retired-key revocation never waits on the drift fingerprint key
• An unreadable key-rotation record is logged and named in the console, never silent
• An eligibility answer is honoured only from the releases the bootstrap asked
• A pending credential repair is read from the projection, so it survives an agent restart
• A restored previous release needs an explicit started marker
• A hop status's backup record id is an identifier, never free text
• An unknown hop phase's commit still counts, and a committed attempt never ends previous_release_restored
• A running or successful hop status carries no failure
• Read the hop's database credential from its source copy and keep restore verification state 0700
• Nothing may follow a terminal hop phase, not even an unrecognized one
• Retry retired-key revocation off-schedule, re-check drift after a recovered rotation, and name the layout remedy
• A hop status's phases must form a mirrorable history under its disruption marker and plan
• Trust the hop's source copy only once its journal records the acquisition
• Give the drift-repair migration its own version after development's 20261003000200
• An unrecognized hop state may not end terminal, and every phase carries its facts
• The credential-file writer keeps FOWNER to set the mode after the chown
• Restore the queued-update backup repair exclusion
• A hop status must agree with its journal and write-ahead marker
• …and 16 more

AppSweet backend 0.1.0-build.110

New

• Upgrade-rehearsal core + local-pair mode (#968 stage 2)
• Require the update mid-session and guide a move to Applications

Fixed

• Four small confirmed fixes
• Isolate the managed OAuth key restore and accept it in the bundle contract
• Docs crash in release builds (chunk cycle), Docs startup waits out the shared engine, route errors show details

AppSweet backend 0.1.0-build.109

No user-facing changes were recorded for this build.

AppSweet backend 0.1.0-build.108

New

• Manage the pinned local model lifecycle
• Connect owned worker to ordinary chat
• Qualify HM5.0 staged worker and retain not-qualified result
• Finish HM4.2 runtime screening
• Add HM4.2 accounting and native comparison jobs
• Leased connections, bounded write-ahead logs, one instance per profile (Phase 1a)
• Performance baseline instrumentation (Phase 0)
• Split key results into their own wizard

Fixed

• Keep the next alpha buildable and installable by what is in the field
• Restore verified model after relaunch and repair setup dead ends
• Share the key-version lock, and isolate the dispatch test that plants a backlog
• Terminalize staged runner failures

Performance

• The mutation receipt is a marker, and Phase 5 is complete
• The event log is pruned, and no client or consumer loses state to it
• A fresh client starts from a snapshot, not the whole log
• Idle worker under budget, no idle Goals events, batched resync
• Deliver an event from one resolution per process (Phase 4, realtime-delivery)
• Goals cycle detail in two queries, every module list read paged (goals-reads)
• The sync mutation path (sync-mutation-path)
• The preamble every request pays (request-preamble)
• Lifecycle-socket — one connection per session, a subscription per workspace (Phase 3)
• Startup-bundle — fonts from the bundle, screens with their route (Phase 3)
• Startup-path — the request path of a start (Phase 3)

AppSweet backend 0.1.0-build.107

Complete signed AppSweet backend build from source commit 16e0d174cef454aff270c095656430c948076db6.