serverless-ircd 0.2.0 → 0.4.0

package/tickets.md

@@ -1,2485 +0,0 @@
-# ServerlessIRCd — Tickets
-
-Derived from `PLAN.md` §7 Roadmap. Phase 0 (Foundation) is already completed.
-Points use the Fibonacci scale (8 points ≈ 1 week for a human developer).
-Development follows strict TDD (Red → Green → Refactor). Every ticket starts
-with a failing test.
-
-Status legend: ⬜ pending · 🔄 in-progress · ✅ done · 🚫 blocked
-
----
-
-## Phase 1 — Pure protocol engine (no cloud)
-
-### TICKET-001 — Core state shapes, `Effect` taxonomy, `dispatch` interpreter
-- **Phase:** 1
-- **Points:** 5
-- **Status:** ✅
-- **Dependencies:** —
-- **Description:** Define the pure core of `irc-core`: the `IrcState` shapes
-  (`ConnectionState`, `ChannelState`, `Roster`, `Registry`), the discriminated
-  union `Effect` taxonomy (`Send`, `Broadcast`, `Disconnect`, `ReserveNick`,
-  `ChangeNick`, `ReleaseNick`, `ApplyChannelDelta`, `Lookup`…), and the
-  `Reducer<S>` signature
-  `(state, msg, ctx) => { state, effects }`. Implement
-  `dispatch(effects, runtime)` that interprets an `Effect[]` against the
-  `IrcRuntime` port (port defined here as an interface; concrete runtimes come
-  later). Add ports `Clock` and `IdFactory` for deterministic time/IDs.
-- **Acceptance Criteria:**
-  - All type files compile under `tsconfig.base.json` strict mode.
-  - `dispatch` is unit-tested with a fake `IrcRuntime` recording calls;
-    ordering and dedup of effects verified.
-  - `Effect` union covers every side-effect referenced in PLAN §2.1.
-  - 100% coverage on `dispatch.ts`, `effects.ts`, `types.ts`, ports.
-- **TDD Outline:**
-  1. Red: write a test asserting `dispatch([Send(...), Broadcast(...)])`
-     calls the fake runtime in order — fails (no `dispatch`).
-  2. Green: implement `dispatch` as a thin loop.
-  3. Refactor: extract effect handlers into a dispatch table keyed by
-     effect tag.
-
-### TICKET-002 — `PING` / `PONG` reducer
-- **Phase:** 1
-- **Points:** 1
-- **Status:** ✅
-- **Dependencies:** TICKET-001
-- **Description:** Pure reducer for client `PING` (server replies `PONG`)
-  and server-initiated `PING` (emits `Send(PING)`; expects client `PONG`).
-  Idle/PING bookkeeping is the runtime's job; reducer only emits replies.
-- **Acceptance Criteria:**
-  - `PING <token>` → emits `PONG <token>` to sender.
-  - Missing token still produces a `PONG` (per modern client behavior).
-  - No state mutation beyond last-seen.
-- **TDD Outline:** Red on "ping with token returns matching pong"; green;
-  cover missing-token + uppercase/lowercase variants.
-
-### TICKET-003 — `QUIT` reducer
-- **Phase:** 1
-- **Points:** 2
-- **Status:** ✅
-- **Dependencies:** TICKET-001
-- **Description:** Pure reducer for `QUIT [reason]`. Emits `Broadcast(QUIT)`
-  to every channel the user is in, `Disconnect`, `ReleaseNick`, and a
-  `ChannelDelta` removing the user from each channel roster.
-- **Acceptance Criteria:**
-  - All joined channels receive the QUIT message.
-  - Nick is released in the registry effect.
-  - Reason defaults to the connection's configured quit message.
-  - Idempotent if connection had not yet registered.
-- **TDD Outline:** Red on "quit broadcasts to two channels"; green; cover
-  no-channels case + unregistered-connection case.
-
-### TICKET-004 — Registration reducers: `NICK` / `USER` / `PASS` (core)
-- **Phase:** 1
-- **Points:** 5
-- **Status:** ✅
-- **Dependencies:** TICKET-001
-- **Description:** Pure reducers for the registration handshake
-  (pre-`CAP`). `NICK` reserves via `ReserveNick` effect and validates
-  nick grammar (`nick = [a-zA-Z][\w-\[\]\\\`\^{|}]*`). `USER` stores
-  username/realname. `PASS` stashes the server password for validation.
-  On completion emits welcome numerics `001`–`005` placeholder (005 filled
-  in TICKET-024), `375`/`372`/`376` MOTD placeholders.
-- **Acceptance Criteria:**
-  - Invalid nick → `432`/`433` as appropriate.
-  - Already-registered → `462`.
-  - Welcome sequence only fires once NICK *and* USER are received.
-  - `PASS` mismatch → close with effect (server-password enforcement
-    lives in TICKET-030; this reducer only records the attempt).
-- **TDD Outline:** Red on "nick + user → emits 001..005"; green; then add
-  each error path as its own test.
-
-### TICKET-005 — `JOIN` reducer
-- **Phase:** 1
-- **Points:** 5
-- **Status:** ✅
-- **Dependencies:** TICKET-001, TICKET-004
-- **Description:** Pure reducer for `JOIN <chan>{,<chan>} [<key>{,<key>}]`.
-  Validates channel name grammar & allowed prefixes; honors `k` (key), `i`
-  (invite-only), `l` (limit), `b` (ban) on channel state. Emits
-  `Broadcast(JOIN)` to the channel including the joiner, followed by the
-  joiner's `353` NAMES list and `366` end-of-names.
-- **Acceptance Criteria:**
-  - Join cascade produces the correct RFC-compliant message order.
-  - `JOIN 0` parts all channels (legacy edge case) — tested.
-  - Channel key checked against channel state's `k`.
-  - Limits: max channels per user (configurable via `ctx`).
-- **TDD Outline:** Red on "join #foo → broadcasts JOIN + sends 353/366";
-  green; then one test per rejection (`403`, `471`, `473`, `475`,
-  `405`).
-
-### TICKET-006 — `PART` reducer
-- **Phase:** 1
-- **Points:** 2
-- **Status:** ✅
-- **Dependencies:** TICKET-001, TICKET-005
-- **Description:** Pure reducer for `PART <chan>{,<chan>} [:reason]`.
-- **Acceptance Criteria:**
-  - Not on channel → `441`.
-  - No such channel → `403`.
-  - Broadcasts `PART` to channel; updates roster via `ChannelDelta`.
-- **TDD Outline:** Red on "part with reason"; green; then negative paths.
-
-### TICKET-007 — `PRIVMSG` / `NOTICE` reducer (channel + private)
-- **Phase:** 1
-- **Points:** 3
-- **Status:** ✅
-- **Dependencies:** TICKET-001, TICKET-005
-- **Description:** Pure reducer for `PRIVMSG`/`NOTICE` to channels and to
-  users. Channel target fans out via `Broadcast`; user target routes via
-  `LookupNick` → `Send`. Enforces `+n` (no external), `+m` (moderated),
-  `+b` (ban). No echoes unless `echo-message` cap is set (handled in
-  TICKET-014). `NOTICE` MUST NEVER produce numeric error replies
-  (RFC-critical).
-- **Acceptance Criteria:**
-  - Channel PRIVMSG broadcasts to all members except sender (unless
-    echo-message).
-  - Private PRIVMSG to offline user → `401` for PRIVMSG; silent for NOTICE.
-  - 512-byte truncation handled in parser (TICKET-001 foundation); reducer
-    enforces max target count.
-- **TDD Outline:** Red on channel PRIVMSG; green; then NOTICE silence path
-  + ban/+n/+m rejection paths.
-
-### TICKET-008 — `TOPIC` reducer
-- **Phase:** 1
-- **Points:** 3
-- **Status:** ✅
-- **Dependencies:** TICKET-001, TICKET-005
-- **Description:** Pure reducer for `TOPIC <chan> [:topic]`. Reads emit
-  `331` (no topic) or `332` + `333` (setter/time). Writes honor `+t`
-  (op-only) → `482` for non-ops.
-- **Acceptance Criteria:**
-  - Not on channel → `442`.
-  - No such channel → `403`.
-  - Topic length cap configurable in `ctx`.
-- **TDD Outline:** Red on set topic; green; then read variants and `+t`
-  enforcement.
-
-### TICKET-009 — `NAMES` reducer
-- **Phase:** 1
-- **Points:** 2
-- **Status:** ✅
-- **Dependencies:** TICKET-001, TICKET-005
-- **Description:** Pure reducer for `NAMES [<chan>{,<chan>}]`. Emits
-  `353`/`366`. Honors `+s` (secret) / `+p` (private): non-members cannot
-  list.
-- **Acceptance Criteria:**
-  - Multi-prefix output depends on the client's `multi-prefix` cap
-    (plumbed through `ctx`).
-  - No args → all visible channels + a final "end of list" `366` per
-    modern clients.
-- **TDD Outline:** Red on names of joined channel; green; then secret
-  channel exclusion.
-
-### TICKET-010 — `MOTD` reducer
-- **Phase:** 1
-- **Points:** 1
-- **Status:** ✅
-- **Dependencies:** TICKET-001, TICKET-004
-- **Description:** Pure reducer for `MOTD`. Reads the MOTD from a
-  `MotdProvider` port (so adapters can supply from KV/D1/SecretsManager).
-  Emits `375`/`372`×N/`376`, or `422` if no MOTD.
-- **Acceptance Criteria:**
-  - Empty MOTD → `422`.
-  - Long lines split per the 512-byte (incl. tags) limit.
-- **TDD Outline:** Red on "motd with 3 lines emits 3×372"; green.
-
-### TICKET-011 — `MODE` reducer (channel + user)
-- **Phase:** 1
-- **Points:** 8
-- **Status:** ⬜
-- **Dependencies:** TICKET-001, TICKET-005
-- **Description:** Pure reducer for `MODE`. Two surfaces: channel modes
-  (`o v b i k l t n m s p` — op, voice, ban, invite-only, key, limit,
-  topic-lock, no-external, moderated, secret, private) and user modes
-  (`i o w s`). Modes parsed into an additive/subtractive delta. Ban masks
-  produce `367`/`368` list replies.
-- **Acceptance Criteria:**
-  - All channel mode letters tested for set, unset, and invalid.
-  - Op/voice prefix changes broadcast `MODE` to the channel.
-  - `l` requires a numeric argument; `k` requires a key arg.
-  - Non-op attempting mode change → `482`.
-  - Unknown mode char → `472`.
-- **TDD Outline:** Red on simple `+t`; green; then incrementally add modes
-  one test at a time. Refactor to a mode table-driven parser.
-
-### TICKET-012 — `KICK` reducer
-- **Phase:** 1
-- **Points:** 3
-- **Status:** ⬜
-- **Dependencies:** TICKET-001, TICKET-005, TICKET-011
-- **Description:** Pure reducer for `KICK <chan> <user> [:reason]`.
-- **Acceptance Criteria:**
-  - Not op → `482`.
-  - Target not on channel → `441`.
-  - Kicker not on channel → `442`.
-  - Broadcasts `KICK` then updates roster.
-- **TDD Outline:** Red on successful kick; green; then each error path.
-
-### TICKET-013 — `INVITE` reducer
-- **Phase:** 1
-- **Points:** 3
-- **Status:** ⬜
-- **Dependencies:** TICKET-001, TICKET-005, TICKET-011
-- **Description:** Pure reducer for `INVITE`. Sends `341` to inviter and an
-  `INVITE` notice to the invitee; records pending invite in channel state
-  so a later `JOIN` bypasses `+i`. Honors channel `+i` requiring inviter
-  to be a member (operator-only if configured).
-- **Acceptance Criteria:**
-  - Invite to nonexistent channel → `403`.
-  - Invitee already on channel → `443`.
-  - Pending invite allows join past `+i` until consumed or expired.
-- **TDD Outline:** Red on successful invite; green; then edge cases.
-
-### TICKET-014 — `WHO` reducer
-- **Phase:** 1
-- **Points:** 3
-- **Status:** ⬜
-- **Dependencies:** TICKET-001, TICKET-005
-- **Description:** Pure reducer for `WHO [<mask>] [o]`. Emits `352` per
-  match then `315`. Honors `+i` (invisible) user mode and `+s` channels.
-- **Acceptance Criteria:**
-  - `WHO #chan` lists members.
-  - Invisible users only shown if the requester shares a channel.
-  - Operator flag (`*`) and away flag (`H`/`G`) correct in `352`.
-- **TDD Outline:** Red on WHO of a joined channel; green; then `+i`
-  filtering.
-
-### TICKET-015 — `WHOIS` reducer
-- **Phase:** 1
-- **Points:** 3
-- **Status:** ⬜
-- **Dependencies:** TICKET-001, TICKET-004
-- **Description:** Pure reducer for `WHOIS <nick>{,<nick>}`. Emits
-  `311`/`319`/`312`/`317`/`318` (and `330` account when the
-  `account-tag`/`extended-join` data is available).
-- **Acceptance Criteria:**
-  - Unknown nick → `401` then `318`.
-  - Idle seconds & signon time sourced from `ConnSnapshot`.
-  - Channels list truncated / hidden per `+s`/`+p`.
-- **TDD Outline:** Red on WHOIS of registered user; green; then unknown
-  nick and secret-channel filtering.
-
-### TICKET-016 — `LIST` reducer
-- **Phase:** 1
-- **Points:** 2
-- **Status:** ⬜
-- **Dependencies:** TICKET-001, TICKET-005
-- **Description:** Pure reducer for `LIST [<chan>{,<chan>}]`. Emits `321`,
-  one `322` per channel, `323`. Secret channels hidden from non-members.
-- **Acceptance Criteria:**
-  - `LIST` with no args → all non-secret channels.
-  - Specific channel list → only those channels.
-  - Capped result set (configurable) to prevent thundering-herd
-    (PLAN §10 risk).
-- **TDD Outline:** Red on LIST of public channels; green; then `+s`
-  filtering.
-
-### TICKET-017 — IRCv3 `CAP` negotiation (`LS`/`REQ`/`ACK`/`NAK`/`END`/`LIST`/`NEW`/`DEL`)
-- **Phase:** 1
-- **Points:** 3
-- **Status:** ⬜
-- **Dependencies:** TICKET-001, TICKET-004
-- **Description:** Pure reducer for the `CAP` command and the
-  `capabilities.ts` capability table. Maintains connection's negotiated cap
-  set in `ConnectionState`.
-- **Acceptance Criteria:**
-  - `CAP LS` → `* LS :<caps>` (multiline if needed).
-  - `CAP REQ` validates each requested cap; ACKs supported, NAKs unknown.
-  - `CAP END` triggers the welcome sequence if registration is otherwise
-    complete.
-  - All caps from PLAN §3 listed in the table (their *behaviors* ship in
-    later tickets; the table itself ships here as data).
-- **TDD Outline:** Red on `CAP LS` response; green; then ACK/NAK matrix.
-
-### TICKET-018 — IRCv3 `message-tags` + `server-time`
-- **Phase:** 1
-- **Points:** 3
-- **Status:** ⬜
-- **Dependencies:** TICKET-017
-- **Description:** Implement `message-tags` (client `+tag` send +
-  server-tag emission) and `server-time` (prepend `@time=...` on all
-  outbound messages). Hook into serializer (TICKET-001 foundation).
-- **Acceptance Criteria:**
-  - Time format is ISO-8601 with milliseconds (`yyyy-MM-ddTHH:mm:ss.sssZ`).
-  - Tag values escaped/unescaped per spec.
-  - Tags only emitted to clients who negotiated the relevant cap.
-  - 512-byte limit includes tags for clients that have `message-tags`.
-- **TDD Outline:** Red on "broadcast PRIVMSG to server-time client
-  includes @time"; green; then property-test round-trip of tag escaping.
-
-### TICKET-019 — IRCv3 `echo-message`
-- **Phase:** 1
-- **Points:** 1
-- **Status:** ⬜
-- **Dependencies:** TICKET-017, TICKET-007
-- **Description:** For clients with `echo-message`, the reducer emits a
-  `Send` back to the originator mirroring their own PRIVMSG/NOTICE/TAGMSG.
-- **Acceptance Criteria:**
-  - Without the cap: no echo.
-  - With the cap: one echo per message, after the broadcast.
-- **TDD Outline:** Red on echo path; green.
-
-### TICKET-020 — IRCv3 `multi-prefix`
-- **Phase:** 1
-- **Points:** 2
-- **Status:** ⬜
-- **Dependencies:** TICKET-009, TICKET-017
-- **Description:** NAMES `353` and `WHO` `352` outputs include all
-  applicable prefixes (`@+`) for clients that negotiated `multi-prefix`;
-  legacy clients get only the highest-priority prefix.
-- **Acceptance Criteria:**
-  - Op+voice user shown as `@+nick` to multi-prefix clients.
-- **TDD Outline:** Red on NAMES with both caps; green.
-
-### TICKET-021 — IRCv3 `extended-join`
-- **Phase:** 1
-- **Points:** 1
-- **Status:** ⬜
-- **Dependencies:** TICKET-005, TICKET-017
-- **Description:** `JOIN` messages for clients with `extended-join` carry
-  `account` and `realname`: `:nick JOIN #chan account :realname`. `_`
-  account = not logged in.
-- **Acceptance Criteria:**
-  - Account name plumbed from SASL auth (later ticket) or `_`.
-- **TDD Outline:** Red on extended JOIN format; green.
-
-### TICKET-022 — IRCv3 `chghost`
-- **Phase:** 1
-- **Points:** 2
-- **Status:** ⬜
-- **Dependencies:** TICKET-017
-- **Description:** On user/host change (cloaking in TICKET-030; SETNAME
-  not in v1 scope), emit `CHGHOST` to peers in shared channels who have
-  the cap.
-- **Acceptance Criteria:**
-  - Only emitted to cap-enabled peers.
-  - Only emitted after registration completes (never during).
-- **TDD Outline:** Red on hostmask change broadcast; green.
-
-### TICKET-023 — IRCv3 `away-notify`
-- **Phase:** 1
-- **Points:** 2
-- **Status:** ✅
-- **Dependencies:** TICKET-017
-- **Description:** `AWAY` reducer (reuses logic from core): on AWAY set,
-  emit `RPL_AWAY` numerics to PRIVMSG senders AND `AWAY` messages to
-  cap-enabled peers in shared channels. On unset, emit `AWAY` with empty
-  reason.
-- **Acceptance Criteria:**
-  - Without cap: only numeric replies to senders.
-  - With cap: relayed AWAY/UNAWAY events to shared-channel peers.
-- **TDD Outline:** Red on AWAY set with cap peer; green.
-
-### TICKET-024 — IRCv3 `invite-notify`
-- **Phase:** 1
-- **Points:** 1
-- **Status:** ✅
-- **Dependencies:** TICKET-013, TICKET-017
-- **Description:** Channel members with `invite-notify` receive a copy of
-  `INVITE` messages issued to the channel, in addition to the invitee.
-- **Acceptance Criteria:**
-  - Only cap-enabled members get the copy.
-  - Invitee still gets exactly one INVITE.
-- **TDD Outline:** Red on extra INVITE fanout; green.
-
-### TICKET-025 — IRCv3 `batch`
-- **Phase:** 1
-- **Points:** 5
-- **Status:** ✅
-- **Dependencies:** TICKET-017, TICKET-018
-- **Description:** Wrap multi-line server responses (`353` NAMES, JOIN
-  + 353 + 366 sequence, NETJOIN) in `BATCH` for clients that negotiate it.
-  Netbatch ref id allocation via `IdFactory`.
-- **Acceptance Criteria:**
-  - `BATCH +id type [:args]` … `BATCH -id` framing correct.
-  - Nested batches supported.
-  - Without cap: no change to output.
-- **TDD Outline:** Red on NAMES wrapped in batch; green; then nested.
-
-### TICKET-026 — SASL authentication (`PLAIN` via `AccountStore`, `EXTERNAL` stubbed)
-- **Phase:** 1
-- **Points:** 5
-- **Status:** ⬜
-- **Dependencies:** TICKET-017, TICKET-004
-- **Description:** Implement `AUTHENTICATE` / `901`–`908` numerics. Define
-  an `AccountStore` port (`verify(mech, payload) →
-  { ok, account } | { ok: false, reason }`). Implement `PLAIN`. `EXTERNAL`
-  is recognized and rejected (`904`) until mTLS lands (v1.x).
-- **Acceptance Criteria:**
-  - `CAP REQ sasl` then `AUTHENTICATE PLAIN` flow completes with `900`/
-    `903` on success or `904`/`907` on failure.
-  - Account name recorded on connection for `extended-join`/`account-tag`.
-  - Abort path (`AUTHENTICATE` after `CAP END`) → `907`.
-- **TDD Outline:** Red on successful PLAIN flow with a fake AccountStore;
-  green; then each failure numeric.
-
-### TICKET-027 — `isupport` (`005`) generator
-- **Phase:** 1
-- **Points:** 2
-- **Status:** ⬜
-- **Dependencies:** TICKET-004, TICKET-011
-- **Description:** Pure function `generateIsupport(serverConfig, connCaps)
-  → RawLine[]` producing the `005` tokens
-  (`CHANTYPES=#`, `CHANMODES=…`, `PREFIX=(ov)@+`, `MODES`, `NICKLEN`,
-  `CHANNELLEN`, `CASEMAPPING=ascii|rfc1459`, `NETWORK=…`, etc.). Wires into
-  the welcome sequence emitted by TICKET-004.
-- **Acceptance Criteria:**
-  - Tokens derived from config, not hard-coded.
-  - Multi-line `005` split correctly; final token `:are supported by
-    this server`.
-- **TDD Outline:** Red on basic token set; green; then each configurable
-  knob.
-
-### TICKET-028 — Flood control (token bucket) as pure reducer wrapper
-- **Phase:** 1
-- **Points:** 3
-- **Status:** ⬜
-- **Dependencies:** TICKET-001
-- **Description:** Higher-order reducer wrapper that consults a
-  per-connection token bucket (refilled using injected `Clock`). Over-rate
-  messages either queue or trigger `Disconnect(excess flood)` based on
-  policy. Bucket state stored on `ConnectionState`.
-- **Acceptance Criteria:**
-  - Under-limit messages pass through unchanged.
-  - Burst over limit triggers `Disconnect` with the canonical
-    "Excess Flood" reason after the configured threshold.
-  - Deterministic: same Clock input → same decision.
-  - **TDD Outline:** Red on "10 PRIVMSG in 1ms disconnects"; green; then
-    parameterize thresholds.
-
-### TICKET-059 — Wire `WHOIS` into the `ConnectionActor` dispatcher
-- **Phase:** 1
-- **Points:** 2
-- **Status:** ✅
-- **Dependencies:** TICKET-015 (reducer, ✅), TICKET-030 (actor, ✅)
-- **Description:** The `WHOIS` reducer is fully implemented and tested
-  (TICKET-015), but `packages/irc-server/src/actor.ts:182-236` deliberately
-  does **not** route `WHOIS` — an inline comment at `actor.ts:221-222`
-  reads *"WHOIS needs state the actor doesn't currently expose (full
-  connection map). Falls through to the default 421 path."* As a result a
-  client sending `WHOIS` receives `421 ERR_UNKNOWNCOMMAND` (verified by
-  `packages/irc-server/tests/actor.test.ts:496-503`). This ticket adds the
-  missing `case 'WHOIS'` and exposes whatever connection-map state the
-  reducer needs (e.g. via `IrcRuntime`/`ConnSnapshot` lookup) so the
-  existing reducer is actually reachable.
-- **Acceptance Criteria:**
-  - `WHOIS <nick>` returns the `311`/`319`/`312`/`317`/`318` sequence
-    (and `401`+`318` for an unknown nick) — never `421`.
-  - The `actor.ts:221-222` "falls through" comment is removed.
-  - The test at `actor.test.ts:496-503` asserting `421` for `WHOIS` is
-    replaced with a test asserting the real `311`+`318` flow.
-  - `packages/irc-core/tests/commands/whois.test.ts` continues to pass
-    unchanged (reducer behavior is not modified, only wired in).
-- **TDD Outline:** Red on an actor-level test asserting `WHOIS` of a
-  registered user emits `311` (currently fails — emits `421`); green by
-  adding the `case` and the state plumbing; then add the unknown-nick
-  path at the actor level.
-
-### TICKET-060 — Wire `AUTHENTICATE` into the `ConnectionActor` dispatcher
-- **Phase:** 1
-- **Points:** 1
-- **Status:** ✅
-- **Dependencies:** TICKET-026 (SASL reducer), TICKET-030 (actor, ✅)
-- **Description:** The `sasl` capability is advertised to clients as
-  `sasl=PLAIN,EXTERNAL` (`packages/irc-core/src/caps/capabilities.ts:34`),
-  but `actor.ts:182-236` has no `case 'AUTHENTICATE'`. Once TICKET-026
-  ships the SASL reducer and `901`–`908` numerics, this ticket adds the
-  dispatcher routing so the command is reachable. Until then, any client
-  that negotiates `sasl` and sends `AUTHENTICATE PLAIN` gets a `421`.
-- **Acceptance Criteria:**
-  - After `CAP REQ sasl` / `CAP ACK`, `AUTHENTICATE PLAIN` is routed to
-    the SASL reducer (no `421`).
-  - `actor.ts` contains a `case 'AUTHENTICATE'`.
-  - Pre-registration `AUTHENTICATE` (before `CAP END`) is handled per the
-    SASL spec, not rejected as unknown.
-- **TDD Outline:** Red on an actor-level test asserting
-  `AUTHENTICATE PLAIN` (post-`CAP REQ sasl`) does not return `421`;
-  green by adding the `case`.
-
-### TICKET-061 — Wire `AWAY` into the `ConnectionActor` dispatcher
-- **Phase:** 1
-- **Points:** 1
-- **Status:** ✅
-- **Dependencies:** TICKET-023 (AWAY reducer), TICKET-030 (actor, ✅)
-- **Description:** The `away-notify` capability is advertised to clients
-  (`packages/irc-core/src/caps/capabilities.ts:26`), and the `RPL_AWAY`
-  (`301`), `RPL_UNAWAY` (`305`), `RPL_NOWAWAY` (`306`) numerics are
-  already defined in `packages/irc-core/src/protocol/numerics.ts:20-24`
-  but never emitted. `actor.ts:182-236` has no `case 'AWAY'`, so a client
-  sending `AWAY :reason` gets `421`. Once TICKET-023 ships the `AWAY`
-  reducer, this ticket adds the dispatcher routing so the command is
-  reachable.
-- **Acceptance Criteria:**
-  - `AWAY :reason` is routed to the AWAY reducer (no `421`); emits
-    `306 RPL_NOWAWAY`.
-  - `AWAY` with no params (or empty reason) unsets away; emits
-    `305 RPL_UNAWAY`.
-  - `actor.ts` contains a `case 'AWAY'`.
-- **TDD Outline:** Red on an actor-level test asserting `AWAY :gone`
-  does not return `421`; green by adding the `case`; then the unset path.
-
----
-
-## Phase 2 — Runtime port + reference impl
-
-### TICKET-029 — Define `IrcRuntime` port; implement `in-memory-runtime`
-- **Phase:** 2
-- **Points:** 5
-- **Status:** ⬜
-- **Dependencies:** TICKET-001
-- **Description:** Lock down the `IrcRuntime` interface (PLAN §2.2) in
-  `packages/irc-server/src/runtime.ts`. Ship a single-process reference
-  implementation in `packages/in-memory-runtime` backed by `Map`s and the
-  injected `Clock`/`IdFactory`. Used by integration tests, the local CLI,
-  and as the contract spec for CF/AWS.
-- **Acceptance Criteria:**
-  - All `IrcRuntime` methods implemented and unit-tested.
-  - Nick reservation is race-free within the single-process model (proven
-    by a stress test using a fake clock).
-  - `broadcast` skips `except` correctly.
-- **TDD Outline:** Red on `reserveNick` uniqueness across two calls;
-  green; then broadcast/nick-change/getChannelSnapshot.
-
-### TICKET-030 — `ConnectionActor`: bytes → framed messages → reducer → dispatch
-- **Phase:** 2
-- **Points:** 5
-- **Status:** ⬜
-- **Dependencies:** TICKET-029, TICKET-028
-- **Description:** In `packages/irc-server/src/actor.ts`, implement the
-  per-connection pipeline: receive a WebSocket text frame, split on `\r\n`
-  (tolerating the single-message-per-frame and joined-frame variants from
-  PLAN §9), parse, route by command to the right reducer per the
-  location-of-authority table, apply, and `dispatch` the resulting effects
-  against the bound `IrcRuntime`.
-- **Acceptance Criteria:**
-  - One message per frame → one reducer invocation.
-  - Joined frame with N `\r\n` → N invocations, in order.
-  - Parser failures produce `421` and continue (never crash the actor).
-  - Flood-control wrapper applied per TICKET-028.
-- **TDD Outline:** Red on "text frame with one PRIVMSG results in one
-  broadcast"; green; then multi-line frame + malformed line.
-
-### TICKET-031 — `apps/local-cli`: runnable WebSocket server using in-memory runtime
-- **Phase:** 2
-- **Points:** 3
-- **Status:** ⬜
-- **Dependencies:** TICKET-029, TICKET-030
-- **Description:** A `node`-runnable WS server (`apps/local-cli/src/main.ts`)
-  that wires `in-memory-runtime` + `ConnectionActor` to a `ws` server,
-  loads a config file (MOTD, server name, etc.), and logs each connection.
-  This is the manual-test harness and the e2e fixture target.
-- **Acceptance Criteria:**
-  - `pnpm --filter local-cli start -- --port 6667` boots.
-  - WeeChat/HexChat can connect, register, join, and talk.
-  - Logs structured JSON.
-- **TDD Outline:** Red on an e2e-ish test spinning up the WS server in a
-  test process and connecting a tiny client (from `tools/irc-client`
-  stub); green.
-
-### TICKET-032 — Parametrized integration test suite over `IrcRuntime`
-- **Phase:** 2
-- **Points:** 5
-- **Status:** ⬜
-- **Dependencies:** TICKET-029, TICKET-030
-- **Description:** In `tests/integration`, define IRC scenarios (register,
-  join, privmsg, mode change, kick, reconnect, nick collision, …) as data,
-  with a runner that takes any `IrcRuntime` factory. The same suite runs
-  against `in-memory-runtime` now, against the CF runtime in Phase 3, and
-  against the AWS runtime in Phase 4.
-- **Acceptance Criteria:**
-  - ≥20 scenarios covering every Phase 1 command + the trickier
-    cross-authority paths (JOIN mutates both Connection and Channel
-    state).
-  - All scenarios green against `in-memory-runtime`.
-  - Adding a new runtime requires only registering a factory.
-- **TDD Outline:** Red on one parametrized scenario; green; then add
-  scenarios incrementally.
-
----
-
-## Phase 3 — Cloudflare adapter
-
-### TICKET-033 — `ConnectionDO` (hibernatable WS), state migration, alarms
-- **Phase:** 3
-- **Points:** 8
-- **Status:** ✅
-- **Dependencies:** TICKET-030, TICKET-032
-- **Description:** Implement `packages/cf-adapter/src/connection-do.ts`
-  using `DurableObjectState`'s `HibernatingWebSocketHandler`. Owns one
-  connection's socket + state (via `state.storage`). Routes incoming
-  frames through `ConnectionActor` with a `CfRuntime` stub. Set alarms
-  for PING/idle sweeps.
-- **Acceptance Criteria:**
-  - Survives hibernation: state restored on wake.
-  - WebSocket close releases nick and triggers QUIT fanout via
-    `ChannelDO` stubs.
-  - Alarms fire and emit PING; missing PONG closes the connection.
-- **TDD Outline:** Red via `@cloudflare/vitest-pool-workers` on
-  "hibernate then wake preserves nick"; green; then alarm-driven PING.
-
-### TICKET-034 — `RegistryDO` with sharding plan
-- **Phase:** 3
-- **Points:** 5
-- **Status:** ✅
-- **Dependencies:** TICKET-029
-- **Description:** Implement `RegistryDO` keyed by `hash(nick) % N` (N
-  configurable, default 32). Methods match `reserveNick` / `changeNick` /
-  `releaseNick`. Single-threaded DO gives the uniqueness invariant for
-  free.
-- **Acceptance Criteria:**
-  - Two concurrent reservations for the same nick from different
-    `ConnectionDO`s → exactly one succeeds.
-  - Sharding function documented and unit-tested.
-- **TDD Outline:** Red on concurrent reserve from two stub ConnectionDOs;
-  green.
-
-### TICKET-035 — `ChannelDO` (roster + modes + fanout via ConnectionDO stubs)
-- **Phase:** 3
-- **Points:** 8
-- **Status:** ⬜
-- **Dependencies:** TICKET-033, TICKET-034
-- **Description:** `ChannelDO` keyed by lowercased channel name. Owns
-  roster, topic, modes, ban list. Fanout = loop roster, call each member's
-  `ConnectionDO.fetch()` with the line. Coordinates with `ConnectionDO`
-  via `state.storage` deltas.
-- **Acceptance Criteria:**
-  - JOIN/PART/KICK/MODE/TOPIC all drive correct state + fanout.
-  - Gone `ConnectionDO` (websocket closed) removed lazily from roster.
-  - Up to 1k members in a single channel under the local workerd.
-- **TDD Outline:** Red on "two members of a channel both receive
-  PRIVMSG"; green; then gone-connection sweep.
-
-### TICKET-036 — `CfRuntime` implementing `IrcRuntime`
-- **Phase:** 3
-- **Points:** 5
-- **Status:** ⬜
-- **Dependencies:** TICKET-029, TICKET-033, TICKET-034, TICKET-035
-- **Description:** Wire the three DOs together behind a single
-  `CfRuntime` class implementing the `IrcRuntime` interface. Each method
-  issues the correct DO `stub()`/`fetch()` calls.
-- **Acceptance Criteria:**
-  - All `IrcRuntime` methods work end-to-end.
-  - Cross-DO coordination uses `stub()` (no in-memory caching that could
-    drift).
-  - Phase 2 integration suite (TICKET-032) registered against
-    `CfRuntime` and passing.
-- **TDD Outline:** Red on the first integration scenario against
-  `CfRuntime`; green; iterate.
-
-### TICKET-037 — Cloudflare deploy pipeline (wrangler), staging env, smoke e2e
-- **Phase:** 3
-- **Points:** 3
-- **Status:** ⬜
-- **Dependencies:** TICKET-036
-- **Description:** `apps/cf-worker` deploy glue: `wrangler.toml`,
-  migrations, secrets. GitHub Actions step to deploy to a `staging`
-  environment on push to `main`. Smoke e2e test in CI: connect, register,
-  JOIN, PRIVMSG, QUIT.
-- **Acceptance Criteria:**
-  - `pnpm deploy:cf:staging` works from a clean checkout.
-  - CI smoke e2e green on every merge.
-- **TDD Outline:** Red on a CI job that asserts a deployed server
-  responds to a CONNECT; green.
-
-### TICKET-038 — Docs: `docs/deployment-cf.md`
-- **Phase:** 3
-- **Points:** 1
-- **Status:** ✅
-- **Dependencies:** TICKET-037
-- **Description:** End-to-end deployment guide: prerequisites, wrangler
-  config knobs, secrets, sharding, cost notes, troubleshooting.
-- **Acceptance Criteria:**
-  - A new contributor can deploy their own staging instance following
-    only this doc.
-- **TDD Outline:** N/A (documentation). Reviewed by following the steps
-  from scratch in a clean environment.
-
----
-
-## Phase 4 — AWS adapter
-
-### TICKET-039 — CDK stack: APIGW WebSocket, Lambda, DynamoDB tables, IAM
-- **Phase:** 4
-- **Points:** 8
-- **Status:** ⬜
-- **Dependencies:** TICKET-032
-- **Description:** `apps/aws-stack` CDK v2 app. API Gateway v2 WebSocket
-  API; Node 20 Lambdas for `$connect`/`$disconnect`/`$default`; DynamoDB
-  tables `Connections`, `ChannelMeta`, `ChannelMembers`, `Nicks`,
-  `Accounts` per PLAN §4; least-privilege IAM.
-- **Acceptance Criteria:**
-  - `pnpm cdk deploy` brings up the stack in a fresh AWS account.
-  - `cdk synth` clean, no warnings about broad permissions.
-  - Local validation via localstack.
-- **TDD Outline:** Red on a localstack-backed test asserting all five
-  tables exist post-deploy; green.
-
-### TICKET-040 — `$connect` / `$disconnect` / `$default` handlers + `AwsRuntime`
-- **Phase:** 4
-- **Points:** 8
-- **Status:** ⬜
-- **Dependencies:** TICKET-030, TICKET-039
-- **Description:** Lambda handlers wiring APIGW events to
-  `ConnectionActor` with `AwsRuntime`. `AwsRuntime` implements
-  `IrcRuntime` backed by DynamoDB + `ApiGatewayManagementApi`.
-- **Acceptance Criteria:**
-  - All Phase 2 integration scenarios pass against `AwsRuntime`
-    (dynamodb-local).
-  - Send to a gone connection caught and triggers cleanup.
-- **TDD Outline:** Red on first integration scenario against
-  `AwsRuntime`; green; iterate.
-
-### TICKET-041 — DynamoDB transactions for membership; gone-connection sweep
-- **Phase:** 4
-- **Points:** 5
-- **Status:** ⬜
-- **Dependencies:** TICKET-040
-- **Description:** Use `TransactWriteItems` for JOIN/PART/KICK (mutates
-  `Connections.joined` and `ChannelMembers` atomically). Lazy
-  gone-connection cleanup on `GoneException` plus a sweeper Lambda on a
-  schedule.
-- **Acceptance Criteria:**
-  - Concurrent JOIN/PART by the same connection on the same channel
-    cannot leave inconsistent state (proven by a stress test).
-  - Sweeper removes stale `Connections`/`ChannelMembers` rows past a TTL.
-- **TDD Outline:** Red on concurrent-join race; green; then sweeper
-  test.
-
-### TICKET-042 — EventBridge idle / PING timers
-- **Phase:** 4
-- **Points:** 3
-- **Status:** ⬜
-- **Dependencies:** TICKET-040
-- **Description:** EventBridge Scheduler one-time per-connection PING
-  jobs; on PING, Lambda checks last-seen and either posts PONG wait or
-  disconnects.
-- **Acceptance Criteria:**
-  - Idle connection gets `PING` after the configured interval.
-  - Missing `PONG` for the configured window → disconnect + cleanup.
-- **TDD Outline:** Red on "no PONG for 2× interval → connection
-  removed"; green.
-
-### TICKET-043 — AWS deploy pipeline (CDK), staging env, smoke e2e
-- **Phase:** 4
-- **Points:** 3
-- **Status:** ✅
-- **Dependencies:** TICKET-042
-- **Description:** GitHub Actions CDK deploy to `staging` on push to
-  `main`. Smoke e2e identical in shape to TICKET-037.
-- **Acceptance Criteria:**
-  - `pnpm deploy:aws:staging` works from a clean checkout.
-  - CI smoke e2e green on every merge.
-- **TDD Outline:** Red on a CI job asserting a deployed server responds
-  to CONNECT; green.
-
-### TICKET-044 — Docs: `docs/AWS-Deployment.md`
-- **Phase:** 4
-- **Points:** 1
-- **Status:** ✅
-- **Dependencies:** TICKET-043
-- **Description:** End-to-end AWS deployment guide: prerequisites, CDK
-  knobs, DynamoDB capacity planning, region strategy, cost notes,
-  troubleshooting.
-- **Acceptance Criteria:**
-  - A new contributor can deploy their own staging instance following
-    only this doc.
-- **TDD Outline:** N/A (documentation). Reviewed by following the steps
-  from scratch.
-
-### TICKET-066 — CDK `environmentName` parameter + prefixed resource names
-- **Phase:** 4
-- **Points:** 3
-- **Status:** ⬜
-- **Dependencies:** TICKET-044 (✅)
-- **Description:** The `IrcAwsStack` (`apps/aws-stack/src/aws-stack.ts`)
-  is a single hard-coded stack: the CloudFormation stack name is
-  `IrcAwsStack`, every DynamoDB physical table name is the bare logical
-  id (`Connections`, `ChannelMeta`, …), and the APIGW stage is always
-  `prod`. Two environments (staging + production) therefore **cannot
-  coexist in the same AWS account + region** — the second deploy
-  collides on table names and stack id. This ticket adds an
-  `environmentName: string` construct prop (e.g. `"staging"`,
-  `"production"`) that:
-  1. Becomes part of the CloudFormation stack id
-     (`IrcAwsStack-<environmentName>`).
-  2. Prefixes every physical DynamoDB table name
-     (`<env>Connections`, `<env>ChannelMeta`, …) so cross-env table
-     scans/isolation is unambiguous and the gone-connection sweeper
-     never touches the wrong env's rows.
-  3. Suffixes the APIGW stage name when desirable (or keeps `prod`
-     per-stage — design call, but the default should remain
-     client-compatible).
-  4. Flows through `bin/aws.ts` from a CDK context variable
-     (`-c environmentName=staging`) with a default of `staging` for
-     backward compatibility with the existing deploy pipeline
-     (TICKET-043).
-- **Acceptance Criteria:**
-  - `cdk synth -c environmentName=staging` and
-    `cdk synth -c environmentName=production` produce templates whose
-    DynamoDB table names and stack id differ (no collision).
-  - `cdk deploy` with no `-c environmentName` defaults to `staging`
-    (existing pipeline stays green without changes).
-  - The synth-time test suite (`apps/aws-stack/tests/stack.test.ts`)
-    gains cases asserting the prefix for at least two env names and the
-    default-when-omitted path; existing assertions are updated to pass
-    `environmentName: 'staging'` (or equivalent) in the test harness.
-  - The Lambda env-var injection loop
-    (`<NAME>_TABLE`) still injects the **prefixed** physical name so
-    `buildDepsFromEnv` resolves the correct table at runtime.
-  - The deploy workflow (`.github/workflows/deploy-aws.yml`) is updated
-    to pass `-c environmentName=staging` explicitly (so the default
-    behaviour is intent, not accident) and the smoke URL resolution
-    step targets `IrcAwsStack-staging`.
-  - `docs/deployment-aws.md` §7 (Configuration reference) is updated to
-    document the new knob.
-- **TDD Outline:**
-  1. Red — synth test: table names contain the env prefix when
-     `environmentName: 'production'`; currently fails (names are bare).
-     Green by threading the prop into the `Table` constructs and the
-     `TABLE_DEFS` spread.
-  2. Red — synth test: stack id / CloudFormation stack name includes the
-     env suffix; green.
-  3. Red — synth test: omitting the prop defaults to `staging` and
-     existing table-name assertions still hold; green by defaulting the
-     prop in `bin/aws.ts`.
-- **Out of scope:**
-  - Multi-account or multi-region fan-out (region strategy is
-    documented in `docs/deployment-aws.md` §10; this ticket is
-    single-account / single-region env isolation only).
-  - Cross-env data migration (greenfield envs only).
-
-### TICKET-067 — Fix MOTD parsing mismatch (CDK default vs config loader)
-- **Phase:** 4
-- **Points:** 1
-- **Status:** ✅
-- **Dependencies:** TICKET-043 (✅)
-- **Description:** The Lambda config loader
-  (`packages/aws-adapter/src/config-loader.ts`) splits the `MOTD` env
-  var on `\n` to produce `motdLines`. But the CDK default injected in
-  `apps/aws-stack/src/aws-stack.ts` is **comma-separated**:
-  `'Welcome to the ServerlessIRCd deployment.,This server runs on AWS Lambda.'`
-  — so a freshly deployed stack advertises a single MOTD line containing
-  a literal comma instead of two lines. Pick **one** canonical delimiter
-  and align both sides. `\n` is the existing loader contract and is what
-  the config schema expects, so the CDK default should switch to a
-  `\n`-joined string (or the stack should accept a `string[]` and join
-  it itself, which composes better with TICKET-068).
-- **Acceptance Criteria:**
-  - A freshly deployed stack shows the expected number of MOTD lines
-    (375 / 372 / 376 sequence with each line on its own numeric), not a
-    single comma-joined line.
-  - A unit test in `packages/aws-adapter` asserts that a `\n`-joined
-    `MOTD` env var round-trips through the loader into the expected
-    `motdLines` array length.
-  - The CDK default in `aws-stack.ts` uses `\n` (or the array-join path)
-    — no comma-separated literals remain.
-  - `docs/deployment-aws.md` §7 (where the MOTD env var is documented)
-    is updated to state the delimiter unambiguously.
-- **TDD Outline:**
-  1. Red — assert that the CDK-injected default MOTD value, when fed
-     through the loader, yields `motdLines.length >= 2`; currently fails
-     (length 1). Green by changing the delimiter in the CDK default.
-  2. Refactor — if TICKET-068 has landed, the MOTD is sourced from a
-     `string[]` construct prop and joined with `\n` in the stack, so
-     the mismatch is structural rather than literal.
-
-### TICKET-068 — Make hardcoded stack identity vars configurable via construct props
-- **Phase:** 4
-- **Points:** 2
-- **Status:** ⬜
-- **Dependencies:** TICKET-044 (✅)
-- **Description:** `apps/aws-stack/src/aws-stack.ts` hard-codes three
-  deployment-identity values as string literals in `addEnvironment`
-  calls (around lines 132–145): `SERVER_NAME='irc.example.com'`,
-  `NETWORK_NAME='ExampleNet'`, and `MOTD='…'`. There is no deploy-time
-  knob — overriding any of them requires editing source. Promote these
-  to construct props on `IrcAwsStack` (or a typed `IrcStackProps` bag)
-  with the current literals as defaults, and flow them through
-  `bin/aws.ts` from CDK context variables (`-c serverName=…`,
-  `-c networkName=…`, `-c motd=…`). This composes with TICKET-066
-  (env-name parameter) — recommend landing 066 first so the prop bag is
-  extended once rather than twice.
-- **Acceptance Criteria:**
-  - `IrcAwsStack` accepts an optional `{ serverName?, networkName?,
-    motdLines? }` prop bag; when omitted, the existing defaults apply
-    (no behaviour change for current deploys).
-  - `bin/aws.ts` reads `serverName` / `networkName` / `motd` from CDK
-    context (`app.node.tryGetContext`) and forwards them.
-  - The same values are injected into **both** the `IrcHandler` and
-    `IrcPingChecker` Lambdas (both currently carry the hard-coded
-    copies — de-duplicate via the prop bag).
-  - Synth-time test: overriding the props produces a template whose
-    Lambda env vars carry the overridden values.
-  - `docs/deployment-aws.md` §7.1 (currently documenting these as
-    "hardcoded, override requires source edit") is updated to show the
-    `-c` context override path.
-- **TDD Outline:**
-  1. Red — synth test: passing `serverName: 'irc.my.net'` produces a
-     Lambda env var `SERVER_NAME=irc.my.net`; currently fails (always
-     `irc.example.com`). Green by threading the prop into
-     `addEnvironment`.
-  2. Red — synth test: the same override flows to `IrcPingChecker`
-     (catches the duplicated hard-coded copy); green.
-  3. Green — CDK context override path in `bin/aws.ts` end-to-end via
-     `cdk synth -c serverName=…`.
-- **Out of scope:**
-  - Secrets (server password, SASL creds) — those belong in Secrets
-    Manager / SSM, not CDK context; tracked separately.
-
----
-
-## Phase 5 — Cross-cutting
-
-### TICKET-045 — Observability: structured logs, trace IDs, dashboards
-- **Phase:** 5
-- **Points:** 3
-- **Status:** ✅
-- **Dependencies:** TICKET-036, TICKET-040
-- **Description:** Structured JSON logs everywhere with a per-request
-  `traceId` propagated via `ctx`. CF Workers Analytics; CloudWatch
-  dashboards + metrics for connections/sec, msg latency, error rate.
-- **Acceptance Criteria:**
-  - Every log line has `traceId`, `connectionId` where relevant.
-  - Dashboards checked in (CDK / wrangler config).
-- **TDD Outline:** Red on a test asserting log shape via an injected
-  logger; green.
-
-### TICKET-046 — Security: server password, SASL, cloaking, rate limits, caps
-- **Phase:** 5
-- **Points:** 5
-- **Status:** ⬜
-- **Dependencies:** TICKET-026, TICKET-028
-- **Description:** Production hardening: enforce server password
-  (configured per deployment), hostmask cloaking for user IPs, per-IP and
-  per-connection rate limits beyond TICKET-028's flood control, max
-  channels and connections per user, 512-byte input cap enforced in
-  parser (verify), max nickname/channel length caps from isupport.
-- **Acceptance Criteria:**
-  - Each limit tested in isolation.
-  - Documented defaults + override knobs in config.
-- **TDD Outline:** Red per limit; green per limit.
-
-### TICKET-047 — Config: MOTD, server/network name, channel prefixes, max clients, oper creds
-- **Phase:** 5
-- **Points:** 2
-- **Status:** ✅
-- **Dependencies:** TICKET-027
-- **Description:** A single `ServerConfig` schema (Zod) loaded from file
-  per adapter (CF: KV/secret; AWS: Secrets Manager/SSM). Covers MOTD,
-  server name, network name, allowed channel prefixes, max clients, oper
-  credentials.
-- **Acceptance Criteria:**
-  - Invalid config fails fast at boot with a readable error.
-  - Both adapters consume the same schema.
-- **TDD Outline:** Red on schema validation of a malformed config;
-  green.
-
-### TICKET-048 — CI hardening: coverage gate ≥90%, contract tests on every PR, mutation testing spot-check
-- **Phase:** 5
-- **Points:** 3
-- **Status:** ✅
-- **Dependencies:** TICKET-032
-- **Description:** CI workflow enforces ≥90% coverage (100% on
-  `irc-core`). Integration contract suite runs on every PR.
-  Stryker/`@stryker-mutator-runner` spot-check on `irc-core/protocol`
-  and `irc-core/commands` to confirm test quality.
-- **Acceptance Criteria:**
-  - PR with uncovered code fails CI.
-  - Mutation score ≥80% on spot-checked packages.
-- **TDD Outline:** N/A (infra). Validated by intentionally lowering a
-  test and watching CI fail.
-
----
-
-## Phase 6 — Hardening / polish
-
-### TICKET-049 — Load test: 10k concurrent connections per platform
-- **Phase:** 6
-- **Points:** 5
-- **Status:** ⬜
-- **Dependencies:** TICKET-037, TICKET-043
-- **Description:** `tools/load-test` synthetic client farm (k6 or custom)
-  that opens N WebSocket connections, registers, joins, and chats.
-  Capture p50/p95/p99 latency, drop rate, cost. Produce a written report
-  per platform.
-- **Acceptance Criteria:**
-  - 10k concurrent connections sustained per platform.
-  - Bottlenecks identified and filed as follow-up issues.
-- **TDD Outline:** N/A (perf). Smoke assertion: load test script
-  completes without crashing.
-
-### TICKET-050 — Compatibility sweep: WeeChat, HexChat, IRCCloud, TheLounge, matrix-IRC bridge
-- **Phase:** 6
-- **Points:** 3
-- **Status:** ⬜
-- **Dependencies:** TICKET-031, TICKET-037, TICKET-043
-- **Description:** Manual + scripted compatibility sweep against the
-  listed clients. File and fix any incompatibilities found. Record known
-  quirks in `docs/compatibility.md`.
-- **Acceptance Criteria:**
-  - ≥3 reference clients complete the standard flow without warnings.
-  - Quirks documented.
-- **TDD Outline:** N/A (manual/scripted). Output is the compatibility
-  matrix.
-
-### TICKET-051 — ADRs for irreversible decisions
-- **Phase:** 6
-- **Points:** 2
-- **Status:** ⬜
-- **Dependencies:** all prior
-- **Description:** Write ADRs in `docs/adr/` for: state-authority split,
-  effect system, DO sharding, DynamoDB schema, wss-only v1, reducer
-  purity, dropped TCP support, SASL mechanism scope.
-- **Acceptance Criteria:**
-  - Each ADR follows the standard Context/Decision/Consequences format.
-  - All irreversible choices from PLAN §9 covered.
-- **TDD Outline:** N/A (documentation).
-
----
-
-## Phase 7 — TLS hardening & raw TCP transport (v1.x)
-
-The v1 plan locked wss-only (PLAN §3, §9). Phase 7 reverses that to add
-irc+tls on :6697 alongside wss, and ships the mTLS work TICKET-026 has
-been waiting on. Raw TCP is a **second adapter per platform**, not a
-config flag — Workers cannot accept raw TCP and API GW is WebSocket-only,
-so both platforms need a different entry point (Cloudflare Spectrum;
-AWS NLB).
-
-### TICKET-052 — Revise transport decision: dual wss + irc+tls (ADR); update PLAN §3/§9
-- **Phase:** 7
-- **Points:** 2
-- **Status:** ⬜
-- **Dependencies:** TICKET-051
-- **Description:** Write a superseding ADR documenting the dual-transport
-  model: wss stays the serverless default; irc+tls :6697 is added for
-  RFC-compliant clients. Cover the per-platform mapping (Spectrum on CF,
-  NLB on AWS), why wss-only was originally chosen, and what changed the
-  decision. Update PLAN §3 ("No plaintext TCP in v1" → "v1.x adds
-  irc+tls :6697") and §9 (drop the "wss-only" framing). Supersedes the
-  wss-only/dropped-TCP entry in TICKET-051.
-- **Acceptance Criteria:**
-  - ADR follows Context/Decision/Consequences and explicitly supersedes
-    the wss-only ADR from TICKET-051.
-  - PLAN.md §3 and §9 updated; references consistent.
-- **TDD Outline:** N/A (documentation). Reviewed by walking through the
-  decision tradeoffs against the original wss-only rationale.
-
-### TICKET-053 — Generalize `ConnectionActor` transport seam (TCP byte-stream framing)
-- **Phase:** 7
-- **Points:** 3
-- **Status:** ⬜
-- **Dependencies:** TICKET-030
-- **Description:** Extract the `\r\n` line-framing logic from
-  `ConnectionActor` (PLAN §9 already tolerates joined WS frames) into a
-  `Transport` seam. `ConnectionActor` accepts either a
-  `WsTextFrameTransport` (one message per frame, current behavior) or a
-  `TcpByteStreamTransport` (stateful `\r\n` framing across chunks with
-  partial-line buffering). Parser/reducer/dispatch pipeline is shared
-  unchanged — the core is transport-agnostic by design.
-- **Acceptance Criteria:**
-  - One message per WS text frame and one message per `\r\n` over a
-    chunked TCP stream produce identical reducer invocations.
-  - Partial-line buffering across chunks is correct (no message loss or
-    duplication at chunk boundaries).
-  - 100% coverage on the new framing module.
-- **TDD Outline:** Red on "two TCP chunks split mid-line produce one
-  PRIVMSG broadcast"; green; then partial-line, empty-line, and
-  mixed `\r\n`/`\n` edge cases.
-
-### TICKET-054 — mTLS support: edge config + `AccountStore` plumbing (enables SASL EXTERNAL)
-- **Phase:** 7
-- **Points:** 5
-- **Status:** ⬜
-- **Dependencies:** TICKET-026, TICKET-052
-- **Description:** Wire platform-native mTLS into both adapters and feed
-  the verified client-cert subject into the `AccountStore` so SASL
-  `EXTERNAL` (stubbed `904` in TICKET-026) actually authenticates.
-  CF: API Shield mTLS with uploaded CA pool, cert subject exposed to the
-  Worker. AWS: API Gateway WebSocket custom-domain mTLS with a PEM trust
-  store, subject in the `$connect` event context. Define an
-  `MtlsIdentityProvider` port in `irc-core` consumed by `AccountStore`;
-  adapters inject the platform implementation.
-- **Acceptance Criteria:**
-  - CF and AWS adapters each have a documented mTLS configuration path
-    (CA/trust-store upload, custom domain, client-cert verification).
-  - SASL `EXTERNAL` succeeds when a valid client cert is presented;
-    fails with `904` when absent or untrusted.
-  - Identity is plumbed via a port — no cloud deps in `irc-core`.
-  - Works over both wss and (once landed) raw TCP+TLS.
-- **TDD Outline:** Red on `AccountStore.verify('EXTERNAL', certSubject)`
-  returning the mapped account with a fake provider; green; then
-  per-adapter integration tests with a generated test CA.
-
-### TICKET-055 — CF TCP+TLS adapter via Cloudflare Spectrum + Container origin
-- **Phase:** 7
-- **Points:** 8
-- **Status:** ⬜
-- **Dependencies:** TICKET-053, TICKET-052
-- **Description:** Workers cannot accept raw TCP, so the CF TCP+TLS path
-  requires **Cloudflare Spectrum** (TLS termination, Enterprise tier)
-  fronting a stateful TCP origin. The origin is a **Cloudflare Container**
-  (or external compute) running the IRC core with the generalized TCP
-  byte-stream `ConnectionActor` over a persistent runtime. Spectrum
-  terminates TLS at the edge and forwards plaintext TCP to the origin.
-  Connection state is held in the container runtime and persisted
-  per the runtime's storage layer.
-- **Acceptance Criteria:**
-  - A client connecting to `irc.example.com:6697` over TLS completes
-    registration, JOIN, PRIVMSG, QUIT.
-  - TLS is terminated by Spectrum; origin only sees plaintext (unless
-    mTLS passthrough is configured via TICKET-054).
-  - Connection state survives origin reconnect via the runtime's
-    persistence layer.
-  - Deploy pipeline (wrangler/terraform for Spectrum + container) is
-    checked in.
-- **TDD Outline:** Red on an integration scenario against a local
-  TLS-terminating proxy (stunnel) in front of the container; green;
-  then e2e against staging Spectrum.
-
-### TICKET-056 — AWS TCP+TLS adapter via Network Load Balancer (TLS) + Lambda streaming
-- **Phase:** 7
-- **Points:** 8
-- **Status:** ⬜
-- **Dependencies:** TICKET-053, TICKET-052
-- **Description:** NLB with a `tls` listener terminates TLS and invokes a
-  **Lambda streaming function** as the target. Connection identity is
-  derived from NLB flow metadata (source IP + port) and mapped to the
-  existing `connectionId` scheme. Bidirectional traffic flows via the
-  Lambda response stream. Reuses `AwsRuntime` (DynamoDB-backed state)
-  with the generalized TCP byte-stream `ConnectionActor`. Add CDK
-  constructs for NLB + target group + ACM cert; document the NLB+Lambda
-  streaming limits (idle timeout, max connection duration).
-- **Acceptance Criteria:**
-  - A client connecting to the NLB endpoint on :6697 completes a full
-    IRC session end-to-end.
-  - Same connection-identity semantics as the APIGW WebSocket path
-    (one stable ID per connection, routable via DynamoDB).
-  - Bidirectional streaming verified under sustained traffic and on
-    reconnect.
-  - CDK stack deploys cleanly into a fresh account via localstack.
-- **TDD Outline:** Red on a localstack-backed test simulating NLB→Lambda
-  byte framing for a single PRIVMSG; green; then the streaming-back
-  path and chunk-boundary cases.
-
-### TICKET-057 — Extend integration contract suite over transport (wss × TCP+TLS)
-- **Phase:** 7
-- **Points:** 3
-- **Status:** ⬜
-- **Dependencies:** TICKET-032, TICKET-053, TICKET-055, TICKET-056
-- **Description:** Extend the parametrized `IrcRuntime` contract suite
-  from TICKET-032 with a `Transport` dimension. Every scenario runs
-  against (runtime × transport): in-memory+WS, in-memory+TCP, CF+WS,
-  CF+TCP, AWS+WS, AWS+TCP. Add scenarios specific to TCP framing
-  (chunk boundaries, slow-loris-style partial sends, `\r\n` only,
-  bare `\n` tolerance).
-- **Acceptance Criteria:**
-  - All existing scenarios green across both transports on the
-    in-memory runtime.
-  - TCP-specific framing scenarios (multi-chunk message, partial line,
-    mixed line endings) covered with deterministic assertions.
-  - Adding a new transport requires only registering a factory.
-- **TDD Outline:** Red on a chunk-boundary scenario against the
-  in-memory runtime; green; then port the matrix to CF and AWS.
-
-### TICKET-058 — Docs: `deployment-cf-tcp.md` and `deployment-aws-tcp.md` (TCP+TLS variants)
-- **Phase:** 7
-- **Points:** 2
-- **Status:** ⬜
-- **Dependencies:** TICKET-055, TICKET-056
-- **Description:** End-to-end deployment guides for the :6697 TCP+TLS
-  variants: prerequisites (CF Enterprise for Spectrum; ACM cert for AWS
-  NLB), per-platform config knobs, cost/ops implications versus the wss
-  path, mTLS trust-store setup (cross-ref TICKET-054), and
-  troubleshooting.
-- **Acceptance Criteria:**
-  - A new contributor can deploy their own TCP+TLS staging instance on
-    each platform following only the doc.
-  - Cost and operational caveats (stateful origin on CF, NLB+Lambda
-    streaming limits on AWS) are clearly stated.
-- **TDD Outline:** N/A (documentation). Reviewed by following the steps
-  from scratch in a clean environment.
-
----
-
-### TICKET-062 — IRCv3 `safelist` capability + `SAFELIST` ISUPPORT token
-- **Phase:** 1
-- **Points:** 1
-- **Status:** ✅
-- **Dependencies:** TICKET-016, TICKET-017, TICKET-027
-- **Description:** Advertise the IRCv3 `safelist` capability and the
-  matching `SAFELIST` token in `005 RPL_ISUPPORT`. Per
-  <https://ircv3.net/docs/specs/extensions/safelist-3.2.html> this is
-  purely a signal to clients that the server will not terminate the
-  client connection for issuing `LIST` — the `LIST` reducer itself is
-  already non-destructive (TICKET-016), so this ticket is the
-  advertisement surface only: a new entry in
-  `packages/irc-core/src/caps/capabilities.ts` and a new token in
-  `packages/irc-core/src/commands/isupport.ts`.
-- **Acceptance Criteria:**
-  - `CAP LS` advertises `safelist` (bare name, no value).
-  - `CAP REQ :safelist` is accepted, ACKed, and added to the
-    connection's negotiated cap set; `CAP LIST` then includes it.
-  - `005 RPL_ISUPPORT` advertises the bare `SAFELIST` token on every
-    line set (independent of cap negotiation — ISUPPORT is global).
-  - `LIST` still works identically before and after negotiating
-    `safelist` (no behaviour change — the cap is purely advisory).
-- **TDD Outline:** Red on `isSupportedCap('safelist')` and on a missing
-  `SAFELIST` token in the 005 output; green by adding the table entry
-  and the token; then assert end-to-end via `CAP REQ` + `CAP LIST` and
-  confirm `LIST` still produces `321`/`322`/`323`.
-
----
-
-### TICKET-063 — IRCv3 `draft/chathistory` playback (bouncer-style backlog on JOIN + explicit query)
-- **Phase:** 1
-- **Points:** 8
-- **Status:** ✅
-- **Dependencies:** TICKET-005 (JOIN ✅), TICKET-007 (PRIVMSG/NOTICE ✅),
-  TICKET-017 (CAP ✅), TICKET-018 (`message-tags` + `server-time` ✅),
-  TICKET-025 (`batch` ✅)
-- **Description:** Implement the IRCv3 `draft/chathistory` extension
-  (<https://ircv3.net/specs/extensions/chathistory>) so a reconnecting
-  client receives the messages it missed — the bouncer-style behaviour
-  users expect from ZNC / TheLounge. Two surfaces ship here:
-
-  1. **Explicit query** — a `CHATHISTORY` command with the spec subcommands
-     `BEFORE`, `AFTER`, `LATEST`, `AROUND`, `BETWEEN`, `TARGETS`. The
-     server replies with a `BATCH` of type `chathistory` containing the
-     matching `PRIVMSG`/`NOTICE`/`TAGMSG` lines, each tagged with
-     `@time=…` (server-time) and `msgid=…` (message-tags).
-  2. **Auto-playback on JOIN** — when a client with the cap negotiated
-     joins a channel, the server prepends a `BATCH chathistory` of the
-     last N messages (default 50, configurable in `ServerConfig`) to the
-     normal JOIN/353/366 sequence. A per-`(connection, channel)` "last
-     read" marker is kept in `ConnectionState` so repeated JOIN/PART
-     cycles do not re-feed the same backlog; the marker advances to the
-     newest replayed msgid on every playback.
-
-  The persistence layer is behind a new `MessageStore` port
-  (`packages/irc-core/src/ports.ts`), mirroring the `MotdProvider` /
-  `AccountStore` pattern: the port is **synchronous** for record
-  (reducers must stay pure) and **sync-returning-via-effect** for query
-  (the reducer emits a new `QueryHistory` effect that `dispatch`
-  resolves against `IrcRuntime.queryHistory`, exactly as `LookupNick`
-  and `GetConnectionInfo` are resolved today). Recording is driven by a
-  new `RecordMessage` effect emitted alongside `Broadcast` from the
-  channel PRIVMSG/NOTICE reducer; the dispatch layer fans the record
-  into the bound `MessageStore`. Concrete adapters (in-memory ring
-  buffer for tests/local-cli, D1/R2 for CF, DynamoDB for AWS) ship in
-  follow-up Phase 2/3/4 tickets — this ticket defines the contract and
-  the in-memory reference implementation only.
-
-  Cap advertisement: `draft/chathistory` (bare name, no value) in
-  `capabilities.ts`. The cap MUST be negotiated before any
-  `CHATHISTORY` command is accepted and before JOIN auto-playback is
-  emitted; clients without the cap see no change whatsoever (RFC 2812
-  behaviour).
-- **Acceptance Criteria:**
-  - `CAP LS` advertises `draft/chathistory` (bare name); `CAP REQ
-    :draft/chathistory` is ACKed and recorded on the connection.
-  - `CHATHISTORY` is `421 ERR_UNKNOWNCOMMAND` (or silently ignored per
-    spec) when the cap is not negotiated.
-  - `CHATHISTORY LATEST #foo * 50` returns up to 50 most-recent
-    messages wrapped in `BATCH +id chathistory #foo … BATCH -id`,
-    oldest first, each line carrying `@time=…;msgid=…` tags.
-  - `CHATHISTORY BEFORE #foo <msgid> 50` / `AFTER #foo <msgid> 50` /
-    `BETWEEN #foo <msgid1> <msgid2>` / `AROUND #foo <msgid> 10` return
-    the correct slices; bounds (start/end of history) return fewer
-    than the requested limit with no error.
-  - `CHATHISTORY TARGETS * *` enumerates channels with recent activity
-    (used by clients to discover what to fetch after a disconnect).
-  - Unknown msgid reference → `ERR_INVALIDPARAMS (461)` per spec;
-    non-existent channel → `403`; requester not on `+s`/`+p` channel
-    they are not a member of → empty batch (no leak).
-  - JOIN by a cap-enabled client emits the auto-playback BATCH **before**
-    the `JOIN`/`353`/`366` lines, then advances the per-connection
-    last-read marker for that channel to the newest replayed msgid.
-  - PART + re-JOIN with no new messages in between replays **nothing**
-    (marker is unchanged); PART + re-JOIN after K new messages replays
-    exactly those K.
-  - A `RecordMessage` effect is emitted for every accepted channel
-    PRIVMSG and NOTICE (NOT for NOTICE-to-user or for messages blocked
-    by `+n`/`+m`/`+b`); the dispatch layer records it via
-    `runtime.recordMessage(...)` with a fresh msgid from
-    `IdFactory.nonce()` and `ctx.clock.now()` as the timestamp.
-  - The `MessageStore` port is defined in `ports.ts`; an
-    `InMemoryMessageStore` (ring buffer, configurable max per channel)
-    ships as the reference implementation, used by the local CLI and
-    tests.
-  - 100% coverage on the new reducer, the port, the in-memory store,
-    and the JOIN/PRIVMSG hooks.
-- **TDD Outline:**
-  1. **Red** — `isSupportedCap('draft/chathistory')` returns true; cap
-     table test fails.
-  2. **Green** — add the cap entry; assert `CAP LS` / `CAP REQ` /
-     `CAP LIST` round-trip.
-  3. **Red** — `InMemoryMessageStore.record(...)` then `query({chan,
-     direction:'latest', limit:50})` returns the recorded messages in
-     chronological order; fails (no port).
-  4. **Green** — implement the ring buffer with msgid/time indices.
-  5. **Red** — channel PRIVMSG reducer emits a `RecordMessage` effect
-     alongside `Broadcast`; fails (no such effect tag).
-  6. **Green** — extend the `Effect` union with `RecordMessage`; thread
-     the msgid (`ctx.ids.nonce()`) and time (`ctx.clock.now()`) through
-     the broadcast line so the recorded payload matches what peers see.
-  7. **Red** — `chathistoryReducer` on `CHATHISTORY LATEST #foo * 2`
-     emits a `QueryHistory` effect whose resolved reply is the BATCH
-     frame; fails (no reducer).
-  8. **Green** — implement the reducer; cover each subcommand and each
-     error path as its own test.
-  9. **Red** — `joinReducer` with a cap-enabled joiner and a non-empty
-     `MessageStore` prepends a `chathistory` BATCH and advances the
-     marker; fails.
-  10. **Green** — wire the JOIN hook; cover the empty-store case, the
-      PART/re-JOIN no-op case, and the marker-advance case.
-  11. **Refactor** — extract the BATCH-wrapping into a shared helper
-      alongside `wrapBatch` (TICKET-025) so the chathistory BATCH and
-      the NAMES BATCH share framing code.
-- **Out of scope (follow-up tickets):**
-  - Phase 2 — wire the `MessageStore` into `ConnectionActor` +
-    `IrcRuntime`; ship a persistent variant in `in-memory-runtime`.
-  - Phase 3 — `R2`/`D1`-backed `MessageStore` for the CF adapter
-    (`MessageStoreDO` keyed by lowercased channel, lifecycle-managed by
-    `ChannelDO`). Retention/TTL policy goes here.
-  - Phase 4 — DynamoDB-backed `MessageStore` for the AWS adapter
-    (`Messages` table, partition key `chan`, sort key `time`; GSI on
-    `msgid` for BEFORE/AFTER pivots).
-  - Per-user `+H` channel mode (max history entries) and
-    `draft/pre-away` markers — these layer on top of this ticket's
-    marker plumbing.
-
----
-
-### TICKET-064 — Flood control: per-command cost + control-plane exemption
-- **Phase:** 1
-- **Points:** 2
-- **Status:** ⬜
-- **Dependencies:** TICKET-028 (✅)
-- **Description:** The flood-control wrapper landed in TICKET-028
-  charges a flat `MESSAGE_COST = 1` for every observed command. That is
-  too blunt: a client exchanging `PING`/`PONG` with the server, or
-  negotiating `CAP` / `AUTHENTICATE` during SASL, can flood itself out
-  through no fault of its own — mainstream ircds (charybdis, hybrid,
-  Unreal) exempt exactly these control-plane commands for that reason.
-  This ticket generalizes `FloodControlConfig` so the cost is a pure
-  function of the command name, ships a sensible default exemption set,
-  and keeps backward compatibility with the v1 flat-cost behaviour.
-- **Acceptance Criteria:**
-  - `FloodControlConfig` gains an optional `commandCost?: (command:
-    string) => number` field. When omitted, the wrapper uses the
-    existing flat cost (`1`) for every command — i.e. TICKET-028
-    callers see no behaviour change.
-  - The wrapper exports a ready-made `defaultCommandCost` function (or
-    equivalent named export) that returns `0` for the exempt set
-    `PING`, `PONG`, `CAP`, `AUTHENTICATE`, `QUIT` and `1` for
-    everything else. The set is documented inline and overridable by
-    callers composing their own cost function.
-  - A command with cost `0` does NOT decrement the bucket and does NOT
-    trigger the disconnect path even when the bucket is exhausted —
-    the inner reducer is called as normal.
-  - Negative costs are rejected at wrapper-construction time (throw /
-    assert) — they would invert the bucket.
-  - Cost is derived from the parsed `IrcMessage.command` (uppercased
-    by the parser), so case-insensitivity is handled once.
-  - Determinism preserved: same `(Clock, message stream)` → same
-    decision, regardless of cost function (the cost function itself
-    is pure).
-  - 100% coverage on the new code paths in `flood-control.ts`,
-    including the rejection path and the `commandCost === undefined`
-    fallback.
-- **TDD Outline:**
-  1. Red — `PING` arriving when the bucket is at `0` tokens still
-     delegates to the inner reducer (currently fails: wrapper
-     disconnects). Green by adding the cost seam and the default
-     exempt set.
-  2. Red — passing a `commandCost` that returns `0` for `CAP` and
-     asserting a `CAP LS` burst (10 frames in 1ms with capacity 5)
-     does NOT disconnect; green.
-  3. Red — `commandCost: () => -1` throws at
-     `wrapWithFloodControl(...)` time; green by validating.
-  4. Red — when `commandCost` is omitted, behaviour matches
-     TICKET-028 exactly (regression test on the existing 11-test
-     suite; all still pass unchanged).
-  5. Refactor — extract the cost decision into a tiny pure helper so
-     the disconnect branch and the pass-through branch share one
-     "new balance" computation.
-
-### TICKET-065 — Wire `wrapWithFloodControl` into the `ConnectionActor`
-- **Phase:** 2
-- **Points:** 3
-- **Status:** ⬜
-- **Dependencies:** TICKET-028 (✅), TICKET-030 (✅)
-- **Description:** The flood-control wrapper (TICKET-028) and its
-  per-command cost refinement (TICKET-064, recommended-first) exist but
-  are not applied anywhere — a client can still send an unbounded
-  command stream to a `ConnectionActor` and the actor will route every
-  frame. This ticket wires the wrapper into the actor pipeline so a
-  flooding connection is actually disconnected end-to-end, with the
-  thresholds sourced from `ServerConfig` so deployments can tune or
-  disable flood control without code changes. Mirrors the shape of the
-  other "wire reducer X into the actor" tickets (TICKET-059 / -060 /
-  -061).
-- **Acceptance Criteria:**
-  - `ServerConfig` gains an optional `floodControl?: FloodControlConfig
-    & { commandCost?: ... }` field (shape delegated to TICKET-064).
-    When omitted, the actor applies a documented default
-    (`{ capacity, refillRatePerSecond, disconnectThreshold }` matching
-    the charybdis-class defaults cited in the flood-control tests);
-    when set to `null` explicitly, flood control is disabled for that
-    deployment.
-  - The actor wraps every reducer it dispatches (connection-authority
-    AND channel-authority routes) so flooding is bounded regardless of
-    target — flood control is about bytes-in from the client, not
-    about which state the command mutates.
-  - The wrapped reducer receives a `ctx.clock` consistent with the
-    actor's existing `Clock` injection (no new time source).
-  - An actor-level test: a client sending `capacity + threshold + 1`
-    `PRIVMSG` frames at fake-clock `t=0` is disconnected with a
-    `Disconnect("Excess Flood")` effect that the actor dispatches to
-    the bound `IrcRuntime`, and the underlying socket/close path is
-    invoked (asserted via a fake runtime + close spy).
-  - A second actor-level test: `PING`/`CAP` frames interleaved into the
-    burst do NOT advance the bucket (proves TICKET-064 is plumbed
-    through) — gated on TICKET-064 landing first; if 064 has not
-    landed, this test is skipped or adapted to the flat-cost model.
-  - The `apps/local-cli` server boots with the default config and a
-    manual flood (e.g. `yes 'PRIVMSG #foo :bar' | nc`) disconnects the
-    client within the configured threshold.
-  - Existing actor tests stay green; the wrapper is additive.
-- **TDD Outline:**
-  1. Red — actor test: 20 `PRIVMSG` frames in one tick against the
-     default-capacity bucket emit a `Disconnect` to the fake runtime;
-     currently fails (no wiring). Green by wrapping the reducer map at
-     actor construction.
-  2. Red — actor test: `ServerConfig.floodControl = null` disables the
-     wrapper and the same 20-frame burst passes through; green by
-     gating wrapper construction on the config field.
-  3. Red — actor test: a `PING` interleaved into the burst does not
-     change the disconnect count; green by threading
-     `commandCost`/TICKET-064's default exempt set into the wired
-     config.
-  4. Refactor — extract reducer-map construction into a pure
-     `buildRoutedReducers(config)` helper so the actor and tests can
-     inspect the wrapped map without spinning up a full actor.
-  5. Manual smoke against `apps/local-cli` (documented in the ticket
-     PR, not automated) confirming a real client gets dropped on flood.
-- **Out of scope (follow-ups):**
-  - Per-IP / per-listener rate limits beyond the per-connection bucket
-    (TICKET-046 territory).
-  - Queue-based policy (still needs a `Buffer` effect — separate
-    ticket).
-  - Observability metrics (disconnects/sec) — TICKET-045.
-
----
-
-### TICKET-069 — Wire `CHATHISTORY` into the `ConnectionActor` dispatcher + `MessageStore` plumbing
-- **Phase:** 1
-- **Points:** 3
-- **Status:** ✅
-- **Dependencies:** TICKET-063 (chathistory reducer + `MessageStore`, ✅),
-  TICKET-030 (actor, ✅), TICKET-059/060/061 (actor wiring pattern, ✅)
-- **Description:** The pure `chathistoryReducer`
-  (`packages/irc-core/src/commands/chathistory.ts`) is fully implemented
-  and tested (TICKET-063 ✅), but `ConnectionActor.route()`
-  (`packages/irc-server/src/actor.ts`) has no `case 'CHATHISTORY'`, so the
-  command falls through to the `default` branch → `421
-  ERR_UNKNOWNCOMMAND`. Additionally the actor's `buildCtx({...})` call
-  does not thread a `MessageStore`, so `ctx.messages` is always
-  `undefined`: chathistory has no data to read, and the PRIVMSG/NOTICE
-  recording path (`ctx.messages.record(...)` in the channel reducer) is
-  inert. This ticket is the wiring layer (the mirror of TICKET-059/060/061
-  which wired WHOIS/AUTHENTICATE/AWAY into the actor) — the reducer itself
-  is NOT modified.
-
-  Two changes:
-  1. **`MessageStore` plumbing** — add an optional `messages?` field to
-     `ConnectionActorOptions`, store it on the actor, and pass it to
-     `buildCtx({...})` so `ctx.messages` is defined when a store is bound
-     (and stays `undefined` when none is bound, preserving no-store
-     behaviour for existing callers/tests). This lights up the
-     synchronous recording path in the PRIVMSG/NOTICE channel reducer
-     (the data source for JOIN auto-playback) without touching `dispatch`
-     or `IrcRuntime` (recording is synchronous, no new `Effect`).
-  2. **Dispatcher routing** — add `case 'CHATHISTORY'` that calls
-     `chathistoryReducer(channel, msg, ctx).effects` directly (the same
-     bespoke-signature pattern as `routeList`/`routeWho`/`routeWhois`; NOT
-     added to `buildRoutedReducers`). The target channel is
-     `msg.params[1]` (params[0] is the subcommand). It must be resolved
-     WITHOUT creating it as a side effect: add an optional `getChannel?`
-     peek to `ActorChannelAccess` (mirrors `refreshChannel?`) and have the
-     in-memory runtimes implement it; pass `undefined` when the channel
-     does not exist (reducer emits `403`).
-- **Acceptance Criteria:**
-  - `actor.ts` contains a `case 'CHATHISTORY'`.
-  - A connection that negotiated `draft/chathistory` (plus `server-time`,
-    `message-tags`, `batch`), with a bound `InMemoryMessageStore` seeded
-    with messages in `#foo`, receiving `CHATHISTORY LATEST #foo * 2` emits
-    a `BATCH +… chathistory` frame (NOT `421`).
-  - A connection WITHOUT the cap receiving `CHATHISTORY ...` still gets
-    `421` (routing reaches the reducer, which does cap-gating internally).
-  - An unknown channel target emits `403 ERR_NOSUCHCHANNEL` via the reducer.
-  - `ctx.messages` is `undefined` when no store is bound; existing actor
-    tests pass unchanged (no crash, PRIVMSG does not record).
-  - A channel PRIVMSG through the actor with a bound store records into
-    the store (the JOIN auto-playback data source).
-  - `ActorChannelAccess` gains an optional `getChannel?` peek; resolving a
-    CHATHISTORY target never creates a channel.
-  - `packages/irc-core` chathistory tests remain green UNCHANGED (reducer
-    behaviour is not modified).
-- **TDD Outline:**
-  1. **Red #1** — actor test: bound store + negotiated caps + seeded
-     messages + `CHATHISTORY LATEST #foo * 2` → expects a `BATCH
-     chathistory` frame, not `421`. Currently fails (421 fallthrough).
-  2. **Red #2** — actor test: no cap + `CHATHISTORY ...` → still `421`
-     (regression: routing reaches the reducer which cap-gates).
-  3. **Green** — add `case 'CHATHISTORY'`; thread `messages` into
-     `buildCtx`; add `getChannel?` peek + implement in `FakeRuntime`; cover
-     the unknown-target (→ `403`) path.
-  4. **Refactor** — confirm no-store callers behave unchanged; assert
-     PRIVMSG recording lights up when a store is bound.
-
----
-
-## Phase 8 — PLAN-FIXES Remediation
-
-Tickets derived from `PLAN-FIXES.md` (the post-Phase-1–7 audit of stubbed,
-incomplete, and not-fully-wired functionality). Each ticket's **Phase:**
-field records the logical phase the work conceptually belongs to (the
-section it remediates); the tickets are collected here as a single
-remediation batch for clean tracking. Grouped by PLAN-FIXES severity:
-**Critical** (TICKET-070–074) → **Absent IRC commands** (TICKET-075–078) →
-**Partial** (TICKET-079–085) → **Minor / Dead scaffolding**
-(TICKET-086–092).
-
----
-
-### TICKET-070 — Wire `MessageStore` into all three adapters (chathistory end-to-end)
-- **Phase:** 8 (remediates Phase 3/4 wiring; cross-cutting)
-- **Points:** 5
-- **Status:** ⬜
-- **Dependencies:** TICKET-069 (actor `MessageStore` plumbing, ✅),
-  TICKET-063 (chathistory reducer + `MessageStore` port, ✅)
-- **Description:** PLAN-FIXES #1. `ConnectionActor` accepts
-  `messages?: MessageStore` (`packages/irc-server/src/actor.ts:105`)
-  since TICKET-069, and `irc-core` ships a complete
-  `InMemoryMessageStore`, the `CHATHISTORY` reducer, and JOIN
-  auto-playback. None of the three adapters construct and pass a
-  `MessageStore` at the actor-construction sites:
-
-  - `packages/cf-adapter/src/connection-do.ts:303-312`
-  - `packages/aws-adapter/src/handlers/default.ts:103-111`
-  - `apps/local-cli/src/server.ts:480-501`
-
-  **Impact:** chathistory recording and playback are dead code outside
-  unit tests; `ctx.messages` is always `undefined` in any deployment, so
-  the `draft/chathistory` cap (TICKET-063) is advertised but never
-  functional end-to-end.
-- **Acceptance Criteria:**
-  - Each adapter constructs a `MessageStore` instance and passes it via
-    `messages: ...` in `ConnectionActorOptions`.
-  - `apps/local-cli`: `InMemoryMessageStore` (per-process ring buffer,
-    config-driven max-per-channel).
-  - CF adapter: a `MessageStore` scoped to the connection (in-worker
-    `InMemoryMessageStore` as the minimum viable impl; a
-    Durable-Object-backed persistent variant is a documented follow-up).
-  - AWS adapter: a DynamoDB-backed `MessageStore` (new `Messages` table,
-    partition key `chan`, sort key `time`, GSI on `msgid` for
-    BEFORE/AFTER pivots) OR an in-memory v1 impl with persistence as a
-    documented follow-up.
-  - End-to-end per adapter: a client negotiating `draft/chathistory` +
-    `server-time` + `message-tags` + `batch`, sending a PRIVMSG to a
-    channel, then issuing `CHATHISTORY LATEST #chan * 10`, receives the
-    recorded message back in a `BATCH +… chathistory` frame.
-  - JOIN auto-playback prepends a BATCH on rejoin after messages were
-    sent while the client was away.
-  - 100% coverage on the new adapter wiring code.
-- **TDD Outline:**
-  1. Red — per adapter, an integration test asserting
-     `CHATHISTORY LATEST` returns the just-recorded PRIVMSG; currently
-     fails (store not bound → empty result).
-  2. Green — construct and bind the store at each actor-construction
-     site.
-  3. Refactor — extract a shared `bindMessageStore(env/config)` helper
-     per adapter so the construction logic is unit-testable in isolation.
-- **Out of scope:** retention/TTL policies on the persistent stores
-  (follow-up once the storage shape lands).
-
----
-
-### TICKET-071 — Wire `AccountStore` into the `ConnectionActor` (SASL PLAIN end-to-end)
-- **Phase:** 8 (remediates Phase 3/4 wiring; cross-cutting)
-- **Points:** 8
-- **Status:** ⬜
-- **Dependencies:** TICKET-026 (SASL reducer, ✅),
-  TICKET-060 (AUTHENTICATE actor wiring, ✅)
-- **Description:** PLAN-FIXES #2. `ConnectionActorOptions`
-  (`packages/irc-server/src/actor.ts:89-119`) has **no `accounts`**
-  field, and `route()` → `buildCtx()`
-  (`packages/irc-server/src/actor.ts:238-245`) never supplies one, even
-  though `buildCtx` supports it
-  (`packages/irc-core/src/types.ts:143`).
-
-  **Impact:** SASL PLAIN authentication can never succeed in any
-  adapter. A client completing `AUTHENTICATE PLAIN` always receives
-  `904 ERR_SASLFAIL` because `ctx.accounts` is `undefined`. Only unit
-  tests (which call `buildCtx` directly) exercise the happy path.
-- **Acceptance Criteria:**
-  - `ConnectionActorOptions` gains an optional `accounts?: AccountStore`
-    field; the actor stores it and forwards it through `route()` into
-    `buildCtx`.
-  - When no store is bound, `ctx.accounts` is `undefined` (existing
-    behaviour preserved for callers/tests that do not opt in).
-  - Each adapter supplies an `AccountStore`:
-    - CF: an in-worker `AccountStore` seeded from config as the minimum
-      viable impl; a Durable-Object / D1-backed persistent variant is a
-      follow-up.
-    - AWS: a DynamoDB-backed `AccountStore` against the `Accounts` table
-      (cross-ref TICKET-072).
-    - local-cli: an in-memory `AccountStore` seeded from config.
-  - End-to-end per adapter: a client negotiating `sasl` and sending
-    `AUTHENTICATE PLAIN` with valid creds gets `900`/`903`; invalid creds
-    get `904`; the account name is recorded on the connection for
-    `extended-join`/`account-tag`.
-  - 100% coverage on the actor plumbing and on each adapter's
-    `AccountStore`.
-- **TDD Outline:**
-  1. Red — actor test: bound `AccountStore` + `AUTHENTICATE PLAIN` with
-     valid creds returns `903`; currently fails (always `904`).
-  2. Red — actor test: no store bound + `AUTHENTICATE PLAIN` returns
-     `904` (regression guard preserving existing behaviour).
-  3. Green — add `accounts?` to options; thread into `buildCtx`.
-  4. Red — per adapter: end-to-end `AUTHENTICATE PLAIN` with a seeded
-     account.
-  5. Green — implement each adapter's `AccountStore`.
-  6. Refactor — share credential-resolution logic across adapters via a
-     helper.
-
----
-
-### TICKET-072 — Decide fate of AWS `Accounts` DynamoDB table (implement AccountStore or remove)
-- **Phase:** 8 (remediates Phase 4)
-- **Points:** 8
-- **Status:** ⬜
-- **Dependencies:** TICKET-039 (CDK stack, ✅),
-  TICKET-071 (AccountStore plumbing)
-- **Description:** PLAN-FIXES #5. The `Accounts` DynamoDB table is
-  provisioned in CDK (`packages/aws-adapter/src/cdk-table-defs.ts:61-65`)
-  and required by `tablesConfigFromNames`, but no runtime code reads or
-  writes it. No `AccountStore` implementation is backed by it.
-
-  **Impact:** paid-for infrastructure with no consumer; also blocks SASL
-  account persistence (see TICKET-071).
-- **Acceptance Criteria:**
-  - Decision documented in an ADR or in `docs/AWS-Deployment.md`:
-    either (a) implement a DynamoDB-backed `AccountStore`, or (b) remove
-    the table until it is needed.
-  - If implementing: a `DynamoAccountStore` class backed by the
-    `Accounts` table; `verify('PLAIN', payload)` queries by username,
-    validates credentials (hashed — never plaintext), returns the
-    account. CRUD/seed tooling for adding oper/SASL accounts documented.
-  - If removing: `cdk-table-defs.ts` no longer provisions `Accounts`;
-    `tablesConfigFromNames` no longer requires it; deploy notes updated;
-    TICKET-071's AWS adapter uses an in-memory store seeded from Secrets
-    Manager / SSM until persistence is needed.
-  - `cdk diff` reflects the chosen path; existing synth tests updated.
-  - 100% coverage on whichever code path ships.
-- **TDD Outline:**
-  1. Decision spike — implement-vs-remove; document in the ticket PR.
-  2. Red — synth/integration test asserting the chosen end state (table
-     present + `AccountStore` implemented, OR table absent); currently
-     fails (table present, no consumer).
-  3. Green — implement the chosen path.
-  4. Refactor — extract the `AccountStore`-vs-table decision into config
-     so operators can swap implementations.
-
----
-
-### TICKET-073 — Cloudflare runtime: implement stubbed `getConnection`/`getChannelConnections`/`listChannels`/cross-connection `disconnect`
-- **Phase:** 8 (remediates Phase 3)
-- **Points:** 13
-- **Status:** ⬜
-- **Dependencies:** TICKET-036 (CfRuntime, ✅),
-  TICKET-033 (ConnectionDO, ✅), TICKET-035 (ChannelDO, ✅)
-- **Description:** PLAN-FIXES #3. The AWS runtime fully implements all
-  16 `IrcRuntime` methods against DynamoDB. The CF runtime
-  (`packages/cf-adapter/src/cf-runtime.ts`) has explicit stubs that
-  break three commands plus remote disconnect for anything beyond the
-  local connection:
-
-  | Method | Line | Stub | Impact |
-  |---|---|---|---|
-  | `getConnection()` | cf-runtime.ts:234-244 | returns `null` for remote conns | Remote WHOIS broken (only `401` + `318`) |
-  | `getChannelConnections()` | cf-runtime.ts:246-251 | returns empty `Map` | WHO broken on CF |
-  | `listChannels()` | cf-runtime.ts:253-258 | returns `[]` | LIST returns no channels on CF |
-  | `disconnect()` | cf-runtime.ts:115-126 | cross-connection disconnect is a no-op | KICK of a remote user does not close their socket |
-
-  **Fix:** add the missing ConnectionDO RPCs (`getConnState`,
-  channel-membership enumeration, a channel registry) and a
-  cross-connection `disconnect` RPC; wire `cf-runtime.ts` to call them.
-- **Acceptance Criteria:**
-  - New ConnectionDO RPCs: `getConnState()` returns the connection's
-    authoritative `ConnectionState`; cross-connection
-    `disconnect(reason)` closes the target DO's WebSocket.
-  - New channel-membership enumeration RPC on `ChannelDO` so
-    `getChannelConnections(chan)` can resolve every member to a
-    `ConnectionState` via the new `getConnState` RPC.
-  - Channel registry for `listChannels()`: either a dedicated
-    `ChannelRegistryDO` or a KV-backed index updated on channel
-    create/destroy.
-  - `cf-runtime.ts`:
-    - `getConnection(remoteConn)` → calls the target ConnectionDO's
-      `getConnState` RPC; returns `null` on missing/gone.
-    - `getChannelConnections(chan)` → enumerates ChannelDO members and
-      resolves each to a `ConnectionState`.
-    - `listChannels()` → queries the registry; returns `ChanSnapshot[]`.
-    - `disconnect(remoteConn, reason)` → calls the target ConnectionDO's
-      `disconnect` RPC; no-op on missing.
-  - WHOIS of a remote user on CF returns the full
-    `311`/`319`/`312`/`317`/`318` sequence (not just `401`+`318`).
-  - WHO on CF returns channel members.
-  - LIST on CF returns channels.
-  - KICK of a remote user closes their WebSocket on CF.
-  - Phase 2 integration suite (TICKET-032) green against the
-    now-complete `CfRuntime`.
-  - 100% coverage on the new RPCs and the cf-runtime.ts methods.
-- **TDD Outline:**
-  1. Red — unit test: `cfRuntime.getConnection(remoteConnId)` returns a
-     non-null `ConnectionState` when the stub returns one; currently
-     fails (returns `null`).
-  2. Green — add `getConnState` RPC to ConnectionDO; wire `getConnection`.
-  3. Red — WHOIS integration: a remote user returns `311`, not just
-     `401`+`318`.
-  4. Green — verify the WHOIS reducer now receives remote state.
-  5. Red — `getChannelConnections(chan)` returns members; currently
-     fails (empty `Map`).
-  6. Green — implement the channel-membership enumeration RPC.
-  7. Red — `listChannels()` returns channels; currently fails (`[]`).
-  8. Green — implement the channel registry (design: dedicated DO vs KV
-     index).
-  9. Red — `disconnect(remoteConn)` closes the target socket.
-  10. Green — add `disconnect` RPC to ConnectionDO.
-  11. Refactor — share RPC stub-typing across ConnectionDO/ChannelDO/
-      RegistryDO.
-- **Out of scope:** CF TCP+TLS adapter (Phase 7 — TICKET-055); this
-  ticket is the wss DO path only.
-
----
-
-### TICKET-074 — AWS disconnect: broadcast QUIT to peers
-- **Phase:** 8 (remediates Phase 4)
-- **Points:** 5
-- **Status:** ⬜
-- **Dependencies:** TICKET-040 (AwsRuntime, ✅),
-  TICKET-003 (QUIT reducer, ✅)
-- **Description:** PLAN-FIXES #4.
-  `packages/aws-adapter/src/aws-runtime.ts:645` — `cleanupConnection`
-  explicitly discards `managementApi` (`void managementApi;`) and never
-  broadcasts QUIT. Confirmed at the call site:
-  `packages/aws-adapter/src/handlers/disconnect.ts:28` hardcodes `null`.
-
-  **Impact:** when a connection tears down, peers in shared channels
-  never receive the QUIT fanout. Their local rosters go stale until a
-  subsequent broadcast prunes the ghost member.
-- **Acceptance Criteria:**
-  - `handleDisconnect` (`handlers/disconnect.ts`) threads the
-    `managementApi` (or a `PostToConnection`) through to
-    `cleanupConnection`.
-  - `cleanupConnection` builds a QUIT line for the disconnecting
-    connection and, for each channel in `joinedChannels`, fans the QUIT
-    out to every other member via `managementApi.PostToConnection`.
-  - Gone connections during fanout are caught (`GoneException` path) and
-    trigger lazy cleanup — no crash on a partially-torn-down roster.
-  - Both the `$disconnect` route and the `$default`/send `GoneException`
-    cleanup path emit QUIT fanout.
-  - Integration test: two connections sharing a channel; connection A's
-    `$disconnect` causes connection B to receive `:A QUIT :reason`.
-  - 100% coverage on the new fanout code.
-- **TDD Outline:**
-  1. Red — integration test asserting peer B receives QUIT on A's
-     disconnect; currently fails (no fanout).
-  2. Green — thread `managementApi`; implement fanout.
-  3. Red — fanout to a gone peer triggers lazy cleanup, not a crash.
-  4. Green — wrap `PostToConnection` in try/catch; route
-     `GoneException` to cleanup.
-  5. Refactor — extract the fanout loop into a shared
-     `broadcastQuitToChannels(...)` helper reusable by both
-     `$disconnect` and the `GoneException` sweep.
-
----
-
-### TICKET-075 — Implement `OPER` command (verify creds, set oper mode, emit `381`)
-- **Phase:** 8 (remediates Phase 1)
-- **Points:** 5
-- **Status:** ⬜
-- **Dependencies:** TICKET-011 (MODE reducer, ✅),
-  TICKET-047 (oper creds config, ✅),
-  TICKET-015 (WHOIS reducer exposing `RPL_WHOISOPERATOR`, ✅)
-- **Description:** PLAN-FIXES #6. No `OPER` case in `actor.ts` `route()`
-  switch, no reducer, no entry in `packages/irc-core/src/commands/`.
-  Referenced everywhere as scaffolding:
-
-  - `packages/irc-core/src/commands/mode.ts:15` — comment: *"The oper
-    flag (`+o`) is granted via the future OPER command, not via MODE."*
-  - `packages/irc-core/src/commands/mode.ts:547, 612-624` — user
-    `MODE +o` hard-rejected with `481 ERR_NOPRIVILEGES`, gated on an
-    OPER command that does not exist.
-  - `operCreds` is defined, validated, and loaded by **all three
-    adapters** (`packages/cf-adapter/src/config-loader.ts:65`,
-    `packages/aws-adapter/src/config-loader.ts:59`,
-    `apps/local-cli/src/config-loader.ts:27`) but no runtime code ever
-    reads `serverConfig.operCreds`.
-  - Reserved-but-unused numerics: `RPL_YOUREOPER: 381`,
-    `RPL_REHASHING: 382`, `ERR_NOOPERHOST: 491`
-    (`packages/irc-core/src/numerics.ts:75-76, 138`).
-
-  **Impact:** `state.userModes.oper` can never become `true` via any
-  command flow, so the `RPL_WHOISOPERATOR` (`313`) branch in
-  `packages/irc-core/src/commands/whois.ts:132-136` and the WHO `*`
-  oper flag (`packages/irc-core/src/commands/who.ts:69`) are
-  unreachable.
-- **Acceptance Criteria:**
-  - A new `operReducer` in `packages/irc-core/src/commands/oper.ts`:
-    parses `OPER <name> <password>`, verifies against
-    `serverConfig.operCreds`, on success sets `state.userModes.oper =
-    true` and emits `381 RPL_YOUREOPER`.
-  - Wrong password / unknown name → `464 ERR_PASSWELCOME` (or `491
-    ERR_NOOPERHOST` if no creds configured).
-  - Already-oper → graceful no-op or `462`-style reply.
-  - Route case `OPER` added to `actor.ts` switch.
-  - `RPL_WHOISOPERATOR (313)` branch in `whois.ts` now reachable: a
-    WHOIS of an oper returns `313`.
-  - WHO `*` oper flag (`who.ts:69`) now reachable.
-  - `mode.ts:612-624` user `MODE +o` rejection stays (oper is set via
-    OPER, not MODE); the comment at `mode.ts:15` is updated to past
-    tense now that OPER exists.
-  - 100% coverage on `operReducer`; existing whois/who oper-branch tests
-    updated to use a real oper.
-- **TDD Outline:**
-  1. Red — reducer test: `OPER alice secret` against a config with
-     `operCreds: [{name:'alice', password:'secret'}]` sets `oper:true`
-     and emits `381`; currently fails (no reducer).
-  2. Green — implement `operReducer`.
-  3. Red — wrong password → `464`; no creds configured → `491`.
-  4. Green — cover error paths.
-  5. Red — actor test: routed `OPER` does not return `421`.
-  6. Green — add the route case.
-  7. Red — WHOIS of an oper returns `313`.
-  8. Green — verify the existing whois branch now lights up.
-  9. Refactor — extract credential-match into a pure helper.
-- **Out of scope:** oper-gated verbs `KILL`/`REHASH`/`CONNECT`/`SQUIT`/
-  `TRACE` (TICKET-078).
-
----
-
-### TICKET-076 — Implement `TAGMSG` command (IRCv3 `message-tags` recorder)
-- **Phase:** 8 (remediates Phase 1)
-- **Points:** 3
-- **Status:** ⬜
-- **Dependencies:** TICKET-018 (`message-tags`, ✅),
-  TICKET-063 (chathistory, ✅), TICKET-070 (`MessageStore` wiring)
-- **Description:** PLAN-FIXES #7. `StoredCommand = 'PRIVMSG' | 'NOTICE' |
-  'TAGMSG'` (`packages/irc-core/src/ports.ts:200`) and
-  `packages/irc-core/src/commands/chathistory.ts:237-238` contain real
-  replay code for a stored TAGMSG. But nothing ever records one: the
-  only call to `ctx.messages.record(...)` is
-  `packages/irc-core/src/commands/privmsg.ts:188`, which records
-  PRIVMSG/NOTICE only.
-
-  **Impact:** the `message-tags` cap is advertised
-  (`packages/irc-core/src/caps/capabilities.ts:33`) with no command that
-  consumes it. The TAGMSG replay branch in `chathistory.ts` is dead
-  code.
-- **Acceptance Criteria:**
-  - A `TAGMSG` reducer (new file or extension to `privmsg.ts`) handles
-    `TAGMSG <target> +tag1=value1;tag2`.
-  - Channel TAGMSG broadcasts to members (excluding sender unless
-    `echo-message` is negotiated) carrying the tag set.
-  - Private TAGMSG to a user routes via `LookupNick`.
-  - Channel TAGMSG records via `ctx.messages.record({ command:
-    'TAGMSG', ... })` when a `MessageStore` is bound (the data source
-    for chathistory replay).
-  - NOTICE-style rule: TAGMSG MUST NOT trigger numeric error replies
-    (it is a stateless tag broadcast per the IRCv3 spec).
-  - Without the `message-tags` cap: the command is `421
-    ERR_UNKNOWNCOMMAND` (per spec).
-  - Route case `TAGMSG` added to `actor.ts`.
-  - chathistory replay now returns recorded TAGMSGs in BATCH output.
-  - 100% coverage on the new reducer and route case.
-- **TDD Outline:**
-  1. Red — reducer test: `TAGMSG #foo +foo=bar` to a channel broadcasts
-     the line; currently fails (no reducer).
-  2. Green — implement the `TAGMSG` reducer.
-  3. Red — recording: with a bound `MessageStore`,
-     `ctx.messages.record` receives a TAGMSG entry.
-  4. Green — wire the record path.
-  5. Red — actor test: `TAGMSG` routes (no `421`).
-  6. Green — add the route case.
-  7. Red — chathistory LATEST returns recorded TAGMSGs.
-  8. Refactor — share the broadcast/record loop with `privmsg.ts`.
-
----
-
-### TICKET-077 — Implement `WHOWAS` (or drop the numerics)
-- **Phase:** 8 (remediates Phase 1)
-- **Points:** 5
-- **Status:** ⬜
-- **Dependencies:** TICKET-015 (WHOIS reducer, ✅),
-  TICKET-003 (QUIT reducer, ✅)
-- **Description:** PLAN-FIXES #8. `RPL_ENDOFWHOWAS: 369`,
-  `ERR_WASNOSUCHNICK: 406` are defined
-  (`packages/irc-core/src/numerics.ts:65, 97`); no reducer, no route
-  case.
-- **Acceptance Criteria:**
-  - Decision documented in the ticket PR: either implement WHOWAS or
-    remove the numerics.
-  - If implementing:
-    - A nick-history store (port + in-memory reference impl): records
-      `(nick, connId, username, hostname, signoffTime)` on
-      QUIT/NICK-change; purged past a configurable TTL.
-    - `WHOWAS <nick>{,<nick>} [<count>]` queries the store; emits `314
-      RPL_WHOWASUSER` per match, `369 RPL_ENDOFWHOWAS` terminator, `406
-      ERR_WASNOSUCHNICK` when no match.
-    - Route case `WHOWAS` added to `actor.ts`.
-  - If dropping: remove `RPL_ENDOFWHOWAS`/`ERR_WASNOSUCHNICK` from
-    `numerics.ts`; update any tests referencing them; note the decision
-    in `docs/`.
-  - 100% coverage on whichever path ships.
-- **TDD Outline:**
-  1. Decision spike — pick implement-vs-drop; document in the ticket PR.
-  2. Red (if implementing) — reducer test: `WHOWAS alice` after alice
-     QUIT returns `314`; currently fails (no reducer).
-  3. Green — implement `whowasReducer` + the nick-history store.
-  4. Red — `WHOWAS unknownnick` → `406`.
-  5. Green — cover the no-match path.
-  6. Red — actor test: `WHOWAS` routes.
-  7. Green — add the route case.
-  8. Refactor — share nick-history plumbing with the QUIT/NICK-change
-     reducers that populate it.
-
----
-
-### TICKET-078 — Implement (or drop) remaining standard IRC verbs
-- **Phase:** 8 (remediates Phase 1)
-- **Points:** 5
-- **Status:** ⬜
-- **Dependencies:** TICKET-030 (actor, ✅),
-  TICKET-047 (config, ✅),
-  TICKET-075 (oper — gates oper-only verbs)
-- **Description:** PLAN-FIXES #9. Commands currently returning `421
-  ERR_UNKNOWNCOMMAND` via `actor.ts:318-319` (graceful, not broken):
-
-  `VERSION`, `ADMIN`, `INFO`, `TIME`, `STATS`, `LUSERS`, `LINKS`,
-  `USERHOST`, `ISON`, `WALLOPS`, `SETNAME`, `KILL`, `REHASH`,
-  `CONNECT`, `TRACE`, `SQUIT`, `SERVICE`, `SUMMON`, `USERS`.
-
-  Several have dedicated numerics defined but unused: `RPL_USERHOST:
-  302`, `RPL_ISON: 303`, `RPL_INFO: 371`, `RPL_LINKS: 364`,
-  `RPL_TIME: 391`, `RPL_ADMINME: 256`.
-- **Acceptance Criteria:**
-  - Triage documented in the ticket PR: classify each verb as
-    implement / drop / defer. Recommended minimum viable set to
-    implement: `VERSION` (uses `SERVER_VERSION` + `SERVER_NAME`),
-    `TIME` (uses `Clock`), `USERHOST` (uses `ConnectionState`),
-    `ISON` (uses `ConnectionState`/registry), `LUSERS` (uses runtime
-    stats).
-  - For each implemented verb: a reducer in
-    `packages/irc-core/src/commands/`, a route case in `actor.ts`, and
-    spec-correct numeric replies.
-  - For each dropped verb: either remove the unused numerics (if
-    exclusive to that verb) or leave a comment explaining why the
-    numeric is retained.
-  - `KILL`, `REHASH`, `CONNECT`, `SQUIT`, `TRACE` — oper-gated (depend
-    on TICKET-075); implement only if oper has landed, otherwise defer
-    with a documented note.
-  - 100% coverage on each implemented reducer.
-- **TDD Outline:**
-  1. Red — one test per implemented verb (e.g. `VERSION` returns `351`
-     with the configured version); currently fails (`421`).
-  2. Green — implement each reducer; add the route case.
-  3. Red — oper-gated verbs return `481` for non-opers
-     (post-TICKET-075).
-  4. Refactor — share a "config-derived reply" helper across
-     `VERSION`/`ADMIN`/`INFO`.
-
----
-
-### TICKET-079 — SASL `EXTERNAL`: implement mTLS-backed auth OR stop advertising
-- **Phase:** 8 (remediates Phase 5; supersedes the EXTERNAL stub in
-  TICKET-026)
-- **Points:** 2
-- **Status:** ⬜
-- **Dependencies:** TICKET-026 (SASL reducer, ✅)
-- **Description:** PLAN-FIXES #10.
-  `packages/irc-core/src/commands/sasl.ts:95-97` recognizes
-  `AUTHENTICATE EXTERNAL` but unconditionally returns `904
-  ERR_SASLFAIL`. The `sasl` cap advertises `PLAIN,EXTERNAL`
-  (`packages/irc-core/src/caps/capabilities.ts:36`,
-  `packages/irc-core/src/commands/sasl.ts:42`
-  `SUPPORTED_MECHS = 'PLAIN,EXTERNAL'`).
-
-  **Impact:** EXTERNAL is advertised but non-functional. (PLAIN is fully
-  implemented but see TICKET-071.)
-
-  Full mTLS implementation is Phase 7 (TICKET-054). This ticket is the
-  interim decision: either implement EXTERNAL against a pluggable
-  cert-subject provider, OR stop advertising it until 054 lands.
-- **Acceptance Criteria:**
-  - Decision documented in the ticket PR: implement OR stop-advertising.
-  - If stop-advertising (recommended interim):
-    - `SUPPORTED_MECHS` becomes `'PLAIN'`.
-    - The `sasl` cap value is updated wherever advertised.
-    - `AUTHENTICATE EXTERNAL` now returns `908 ERR_SASLMECHS`
-      (supported-mechs list) instead of `904`.
-    - A code comment cross-references TICKET-054 so the mech is
-      re-enabled when mTLS lands.
-  - If implementing (only if a pluggable `MtlsIdentityProvider` is
-    feasible without Phase 7 infra):
-    - `AccountStore.verify('EXTERNAL', certSubject)` resolves the cert
-      subject to an account.
-    - `AUTHENTICATE EXTERNAL` with a valid subject succeeds (`903`);
-      invalid → `904`.
-  - 100% coverage on the chosen path.
-- **TDD Outline:**
-  1. Red (stop-advertising) — test asserting `CAP LS sasl` value is
-     `PLAIN`; currently fails (advertises `PLAIN,EXTERNAL`).
-  2. Green — change `SUPPORTED_MECHS`.
-  3. Red — `AUTHENTICATE EXTERNAL` returns `908` (not `904`).
-  4. Green — update the mech-not-supported branch.
-  5. Refactor — drive `SUPPORTED_MECHS` from config so operators can
-     enable EXTERNAL without code changes once 054 lands.
-
----
-
-### TICKET-080 — Welcome MOTD: drive from `MotdProvider` instead of hardcoded placeholder
-- **Phase:** 8 (remediates Phase 5)
-- **Points:** 2
-- **Status:** ⬜
-- **Dependencies:** TICKET-004 (registration reducer, ✅),
-  TICKET-010 (MOTD reducer, ✅)
-- **Description:** PLAN-FIXES #11.
-  `packages/irc-core/src/commands/registration.ts:84-87` always emits:
-
-  ```
-  375 <nick> :- <server> Message of the day -
-  372 <nick> :- MOTD placeholder
-  376 <nick> :End of MOTD command
-  ```
-
-  regardless of the configured `MotdProvider`. The comment claims
-  "filled via `MotdProvider` elsewhere" but it is not. The standalone
-  `MOTD` command correctly uses `ctx.motd.lines()`
-  (`packages/irc-core/src/commands/motd.ts:59`).
-
-  **Impact:** every client sees `372 <nick> :- MOTD placeholder` on
-  connect regardless of configuration.
-- **Acceptance Criteria:**
-  - `buildWelcomeLines` calls `ctx.motd.lines()` and emits the real
-    `375`/`372`×N/`376` sequence (mirroring `motd.ts:59`).
-  - Empty MOTD → `422 ERR_NOMOTD` instead of the placeholder (matches
-    standalone MOTD behaviour).
-  - Long lines split per the byte limit (same helper as `motd.ts`).
-  - The standalone `MOTD` command behaviour is unchanged.
-  - 100% coverage on the new path.
-- **TDD Outline:**
-  1. Red — registration test: with a `MotdProvider` returning
-     `['line A','line B']`, the welcome sequence contains two `372`
-     lines; currently fails (always `MOTD placeholder`).
-  2. Green — call `ctx.motd.lines()` in `buildWelcomeLines`.
-  3. Red — empty MOTD → `422`.
-  4. Green — handle the empty case.
-  5. Refactor — extract the MOTD-lines→numerics helper shared between
-     `registration.ts` and `motd.ts`.
-
----
-
-### TICKET-081 — Registration placeholders: drive `SERVER_VERSION` and `CREATED_TEXT` from `ServerConfig`
-- **Phase:** 8 (remediates Phase 5)
-- **Points:** 3
-- **Status:** ⬜
-- **Dependencies:** TICKET-004 (registration, ✅),
-  TICKET-047 (config, ✅)
-- **Description:** PLAN-FIXES #12.
-  `packages/irc-core/src/commands/registration.ts:29, 32`:
-
-  - `SERVER_VERSION = '0.1.0'` — *"Placeholder until a config-driven
-    version lands."*
-  - `CREATED_TEXT = 'Phase 1'` — *"Placeholder."*
-
-  Surfaced verbatim in `002`/`003`/`004` replies.
-- **Acceptance Criteria:**
-  - `ServerConfig` gains optional `serverVersion?: string` and
-    `createdAt?: string | number` fields.
-  - When `serverVersion` is omitted, the build process injects the
-    `package.json` version at build time — or the field is required at
-    adapter config-load time (recommended fail-fast to match
-    TICKET-082).
-  - When `createdAt` is omitted, a sensible default is used (build
-    timestamp or deploy-time).
-  - The `002`/`003`/`004` replies reflect the configured/injected
-    values, not the literals `'0.1.0'` / `'Phase 1'`.
-  - The placeholder constants are removed from `registration.ts`.
-  - Zod schema updated; both adapters' config loaders pass the new
-    fields.
-  - 100% coverage on the new plumbing.
-- **TDD Outline:**
-  1. Red — registration test: with `serverVersion: '9.9.9'`, the `002`
-     line contains `9.9.9`; currently fails (always `0.1.0`).
-  2. Green — thread the config field into `buildWelcomeLines`.
-  3. Red — `createdAt` flows into `003`.
-  4. Green — implement.
-  5. Red — schema rejects malformed `serverVersion`.
-  6. Refactor — share config-driven-version resolution across adapters.
-
----
-
-### TICKET-082 — Require `serverName` at adapter config-load (drop `irc.example.com` placeholder)
-- **Phase:** 8 (remediates Phase 5)
-- **Points:** 3
-- **Status:** ⬜
-- **Dependencies:** TICKET-047 (config, ✅)
-- **Description:** PLAN-FIXES #13.
-  `packages/irc-core/src/config.ts:244-247` — `serverName:
-  'irc.example.com'` as the baseline. Documented as a boot/test
-  baseline that adapters overlay, and `docs/AWS-Deployment.md:414` warns
-  *"(placeholder -- override!)"*.
-
-  **Impact:** if a deployment forgets to override, the server advertises
-  `irc.example.com`.
-- **Acceptance Criteria:**
-  - `DEFAULT_SERVER_CONFIG.serverName` is removed (or set to a sentinel
-    that triggers fail-fast).
-  - Each adapter's config loader (CF / AWS / local-cli) requires
-    `serverName` at boot; missing → fail with a readable error pointing
-    at the config knob.
-  - Tests can still construct a `ServerConfig` without `serverName` by
-    passing an explicit test-only value (test helpers updated).
-  - `docs/AWS-Deployment.md` and `docs/deployment-cf.md` updated:
-    `serverName` is required, no longer "placeholder -- override!".
-  - 100% coverage on the fail-fast path per adapter.
-- **TDD Outline:**
-  1. Red — adapter loader test: missing `serverName` throws with a
-     readable message; currently fails (defaults to `irc.example.com`).
-  2. Green — remove the default; add the validation.
-  3. Red — test-only configs that omit `serverName` still work via a
-     test helper.
-  4. Green — provide the helper.
-  5. Refactor — share the validation across the three loaders.
-
----
-
-### TICKET-083 — AWS `handleConnect`: implement max-clients admission gating
-- **Phase:** 8 (remediates Phase 4)
-- **Points:** 5
-- **Status:** ⬜
-- **Dependencies:** TICKET-040 (AwsRuntime, ✅),
-  TICKET-046 (security, ✅)
-- **Description:** PLAN-FIXES #14.
-  `packages/aws-adapter/src/handlers/connect.ts:36` —
-  `void params.serverConfig;` (*"reserved for max-clients gating"*).
-
-  **Impact:** connection-count admission gating at connect time is
-  unimplemented.
-- **Acceptance Criteria:**
-  - `handleConnect` reads `serverConfig.maxClients` (and optionally
-    per-IP limits) and rejects new connections over the cap with an
-    APIGW `403 Forbidden` (or `429`) before the connection is recorded
-    in DynamoDB.
-  - The cap is enforced atomically against the `Connections` table
-    (e.g. a count query or a lever on table capacity).
-  - Per-IP limit (optional) keys on the source IP from the APIGW event.
-  - Documented default cap (e.g. 10000) and override knob in config.
-  - Integration test: `cap=2`, three connects → third rejected; the two
-    accepted connections function normally.
-  - 100% coverage on the admission path.
-- **TDD Outline:**
-  1. Red — integration test: cap exceeded → third connect rejected;
-     currently fails (all accepted).
-  2. Green — read `maxClients`, count `Connections`, reject over cap.
-  3. Red — per-IP limit enforced.
-  4. Green — implement the per-IP counter.
-  5. Refactor — extract the admission decision into a pure helper.
-
----
-
-### TICKET-084 — AWS Lambda transport `disconnect` no-op: document the platform limit
-- **Phase:** 8 (remediates Phase 4)
-- **Points:** 1
-- **Status:** ⬜
-- **Dependencies:** TICKET-040 (AwsRuntime, ✅)
-- **Description:** PLAN-FIXES #15.
-  `packages/aws-adapter/src/handlers/default.ts:86-89` —
-  `AwsRuntimeHandlers.disconnect` does nothing. Documented as a
-  platform limit (a Lambda cannot close its own APIGW socket; the
-  canonical close is the `$disconnect` route).
-
-  **Impact:** effect-driven `Disconnect` on the bound connection never
-  reaches the transport from within a `$default` invocation. No code
-  fix is possible without an APIGW feature; this ticket is
-  documentation only.
-- **Acceptance Criteria:**
-  - `docs/AWS-Deployment.md` gains a "Limitations" section explaining
-    that a Lambda `$default` invocation cannot close its own APIGW
-    socket; the canonical teardown is the `$disconnect` route (or a
-    callback to a sidecar sweeper).
-  - The stale comment at `handlers/default.ts:86-89` is updated to
-    cross-reference the doc section.
-  - Optional: explore an APIGW callback / EventBridge path to
-    force-close from within `$default`; documented as a future
-    enhancement or ADR if promising.
-- **TDD Outline:**
-  - N/A (documentation). Reviewed by reading the doc section and
-    confirming it explains the limit clearly to an operator.
-
----
-
-### TICKET-085 — CF `webSocketMessage` channel-registration: wire ChannelDO registration OR remove the dead loop
-- **Phase:** 8 (remediates Phase 3)
-- **Points:** 2
-- **Status:** ⬜
-- **Dependencies:** TICKET-035 (ChannelDO, ✅)
-- **Description:** PLAN-FIXES #16.
-  `packages/cf-adapter/src/connection-do.ts:150-156` — the loop body is
-  `void chan;`.
-
-  **Impact:** no real channel-registration work happens on join beyond
-  the `ApplyChannelDelta` already emitted by the reducer.
-- **Acceptance Criteria:**
-  - Decision documented: wire real channel-DO registration here, OR
-    remove the dead loop.
-  - If wiring: the loop registers the ConnectionDO with each ChannelDO
-    it joins (so the ChannelDO can fan out broadcasts to it). Verify
-    this isn't already handled by `applyChannelDelta` (if it is, remove
-    the loop and add a comment explaining the redundancy).
-  - If removing: the dead loop and its `void chan;` body are deleted; a
-    comment explains that channel membership is driven solely by
-    `ApplyChannelDelta`.
-  - 100% coverage on whichever path ships.
-- **TDD Outline:**
-  1. Spike — confirm whether `ApplyChannelDelta` already covers
-     channel-DO registration (read the ChannelDO reducer).
-  2. Red (if removing) — test asserting the loop body is gone
-     (compile-time / lint check).
-  3. Green — delete the dead code.
-  4. Red (if wiring) — integration test: joining a channel makes the
-     ConnectionDO discoverable to ChannelDO broadcast.
-  5. Green — wire the registration.
-
----
-
-### TICKET-086 — Remove (or wire) dead lookup Effects: `LookupNick`, `GetConnectionInfo`, `GetChannelSnapshot`
-- **Phase:** 8 (remediates Phase 6)
-- **Points:** 2
-- **Status:** ⬜
-- **Dependencies:** TICKET-001 (Effect taxonomy, ✅)
-- **Description:** PLAN-FIXES #17. `LookupNick`, `GetConnectionInfo`,
-  `GetChannelSnapshot` are defined in
-  `packages/irc-core/src/effects.ts:74-87` and `:170-178` (and included
-  in the `Effect` union at `:112-114`), but their dispatch results are
-  discarded via `noop`
-  (`packages/irc-server/src/dispatch.ts:36-38`) and no reducer ever
-  emits them. The runtime methods they wrap
-  (`lookupNick`/`getConnectionInfo`/`getChannelSnapshot`) are used
-  elsewhere, so only the Effect path is dead.
-- **Acceptance Criteria:**
-  - Decision documented: wire these effects to real consumers, OR
-    remove the variants and their dispatch arms.
-  - If removing: delete the three Effect variants from `effects.ts`,
-    remove their cases from `dispatch.ts`, and remove from the `Effect`
-    union. Confirm no reducer/test references them.
-  - If wiring: identify a reducer that should emit them (e.g. PRIVMSG
-    to a user emitting `LookupNick` instead of calling
-    `runtime.lookupNick` directly); implement the dispatch resolution;
-    add a test asserting the effect round-trips through dispatch.
-  - 100% coverage on whichever path ships; existing dispatch tests
-    updated.
-- **TDD Outline:**
-  1. Spike — grep for any emit site of the three effects (expected:
-     none).
-  2. Red (if removing) — compile error after deletion is the "test";
-     existing dispatch tests adjusted.
-  3. Green — delete the dead variants.
-  4. Red (if wiring) — a reducer emits `LookupNick` and dispatch
-     resolves it.
-  5. Green — wire the consumer.
-  6. Refactor — consolidate the dispatch table.
-
----
-
-### TICKET-087 — CF outbound batching: implement OR drop the reserved optimization
-- **Phase:** 8 (remediates Phase 6)
-- **Points:** 2
-- **Status:** ⬜
-- **Dependencies:** TICKET-033 (ConnectionDO, ✅)
-- **Description:** PLAN-FIXES #18.
-  `packages/cf-adapter/src/connection-do.ts:100-101` — a field for
-  batching outbound line drains is commented out, explicitly deferred.
-- **Acceptance Criteria:**
-  - Decision documented: implement the batching optimization, OR drop
-    the reserved comment.
-  - If implementing: a buffered outbound drain that coalesces multiple
-    lines into a single `WebSocket.send()` per microtask (or per alarm
-    tick); benchmark showing reduced WS round-trips under burst load;
-    correctness test that line ordering is preserved.
-  - If dropping: the commented-out field is removed; a brief note in a
-    perf-relevant ADR or doc explains why batching was deferred (e.g.
-    *"out of scope for v1; revisit if WS round-trips become a
-    bottleneck — see load-test report TICKET-049"*).
-  - 100% coverage on whichever path ships.
-- **TDD Outline:**
-  1. Spike — measure current WS round-trips per PRIVMSG burst (informs
-     implement-vs-drop).
-  2. Red (if implementing) — test: N broadcasts in one tick result in 1
-     `WebSocket.send` call (currently N).
-  3. Green — implement the buffered drain.
-  4. Red (if dropping) — the field is gone (compile-time check).
-  5. Green — delete.
-  6. Refactor — share the buffering logic with the AWS adapter if both
-     end up batching.
-
----
-
-### TICKET-088 — Update stale doc-comments advertising DOs as stubbed
-- **Phase:** 8 (remediates Phase 6)
-- **Points:** 2
-- **Status:** ⬜
-- **Dependencies:** TICKET-035 (ChannelDO, ✅),
-  TICKET-034 (RegistryDO, ✅)
-- **Description:** PLAN-FIXES #19.
-  `packages/cf-adapter/src/env.ts:23-36` — still describes `REGISTRY_DO`
-  as *"Stubbed now (033); real impl in 034"* and `CHANNEL_DO` as
-  *"Stubbed now; real in 035"*, even though `registry-do.ts` and
-  `channel-do.ts` now contain real implementations.
-
-  `packages/cf-adapter/src/connection-do.ts:148-153, 291-293, 337-338,
-  504-506, 549` contain similar stale "stub" language; `:546-549`
-  exports `applyChannelDelta` purely to keep an import used by tests.
-- **Acceptance Criteria:**
-  - All stale "stub" / "real in 0XX" comments in `env.ts` and
-    `connection-do.ts` updated to reflect the implemented state.
-  - The test-only re-export of `applyChannelDelta`
-    (`connection-do.ts:546-549`) is either moved behind a test boundary
-    (e.g. a `__test__` export or a separate `internal.ts` consumed only
-    by tests) or removed if tests can import directly.
-  - No functional change; full test suite stays green.
-- **TDD Outline:**
-  1. Red — lint/test asserting no occurrences of "Stubbed now" or
-     "real in 0" in `packages/cf-adapter/src/*.ts` (custom grep test or
-     ESLint rule).
-  2. Green — rewrite the comments.
-  3. Red — test asserting `applyChannelDelta` is not part of the public
-     `connection-do.ts` surface.
-  4. Green — move the export behind a test boundary.
-  5. Refactor — centralize DO-status documentation in a single ADR or
-     doc section.
-
----
-
-### TICKET-089 — Implement rfc1459 case-mapping (replace ad-hoc `toLowerCase`)
-- **Phase:** 8 (remediates Phase 6)
-- **Points:** 5
-- **Status:** ⬜
-- **Dependencies:** TICKET-011 (MODE reducer, ✅)
-- **Description:** PLAN-FIXES #20. `packages/irc-core/src/isupport.ts:43`
-  advertises `CASEMAPPING=rfc1459`, but
-  `packages/irc-core/src/commands/kick.ts:57-60` (and the duplicated
-  `lowerNick`/`lower` helpers in `mode.ts`, `invite.ts`, `join.ts`,
-  `packages/in-memory-runtime/src/in-memory-runtime.ts`) use bare ASCII
-  `toLowerCase()`. The advertised case-mapping and the actual folding
-  diverge for the `[]\^` special chars.
-- **Acceptance Criteria:**
-  - A single shared `caseFold(mapping, s)` helper in `irc-core`
-    (supports at least `rfc1459`; `ascii` as a subset).
-  - All nick/channel-name lowering call sites (`kick.ts`, `mode.ts`,
-    `invite.ts`, `join.ts`, `in-memory-runtime.ts`, and any other
-    `lower*`/`toLowerCase` sites used for IRC-name comparison) use the
-    shared helper.
-  - `[]\^` and `{}|~` fold correctly per rfc1459 (`[` ↔ `{`, etc.).
-  - The `CASEMAPPING=` token in isupport now matches actual behaviour.
-  - 100% coverage on the helper; property-test round-trip
-    (`fold(fold(s)) === fold(s)`).
-  - Existing reducer tests pass unchanged (their inputs happen to be
-    ASCII-safe; new tests cover the special chars).
-- **TDD Outline:**
-  1. Red — unit test: `caseFold('rfc1459', '[Foo]')` equals `'{foo}'`;
-     currently fails (no helper, or `toLowerCase` yields `[foo]`).
-  2. Green — implement the helper.
-  3. Red — channel comparison test: `JOIN #foo` then `JOIN #FOO` are
-     the same channel under rfc1459 (currently they may diverge for
-     `[`-containing names).
-  4. Green — replace ad-hoc `toLowerCase` call sites with the helper.
-  5. Red — property test: `fold(fold(s)) === fold(s)` for generated
-     inputs.
-  6. Refactor — delete the duplicated `lowerNick`/`lower` helpers.
-
----
-
-### TICKET-090 — Remove unused `_disabledRecordId()` helper
-- **Phase:** 8 (remediates Phase 6)
-- **Points:** 1
-- **Status:** ⬜
-- **Dependencies:** TICKET-029 (in-memory-runtime, ✅)
-- **Description:** PLAN-FIXES #21.
-  `packages/in-memory-runtime/src/in-memory-runtime.ts:61-69` — mints
-  admission record ids whose own doc comment states *"The id is never
-  consulted (no `AdmissionStats` exists)."* Called at `:116` when
-  admission is disabled; the returned `recordId` flows nowhere.
-- **Acceptance Criteria:**
-  - `_disabledRecordId()` helper deleted; its call site at `:116`
-    removed.
-  - If an `AdmissionStats` consumer is desired, file a separate
-    follow-up; otherwise the helper and the admission-record concept are
-    gone from the codebase.
-  - Full test suite stays green (the helper was never asserted).
-  - 100% coverage on the cleaned-up admission path.
-- **TDD Outline:**
-  1. Red — grep/compile test asserting no references to
-     `_disabledRecordId`.
-  2. Green — delete the helper and its call site.
-  3. Refactor — simplify the disabled-admission branch.
-
----
-
-### TICKET-091 — Update stale CLI doc comment ("fuller config-loader lands in a later ticket")
-- **Phase:** 8 (remediates Phase 6)
-- **Points:** 1
-- **Status:** ⬜
-- **Dependencies:** TICKET-031 (local-cli, ✅)
-- **Description:** PLAN-FIXES #22. `apps/local-cli/src/main.ts:17` —
-  *"a fuller config-loader lands in a later ticket."*
-  `apps/local-cli/src/config-loader.ts` already exists and fully
-  validates via `ServerConfigSchema`.
-- **Acceptance Criteria:**
-  - The stale comment at `main.ts:17` is removed or rewritten to
-    reflect that config loading is fully implemented via
-    `apps/local-cli/src/config-loader.ts`.
-  - No functional change.
-- **TDD Outline:**
-  - N/A (comment-only). Verified by reading the updated comment and
-    confirming `config-loader.ts` is exercised by the CLI's tests.
-
----
-
-### TICKET-092 — Update stale release-process doc (90% coverage gate IS wired in CI)
-- **Phase:** 8 (remediates Phase 6)
-- **Points:** 1
-- **Status:** ⬜
-- **Dependencies:** TICKET-048 (CI coverage gate, ✅)
-- **Description:** PLAN-FIXES #23. `docs/Release-Process.md:114` —
-  *"the 90% coverage gate (TICKET-048) is not yet wired in CI."*
-  `.github/workflows/ci.yml:57-60` shows the gate **is** wired and
-  enforced per package (100% on `irc-core`/`irc-server`/
-  `in-memory-runtime`, >=90% elsewhere).
-- **Acceptance Criteria:**
-  - `docs/Release-Process.md` updated: the coverage gate is enforced in
-    CI per package; the exact thresholds (100% / ≥90%) are stated.
-  - Cross-reference to `.github/workflows/ci.yml` and to TICKET-048.
-  - No functional change.
-- **TDD Outline:**
-  - N/A (documentation). Verified by reading the updated doc and
-    confirming the CI workflow matches the stated thresholds.
-
----
-
-*Next ticket number: **TICKET-093**.*