serverless-ircd 0.7.0 → 0.8.0

package/docs/PlanExtensions.md

@@ -253,9 +253,30 @@ connection is not identified as. The dispatch layer resolves it against
 Already-present seams the services reuse:
 
 - `AccountStore.verify('PLAIN', ...)` (TICKET-026 ✅) → a successful
-  NickServ `IDENTIFY` and a SASL PLAIN login both reduce to "this
-  connection is now account X", setting the `+r` user mode and
-  emitting `ACCOUNT` to `account-notify`-capable peers.
+  NickServ `IDENTIFY`, a SASL PLAIN login, and a PASS-based account login
+  (TICKET-152 ✅) all reduce to "this connection is now account X". The
+  shared `applyAccountSuccess(state, ctx, account)` helper stamps the
+  account, sets the `+r` user mode, restores per-account state (read
+  markers, persisted away, queued memos), and emits `900 RPL_LOGGEDIN` +
+  `903 RPL_SASLSUCCESS` plus the `ACCOUNT` broadcast to
+  `account-notify`-capable peers.
+- **PASS-based account auth (TICKET-152 ✅)** — a third account-login
+  entry point alongside SASL and NickServ `IDENTIFY`. A client that sends
+  `NICK <nick>` then `PASS <nick>:<password>` (then `USER`) is identified
+  to `ctx.accounts` at registration completion without speaking SASL. The
+  `<nick>:<password>` literal matches the `SASL_ACCOUNTS` seed format. The
+  payload nick (left of the first `:`) is the account name and MUST equal
+  `state.nick` at registration completion. Order of precedence at
+  registration is: (1) already identified (SASL/PASS-auth) → gate
+  satisfied; (2) `<nick>:<password>` verifies against `ctx.accounts` →
+  account set; (3) bare `PASS` matches `serverPassword` → gate satisfied;
+  (4) else `464 ERR_PASSWDMISMATCH` + disconnect. A bare `PASS <value>`
+  (no colon) is always a server-password candidate, never an account
+  credential; when `ctx.accounts` is unbound the `<nick>:<password>` form
+  is ignored and behaviour collapses to the server-password gate. Like
+  SASL, PASS-auth runs through `applyAccountSuccess` and therefore stamps
+  `+r`; a failed verify reveals nothing — unknown nick and wrong password
+  are indistinguishable (a fixed dummy verify equalises the failure path).
 - `MessageStore` (TICKET-063 ✅) → MemoServ's `SEND` is a record into
   a per-account memo queue; delivery is a fanout at identify time.
 - `clock` / `IdFactory` ports → memo ids, enforcement grace timers.
@@ -464,6 +485,52 @@ follows strict TDD (Red → Green → Refactor) per `CLAUDE.md` /
   `seedReadMarkers`; `CHATHISTORY BEFORE` with no pivot falls back to the
   connection's marker. TICKET-122 should fold this store into the unified
   services `UserStore` when it lands.
+- **Divergence vs. spec compliance (TICKET-150 follow-up, shipped):**
+  TICKET-118 shipped **channel-wide** mark TAGMSG fanout for pragmatic parity
+  with the `draft/typing` precedent — every `message-tags` OR
+  `draft/read-marker` peer in the channel received the mark. The ircv3
+  `draft/read-marker` spec, however, mandates that a read marker **MUST NOT be
+  disclosed to other users**: a client's own mark is private to its account.
+  The Phase 14 follow-up (account-scoped `draft/read-marker` fanout) restored
+  spec compliance with two behaviour changes:
+
+  1. **Identified originator → account-scoped fanout.** The
+     `tagmsgChannelReducer` now annotates the mark `TAGMSG` Broadcast effect
+     with the originator's `account`. The dispatch layer's cap-aware
+     `broadcast()` restricts the recipient set to channel members
+     authenticated as that same account (RFC 1459 case-folded comparison),
+     still honouring `except` (originator skip) and the OR-semantics `caps`
+     filter (`message-tags` OR `draft/read-marker`). Other accounts in the
+     channel never receive the mark; the originator's other live sessions on
+     the same account (multi-device sync, when they share the channel)
+     receive it. `filterClientTags` and its `+draft/read-marker` whitelist
+     are unchanged — only the *recipient set* changes.
+  2. **Unidentified originator → no fanout (session-local).** An
+     unidentified connection (no account) emits **no** Broadcast for a read-
+     marker mark. Its mark stays session-local (the in-memory
+     `lastReadMarkers` still advances; persistence is a no-op without an
+     account, unchanged from TICKET-118). The originator's own client still
+     observes its mark via the `echo-message` self-echo. This matches the
+     spec's privacy default: a read marker never reaches *other* users, and
+     an unidentified connection has no account to share a mark with.
+
+  **Recipient-resolution primitive ("or equivalent" index).** The ticket's
+  description floated an `AccountConnections` index on the runtime. The
+  shipped implementation takes the spec-permitted "(or equivalent)" path:
+  there is **no separate index structure**. The recipient set is resolved at
+  dispatch time by walking the channel roster and consulting each member's
+  live `ConnectionState.account` via the existing `getConnectionInfo` port
+  method (the same per-recipient resolution already used for cap gating).
+  This is always fresh by construction — disconnected connections leave the
+  roster, and account changes are live references — so the staleness
+  concerns an explicit index would need (re-sync on `ACCOUNT`/SASL/
+  disconnect) do not apply. Global cross-channel account fanout (reaching an
+  account's sessions that are *not* in the marked channel) is a documented
+  follow-up, not needed for spec privacy: the mark is channel-specific, and
+  the persistence layer (`ServicesStore.setLastReadMarker`) already syncs a
+  session's marker on reconnect/rejoin via `seedReadMarkers`. 100% coverage
+  on the account-scoped fanout + dispatch filter (irc-core and irc-server
+  both enforce a 100% gate).
 
 #### TICKET-119 — IRCv3 `draft/pre-away` (persist away status)
 - **Phase:** 12
@@ -613,6 +680,49 @@ follows strict TDD (Red → Green → Refactor) per `CLAUDE.md` /
 - **TDD Outline:** Red on REGISTER→`+r`; green; then `+R`/`+M`;
   then KEEPTOPIC; then MLOCK.
 
+  Implementation notes (post-land):
+  - Three new boolean channel modes added to `ChannelModes`:
+    `registered` (`+r`), `blockUnidentified` (`+R`), `moderatedIdent`
+    (`+M`). They appear in the `324 RPL_CHANNELMODEIS` reply when set,
+    but `channelModeReducer` rejects `+r`/`+R`/`+M` via `MODE` with `472
+    ERR_UNKNOWNMODE` — only ChanServ may toggle them via
+    `ApplyChannelDelta` effects.
+  - `519 ERR_ALLMUSTREGISTER` added to `Numerics` for the `+R` JOIN gate.
+  - `ServicesStore` extended: `getChannel`, `setChannelFounder`,
+    `setChannelMlock`/`getChannelMlock`, `setChannelRestricted`,
+    `setChannelKeepTopic`, `setChannelTopic`/`getChannelTopic`. The
+    `RegisteredChannel` record now carries `mlock` / `restricted` /
+    `keepTopic` / `topic?`. The in-memory store returns defensive
+    copies (callers cannot mutate the store by editing returned
+    records).
+  - `chanservReducer` (new, `commands/chanserv.ts`) handles
+    `PRIVMSG ChanServ :<command>`. Subcommands: `REGISTER`, `DROP`,
+    `INFO`, `SET FOUNDER/MLOCK/RESTRICTED/KEEPTOPIC`. Channel
+    mutations are emitted as `ApplyChannelDelta` effects so the actor
+    applies them to the authoritative `ChannelState`.
+  - `SET RESTRICTED ON|OFF` toggles the `+R` channel mode (and stores
+    the preference). `SET KEEPTOPIC ON|OFF` toggles topic persistence
+    and drops any previously-stored snapshot when turned off.
+  - JOIN reducer consults services on the first join after empty-recreate
+    to restore a KEEPTOPIC snapshot (emits `332`/`333` to the joiner).
+    `+R` JOIN gate rejects unidentified clients with `519`.
+  - TOPIC reducer persists the snapshot on every change (set or clear)
+    when KEEPTOPIC is on.
+  - PRIVMSG/NOTICE channel reducers enforce `+M` (op/voice/identified
+    pass) and `+R` (identified pass) with `404`; NOTICE is silent.
+  - `channelModeReducer` reapplies MLOCK after every applied MODE: any
+    positively-locked boolean mode that ended up unset (whether by this
+    MODE or by prior state) is re-asserted via a ChanServ-emitted
+    `ApplyChannelDelta` + `Broadcast` (`:ChanServ!ChanServ@services
+    MODE #chan +…`). Defence in depth — services-only modes (`+r`) are
+    also defended, so the registered mark survives even if a future
+    code path applies an `ApplyChannelDelta` clearing it.
+  - Actor routes `PRIVMSG ChanServ` (case-insensitive) to
+    `reducers.chanserv`; NOTICE and unbound-services cases fall through
+    to the normal user-target reducer (RFC: NOTICE is silent).
+  - 100% coverage on `chanserv.ts`, `mode.ts` (reapply branch), and the
+    new join/privmsg/topic branches.
+
 #### TICKET-126 — ChanServ: ACCESS / LEVELS (SOP/AOP/VOP/HOP)
 - **Phase:** 13
 - **Points:** 5

package/docs/Release-Process.md

@@ -15,8 +15,8 @@ opening a PR that bumps versions and updates `CHANGELOG.md`; the
 maintainer team cuts the tag.
 
 Cross-reference: `README.md` (Roadmap), `progress.md` / `tickets.md`
-(release content), `docs/deployment-cf.md` (prod deploy step §6),
-`.github/workflows/ci.yml`, `.github/workflows/deploy-cf.yml`.
+(release content), `docs/Cloudflare-Deployment-Guide.md` (prod deploy
+step §6), `.github/workflows/ci.yml`, `.github/workflows/deploy-cf.yml`.
 
 ---
 
@@ -37,7 +37,7 @@ this repo itself) should pin exact versions.
 
 ### 1.1 Workspace version lock
 
-All eight `package.json` files (root + 7 workspace packages) carry the
+All fifteen `package.json` files (root + 14 workspace packages) carry the
 **same** version string. They are bumped together in the release
 commit. The pre-release checklist in §4 enforces this.
 
@@ -132,17 +132,20 @@ node apps/cf-worker/scripts/smoke.mjs \
 If any box fails, **stop**. Fix forward on `main` and restart the
 checklist — do not tag over a broken tip.
 
-### 4.1 What is explicitly out of scope for a 0.x release
+### 4.1 What is explicitly out of scope for the 0.x line
 
-- AWS adapter (TICKET-039 through TICKET-044).
-- SASL authentication (TICKET-026).
-- Flood control (TICKET-028).
-- Server password / rate limits / cloaking (TICKET-046).
-- Config loader (TICKET-047).
+Items still pending in `progress.md` that are **not** blockers for a
+given release — they ship when ready and are called out under "Known
+limitations" in the GitHub Release body:
 
-These belong in a later 0.x release. Their absence is **not** a
-blocker and should be called out under "Known limitations" in the
-GitHub Release body.
+- Client compatibility sweep (WeeChat / HexChat / IRCCloud / TheLounge /
+  matrix-IRC bridge) — `progress.md` TICKET-050.
+- Playwright headless-browser e2e for the web client — TICKET-138.
+- Driving the sub-100% packages to full coverage — TICKET-143 through
+  TICKET-148.
+
+Their absence is **not** a blocker. If a release intentionally defers an
+in-progress ticket, name it under "Known limitations".
 
 ---
 
@@ -184,7 +187,7 @@ understand what changed and what they need to do.
 
 ## 6. Bumping versions
 
-There are eight `package.json` files. They must end up at the same
+There are fifteen `package.json` files. They must end up at the same
 version:
 
 ```
@@ -192,10 +195,17 @@ version:
 packages/irc-core/package.json
 packages/irc-server/package.json
 packages/in-memory-runtime/package.json
+packages/irc-test-support/package.json
 packages/cf-adapter/package.json
+packages/aws-adapter/package.json
 apps/local-cli/package.json
 apps/cf-worker/package.json
+apps/cf-tcp-container/package.json
+apps/aws-stack/package.json
+apps/web/package.json
 tools/tcp-ws-forwarder/package.json
+tools/load-test/package.json
+tools/ci-hardening/package.json
 ```
 
 To cut `v0.X.Y`: