Task: Split the configuration document protocol by document family

The configuration document protocol is split on the seam the investigation names, so no translation unit's encode path reaches every convention and curve type at once, and the Windows MSVC build passes with no /constexpr flag.

• The protocol and handler are split on the seam the investigation names, and each translation unit reaches one document family.
• The NATS subjects, message shapes and generated codecs are unchanged apart from the file split.
• The Windows MSVC job of continuous-windows.yml passes, or the remaining failure is recorded against its own task.
• No new MSVC compiler flag is added, and the existing ores.trading.api flags are left as they are unless a separate task removes them.

The task's premise is that the MSVC build fails on C1202 in the reflected aggregate. On 2026-10-28 it does not: the nightly run 40643890504 contains no C1202 at all, because the build stops earlier:

real_environment_provider.cpp(28): error C2220: the following warning is
treated as an error
clang-cl: error: 'getenv' is deprecated [-Wdeprecated-declarations]

That is a unity-build effect: the file defined _CRT_SECURE_NO_WARNINGS, which arrives after the CRT has already been included by an earlier file in the same unity unit, so it suppressed nothing. Fixed by reading the environment with _dupenv_s on Windows and dropping the define.

The same sweep found the rule broken in four test files, eighteen calls in all, one of which suppressed the warning with the same macro and one of which used setenv, unsetenv and tzset with no platform guard at all – a Windows build break waiting behind this one. They read through ores.platform now, and the timezone calls have a portable shim. No warning is suppressed anywhere in the tree; the only native getenv left is the provider's own POSIX branch, which is where the project's memory says it belongs.

The consequence for this task is an order, not a change of goal: the C1202 cannot be observed, let alone measured, until the build gets past the errors in front of it. The Windows job also reports nats-server did not become ready within 30s, which is its own problem and does not stop the compile.

With the environment read fixed, the 2026-10-28 run 40722677906 gets past it and stops somewhere else, in each of its two compilers.

MSVC stops on a unity-build name clash in this project's own header:

ores.nats/service/retry.hpp(56): warning C4459: declaration of 'logger_name'
hides global declaration  -> error C2220
note: see declaration of 'ores::nats::service::`anonymous-namespace'::logger_name

The local in retry_with_backoff is now named for the retry, so it hides nothing.

clang-cl stops inside third-party headers, on a preprocessor error rather than on anything this project wrote:

vcpkg_installed/x64-windows/include/rfl/Literal.hpp:413:75: error: too few
arguments provided to function-like macro invocation
(same in rfl/Variant.hpp:31 and rfl/Generic.hpp:211)

That is a separate failure with a separate owner: it is an =rfl=/clang-cl interaction, it appears in headers the project does not own, and nothing in the configuration document is involved. It is recorded here so the split is not blamed for it, and it wants its own task before the clang-cl job can prove anything about this one.

The run 40783811342 on main at 0d97232d7f carries the getenv, retry.hpp and codec.cpp fixes. Both legs move, and neither reaches the aggregate.

• MSVC gets past ores.database and into ores.refdata.core – the component this task is about – where it stops on C4702: unreachable code in counterparty_identifier_service.cpp and counterparty_service.cpp. Both files refuse a direct write with a [[noreturn]] helper, so everything after it is dead. The dead bodies are deleted in #4037.
• clang-cl stops where it did, but the cause is now known: Windows.h's min and max macros break std::numeric_limits<T>::max() inside rfl. NOMINMAX is defined for every Windows target in #4033.

The order the story's plan set still holds: each fix clears one error, the next run names the next one, and C1202 is judged only when the MSVC leg compiles the document's own unit.

The measurement first. The document holds 33 typed vectors plus its configuration object, in one reflected struct: a literal of 34 names. The sprint 28 investigation measured the unit as Mode 1, context accumulation, not a single literal that is too wide: the same 24-name tenor_basis_swap_convention literal built in a unit of 12 headers and failed in a unit of 103. See Why the configuration document protocol unit is wide.

That reading decides the remedy, and it rules out two candidates:

• A file split alone does not lower accumulation, and under a unity build it cannot even separate the files: every source of the component lands in the same unit.
• rfl::Flatten is not a decomposition fix either. It adds the flattened struct's names to the parent's literal, recursively, so a wide parent stays wide, and it is a JSON-shape decision, never a compile fix. A plain nested member, by contrast, costs the parent one name and does lower its literal. Either way the accumulation path is untouched. See Data-Oriented Design in ORE Studio.

What the investigation recommended, and what already happened. It recommended one operation model per document family, so each unit's encode graph reaches one document. The conventions half is gone: ebcf187bca deleted the conventions aggregate and the whole-document service, so this protocol now carries one document of 33 element types where it carried two and 58. That is 25 of the 58 element types gone, and the heavier ones: the investigation put the widest literal in the deleted document at 60 names (commodity_future_convention), above the 59-member struct the project had measured building. The accumulation left the unit by deleting a document, not by splitting a file.

What remains is 33 element types in one unit, and whether that is over MSVC's ceiling is not known: C1202 has never been reached, because the Windows job stops earlier every time. The next step is evidence, not code.

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.

• 2026-10-28. The field-group template said that composing a parent with rfl::Flatten keeps the per-struct field count low. The Data-Oriented Design decomposition section says the opposite: Flatten adds the group's names to the parent's literal, recursively. The template is corrected with this page, and the plan below no longer proposes that split.
• The same day's nightly answers nothing about this task yet: the MSVC leg stops in ores.database, and the clang leg inside rfl's headers, on min=/=max from Windows.h. Both are separate tasks.

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.