serverless-ircd 0.1.0 → 0.2.0

package/tickets.md

@@ -0,0 +1,2485 @@
+# 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**.*