Task: Manage the sensitivity templates

The screen searches and orders on the server, as the standard requires, and the generated contract carried neither. The model now declares code and description searchable, and code, asset_class, method and description sortable, so the store searches the two fields a person searches by and refuses no column the list offers. The generated filter gains search, so the contract is extended rather than the screen reading every row.

sensitivity-templates.ts registers six routes under /api/analytics/sensitivity-templates: the page, one key, the two writes, the removal, and the history, plus the choices the dialog draws. Each route names a generated subject, so the wire shape is the protocol's and not the module's.

• The page reads one page through analytics.v1.sensitivity_templates.list and answers the store's total, so the pager counts every key.
• A create claims must_not_exist and a correction claims must_match_version, so a key written meanwhile is refused rather than replaced. The service states the refusal's code, and the module answers 409 for a code the tenant holds and for a row that moved on, and 404 for a code it does not hold.
• Both writes derive method_code from the method. The table checks the pair, and a person types neither the code nor its token.
• A removal reads the row first and answers what it removed, because the versions stay in the history and the dialog says so.
• The history route reads the key's versions through the shared history read (RS-HIST-01). The generic /api/history route also serves the entity type, because that is the request the standard's timeline reads.

Two pages under web/src/sensitivityTemplates/, one form module, and one module of the reads and the permissions. The list and the record page use the shared parts the classifications screens use: RecordList, RecordHeader, RecordDetails, Dialog, ReasonFields, useCloseGuard, DeleteDialog, RevertVersionDialog and RecordTimeline. The header actions are the standard three: Edit, then Delete, with History as the second tab.

The form is one dialog with no tabs (the form has four fields), the asset class and the method as selects over the choices route, the key as text on create and as words on a correction, and the derived method code as a statement under them. The reason and the commentary come last, and a new key carries system.new_record in a note rather than asking for it.

Sensitivity templates are read by the pricing engine configuration, which is Product pricing in the reporting area, and the shifts they imply are the sensitivity configuration's. The reporting area has no Sensitivity analysis card or configuration yet, so the entry is a card of that area beside Product pricing and Engine run settings, named Sensitivity templates, and the area opens for a person who holds the read of any of its four screens.

• The configuration standard's "What this configuration decides" sentence wants its second half to link to the other configuration. The sensitivity configuration has no screen yet, so the half that names it is words and not a link.
• The record standard's natural order for reference data is the display order then the name. A template has no display order and its display field is its key, so the order is the key's.
• The History tab reads the generic history request, because RS-HIST-01 names it, so the module's own history route answers the same read for a caller that names the record's own address. Both are tested.

The History tab answered nothing at first. A history provider reads with the caller's tenant, and the entities whose rows the system tenant holds, which includes every pricing engine vocabulary table, answered an empty list for a row the caller may read. The provider now scopes to the system tenant for the entities the model declares system_tenant_validation on, and the 29 entities that declare it are regenerated. The pricing engine type, method, model, pair and pair setting histories are fixed by the same change.

The reporting area, as a card named Sensitivity templates, beside Product pricing and Engine run settings. The two configurations beside it are what read these keys: a product carries one with the SensitivityTemplate setting. The area already had no Sensitivity analysis card, so the entry went beside those two, and the area opens for a person who holds the read of any of its four screens.

They are the build tree's, not the source tree's: build/output/ui-tests/01-list.png, 02-list-second-page.png, 03-search.png, 04-add-dialog.png, 05-record.png, 06-edit-dialog.png, 07-history.png, 08-delete-dialog.png, 09-list-after-delete.png and 10-seeded-key-untouched.png.

• The configuration standard's "What this configuration decides" sentence wants its second half to link to the other configuration. The sensitivity configuration has no screen, so the half that names it is words and not a link.
• The record standard's natural order for reference data is the display order then the name. A template has no display order and its display field is its key, so its order is the key's.
• The History tab reads the generic history request, because RS-HIST-01 names it, so the module's own history route answers the same read for a caller that names the record's own address. Both are tested.
• The browser instrument wants a Chromium revision this sandbox cannot install (the home directory is read-only), so a local launch config points at the revision the checkout's cache holds. It is gitignored, and the README's rule about the browsers' location says why.

The first pass stored the class and the method as text and enforced them with checks. A design review settled the model this screen should sit on:

• asset_class_code is a nullable soft FK to ores_refdata_asset_class_codes_tbl, validated by ores_refdata_validate_asset_class_code_fn, the same pattern the market series junction uses. The ORE presentation prefix (COMM for commodity) lives in a bridge entity, sensitivity_asset_class, with the class's words; the five classes ORE presents are seeded, and bond and inflation are not, because ORE's templates have no prefix for them.
• The method is its own entity, sensitivity_method: code, name, description, needs_asset_class and display order. Trade is the one method that names no class.
• SensiTrade is a real ORE product type with no asset class, so ALL is gone: the class is null exactly when the method is Trade. The rule is a table check, because the generator's validations see one column at a time; the method's needs_asset_class is what the screen reads.
• The template key stays free: ORE resolves the key a configuration states.

The catalogue view composes the label from the two lookups: Interest rate · Analytical, and Trade level alone for the classless key. The BFF choices route reads the two list subjects, the writes carry the two codes and refuse a pair the tables would refuse, and the screen draws both as selects; choosing Trade clears and disables the class, and the record states the class's words, the method's words, the method code and the prefix under the sentence that says the shifts are set per market key and may reach keys outside the class.

The seeds are 5 methods, 5 classes and 19 templates, verified on a recreated database, and SensiTrade carries no class.

1. A generated synthetic generator appended -<idx> to a text primary key even when the model opted out with :no_generator_suffix:. The flag was parsed and the element generator honoured it; the scalar generator did not. The template now honours it for a text primary key, and the bridge states a refdata code unsuffixed, cycling the five so many synthetic rows stay distinct. The common case's generated output is unchanged, so no other entity was regenerated.
2. Running the browser case as a person rather than the tenant administrator showed the screen's role could read the keys and nothing else: Operations held the template read, the write and delete were seeded without a grant, and the two lookups were granted to Member alone. The seed now grants the four to Operations, and the browser case signs in as an Operations account.

• ./compass.sh build exit 0.
• ores.analytics.core.tests 78 cases and 512 assertions; BFF 1072 tests; web 2165 tests; the pgTAP suites for the templates and the lookups pass 18 of 18 on a recreated, provisioned database.
• The browser case passes as an Operations account against the running environment: 19 keys paged, search, add, correct, history, delete, seeded key untouched.
• The named local checks pass: cmake-sources, model-drift, sql-hygiene, model-sql-types, handler-permissions, route-auth, bff-list-requests, web, tangle-templates, format, component-drift.