Task: Build the curve blueprint screens

1. The reads and the BFF exposure. ir_curve_bootstrap_config declares the list contract its screen needs: currency_code and index_tenor are searchable, currency_code and curve_family_role are filterable, discount_curve_config_id is filterable, and five columns are sortable. The pillar's bootstrap_config_id is filterable, so the Pillars tab is one filtered read. Both kinds are in REFDATA_RECORDS with their generated subjects, write schemas and the permissions the handlers check, and the generic record route forwards filters as f.<member>. Two reads join the curve routes: the oresmd URI of a set of series ids, and the build itself (marketdata.v1.ops.compute_curve, which had a handler and no route).
2. The web screens. CurveBlueprintsPage and CurveBlueprintPage on the shared parts, at /market-data/curve-blueprints, with Details, Pillars, Check, Published sets and History. Add, Edit and Copy are the standard record dialog, and the output series is chosen there with the record picker over the series the party holds. The pillar's sequence is completed from its end tenor rather than typed. Two field kinds were added to the shared table instead of built in the screen: a picker over a list the screen supplies (the tenor ladder, a currency's funding blueprints), and the parts panel's .complete, for a part whose parent decides a field.
3. The check flow. The six checks, the forwards and the findings are one pure module (curveBlueprintCheck.ts) with 18 assertions; the points come from the build route; the tab never shows an unrun check as passed and a recipe that fails a check stops before the market is read.
4. The badges. Six domains, 17 badge definitions and 17 mappings in the system seed, and the same rows in the three artefact seeds the catalogue publishes to a tenant from.

The task opened with the rule that the server mints the output series. It does not, and it cannot: a curve's oresmd URI carries the index name (DISCOUNT/RATE/USD/USD-SOFR-FOMC) and the config holds the currency and the index tenor and not the index, so no operation can compose the identity the record is keyed by. On 2026-10-28 the owner decided the other way: the output series is chosen when the blueprint is created, with the standard record picker over the series the party holds. Add and Copy now create the record through the store like every other kind, the journeys and the design note carry the reversal, and the minting rule is struck where it appeared – in journey_maintain-the-curve-blueprints.org, in doc/prototypes/market_data/curve-blueprints.org and in the model's own note. The candidate for later is a series created from the same dialog, which is what the Qt window did inline.

• The curve code is not searchable on the server. The first column and the display handle are the output series' URI, which lives in another component's table; the list contract can search the currency and the index tenor, and that is what the search covers.
• The published sets are filtered on the page. list_published_curves has no bootstrap_config_id filter, so the tab reads the party's sets and picks this blueprint's. The journey records the same gap.
• The check is the screen's. No operation validates a recipe, so a recipe that fails its checks can still be saved, and the result is held by the person who ran it and not against the version.
• A schedule-resolved pillar does not build. The live build refuses a 1F pillar ('1F is not a period, a date, ON, TN, SN or a continuation'), so the Check tab draws the server's words for the seeded FOMC recipe; the FOMC key derivation in compute_curve is a separate gap.
• Retire. The record has no status, so the page draws the state it can infer ("no set in use since …") and offers no action.
• The as-of is a text field. The standard's field table has no instant kind, so the Check tab takes the instant in one line of text, held in the address as ?asof, and says nothing it cannot. Adding the kind is the capture the journey names.