Release 0.5.0: PR-less per-RFC discussion (contribution still requires PR)

Roadmap item #3. An RFC's main view now carries a discussion surface
distinct from PR comments and from branch chat. The substrate is the
existing threads/thread_messages tables — rows with branch_name IS NULL
scope to the RFC's main view; the schema already permitted that shape,
v0.5.0 is the first build to write it. Five new endpoints under
/api/rfcs/<slug>/discussion/..., a new RFCDiscussionPanel right-column
component used when branchParam === main, SPEC §10.10 settling
discussion-vs-contribution, and §17 listing the new routes. Notification
routing reuses the existing chat_message_in_participated_thread /
chat_reply_to_my_message event kinds with branch_name=null on the
fan-out row; a distinct event_kind is a §19.2 candidate. Anonymous
viewers can read; writes require contributor — v0.6.0's item #4 will
harden adjacent gates. No schema migration; minor bump, no operator
action required beyond rebuild and restart.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

CHANGELOG.md

@@ -23,6 +23,103 @@ skip versions are the composition of each intervening adjacent
 release's steps in order — no A-to-B path is pre-computed beyond
 that.
 
+## 0.5.0 — 2026-05-27
+
+**Minor — no operator action required.** This release wires the
+PR-less per-RFC discussion surface (roadmap item #3, SPEC §10.10).
+An RFC's main view now carries a discussion panel distinct from PR
+comments and branch chat; contribution — proposing edits the document
+will land — still requires opening a PR via the §10.1 affordance.
+The substrate is the existing `threads` / `thread_messages` tables;
+rows with `threads.branch_name IS NULL` scope to the RFC's main view.
+No schema migration is required.
+
+### Added
+
+- **PR-less discussion endpoints** (`backend/app/api_discussion.py`)
+  mounted at `/api/rfcs/<slug>/discussion/...`:
+  - `GET  /api/rfcs/<slug>/discussion/threads` — list threads where
+    `threads.branch_name IS NULL`. Anonymous-readable per the v0.3.0
+    contract; the default whole-doc chat thread is materialized
+    lazily on first read.
+  - `POST /api/rfcs/<slug>/discussion/threads` — open a new
+    discussion thread (`thread_kind='chat'`, `anchor_kind='whole-doc'`,
+    `branch_name=NULL`). Body: optional `label`, optional first
+    `message`. Requires contributor role.
+  - `GET  /api/rfcs/<slug>/discussion/threads/<thread_id>/messages`
+    — read messages on a discussion thread. Anonymous-readable.
+  - `POST /api/rfcs/<slug>/discussion/threads/<thread_id>/messages`
+    — post a message. Body: `text`, optional `quote`. Requires
+    contributor role.
+  - `POST /api/rfcs/<slug>/discussion/threads/<thread_id>/resolve`
+    — resolve a discussion thread. Permission per §10.10: thread
+    creator, RFC owner / arbiter, or app admin / owner.
+- **`RFCDiscussionPanel.jsx`** — the right-column surface on the RFC
+  view when the viewer is on `main`. Composer requires sign-in;
+  Cmd/Ctrl+Enter sends. Multiple threads surface as pill-shaped
+  tabs above the message feed. A "New thread" affordance opens a
+  fresh thread on the same RFC.
+- **SPEC `§10.10` PR-less discussion vs. contribution** — settles
+  the distinction between discussion (RFC-scoped, no PR, both
+  anonymous-readable and contributor-writeable) and contribution
+  (still requires a PR via §10.1). Also extends `§5`'s `threads`
+  table commentary so the null-branch interpretation is documented
+  as actively used rather than reserved scaffold.
+- **SPEC `§17`** — lists the five new `discussion/...` endpoints
+  in the illustrative table.
+
+### Changed
+
+- **`backend/app/chat.py`** — `_fan_out_chat` now passes
+  `branch_name` straight through to the notify chokepoint instead of
+  coercing `None` to `"main"`. The notifications row carries the
+  null through, which preserves the §15.7 reconciler's keying on
+  `(rfc_slug, branch_name)` for the eventual discussion-side
+  chat-seen advance (deferred to a §19.2 candidate). Existing
+  branch-scoped chat continues to pass non-null branch names; the
+  change is invisible to that path.
+- **`backend/app/notify.py`** — `fan_out_chat_message`'s
+  `branch_name` parameter is now typed `str | None` to match the
+  v0.5.0 PR-less shape. Routing rules are unchanged; the inbox prose
+  renders identically whether the chat lives on a branch or on the
+  RFC's discussion surface, which is the right honest signal.
+- **`RFCView.jsx`** — the right-column panel is now conditional:
+  when `branchParam === 'main'`, render `RFCDiscussionPanel`
+  (the new PR-less surface); otherwise render the existing
+  `ChatPanel` (branch chat unchanged).
+
+### §19.2 candidates surfaced
+
+- PR-less discussion: range / paragraph anchors (the data model
+  permits them; the UI is the deferred part).
+- PR-less discussion: distinct notification `event_kind`s
+  (`open_rfc_discussion_thread`, etc.) if usage shows contributors
+  want to filter discussion-vs-branch in the §15.2 inbox.
+- PR-less discussion: chat-seen cursor closing the §15.7
+  reconciliation loop for the new surface.
+- PR-less discussion: AI participant invocation (discussion-only,
+  no `<change>` block side-effects).
+- PR-less discussion: anonymous-read polish to match the v0.6.0
+  write-gate hardening (item #4).
+
+### Upgrade steps (from 0.4.0)
+
+1. The deployment **MUST** rebuild the frontend (`npm install &&
+   npm run build`) so `RFCDiscussionPanel.jsx` ships in the bundle.
+   No new env vars; existing `frontend/.env` is sufficient.
+2. The deployment **MUST** restart the backend so the new
+   `api_discussion` router mounts. No schema migration runs — the
+   `threads` table already supports `branch_name IS NULL` per §5,
+   and the v0.5.0 build is the first to write rows in that shape.
+3. The deployment **MAY** announce the new surface to its
+   contributors: the RFC view's main page now carries a discussion
+   panel below the document. Existing branch chat and PR review
+   surfaces are unchanged.
+4. The deployment **SHOULD NOT** expect a hardening of the
+   anonymous-write gate in v0.5.0 — that lands in v0.6.0 (item #4).
+   v0.5.0's write paths already refuse anonymous posts, so no
+   pre-emptive operator action is needed.
+
 ## 0.4.0 — 2026-05-27
 
 **Minor — no operator action required beyond rebuild + restart.** The