Task: Write the ORE index codec

A fixing is named by a hand-written index codec that reads every index name ORE reads, as ORE reads it, and writes it back; the fixing import, export and classification use it, and the generated grammar has no remaining consumer.

• A catalogue of index names, taken from every fixing file in the corpus and from the forms ORE's parseIndex documents, records ORE's own reading of each, regenerated from the local ORE build like the key catalogue.
• The codec accepts the index names ORE accepts and refuses the ones it refuses, and write(read(n)) == n or the canonical spelling where ORE reads an alias.
• The fixing URI shape is agreed with the product owner before the codec writes it, and a fixing URI is one to one with the canonical index name.
• The fixing import, the export and the classifier's index-name rule use the codec; oresmd_parser and oresmd_projections have no production consumer.
• The SQL seeds that hold fixing URIs hold the new form, and a test checks every one.

Added on 2026-10-03, when the retire task found that fixings still need the generated grammar: a fixing is named by an ORE index name such as EUR-EURIBOR-6M, UKRPI or FX-ECB-EUR-USD, and only the old grammar's from_index_name and to_index_name read and write one. The product owner chose to replace it before the retire task removes the grammar, rather than keep the fixing half or flatten the fixing identity.

The same method as the key codec:

1. Extend the catalogue harness to ORE's parseIndex, and record ORE's reading of every index name in the corpus's fixing files and of the forms parseIndex documents.
2. Model the index identity as data, the way the schema models a quote.
3. Agree the fixing URI shape with the product owner.
4. Write the codec, test it against the catalogue, and move the fixing import, the export and the classifier onto it, with the seeds.

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.

ore_index_codec reads every index name ORE's parseIndex reads, by structure, and writes it back; market_index holds a fixing's identity as data, one row per family; and oresmd_uri_codec writes and reads the agreed fixing URI. The fixing import, the export, the classifier and the tenant provisioning handler use them, so the generated grammar has no production consumer and the retire task can delete it. Along the way this found and fixed a regression from the cut-over: tenant provisioning still wrote old-form feed bindings.