Release v0.22.0: optional propose use-case field (#26)

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

CHANGELOG.md

@@ -23,6 +23,55 @@ 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.22.0 — 2026-05-28
+
+Roadmap item #26: an optional **"What will you be using this for?"**
+field on both propose surfaces. Shipped from driver session 0022.0.
+Additive and backward-compatible — no behavior changes for anyone who
+leaves the field blank.
+
+1. **Propose-RFC modal.** Below the required "Why is this RFC needed?"
+   field (`pitch`) sits a new optional **"What will you be using this
+   RFC for?"** textarea. "Needed" is the abstract justification; "using
+   it for" is the concrete ground-truth use case — captured without
+   being forced.
+2. **Propose-PR modal.** Below the required "Why is this change needed?"
+   field (`description`) sits a new optional **"What will you be using
+   this change for?"** textarea.
+3. **Display.** The RFC view (`RFCView` / `ProposalView`) and PR review
+   view (`PRView`) render the captured use case alongside the existing
+   "why" text, with a muted "left blank" treatment when absent.
+4. **Persistence (deployment note).** In this deployment the framework's
+   `rfcs` / PR surfaces are the Gitea-backed cache tables `cached_rfcs`
+   / `cached_prs`, rebuilt by the reconciler. Because the propose write
+   path is endpoint → Gitea → reconcile (and the reconciler doesn't
+   carry the new field), the durable home is a canonical, reconcile-proof
+   side table `proposed_use_cases` (keyed by `(scope, pr_number)`) that
+   the propose/open endpoints write directly and the view endpoints read
+   back. The literal nullable `proposed_use_case` columns named by the
+   roadmap are also added to `cached_rfcs` / `cached_prs` for parity and
+   any future reconciler that learns to carry the field. NULL/blank use
+   cases simply never write a side-table row — absence is "left blank".
+
+Migration `021_proposed_use_case.sql` adds the two cache columns
+(`ALTER TABLE … ADD COLUMN proposed_use_case TEXT`), the
+`proposed_use_cases` canonical table, and its lookup indexes. The
+reconciler's upsert (`ON CONFLICT DO UPDATE`) sets only known columns,
+so the added cache columns survive reconciles. Backend validators accept
+the field as NULL/omitted (no required-validation) with an 8000-char cap
+matching the existing PR `description` bound; blank/whitespace is treated
+as absent.
+
+Upgrade steps:
+
+1. Deployments **MUST** apply database migrations; `021_proposed_use_case.sql`
+   runs automatically on next boot (the migration runner globs
+   `backend/migrations/*.sql` and applies any not yet recorded in
+   `schema_migrations`). The migration is additive — nullable cache
+   columns plus a new table — and requires no data backfill.
+2. No new environment variables, overlay keys, or secrets. No operator
+   action beyond the standard `flotilla deploy ohm-rfc-app`.
+
 ## 0.21.0 — 2026-05-28
 
 UX-polish wave. Roadmap items #31 (comprehensive UX polish — foundation

VERSION

@@ -1 +1 @@
-0.21.0
+0.22.0

frontend/package.json

@@ -1,7 +1,7 @@
 {
   "name": "rfc-app-frontend",
   "private": true,
-  "version": "0.21.0",
+  "version": "0.22.0",
   "type": "module",
   "scripts": {
     "dev": "vite",