Problem
schemas/runtime/runtime-config.schema.json is the published contract for the runtime config, but it carries no title, no description and no default on its properties, and its root required is ["providers"] alone.
Every client that renders or explains a runtime config therefore has to supply all of that itself. In anolis-workbench, RuntimeForm.svelte is a hand-authored overlay of ~18 fields whose labels, help text and implied defaults are maintained by hand, with nothing tying them to this schema and no CI check that they still agree with the runtime's actual behaviour.
The practical consequence: a client that wants to say "not set — the runtime's default applies" has to hand-copy the default out of the runtime's own config sources, unhashed and unverified, which shadows a contract that already has a lock file and a byte-identity check.
Ask
Add to schemas/runtime/runtime-config.schema.json:
title and description on each property, describing what it does and what it costs to get wrongdefault wherever the runtime has one, matching the value the runtime actually applies when the key is absent
This is additive and does not change the accepted document set.
Why it matters beyond cosmetics
Consumers vendor this schema and verify it byte-identical against the release asset, so they can never author these annotations themselves. Putting the descriptions here is the only way a client can explain a runtime setting without inventing its own parallel truth.
It also unblocks a second thing downstream: the vendored copy in anolis-workbench is currently pinned at an older tag and predates both the safety and health blocks. Resyncing it is what makes any client-side handling of safety possible at all, and that resync is more useful if the schema is self-describing when it lands.
Acceptance
- Every property carries
title and description.
- Every property the runtime defaults carries a
default equal to the applied value.
- Existing valid configs remain valid; no new
required entries.
Problem
schemas/runtime/runtime-config.schema.jsonis the published contract for the runtime config, but it carries notitle, nodescriptionand nodefaulton its properties, and its rootrequiredis["providers"]alone.Every client that renders or explains a runtime config therefore has to supply all of that itself. In
anolis-workbench,RuntimeForm.svelteis a hand-authored overlay of ~18 fields whose labels, help text and implied defaults are maintained by hand, with nothing tying them to this schema and no CI check that they still agree with the runtime's actual behaviour.The practical consequence: a client that wants to say "not set — the runtime's default applies" has to hand-copy the default out of the runtime's own config sources, unhashed and unverified, which shadows a contract that already has a lock file and a byte-identity check.
Ask
Add to
schemas/runtime/runtime-config.schema.json:titleanddescriptionon each property, describing what it does and what it costs to get wrongdefaultwherever the runtime has one, matching the value the runtime actually applies when the key is absentThis is additive and does not change the accepted document set.
Why it matters beyond cosmetics
Consumers vendor this schema and verify it byte-identical against the release asset, so they can never author these annotations themselves. Putting the descriptions here is the only way a client can explain a runtime setting without inventing its own parallel truth.
It also unblocks a second thing downstream: the vendored copy in
anolis-workbenchis currently pinned at an older tag and predates both thesafetyandhealthblocks. Resyncing it is what makes any client-side handling ofsafetypossible at all, and that resync is more useful if the schema is self-describing when it lands.Acceptance
titleanddescription.defaultequal to the applied value.requiredentries.