From 7d8371dea1444f6984619f19bfea40c2ce09bd9c Mon Sep 17 00:00:00 2001 From: Ben Stull Date: Thu, 28 May 2026 12:32:34 -0700 Subject: [PATCH] Release v0.22.0: optional propose use-case field (#26) Co-Authored-By: Claude Opus 4.8 (1M context) --- CHANGELOG.md | 49 +++++++++++++++++++++++++++++++++++++++++++ VERSION | 2 +- frontend/package.json | 2 +- 3 files changed, 51 insertions(+), 2 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index 08b54f3..6c221b6 100644 --- a/CHANGELOG.md +++ b/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 diff --git a/VERSION b/VERSION index 8854156..2157409 100644 --- a/VERSION +++ b/VERSION @@ -1 +1 @@ -0.21.0 +0.22.0 diff --git a/frontend/package.json b/frontend/package.json index 32841ba..7617aac 100644 --- a/frontend/package.json +++ b/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",