Task: Give the BFF the synthetic routes

The screens can read and write every synthetic entity the four journeys name, through routes the BFF serves.

• Every synthetic entity the four journeys name is readable through the BFF: all rows of a resource, and one row by its key.
• The FX feed, its mixture, the IR curve feed, its parameter values and its ladder rows are writable, and the process types are writable from a system session. A save of one or many rows is one atomic call, and a stale version is refused with 409.
• The parameter definitions, the folders and the collections are read only, and the route says why.
• The previews, the feed start and stop, the folder start and stop, the running set and the vintage validity have routes.
• The history of every synthetic entity is served by the existing history route.
• Unit tests cover each route against canned replies, and each route answers correctly against the running services.

(Implementation strategy. Written when work starts; key decisions are distilled into the parent story's * Decisions at close, but the plan itself stays — it is the historical record of what we did.)

The synthetic CRUD is uniform: nine generated resources, each with list, put_many and delete subjects, one key field and one one-of filter. So the BFF holds one table of synthetic resources and serves generic routes over it, like the refdata record routes, rather than one route set per screen.

• bff/src/synthetic.ts holds SYNTHETIC_RECORDS. A row names the URL key, the entity type, the key field, the one-of filter, the reply field and the subjects. A row with a write schema is writable. A row without one is read only.
• GET /api/synthetic returns the catalogue with the read, write and delete permission of each resource.
• GET /api/synthetic/:resource returns every row. GET /api/synthetic/:resource/key/:key reads one row through the one-of filter, not through get: a definition's get takes parameter_name, which several process types share.
• PUT /api/synthetic/:resource takes one or many changes and sends put_many. The server checks every row's version and writes the set in one statement, so one path serves a single save and a mixture reorder.
• DELETE /api/synthetic/:resource takes one or many removals. One removal sends delete with its version. Many send delete_many, which the server accepts only without versions, so the BFF refuses a versioned batch.
• The definitions are read only. The server reads and writes a definition by parameter_name alone, so a write would reach whichever type's row it found first. The gaps task fixes the key. Folders and collections are read only because no journey step writes them. The process types are one catalogue every tenant shares, so only a system session writes them.
• The write schemas check structure only and satisfy the generated write types. The table checks enforce the domain rules, so the BFF does not copy the enumerations.
• Operation routes: GET /api/synthetic/running, POST /api/synthetic/feeds/:id/start and /stop, POST /api/synthetic/folders/:id/start and /stop, GET /api/synthetic/vintages, POST /api/synthetic/simulate/fx, POST /api/synthetic/simulate/ir and POST /api/synthetic/preview/ir-shape.
• HISTORY_TYPES takes the synthetic entity types, so /api/history serves them through synthetic.v1.history.get.

Out of scope: the refdata pickers the IR screen needs (tenors, payment frequencies, index conventions, instrument codes) and the market series coverage read. They are not synthetic entities, and each screen task adds the picker it needs.

Every number this task claims about a tree, with the command that produced it and the commit it was measured at. A number without both is not a measurement, because a clean-up record describes a tree and trunk moves under a branch: a consumer count, a gate's component count and a suite's size all change with no code changing, and the reader of a bare number cannot tell which tree it came from. Where the raw output matters, put it in an evidence/ file beside the task and name that file in the Command column.

Three things the live stack showed that the canned tests could not.

• The process types were invisible to every tenant. The catalogue lives in the system tenant. The definition handler reads there, because its model sets system_tenant_validation, but the process type model did not, so a tenant listed an empty catalogue and a tenant write would have landed a private row the validators never read. The SQL validator already checks the system tenant, and regenerating the SQL with the flag changes no byte, so the flag was missing only from the model. The flag is now set and the handler regenerated.
• A system-owned write crosses tenants. With the handler in the system tenant, a tenant role that holds the write permission changes every tenant's catalogue. The BFF now writes the process types only from a system session. The server-side exposure, which the definitions already had, is captured as A tenant can write a system catalogue.
• A whole-number double fails to decode. The reflect-cpp msgpack reader refuses an integer for a double, and the web client writes 1 and 0 as integers. The FX preview fails for a mixture with a weight of 1 or a mean of 0. This is in the shared codec, so it is captured as The server refuses a whole number in a double field and not fixed here.

Manual QA scenarios (scaffolded via compass add test_scenario) that verify this task. Link new ones here as they're created; the scenario doc itself links back via its "Verifies task" field.

The BFF serves every synthetic entity the four journeys name. One table in bff/src/synthetic.ts holds the nine resources, and 14 routes serve them: the catalogue with each resource's permissions, all rows, one row by key, a save of one or many rows in one put_many, a removal of one row by version or of many rows at once, the three previews, the feed and folder start and stop, the running set and the vintage validity. The history route serves the synthetic types.

All acceptance bullets are met. The writes refuse a stale version with 409 in the server's words, and a save of a two-row mixture landed in one call on the live stack. The parameter definitions, the folders and the collections are read only, and the catalogue says why. Every route answered as designed against the running services, and 26 unit tests cover them.

The live run also found and fixed one defect. Every tenant listed an empty process type catalogue, because the model lacked system_tenant_validation. The flag is set, the handler regenerated, and an Acme user now reads the five types. Because that handler writes in the system tenant, the BFF writes the process types only from a system session.

Two defects stay open as captures, and one existing capture grows:

• The server refuses a whole number in a double field. The FX preview fails for a mixture with a weight of 1 or a mean of 0 until the codec accepts integers for doubles. The FX screen task depends on it.
• A tenant can write a system catalogue. The BFF guards the process types and the definitions; the bus does not.
• The four template defects capture now also records that a table check or a validation trigger refusal comes back as failed, so the BFF answers 502 with PostgreSQL text where a 400 belongs.

The component audit did not run: none of its triggers applies. The task added one file to an existing BFF folder and one flag to a synthetic model, cleared no drift and changed no folder or template. validate_docs.sh passes for all 41 components.