What shipped, and when it was proven

Customers became a module of its own

An organisation can now keep the companies it works with — contacts, addresses, an activity log and a follow-up date — without installing time tracking or anything else. Opening one customer shows the projects being run for them, the hours those cost, the appointments they booked and the last thing anybody said to them, assembled from whichever modules are installed. A customer can be a company or a person, and the financial fields are absent rather than blank when nobody may see them.

Phase 4r, steps 4r.1–4r.19

Projects left time tracking and became their own surface

Projects no longer belong to the Time module. An organisation can say what it is working on, who owns it and what it owes by when, with milestones, status updates, risks, decisions and files on one screen alongside the project’s room and its boards. An organisation that also runs Time decides per project whether it appears there at all, and switching a project off stops it accepting new hours without losing any hour already booked. Links pasted into a room months ago still resolve after a project is renamed.

Phase 4q, steps 4q.1–4q.17

One agenda across everything on your day

A new agenda view collects what is actually on somebody’s day from six sources at once — appointments, milestones, absences and the rest — instead of asking them to check four screens. Appointments gained an owner and a project to book against, a completed appointment offers the hour it took, and a board can carry a project so a timer started from an item knows what to book against.

The day strip on the week board was planned for this step and was not built; it is recorded as deferred rather than done.

Phase 4n, steps 4n.1–4n.15

Links between modules resolve into cards

Dropping a link to a board item, a project, a person or a time entry into a room now shows a card describing it rather than a bare URL, resolved for the reader according to what that reader is allowed to see. Typing # in the composer searches across sixteen kinds of object and mentions one in a sentence. Boards learned what they cost — hours appear on the item and a timer starts from it — and notifications from every module arrive in one clickable inbox.

Phase 4m (Interconnection), steps 4m.1–4m.16

Employee cards, shareable and verifiable

Every employee gets a card derived from the employment in force on the date being asked about, which they can fill in themselves and send to a customer who saves the contact without signing in to anything. Each card carries a per-organisation signature, so somebody at reception can check that this person works here and in what position — and on the day the employment ends, the same check says so without anybody having revoked anything. A manager sees their report’s card and not their pay.

Wallet passes, the email-signature generator and batch printing were deferred and are not available.

Phase 4m (Cards), steps 4m.1–4m.15

The hosted service got a repeatable deployment

The hosted installation moved from a description to a scripted, documented procedure: a stack that joins an existing edge, secrets created rather than pasted, the object-store configuration rendered from one source, and a runbook written from an actual deployment rather than from the file. Three defects the first real run exposed were fixed at the root, and the procedure is recorded in the repository’s runbooks.

Session entries of 2026-08-05, `compose/stack.hosted.yaml` and `docs/runbooks/deploy-hosted.md`

One account, several organisations, one address each

Registration no longer asks anybody to choose an organisation first: the account, the organisation and the first membership are created together and the organisation is named from the username, then renamed in settings. Each organisation lives at its own address, and somebody who belongs to more than one switches between them from the rail without signing in again, seeing in each exactly what that membership allows. Sessions moved to a host-only cookie the browser will not hand to another organisation.

Phase 7b, steps 7b.1–7b.10

The tenant boundary became testable, then tested

The organisation is now asserted at one choke point rather than remembered at each call site, and a request for another organisation’s object is answered with a not-found rather than a forbidden — because a forbidden confirms that the object exists. A probe suite generated from the API description drives every operation across the boundary and asserts that all of them refuse: 203 driven, 203 refused. It runs on every build, so a regression fails continuous integration instead of reaching anybody.

Phase 7a, steps 7a.1–7a.11

Owners, administrators and roles an organisation names itself

Each organisation now has exactly one owner, enforced by the database and transferable, above an administrator and member ladder. On top of that, an organisation defines roles of its own over an organisation-level permission set, and a role can never carry a permission its author does not hold. The member roster, invitations, role changes and removal all moved into the organisation’s own settings.

Phase 7c, steps 7c.1–7c.6

A control plane that cannot read your content

The surface Enclessa operators use became a separate identity with its own sign-in, mandatory second factor, sessions and audit log. It can list organisations, see counts and states, suspend one and schedule a deletion — and it cannot read a message, a file or a personnel record. That is enforced by a check in continuous integration that forbids the control-plane package from importing anything capable of reading content, so it fails the build rather than a policy review.

Phase 7d, steps 7d.1–7d.9

Rate limits, storage accounting, retention and full export

The controls that matter after signature rather than at it. Rate limits apply per organisation and scale with seat count, with each member capped at a share, so one runaway integration cannot exhaust everybody else’s budget. Storage is accounted per organisation, retention is configurable per organisation with a default that keeps data, every metric and log line carries the organisation it belongs to, and an organisation can export everything the platform holds for it at any time.

Finer-grained retention per team and per channel, and export of the audit log to an external sink, are planned work and are not available.

Phase 7e, steps 7e.1–7e.5

People: records, org chart, onboarding and offboarding

Somebody can now be hired before they have an account. The People module holds employee records with effective-dated employment and compensation, organisational units, positions, locations and cost centres with a chart drawn from them, documents with versions and acknowledgements, self-service change requests, and onboarding and offboarding workflows that drive the other modules. Field visibility resolves across seven roles, so a manager sees what a manager may see and no more.

Phase 4k, steps 4k.1–4k.16

Time tracking: clock, timesheets, approvals and absence

Somebody clocks in, takes a break, clocks out and sees the right balance — computed from a ledger rather than stored in a column, so it can be shown line by line. Hours book against a customer’s project, an activity, a board item or a pull request; a week is submitted and a manager returns it; corrections supersede rather than overwrite; and holiday is requested against an entitlement that can be explained. An organisation that has not installed Time sees no navigation for it and answers not-found to every one of its routes.

Phase 4j, steps 4j.1–4j.14

The week, drawn rather than listed

Time tracking gained the four views it could already compute and not show: a week board where a timesheet is drawn and dragged instead of typed into a table, an hours account showing a year month by month and day by day, an absence planner covering everybody the viewer is allowed to see, and a personal list of what was requested and what came of it.

The absence planner is read-only by decision, not by omission.

Phase 4l, steps 4l.1–4l.13

Modules are installed, configured and suspended from one page

Optional surfaces stopped being feature flags and became installable modules. An administrator installs, suspends, resumes or uninstalls from a single catalogue page; each module gets a settings screen generated from what it declares; changes are stored as revisions so an earlier one can be rolled forward as a new revision rather than edited over; and an uninstalled module keeps its history for thirty days before it is purged. A module that is not installed answers not-found to every one of its routes.

Phases 4h and 4i, session of 2026-08-04

Task boards, next to the conversation

A decision made in a room turns into an item on a board, moves through columns the team defined, and appears as a table, a board with drag-and-drop, or a roadmap — the same items, three ways. Items carry fields, assignees, tags, dates, comments and a link back to the room they came from, and saved views keep whatever arrangement somebody works in.

Phase 4b, steps 4b.1–4b.9

GitHub mirrors a project onto a board

An administrator connects GitHub once and a board mirrors a project: cards arrive in the columns the team named, each showing whether its pull request is merged and whether its checks are green. Credentials are sealed rather than stored, webhooks are verified and logged, redelivery is idempotent, and an organisation can stop every outbound write with one setting without unlinking a board or revoking anything.

A sync against a live GitHub organisation has not been run — the credential for it does not exist on the build machine — so the connector is verified against a GitHub that actively refuses rather than one that accepts.

Phase 4c, steps 4c.1–4c.9

Bots, incoming webhooks and slash commands

A script holding a token can post as a bot into a room it was added to, a build system can post to a webhook URL with no account at all, and the built-in slash commands work in the composer alongside custom ones an organisation registers against its own HTTP endpoint. Tokens are scoped to named operations, and none of the three reaches the administration console.

Phase 4d, steps 4d.1–4d.5

Saying when not to be disturbed, and being obeyed

Status with an expiry, do-not-disturb, quiet hours and out-of-office now hold in email and in push rather than only in the interface. Keyword notifications reach somebody about a word they care about without their name being used, custom groups can be mentioned as one, a message written at midnight can be scheduled to arrive at nine, and a missed-message digest arrives by email.

Phase 4e, steps 4e.1–4e.7

Link previews, voice messages and search inside files

A pasted link explains itself without being clicked — fetched by the server behind protection against being pointed at internal addresses, never from the reader’s browser. Voice messages record, show a waveform and play back inline, mathematical notation renders, and a file somebody sent last month is findable by a word inside it rather than only by its name.

Phase 4f, steps 4f.1–4f.4

Video calls with screen sharing, a lobby and host controls

Calls run in any room and ad hoc: a stage with tiles, device pickers, screen sharing, in-call chat, reactions, raised hands, a lobby, host controls and an incoming-call ring. An ad-hoc call’s link works for somebody who was not rung. Media in encrypted rooms carries a key bound to the room’s own group rather than one the media server holds, and that handover was demonstrated between two browsers.

No call has been run at fifty people. The load harness exists and the test has not been executed, so Enclessa publishes no measured figure for call size. Recording exists for managed rooms and produces no downloadable file.

Phase 4, steps 4.1–4.14

Direct messages became end-to-end encrypted

Direct messages and group direct messages are end-to-end encrypted with MLS, the IETF standard published as RFC 9420, implemented with OpenMLS and compiled once in Rust so every client runs identical cryptographic code. Each device is a separate member of the group: adding one is visible, and revoking one re-keys the conversation so it can decrypt nothing sent afterwards. Attachments are encrypted with the message, devices are cross-signed, both sides compute the same safety number, and search in encrypted rooms runs on the reader’s own device against a local index because the server has nothing to index.

A second device of the same user does not yet sign itself: the identity key stays on the device that minted it until the encrypted key backup has an interface. The backup itself is built.

Phase 2, steps 2.1–2.9

Categories, custom roles and permission overwrites

A team can express that a shelf is for these people, that a room is read-only, and that these three may notify everybody — without an administrator touching a database. Permissions are a bitmask evaluated in the data layer rather than hidden in the interface, teams name roles of their own over it, and allow-or-deny overwrites apply per category and per channel. Who is in a public room is derived from the permission rather than maintained by hand.

Phase 2c, steps 2c.1–2c.9

Configuration without a shell, and a way back in

An operator with no access to the machine can set who may create an account, what the installation is called and where its mail goes, from the console — with what the console owns winning over the environment. Sign-up, invitation, email confirmation, password reset and changing your own password all work, with tokens hashed and single-use, so somebody who has forgotten their password does not need an administrator either.

Phase 2d, steps 2d.1–2d.9

Channels, threads, search, files and presence

The first usable Enclessa: teams, channels and threads with reactions, edits, deletes and mentions; messages arriving live over a WebSocket rather than on a refresh; uploads with thumbnails and malware scanning before anybody can open them; full-text search across messages; an activity feed with notification settings; an email pipeline; and an audit log of administrative action.

Phase 1, steps 1.1–1.13

The foundation, and the licence gate

The first working system: the database schema and its migrations, the API with a generated OpenAPI description, authentication with a device registry, telemetry, the design tokens the product is built from, and continuous integration — including the licence gate that fails the build if any runtime dependency stops being open source under an OSI-approved licence.

Phase 0, steps 0.1–0.9