Task: Edit the run document through the projection

The package handler states a date change as a document change and asks the codec for the facts it needs, so no caller depends on how ORE spells an element.

• No code searches for an ORE element name or attribute spelling.
• The as-of date is read and set through the run document projection.
• The latest market data date comes from the market data reader.
• Tests cover a document whose marker sits in a comment, and one that writes its attributes in another order.

Both facts the handler needs are operations the codec can state, so they become operations on the two readers rather than searches inside the handler:

• run_document_projection::as_of_date reads the document and maps it, so the parameter is found by name and the projection decides what an as-of date is. with_as_of_date maps the document, sets the date, and writes it back through the projection, which is also how the export built it.
• market::latest_market_data_date reads the body with the market data parser and takes the last date it states, so a comment, a second date spelling or a repeated key are the parser's business.

The handler keeps what it alone knows: that a run prices at the data's last date when the data ends before the date the run asked for.

The tests live with the owners: a document that mentions the parameter in a comment and again inside an analytic, one that spells the attribute with other spacing and quote characters, one that states no date, and a body with comments, two date spellings and a line the tokeniser refuses.

ORE's schema gives Parameter one attribute, so "another attribute order" cannot be written for the element this task reads. The spellings XML does allow, and the decoy in an analytic's parameter list, are the cases a text search reads wrong.

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.

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 package handler states a date change as a document change and asks the codec for the facts it needs. Its three text helpers are gone: no code outside the projection searches for an ORE element name or attribute spelling.

as_of_date and with_as_of_date are operations on the run document projection, and latest_market_data_date is an operation on the market data parser. The rewrite goes through the same reverse the export used, so the document it writes is the one the export would have written with the other date: the parameters the model always states are written with the values the document gave them, and no parameter outside the model is invented.

A line the market data tokeniser cannot read is not a date line and is skipped, so a body with junk in it still states the newest date the lines around it carry. That mattered: reading a refused line as "no date" failed a run whose data did carry dates.

The handler keeps one rule of its own, which is about runs and not about ORE: a run whose gathered data ends before the date it asked for prices at the data's last date, and says so.