Manage synthetic collections prototype

A collection is a market_data_generation_config: a name, a description, an enabled flag, the system party, a provider and a dataset of origin, and it owns the typed FX and IR feeds beneath it. In the tree the same rows are the Collection nodes, and the folder-scoped start request names one node.

The open question is how the ownership and the provenance stay visible while the collection is chosen and started. The tree says nothing else about a node: not what it owns, what it was published from, who changed it, or what coverage a start will produce.

Switch with the bottom bar, or ?variant. The default is a. The variants disagree about where the collection is judged: as a row among rows, as a record with an audit tail, or as the coverage it produces.

A is the working view and the closest to the existing window. B gives the provenance equal standing with the fields. C is the view the group did not have, and it reads an empty cell as a gap rather than a zero.

Switch with the bottom bar, or ?state. The default is realistic. Each state sets the mock collection the page reads, drawn from the seed populate scripts under =projects/ores.sql/populate/synthetic/.

ORE Samples 2016, the disabled IBOR-era theme, is in the list but not the bar.

Everything on the page is live and nothing is stored. New Collection adds an empty collection with no feeds; Edit opens the detail form on that collection; Delete asks first and says the feeds go with it; Start all and Stop all set the mock feeds running and report one folder-scoped request, fanned out by the server. Reset mock changes appears once a change is made; Save reports the version the save would write.

Everything on the page is mock data. The four collections, their names, descriptions, dataset ids, versions, audit rows and histories are hard-coded literals, as are their feeds, currencies, index families, process types and source names. There is no server, no session and no build step.

doc/prototypes/market_data/manage-synthetic-collections/. One file, index.html, with its CSS and its JavaScript inline: no framework, no prototype.css and no prototype.js. The site build copies the directory as it stands and adds nothing.

The group accepted the argument and recorded it as the row this note answers to: a collection is the unit a person starts and stops, so it must show what it owns and where it came from before it is run. What the group took is not one variant but the requirement they share: the list states the feed count and the asset classes, the detail states the dataset, the actor and the version history, and the coverage states what a start would span. The three variants and the four states stayed on the page as the record.

The coverage view. The screens note records that no screen shows a collection's coverage before it is started, and variant C argues for one. Whether it belongs in the list, in the detail, or on a page of its own is open.

The delete cascade. The page deletes a collection and its feeds together, behind one confirmation. Whether each feed is named, or the whole set is deleted as one act, is open.

The start and the enabled flag. The page draws Start all beside Delete, and a collection can be enabled while no feed runs. Whether enabling and starting are one act is open, as is the collision Uniform Demo states, its IR curves left at auto-start false because they meet Realistic 2026 on currency and index family.

The collection's own axes. scope and binding_mode are not drawn at all, and the page shows dataset_id without showing how a publish from a DQ dataset resolves it. A feed is identified by its source_name, so a rename is a re-identification, and the page does not offer one.