mix
06c2014384
roadmap.md is linked from the README table, so it is a page strangers land on. Translated in full, with a note up front that none of it is a commitment: there are no dates, the order is a recommendation, and an item can be dropped once its plan is written. The note also points at product.md for the opposite question — what the project deliberately will not do — so absence from the roadmap is not read as a silent plan. The model assigned to inbound-relay is dropped from the item; model routing belongs in development.md, not in a statement of direction. The README row described the file as internal and Russian. It is now neither. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
4.6 KiB
Roadmap: open work (1.x+)
Status: a working tracker of extensions to the v1.0 boundary, each taken up
only after explicit agreement (product.md,
.cursor/rules/agent-rules.mdc). Detailed
design lives in plans/. Items marked candidate need an OK before
any code is written.
Reading this from outside the project: nothing here is a commitment or a release promise. There are no dates, the order is a recommendation rather than a schedule, and an item can be dropped or reshaped once its plan is written. What the project will not do is a separate question, answered in product.md — an item's absence from this file does not mean it is planned but unlisted.
Versioning: SemVer MINOR in the 1.x+ line by default (1.1.0…), as long
as defaults and migrations stay compatible with 1.0.0. A major 2.x only for
an explicit break.
Process: development.md. The history of closed phases is
in git log and CHANGELOG.md.
Index
| ID | Topic | Status | Plan |
|---|---|---|---|
| web-split | Splitting internal/web |
agreed | plans/web-split.md |
| domain-admin | Domain administrator role | agreed | plans/domain-admin.md |
| inbound-relay | Inbound relay (backup-MX / forwarding) | agreed | plans/inbound-relay.md |
| contributing | CONTRIBUTING.md |
candidate | — |
Recommended order (not binding): web-split → domain-admin → inbound-relay — first the package split, then role-wide authorisation, then the new vertical slice of the inbound relay. Deviating is allowed; there are no hard phases here.
After a context reset, pick an item marked agreed or in progress, then work
the checklist in its linked plan.
inbound-relay
Goal: optional acceptance of mail on port 25 for explicitly configured
domains, forwarded to an upstream (backup-MX / relay-forwarder). Off by default
(INBOUND_RELAY_ENABLE=false); without the flag the outbound path is
unchanged.
Boundary: an extension of v1.0 — product.md excludes inbound mail and mailboxes. This is relay/forward, not IMAP/POP3/webmail; an anti-spam engine stays outside the image, only the attachment point is provided.
Done when: see the criteria in plans/inbound-relay.md.
Dependencies / risks: a finished outbound path; open relay and backscatter;
a wider attack surface (port 25 accepting mail).
Order: recommended after web-split and
domain-admin.
Version: target bump 1.x; 2.x possible — to be settled once the
implementation lands.
domain-admin
Goal: a role with access to one or several assigned domains (the list is
set by the global administrator) — applications, DKIM/DNS, and the send log for
each of them; without global operations (adding domains, full backup, the
queue, mail.log).
Boundary: an extension of v1.0 — product.md fixes a single administrator. Not a second all-powerful admin, but limited access to the assigned domains (one or several).
Done when: see plans/domain-admin.md.
Dependencies / risks: a users table, the role in the session, authorisation
in every handler, setup and backup. Order: recommended after
web-split, before
inbound-relay.
Version: 1.x MINOR, given a compatible migration of the current
administrator into a global one.
web-split
Goal: deliberately split internal/web (or settle on keeping the package
flat) before it grows under inbound-relay and domain-admin.
Boundary: an internal refactor; the panel's behaviour for the operator does not change.
Done when: the package is split along the chosen scheme, or it is settled that it stays flat — see plans/web-split.md.
Dependencies / risks: exporting a package-private API. Order:
recommended first among the agreed features (before domain-admin and
inbound-relay).
Version: 1.x; on its own it does not force a break.
contributing
Goal: CONTRIBUTING.md in the root — the dev loop, the checks to run
before a PR, the commit protocol; development.md links to it
rather than repeating it.
Boundary: process documentation; worth writing once there is an external flow of PRs.
Done when: the file is in the root and development.md does not duplicate it.
Dependencies / risks: with a single developer and no PRs, this is low priority. Version: no bearing on semver.