Ben Stull
7c6c906db2
Adds an optional "What will you be using this for?" capture as a sibling to the required justification on both propose surfaces, per roadmap #26. - propose-RFC modal (ProposeModal): optional textarea below the required "Why is this RFC needed?" pitch, labeled "What will you be using this RFC for? (optional)". - propose-PR modal (PRModal): optional textarea below the required description, labeled "What will you be using this change for?". - Backend: ProposeBody / OpenPRBody gain an optional `proposed_use_case` (NULL/omitted accepted, no min, 8000-char cap matching the existing free-text bound). Persisted to a new canonical side table `proposed_use_cases` keyed by PR number, mirrored onto the cache columns added by migration 021. Returned on the proposal list/detail, RFC detail (by slug), and PR detail endpoints. - Display: ProposalView, RFCView (main only), and PRView render the captured use case with a muted "left blank" treatment when NULL. - migration 021: nullable `proposed_use_case` on cached_rfcs/cached_prs plus the reconcile-proof `proposed_use_cases` truth table. - New vertical test_proposed_use_case_vertical: persists+returns when supplied, accepted as NULL/omitted, for both surfaces. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
48 lines
2.5 KiB
SQL
48 lines
2.5 KiB
SQL
-- Roadmap #26 (rfc-app v0.22.0): the optional "What will you be using
|
|
-- this for?" capture on the two propose surfaces.
|
|
--
|
|
-- The roadmap's framing names "the rfcs table" and "the PR-metadata
|
|
-- table" for a `proposed_use_case TEXT NULL` column. In this deployment
|
|
-- those two surfaces are the cache tables `cached_rfcs` and `cached_prs`
|
|
-- (002_cache.sql). We add the nullable column to each, matching the
|
|
-- existing naming convention (no NOT NULL, no default — NULL is the
|
|
-- "left blank" sentinel the view surfaces render tastefully).
|
|
--
|
|
-- BUT: those tables are *cache*, rebuilt from Gitea by the §4.1
|
|
-- reconciler (cache.py). The reconciler's INSERT...ON CONFLICT DO UPDATE
|
|
-- sets only the columns it knows about, so an unlisted column is
|
|
-- preserved on the update path — yet a propose/open never *writes* the
|
|
-- column through the cache (the write path is endpoint -> Gitea ->
|
|
-- reconcile, and the reconciler does not carry this field). So the cache
|
|
-- column alone would always read NULL.
|
|
--
|
|
-- The durable home is therefore a dedicated app-truth table the propose
|
|
-- /open endpoints write directly (keyed by the PR number, which is the
|
|
-- stable identity for both idea PRs and rfc_branch PRs) and the view
|
|
-- endpoints read back. This is not cache — it is canonical and survives
|
|
-- any reconcile. The cache columns are added too for parity with the
|
|
-- roadmap's literal shape and for any future reconciler that learns to
|
|
-- carry the field, but the side table is the source of truth read at
|
|
-- view time.
|
|
|
|
ALTER TABLE cached_rfcs ADD COLUMN proposed_use_case TEXT;
|
|
ALTER TABLE cached_prs ADD COLUMN proposed_use_case TEXT;
|
|
|
|
-- Canonical, reconcile-proof store. One row per propose/open that
|
|
-- supplied a use case. `scope` distinguishes the propose-RFC surface
|
|
-- ('rfc') from the propose-PR-against-an-RFC surface ('pr'); `pr_number`
|
|
-- is the join key the endpoints already have in hand. NULL/omitted use
|
|
-- cases simply never write a row here, so absence == "left blank".
|
|
CREATE TABLE proposed_use_cases (
|
|
id INTEGER PRIMARY KEY AUTOINCREMENT,
|
|
scope TEXT NOT NULL CHECK (scope IN ('rfc', 'pr')),
|
|
rfc_slug TEXT NOT NULL,
|
|
pr_number INTEGER NOT NULL,
|
|
use_case TEXT NOT NULL,
|
|
created_at TEXT NOT NULL DEFAULT (datetime('now')),
|
|
UNIQUE (scope, pr_number)
|
|
);
|
|
|
|
CREATE INDEX idx_proposed_use_cases_lookup ON proposed_use_cases (scope, pr_number);
|
|
CREATE INDEX idx_proposed_use_cases_slug ON proposed_use_cases (scope, rfc_slug);
|